Android Vendor Test Suite (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 推送时间。 下图描述了这种新的架构：

采用新架构后 Android 系统升级过程是直接对的 Framework 替换如下图所示：

对工程师的影响

对于这样的架构变化 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 android.hardware.nfc@1.0 hardware/libhardware/include/hardware/nfc.h

关于 HIDL 可以参考我之前写的介绍。《Android HIDL 本文简介。 除模块编写外 .hal 我们还应确保相应的文件.rc脚本也被添加到源代码目录中，脚本的名称通常是 android.hardware.<moduleName>@<version>-service.rc，位于 hardware/interfaces/<moduleName>/<versionNumber>/default/ 目录下。例如，音频模块的脚本名称是android.hardware.audio@2.0-service.rc。例如，音频模块的脚本名称是android.hardware.audio@2.0-service.rc。如下图：

然后在 makefile 添加相应的声明：

再在 sepolicy 添加相应的权限声明： device/<companyName>/commom/sepolicy/ 目录下新建 .te 例如，我负责文件 Audio 然后在目录下新建模块 hal_audio_default.te 在文件中添加所需的规则。如下：

也可以最后加这些 sepolicy 规则。相应的规则没有。 .te 在文件的情况下，直接将文件 setenforce 环境变量值设置为 permissive 测试不会提示权限问题。 最后，编译系统镜像并将其烧制到设备中。设备上电后可使用 ps -A 命令看到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

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 配置