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

　　Android的HAL（硬件抽像层）是Google因应厂商希望不公开源码的要求下，所推出的新观念，其架构如下图。
　　虽然HAL现在的抽象程度还不足（2009年），现阶段实现还不是全面符合HAL的架构规划，不过也确实给了我们很好的思考空间。
　　图1：AndroidHAL架构规划
　　这是PatrickBrady（Google）在2008GoogleIO所发布的演讲AnatomyPhysiologyofanAndroid中，所提出的AndroidHAL架构图。从这张架构图我们知道，HAL的目的是为了把Androidframework与Linuxkernel完整隔开。让Android不至过度依赖Linuxkernel，有点像是kernelindependent的意思，让Androidframework的开发能在不考虑驱动代码的前提下进行发展。
　　在Android源代码里，HAL主要的实现存储于以下目录：libhardwarelegacy过去的实现、采取库模块的方法libhardware新的实现、调整为HALstub（代理人）（一种代理proxy的概念）的方法rilRadioInterfaceLayer
　　图3：AndroidHALlibhardware
　　图2：AndroidHALlibhardwarelegacy
　　过去的libhardwarelegacy的实现，是比较传统的module方法，也就是将。so库当做sharedlibrary来使用，在runtime（JNI部分）以directfunctioncall使用HALmodule。通过直接函数调用的方式，来操作驱动程序。当然，应用程序也可以不需要透过JNI的方式进行，直接以加载。so文件（dlopen）的做法调用。so里的符号（symbol）也是一种方式。
　　现在的libhardware作法，就有stub的味道了。HALstub是一种代理人（proxy）的概念，stub虽然仍是以。so文件的形式存在，但HAL已经将。so文件隐藏起来了。Stub向HAL提供操作函数（operations），而runtime（JNI部分）则是向HAL取得特定模块（stub）的operations，再callback这些操作函数。这种以indirectfunctioncall（非直接函数调用）的实现架构，让HALstub变成是一种包含关系，即HAL里包含了许许多多的stub（代理人）。Runtime（JNI部分）只要说明类型，即moduleID，就可以取得操作函数。
　　未来的HAL做法，倾向全面采用JNI的方式进行。也就是，在Android的架构中，修改Androidruntime实现（即CoreLibrary），在取得HAL模块的operations后再做callback操作。将HAL模块完全放在HAL里面。
　　参考：
　　https：www。jollen。orgblog200910androidhalstatusreport。html