为啥有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直通式：

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

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

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

这种方式实现的代表就有audio部分 android.hardware.audio@6.0[2]::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[3]