Android (VTS) 的概念、作用及測試方法

轉載自：[http://blog.csdn.net/qidi_huang/article/details/76653677]

Android Vendor Test Suite (VTS) 的概念、作用及測試方法

Qidi　2017.08.01 (Markdown & Haroopad)

---

注意：本文基於 Android 8.0 進行分析。

這篇文章會不定期更新，歡迎大家指出問題和提出建議。

---

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

• 1

• 1

　　然後就可以使用這個工具進行自動轉換了。比如我們要為 NFC HAL 生成相應的 .hal 檔案，那麼可以執行下方的命令：

$ c2hal -r android.hardware:hardware/interfaces -r android.
hidl:system/libhidl/transport -p android.hardware.nfc@1.0 hardware/libhardware/include/hardware/nfc.h

• 1
• 2

• 1
• 2

　　關於 HIDL 的介紹可以參考我之前寫的《Android HIDL 簡介》這篇文章。 
　　除了為模組編寫.hal檔案，我們還應該確保相應的.rc指令碼也已經新增到原始碼目錄中了，指令碼的名字一般是android.hardware.<moduleName>@<version>-service.rc，位於hardware/interfaces/<moduleName>/<versionNumber>/default/目錄下。比如音訊模組的指令碼名稱就是android.hardware.audio@2.0-service.rc。如下圖： 

　　然後在 makefile 中新增相應的宣告： 
 
　　再在 sepolicy 中新增相應的許可權宣告：在 device/<companyName>/commom/sepolicy/ 目錄下新建 .te 檔案，比如我負責 Audio 模組，那麼就在該目錄下新建了 hal_audio_default.te 檔案，然後在檔案中新增需要的規則。如下： 

　　也可以最後再新增這些 sepolicy 規則。在沒有編寫相應 .te 檔案的情況下，直接把 setenforce 環境變數的值設定為 permissive 進行測試也不會提示許可權問題。 
　　最後編譯系統映象並燒寫到裝置，裝置上電執行起來後就可以使用ps命令看到android.hardware.audio@2.0-service程式已經隨系統啟動而執行起來了。

---

4、怎麼進行 VTS 測試

　　要進行 VTS 測試，首先需要搭建測試環境，我們需要以下這些元件： 
　　 
+ 64-bit Ubuntu Linux 
+ Java 8 
+ Python 2.7 
+ ADB 1.0.39

　　具體的搭建步驟是： 
1） 安裝 Python 開發包

$ sudo apt-get install python-dev

• 1

• 1

2） 安裝 Protocol Buffer 工具

$ sudo apt-get install python-protobuf
$ sudo apt-get install protobuf-compiler

• 1
• 2

• 1
• 2

3） 安裝 Python 虛擬環境相關工具

$ sudo apt-get install python-virtualenv
$ sudo apt-get install python-pip

• 1
• 2

• 1
• 2

4） 在裝置上啟用開發者模式並開啟 USB 除錯功能 
5） 檢查裝置是否能被 ADB 探測到

$ adb devices

• 1

• 1

6） 使用 ADB 登入裝置

$ adb shell

• 1

• 1

　　如果以上步驟你都執行成功了，那麼 VTS 測試環境就搭建好了。 
　　然後我們還需要先編譯 VTS 測試工具。在 Android 原始碼根目錄下執行以下命令可以生成測試工具：

$ source build/envsetup.sh
$ lunch <productName>
$ make vts -j20

• 1
• 2
• 3

• 1
• 2
• 3

　　其中 < product > 的值需要根據你想要進行測試的產品來給定。 
　　編譯完成後，我們可以在out/host/linux-x86/vts/android-vts.zip目錄下找到 VTS 測試包，解壓之後，進入android-vts/tools/目錄，執行以下命令即可進行預設的全域性 VTS 測試：

$ vts-tradefed
> run vts

• 1
• 2

• 1
• 2

　　也可以只對某個模組進行測試：

$ vts-tradefed
> run vts -m VtsHalAudioV2_0Target

• 1
• 2

• 1
• 2

　　還可以只對某個模組中的某一項用例進行測試：

$ vts-tradefed
> run vts -m VtsHalAudioV2_0Target -t RecommendedOutputStreamConfigSupport

• 1
• 2

• 1
• 2

　　剩下的就是耐心等待。測試完成後我們可以在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》