Android硬件抽象层HAL层

hal的作用

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

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表示硬件模块,它主要包含了一些硬件模块的信息,结构体的定义:

Android硬件抽象层HAL层_第2张图片

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

hw_dvice_t

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

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

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

hal层搜索调用so库

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

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

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

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

Android硬件抽象层HAL层_第5张图片

  • 看第一行我们知道有两个参数,第一参数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中实现的。实现加载共享库的

Android硬件抽象层HAL层_第6张图片
Android硬件抽象层HAL层_第7张图片
Android硬件抽象层HAL层_第8张图片

  • 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就能打开硬件模块对应的设备了,通过结构体中的一些方法就能操作硬件设备了。

你可能感兴趣的:(Android硬件抽象层HAL层)