HAL（Hardware Abstract Layer）硬件抽象层工作原理

HAL的存在意义

硬件抽象层是介于android内核kernel和上层之间的抽象出来的一层结构。他是对linux驱动的一个封装，对上层提供统一接口，上层应用不必知道下层硬件具体怎么实现工作的，它屏蔽了底层的实现细节。

它在整个android架构中的位置如下图所示：

传统的linux对硬件的操作基本上在内核空间的linux驱动程序中实现了，那么现在为什么要多此一举把对硬件的操作分为HAL和linux驱动两部分呢？而且HAL是属于用户空间，linux驱动属于内核空间。
其实并不多余，理由是很多的：
1.谷歌搭好了HAL的框架，为上层framework通过JNI调用HAL提供了统一的API，硬件开发商或者移植人员只需要按照框架开发即可，无需话费精力在与上层的交互上的实现上，将精力放在hal层本身的实现上即可。
2.从商业角度，许多硬件厂商不愿意将自己硬件相关一些核心的东西开源出去，假如将对自己硬件的驱动程序全部放入内核空间驱动程序实现，那么必须遵循GPL协议，是必需开源的。有了HAL层之后，他们可以把一些核心的算法之类的东西的实现放在HAL层，而HAL层位于用户空间，不属于linux内核，和android源码一样遵循的是Apache协议，这个是可以不用开源的。

以上就是HAL层存在的意义，下面来根据HAL层源码分析一下HAL到底是怎么样个架构和实现原理，深入剖析一下。

HAL重要数据结构

android HAL层的代码主要位于/hardware/libhardware下面我们从上往下走。

在HAL层中，各类硬件的都是以硬件模块的形式描述的，是用hw_module_t结构体来描述的，而每一类硬件模块中又有各个独立的硬件，是用hw_device_t结构体来描述的。

上层app通过JNI调用硬件时，首先得获取到hw_module_t结构体，也即是硬件模块，有了这个才能再对硬件进行操作。那么我们来看看看看这两个结构体定义是什么样子的。

它们的定义在/hardware/libhardware/include/hardware/hardware.h里面。

A. 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;

    /**
     * The API version of the implemented module. The module owner is
     * responsible for updating the version when a module interface has
     * changed.
     *
     * The derived modules such as gralloc and audio own and manage this field.
     * The module user must interpret the version field to decide whether or
     * not to inter-operate with the supplied module implementation.
     * For example, SurfaceFlinger is responsible for making sure that
     * it knows how to manage different versions of the gralloc-module API,
     * and AudioFlinger must know how to do the same for audio-module API.
     *
     * The module API version should include a major and a minor component.
     * For example, version 1.0 could be represented as 0x0100. This format
     * implies that versions 0x0100-0x01ff are all API-compatible.
     *
     * In the future, libhardware will expose a hw_get_module_version()
     * (or equivalent) function that will take minimum/maximum supported
     * versions as arguments and would be able to reject modules with
     * versions outside of the supplied range.
     */
    uint16_t module_api_version;
#define version_major module_api_version
    /**
     * version_major/version_minor defines are supplied here for temporary
     * source code compatibility. They will be removed in the next version.
     * ALL clients must convert to the new version format.
     */

    /**
     * The API version of the HAL module interface. This is meant to
     * version the hw_module_t, hw_module_methods_t, and hw_device_t
     * structures and definitions.
     *
     * The HAL interface owns this field. Module users/implementations
     * must NOT rely on this value for version information.
     *
     * Presently, 0 is the only valid value.
     */
    uint16_t hal_api_version;
#define version_minor hal_api_version

    /** Identifier of module */
    const char *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;//打开硬件模块的库时得到的句柄

#ifdef __LP64__
    uint64_t reserved[32-7];
#else
    /** padding to 128 bytes, reserved for future use */
    uint32_t reserved[32-7];
#endif

} hw_module_t;

B. 下面我们再来看看hw_device_t结构体,这个结构体主要是用来描述模块中硬件设备的属性信息什么的。一个硬件模块可能有多个硬件设备。比如说，传感器模块，sensor_module,是一个硬件模块，但是手机中的传感器就对应的有好多种，比如加速度acc_sensor,磁传感器M_sensor等，那么他们都属于sensor_module,但是他们有都有自己的hw_device_t结构体来描述。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;

    /**
     * Version of the module-specific device API. This value is used by
     * the derived-module user to manage different device implementations.
     *
     * The module user is responsible for checking the module_api_version
     * and device version fields to ensure that the user is capable of
     * communicating with the specific module implementation.
     *
     * One module can support multiple devices with different versions. This
     * can be useful when a device interface changes in an incompatible way
     * but it is still necessary to support older implementations at the same
     * time. One such example is the Camera 2.0 API.
     *
     * This field is interpreted by the module user and is ignored by the
     * HAL interface itself.
     */
    uint32_t version;

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

    /** padding reserved for future use */
#ifdef __LP64__
    uint64_t reserved[12];
#else
    uint32_t reserved[12];
#endif

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

} hw_device_t;

其中，第三个成员module指向的是这个设备归属的硬件模块结构体。
最后一个函数指针close指向的肯定是关闭设备的函数。

到此，HAL的主要的两个结构体讲完了，下面我们继续，将结合源码，看看hal层到底是怎么工作的，看看上层怎么获取到硬件模块，硬件设备的，到底是怎么加载解析动态共享库的。

HAL实现原理

我们知道，一些硬件厂商不愿意将自己的一些核心代码开放出去，所以将这些代码放到HAL层，但是怎么保证它不开放呢？HAL层代码不是也让大家知道下载吗？其实硬件厂商的HAL核心代码是以共享库的形式出现的，每次在需要的时候，HAL会自动加载调用相关共享库。那么是怎么加载找到某一硬件设备对应的共享库的呢？这也是我们都要说的。

上层APP通过JNI调用HAL层的hw_get_module函数获取硬件模块，这个函数是上层与HAL打交道的入口。所以如果我们以程序调用执行的流程去看源码的话，这个函数就是HAL层第一个被调用的函数，下面我们就
沿着程序执行的流程走下去。比如说在frameworks\native\services\sensorservice\SensorDevice.cpp中

SensorDevice::SensorDevice()
    :  mSensorDevice(0),
       mSensorModule(0)
{
    status_t err = hw_get_module(SENSORS_HARDWARE_MODULE_ID,
            (hw_module_t const**)&mSensorModule);

    ALOGE_IF(err, "couldn't load %s module (%s)",
            SENSORS_HARDWARE_MODULE_ID, strerror(-err));

    if (mSensorModule) {
        err = sensors_open_1(&mSensorModule->common, &mSensorDevice);

        ALOGE_IF(err, "couldn't open device for module %s (%s)",
                SENSORS_HARDWARE_MODULE_ID, strerror(-err));

        if (mSensorDevice) {
            if (mSensorDevice->common.version == SENSORS_DEVICE_API_VERSION_1_1 ||
                mSensorDevice->common.version == SENSORS_DEVICE_API_VERSION_1_2) {
                ALOGE(">>>> WARNING <<< Upgrade sensor HAL to version 1_3");
            }

            sensor_t const* list;
            ssize_t count = mSensorModule->get_sensors_list(mSensorModule, &list);
            mActivationCount.setCapacity(count);
            Info model;
            for (size_t i=0 ; iactivate(
                        reinterpret_cast(mSensorDevice),
                        list[i].handle, 0);
            }
        }
    }
}

这里调用hw_get_module()得到硬件模块结构体hw_module_t.有了hw_module_t,通过其内部的method open就能打开硬件模块对应的设备了，通过结构体中的一些方法就能操作硬件设备了。
接下来我们看hw_get_module函数具体是怎么实现的，
hw_get_module函数定义在hardware\libhardware\hardware.c中，打开这个文件可以看到定义如下：

int hw_get_module(const char *id, const struct hw_module_t **module)
{
    return hw_get_module_by_class(id, NULL, module);
}

这是其函数原型，传入的参数id对应硬件设备的id，这是一个字符串，比如我们比较熟悉的sensor的id是SENSORS_HARDWARE_MODULE_ID，这个跟HAL_MODULE_INFO_SYM结构体中id的定义一样，这个将在下面讲到。hw_get_module函数根据这个id去查找匹配和这个id对应的硬件模块结构体的。如果找到了对应的hw_module_t结构体，会将其指针放入*module中。
然后我们进入hw_get_module_by_class（）看看它具体实现：

int hw_get_module_by_class(const char *class_id, const char *inst,
                           const struct hw_module_t **module)
{
    int i = 0;
    char prop[PATH_MAX] = {0};
    char path[PATH_MAX] = {0};
    char name[PATH_MAX] = {0};
    char prop_name[PATH_MAX] = {0};


    if (inst)
        snprintf(name, PATH_MAX, "%s.%s", class_id, inst);
    else
        strlcpy(name, class_id, PATH_MAX);//拷贝hardware id，name为sensor

    /*
     * 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.
     */

    /* First try a property specific to the class and possibly instance */
    snprintf(prop_name, sizeof(prop_name), "ro.hardware.%s", name);//先尝试获取ro.hardware.sensor的属性值
    if (property_get(prop_name, prop, NULL) > 0) {
        if (hw_module_exists(path, sizeof(path), name, prop) == 0) {//查看是否存在对应的库
            goto found;
        }
    }

    /* Loop through the configuration variants looking for a module */
    for (i=0 ; i

prop这个变量的值是前面property_get(variant_keys[i], prop, NULL)函数获取到的，其实这个函数是通过ariant_keys数组的属性查找到系统中对应的变种名称。不同的平台获取到prop值是不一样的。然后将参数传入hw_module_exists（）函数进行判断该库是否存在。
hw_module_exists如下：

/*
 * Check if a HAL with given name and subname exists, if so return 0, otherwise
 * otherwise return negative.  On success path will contain the path to the HAL.
 */
static int hw_module_exists(char *path, size_t path_len, const char *name,
                            const char *subname)
{
    snprintf(path, path_len, "%s/%s.%s.so",//查找动态链接库的两个路径   vendor/lib/hw/   system/lib/hw
             HAL_LIBRARY_PATH2, name, subname);
    if (access(path, R_OK) == 0)
        return 0;

    snprintf(path, path_len, "%s/%s.%s.so",
             HAL_LIBRARY_PATH1, name, subname);
    if (access(path, R_OK) == 0)
        return 0;

    return -ENOENT;
}

该函数先拼凑出path，结合 HAL_LIBRARY_PATH2 为"/vendor/lib/hw"，假设获取到的prop值是tout，需要获取的硬件模块的id是leds，这种情况下path拼出来的值是/vender/lib/hw/leds.tout.so,然后在判断文件是否存在。存在返回0.
variant_keys定义如下：

/**
 * There are a set of variant filename for modules. The form of the filename
 * is ".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"
};

上述代码主要是搜索库并获取动态链接库的路径，然后调用load函数去加载指定路径下的库文件，load函数是关键所在。下面我们看看load（）：

/**
 * 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 = -EINVAL;
    void *handle = NULL;
    struct hw_module_t *hmi = NULL;

    /*
     * 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();
        ALOGE("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就是模块结构的符号标志
    hmi = (struct hw_module_t *)dlsym(handle, sym);//根据符号返回符号对应的地址
    if (hmi == NULL) {
        ALOGE("load: couldn't find symbol %s", sym);
        status = -EINVAL;
        goto done;
    }

    /* Check that the id matches */
    if (strcmp(id, hmi->id) != 0) {//匹配解析出硬件模块的id和传入我们实际想要得到的模块id是否一致。
        ALOGE("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 {
        ALOGV("loaded HAL id=%s path=%s hmi=%p handle=%p",
                id, path, *pHmi, handle);
    }

    *pHmi = hmi;//返回找到的模块结构，赋值给module

    return status;
}

可以看到load函数传入的几个参数，第一个参数就是需要加载的硬件模块对应动态库的硬件模块的id，

第二个参数就是动态库存放的路径，就是在hw_get_module函数前部分搜索库得到的path，

第三个参数就是我们需要得到的硬件模块结构体，通过它传给hw_get_module，hw_get_module函数在通过参数传给jni。

首先调用dlopen打开共享库，该函数通过传入的库的路径找到库，并且打开它，传回一个操作句柄handle，然后再调用dlsym函数解析这个打开的库，得到库中包含的对应的硬件模块结构体，并将它返回回来。所有硬件厂商或者硬件移植者都必须根据HAL的这个架构去实现填充这个和自己硬件相关的硬件模块结构体hw_module_t，供使用。

通过dlsym解析之后就得到了hw_module_t，将从库中解析得到的结构体中的id和传入的id做比较，看是否一致。如果一致则证明就是得到正确的硬件模块了。

最后将hw_module_t结构体指针传给第三个参数，传给hw_get_module函数。

提醒一下，HAL_MODULE_INFO_SYM_AS_STR这个宏很重要：

/**
 * Name of the hal_module_info as a string
 */
#define HAL_MODULE_INFO_SYM_AS_STR  "HMI"

硬件抽象层中的每一个模块都必须存在一个导出符号HAL_MODULE_IFNO_SYM，即“HMI”，它指向一个自定义的硬件抽象层模块结构体。以sensor为例，在\hardware\libhardware\modules\sensors\multihal.cpp下

struct sensors_module_t HAL_MODULE_INFO_SYM = {
    common :{
        tag : HARDWARE_MODULE_TAG,
        version_major : 1,
        version_minor : 1,
        id : SENSORS_HARDWARE_MODULE_ID,
        name : "MultiHal Sensor Module",
        author : "Google, Inc",
        methods : &sensors_module_methods,
        dso : NULL,
        reserved : {0},
    },
    get_sensors_list : module__get_sensors_list
};

这里定义了一个名为HAL_MODULE_INFO_SYM的sensors_module_t的结构体，事实上每个硬件模块都必须定义一个变量名为HAL_MODULE_INFO_SYM的结构体，而且common成员为hw_module_t类型（这段话在定义hw_module_t结构体时有说明）。注意这里的HAL_MODULE_INFO_SYM变量必须为这个名字，这样编译器才会将这个结构体的导出符号变为“HMI”，dlsym函数才能找到这个结构体，才能根据符号返回符号对应的模块地址。

模块方法的实现

另外在hw_module_t结构体中定义了struct hw_module_methods_t* methods; hw_module_methods_t
这个指针methods它指向的是与本硬件模块相关的方法的结构体，里面不用看可以猜出肯定有一些函数指针，但是它里面只有一个函数指针。可以看看定义：

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;

我们可以看到确实只有一个函数指针，open它是打开硬件模块中硬件设备的函数。
以sensors为例，在hardware\libhardware\modules\sensors\multihal.cpp中有关于sensors打开设备的方法定义代码如下

static struct hw_module_methods_t sensors_module_methods = {
    open : open_sensors
};

我们进入open_sensors，看看其具体实现：

static int open_sensors(const struct hw_module_t* hw_module, const char* name,
        struct hw_device_t** hw_device_out) {
    ALOGV("open_sensors begin...");

    lazy_init_modules();

    // Create proxy device, to return later.
    sensors_poll_context_t *dev = new sensors_poll_context_t();
    memset(dev, 0, sizeof(sensors_poll_device_1_t));
    dev->proxy_device.common.tag = HARDWARE_DEVICE_TAG;
    dev->proxy_device.common.version = SENSORS_DEVICE_API_VERSION_1_3;
    dev->proxy_device.common.module = const_cast(hw_module);
    dev->proxy_device.common.close = device__close;
    dev->proxy_device.activate = device__activate;
    dev->proxy_device.setDelay = device__setDelay;
    dev->proxy_device.poll = device__poll;
    dev->proxy_device.batch = device__batch;
    dev->proxy_device.flush = device__flush;

    dev->nextReadIndex = 0;

    // Open() the subhal modules. Remember their devices in a vector parallel to sub_hw_modules.
    for (std::vector::iterator it = sub_hw_modules->begin();
            it != sub_hw_modules->end(); it++) {
        sensors_module_t *sensors_module = (sensors_module_t*) *it;
        struct hw_device_t* sub_hw_device;
        int sub_open_result = sensors_module->common.methods->open(*it, name, &sub_hw_device);
        if (!sub_open_result) {
            if (!HAL_VERSION_IS_COMPLIANT(sub_hw_device->version)) {
                ALOGE("SENSORS_DEVICE_API_VERSION_1_3 is required for all sensor HALs");
                ALOGE("This HAL reports non-compliant API level : %s",
                        apiNumToStr(sub_hw_device->version));
                ALOGE("Sensors belonging to this HAL will get ignored !");
            }
            dev->addSubHwDevice(sub_hw_device);
        }
    }

    // Prepare the output param and return
    *hw_device_out = &dev->proxy_device.common;
    ALOGV("...open_sensors end");
    return 0;
}

可以看到里面对设备的一些赋值

以上是我这两天学习硬件抽象层知识的一些总结。