https://zhuanlan.zhihu.com/p/28301953
1、前言 - Project Treble
Android 目前有一個比較明顯的缺點是裝置更新到新版本系統所要花費的時間太長（比如從 Android 6.0 更新到 Android 7.0）。通常在由 Google 釋出新版本的 AOSP 之後，還需要 SoC 廠商對 HAL 進行更新，以及 OEM 廠商對 HAL 和 Framework 進行更新後，使用者才能在裝置上收到 OTA 更新包的推送。低端一點的産品甚至在出廠後就不會再進行系統更新了。使用者對此抱怨良多。反觀競争對手 iOS 在這方面就做得比較好（但這不代表我支援 iOS）。
為了解決這個問題，于是 Google 發起了 Project Treble 項目。2017 年 5 月 12 日，官方在”Developers Blog”上向公衆介紹了這一項目并宣布 Android 8.0 中将引入它，但從目前我拿到的描述 Project Treble 的相關文檔的修訂記錄來看，這些文檔最早的起草時間可以追溯到 2015 年 10 月 30 日。 而 Project Treble 中最重要的就是新增了 Vendor Interface 這一概念，以及相應的 Vendor Test Suite (VTS) 測試。
2、VTS 的概念及作用
VTS 全稱是 Vendor Test Suite，官方在介紹它時将其與 CTS 進行了類比，原文是：
Project Treble aims to do what CTS did for apps, for the Android OS framework. The core concept is to separate the vendor implementation — the device-specific, lower-level software written in large part by the silicon manufacturers — from the Android OS Framework.
This is achieved by the introduction of a new vendor interface between the Android OS framework and the vendor implementation. The new vendor interface is validated by a Vendor Test Suite (VTS), analogous to the CTS, to ensure forward compatibility of the vendor implementation.
意思是 Project Treble 中引入 Vendor Interface 的目的是将 Android Framework 與 HAL 分開，并通過 VTS 測試來對這些 Vendor Interface 進行測試以確定 HAL 的向前相容。
隻看這一段可能還是描述得不太清楚。我們知道僅管 APP 層與 Framework 層在設計上是分開的， 但通過 CTS 測試，確定了 APP 與 Android Framework 之間有一緻的調用接口（API），這使得 APP 開發者編寫的同一款程式可以運作在不同系統版本（向前相容）、不同硬體平台、不同廠商制造的不同裝置上。 VTS 類似 CTS，通過對 Vendor Interface 進行測試，確定同一個版本的 Android Framework 可以運作在不同 HAL 上，或不同 Android Framework 可以運作在 同一個 HAL 上。 通過這樣的 Framework / HAL 分離設計和接口一緻性保證，也使得 8.0 版本之後的 Android 系統在進行更新時，可以直接對 Framework 進行更新而不用考慮 HAL 層的改動，進而縮短了使用者手上裝置得到系統更新 OTA 推送的時間。
下面的圖描述了這種新的架構：
采用新架構之後的 Android 系統更新過程則是直接對 Framework 進行替換，如下圖：
3、對工程師的影響
這樣的架構變動對于 Android 裝置使用者的影響是他們今後可以得到更及時的更新服務，對于我們 Android BSP 工程師來說就是要為實作這樣的服務鋪設好平台基礎，主要是以下幾方面工作：
1）将現有 Android Framework 中耦合的 HAL 代碼剝離出來
2）使用 HIDL 描述的 HAL （.hal檔案）替換舊的頭檔案描述的 HAL
3）根據接口描述實作各子產品 HAL。
4）在 makefile 中為 .hal 檔案添加聲明
5）添加相應的 SEpolicy 配置
根據文檔《HIDLHALVersioningandExtensions.pdf》的描述，Android 8.0 及之後版本的系統僅支援經過 binder 化（binderized）的 HAL，是以老版本的 HAL 必須被全部替換掉。原文如下：
The most relevant aspect of this change is the binderization of the HAL:
Binderized HALs replace older versions of the HALs, and all devices running Android O must support binderized HALs only.
慶幸的是，我們可以使用 c2hal 工具将那些在頭檔案中定義的老的 HAL 接口轉換為使用 HIDL 描述的 .hal 檔案，這會大大減少我們手動進行添加的工作量，甚至有時我們會發現這些基本工作有的已經由 Google 的工程師幫我們完成了，我們隻需要根據這些 .hal 檔案中的 Vendor Interface 接口定義和資料聲明來實作這些接口就好。
要使用 c2hal 工具，我們需要先執行下面的指令來生成她：
$ make c2hal
然後就可以使用這個工具進行自動轉換了。比如我們要為 NFC HAL 生成相應的 .hal 檔案，那麼可以執行下方的指令：
$ c2hal -r android.hardware:hardware/interfaces -r android.
hidl:system/libhidl/transport -p andro[email protected] hardware/libhardware/include/hardware/nfc.h
關于 HIDL 的介紹可以參考我之前寫的《Android HIDL 簡介》這篇文章。
除了為子產品編寫 .hal 檔案，我們還應該確定相應的.rc腳本也已經添加到源碼目錄中了，腳本的名字一般是 android.hardware.<moduleName>@<version>-service.rc，位于 hardware/interfaces/<moduleName>/<versionNumber>/default/ 目錄下。比如音頻子產品的腳本名稱就是 [email protected].rc。如下圖：
然後在 makefile 中添加相應的聲明：
再在 sepolicy 中添加相應的權限聲明：在 device/<companyName>/commom/sepolicy/ 目錄下建立 .te 檔案，比如我負責 Audio 子產品，那麼就在該目錄下建立了 hal_audio_default.te 檔案，然後在檔案中添加需要的規則。如下：
也可以最後再添加這些 sepolicy 規則。在沒有編寫相應 .te 檔案的情況下，直接把 setenforce 環境變量的值設定為 permissive 進行測試也不會提示權限問題。
最後編譯系統鏡像并燒寫到裝置，裝置上電運作起來後就可以使用 ps -A 指令看到[email protected]程序已經随系統啟動而執行起來了。
4、怎麼進行 VTS 測試
要進行 VTS 測試，首先需要搭建測試環境，我們需要以下這些元件：
+ 64-bit Ubuntu Linux
+ Java 8
+ Python 2.7
+ ADB 1.0.39
具體的搭建步驟是：
1） 安裝 python 開發包
$ sudo apt-get install python-dev
2） 安裝 Protocol Buffer 工具
$ sudo apt-get install python-protobuf
$ sudo apt-get install protobuf-compiler
3） 安裝 Python 虛拟環境相關工具
$ sudo apt-get install python-virtualenv
$ sudo apt-get install python-pip
4） 在裝置上啟用開發者模式并打開 USB 調試功能
5） 檢查裝置是否能被 ADB 探測到
$ adb devices
6） 使用 ADB 登入裝置
$ adb shell
如果以上步驟你都執行成功了，那麼 VTS 測試環境就搭建好了。 然後我們還需要先編譯 VTS 測試工具。在 Android 源碼根目錄下執行以下指令可以生成測試工具：
$ source build/envsetup.sh
$ lunch <productName>
$ make vts -j20
其中 < product > 的值需要根據你想要進行測試的産品來給定。
編譯完成後，我們可以在out/host/linux-x86/vts/android-vts.zip目錄下找到 VTS 測試包，解壓之後，進入android-vts/tools/目錄，執行以下指令即可進行預設的全局 VTS 測試：
$ vts-tradefed
> run vts
也可以隻對某個子產品進行測試：
$ vts-tradefed
> run vts -m VtsHalAudioV2_0Target
還可以隻對某個子產品中的某一項用例進行測試：
$ vts-tradefed
> run vts -m VtsHalAudioV2_0Target -t RecommendedOutputStreamConfigSupport
剩下的就是耐心等待。測試完成後我們可以在android-vts/results/目錄下找到測試報告，可以在android-vts/logs/目錄下看到測試日志。
5、如何解決 VTS Fail 項 / VTS 測試失敗的可能原因
目前我根據文檔總結出了以下幾種可能導緻 VTS 測試失敗的原因：
1) 沒有使用經過 binderized 的 HAL
2) HAL 中存在與接口規範不符的實作
3) Kernel 接口問題
4) 沒有添加相應的 SEpolicy 配置
這個内容我寫了另一篇文章，感興趣的工程師朋友可以閱讀《Android 8.0 VTS 測試 FAIL 項解決記錄》。
參考資料：
[1] 《Here comes Treble: A modular base for Android》（需要翻牆）
[2] 《Android VTS v8.0 Codelab》（需要翻牆）
[3] 《VendorTestSuiteDesign.pdf》
[4] 《Using_Binder_Between_Vendor_Processes_5_5_17.pdf》
[5] 《TrebleHALChecklist.pdf》
[6] 《Project Treble Engineering Design.pdf》
[7] 《HIDLHALVersioningandExtensions.pdf》