Android硬件抽象层（HAL）概要介绍和学习计划  

20##-08-02 14:34:31|  分类： android |  标签：android  ubuntu11.04  硬件抽象层  hal   |字号 订阅

 

      Android的硬件抽象层，简单来说，就是对Linux内核驱动程序的封装，向上提供接口，屏蔽低层的实现细节。也就是说，把对硬件的支持分成了两 层，一层放在用户空间（User Space），一层放在内核空间（Kernel Space），其中，硬件抽象层运行在用户空间，而Linux内核驱动程序运行在内核空间。为什么要这样安排呢？把硬件抽象层和内核驱动整合在一起放在内 核空间不可行吗？从技术实现的角度来看，是可以的，然而从商业的角度来看，把对硬件的支持逻辑都放在内核空间，可能会损害厂家的利益。我们知 道，Linux内核源代码版权遵循GNU License，而Android源代码版权遵循Apache License，前者在发布产品时，必须公布源代码，而后者无须发布源代码。如果把对硬件支持的所有代码都放在Linux驱动层，那就意味着发布时要公开 驱动程序的源代码，而公开源代码就意味着把硬件的相关参数和实现都公开了，在手机市场竞争激烈的今天，这对厂家来说，损害是非常大的。因 此，Android才会想到把对硬件的支持分成硬件抽象层和内核驱动层，内核驱动层只提供简单的访问硬件逻辑，例如读写硬件寄存器的通道，至于从硬件中读 到了什么值或者写了什么值到硬件中的逻辑，都放在硬件抽象层中去了，这样就可以把商业秘密隐藏起来了。也正是由于这个分层的原因，Android被踢出了 Linux内核主线代码树中。大家想想，Android放在内核空间的驱动程序对硬件的支持是不完整的，把Linux内核移植到别的机器上去时，由于缺乏 硬件抽象层的支持，硬件就完全不能用了，这也是为什么说Android是开放系统而不是开源系统的原因。

     撇开这些争论，学习Android硬件抽象层，对理解整个Android整个系统，都是极其有用的，因为它从下到上涉及到了Android系统的硬件驱动 层、硬件抽象层、运行时库和应用程序框架层等等，下面这几个图阐述了硬件抽象层在Android系统中的位置，以及它和其它层的关系，以及在整个启动过程 中和应用程序调用的过程中HAL在整个android系统中所起到的作用。

     本章，我们将重点放在HAL硬件抽象层的学习当中，在学习Android硬件抽象层的过程中，我们将会学习如何在内核空间编写硬件驱动程序、如何在硬件抽 象层中添加接口支持访问硬件、如何在系统启动时提供硬件访问服务以及、如何编写JNI使得可以通过Java接口来访问硬件，而作为中间的一个小插曲，我们 还将学习一下如何在Android系统中添加一个C可执行程序来访问硬件驱动程序。由于这是一个系统的学习过程，笔者将分成六篇文章来描述每一个学习过 程，包括:

     一. 在ubuntu11.04下为Android内核源代码工程中编写硬件驱动程序。

     二. 在ubuntu11.04下为Android系统中增加C可执行程序来访问硬件驱动程序。

     三. 在ubuntu11.04下为Android硬件抽象层增加接口模块访问硬件驱动程序。

     四. 在ubuntu11.04下为Android系统中编写JNI方法在应用程序框架层提供Java接口访问硬件。

     五. 在ubuntu11.04下为Android系统的应用程序框架层增加硬件服务接口。

     六. 在ubuntu11.04下为Android系统中编写APP通过应用程序框架层访问硬件服务。

     学习完这六篇文章，相信大家对Android系统就会有一个更深刻的认识了，敬请关注。

原文摘自：http://blog.csdn.net/luoshengyang/article/details/6567257，本文只作为个人理解后的内容。

 

第二篇：Android硬件抽象层(HAL)之深入剖析

作为一个搞android驱动或者说搞底层的人，我觉得对于hal那是必须要掌握的，而且必须达到一定深度，于是我总结了一下，将整个自己的分析思路写下来。

主要是看android源代码，根据源代码得到的思路。(看源代码比看什么著作书籍都管用) android 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源码一样遵循的是appache协议，这个是可以开源或者不开的。

搞清楚了hal的存在意义，下面来根据hal层源码分析一下hal到底是怎么样个架构和实现原理，深入剖析一下。

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

在hal层中，各类硬件的都是以硬件模块的形式描述的hal层中是用hw_module_t结构体来描述的，而每一类硬件模块中又有各个独立的硬件，hal中是用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; //tag，根据引文注释可以看到必须被初始化为

HARDWARE_MODULE_TAG

/** major version number for the module */

uint16_t version_major;//主版本号

/** minor version number of the module */

uint16_t version_minor;//次版本号

/** Identifier of module */

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

/** padding to 128 bytes, reserved for future use */

uint32_t reserved[32-7];

} hw_module_t;

前面tag，name那几个成员属性就不说了，看了注释相信大家都知道了，下面看看hw_module_methods_t,这个指针methods它指向的是与本硬件模块相关的方法的结构体，里面不用看可以猜出肯定有一些函数指针，但是它里面只有一个函数指针。可以看看定义： 1 typedef struct hw_module_methods_t {

2 /** Open a specific device */

3 int (*open)(const struct hw_module_t* module, const char* id,//打开硬件设备函数指针

4

struct hw_device_t** device);

5

6 } hw_module_methods_t;

我们可以看到确实只有一个函数指针，open它是打开硬件模块中硬件设备的函数。 然后是成员void* dso，它是打开硬件模块相关的额设备之后返回的句柄给它，这个在后面看hw_get_module函数源码的时候你就会明白。

b. 下面我们再来看看hw_device_t结构体,这个结构体主要是用来描述模块中硬件设备的属性信息什么的。一个硬件模块可能有多个硬件设备。

比如说，传感器模块，sensor_module,是一个硬件模块，但是手机中的传感器就对应的有好多种，比如加速度acc_sensor,磁传感器M_sensor等，那么他们都属于

sensor_module,但是他们有都有自己的

hw_device_t结构体来描述。hw_device_t定义：

1 /**

2 * Every device data structure must begin with hw_device_t

3 * followed by module specific public methods and attributes.

4 */

5 typedef struct hw_device_t {

6 /** tag must be initialized to HARDWARE_DEVICE_TAG */

7 uint32_t tag; //设备tag

8

9 /** version number for hw_device_t */

10 uint32_t version;//版本

11

12 /** reference to the module this device belongs to */

13

struct hw_module_t* module;//本设备归属的硬件模块

14

15 /** padding reserved for future use */

16 uint32_t reserved[12];//保留

17

18 /** Close this device */

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

21 } hw_device_t;

其中，第三个成员module指向的是这个设备归属的硬件模块结构体。

最后一个函数指针close

指向的肯定是关闭设备的函数。

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

上一篇我们分析了android HAL层的主要的两个结构体hw_module_t(硬件模块)和hw_device_t(硬件设备)的成员，下面我们来具体看看上层app到底是怎么实现操作硬件的？

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

上层app通过jni调用hal层的hw_get_module函数获取硬件模块，这个函数是上层与hal打交道的入口。所以如果我们以程序调用执行的流程去看源码的话，这个函数就是hal层第一个被调用的函数，下面我们就

从这个函数开始，沿着程序执行的流程走下去。

hw_get_module函数定义在/hardware/libhardware/hardware.c中，打开这个文件可以看到定义如下：

1 int hw_get_module(const char *id, const struct hw_module_t **module) 2 {

3 int status;

4 int i;

5 const struct hw_module_t *hmi = NULL;

6

char prop[PATH_MAX];

7 char path[PATH_MAX];

8

9 /*

10 * Here we rely on the fact that calling dlopen multiple times on

11 * the same .so will simply increment a refcount (and not load

12 * a new copy of the library).

13 * We also assume that dlopen() is thread-safe.

14 */

15

16 /* Loop through the configuration variants looking for a module */ 17 for (i=0 ; i<HAL_VARIANT_KEYS_COUNT+1 ; i++) {

18 if (i < HAL_VARIANT_KEYS_COUNT) {

19 if (property_get(variant_keys[i], prop, NULL) == 0) {//获取属性 20 continue;

21 }

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

23 HAL_LIBRARY_PATH1, id, prop);

24 if (access(path, R_OK) == 0) break;//检查system路径是否有库文件

25

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

27 HAL_LIBRARY_PATH2, id, prop);

28 if (access(path, R_OK) == 0) break;//检查vender路径是否有库文件

29 } else {

30 snprintf(path, sizeof(path), "%s/%s.default.so",//如果都没有，则使用缺省的

31 HAL_LIBRARY_PATH1, id);

32 if (access(path, R_OK) == 0) break;

33 }

34 }

35

36 status = -ENOENT;

37 if (i < HAL_VARIANT_KEYS_COUNT+1) {

38 /* load the module, if this fails, we're doomed, and we should not try 39 * to load a different variant. */

40 status = load(id, path, module);//装载库，得到module

41 }

42

43 return status;

44 }

看第一行我们知道有两个参数，第一参数id就是要获取的硬件模块的id，第二个参数module就是我们想得到的硬件模块结构体的指针。

所以可以看出，上层首先给hal需要获取的硬件模块的id，hw_get_module函数根据这个id去查找匹配和这个id对应的硬件模块结构体的。

下面看看怎么找的。

17行有个for循环，上限是HAL_VARIANT_KEYS_COUNT+1，那么这个

HAL_VARIANT_KEYS_COUNT是什么呢？查看同文件下找到有：

static const int HAL_VARIANT_KEYS_COUNT =

(sizeof(variant_keys)/sizeof(variant_keys[0]));

原来它是ariant_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"

};

可以看到它其实是个字符串数组。站且不知道干什么的。继续看hw_get_module函数，进入for循环里面，看22行，其实它是将HAL_LIBRARY_PATH1, id, prop这三个串拼凑一个路径出来，

HAL_LIBRARY_PATH1定义如下：

/** Base path of the hal modules */

#define HAL_LIBRARY_PATH1 "/system/lib/hw"

#define HAL_LIBRARY_PATH2 "/vendor/lib/hw"

id是上层提供的，prop这个变量的值是前面19行property_get(variant_keys[i], prop, NULL）函数获取到的，其实这个函数是通过ariant_keys数组的的属性查找到系统中对应的变种名称。不同的平台获取到prop值是不一样的。

假如在获取到的prop值是tout，需要获取的硬件模块的id是leds，那么最后path组成的串是/system/lib/hw/leds.tout.so。

后面24行access是检查这个路径下是否存在，如果有就break，跳出循环。如果没有，继续走下面，

可以看到下面几行和刚才形式差不多，

snprintf(path, sizeof(path), "%s/%s.%s.so", HAL_LIBRARY_PATH2, id, prop); if (access(path, R_OK) == 0) break;//检查vender路径是否有库文件

结合 HAL_LIBRARY_PATH2 为"/vendor/lib/hw"，假设同样获取到的prop值是tout，需要获取的硬件模块的id是leds，这种情况下path拼出来的值是

/ender/lib/hw/leds.tout.so,然后在判断文件是否存在。如果存在跳出循环。

从以上分析，其实这就是hal层搜索动态共享库的方式，从中我们可以得到两点：

1.动态共享库一般放在 "/system/lib/hw"和"/vendor/lib/hw"这两个路径下。

2.动态库的名称是以"id.variant.so"的形式命名的，其中id为上层提供，中间variant为变种名称，是岁系统平台变化的。

接着，从29到32行我们可以看到，当所有变种名称形式的包都不存在时，就以"id.default.so"形式包名查找是否存在。

37行， if (i < HAL_VARIANT_KEYS_COUNT+1)，如果i小于变种名称数组的话，表示找到了对应的库，那么38行load(id, path, module);//装载库，得到module。

以上就对hal层搜索库的规则搞清楚了。