一、前言
Android O(8.0) 版本之后，底层实现有了比较大的变化，最显著的一个方面就是 HIDL 机制的全面实施。本文及接下来的几篇博文将从 HIDL的基本概念、HIDL服务模拟、framework层aidl服务、应用层程序 这四个方面来全面的阐述 HIDL 工作全过程，这对于理解系统源码中 Gnss、Usb、Camera 等模块的工作原理有极大帮助。
二、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，因此称为纯绑定式
上述可总结为：
参考
[ 1 ] hidl
[ 2 ] hidl trebl 演进
