一、什么是 VTS，为什么它对出海至关重要
从 Android 8.0 开始，Google 引入Project Treble，将系统框架层与厂商实现层（Vendor）解耦。Treble 之前，每次系统升级都需要厂商同步修改底层实现；Treble 之后，Google 提供了稳定的 Vendor 接口，厂商只需更新框架层即可大幅缩短升级周期。
对应到认证体系中，Google 通过两套测试套件保障兼容性：
| 测试套件 | 测试对象 | 主要覆盖 |
|---|---|---|
| CTS | Framework 层 | 应用兼容性、系统 API |
| VTS | Vendor 层 | Kernel、HAL、Lib 等底层接口 |
从 Android 8.0 起，所有新设备不仅需要通过 CTS，还必须通过 VTS，且VTS 测试必须在 CTS 之前完成。对于出海项目而言，VTS 是 GMS 认证流程中不可跳过的关键环节。
二、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 环境变量配置示例：
# 编辑 /etc/profile，添加本地 vtspython 源路径exportVTS_PYPI_PATH=/usr/local/bin/vtspythonsource/etc/profileecho$VTS_PYPI_PATH# 验证配置生效注意：Android 14 及以上版本 VTS 测试需要配置 AAPT2 环境，否则部分 APK 解析安装会失败。
2) 设备端环境
设备端配置是 VTS 通过率的“隐形门槛”，需要按步骤逐一完成：
- 设备校准：建议通过 GNSS OTA 校准
- 硬件模组：安装指纹模组、NFC 模组和 Camera 模组
- Unlock 操作：下载 Userdebug 版本，开启 OEM unlocking 和 USB debugging，执行
fastboot flashing unlock - 产线部署：Android 12+ 必需，写入 RPMB Key，一台设备只需部署一次
- Device Attestation ID 部署：Android 13+ 必需
- keybox 部署：Android 15 及之前需要（Android 16 首发设备改用 RKP）
- 刷 GSI 版本：使用带 GSI 的 User 工程 pac 包
- CSR 提取上传：Android 13+ 必需，用于 RKP 远程密钥配置
3) 网络与外场条件
- Wi-Fi 必须稳定，且能正常访问 Google 服务器
- Android 9+ 需要稳定 GPS 信号（室外空旷环境，或室内使用 GPS 信号转发器）
- 双卡机型需插入双实网 SIM 卡并设置主卡
- 支持 SecureElement HAL 的项目需准备 Android Test Card（支持 SE 的白卡）
三、VTS 实测流程：从启动到结果判定
1) 基本执行流程
# 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 测试包）测试通过后才能申请豁免，否则不予同意。
五、推荐的团队落地打法（可直接复用）
- 建立版本化测试基线：按 Android 主版本维护独立 VTS 命令模板与环境清单
- 固化预检脚本：在正式跑测前自动检查 adb/fastboot/aapt2、网络连通、主卡状态、GPS 条件
- 失败分层归类：环境类、配置类、平台类、Google 原生问题分别入库追踪
- 豁免流程前置：对疑似 Google 原生问题尽早提交 issue，保留复现证据和对比版本记录
六、结语
VTS 不是“跑一遍命令”这么简单，而是一套覆盖环境、设备、安全认证与版本策略的系统工程。在 Android 出海项目中，越早把 VTS 流程标准化、自动化，越能降低认证周期与返工成本。
如果你正在推进 Android 13/14/15/16 的海外认证，建议优先把RKP/CSR、产线部署、网络/GPS 稳定性三件事做成可重复执行的检查清单，这会直接提升首轮通过率。
