一、前言

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，因此稱為純綁定式

上述可總結為：