Android出海系列-VTS测试介绍
2026-07-19 / 龙之叶   

一、什么是 VTS，为什么它对出海至关重要

从 Android 8.0 开始，Google 引入 Project Treble，将系统框架层与厂商实现层（Vendor）解耦。Treble 之前，每次系统升级都需要厂商同步修改底层实现；Treble 之后，Google 提供了稳定的 Vendor 接口，厂商只需更新框架层即可大幅缩短升级周期。

Project Treble 架构对比示意

对应到认证体系中，Google 通过两套测试套件保障兼容性：

测试套件 测试对象 主要覆盖
CTS Framework 层 应用兼容性、系统 API
VTS Vendor 层 Kernel、HAL、Lib 等底层接口

CTS 与 VTS 测试范围对比

从 Android 8.0 起，所有新设备不仅需要通过 CTS，还必须通过 VTS，且 VTS 测试必须在 CTS 之前完成。对于出海项目而言，VTS 是 GMS 认证流程中不可跳过的关键环节。

二、VTS 测试前的环境准备（决定首轮通过率）

VTS 的通过率，通常不是由“命令会不会跑”决定，而是由“测试环境是否严谨”决定。建议按以下三层准备：

VTS 测试环境三层准备清单

1) PC 端环境

  • 操作系统：Ubuntu 14.04 及以上
  • JDK：1.8 及以上，Android 11+ 建议 JDK 9+
  • Python：Android 10 及之前使用 Python 2.7，Android 11+ 使用 Python 3
  • 工具链：安装并配置 adb、fastboot、aapt/aapt2
  • 环境变量：将上述工具路径加入 PATH
  • 本地化 vtspython 源：避免从 PyPI 在线拉取依赖导致网络不稳定而测试失败

Python 环境变量配置示例：

1
2
3
4
# 编辑 /etc/profile，添加本地 vtspython 源路径
export VTS_PYPI_PATH=/usr/local/bin/vtspython
source /etc/profile
echo $VTS_PYPI_PATH   # 验证配置生效

注意：Android 14 及以上版本 VTS 测试需要配置 AAPT2 环境，否则部分 APK 解析安装会失败。

2) 设备端环境

设备端配置是 VTS 通过率的“隐形门槛”，需要按步骤逐一完成：

  1. 设备校准：建议通过 GNSS OTA 校准
  2. 硬件模组：安装指纹模组、NFC 模组和 Camera 模组
  3. Unlock 操作：下载 Userdebug 版本，开启 OEM unlocking 和 USB debugging，执行 fastboot flashing unlock
  4. 产线部署：Android 12+ 必需，写入 RPMB Key，一台设备只需部署一次
  5. Device Attestation ID 部署：Android 13+ 必需
  6. keybox 部署：Android 15 及之前需要（Android 16 首发设备改用 RKP）
  7. 刷 GSI 版本：使用带 GSI 的 User 工程 pac 包
  8. CSR 提取上传：Android 13+ 必需，用于 RKP 远程密钥配置

安全部署策略时间线

3) 网络与外场条件

  • Wi-Fi 必须稳定，且能正常访问 Google 服务器
  • Android 9+ 需要稳定 GPS 信号（室外空旷环境，或室内使用 GPS 信号转发器）
  • 双卡机型需插入双实网 SIM 卡并设置主卡
  • 支持 SecureElement HAL 的项目需准备 Android Test Card（支持 SE 的白卡）

三、VTS 实测流程：从启动到结果判定

1) 基本执行流程

VTS 测试完整流程

1
2
3
4
5
6
7
8
9
# 1. 解压 VTS 测试包到本地
# 2. 进入 tools 目录
cd <installation-path>/android-vts/tools

# 3. 启动 VTS 控制台
./vts-tradefed

# 4. 执行整包测试
> run vts

常用命令速查：

命令 含义
> l r 列出所有跑测结果
> l d 列出所有检测到的设备
> run vts -m <模块名> 单跑某个模块
> run vts -m <模块名> -t <测试项名> 单跑指定测试项
> run vts -s <device_id> --logcat-on-failure 失败时捕获 logcat
> run retry --retry <session_id> 重跑失败项（Android 10+）

更多命令可通过控制台执行 help all 查看。

2) 结果怎么看

测试结束后，控制台会显示执行完成提示，同时在测试包路径下生成 logs 和 results 文件夹。打开 results/<日期>/test_result.xml 即可查看详细测试结果。

判定要点：

  • 控制台出现执行结束提示 → 当前轮次完成
  • test_result.xml 中 fail 项需逐一分析
  • 建议结合 logcat-on-failure 日志做首轮归因
  • 环境类 Fail 建议复测一次后再提交研发

四、高频失败点与出海项目实战建议

1) 先区分“环境失败”与“代码失败”

很多首轮 Fail 来自环境波动（Wi-Fi、GPS、SIM、部署前置步骤缺失），并非代码缺陷。建议先复测一次，再决定是否进入研发改码流程。

2) 已知特殊情况速查

特殊要求 影响模块 适用版本
设备 Unlock All All
产线部署 PerInstance/GenerateKeyTests 等 Android 12+
Device Attestation ID VtsHalRemotelyProvisionedComponentTargetTest Android 13+
keybox 部署 VtsAidlKeyMintTargetTest 等 Android 15 及之前
指纹模组 VtsHalBiometricsFingerprint 系列 All
双实网 SIM 卡 VtsHalRadio、CtsVcnTestCases Android 9+
稳定 Wi-Fi VtsHalDrm 系列 All
稳定 GPS VtsHalGnssV1_1Target Android 9+
Android Test Card VtsHalSecureElementV1_0Target Android 9+

3) Android 版本越新，安全与认证前置条件越重

  • **Android 12+**：产线部署对部分模块已是硬性前提
  • **Android 13+**：VtsHalRemotelyProvisionedComponentTargetTest 与 Device Attestation/CSR 强相关
  • Android 15 及之前：若未完成 keybox，KeyMint 相关用例容易集中失败
  • Android 16 首发（first_api_level >= 36）：不再部署 keybox，仅支持 RKP 方案

4) Ylog 策略要“按需开启”

VTS 问题定位通常先看 VTS 自身日志；仅在需要跨层排查时再补抓 AP/Modem/WCN/GNSS 日志，避免无效日志导致分析成本上升。各 Android 版本的 Ylog 命令差异较大，建议按目标平台查阅对应配置。

5) Google 原生问题与豁免策略

部分 Fail 属于 Google VTS 用例本身的 Bug，需提交 Google Issue 跟踪。Google 对豁免用例的处理策略是：必须在 dev 包（Google 提供的修改版 VTS 测试包）测试通过后才能申请豁免，否则不予同意。

五、推荐的团队落地打法（可直接复用）

  1. 建立版本化测试基线：按 Android 主版本维护独立 VTS 命令模板与环境清单
  2. 固化预检脚本：在正式跑测前自动检查 adb/fastboot/aapt2、网络连通、主卡状态、GPS 条件
  3. 失败分层归类：环境类、配置类、平台类、Google 原生问题分别入库追踪
  4. 豁免流程前置：对疑似 Google 原生问题尽早提交 issue，保留复现证据和对比版本记录

六、结语

VTS 不是“跑一遍命令”这么简单，而是一套覆盖环境、设备、安全认证与版本策略的系统工程。在 Android 出海项目中，越早把 VTS 流程标准化、自动化，越能降低认证周期与返工成本。

如果你正在推进 Android 13/14/15/16 的海外认证，建议优先把 RKP/CSR、产线部署、网络/GPS 稳定性 三件事做成可重复执行的检查清单，这会直接提升首轮通过率。

本文链接：
http://longzhiye.top/2026/07/19/2026-07-19/