1. 概述什么是 GTS/为什么要测GTSGMS Test SuiteGMS 测试套件是自动化测试工具用于验证GMS 应用集成是否正确与 Google 签订合同条款相关的系统配置是否一致典型测试项包括GMS 集成验证、部分系统 API 校验、Widevine 集成、用户体验要求例如 launcher 必需放置 Google Search、分销协议要求如 MADA/EMADA 条款等注意GTS 测试在 Linux 环境执行无 Windows 版本。2. 测试环境搭建PC 端Linux2.1 PC 基本要求支持 64bit Linux 系统Android 11 及以上需要在 Ubuntu 14.04 及更高版本上测试2.1.1 ADB 和 AAPT开始 GTS 测试前确认已安装最新版本的adbAndroid Debug Bridge与aaptAndroid Asset Packaging Tool工具路径已加入环境变量PATH步骤概览从 Android SDK 下载工具包解压后运行 tools 目录下的 Android 工具在 SDK Manager 更新Android SDK Tools、Platform-tools、Build-tools将Tools、Platform-tools、Build-tools三个目录加入PATH重新加载环境变量如source另外Android 14 及以上 GTS 需要配置 AAPT2否则可能出现部分 APK 解析/安装失败。AAPT2 下载https://developer.android.google.cn/studio/command-line/aapt2?hlen#download_aapt2配置要点文档描述将 AAPT2 复制到/usr/bin并赋予可执行权限如sudo chmod 777 aapt22.1.2 JDK 版本Android 11 及以上OpenJDK 112.1.3 GTS 文件测试包下载需匹配待测设备的内容与待测设备 Android 版本匹配的 GTS与待测设备支持的 ABIApplication Binary Interface匹配的 GTS 测试包目录结构要点logs/、results/在测试执行后才会出现2.1.4 Device detectionUSB 设备识别udevUbuntu 下如无法识别通过 USB 连接的终端需要创建 udev 规则sudogedit /etc/udev/rules.d/51-android.rulesSUBSYSTEMusb, ATTR{idVendor}1782,MODE0666,GROUPplugdev# 参数按实际配置sudochmod777/etc/udev/rules.d/51-android.rulessudoserviceudev restartidVendor/GROUP等参数需按你实际厂商/用户组环境调整。2.1.5 定制化 GTS 能力测试可选Google 增加了定制化 GTS 能力可为特定合作伙伴增加额外测试集限制在授权范围内。关键步骤从 Google Account Manager 或第三方实验室获取authentication key文件将 key 文件放到 PC 可访问目录将 key 文件绝对路径配置到环境变量APE_API_KEY示例文档形式exportAPE_API_KEYpath_to_key.json进入 GTS 测试包执行一次探测测试run gts-mGtsPlacementTestCases--conditional-business-logic-tcom.google.android.placement.gts.DefaultIntentTest#testDefaultIntentHandlers若通过该测试项表示定制环境配置成功否则需要检查 key、上传状态等。3. 待测设备配置Device 端3.1 User buildsGTS 需要在User版本构建上进行测试不要用 engineering/userdebug。3.2 Attestation Keybox 部署Android 16 适配要点文档要求GTS 测试前需要对测试设备进行Attestation Keybox 部署否则部分测试项会失败。但同时给出关键更新Android 16 开始不需要部署 Attestation Keybox。结论面向 Android 16 的目标机型可跳过 Attestation Keybox 部署步骤但如果你仍在做低版本回归/兼容测试仍需按文档要求部署。3.3 Widevine Keybox 部署GTS 测试前需要进行Widevine Keybox部署否则部分测试项会失败。若支持 Provisioning 4.0则无需单独部署 Widevine Keybox。3.4 Device ID 部署Android 13对于 Android 13 及以上版本GTS 测试前需要对测试设备进行 Device ID 部署否则部分测试项会失败。3.5 CSR 部署Android 13对于 Android 13 及以上版本需要提取测试设备 CSR 信息并上传到 Google 服务器否则部分测试项会失败。3.6 屏幕若待测设备无嵌入式屏幕需要外接一个屏幕。3.7 SD 卡若设备存在存储卡槽插入一张空SD 卡SD 卡建议支持 UHS或写入速度至少 Class 1010MB/s用于确保能通过 GTS 测试3.8 SIM 卡若设备存在 SIM 卡槽每个卡槽插入激活的 SIM 卡如设备支持 SMS需要在Setting中显示每张 SIM 卡对应的电话号码Android 12 及以上所有 SIM 卡必须支持存储 ADNAbbreviated Dialling Numbers带telecom dedicated file (DTelcom)的 GSM/USIM 卡满足该要求文档提醒部分模块可能因 Google 测试要求变化使用普通 SIM 卡无法通过此时需要更换可国际漫游的流量卡再次测试。当且仅当待测设备不支持 Modem 功能时该项配置可忽略。3.9 Developer UICCCarrier API 测试为运行 GTS 中的 carrier API 测试用例待测设备需要一张支持carrier privilege规则的 SIM 卡。4. 待测设备预置条件运行前准备文档列出的关键预置条件如下烧写待测版本或恢复出厂设置恢复出厂Settings System Reset options Erase all data (factory reset)连接 Wi‑Fi 并确保能访问 Internet入口Settings Network internet internet系统语言设置为英语United StatesSettings System Language region如支持 GPS 或网络定位能力打开 LocationSettings Location On取消屏幕锁/密码Settings Security privacy Device unlock Screen lock None开启 USB debuggingSettings Developer options USB debugging若 Developer options 被隐藏Settings About phone点击Build number7 次开启 USB 调试后需进行额外设置Stay AwakeOnVerify apps over USBOff文档提醒 Android 4.2 需要此项取消浏览器 startup/setupGoogle 浏览器打开后选择No thanks设置系统时间为 12 小时制Settings System Date time Use 24-hour format Off使用 USB 线连接 PC 与设备当弹出“是否接受一个 RSA Key”对话框选择允许 USB debugging5. 网络环境要求GTS 测试需要一个“可访问 Google 服务器”的代理 Wi‑Fi并保证能访问 Google 服务器没有任何限制文档表述为没有限制6. 测试方法6.1 单机测试Single Device单机流程可参考下图PC/Linux 端准备 → 解压测试包 → tradefed 执行 → 输出 results/logs 用于定位。命令步骤PC 端命令行窗口查看设备adb devices进入解压后的 GTS 测试包并执行cdandroid-gts/tools ./gts-tradefed run gts# 整体测试run gts-mModuleName# 测试某个 module 的所有 Caserun gts-mModuleName-tTestCaseName# 测试某个 module 中指定 Case6.2 分布式测试Distributed / Sharding分布式测试把测试任务分发到多个待测设备并行执行从而缩短整体测试时间。示例3 台设备cdandroid-gts/tools ./gts-tradefed run gts --shard-count3--shard-count对应待测设备数。6.3 Token sharding 指令测试Android 10Token sharding 目标自动把“需要特殊设置的测试”匹配到“支持的设备”避免为所有设备配备 SIM支持 Android 10 及以上版本支持第一次测试与 retryToken sharding 原理图执行前文档要求先启用命令能力run gts --enable-token-sharding...other flags...若待测设备不支持 Modem 功能则无需使用 Token sharding 指令测试。7. 测试问题分析以testValidSysConfigPresent为例当某些测试项失败时文档建议按“results → host log → device logcat → 进一步分析/修复 → 重测”的顺序定位。7.1 分析resultstest_result.html结果文件示例results/date_time/test_result.html在页面中重点关注Summary查看Suite/Build判断 GTS 版本号是否正确与Tests Failed失败项数量Details查看失败原因常见如缺少 YouTube Music 等应用7.2 分析 host log若结果文件没有足够信息需要进一步查看 host 日志logs/date_time/inv_.../host_log_....txthost log 往往包含执行了哪些 apk、失败原因、以及测试项执行流程。7.3 分析 device log按 PID 关键字若 host log 仍无法准确定位查看 device logcat 文件logs/date_time/inv_.../device_logcat_test_serial_pid.txt做法用 PID测试 apk 进程编号与TestRunner关键字搜索观察失败发生前后的输出确认是缺配置、缺应用、还是业务逻辑错误7.4 反汇编/进一步分析非开源场景GTS 非开源文档建议可对相关 apk/jar 做反汇编使用jadx反汇编 apk使用jd反汇编 jar并结合失败用例如com.google.android.os.gts.SysConfigTest.assertSystemConfigEquals/testValidSysConfigPresent推断具体比对逻辑。7.5 修改配置文件并重测修复路径打开partner_gms/etc/sysconfig/google.xml按失败信息补齐缺失应用示例添加 YouTube Music重测直至通过7.6 查找 Google 规范Partner 站点你可以在 Google partner 网站查阅对应规范/要求理解为什么某类测试对缺失应用敏感例如特定配置要求包含 YouTube Music。8. 其他常见失败补充8.1GTS Business Logic失败业务逻辑/远程配置类推荐定位顺序先检查APE_API_KEY是否设置正确确认项目是否存在APAportal若 portal 正确仍失败错误通常会出现在 error log 中常见包括Unable to execute because authorization failed, please ensure the service account key is properly installed.通常是APE_API_KEY未正确配置或 key 文件本身问题Unable to execute because service account is not authorized to access information for this device...检查 APA portal 中的权限与设备属性配置Cannot connect to business logic service for suite GTS...通常为 Google 服务器连接问题可稍后重试若持续可联系 Google 支持或第三方实验室认证中心文档还提到如反复失败可考虑使用--ignore-business-logic-failure使测试继续执行但依赖远程配置的测试仍可能失败。8.2waiver requests豁免请求若 GTS 测试不通过可尝试使用 preview 包测试preview 测试通过无需提交 waiver requestspreview 测试不通过需要咨询 FAE、第三方实验室认证中心或 Google 是否要提交 waiver requestswaiver 指引参考文档链接Reducing waiver requests / verify-dev-buildshttps://docs.partner.android.com/gms/testing/cts/test-improvement-request-guide?hlen#verify-dev-buildscreate-gtshttps://docs.partner.android.com/gms/testing/cts/test-improvement-request-guide?hlen#create-gts