Android HAL

核心提示：现在的 libhardware 作法，就有「 stub 」的味道了，Android HAL(2)， HAL stub 是一种代理人( proxy )的概念， stub 虽然仍是以 *.so ?的形式存在，其中 hardwarelibhardware 下是同一用模块的概念来加载 HAL 的 .so 库， 这里以一个简单的

现在的 libhardware 作法，就有「 stub 」的味道了。 HAL stub 是一种代理人( proxy )的概念， stub 虽然仍是以 *.so ?的形式存在，但 HAL 已经将 *.so 档隐藏起来了。 Stub 向 HAL 「提供」操作函数( operations )，而 runtime 则是向 HAL 取得特定模块( stub )的 operations ，再 callback 这些操作函数。这种以 indirect function call 的实作架构，让 HAL stub 变成是一种「包含」关系，即 HAL 里包含了许许多多的 stub (代理人)。 Runtime 只要说明「类型」，即 module ID ，就可以取得操作函数。 HAL 的实现主要在 hardware.c 和 hardware.h 文件中。实质也是通过加载 *.so 档( dlopen )从而呼叫 *.so 里的符号( symbol )实现。这里所谓的代理，我感觉不过是 Android 统一定义了三个结构体，然后通过几个“必须”从而统一了调用接口

HAL 的未来发展?

新的 HAL 做法，倾向全面采用 JNI 的方式进行。也就是，在 Android 的架构中，修改 Android runtime 实作(即「 Core Library 」)，在取得 HAL 模块的 operations 后再做 callback 操作。将 HAL 模块完全放在 HAL 里面。以上我想应该是针对 framework 开发来说的。如果仅是使用 hal 访问硬件，完全可以不修改 core library 。

一、 HAL 使用步骤：

(1)Java AP 初始化一个 java service ， 然后根据需求组合调用 java service 提供的接口。

(2)Java Service 设置 Native Interface 声明， 并在初始化时加载 Native Service 所在的库 .Native Service 实际上是一个动态链接库， 通过 JNI 和 Java Service 交互。

(3) 通过 OnLoad 方法注册与 Java Service 的 Native Function 之间的对应 JNI table 。

(4) 通过 HAL Module ID 获得当前实际板上对应的硬件设备的 Module ， 并通过此 Module 的 HAL 接口 Open 获得硬件设备的 device 实例。 通过 device 提供的接口组合本地函数的实现。

(5) 编写 HAL stub, 对具体的硬件设备初始化对应 Module 和 Device 实例， 并实现对硬件驱动的 API 封装。

(6)HAL 模块要以 MODULE_ID.platform.so 的名字存放在文件系统的 /system/lib/hw/ 下面。

Android HAL 层主要在 hardware 目录下，其中 hardwarelibhardware 下是同一用模块的概念来加载 HAL 的 .so 库。 这里以一个简单的 led 小例子(假设备，不涉及硬件操作)来说明具体实现步骤。