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 主要的完成存储于以下目次 ：
- libhardware_legacy/ – 已往的完成、接纳库模块的办法
- libhardware/ – 新的完成、调停为 HAL stub （署理人）（一种署理proxy的看法）的办法
- 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
