Android 的 HAL 技术，1： HAL的过去现在未来简介-车机

Android 的 HAL（硬件抽像层）是 Google 因应厂商「希望不公开源码」的要求下，所推出的新观念，其架构如下图。

虽然 HAL 现在的「抽象程度」还不足（2009年），现阶段实现还不是全面符合 HAL 的架构规划，不过也确实给了我们很好的思考空间。

图1：Android HAL 架构规划

这是 Patrick Brady （Google） 在 2008 Google I/O 所发布的演讲Anatomy & Physiology of an Android中，所提出的 Android HAL 架构图。 从这张架构图我们知道，HAL 的目的是为了把 Android framework 与 Linux kernel 完整「隔开」。 让 Android 不至过度依赖 Linux kernel，有点像是「kernel independent」的意思，让 Android framework 的开发能在不考虑驱动代码的前提下进行发展。

在 Android 源代码里，HAL 主要的实现存储于以下目录 ：

1. libhardware_legacy/ - 过去的实现、采取库模块的方法
2. libhardware/ - 新的实现、调整为 HAL stub （代理人）（一种代理proxy的概念）的方法
3. ril/ - Radio Interface Layer

图3：Android HAL / libhardware

图2：Android HAL / libhardware_legacy

过去的libhardware_legacy的实现，是比较传统的「module」方法，也就是将 *.so 库当做「shared library」来使用，在 runtime（JNI 部分）以 direct function call 使用 HAL module。 通过直接函数调用的方式，来操作驱动程序。当然，应用程序也可以不需要透过 JNI 的方式进行，直接以加载 *.so 文件（dlopen）的做法调用 *.so 里的符号（symbol）也是一种方式。

现在的 libhardware 作法，就有「stub」的味道了。 HAL stub 是一种代理人（proxy）的概念，stub 虽然仍是以 *.so 文件的形式存在，但 HAL 已经将 *.so 文件隐藏起来了。 Stub 向 HAL「提供」操作函数（operations），而 runtime （JNI 部分）则是向 HAL 取得特定模块（stub）的 operations，再 callback 这些操作函数。 这种以indirect function call（非直接函数调用）的实现架构，让HAL stub变成是一种包含关系，即HAL里包含了许许多多的 stub（代理人）。 Runtime（JNI 部分） 只要说明「类型」，即 module ID，就可以取得操作函数。

未来的 HAL 做法，倾向全面采用 JNI 的方式进行。 也就是，在 Android 的架构中，修改 Android runtime 实现（即「Core Library」），在取得 HAL 模块的 operations 后再做 callback 操作。 将 HAL 模块完全放在 HAL 里面。

参考：

https://www.jollen.org/blog/2009/10/android-hal-status-report.html