1. 什么是 CTS為什么它是出海必修課CTSCompatibility Test Suite是 Android 兼容性測試套件。對希望接入 GMS 生態(tài)的設(shè)備手機、平板等來說CTS 是基礎(chǔ)門檻之一通過 CTS意味著設(shè)備行為與 Android 兼容性要求對齊標準 Android 應用在該設(shè)備上的運行一致性更高。從出海項目視角看CTS 的價值主要體現(xiàn)在三點降低應用兼容性風險減少上線后的區(qū)域性故障。為 GMS 認證鏈路提供關(guān)鍵測試憑證。在多機型并行開發(fā)時建立統(tǒng)一的質(zhì)量基線。2. 物理測試環(huán)境先把“外部條件”搭對很多 CTS 失敗并非代碼問題而是環(huán)境不滿足測試前提。建議優(yōu)先把物理環(huán)境一次性搭齊。2.1 Bluetooth LE若設(shè)備支持 BLE執(zhí)行 BLE scan 相關(guān)測試時設(shè)備周邊約 5 米范圍內(nèi)建議至少放置 3 個 Beacon。2.2 CameraCamera 測試建議在正常照明下進行并準備測試圖表如棋盤格。若設(shè)備支持外置攝像頭能力測試時需接入外置 Camera否則相關(guān)用例可能失敗。2.3 GPS/GNSS若設(shè)備支持 GPS/GNSS需提供符合要求的信號源如衛(wèi)星模擬器、轉(zhuǎn)發(fā)器或足夠良好的室外信號條件。2.4 Wi-Fi 與 IPv6推薦使用支持 IPv4/IPv6、DNS、組播能力的 Wi-Fi 網(wǎng)絡并可訪問互聯(lián)網(wǎng)。若現(xiàn)場無法直接提供 IPv6可通過可用的 IPv6 VPN 補齊部分能力。2.5 Wi-Fi RTTAndroid 9建議準備可用于 RTT 場景的 AP設(shè)備與 AP 距離建議在 12 米內(nèi)。RTT 場景下 AP 供電開啟即可不強制要求連網(wǎng)。3. 測試設(shè)備配置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 相關(guān)文件可能觸發(fā)動態(tài)下載建議提前準備減少首跑時長。3.2 DUT待測設(shè)備配置要點必須使用 User GMS 構(gòu)建版本執(zhí)行 CTS。Android 13 重點關(guān)注 Device ID 與 CSR 部署缺失會導致部分用例失敗。Keybox文檔指出 Android 16 開始不再需要部署。若設(shè)備具備卡槽/外設(shè)能力需按要求插入并激活 SIM/SD 卡必要時準備支持特權(quán)規(guī)則的 Developer UICC。無內(nèi)置屏幕設(shè)備需外接顯示器。3.3 Android 14 輔助設(shè)備建議準備支持 CDP 協(xié)議的 Hub 參與輔助測試。4. 開測前 Checklist把高頻失敗點提前清零建議每輪正式跑測前做一次“5 分鐘體檢”系統(tǒng)語言切換為 English (United States)。打開 Location連接可用 IPv6 Wi-Fi 并聯(lián)網(wǎng)。關(guān)閉鎖屏密碼開啟 USB Debugging 與 Stay Awake。Android 13 設(shè)備開啟 Allow Mock Modem如項目涉及相關(guān) Telephony 測試。USB 連接后確認調(diào)試授權(quán)RSA已允許。媒體能力設(shè)備執(zhí)行copy_media.sh all適用對應 CTS 版本要求。這一步做得細通?？梢燥@著減少“非代碼型失敗”。5. CTS 執(zhí)行策略單機、分布式與精細化運行5.1 單機測試基礎(chǔ)模式cdandroid-cts/tools ./cts-tradefed run cts也可按模塊或單用例精準運行run cts-mModuleNamerun cts-mModuleName-tTestCaseName5.2 分布式測試提速模式多臺設(shè)備并行可顯著縮短總時長例如 3 臺設(shè)備run cts --shard-count36. Token Sharding降低資源門檻的并行測試方案Token Sharding 的核心價值在于“按能力分配任務”將對 SIM/UICC/SE 有特殊依賴的測試項自動匹配到滿足條件的設(shè)備。避免所有設(shè)備都必須插同規(guī)格 SIM 卡降低實驗室準備成本。同時支持首次測試與重試測試retry場景。啟用方式示例run cts --enable-token-sharding...other flags...若設(shè)備不支持 Modem可按文檔建議忽略該模式。7. 測試結(jié)果與日志分析從“跑完”到“可交付”CTS 結(jié)束后重點關(guān)注以下輸出android-cts/results/按時間戳生成結(jié)果目錄及 zip 包。test_result.xml最關(guān)鍵的結(jié)構(gòu)化測試結(jié)果。android-cts/logs/host_log主機側(cè)執(zhí)行日志tradefed/終端輸出。android-cts/logs/device_log設(shè)備側(cè)日志system/main。建議團隊內(nèi)部建立統(tǒng)一歸檔規(guī)范“版本號 設(shè)備型號 構(gòu)建號 測試日期 結(jié)果摘要 問題單鏈接”方便后續(xù)復測與審計。8. CTS-on-GSI、PAB 與調(diào)試閉環(huán)8.1 CTS-on-GSI與常規(guī) CTS 在環(huán)境與前置條件上基本一致。關(guān)鍵差異在鏡像要求命令為run cts-on-gsi8.2 PAB 包策略正式 CTS 版本更新節(jié)奏相對穩(wěn)定短期修復常通過 PAB 包在 Android CI 發(fā)布。若正式版失敗但最新 PAB 驗證通過通?？砂戳鞒烫峤煌ㄟ^報告無需額外豁免以當期認證規(guī)則為準。8.3 Debug 建議路徑對齊到對應 CTS Tag/Branch 代碼后再分析問題。必要時在 CTS 代碼中加日志并重編譯對應 APK。用替換后的測試 APK 做最小復現(xiàn)場景驗證。區(qū)分“平臺問題 / 用例問題 / 環(huán)境問題”再決定是本地修復、cherry-pick 還是向上游提交 patch。9. 一套可復用的出海 CTS 執(zhí)行方法論最后給出一個實踐順序供團隊落地先環(huán)境后跑測先把物理與網(wǎng)絡條件固化。先單機后分布式先驗證基線穩(wěn)定再用分布式提速。先歸因后修復先定位失敗類別再決定修復路徑。先沉淀再復制把每次踩坑轉(zhuǎn)成 Checklist縮短下一機型導入周期。