Android架构分析之硬件抽象层(HAL)

 

一、硬件抽象层核心数据结构

Android硬件抽象层有三个核心数据结构,分别是hw_module_t , hw_module_methods_t, hw_device_t。定义在hardware/libhardware/include/hardware/hardware.h文件中：

  40/**
  41 * Every hardware module must have a data structure named HAL_MODULE_INFO_SYM
  42 * and the fields of this data structure must begin with hw_module_t
  43 * followed by module specific information.
  44 */
  45typedef struct hw_module_t {
  46    /** tag must be initialized to HARDWARE_MODULE_TAG */
  47    uint32_t tag;
  48
  49    /** major version number for the module */
  50    uint16_t version_major;
  51
  52    /** minor version number of the module */
  53    uint16_t version_minor;
  54
  55    /** Identifier of module */
  56    const char *id;
  57
  58    /** Name of this module */
  59    const char *name;
  60
  61    /** Author/owner/implementor of the module */
  62    const char *author;
  63
  64    /** Modules methods */
  65    struct hw_module_methods_t* methods;
  66
  67    /** module's dso */
  68    void* dso;
  69
  70    /** padding to 128 bytes, reserved for future use */
  71    uint32_t reserved[32-7];
  72
  73} hw_module_t;
  74
  75typedef struct hw_module_methods_t {
  76    /** Open a specific device */
  77    int (*open)(const struct hw_module_t* module, const char* id,
  78            struct hw_device_t** device);
  79
  80} hw_module_methods_t;
  81
  82/**
  83 * Every device data structure must begin with hw_device_t
  84 * followed by module specific public methods and attributes.
  85 */
  86typedef struct hw_device_t {
  87    /** tag must be initialized to HARDWARE_DEVICE_TAG */
  88    uint32_t tag;
  89
  90    /** version number for hw_device_t */
  91    uint32_t version;
  92
  93    /** reference to the module this device belongs to */
  94    struct hw_module_t* module;
  95
  96    /** padding reserved for future use */
  97    uint32_t reserved[12];
  98
  99    /** Close this device */
 100    int (*close)(struct hw_device_t* device);
 101
 102} hw_device_t;

40-44行，注意这段说明文字，硬件抽象层HAL由一个一个的模块组成，Android规定，每一个模块都是一个命名为HAL_MODULE_INFO_SYM的自定义结构体，并且该结构体的第一个成员必须为hw_module_t类型的变量，其它成员变量根据需要由开发者设置。

82-85行，注意这段说明文字，每个设备对应一个自定义结构体，该结构体的第一个成员必须为hw_device_t，其它成员根据需要由开发者设置。

例如，sensor模块对应的结构体定义在hardware/libhardware/include/hardware/sensors.h文件中：

 344/**
 345 * Every hardware module must have a data structure named HAL_MODULE_INFO_SYM
 346 * and the fields of this data structure must begin with hw_module_t
 347 * followed by module specific information.
 348 */
 349struct sensors_module_t {
 350    struct hw_module_t common;
 351
 352    /**
 353     * Enumerate all available sensors. The list is returned in "list".
 354     * @return number of sensors in the list
 355     */
 356    int (*get_sensors_list)(struct sensors_module_t* module,
 357            struct sensor_t const** list);
 358};
 sensor设备对应的结构体如下：
 392/**
 393 * Every device data structure must begin with hw_device_t
 394 * followed by module specific public methods and attributes.
 395 */
 396struct sensors_poll_device_t {
 397    struct hw_device_t common;
 398
 399    /** Activate/deactivate one sensor.
 400     *
 401     * @param handle is the handle of the sensor to change.
 402     * @param enabled set to 1 to enable, or 0 to disable the sensor.
 403     *
 404     * @return 0 on success, negative errno code otherwise
 405     */
 406    int (*activate)(struct sensors_poll_device_t *dev,
 407            int handle, int enabled);
 408
 409    /**
 410     * Set the delay between sensor events in nanoseconds for a given sensor.
 411     * It is an error to set a delay inferior to the value defined by
 412     * sensor_t::minDelay. If sensor_t::minDelay is zero, setDelay() is
 413     * ignored and returns 0.
 414     *
 415     * @return 0 if successful, < 0 on error
 416     */
 417    int (*setDelay)(struct sensors_poll_device_t *dev,
 418            int handle, int64_t ns);
 419
 420    /**
 421     * Returns an array of sensor data.
 422     * This function must block until events are available.
 423     *
 424     * @return the number of events read on success, or -errno in case of an error.
 425     * This function should never return 0 (no event).
 426     *
 427     */
 428    int (*poll)(struct sensors_poll_device_t *dev,
 429            sensors_event_t* data, int count);
 430};

对于三星公司的crespo(Nexus S的开发代号)，其sensor模块的真正实现代码定义在device/samsung/crespo/libsensors/sensors.cpp文件中：

 108static struct hw_module_methods_t sensors_module_methods = {
 109        open: open_sensors
 110};
 111
 112struct sensors_module_t HAL_MODULE_INFO_SYM = {
 113        common: {
 114                tag: HARDWARE_MODULE_TAG,
 115                version_major: 1,
 116                version_minor: 0,
 117                id: SENSORS_HARDWARE_MODULE_ID,
 118                name: "Samsung Sensor module",
 119                author: "Samsung Electronic Company",
 120                methods: &sensors_module_methods,
 121        },
 122        get_sensors_list: sensors__get_sensors_list,
 123};

而在open_sensors函数中，对相应设备对应的sensors_poll_device_t结构进行了赋值：

 305/** Open a new instance of a sensor device using name */
 306static int open_sensors(const struct hw_module_t* module, const char* id,
 307                        struct hw_device_t** device)
 308{
 309        int status = -EINVAL;
 310        sensors_poll_context_t *dev = new sensors_poll_context_t();
 311
 312        memset(&dev->device, 0, sizeof(sensors_poll_device_t));
 313
 314        dev->device.common.tag = HARDWARE_DEVICE_TAG;
 315        dev->device.common.version  = 0;
 316        dev->device.common.module   = const_cast<hw_module_t*>(module);
 317        dev->device.common.close    = poll__close;
 318        dev->device.activate        = poll__activate;
 319        dev->device.setDelay        = poll__setDelay;
 320        dev->device.poll            = poll__poll;
 321
 322        *device = &dev->device.common;
 323        status = 0;
 324
 325        return status;
 326}

poll__close、poll__activate、poll__setDelay、poll__poll等函数也是在该文件中实现。

 

二、Android如何使用硬件抽象层

硬件抽象层的作用是对上层Application Framework屏蔽Linux底层驱动程序，那么Application Framework与硬件抽象层通信的接口是谁呢？答案是hw_get_module函数，该函数定义在hardware/libhardware/hardware.c文件中：

 120int hw_get_module(const char *id, const struct hw_module_t **module)
 121{
 122    int status;
 123    int i;
 124    const struct hw_module_t *hmi = NULL;
 125    char prop[PATH_MAX];
 126    char path[PATH_MAX];
 127
 128    /*
 129     * Here we rely on the fact that calling dlopen multiple times on
 130     * the same .so will simply increment a refcount (and not load
 131     * a new copy of the library).
 132     * We also assume that dlopen() is thread-safe.
 133     */
 134
 135    /* Loop through the configuration variants looking for a module */
 136    for (i=0 ; i<HAL_VARIANT_KEYS_COUNT+1 ; i++) {
 137        if (i < HAL_VARIANT_KEYS_COUNT) {
 138            if (property_get(variant_keys[i], prop, NULL) == 0) {
 139                continue;
 140            }
 141            snprintf(path, sizeof(path), "%s/%s.%s.so",
 142                    HAL_LIBRARY_PATH1, id, prop);
 143            if (access(path, R_OK) == 0) break;
 144
 145            snprintf(path, sizeof(path), "%s/%s.%s.so",
 146                     HAL_LIBRARY_PATH2, id, prop);
 147            if (access(path, R_OK) == 0) break;
 148        } else {
 149            snprintf(path, sizeof(path), "%s/%s.default.so",
 150                     HAL_LIBRARY_PATH1, id);
 151            if (access(path, R_OK) == 0) break;
 152        }
 153    }
 154
 155    status = -ENOENT;
 156    if (i < HAL_VARIANT_KEYS_COUNT+1) {
 157        /* load the module, if this fails, we're doomed, and we should not try
 158         * to load a different variant. */
 159        status = load(id, path, module);
 160    }
 161
 162    return status;
 163}

hw_get_module函数的作用是由第一个参数id指定的模块ID，找到模块对应的hw_module_t结构体，保存在第二个参数module中。

136-153行，这个for循环是为了获取模块名及路径，保存在path中。循环次数为HAL_VARIANT_KEYS_COUNT次，HAL_VARIANT_KEYS_COUNT是下面要用到的variant_keys数组的数组元素个数。

为了说明这个for循环是如何获得模块名及其路径，我们要先来看一下variant_keys数组的定义，这个数组也是定义在hardware/libhardware/hardware.c文件中：

 34/**
 35 * There are a set of variant filename for modules. The form of the filename
 36 * is "<MODULE_ID>.variant.so" so for the led module the Dream variants
 37 * of base "ro.product.board", "ro.board.platform" and "ro.arch" would be:
 38 *
 39 * led.trout.so
 40 * led.msm7k.so
 41 * led.ARMV6.so
 42 * led.default.so
 43 */
 44
 45static const char *variant_keys[] = {
 46    "ro.hardware",  /* This goes first so that it can pick up a different
 47                       file on the emulator. */
 48    "ro.product.board",
 49    "ro.board.platform",
 50    "ro.arch"
 51};
 52
 53static const int HAL_VARIANT_KEYS_COUNT =
 54    (sizeof(variant_keys)/sizeof(variant_keys[0]));

34-43行，这段注释说明了模块对应的动态库的命名规范。模块对应的动态库文件名格式为<MODULE_ID>.variant.so，MODULE_ID是模块对应的ID，不同模块对应一个唯一固定的ID，那么variant是什么呢？又怎么获得variant呢？这就跟下面的variant_keys数组有关了。

45-51行，定义了variant_keys数组，这个数组有4个成员，即指向“ro.hardware”、“ ro.product.board”、“ ro.board.platform”、“ ro.arch”四个字符串的指针。我们可以将“ro.hardware”、“ ro.product.board”、“ ro.board.platform”、“ ro.arch”理解为属性，系统会通过适当的方法，根据平台、架构等给这些属性赋值。

例如，“ro.hardware”属性的属性值是在系统启动时由init进程负责设置的。它首先会读取/proc/cmdline文件，检查里面有没有一个名为androidboot.hardware的属性，如果有，就把它的值赋值给“ro.hardware”，否则，就将/proc/cpuinfo文件的内容读取出来，并解析出Haredware字段的内容赋值给“ro.hardware”。例如在Android模拟器中，从/proc/cpuinfo文件中读取出来的Hardware字段内容为goldfish，于是，init进程就会将 “ro.hardware” 属性设置为goldfish。

“ ro.product.board”、“ ro.board.platform”、“ ro.arch”属性是从/system/build.prop文件读取出来的。/system/build.prop文件是由编译系统中的编译脚本build/core/Makefile和shell脚本build/tools/buildinfo.sh生成的，这里不再详细分析。

53-54行，定义了HAL_VARIANT_KEYS_COUNT变量，它是variant_keys数组的大小。

从上面我们已经知道了variant_keys数组的内容，也知道了模块对应的动态库的命名规范。现在我们的问题是模块动态库命名规范格式<MODULE_ID>.variant.so中的variant是怎样获得的？又跟variant_keys数组有什么关系？为了回答这个问题，我们再回到hw_get_module函数的定义。

hw_get_module函数第138行，调用property_get(variant_keys[i], prop, NULL)函数，其作用是取得variant_keys[i]对应的属性值，保存在prop中。也就是说，在第1次循环时，是取得variant_keys[0]即“ro.hardware”对应的属性值，保存在prop中，如果没有取得到，property_get函数会返回0，则进入下一次循环，依次尝试取得“ ro.product.board”、“ ro.board.platform”、“ ro.arch”对应的属性值，保存在prop中。如果取得了某个variant_keys[i]对应的属性值，则在hw_get_module函数第141-142行，按<MODULE_ID>.variant.so规范，得到模块动态库的名字及路径，其中variant就是我们前面得到的prop的值。

hw_get_module函数第148-153行，如果没有找到variant_keys[i]对应的属性，则使用<MODULE_ID>.default.so。

hw_get_module函数第156-160行，调用load(id, path, module)导入模块动态库，将模块对应的hw_module_t结构体，保存在module变量中。load函数也定义在hardware/libhardware/hardware.c文件中：

  56/**
  57 * Load the file defined by the variant and if successful
  58 * return the dlopen handle and the hmi.
  59 * @return 0 = success, !0 = failure.
  60 */
  61static int load(const char *id,
  62        const char *path,
  63        const struct hw_module_t **pHmi)
  64{
  65    int status;
  66    void *handle;
  67    struct hw_module_t *hmi;
  68
  69    /*
  70     * load the symbols resolving undefined symbols before
  71     * dlopen returns. Since RTLD_GLOBAL is not or'd in with
  72     * RTLD_NOW the external symbols will not be global
  73     */
  74    handle = dlopen(path, RTLD_NOW);
  75    if (handle == NULL) {
  76        char const *err_str = dlerror();
  77        LOGE("load: module=%s\n%s", path, err_str?err_str:"unknown");
  78        status = -EINVAL;
  79        goto done;
  80    }
  81
  82    /* Get the address of the struct hal_module_info. */
  83    const char *sym = HAL_MODULE_INFO_SYM_AS_STR;
  84    hmi = (struct hw_module_t *)dlsym(handle, sym);
  85    if (hmi == NULL) {
  86        LOGE("load: couldn't find symbol %s", sym);
  87        status = -EINVAL;
  88        goto done;
  89    }
  90
  91    /* Check that the id matches */
  92    if (strcmp(id, hmi->id) != 0) {
  93        LOGE("load: id=%s != hmi->id=%s", id, hmi->id);
  94        status = -EINVAL;
  95        goto done;
  96    }
  97
  98    hmi->dso = handle;
  99
 100    /* success */
 101    status = 0;
 102
 103    done:
 104    if (status != 0) {
 105        hmi = NULL;
 106        if (handle != NULL) {
 107            dlclose(handle);
 108            handle = NULL;
 109        }
 110    } else {
 111        LOGV("loaded HAL id=%s path=%s hmi=%p handle=%p",
 112                id, path, *pHmi, handle);
 113    }
 114
 115    *pHmi = hmi;
 116
 117    return status;
 118}

第74行，调用dlopen(path, RTLD_NOW)导入path指定的模块动态库。

第83-84行，通过dlsym函数取得HAL_MODULE_INFO_SYM_AS_STR指定的变量的地址，这个地址就是模块对应的自定义结构体地址。

第115行，将hw_module_t结构赋值给传递进来的参数pHmi，即返回给上层调用函数。

分析到这里，我们可以看出，通过hw_get_module函数，Application Framework代码可以通过指定的模块ID找到模块hw_module_t结构体。有了hw_module_t结构体，就可以调用hw_module_t-> methods->open函数，在open函数中，完成对设备对应的hw_device_t结构体的初始化，并指定设备相关的自定义函数。