android系统硬件抽象层（HAL）原理及实现之原理

作者：朱克锋
转载请注明出处：
/article/7841105.html

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层的原理就简单介绍到这里，接下来我会详细分析不同的具体的模块的实现