關於HIDL的設計
HIDL的設計目的是爲了能夠在不重新編譯HALs的情況下能夠替換framework。HALs將由供應商或SOC製造商構建，並放在設備的vendor下的分區中，而framework框架在它自己的分區中發揮作用，能夠被OTA替換而不重新編譯HALs。
HIDL的設計平衡了以下問題:
共用性
在進程間創建可靠的共用接口，而這些進程可能有不同的架構、工具鏈和構建配置。HIDL接口是版本化的，在發佈後不能更改。
效率
HIDL會將複製的次數最小化。HIDL定義的數據以C++標準layout data structures的形式傳遞給c++代碼，這種數據結構可以不打包的情況下使用。HIDL還提供共享內存接口，由於RPCs天生有點慢，HIDL無需使用RPC調用，而支持兩種傳輸數據的方法:shared memory （共享內存）和 Fast Message Queue (FMQ).
直觀
對於RPC，HIDL只使用參數(參見AIDL)，避免了內存所有權的棘手問題;不能有效通過方法返回的值通過回調函數返回。既不將數據傳遞到HIDL，也不從HIDL接收數據，改變數據的所有權。數據只需要在被調用函數的持續時間內存在，並且可以在被調用函數返回後立即銷燬。
使用 passthrough 模式
爲了更新運行在Android系統早期版本的設備到Android O操作系統，你可以將傳統的(和 legacy遺留的)HALs封裝在新的HIDL接口中，這一接口以binderized 和same-process (passthrough)的模式服務於HAL。這種封裝對HAL和Android框架都是透明的。
Passthrough模式僅適用於c++的客戶端和實現。運行Android早期版本的設備沒有Java編寫的HALs，因此Java HALs必然使用binderized 的模式。
Passthrough header files
當一個.hal文件被編譯後， hidl-gen除了用於binder通信的頭文件外，還生成一個額外的 passthrough 頭文件 BsFoo.h ；這個頭文件定義了dlopened的函數. 由於passthrough HALs 運行在調用它們的相同的進程中，大多數情況下 passthrough 方法被直接通過函數調用 (相同線程)。oneway 方法在他們自己的線程中運行，因爲它們並不打算等待HAL來處理它們(這意味着任何在passthrough模式中使用oneway方法的HAL必須是線程安全的)。
給定一個IFoo.hal文件，BsFoo.h封裝了hidl生成的方法以提供額外的特性(比如在另一個線程中運行oneway事務)。這個文件類似於BpFoo。但是，不是通過binder進行IPC調用，而是直接調用所需的函數。未來HALs可能提供多種實現，例如FooFast HAL和FooAccurate HAL。在這種情況下，將創建每個額外實現的文件(例如:PTFooFast.cpp和PTFooAccurate.cpp)。
Binderizing passthrough HALs
支持passthrough 模式的HAL實現可以binderized 。對於一個HAL 接口[email protected]::IFoo,需要創建兩個包：
[email protected]::IFoo-impl. 包含HAL的實現，並暴露函數IFoo * HIDL_FETCH_IFoo(const char * name)。在legacy hal設備上，這個包是dlopened 的，實現是使用HIDL_FETCH_IFoo實例化的。 您可以使用hidl - gen和- lc + + - impl和- landroidbp - impl生成基本代碼。
[email protected]::IFoo-service. 打開passthrough HAL並將其註冊爲一個binder化服務，使相同的HAL實現被用作passthrough 和binderized。
給定類型IFoo，您可以調用sp < IFoo > IFoo::getService(string name, bool getStub)來獲取IFoo的實例。
如果getStub值是true，getService嘗試只以passthrough模式打開HAL。如果getStub爲false，則getService嘗試查找到一個binderized 服務;如果失敗，則嘗試找到passthrough服務。getStub參數除了defaultPassthroughServiceImplementation不應使用。(使用Android O的設備是完全binderized 的設備，因此不允許以passthrough模式打開一個服務。)