LedHal案例分析.docxVIP

?LedHAL实例架构 上图描述了我们Led实例的框架层次： l? LedDemo.java：是我们写的Android应用程序 l? LedService.java：是根据Led HAL封装的Java框架层的API，主要用于向应用层提供框架层API，它属于Android的框架层 l? libled_runtime.so：由于Java代码不能访问HAL层，该库是LedService.java对应的本地代码部分 l? led.default.so：针对led硬件的HAL代码 LedDemo通过LedService提供的框架层API访问Led设备，LedService对于LedDemo应用程序而言是Led设备的服务提供者，LedService运行在Dalvik中没有办法直接访问Led硬件设备，它只能将具体的Led操作交给本地代码来实现，通过JNI来调用Led硬件操作的封装库libled_runtime.so，由HAL Stub框架可知，在libled_runtime.so中首先查找注册为led的硬件设备module，找到之后保存其操作接口指针在本地库中等待框架层LedService调用。led.default.so是HAL层代码，它是上层操作的具体实施者，它并不是一个动态库（也就是说它并没有被任何进程加载并链接），它只是在本地代码查找硬件设备module时通过ldopen”杀鸡取卵”找module，返回该硬件module对应的device操作结构体中封装的函数指针。 其调用时序如下： Led HAL实例代码分析 我们来看下led实例的目录结构： 主要文件如下： com.hello.LedService.cpp：它在frameworks/services/jni目录下，是的Led本地服务代码 led.c：HAL代码 led.h：HAL代码头文件 LedDemo.java：应用程序代码 LedService.java：Led框架层服务代码 在Android的源码目录下，框架层服务代码应该放在frameworks/services/java/包名/目录下，由Android的编译系统统一编译生成system/framework/services.jar文件，由于我们的测试代码属于厂商定制代码，尽量不要放到frameworks的源码树里，我将其和LedDemo应用程序放在一起了，虽然这种方式从Android框架层次上不标准。 另外，本地服务代码的文件名要和对应的框架层Java代码的名字匹配（包名+类文件名，包目录用“_“代替）。有源码目录里都有对应的一个Android.mk文件，它是Android编译系统的指导文件，用来编译目标module。 1)????????Android.mk文件分析 先来看下led源码中①号Android.mk： [plain]? HYPERLINK /mr_raptor/article/details/8082360 \o view plain view plain HYPERLINK /mr_raptor/article/details/8082360 \o copy copy include?$(call?all-subdir-makefiles)?? 代码很简单，表示包含当前目录下所有的Android.mk文件 先来看下led_app目录下的③号Android.mk： [plain]? HYPERLINK /mr_raptor/article/details/8082360 \o view plain view plain HYPERLINK /mr_raptor/article/details/8082360 \o copy copy #?调用宏my-dir，这个宏返回当前Android.mk文件所在的路径?? LOCAL_PATH:=?$(call?my-dir)??????????????????????????????????????? ?? #?包含CLEAR_VARS变量指向的mk文件build/core/clear_vars.mk，它主要用来清除编译时依赖的编译变量?? include?$(CLEAR_VARS)?????????????????????????????????????? ?? #?指定当前目标的TAG标签，关于其作用见前面Android编译系统章节?? LOCAL_MODULE_TAGS?:=?user?? ?? #?当前mk文件的编译目标模块?? LOCAL_PACKAGE_NAME?:=?LedDemo?? ?? #?编译目标时依赖的源码，它调用了一个宏all-java-files-under，该宏在build/core/definitions.mk