前言：
作为一个搞 android 驱动或者说搞底层的人，我觉得对于 hal 那是必须要掌握的，而且必须达到一定的深度，于是我总结了一下，将整个自己的分析思路写下来。
主要是看 andorid 源代码，根据源代码得到的思路。（看源代码必看什么著作书籍都管用）。
Android HAL 是什么？为什么有它？
硬件抽象层是介于 android 内核 kernel 和上层之间的抽象出来的一层结构。他是对 Linux 驱动的一个封装，对上层提供统一接口，上层应用不必知道下层硬件具体怎么实现工作的，它屏蔽了底层的实现细节。
它在整个 Android 架构中的位置如下图所示：
传统的 Linux 对硬件的操作基本上在内核空间中的 linux 驱动程序中实现了，那么现在为什么那么多此一举把对硬件的操作分为两部分，HAL 和 Linux 驱动呢？
而且 HAL 属于用户空间，Linux 驱动属于内核空间。其实并不多余。那么为什么要搞出这么个东西，理由是很多的：
- 谷歌搭好了 HAL 的框架，为上层 framework 通过 jni 调用 HAL 提供了统一的 api，硬件开发商或者移植人员只需要按照框架开发即可，无需多费精力在与上层的交互的实现上，将精力放在 HAL 层本身的实现上即可。
- 从商业角度，许多硬件厂商不愿意将自己硬件相关的一些核心的东西开源出去，假如将对自己硬件的驱动程序全部放入内核空间驱动程序实现，那么必须遵循 GPL 协议，是必须开源的。有了 HAL 层之后，他们可以把一些核心的算法之类的东西的实现放在 HAL 层，而 HAL 层位于用户空间，不属于 Linux 内核，和 Android 源码一样遵循的是 appache 协议，这个是可以开源或者不开的。
搞清楚了 HAL 的存在意义，下面来根据 HAL 层源码分析一下 HAL 到底是怎么样个架构和实现原理，深入剖析一下。
关键结构体：
/hardware/libardware，下面我们从上往下走。
在 HAL 层中，各类硬件的都是以硬件模块的形式描述的，HAL 层中是用 hw_module_t 结构体来描述的，而每一类硬件模块中又有各个独立的硬件，HAL 中是用 hw_device_t 结构体来描述的。
上层 APP 通过 jni 调用硬件时，首先得获取到 hw_module_t 结构体，也即是硬件模块，有了这个才能再对硬件进行操作。那么我们来看看这两个结构体定义是什么样子的。
它们的定义在 /hardware/libhardware/include/hardware/hareware.h 里面。
hw_module_t：
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 它指向的是与本硬件模块相关的方法的结构体，里面不用看可以猜出肯定有一些函数指针，但是它里面只有一个函数指针。可以看看定义：
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 它是打开硬件模块中硬件设备的函数。
然后是成员 void *dso，它是打开硬件模块相关的设备之后返回的句柄给它，这个在后面看 hw_get_module 函数源码的时候你就会明白。
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; //设备tag
/** version number for hw_device_t */
uint32_t version;//版本
/** reference to the module this device belongs to */
struct hw_module_t* module;//本设备归属的硬件模块
/** padding reserved for future use */
uint32_t reserved[12];//保留
/** Close this device */
int (*close)(struct hw_device_t* device);//关闭设备的函数指针
} hw_device_t;其中，第三个成员 module 指向的是这个设备归属的硬件模块结构体。
最后一个函数指针 close 指向的肯定是关闭设备的函数。
恩，到此，HAL 的主要的两个结构体讲完了，下次我们继续，将结合源码，看看 HAL 层到底是怎么工作的，看看上层怎么获取到硬件模块，硬件设备的，到底是怎么加载解析动态共享库的。
