一、前言
HIDL的全称是HAL interface definition language（硬件抽象层接口定义语言），是AndroidFramework 与Android HAL之间的接口。HIDL 旨在用于进程间通信 (IPC)，进程之间的通信采用 Binder 机制；
Android O(8.0) 版本之后，底层实现有了比较大的变化，最显著的一个方面就是 HIDL 机制的全面实施。今天我们介绍下。
二、HIDL 设计目的
Android O(8.0) 之前系统的升级牵扯多方协作，极为麻烦，HIDL机制的推出就是将 framework 与 hal 层分开，使得框架部分可以直接被覆盖、更新，而不需要重新对 HAL 进行编译，这样在系统升级时，OEM 厂商 跳过 SoC 厂商，先对 framework 进行升级。
2.1、8.0 之前
framework 与 hal 紧紧耦合存在于 system.img 中，因此在版本升级时需要: OEM 厂商适配 framework ，SoC厂商 适配 hal， 之后将修改打包到 system.img，生成 OTA 升级包，推送到手机进行 OTA 升级
2.2、8.0 之后
framework 与 hal 进行了解耦， framework 存在于 system.img，hal 存在于vendor.img，进行版本升级时，分为两次升级:
- framework升级 ：OEM 厂商适配 framework，将修改打包到 system.img， 生成OTA 升级包，推送到手机进行 OTA 升级(framework 发生改变，hal 层未变)。
- hal升级 ：SoC 厂商适配 hal， 将修改打包到 vendor.img, 生成OTA 升级包，推送到手机进行OTA升级(framework发生改变，hal 层发生改变)。
三、HIDL机制演进
3.1 老版本 Framework 与 HAL 的通信框架
旧版的系统架构中， Android Framework 层与 Hal 层是打包成一个 system.img 的，且 Framework 与 hal 层之间是紧密耦合的，通过链接的方式使用相应的硬件 so 库。它们之间的架构一般有如下两种方式：
3.2 HIDL 类型介绍
为了解决两者之间这种紧耦合所带来的弊端，google 引入 HIDL 来定义 Framework 与 HAL 之间的接口，可以用下图来描述：
事实上虽然 google 推出了这种机制，但是很多厂商没有很快的跟上节奏，因此为了向前兼容， google 定义了三种类型：
- ① 是 Treble Project 之前使用的实现架构，使用的是传统 HAL 和旧版 HAL
- ② 直通模式，passthrough mode。如图所示，Framework 和 HAL 层工作在同一个进程当中，下面的 HAL 是使用 HIDL 封装后的库，是直通式 HAL。这些库文件也可用于 ③ 绑定模式
- ③ 绑定模式，binderized mode。是直通式 HAL binder 化，变为绑定式 HAL。Framework 和 HAL 层工作在不同的进程，之间通过 Binder 进行 IPC
- ④ 纯绑定式。相对于 ③ 来说，绑定式 HAL 中并不包含直通式 HAL，因此称为纯绑定式
上述可总结为：
