Android硬件抽象层HAL层

hal的作用

• 硬件抽象层是介于android内核kernel和上层之间的抽象出来的一层结构。他是对linux驱动的一个封装，对上层提供统一接口，上层应用不必知道下层硬件具体的实现工作，屏蔽了底层实现细节。
  

hal的意义

• 谷歌搭建好了hal的框架，为上层framework打开通过jni调用hal提供了同一的api，硬件开发商或者移植人员只需要按照框架开发接口，不需要耗时时间在与上层的交互实现上

• 硬件厂商可以将核心动心放入到hal层，hal层属于用户空间，不属于linux内核，和android源码一样遵循的是appache协议，这个可以自我选择是否开源，如果没有hal层，核心放入内核空间驱动程序实现，必须遵循GPL协议，是必须开源的。

hal的架构和实现原理

• android hal层的代码主要位于/hardware/libhardware

• 在hal层中，各类硬件的都是以硬件模块的形式描述的，hal层中是用hw_module_t结构体来描述的，而每一类硬件模块中又有各个独立的硬件，hal中是用hw_module_t结构体来描述的

• 上层app通过jni调用硬件时，首先获取到hw_module_t结构体，也就是硬件模块，有了这个才能对硬件进行操作。

• 它们的定义在/hardware/libhardware/include/hardware/hardware.h里面。

hw_module_t

• hw_module_t表示硬件模块，它主要包含了一些硬件模块的信息，结构体的定义：

• hw_module_methods_t,这个指针methods它指向的是与本硬件模块相关的方法的结构体，只有一个函数指针，open是打开硬件模块中硬件设备的函数，然后是成员函数void* dso，它是打开硬件模块相关的额设备之后返回的句柄给它
  

hw_dvice_t

• hw_device_t这个结构体主要是用来描述模块中硬件设备的属性信息的。一个硬件模块可能会有多个硬件设备。比如：传感器模块，sensor_module是一个硬件模块，但是手机中的传感器对应的有好多种，比如加速度acc_sensor，磁传感器M_sensor等，他们都属于snesor_module，但是他们会有各自的hw_device_t结构体来描述：

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

• 后一个函数指针close指向的肯定是关闭设备的函数。

hal层搜索调用so库

• 硬件厂商的HAL核心代码是以共享库的形式出现的，每次在需要的时候，hal会子雄加载调用相关共享库，怎么加载找到某一硬件设备对应的共享库呢？

• 上层App通过jni调用hal层的hw_get_module函数获取硬件模块，这个函数是上层与hal打交道的入口。这个函数就是hal层第一个被调用的函数

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

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

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

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

  下面看看怎么找的。

• 有个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这个数组的元素个数，这是一个字符串数组

  将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。

• 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拼出来的值是/vender/lib/hw/leds.tout.so,然后在判断文件是否存在。如果存在跳出循环。

• 从以上分析，其实这就是hal层搜索动态共享库的方式

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

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

  当所有变种名称形式的包都不存在时，就以"id.default.so"形式包名查找是否存在。

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

hal层load so库

• android HAL层是如何搜索硬件模块的动态共享库的，其实就是在"system/lib/hw/“或者”/vendor/lib/hw/"这两个路径下找到共享库modueid.variant.so后，通过调用load函数加载库。

• 以下为load函数定义，同样在/hardware/libhardware/hardware.c中实现的。实现加载共享库的

• load函数传入的几个参数，第一个参数就是需要加载的硬件模块对应动态库的硬件模块的id；

• 第二个参数就是动态库存放的路径，就是在hw_get_module函数前部分搜索库得到的path；

• 第三个参数就是我们需要得到的硬件模块结构体，通过它传给hw_get_module，hw_get_module函数在通过参数传给jni。

• 首先调用dlopen打开共享库，该函数通过传入的库的路径找到库，并且打开它，传回一个操作句柄handle，然后再调用dlsym函数解析这个打开的库，下面第29行，得到库中包含的硬件模块结构体，并将它返回回来。所以硬件厂商或者硬件移植者都必须根据hal的这个架构去实现填充这个和自己硬件相关的硬件模块结构体hw_module_t，供使用。

• 通过dlsym解析之后就得到了hw_module_t，随后第37行，将从库中解析得到的结构体中的id和传入的id做比较，看是否一致。

• 如果一致则证明就是得到正确的硬件模块了。

• 将hw_module_t结构体指针传给第三个参数，传给hw_get_module函数。

• hw_get_module函数就得到了硬件模块结构体hw_module_t.

• 有了hw_module_t,那么通过其内部的method open就能打开硬件模块对应的设备了，通过结构体中的一些方法就能操作硬件设备了。