admin管理员组

文章数量:1648025

文章目录

  • 1.HAL层在Android系统中的位置
  • 2.HAL层概述
  • 3.旧的HAL架构module
  • 4.新的HAL架构module stub
  • 5.HAL Stub框架分析

1.HAL层在Android系统中的位置

2.HAL层概述

1)、HAL层是上层应用对底层硬件操作屏蔽的一个软件层次,就是上层应用不必关心底层硬件具体是如何工作的,只需要调用底层提供的统一接口即可。HAL层对接具体的硬件bsp接口,比如视频接口、收音机接口、网络接口、spi接口等。HAL层就是为了把操作系统和硬件解耦。

Linux 驱动一般由访问硬件代码和业务逻辑代码两部分组成。Linux 内核提供了标准的读写硬件的方法,只需要调用 Linux提供的标准函数即可。

而 Linux驱动的业务逻辑对厂商或个人来说是保密的。例如,缓冲区的设置等。Google 在Android体系中添加一个 HAL层的目的是为了满足不想开源的个人或者厂商的要求,该层位于系统库层和 Linux 内核层之间。对于想开源的 Linux 驱动个人或者厂商,既可以将驱动业务逻辑放在 HAL层,也可以放在驱动程序中。而对于不想公开 Linux 驱动代码的个人或者厂商,Linux 驱动只是一个传递数据给相关设备的角色。即Linux 驱动中只有操作设备寄存器的代码,而没有任何的业务代码。HAL 层统一了硬件的调用接口,HAL 层的编写需要遵循一定的规范。

2)、Android系统为硬件抽象层中的模块接口定义了编写规范,我们必须按照这个规范来编写自己的硬件模块接口。

3)、Android系统的硬件抽象层以模块的形式来管理各个硬件访问接口。每一个硬件模块都对应有一个动态链接库文件,这些动态链接库文件的命名需要符合一定的规范。同时,在系统内部,每一个硬件抽象层模块都是用结构体hw_module_t来描述,而硬件设备则使用结构体hw_device_t来描述。

①、设备驱动分为内核空间和用户空间两部分
  保护厂商利益(出发点)
  内核空间主要负责硬件访问逻辑(GPL)
  用户空间主要负责参数和访问流程控制(Apache License)

②、用户空间部分设备驱动即为HAL Module
  HAL Module通过设备文件访问内核空间部分设备驱动
  
③、系统服务通过HAL Module对硬件进行管理
  系统服务通过JNI访问HAL Module
  
④、应用程序通过系统服务对硬件进行访问
  应用程序通过Binder IPC访问系统服务

3.旧的HAL架构module

Android App或者framework层代码由Java实现,Java运行在Dalvik虚拟机中,没有办法直接访问底层硬件,只能通过调用so本地库代码实现,在so本地代码里有对底层硬件操作的代码,如下图所示:

可以这样说,App或者framework层Java代码,通过JNI技术调用C或C++写的so库代码,在so库代码中调用底层驱动,从而实现上层应用操作底层硬件的目的。实现硬件操作的so库为module。
其实现流程如下图所示:

这种设计架构虽然满足了Java应用访问硬件的需要,但是,使得我们的代码上下层次间的耦合太高,用户程序或者框架代码必须要去加载module库,如果底层硬件有变化,module要重新编译,上层也要做相应变化,另外,如果多个应用程序同时访问硬件,都去加载module,同一module被多个进程映射多次,会有代码的重入问题。

4.新的HAL架构module stub

新的代码架构使用的是module stub方式,.Stub是存根或者桩的意思,其实说白了,就是指一个对象代表的意思。
上层应用层或者框架层代码加载so库代码,so库代码我们称之为module,在Hal层注册了每个硬件对象的存根stub,当上层需要访问硬件的时候,就从当前注册的硬件对象stub里查找,找到之后stub会向上层module提供该硬件对象的operations interface(操作接口),该操作接口就保存在module中,上层应用或框架层再通过这个module操作接口来访问硬件。其架构如下:

以上分别介绍了Module架构和Stub架构,下面做一个对比:

在Module架构中,本地代码由so库实现,上层直接将so库映射到进程空间,会有代码重入及设备多次打开的问题。
新的Stub框架虽然也要加载module库,但是这个module已经不包含操作底层硬件驱动的功能了,它里面保存的只是底层stub提供的操作接口,底层stub扮演了“接口提供者”的角

本文标签: androidHAL