Android 系统HAL 简介

文章出处：http://blog.csdn.net/shift_wwx/article/details/54964384

请转载的朋友标明出处~~

在 《Android，在争议中逃离 Linux 内核的 GPL 约束》一文中说明了android 中产生HAL的过程，简单来说就是为了满足商业需求，避开GPL 约束。

Android Hal 架构分为两种：

• 旧的架构 module
• 新的架构 module stub

下面就两种架构各自特点具体分析：

一 Module架构
     Android用户应用程序或者框架层代码由Java实现，Java运行在Dalvik虚拟机中，没有办法直接访问底层硬件，只能通过调用so本地库代码实现，在so本地代码里有对底层硬件操作的代码，如下图所示：

                                          

       可以这样说，应用层或者框架层Java代码，通过JNI技术调用C或C++写的so库代码，在so库代码中调用底层驱动，从而实现上层应用操作底层硬件的目的。实现硬件操作的so库为module.
其实现流程如下图所示：

                                     

       这种设计架构虽然满足了Java应用访问硬件的需要，但是，使得我们的代码上下层次间的耦合太高，用户程序或者框架代码必须要去加载module库，如果底层硬件有变化，module要从新编译，上层也要做相应变化，另外，如果多个应用程序同时访问硬件，都去加载module，同一module被多个进程映射多次，会有代码的重入问题。

二、新的架构

     新的代码架构使用的是module stub方式.Stub是存根或者桩的意思，其实说白了，就是指一个对象代表的意思。上层应用层或者框架层代码加载so库代码，so库代码我们称之为module，在Hal层注册了每个硬件对象的存根stub，当上层需要访问硬件的时候，就从当前注册的硬件对象stub里查找，找到之后stub会向上层module提供该硬件对象的operations interface（操作接口），该操作接口就保存在module中，上层应用或框架层再通过这个module操作接口来访问硬件。其架构如下：

                                                       

以上分别介绍了Module架构和Stub架构，下面做一个对比：

    在Module架构中，本地代码由so库实现，上层直接将so库映射到进程空间，会有代码重入及设备多次打开的问题。新的Stub框架虽然也要加载module库，但是这个module已经不包含操作底层硬件驱动的功能了，它里面保存的只是底层stub提供的操作接口，底层stub扮演了“接口提供者”的角色，当stub第一次被使用时加载到内存，后续再使用时仅返回硬件对象操作接口，不会存在设备多次打开的问题，并且由于多进程访问时返回的只是函数指针，代码并没有重入。

下一篇会继续说明HAL 实现过程和stub 架构