深入浅出 - Android系统移植与平台开发(十) - led HAL案例分析.pdfVIP

本文由兰州白癜风医院/收集，转载请注明出处 深入浅出 - Android 系统移植与平台开发（十） - led HAL 案例分析 通过前两节HAL 框架分析和JNI 概述，我们对Android 提供的Stub HAL 有了比较详细的 了解了，下面我们来看下led 的实例，写驱动点亮led 灯，就如同写程序，学语言打印 HelloWorld 一样，如果说打印HelloWorld 是一门新语言使用的第一声吆喝，那么点亮led 灯就是我们学习HAL 的一座灯塔，指挥我们在后面的复杂的HAL 代码里准确找到方向。 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 ： include $(call all-subdir-makefiles) 代码很简单，表示包含当前目录下所有的Android.mk 文件 先来看下led_app 目录下的③号Android.mk ： # 调用宏my-dir，这个宏返回当前Android.mk 文件所在的路径 LOCAL_PATH:= $(call my-dir) # 包含CLEAR_VARS 变量指向的mk 文件build/core/clear_vars.mk，它主要用来清除编 译时依赖的编译变量 include $(CLEAR_VARS) # 指定当前目