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縮短下一機型導入周期。