dynamic app(module) access oem layer的机制介绍 作者:东方欲晓
brew采用分层机制,主要为aee层,oem层以及再底下的驱动,系统服务层,分别针对不同的brew运用者.
aee层主要面向brew developer,在这一层高通利用com style实现了一套interface(class)集,每个interface具有特定的一些接口api函数,brew上层应用开发者就是通过创建这些interface(class)的实例并利用他们的接口api函数来实现一系列的应用.简而言之,aee层就是大家都能下载到的brew sdk.
oem层是面向手机oem厂商的,是用来进行brew porting的.aee层虽然定义并实现了一套标准的interface,但是在aee层的这些interface接口函数的具体实现中最终会调用oem层的函数.因为brew类似于一个中间件,与底层平台无关. 但是这种无关性是通过oem厂商的"相关"的操作来实现的.即brew在aee层定义了标准的接口行为,而在oem层由厂商各自通过不同的方式来实现同样的外在表现. 一旦oem层的这些函数厂商都实现了(平台相关性),那么标准的brew aee层就可以顺利调用这些oemXXX的函数来达到规定的行为了(表现出平台无关性).
所有,不同层面向不同的用户.对于brew上层开发者而言,本质上只需要,也只可以access到aee层,即只能运用aee层中的interface,接口函数以及一些aee层的特殊函数. 而oem厂商则同时可以access这两层,在oem层需要access aee层,这是因为有些oem层的函数中大量用到了aee层的一些control.
由上可见,brew上层应用开发的dynamic app(module)只能,也只需要access aee层.
但是,在brew中存在一个独特的interface,IOEMBRIDGE,其vtbl表很特别,正好是oem厂商实现的所有oem层函数的指针表,它的class中(除了vtbl外)唯一的数据成员是引用计数m_nRef,并且该class在oem层被定义为static,初始值为0,这样将保证每次创建的都是同一个实例(即编译期分配的static对象). 这里为什么只用single instance的方式那,理由很简单,它的class不存在其他的数据成员,而vtbl本来就是对象共用的,m_nRef只是用来判读是否首次创建对象,如果是首次创建,则实例化vtbl表(即将vtbl表和oem厂商实现的所有oem层函数关联起来,注意,并不创建对象,因为对象是static的,编译时已经产生,并且一直存在),否则不多此一举.
既然存在这样一个interface,那在程序中那里用到了它那,我试着在整个brew源码工程中查找哪里createinstance了这个interface(通过查找特定该interface的clsid的ishell_createinstance是否被调用),结果根本没有找到.
我困惑了,既然它存在,又这么特殊(vtbl正好是所有oem层函数的集合),为什么又没有用到它那.
后来我请求高人,结果让我恍然大悟!
答案是该interface(class)是作为aee层通向oem层的bridge,即,brew 开发者的dynamic app(module)可以通过创建该interface(class)从而直接access oem层并直接调用oem层的函数.
但是,你几乎(或者说根本)没有看到过有dynamic app(module)这样去作过.
除了OAT.
OAT听过把, 曾经是那么神秘, 它凭什么可以来测试我们底层对接口的实现到底正不正确那?
就是凭这个!
大家如果可以看到OAT源码的话,就真相大白了.
每一个测试的OAT module都会通过创建IOEMBRIDGE的实例来access oem层,从而来测试oem层的实现的正确与否.
比如OATTEXT专门用来测试oem厂商对输入法的实现是否正确, 具体而言,OATTEXT MODULE首先创建IOEMBRIDGE INTERface,从而取得了access oem layer的钥匙,接着调用它感兴趣的那些IOEMBRIDG的接口函数,比如那些和Itextctl有关的oem层的函数(因为该模块只负责测试text input), 从而来完成测试(测试分为自动的和交互的,比如当调用创建text的oem层函数后,会友好的提示,你是否看到了一个编辑框出现在屏幕上那? 按pass 确认,按retry重试.....)
当然,除了OAT外,其他的dynamic app好像真的没有什么理由需要用到这个interface,至少现在是.
不过毕竟brew中是存在这样一个沟通aee层与oem层的bridge. 不过它可是控制在oem厂商的手里哦,一旦通过高通oat测试后,完全可以将该interface kill掉. 或者,对外的访问宏定义(即类似IXXX_XXX()的这种能访问vtbl函数的宏定义)只向高通开放,这样developer将不知道如何调用这些函数,即便创建了该interface也是白忙一场压.
读者大概要问了,那你写本文的目的是什么那?
本文的目的只是想说明几个概念: brew分层的概念,class机制的概念,以及层与层之间是有联系的,并且是存在这样一座bridge的
--
brew采用分层机制,主要为aee层,oem层以及再底下的驱动,系统服务层,分别针对不同的brew运用者.
aee层主要面向brew developer,在这一层高通利用com style实现了一套interface(class)集,每个interface具有特定的一些接口api函数,brew上层应用开发者就是通过创建这些interface(class)的实例并利用他们的接口api函数来实现一系列的应用.简而言之,aee层就是大家都能下载到的brew sdk.
oem层是面向手机oem厂商的,是用来进行brew porting的.aee层虽然定义并实现了一套标准的interface,但是在aee层的这些interface接口函数的具体实现中最终会调用oem层的函数.因为brew类似于一个中间件,与底层平台无关. 但是这种无关性是通过oem厂商的"相关"的操作来实现的.即brew在aee层定义了标准的接口行为,而在oem层由厂商各自通过不同的方式来实现同样的外在表现. 一旦oem层的这些函数厂商都实现了(平台相关性),那么标准的brew aee层就可以顺利调用这些oemXXX的函数来达到规定的行为了(表现出平台无关性).
所有,不同层面向不同的用户.对于brew上层开发者而言,本质上只需要,也只可以access到aee层,即只能运用aee层中的interface,接口函数以及一些aee层的特殊函数. 而oem厂商则同时可以access这两层,在oem层需要access aee层,这是因为有些oem层的函数中大量用到了aee层的一些control.
由上可见,brew上层应用开发的dynamic app(module)只能,也只需要access aee层.
但是,在brew中存在一个独特的interface,IOEMBRIDGE,其vtbl表很特别,正好是oem厂商实现的所有oem层函数的指针表,它的class中(除了vtbl外)唯一的数据成员是引用计数m_nRef,并且该class在oem层被定义为static,初始值为0,这样将保证每次创建的都是同一个实例(即编译期分配的static对象). 这里为什么只用single instance的方式那,理由很简单,它的class不存在其他的数据成员,而vtbl本来就是对象共用的,m_nRef只是用来判读是否首次创建对象,如果是首次创建,则实例化vtbl表(即将vtbl表和oem厂商实现的所有oem层函数关联起来,注意,并不创建对象,因为对象是static的,编译时已经产生,并且一直存在),否则不多此一举.
既然存在这样一个interface,那在程序中那里用到了它那,我试着在整个brew源码工程中查找哪里createinstance了这个interface(通过查找特定该interface的clsid的ishell_createinstance是否被调用),结果根本没有找到.
我困惑了,既然它存在,又这么特殊(vtbl正好是所有oem层函数的集合),为什么又没有用到它那.
后来我请求高人,结果让我恍然大悟!
答案是该interface(class)是作为aee层通向oem层的bridge,即,brew 开发者的dynamic app(module)可以通过创建该interface(class)从而直接access oem层并直接调用oem层的函数.
但是,你几乎(或者说根本)没有看到过有dynamic app(module)这样去作过.
除了OAT.
OAT听过把, 曾经是那么神秘, 它凭什么可以来测试我们底层对接口的实现到底正不正确那?
就是凭这个!
大家如果可以看到OAT源码的话,就真相大白了.
每一个测试的OAT module都会通过创建IOEMBRIDGE的实例来access oem层,从而来测试oem层的实现的正确与否.
比如OATTEXT专门用来测试oem厂商对输入法的实现是否正确, 具体而言,OATTEXT MODULE首先创建IOEMBRIDGE INTERface,从而取得了access oem layer的钥匙,接着调用它感兴趣的那些IOEMBRIDG的接口函数,比如那些和Itextctl有关的oem层的函数(因为该模块只负责测试text input), 从而来完成测试(测试分为自动的和交互的,比如当调用创建text的oem层函数后,会友好的提示,你是否看到了一个编辑框出现在屏幕上那? 按pass 确认,按retry重试.....)
当然,除了OAT外,其他的dynamic app好像真的没有什么理由需要用到这个interface,至少现在是.
不过毕竟brew中是存在这样一个沟通aee层与oem层的bridge. 不过它可是控制在oem厂商的手里哦,一旦通过高通oat测试后,完全可以将该interface kill掉. 或者,对外的访问宏定义(即类似IXXX_XXX()的这种能访问vtbl函数的宏定义)只向高通开放,这样developer将不知道如何调用这些函数,即便创建了该interface也是白忙一场压.
读者大概要问了,那你写本文的目的是什么那?
本文的目的只是想说明几个概念: brew分层的概念,class机制的概念,以及层与层之间是有联系的,并且是存在这样一座bridge的
--
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
