Treble計划
Treble計划是一個非常重要的變革，對系統層面的影響很大。Google每發布一個Android大版本，到廠商和APP的適配，過程是漫長的，每一次大版本適配工作的艱難廠商最能體會，各種兼容性問題。正如去年發布的Android O，目前Android O機型用戶量比較小，APP都沒能快速跟進把targetSdk適配到O的情況下，Android P又即將到來，Android系統的碎片化一直是一個痛點。該計划的核心主旨是讓系統與硬件相關的解耦，加快系統升級速度。Treble始於Android O，到Android P又得以進一步完善。
接下來，來看看Treble在整個Android系統的位置。
- Product: OEM相關定制，主要包括Apps，產品sysprops等
- System：Android系統的Framework和Daemons
- Treble Interface: Treble接口
- Vendor: 硬件相關
- ODM: ODM相關定制，比如VINTF支持
最中間Treble Interface組成成分，在Android O添加的接口：C++依賴(使用VNDK)，IPC調用(使用HIDL)，SELinux，通用Kernel接口，Android Verified Boot(AVB)；到Android P新增接口：Java依賴(使用System SDK)，系統Properties。從圖中可以看出Treble計划是希望底層Vendor用舊版本，也能支持System層升級為新版本，從而保證Android大版本可快速升級。
這里需要注意，System Property兼容性對於treble來說是非常糟糕的，它允許平台和Vendor之間通過非穩定通道進行跨進程通信，這與treble的分離解耦背道而馳。
為此，treble計划通過分離properties到platform和vendor。platform進程只能訪問平platform屬性，vendor進程只能訪問vendor屬性, 當然也是允許platform屬性去暴露給vendor進程。
- 所有platform對外暴露的屬性位於system/sepolicy/public/property_contexts，Vendor無法訪問其他的平台屬性；
- 所有可用於vendor init腳本的屬性位於system/core/init/stable_properties.h，Vendor init腳本不能使用其他的平台屬性來作為
action triggers。 - Vendor或者ODM屬性必須有自己的命名空間，比如vendor., ro.vendor, persist.vendor等
- vendor init使用vendor_init域名，保障只使用vendor相關權限，不可訪問system-only的屬性
VINTF(Vendor Interface)被分離成硬件無關(Framework)和硬件相關兩部分。為了進一步規范化系統架構，定義了CKI(Common Kernel Interface)作為通用系統鏡像必須依賴的內核接口集，並且對Kernel分支精簡也進行了有效的精簡。
VTS會測試HAL，Kernel, VNDK的可靠性，CTS測試通用系統接口，framework feature。從Android O以后就強制要求，通過CTS/VTS則會為system解耦合的適配提供了保障。
Treble語境中，Vendor是指片上系統的HAL層和外圍設備，不依賴於硬件的軟件則不屬於Vendor；VNDK是指Vendor用於實現HAL層所提供的系統庫。
- platform和Vendor的構建是相互隔離的。
- platform lib對應 system.img
- vendor lib對應 vendor.img
- 大多數情況下，Vendor lib跟系統核心不能相互使用；Vendor lib不允許dlopen私有的系統庫
- 合作伙伴不允許為自己的產品在VNDK新增lib，只能貢獻到AOSP