1. 什么是 CTS，为什么它是出海必修课
CTS（Compatibility Test Suite）是 Android 兼容性测试套件。对希望接入 GMS 生态的设备（手机、平板等）来说，CTS 是基础门槛之一：
通过 CTS，意味着设备行为与 Android 兼容性要求对齐，标准 Android 应用在该设备上的运行一致性更高。
从出海项目视角看，CTS 的价值主要体现在三点：
- 降低应用兼容性风险，减少上线后的区域性故障。
- 为 GMS 认证链路提供关键测试凭证。
- 在多机型并行开发时，建立统一的质量基线。
2. 物理测试环境：先把“外部条件”搭对
很多 CTS 失败并非代码问题，而是环境不满足测试前提。建议优先把物理环境一次性搭齐。
2.1 Bluetooth LE
- 若设备支持 BLE，执行 BLE scan 相关测试时，设备周边约 5 米范围内建议至少放置 3 个 Beacon。
2.2 Camera
- Camera 测试建议在正常照明下进行，并准备测试图表（如棋盘格）。
- 若设备支持外置摄像头能力，测试时需接入外置 Camera，否则相关用例可能失败。
2.3 GPS/GNSS
- 若设备支持 GPS/GNSS，需提供符合要求的信号源（如卫星模拟器、转发器或足够良好的室外信号条件）。
2.4 Wi-Fi 与 IPv6
- 推荐使用支持 IPv4/IPv6、DNS、组播能力的 Wi-Fi 网络，并可访问互联网。
- 若现场无法直接提供 IPv6，可通过可用的 IPv6 VPN 补齐部分能力。
2.5 Wi-Fi RTT（Android 9+）
- 建议准备可用于 RTT 场景的 AP，设备与 AP 距离建议在 12 米内。
- RTT 场景下 AP 供电开启即可，不强制要求连网。
3. 测试设备配置：PC 与 DUT 双线准备
3.1 PC 端配置要点
- 建议使用 64-bit Linux（Android 11+ 建议 Ubuntu 14.04 及以上）。
- Android 14+ 需要 FFmpeg 5.1.3 或更高版本。
- 安装并配置最新 ADB / AAPT；Android 14+ 还需单独配置 AAPT2。
- JDK 建议按 Android 版本匹配：
- Android 11+：OpenJDK 11
- 首次运行对应 CTS 版本时，Mainline 相关文件可能触发动态下载，建议提前准备，减少首跑时长。
3.2 DUT（待测设备）配置要点
- 必须使用 User GMS 构建版本执行 CTS。
- Android 13+ 重点关注 Device ID 与 CSR 部署；缺失会导致部分用例失败。
- Keybox：文档指出 Android 16 开始不再需要部署。
- 若设备具备卡槽/外设能力，需按要求插入并激活 SIM/SD 卡，必要时准备支持特权规则的 Developer UICC。
- 无内置屏幕设备需外接显示器。
3.3 Android 14+ 辅助设备
- 建议准备支持 CDP 协议的 Hub 参与辅助测试。
4. 开测前 Checklist：把高频失败点提前清零
建议每轮正式跑测前做一次“5 分钟体检”：
- 系统语言切换为 English (United States)。
- 打开 Location，连接可用 IPv6 Wi-Fi 并联网。
- 关闭锁屏密码；开启 USB Debugging 与 Stay Awake。
- Android 13+ 设备开启 Allow Mock Modem（如项目涉及相关 Telephony 测试）。
- USB 连接后确认调试授权（RSA）已允许。
- 媒体能力设备执行 copy_media.sh all（适用对应 CTS 版本要求）。
这一步做得细，通常可以显著减少“非代码型失败”。
5. CTS 执行策略：单机、分布式与精细化运行
5.1 单机测试（基础模式）
cd android-cts/tools
./cts-tradefed
run cts
也可按模块或单用例精准运行：
run cts -m <ModuleName>
run cts -m <ModuleName> -t <TestCaseName>
5.2 分布式测试（提速模式）
多台设备并行可显著缩短总时长，例如 3 台设备：
run cts –shard-count 3
6. Token Sharding：降低资源门槛的并行测试方案
Token Sharding 的核心价值在于“按能力分配任务”：
- 将对 SIM/UICC/SE 有特殊依赖的测试项，自动匹配到满足条件的设备。
- 避免所有设备都必须插同规格 SIM 卡，降低实验室准备成本。
- 同时支持首次测试与重试测试（retry）场景。
启用方式示例：
run cts –enable-token-sharding <...other flags...>
若设备不支持 Modem，可按文档建议忽略该模式。
7. 测试结果与日志分析：从“跑完”到“可交付”
CTS 结束后，重点关注以下输出：
- android-cts/results/：按时间戳生成结果目录及 zip 包。
- test_result.xml：最关键的结构化测试结果。
- android-cts/logs/host_log：主机侧执行日志（tradefed/终端输出）。
- android-cts/logs/device_log：设备侧日志（system/main）。
建议团队内部建立统一归档规范：
“版本号 + 设备型号 + 构建号 + 测试日期 + 结果摘要 + 问题单链接”，方便后续复测与审计。
8. CTS-on-GSI、PAB 与调试闭环
8.1 CTS-on-GSI
- 与常规 CTS 在环境与前置条件上基本一致。
- 关键差异在镜像要求，命令为：
run cts-on-gsi
8.2 PAB 包策略
- 正式 CTS 版本更新节奏相对稳定，短期修复常通过 PAB 包在 Android CI 发布。
- 若正式版失败但最新 PAB 验证通过，通常可按流程提交通过报告，无需额外豁免（以当期认证规则为准）。
8.3 Debug 建议路径
9. 一套可复用的出海 CTS 执行方法论
最后给出一个实践顺序，供团队落地：
