hal开发之hidl/aidl支持的绑定式直通式详细讲解

为啥有hidl呢？

这个问题其实网络上答案比较多，属于android想要让厂商快速升级解耦制定的，即把原来系统framework和厂商耦合的hal在同一个个system.img进行剥离开，把厂商相关的放到vendor.img，aosp系统公共部分framework相关的放到system.img.
官方解释：
Android O的一项新元素是 Project Treble。这是 Android 操作系统框架在架构方面的一项重大改变，旨在让制造商以更低的成本更轻松、更快速地将设备更新到新版 Android 系统。
在Android O之前，HAL是一个个的.so库，通过dlopen来进行打开，库和framework位于同一个进程。
新的架构之下，framework和hal运行于不同的进程，所有的HAL采用新的HIDL技术来完成。作为此变化的一部分，运行 Android 8.0 的设备必须支持绑定式或直通式 HAL：

绑定式 HAL
以 HAL 接口定义语言 (HIDL) 表示的 HAL。这些 HAL 取代了早期 Android 版本中使用的传统 HAL 和旧版 HAL。在绑定式 HAL 中，Android 框架和 HAL 之间通过 Binder 进程间通信 (IPC) 调用进行通信。所有在推出时即搭载了 Android 8.0 或后续版本的设备都必须只支持绑定式 HAL。

直通式 HAL
以 HIDL 封装的传统 HAL 或旧版 HAL。这些 HAL 封装了现有的 HAL，可在绑定模式和
Same-Process（直通）模式下使用。升级到 Android 8.0 的设备可以使用直通式 HAL。

一看就知道绑定式HAL是主推方法了，后面的HAL也将用绑定式HAL方式编写。

第一种就没啥可以分析的，在8.0以前都是这种方式，即直接应用进程包含一个hw的so，针对以上的其他几个情况分析：

情况2直通式：

这里其实采用就是直通式，目前系统中使用这种方式的较少，最经典就是[email protected]::IMapper/default这个库还是采用这种直通式。
什么是直通式？
最重要区分直通式域绑定式在于调用端客户进程是否和服务端提供hal功能实现的，是否在一个进程执行。
这里也是使用了hidl，但是明显这个地方他只是做了一下接口包装，所有hal的执行依然在客户端进程。

情况3绑定式（服务端包装维护hal库）

这种方式就是采用是绑定式，这样对system的应用或者框架，就可以通过hidl或aidl接口来通讯，但是绑定服务的具体实现其实还是调用了以前的老hal so方式来实现服务的。

这种方式实现的代表就有audio部分 [email protected]::IDevicesFactory/default，
他的实现方式就是有一个单独的服务android.hardware.audio.service：

audioserver    968     1   49636  17696 0                   0 S android.hardware.audio.service

这个服务与audioserver这种客户端进行跨进程通讯，audioserver就通过hidl相关接口调用到android.hardware.audio.service，android.hardware.audio.service具体实现是调用的原来的hal那一套hw库，相当于所有相关的业务其实还在老款的hal库里面

情况4绑定式

这个和上面其实绑定式理解没啥区别，只是在服务端实现有区别，这种实现是直接自己服务端实现hal，而上面实现却是调用了老版本的hal库，这种方式要求新加入的hal库都是这种实现方式，完全所有的实现在服务端进程里面，即不需要在额外包裹hw库方式，厂商编译时候可以考虑直接提供相关的可执行文件既可以
如下图就是直接提供了相关的hal的可执行文件：
这里就直接提供了相关指纹的bin文件进行集成

更多framework干货课程优惠获取相关可以+V（androidframework007）
视频：https://www.bilibili.com/video/BV1ah411d7Y3