作者：朱克锋
转载请注明出处：
http://blog.csdn.net/linux_zkf/article/details/7492391
Android系统硬件抽象层（HAL）原理
在android开发过程中，我们经常看到HAL这个概念，这就android的硬件抽象层的（Hardwaere Abstraction Layer）缩写,它是Goolge应某些厂商不希望公开源码所添加的一个适配层，能以封闭源码的方式提供硬件驱动模块，目的就是把android framework层和linux kernel层隔离开来，使android系统不至于过度的依赖linux kernel层的实现，也就是说android framework可以不考虑linux kernel如何实现的情况下独立开发
Android HAL层位于android系统和linuxkernel之间，如下图所示：
|
Android java应用层（app） |
|
Android java框架层（framework）
|
|
Android本地框架层（native）
|
硬件抽象层（HAL） |
|
硬件抽象层实现
|
驱动层（linuxkernel） |
在移植系统或添加新的模块时都需要android的HAL层进行修改或者添加实现，android的HAL层在android的源码位置：
hardware/libhardware/
hardware/libhardware_legacy/
hardware/xxxx/
有的还位与其他位置。AndroidHAL层的实现方式有几种方式：
1，hardware模块的方式
2，C/C++继承方式
3，直接调用驱动接口方式
4，直接接口方式
下面我从这几种方式作一下简单的分析
《一》首先分析一下hardware模块方式的实现，这种方式是一种不依赖编译时绑定的实现，它可以动态的加载硬件抽象层就是说可以通过ID来动态的打开（dlopen）一个硬件模块，然后找到符号（dlsym）进行调用。
Android native framework-(根据不同的ID)àlibhardware.so-(dlopen)->/system/hw/*.so->drivers
接下来分析一下HAL这个抽象的框架，具体的代码在源码的
hardware/libhardware/hardware.c
hardware/libhardware/include/hardware/hardware.h位置
来看看hardware.h这个头文件，我们可以发现在这个头文件中主要定义的三个结构体
struct hw_device_t
struct hw_module_t
struct hw_module_methods_t
hw_device_t：表示硬件设备，存储了各种硬件设备的公共属性和方法，如果需要移植或者添加新硬件，那么都需要使用该结构进行注册，其中的tag必须初始化。结构体hw_module_t在进行加载的时候用于判断属于哪个module。
typedef struct hw_device_t {
uint32_t tag; //tag需要被初始化为HARDWARE_DEV
uint32_t version; //hw_device_t的版本号
struct hw_module_t* module; //引用这个设备属于的硬件模块
uint32_t reserved[12]; //填充保留字节
int (*close)(struct hw_device_t* device); //关闭设备
} hw_device_t;
typedef struct hw_module_t {
uint32_t tag; //tag需要被初始化为HARDWARE_MODULE_TAG
uint16_t version_major; //主版本号
uint16_t version_minor; //次版本号
const char *id; //模块标识符
const char *name; //模块名称
const char *author; //模块作者
struct hw_module_methods_t* methods; //模块方法
void* dso; //模块的dso
uint32_t reserved[32-7]; //填充字节，为以后使用
} hw_module_t;
hw_module_methods_t：该结构体用于定义操作设备的各种方法operations，这里只定义一个open方法。如果要执行打开设备等操作可以在JNI层使用“module->methods->open(module,LED_HARDWARE_MODULE_ID,(struct hw_device_t** )device);”
typedef struct hw_module_methods_t {
int (*open)(const struct hw_module_t* module, const char* id,struct hw_device_t** device); //打开设备的方法
} hw_module_methods_t;
其中struct hw_device_t表示一个硬件设备
Struct hw_module_t表示硬件模块的格式
Sttruct hw_module_methods_t表示模块的方法
（三个结构体可以看到hw_device_t包含hw_module_t, hw_module_t保含hw_module_methods_t,这是面向对象的思想的体现，呵呵呵）
在加载某个模块的时候会调用hw_get_module这个方法，这个方法就可以获得相应的HAL，代码如下所示：
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) {
//获取ro.hardware/ro.product.board/ro.board.platform/ro.arch等key的值。
if (property_get(variant_keys[i], prop, NULL) == 0) {
continue;
}
snprintf(path, sizeof(path), "%s/%s.%s.so",
HAL_LIBRARY_PATH, id, prop);
} else { //如果没有动态加载的动态链接库，需要加载默认的模块
snprintf(path, sizeof(path), "%s/%s.default.so",
HAL_LIBRARY_PATH, id);
}
if (access(path, R_OK)) {
continue;
}
/* we found a library matching this id/variant */
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);//调用load（）函数打开动态链接库
}
return status;
}
在该方法中可以看出，android系统通过系统的属性查找硬件，根据ID和找到的路径加载相应的.so库文件在hw_get_module中有一个重要的方法
Load
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););//查找“HMI”这个导出符号，并获取其地址
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;
}
从上可以简单得出硬件的具体调用过程，大致是这样的
首先通过ID找到硬件模块
然后硬件模块得到methods打开设备（hw_device_t）
再后调用设备的各个方法
最后使用完毕后通过设备的close方法关闭
《二》C/C++继承方式
这种方式最典型的有CAMERA和AUDIO两个系统，这种方式是在android系统中定义了C++接口如camera中的CameraHardwareInterface.h,其中定义了操作camera的各个方法，这些方法有具体的实现者来实现，一般情况下硬件抽象层会被编译成动态或静态库，由本地框架调用或链接，具体在camera中分析
后两种方式在分析具体模块时再做具体分析
HAL层的原理就简单介绍到这里，接下来我会详细分析不同的具体的模块的实现