一、前言

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

上述可總結為：

審核編輯：劉清