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 ; i<size_t(count) ; i++) {
mActivationCount.add(list[i].handle, model);
mSensorDevice->activate(
reinterpret_cast<struct sensors_poll_device_t *>(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<HAL_VARIANT_KEYS_COUNT; i++) {
if (property_get(variant_keys[i], prop, NULL) == 0) {//获取数组variant_keys里面的属性值
continue;
}
if (hw_module_exists(path, sizeof(path), name, prop) == 0) {
goto found;
}
}
/* Nothing found, try the default */ //当所有变种名称形式的包都不存在时，就以"id.default.so"形式包名查找是否存在
if (hw_module_exists(path, sizeof(path), name, "default") == 0) {
goto found;
}
return -ENOENT;
found:
/* load the module, if this fails, we're doomed, and we should not try
* to load a different variant. */
return load(class_id, path, module);//装载库，得到module
}
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 "<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"
};
上述代码主要是搜索库并获取动态链接库的路径，然后调用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_t*>(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<hw_module_t*>::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;
}
可以看到里面对设备的一些赋值
以上是我这两天学习硬件抽象层知识的一些总结。