本文轉載自:https://blog.csdn.net/yangwen123/article/details/79835965

從AndroidO開始，google引入了Treble架構，目的是為了方便系統升級，將oem定製的東西和Framework分離。

AndroidO之前的版本：
在此之前的Android系統架構當中，Android Framework與Android HAL是打包成一個system.img的，而且Framework與HAL之間是緊耦合的，通過連結的方式使用相應的硬體相關so庫。老版本的android 的系統框架當中framework與HAL之間的一般架構框架是：

所以每次Android framework的升級需要對應的Android HAL升級。

AndroidO以及以後的版本
在Android O以及以後的版本當中，Android 更新了新的框架設計在新的框架設計當中，引入了一套叫HIDL的語言來定義Freamework與HAL之間的介面，新的架構如下圖：



跟以往的Android 版本相比較，Android O裡使用HIDL來解耦Android Framework 與Vendor HAL Implemetation之間的關係，從而簡化降低Android系統升級的影響與難度。

Android Framework會在system分割槽當中，而Vendor HAL Implemetation會在一個新定義的分割槽(Vendor.img)當中，這樣重新整理的system.img 才不會影響到Vendor HAL Implemetation，所以在Android O中的升級方式變成以下方式：



google的目的很理想，但現實很殘酷，大部分oem廠商是沒有google的研發實力的，無法跟上google的節奏，因此很多廠商還停留在android老版本，為了給oem廠商學習時間，同時保持Android向前相容，google為HAL定義了3種類型：

1，BinderizedHALs，從名字上應該是指Binder化的HAL，也就是說HAL都被寫成了binder service了，Android FW都是binder client。
2，PassthroughHALs，從google的官方介紹來說，這個是對原先HAL的包裝，但是最終的binder service 跟binder client都是活在同一個程序當中。這個應該是對老版本HAL的相容。

3，Same-ProcessHALs,由於某些效能的因素，這些HALs必須執行在Android Framework 所在的程序當中，比如surfaceflinger中的gralloc hal，如果進行程序分離，那麼對系統性能影響較大。