1. 什么是 CTS为什么它是出海必修课CTSCompatibility Test Suite是 Android 兼容性测试套件。对希望接入 GMS 生态的设备手机、平板等来说CTS 是基础门槛之一通过 CTS意味着设备行为与 Android 兼容性要求对齐标准 Android 应用在该设备上的运行一致性更高。从出海项目视角看CTS 的价值主要体现在三点降低应用兼容性风险减少上线后的区域性故障。为 GMS 认证链路提供关键测试凭证。在多机型并行开发时建立统一的质量基线。2. 物理测试环境先把“外部条件”搭对很多 CTS 失败并非代码问题而是环境不满足测试前提。建议优先把物理环境一次性搭齐。2.1 Bluetooth LE若设备支持 BLE执行 BLE scan 相关测试时设备周边约 5 米范围内建议至少放置 3 个 Beacon。2.2 CameraCamera 测试建议在正常照明下进行并准备测试图表如棋盘格。若设备支持外置摄像头能力测试时需接入外置 Camera否则相关用例可能失败。2.3 GPS/GNSS若设备支持 GPS/GNSS需提供符合要求的信号源如卫星模拟器、转发器或足够良好的室外信号条件。2.4 Wi-Fi 与 IPv6推荐使用支持 IPv4/IPv6、DNS、组播能力的 Wi-Fi 网络并可访问互联网。若现场无法直接提供 IPv6可通过可用的 IPv6 VPN 补齐部分能力。2.5 Wi-Fi RTTAndroid 9建议准备可用于 RTT 场景的 AP设备与 AP 距离建议在 12 米内。RTT 场景下 AP 供电开启即可不强制要求连网。3. 测试设备配置PC 与 DUT 双线准备3.1 PC 端配置要点建议使用 64-bit LinuxAndroid 11 建议 Ubuntu 14.04 及以上。Android 14 需要 FFmpeg 5.1.3 或更高版本。安装并配置最新 ADB / AAPTAndroid 14 还需单独配置 AAPT2。JDK 建议按 Android 版本匹配Android 11OpenJDK 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 单机测试基础模式cdandroid-cts/tools ./cts-tradefed run cts也可按模块或单用例精准运行run cts-mModuleNamerun cts-mModuleName-tTestCaseName5.2 分布式测试提速模式多台设备并行可显著缩短总时长例如 3 台设备run cts --shard-count36. 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-gsi8.2 PAB 包策略正式 CTS 版本更新节奏相对稳定短期修复常通过 PAB 包在 Android CI 发布。若正式版失败但最新 PAB 验证通过通常可按流程提交通过报告无需额外豁免以当期认证规则为准。8.3 Debug 建议路径对齐到对应 CTS Tag/Branch 代码后再分析问题。必要时在 CTS 代码中加日志并重编译对应 APK。用替换后的测试 APK 做最小复现场景验证。区分“平台问题 / 用例问题 / 环境问题”再决定是本地修复、cherry-pick 还是向上游提交 patch。9. 一套可复用的出海 CTS 执行方法论最后给出一个实践顺序供团队落地先环境后跑测先把物理与网络条件固化。先单机后分布式先验证基线稳定再用分布式提速。先归因后修复先定位失败类别再决定修复路径。先沉淀再复制把每次踩坑转成 Checklist缩短下一机型导入周期。 Android出海系列-CTS测试介绍
1. 什么是 CTS为什么它是出海必修课CTSCompatibility Test Suite是 Android 兼容性测试套件。对希望接入 GMS 生态的设备手机、平板等来说CTS 是基础门槛之一通过 CTS意味着设备行为与 Android 兼容性要求对齐标准 Android 应用在该设备上的运行一致性更高。从出海项目视角看CTS 的价值主要体现在三点降低应用兼容性风险减少上线后的区域性故障。为 GMS 认证链路提供关键测试凭证。在多机型并行开发时建立统一的质量基线。2. 物理测试环境先把“外部条件”搭对很多 CTS 失败并非代码问题而是环境不满足测试前提。建议优先把物理环境一次性搭齐。2.1 Bluetooth LE若设备支持 BLE执行 BLE scan 相关测试时设备周边约 5 米范围内建议至少放置 3 个 Beacon。2.2 CameraCamera 测试建议在正常照明下进行并准备测试图表如棋盘格。若设备支持外置摄像头能力测试时需接入外置 Camera否则相关用例可能失败。2.3 GPS/GNSS若设备支持 GPS/GNSS需提供符合要求的信号源如卫星模拟器、转发器或足够良好的室外信号条件。2.4 Wi-Fi 与 IPv6推荐使用支持 IPv4/IPv6、DNS、组播能力的 Wi-Fi 网络并可访问互联网。若现场无法直接提供 IPv6可通过可用的 IPv6 VPN 补齐部分能力。2.5 Wi-Fi RTTAndroid 9建议准备可用于 RTT 场景的 AP设备与 AP 距离建议在 12 米内。RTT 场景下 AP 供电开启即可不强制要求连网。3. 测试设备配置PC 与 DUT 双线准备3.1 PC 端配置要点建议使用 64-bit LinuxAndroid 11 建议 Ubuntu 14.04 及以上。Android 14 需要 FFmpeg 5.1.3 或更高版本。安装并配置最新 ADB / AAPTAndroid 14 还需单独配置 AAPT2。JDK 建议按 Android 版本匹配Android 11OpenJDK 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 单机测试基础模式cdandroid-cts/tools ./cts-tradefed run cts也可按模块或单用例精准运行run cts-mModuleNamerun cts-mModuleName-tTestCaseName5.2 分布式测试提速模式多台设备并行可显著缩短总时长例如 3 台设备run cts --shard-count36. 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-gsi8.2 PAB 包策略正式 CTS 版本更新节奏相对稳定短期修复常通过 PAB 包在 Android CI 发布。若正式版失败但最新 PAB 验证通过通常可按流程提交通过报告无需额外豁免以当期认证规则为准。8.3 Debug 建议路径对齐到对应 CTS Tag/Branch 代码后再分析问题。必要时在 CTS 代码中加日志并重编译对应 APK。用替换后的测试 APK 做最小复现场景验证。区分“平台问题 / 用例问题 / 环境问题”再决定是本地修复、cherry-pick 还是向上游提交 patch。9. 一套可复用的出海 CTS 执行方法论最后给出一个实践顺序供团队落地先环境后跑测先把物理与网络条件固化。先单机后分布式先验证基线稳定再用分布式提速。先归因后修复先定位失败类别再决定修复路径。先沉淀再复制把每次踩坑转成 Checklist缩短下一机型导入周期。