Android (VTS) 的概念、作用及测试方法

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 推送的时间。