您的位置：首页 > 移动开发 > Android开发

Android HAL(硬件抽象层)介绍以及调用

2015-06-09 13:36 615 查看

1 HAL简介

Android 的 HAL（Hardware Abstract Layer硬件抽象层）是Google因应厂商「希望不公开源码」的要求下，所推出的新观念，其架构如下图。虽然 HAL 现在的「抽象程度」还不足，现阶段实作还不是全面符合 HAL的架构规划，不过也确实给了我们很好的思考空间。

图1：Android HAL 架构规划

这是 Patrick Brady (Google) 在2008 Google I/O 所发表的演讲「Anatomy & Physiology of an Android」中，所提出的 Android HAL 架构图。从这张架构图我们知道，HAL 的目的是为了把 Android framework 与 Linux kernel 完整「隔开」。让 Android 不至过度依赖 Linux kernel，有点像是「kernel independent」的意思，让 Android framework 的开发能在不考虑驱动程序的前提下进行发展。
在 Android 原始码里，HAL 主要的实作储存于以下目录：

1. libhardware_legacy/ - 过去的实作、采取链接库模块的观念进行

2. libhardware/ - 新版的实作、调整为 HAL stub 的观念

3. ril/ - Radio Interface Layer
在 HAL 的架构实作成熟前（即图1的规划），我们先就目前 HAL 现况做一个简单的分析。另外，目前 Android 的 HAL实作，仍旧散布在不同的地方，例如 Camera、WiFi 等，因此上述的目录并不包含所有的 HAL 程序代码。

2 HAL 的过去

图2：Android HAL / libhardware_legacy

过去的 libhardware_legacy 作法，比较是传统的「module」方式，也就是将 *.so 档案当做「shared library」来使用，在runtime（JNI 部份）以 direct function call 使用 HAL module。透过直接函数呼叫的方式，来操作驱动程序。当然，应用程序也可以不需要透过 JNI 的方式进行，直接以加载 *.so 檔（dlopen）的做法呼叫*.so 里的符号（symbol）也是一种方式。总而言之是没有经过封装，上层可以直接操作硬件。
3 HAL 的现况

图3：Android HAL / libhardware

现在的 libhardware 作法，就有「stub」的味道了。HAL stub 是一种代理人（proxy）的概念，stub 虽然仍是以 *.so檔的形式存在，但 HAL 已经将 *.so 档隐藏起来了。Stub 向 HAL「提供」操作函数（operations），而 runtime 则是向 HAL 取得特定模块（stub）的 operations，再 callback 这些操作函数。这种以 indirect function call 的实作架构，让HAL stub 变成是一种「包含」关系，即 HAL 里包含了许许多多的
stub（代理人）。Runtime 只要说明「类型」，即 module ID，就可以取得操作函数。对于目前的HAL，可以认为Android定义了HAL层结构框架，通过几个接口访问硬件从而统一了调用方式。
4 HAL_legacy和HAL的对比

HAL_legacy：旧式的HAL是一个模块，采用共享库形式，在编译时会调用到。由于采用function

call形式调用，因此可被多个进程使用，但会被mapping到多个进程空间中，造成浪费，同时需要考虑代码能否安全重入的问题（thread safe）。

HAL：新式的HAL采用HAL module和HAL stub结合形式，HAL stub不是一个share library，编译时上层只拥有访问HAL stub的函数指针，并不需要HAL stub。上层通过HAL module提供的统一接口获取并操作HAL stub，so文件只会被mapping到一个进程，也不存在重复mapping和重入问题。

5 HAL module架构

HAL moudle主要分为三个结构：

struct hw_module_t;

struct hw_module_methods_t;

struct hw_device_t;

他们的继承关系如下图：

图4：Android HAL结构继承关系
6 HAL使用方法

（1）Native code通过hw_get_module调用获取HAL stub：

hw_get_module (LED_HARDWARE_MODULE_ID, (const hw_module_t**)&module)

（2）通过继承hw_module_methods_t的callback来 open设备：

module->methods->open(module,

LED_HARDWARE_MODULE_ID, (struct hw_device_t**)device);

（3）通过继承 hw_device_t的callback来控制设备：

sLedDevice->set_on(sLedDevice, led);

sLedDevice->set_off(sLedDevice, led);

7 HAL stub编写方法

（1）定义自己的HAL结构体，编写头文件led.h, hardware/hardware.h

struct led_module_t {

struct hw_module_t common;

};

struct led_control_device_t {

struct hw_device_t common;

int fd; /* file descriptor of LED device */

/* supporting control APIs go here */

int (*set_on)(struct led_control_device_t *dev, int32_t led);

int (*set_off)(struct led_control_device_t *dev, int32_t led);

};

继承关系如下图：

图5：HAL stub与HAL module继承关系

（2）设计led.c 完成功能实现和HAL stub注册

（2.1）led_module_methods继承 hw_module_methods_t，实现open的callback

struct hw_module_methods_t led_module_methods = {

open: led_device_open

};

（2.2）用 HAL_MODULE_INFO_SYM实例led_module_t，这个名称不可修改

tag：需要制定为 HARDWARE_MODULE_TAG

id：指定为 HAL Stub 的 module ID

methods：struct hw_module_methods_t，为 HAL 所定义的「method」

const struct led_module_t HAL_MODULE_INFO_SYM = {

common: {

tag: HARDWARE_MODULE_TAG,

version_major: 1,

version_minor: 0,

id: LED_HARDWARE_MODULE_ID,

name: "Sample LED Stub",

author: "The Mokoid Open Source Project",

methods: &led_module_methods,

}

/* supporting APIs go here. */

};
（2.3）open是一个必须实现的callback API，负责申请结构体空间，填充信息，注册具体操作API接口,打开Linux驱动。

由于存在多重继承关系，只需对子结构体hw_device_t对象申请空间即可。

int led_device_open(const struct hw_module_t* module, const char* name,

struct hw_device_t** device)

{

struct led_control_device_t *dev;

dev = (struct led_control_device_t *)malloc(sizeof(*dev));

memset(dev, 0, sizeof(*dev));

dev->common.tag = HARDWARE_DEVICE_TAG;

dev->common.version = 0;

dev->common.module = module;

dev->common.close = led_device_close;

dev->set_on = led_on;

dev->set_off = led_off;

*device = &dev->common;

/*

* Initialize Led hardware here.

*/

dev->fd = open(LED_DEVICE, O_RDONLY);

if (dev->fd < 0)

return -1;

led_off(dev, LED_C608);

led_off(dev, LED_C609);

success:

return 0;

}
（2.4）填充具体API操作代码

int led_on(struct led_control_device_t *dev, int32_t led)

{

int fd;

LOGI("LED Stub: set %d on.", led);

fd = dev->fd;

switch (led) {

case LED_C608:

ioctl(fd, 1, &led);

break;

case LED_C609:

ioctl(fd, 1, &led);

break;

default:

return -1;

}

return 0;

}

int led_off(struct led_control_device_t *dev, int32_t led)

{

int fd;

LOGI("LED Stub: set %d off.", led);

fd = dev->fd;

switch (led) {

case LED_C608:

ioctl(fd, 2, &led);

break;

case LED_C609:

ioctl(fd, 2, &led);

break;

default:

return -1;

}

return 0;

}


Android HAL 是如何被调用的
Android 对硬件的调用， google 推荐使用 HAL 的方式进行调用，对于 Andriod HAL 的写法，可以参考android 源码里的 hardware 目录下几个模块的模版。
在看 HAL 的编写方法的过程中，会发现整个模块貌似没有一个入口。一般说来模块都要有个入口，比如应用程序有 main 函数，可以为加载器进行加载执行， dll 文件有 dllmain ，而对于我们自己写的动态链接库，我们可以对库中导出的任何符号进行调用。
问题来了， Android 中的 HAL 是比较具有通用性的，需要上层的函数对其进行加载调用， Android 的 HAL 加载器是如何实现对不同的 Hardware Module 进行通用性的调用的呢？
带着这个疑问查看 Android 源码，会发现 Android 中实现调用 HAL 是通过 hw_get_module 实现的。
int hw_get_module(const char *id, const struct hw_module_t **module);
这是其函数原型， id 会指定 Hardware 的 id ，这是一个字符串，比如 sensor 的 id 是
#define SENSORS_HARDWARE_MODULE_ID "sensors" ，如果找到了对应的 hw_module_t 结构体，会将其指针放入 *module 中。看看它的实现。。。。

/* 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);

// 如果开发板叫做 mmdroid, 那么这里的 path 就是system/lib/hw/sensor.mmdroid.so

} else {

snprintf(path, sizeof(path), "%s/%s.default.so",

HAL_LIBRARY_PATH, id);// 默认会加载 /system/lib/hw/sensor.default.so

}

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 函数打开动态链接库

}

获取了动态链接库的路径之后，就会调用 load 函数打开它，下面会打开它。

奥秘在 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 ”

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

// 找到了 hw_module_t 结构！！！

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;

}

从上面的代码中，会发现一个很奇怪的宏 HAL_MODULE_INFO_SYM_AS_STR ，它直接被定义为了 #define HAL_MODULE_INFO_SYM_AS_STR "HMI" ，为何根据它就能从动态链接库中找到这个 hw_module_t 结构体呢？我们查看一下我们用到的 hal 对应的 so 就可以了，在 linux 中可以使用 readelf XX.so –s 查看。

Symbol table '.dynsym' contains 28 entries:

Num: Value Size Type Bind Vis Ndx Name

0: 00000000 0 NOTYPE LOCAL DEFAULT UND

1: 00000594 0 SECTION LOCAL DEFAULT 7

2: 00001104 0 SECTION LOCAL DEFAULT 13

3: 00000000 0 FUNC GLOBAL DEFAULT UND ioctl

4: 00000000 0 FUNC GLOBAL DEFAULT UND strerror

5: 00000b84 0 NOTYPE GLOBAL DEFAULT ABS __exidx_end

6: 00000000 0 OBJECT GLOBAL DEFAULT UND __stack_chk_guard

7: 00000000 0 FUNC GLOBAL DEFAULT UND __aeabi_unwind_cpp_pr0

8: 00000000 0 FUNC GLOBAL DEFAULT UND __errno

9: 00001188 0 NOTYPE GLOBAL DEFAULT ABS _bss_end__

10: 00000000 0 FUNC GLOBAL DEFAULT UND malloc

11: 00001188 0 NOTYPE GLOBAL DEFAULT ABS __bss_start__

12: 00000000 0 FUNC GLOBAL DEFAULT UND __android_log_print

13: 00000b3a 0 NOTYPE GLOBAL DEFAULT ABS __exidx_start

14: 00000000 0 FUNC GLOBAL DEFAULT UND __stack_chk_fail

15: 00001188 0 NOTYPE GLOBAL DEFAULT ABS __bss_end__

16: 00001188 0 NOTYPE GLOBAL DEFAULT ABS __bss_start

17: 00000000 0 FUNC GLOBAL DEFAULT UND memset

18: 00000000 0 FUNC GLOBAL DEFAULT UND __aeabi_uidiv

19: 00001188 0 NOTYPE GLOBAL DEFAULT ABS __end__

20: 00001188 0 NOTYPE GLOBAL DEFAULT ABS _edata

21: 00001188 0 NOTYPE GLOBAL DEFAULT ABS _end

22: 00000000 0 FUNC GLOBAL DEFAULT UND open

23: 00080000 0 NOTYPE GLOBAL DEFAULT ABS _stack

24: 00001104 128 OBJECT GLOBAL DEFAULT 13 HMI

25: 00001104 0 NOTYPE GLOBAL DEFAULT 13 __data_start

26: 00000000 0 FUNC GLOBAL DEFAULT UND close

27: 00000000 0 FUNC GLOBAL DEFAULT UND free

从上面中，第 24 个符号，名字就是“ HMI ”，对应于 hw_module_t 结构体。再去对照一下 HAL 的代码。

/*

* The COPYBIT Module

*/

struct copybit_module_t HAL_MODULE_INFO_SYM = {

common: {

tag: HARDWARE_MODULE_TAG,

version_major: 1,

version_minor: 0,

id: COPYBIT_HARDWARE_MODULE_ID,

name: "QCT MSM7K COPYBIT Module",

author: "Google, Inc.",

methods: ©bit_module_methods

}

};

这里定义了一个名为 HAL_MODULE_INFO_SYM 的 copybit_module_t 的结构体， common 成员为hw_module_t 类型。注意这里的 HAL_MODULE_INFO_SYM 变量必须为这个名字，这样编译器才会将这个结构体的导出符号变为“ HMI ”，这样这个结构体才能被 dlsym 函数找到！
综上，我们知道了 andriod HAL 模块也有一个通用的入口地址，这个入口地址就是 HAL_MODULE_INFO_SYM变量，通过它，我们可以访问到 HAL 模块中的所有想要外部访问到的方法。

内容来自用户分享和网络整理，不保证内容的准确性，如有侵权内容，可联系管理员处理

标签：

相关文章推荐

新的分享

章节导航