Android的HAL层遵循Apache协议 android hal层的作用

一、概述

        硬件抽象层（Hardware Abstraction Layer）是位于操作系统内核与硬件电路之间的接口层，其目的在于将硬件抽象化。它隐藏了特定平台的硬件接口细节，为操作系统提供虚拟硬件平台，使其具有硬件无关性，可在多种平台上进行移植。 从软硬件测试的角度来看，软硬件的测试工作都可分别基于硬件抽象层来完成，使得软硬件测试工作的并行进行成为可能。

1、Android HAL是什么？为什么有它？

        硬件抽象层是建立在Linux驱动之上的一套程序库。这套程序库并不属于Linux内核，而是属于Linux内核层上的应用层。在传统的Linux系统中Linux驱动一般有两种类型的代码：

• 访问硬件寄存器的代码。
• 业务逻辑代码。

        对于访问硬件寄存器的代码，并没有什么秘密可言，因为这些都是调用的Linux内核的标准函数进行的标准操作，而Linux驱动的业务逻辑部分对于有些企业或者个人并不想将源代码公开。Google为Android加入HAL主要有以下目的：

• 统一硬件的调用接口。由于HAL有标准的调用接口，所以可以利用HAL屏蔽了Linux驱动复杂、不统一的接口。
• 解决了GPL协议。从商业角度，许多硬件厂商不愿意将自己硬件相关一些核心的东西开源出去，假如将自己硬件的驱动程序全部放入内核空间驱动程序中实现，那么必须遵循GPL协议，是必需开源的。有了HAL层之后，他们可以把一些核心算法之类的实现放在HAL层，而HAL层位于用户空间，不属于linux内核，和Android源码一样遵循的是Appache协议，这个是可以开源或者不开源的。
• 针对一些特殊的要求。对于一些硬件，可能需要访问一些用户空间的资源，或在内核空间不方便完成的工作以及特殊需求。在这种情况下，可以利用位于空间的HAL代码来辅助Linux完成一些工作。

2、HAL层中有三个重要的结构体

• hw_module_t：硬件模块结构体，它主要包含了一些硬件模块的信息。
• hw_ module_methods_t：硬件模块方法结构体。
• hw_device_t：硬件设备结构体，主要是用来描述模块中硬件设备的属性信息等，一个硬件模块可能有多个硬件设备。

        顾名思义hw就是hardware。Android HAL层的代码主要位于/hardware/libhardware下面。三个结构体的定义在/hardware/libhardware/include/hardware/hardware.h里面。

3、hw_module_t结构体定义

/**
 * Every hardware module must have a data structure named HAL_MODULE_INFO_SYM
 * and the fields of this data structure must begin with hw_module_t
 * followed by module specific information.
 */
typedef struct hw_module_t {
    /** tag must be initialized to HARDWARE_MODULE_TAG */
    uint32_t tag;  //tag，根据引文注释可以看到必须被初始化为HARDWARE_MODULE_TAG

    /** major version number for the module */
    uint16_t version_major;//主版本号

    /** minor version number of the module */
    uint16_t version_minor;//次版本号

    /** Identifier of module */
    const char *id;//模块id字符串

    /** Name of this module */
    const char *name;//模块名

    /** Author/owner/implementor of the module */
    const char *author;//作者

    /** Modules methods */
    struct hw_module_methods_t* methods;//硬件模块方法结构体

    /** module's dso */
    void* dso;//打开硬件模块的库时得到的句柄

    /** padding to 128 bytes, reserved for future use */
    uint32_t reserved[32-7];

} hw_module_t;

4、hw_ module_methods_t结构体定义

typedef struct hw_module_methods_t {
    /** Open a specific device */
    int (*open)(const struct hw_module_t* module, const char* id,//打开硬件设备函数指针
            struct hw_device_t** device);

} hw_module_methods_t;

5、hw_device_t结构体定义

/**
 * Every device data structure must begin with hw_device_t
 * followed by module specific public methods and attributes.
 */
typedef struct hw_device_t {
    /** tag must be initialized to HARDWARE_DEVICE_TAG */
    uint32_t tag;   //设备tag

    /** version number for hw_device_t */
    uint32_t version;//版本

    /** reference to the module this device belongs to */
    struct hw_module_t* module;//本设备归属的硬件模块

    /** padding reserved for future use */
    uint32_t reserved[12];//保留

    /** Close this device */
    int (*close)(struct hw_device_t* device);//关闭设备的函数指针

} hw_device_t;

二、搜索硬件模块动态共享库

        一些硬件厂商不愿意将自己的一些核心代码开放出去，所以将这些代码放到HAL层，但是怎么保证它不开放呢？HAL层代码不是也让大家下载吗？其实硬件厂商的HAL核心代码是以共享库的形式出现的，每次在需要的时候，HAL会自动加载调用相关共享库。那么是怎么加载找到某一硬件设备对应的共享库的呢？
        上层App通过JNI调用HAL层的hw_get_module函数获取硬件模块，这个函数是上层与HAL打交道的入口。所以如果我们以程序调用执行的流程去看源码的话，这个函数就是HAL层第一个被调用的函数，下面我们就从这个函数开始，沿着程序执行的流程走下去。hw_get_module函数定义在/hardware/libhardware/hardware.c中，打开这个文件可以看到定义如下：

int hw_get_module(const char *id, const struct hw_module_t **module) 
{
    int status;
    int i;
    const struct hw_module_t *hmi = NULL;
    char prop[PATH_MAX];
    char path[PATH_MAX];

    /*
     * Here we rely on the fact that calling dlopen multiple times on
     * the same .so will simply increment a refcount (and not load
     * a new copy of the library).
     * We also assume that dlopen() is thread-safe.
     */

    /* Loop through the configuration variants looking for a module */
    for (i=0 ; i<HAL_VARIANT_KEYS_COUNT+1 ; i++) {
        if (i < HAL_VARIANT_KEYS_COUNT) {
            if (property_get(variant_keys[i], prop, NULL) == 0) {//获取属性
                continue;
            }
            snprintf(path, sizeof(path), "%s/%s.%s.so",
                    HAL_LIBRARY_PATH1, id, prop);
            if (access(path, R_OK) == 0) break;//检查system路径是否有库文件

            snprintf(path, sizeof(path), "%s/%s.%s.so",
                     HAL_LIBRARY_PATH2, id, prop);
            if (access(path, R_OK) == 0) break;//检查vender路径是否有库文件
        } else {
            snprintf(path, sizeof(path), "%s/%s.default.so",//如果都没有，则使用缺省的
                     HAL_LIBRARY_PATH1, id);
            if (access(path, R_OK) == 0) break;
        }
    }

    status = -ENOENT;
    if (i < HAL_VARIANT_KEYS_COUNT+1) {
        /* load the module, if this fails, we're doomed, and we should not try
         * to load a different variant. */
        status = load(id, path, module);//装载库，得到module
    }

    return status;
}

        看第1行我们知道有两个参数，第一参数id就是要获取的硬件模块的id，第二个参数module就是我们想得到的硬件模块结构体的指针。
        上层首先给HAL需要获取的硬件模块的id，hw_get_module函数根据这个id去查找匹配和这个id对应的硬件模块结构体的。
        第17行有个for循环，上限是HAL_VARIANT_KEYS_COUNT + 1，那么这个HAL_VARIANT_KEYS_COUNT是什么呢？在本文件找，有：

static const int HAL_VARIANT_KEYS_COUNT = (sizeof(variant_keys)/sizeof(variant_keys[0]));

        原来它是variant_keys这个数组的元素个数。那么这个数组又是什么呢？在本文件找，有：

/**
 * There are a set of variant filename for modules. The form of the filename
 * is "<MODULE_ID>.variant.so" so for the led module the Dream variants 
 * of base "ro.product.board", "ro.board.platform" and "ro.arch" would be:
 *
 * led.trout.so
 * led.msm7k.so
 * led.ARMV6.so
 * led.default.so
 */

static const char *variant_keys[] = {
    "ro.hardware",  /* This goes first so that it can pick up a different
                       file on the emulator. */
    "ro.product.board",
    "ro.board.platform",
    "ro.arch"
};

        可以看到它其实是个字符串数组。暂且不知道干什么的。继续看hw_get_module函数，进入for循环里面，看第22行，其实它是将HAL_LIBRARY_PATH1，id，prop这三个串拼凑一个路径出来，HAL_LIBRARY_PATH1定义如下：

/** Base path of the hal modules */
#define HAL_LIBRARY_PATH1 "/system/lib/hw"
#define HAL_LIBRARY_PATH2 "/vendor/lib/hw"

        id是上层提供的，prop这个变量的值是前面第19行property_get(variant_keys[i], prop, NULL)函数获取到的，其实这个函数是通过ariant_keys数组的属性所查找到系统中对应的变种名称。不同的平台获取到prop值是不一样的。
        假如在获取到的prop值是tout，需要获取的硬件模块的id是leds，那么最后path组成的串是/system/lib/hw/leds.tout.so。
        后面第24行access是检查这个路径下的文件是否存在，如果有就break，跳出循环。如果没有继续走下面，可以看到下面几行和刚才形式差不多：

snprintf(path, sizeof(path), "%s/%s.%s.so",  HAL_LIBRARY_PATH2, id, prop);
if (access(path, R_OK) == 0) break;//检查vender路径是否有库文件

        结合HAL_LIBRARY_PATH2为/vendor/lib/hw，假设同样获取到的prop值是tout，需要获取的硬件模块的id是leds，这种情况下path拼出来的值是/vender/lib/hw/leds.tout.so,然后在判断文件是否存在，如果存在跳出循环。
        从以上分析，其实这就是HAL层搜索动态共享库的方式，从中我们可以得到两点：

• 动态共享库一般放在/system/lib/hw和/vendor/lib/hw这两个路径下。
• 动态库的名称是以id.variant.so的形式命名的，其中id为上层提供，中间variant为变种名称，是随系统平台变化的。

        从第29行到第32行我们可以看到，当所有变种名称形式的包都不存在时，就以id.default.so形式包名查找是否存在。第37行， if (i < HAL_VARIANT_KEYS_COUNT+1)，如果i小于变种名称数组的话，表示找到了对应的库，那么第38行load(id, path, module);装载库，得到module。

三、加载硬件模块动态共享库

        下面我们进入load函数，看看具体是如何实现加载共享库的，同样在/hardware/libhardware/hardware.c中实现的。

/**
 * Load the file defined by the variant and if successful
 * return the dlopen handle and the hmi.
 * @return 0 = success, !0 = failure.
 */
static int load(const char *id,
        const char *path,
        const struct hw_module_t **pHmi)
{//传入硬件模块id和库所在路径，获取到硬件模块结构体
    int status;
    void *handle;
    struct hw_module_t *hmi;

    /*
     * load the symbols resolving undefined symbols before
     * dlopen returns. Since RTLD_GLOBAL is not or'd in with
     * RTLD_NOW the external symbols will not be global
     */
    handle = dlopen(path, RTLD_NOW);//打开共享库
    if (handle == NULL) {
        char const *err_str = dlerror();
        LOGE("load: module=%s\n%s", path, err_str?err_str:"unknown");
        status = -EINVAL;
        goto done;
    }

    /* Get the address of the struct hal_module_info. */
    const char *sym = HAL_MODULE_INFO_SYM_AS_STR;
    hmi = (struct hw_module_t *)dlsym(handle, sym);//解析共享库
    if (hmi == NULL) {
        LOGE("load: couldn't find symbol %s", sym);
        status = -EINVAL;
        goto done;
    }

    /* Check that the id matches */
    if (strcmp(id, hmi->id) != 0) {//匹配解析出硬件模块的id和传入我们实际想要得到的模块id是否一致
        LOGE("load: id=%s != hmi->id=%s", id, hmi->id);
        status = -EINVAL;
        goto done;
    }

    hmi->dso = handle;  //将打开库得到句柄传给硬件模块的dso

    /* success */
    status = 0;

    done:
    if (status != 0) {
        hmi = NULL;
        if (handle != NULL) {
            dlclose(handle);
            handle = NULL;
        }
    } else {
        LOGV("loaded HAL id=%s path=%s hmi=%p handle=%p",
                id, path, *pHmi, handle);
    }

    *pHmi = hmi;//将得到的module的结果通过第三个参数传给hw_module_t

    return status;
}

        可以看到load函数传入的几个参数：

• 第一个参数就是需要加载的硬件模块对应动态库的硬件模块的id
• 第二个参数就是动态库存放的路径，就是在hw_get_module函数前部分搜索库得到的path
• 第三个参数就是我们需要得到的硬件模块结构体，通过它传给hw_get_module，hw_get_module函数在通过参数传给jni。

        第19行，首先调用dlopen打开共享库，该函数通过传入的库的路径找到库，并且打开它，传回一个操作句柄handle，然后再调用dlsym函数解析这个打开的库，下面第29行，得到库中包含的硬件模块结构体，并将它返回回来。所以硬件厂商或者硬件移植者都必须根据HAL的这个架构去实现填充这个和自己硬件相关的硬件模块结构体hw_module_t。
        通过dlsym解析之后就得到了hw_module_t，随后第37行，将从库中解析得到的结构体中的id和传入的id做比较，看是否一致，如果一致则证明就是得到正确的硬件模块了。
        最后第60行，将hw_module_t结构体指针传给第三个参数，传给hw_get_module函数。
        到此，hw_get_module函数就得到了硬件模块结构体hw_module_t，有了hw_module_t，那么通过其内部的方法open就能打开硬件模块对应的设备了，通过结构体中的一些方法就能操作硬件设备了。