Android HAL：分析与总结

上接Android HAL：helloworld例程继续深入点学习。

Android HAL:helloworld展示了编写HAL的一个架构。因为HAL最终会被编译层一个.so库文件被Native层调用，那么Native是如何找到这个.so，并打开这个.so呢？

其实Native是通过调用hardware/libhardware/hardware.c中的已实现函数完成查找so和打开so的。

hardware.c

/* * Copyright (C) 2008 The Android Open Source Project * * Licensed under the Apache License, Version 2.0 (the "License"); * you may not use this file except in compliance with the License. * You may obtain a copy of the License at * *      http://www.apache.org/licenses/LICENSE-2.0 * * Unless required by applicable law or agreed to in writing, software * distributed under the License is distributed on an "AS IS" BASIS, * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. * See the License for the specific language governing permissions and * limitations under the License. */#include <hardware/hardware.h>#include <cutils/properties.h>#include <dlfcn.h>#include <string.h>#include <pthread.h>#include <errno.h>#include <limits.h>#define LOG_TAG "HAL"#include <utils/Log.h>/** Base path of the hal modules */#define HAL_LIBRARY_PATH1 "/system/lib/hw"#define HAL_LIBRARY_PATH2 "/vendor/lib/hw"/** * 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",#ifdef OMAP_ENHANCEMENT    "ro.product.processor",#endif    "ro.board.platform",    "ro.arch"};static const int HAL_VARIANT_KEYS_COUNT =    (sizeof(variant_keys)/sizeof(variant_keys[0]));/** * 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){    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) {        LOGE("load: id=%s != hmi->id=%s", id, hmi->id);        status = -EINVAL;        goto done;    }    hmi->dso = handle;    /* 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;    return status;}int hw_get_module_by_class(const char *class_id, const char *inst,                           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];    char name[PATH_MAX];    if (inst)        snprintf(name, PATH_MAX, "%s.%s", class_id, inst);    else        strlcpy(name, class_id, 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_PATH2, name, prop);            if (access(path, R_OK) == 0) break;            snprintf(path, sizeof(path), "%s/%s.%s.so",                     HAL_LIBRARY_PATH1, name, prop);            if (access(path, R_OK) == 0) break;        } else {            snprintf(path, sizeof(path), "%s/%s.default.so",                     HAL_LIBRARY_PATH1, name);            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(class_id, path, module);    }    return status;}int hw_get_module(const char *id, const struct hw_module_t **module){    return hw_get_module_by_class(id, NULL, module);}

Native通过调用hw_get_module函数打开.so，然后并得到返回的扩展的hw_module_t结构体。这里的调用过程是：

hw_get_module()->hw_get_mudule_by_class()->load()

注意load()函数中有一个dlopen()调用，这就是传统的加载打开动态库的函数啊！！！

Native层加载HAL .so的例程：

这里还是以Android HAL：helloworld例程为例

定义模块结构体(hw_module_t)，执行hw_get_module函数：

hw_module_t * module;hw_get_module(HELLO_HARDWARE_MODULE_ID,&module);

通过以上程序片段得到hw_module_t *module，注意helloworld模块module扩展结构体为

struct hello_module_t {struct hw_module_t common;};

struct hello_module_t HAL_MODULE_INFO_SYM = {common: {tag: HARDWARE_MODULE_TAG,version_major: 1,version_minor: 0,id: HELLO_HARDWARE_MODULE_ID,name: MODULE_NAME,author: MODULE_AUTHOR,methods: &hello_module_methods,}};

所以通过hw_get_module得到的模块module指向的地址就是hello_module_t的地址（这也是为什么编写HAL时google要强制模块扩展结构体的第一个成员要是hw_module_t的原巧妙之处，见hardware.h说明）。

定义设备结构体(hw_device_t),调用模块方法(hw_module_methods_t)

struct hw_device_t *device;module->methods(module,"hello",&device);

methods函数实际上就是hello_device_open函数，通过以上程序片段得到hw_device_t *device，注意helloworld设备device扩展结构体为

struct hello_device_t {struct hw_device_t common;int fd;int (*set_val)(struct hello_device_t* dev, int val);int (*get_val)(struct hello_device_t* dev, int* val);};

所以通过调用模块方法得到设备device指向的地址就是hello_device_t的地址（这也是为什么编写HAL时google要强制设备扩展结构体的第一个成员要是hw_device_t的原巧妙之处，见hardware.h说明）

得到hello_device_t结构体后，就可以调用hello_device_t里面实现方法，再看回hello_device_t的定义：

struct hello_device_t {struct hw_device_t common;int fd;int (*set_val)(struct hello_device_t* dev, int val);int (*get_val)(struct hello_device_t* dev, int* val);};

这里实现了set_val和get_val。

所以总结有以下的一点认识结论：

1.HAL与Linux内核driver交互，HAL层充当传统Linux的App角色，通过系统调用访问驱动，并形成一个供上层(Native)调用的接口。

2.HAL里面的扩展设备结构体xxx_hw_device_t里面定义的方法就是供上层调用的接口，是上层的数据通道。

3.HAL里面的模块结构体hw_module_t需实现open函数。

4.Native层费了很大劲通过hw_get_module、module->hw_module_t->methods等等调用目的是想获扩展设备结构体xxx_hw_device_t中实现的接口方法。

总结：

一个HAL基本实现概括为如下：

1.定义一个扩展的hw_module_t模块接口xxx_hw_module_t（helloworld例程定义为：hello_module_t）。

2.定义一个扩展的hw_device_t设备接口xxx_hw_device_t（helloworld例程定义为：hello_device_t）。

3.Native通过hw_get_module获得xxx_hw_module_t。

4.Native再通过xxx_hw_module_t里面的hw_module_t的methods方法（即open方法）获得xxx_hw_device_t。

5.Native获得xxx_hw_device_t后，即可调用xxx_hw_device_t里面实现的方法。