Note: Treble

從Android Oreo, Google 透過Treble 機制去解耦合HAL 跟Framework的相依性,希望借此機制去解決Android 碎片化跟安全性的問題。雖然目前還看不出有達成他想要的目的,但是真的有達成更進一步緊縮Android 裝置的控制權,不過最主要的原因實際是控制了GMS,跟Microsoft 藉由Office 控制桌面作業系統一個道理,是終端使用者離不開這些軟體與服務進而綁住供應商。
下圖是Android 的HAL 跟Framework的連結方式從1的傳統Legacy HAL 到2,3和4的Treble 實作方式,2 and 3的方法是為了提供舊的裝置單純升級到Android Oreo 提供的方法,如果裝置一開始就是Android Oreo 必須使用4 的方法

HIDL 是透過IPC 解藕合HAL與Framework 等於可以動態升級,不再是編譯時期繫結(Bind)。

而除了上述透過HIDL去分離界面外,再Kernel跟Disk Paratitions也做了規範,強制引入了/vendor or /odm paratitions 從/system or /boot 去分離HAL實作 而且也透過Kernel 4.4 and Later 去加入device tree overlays功能,讓廠商達成同一個 /boot and /system 去適應不同裝置的可能性

Update:
而Treble 的這種解藕合方式實際上有很大可能是為了新的Fuchsia OS (Kernel : Zircon)鋪路,透過IPC溝通系統內的所有組件,是micro kernel 的一個基本特徵, 而且透過這種方式後很可能Android P 之後會實現透過OTA切換 Linux/Zircon kernel

廣告

Note: Modular Kernel

官網看來需要把module driver 放到專屬的partitions (vendor/odm) 而且要可驗證的 並且ReadOnly, 而且Google 會強制你必須要用v3.18 (2017年以前出品的SOC 的最低要求), 而之後的SoC 則是不能低於v4.4 這應該是GMS/VTS 強制認證規範才是

然後Module file 不應該在/system 之下

/vendor or /odm 是被建議的Partition 裡面建立起 /lib/modules

然後透過early mount (VBoot v1 or VBoot v2)載入 /vendor and /odm

這幾個規範加起來就感覺到有很多裝置被判死刑