Android HAL层分析 (gralloc显示模块 举例）



Android的HAL是为了保护一些硬件提供商的知识产权而提出的，是为了避开linux的GPL束缚。思路是把控制硬件的动作都放到了Android HAL中，而linux driver仅仅完成一些简单的数据交互作用，甚至把硬件寄存器空间直接映射到user space。而Android是基于Aparch的license，因此硬件厂商可以只提供二进制代码，所以说Android只是一个开放的平台，并不是一个开源的平台。

一、代码文件介绍

/hardware/libhardware_legacy/ - 旧的架构、采取链接库模块的方式

/hardware/libhardware     新架构、调整为 HAL stub 目录的结构如下：

/hardware/libhardware/hardware.c  编译成libhardware.s置于/system/lib

/hardware/libhardware/include/hardware目录下包含如下头文件：

hardware.h                             通用硬件模块头文件

copybit.h                              copybit模块头文件

gralloc.h                              gralloc模块头文件

lights.h                              背光模块头文件

overlay.h                              overlay模块头文件

qemud.h                               qemud模块头文件

sensors.h                              传感器模块头文件

/hardware/libhardware/modules  目录下定义了很多硬件模块

/hardware/msm7k  /hardware/qcom  /hardware/ti  /device/Samsung 

/device/moto            各个厂商平台相关的hal

这些硬件模块都编译成xxx.xxx.so，目标位置为/system/lib/hw目录

二、HAL层实现方式

目前HAL存在两种构架，位于libhardware_legacy目录下的“旧HAL架构”和位于libhardware目录下的“新HAL架构”。两种框架如下图所示：

libhardware_legacy 是将 *.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 则是向 HAL 取得特定模块（stub）的 operations，再 callback 这些操作函数。这种以 indirect function call 的架构，让HAL stub 变成是一种包含关系，即 HAL 里包含了许许多多的 stub（代理人）。Runtime 只要说明类型，即 module ID，就可以取得操作函数。对于目前的HAL，可以认为Android定义了HAL层结构框架，通过几个接口访问硬件从而统一了调用方式。

Android的HAL的实现需要通过JNI(Java Native Interface)，JNI简单来说就是java程序可以调用C/C++写的动态链接库，这样的话，HAL可以使用C/C++语言编写，效率更高。JNI->通用硬件模块->硬件模块->内核驱动接口，具体一点：JNI->libhardware.so->xxx.xxx.so->kernel，具体来说：android frameworks中JNI调用hardware.c中定义的hw_get_module函数来获取硬件模块，然后调用硬件模块中的方法，硬件模块中的方法直接调用内核接口完成相关功能

在Android下访问HAL大致有以下两种方式：

   （1）Android的app可以直接通过service调用.so格式的jni

（2）经过Manager调用service

上面两种方法应该说是各有优缺点，第一种方法简单高效，但不正规。第二种方法实现起来比较复杂，但更符合目前的Android框架。第二种方法中，LegManager和LedService（java）在两个进程中，需要通过进程通讯的方式来通讯。

在现在的android框架中，这两种方式都存在，比如对于lights，是直接透过LightsService调用JNI，而对于sensor，中间则是通过SensorsManager

来调用JNI的。

三、源码分析

最近在看SurfaceFlinger，我们就以这个为切入点，我们来看下面这段代码，通过hw_get_module函数通过HAL层获取到module，然后通过gralloc_open函数通过module来获取device。

GraphicBufferAllocator::GraphicBufferAllocator()
    : mAllocDev(0)
{
    hw_module_t const* module;
    int err = hw_get_module(GRALLOC_HARDWARE_MODULE_ID, &module);
    if (err == 0) {
        gralloc_open(module, &mAllocDev);
    }
}

3.1 hw_get_modeule

我们先来看hardware/libhardware/hardware.c中的hw_get_module函数，调用了hw_get_module_by_class函数。

int hw_get_module(const char *id, const struct