自 2025 年 3 月 27 日起，我們建議您使用 android-latest-release 而非 aosp-main 建構及貢獻 AOSP。詳情請參閱「Android 開放原始碼計畫變更」。
CTS 常見問題
透過集合功能整理內容
你可以依據偏好儲存及分類內容。
Android 相容性計畫是維持 Android 生態系統正面回饋的重要推手。CTS 是確保大規模相容性品質的重要工具。Android 團隊會持續改善 CTS 工具和測試涵蓋率。定期新增測試案例，可大幅改善相容裝置的品質。
一般問題
本節提供一般 CTS 常見問題。
CTS 會測試哪些項目？
CTS 會測試所有支援的 Android 強型別 API 是否存在且運作正常。CTS 也會測試其他非 API 系統行為，例如應用程式生命週期和效能。
CTS 的授權方式為何？
CTS 的授權條款與 Android 大部分使用的 Apache 軟體授權 2.0 版相同。
編碼器是否經過 CTS 驗證？
可以。CTS 會驗證所有必要的編解碼。
測驗專屬問題
本節提供常見問題，協助您更有效率地執行 CTS 測試。
CTS 區塊與 TF 區塊有何差異？
CTS 區塊和 TF 區塊是完全不同的測試計畫，由不同的測試基礎架構程式碼集提供支援。雖然不同版本的執行指令相同，但分割結果的行為有所不同。CTS 分割功能會將測試案例靜態指派給測試中的裝置 (DUT)，如下所示：
TF 區塊功能會動態將測試案例指派給可用的 DUT，如下所示：
支援多個 ABI 的裝置應具備哪些功能？
裝置必須針對聲稱支援的每種 ABI 模式，通過所有 CTS 和 CTS Verifier 測試。因此，您必須為特定 ABI 執行應用程式。針對多個 ABI 的規範如下：
- 針對 CTS 和 CTS 驗證工具，每個架構都有 ARM 和 x86 版本。每個版本都能支援 32 位元或 64 位元模式。
- 針對 CTS 測試，如果裝置同時支援 ARM 和 x86，則必須分別執行並通過 ARM 和 x86 CTS 測試。
請參閱 CDD 3.3.1。應用程式二進位檔介面：ABI 的 CDD 規定。
是否只要針對主要 ABI (例如 64 位元) 執行測試，即可縮短測試執行時間？
否。Android 應用程式會在其專屬的 32 位元或 64 位元執行階段中執行。實際的機器碼、程式碼路徑和狀態會因 32 和 64 而異。如果您略過其中一個模式，就只涵蓋了 50% 的裝置 ABI。
為什麼有這麼多測試案例回報為「未執行」？
請檢查「Module Done」數字，而非「Not Executed」數字。
在先前版本中，CTS 模組在完成前會過度頻繁地回報為「Module Done」。因此，即使某些裝置發生問題，系統仍會回報 Modules Done 數字，而非所有測試案例都已完成。新的測試裝載元件較為保守，在發生問題時會回報較多的「未執行」測試。
模組執行至完成時，在下列情況下，報表會在最近一次叫用 (done="false") 中回報「Module Not Done」：
如要取得這些模組的 Module Done 狀態 (done="true")，請針對最近一次叫用重試以下操作：
run retry --retry <session_id> for Android 9 and later versions
run cts --retry <session_id> for Android 8.1 and previous versions
如果執行的模組沒有任何先前提到的問題 (即使剩餘測試為 0)，新報表中會標示「Module Done」。
例外狀況
- 由於 Linux/OS 的 args 限制，CtsNNAPITestCases 有已知問題。您可以直接透過
run cts -m
CtsNNAPITestCases 重新執行模組。
如何避免在公司防火牆後方進行測試準備時失敗？
所有自動化測試套件都會在執行階段嘗試下載 CTS 媒體檔案或業務邏輯檔案。在許多企業環境中，防火牆和 Proxy 通常會導致測試準備作業失敗。執行下列指令行或將其新增至 .profile (在 Ubuntu 上)。
export JAVA_TOOL_OPTIONS='-Djava.net.useSystemProxies=true'
我是否需要使用 SIM 卡才能進行 CTS for Secure Element 測試？
測試是否需要 SIM 卡取決於您是否瞭解測試裝置是否支援這項功能。
- 如果裝置不需要支援 Android 應用程式存取安全元件 (無論是透過行動網路業者分發的 UICC (例如 SIM 卡)，或是嵌入裝置)，您可以設定 HIDL 資訊清單，不納入
android.hardware.secure_element HAL 元素。在這種情況下，android.se.omapi.SEService.getReaders() API 會回報空白清單，CTS 測試會自動通過並回報 CTS 通過的結果。
- 如果裝置需要支援 Android 應用程式存取安全元素 (可在行動網路業者 (電信業者) 發行的 UICC (例如 SIM 卡) 中，或在裝置中嵌入)，您就必須正確實作安全元素，並在內部測試。「安全元件的 CTS 測試」一文概略說明如何準備執行 CTS 測試，確保在 Android 9 中新增的 android.se.omapi API 套件可正常運作。由於 CTS 測試涵蓋的範圍很小，因此我們也建議您自行進行額外測試。
哪裡可以取得安全元件 CTS 的 SIM 卡？
你可以聯絡你偏好的 SIM 卡供應商。
為什麼在使用權杖分割功能執行 CTS 時，鎖定畫面會顯示 Orange SIM？
測試 SIM 卡是否已鎖定，因此測試案例不會開始。在執行具備符記分割功能的 CTS 之前，請先停用 SIM 卡鎖定設定中的「鎖定 SIM 卡」。
這個頁面中的內容和程式碼範例均受《內容授權》中的授權所規範。Java 與 OpenJDK 是 Oracle 和/或其關係企業的商標或註冊商標。
上次更新時間：2025-07-27 (世界標準時間)。
[[["容易理解","easyToUnderstand","thumb-up"],["確實解決了我的問題","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["缺少我需要的資訊","missingTheInformationINeed","thumb-down"],["過於複雜/步驟過多","tooComplicatedTooManySteps","thumb-down"],["過時","outOfDate","thumb-down"],["翻譯問題","translationIssue","thumb-down"],["示例/程式碼問題","samplesCodeIssue","thumb-down"],["其他","otherDown","thumb-down"]],["上次更新時間：2025-07-27 (世界標準時間)。"],[],[],null,["# CTS FAQ\n\nThe [Android Compatibility Program](/docs/compatibility/cts)\nis the key driver to sustain the positive feedback for Android ecosystem. CTS\nis the key tool to ensure the quality of compatibility in the scale. The\nAndroid team continues to improve CTS tool and test coverage. The regular\naddition of test cases has significant improvement on the quality of\ncompatible devices.\n\nGeneral questions\n-----------------\n\nThis section provides general CTS FAQs.\n\n### What kinds of things does the CTS test?\n\nThe CTS tests that all of the supported Android strong-typed APIs\nare present and behave correctly. The CTS also tests other non-API system\nbehaviors such as app lifecycle and performance.\n\n### How is the CTS licensed?\n\nThe CTS is licensed under the same Apache Software License 2.0 that the\nbulk of Android uses.\n\n### Are codecs verified by CTS?\n\nYes. All mandatory codecs are verified by CTS.\n\nTest-specific questions\n-----------------------\n\nThis section provides FAQs that help run CTS tests more efficiently.\n\n### What is the difference between CTS Sharding and TF Sharding?\n\nCTS Sharding and TF Sharding are totally different test plans powered by\ndifferent test infrastructure codebase. While the run command is the\nsame across different versions, the sharding result behaves differently.\nCTS Sharding statically assigns test cases to Devices Under Test (DUTs)\nas follows:\n\n- Command: run cts\n- Configuration for Android 8.1 and lower versions: [/tools/cts-tradefed/res/config/cts.xml](https://android.googlesource.com/platform/cts/+/oreo-cts-dev/tools/cts-tradefed/res/config/cts.xml)\n\nTF Sharding dynamically assigns test cases to available DUTs as follows:\n\n- Command: run cts\n- Configuration for Android 9: [/platform/test/suite_harness/+/pie-cts-dev/tools/cts-tradefed/res/config/cts-suite.xml](https://android.googlesource.com/platform/test/suite_harness/+/pie-cts-dev/tools/cts-tradefed/res/config/cts-suite.xml)\n\n### What is expected from a device supporting multiple ABIs?\n\nThe device has to pass all CTS and CTS Verifier tests for each ABI mode it\nclaims to support. Therefore, it is necessary to execute an app for the\nparticular ABIs. The guidelines for multiple ABIs are as follows:\n\n- For CTS and CTS Verifier, there are [ARM and x86 releases](/compatibility/cts/downloads) for each architecture. Each of them can support to 32- or 64-bit mode.\n- For CTS tests, if a device supports both ARM and x86, it has to run and pass both ARM and x86 CTS tests respectively.\n\nSee [CDD 3.3.1. Application Binary Interfaces](/compatibility/android-cdd#331_application_binary_interfaces)\nfor CDD requirements on ABI.\n\n### Is it sufficient to run a test only on the primary ABI (for example, 64 bits) to reduce test execution time?\n\n**No.** An Android app runs on its own 32 -bit or 64-bit runtimes.\nThe actual machine code, code path, and state are different\nbetween 32 and 64. If you skip one mode, you are only covering 50% of\nthe device ABI.\n\n### Why are there so many test cases reported as Not Executed?\n\nYou should check the **Module Done** number instead\nof **Not Executed** number.\n\nIn the previous versions, CTS modules were reported as **Module Done** too\naggressively before being completed. Therefore, a **Modules Done** number\nwas reported without all the test case complete even when some devices\nhad problems. The new test harness is more conservative and reports a\nhigher number of **Not Executed** tests when a problem occurs.\n\nA module run to completion reports **Module Not Done** in the most\nrecent invocation (done=\"false\") in the report during the following:\n\n- A test run for the module was interrupted by a device connection issue.\n- Not all expected test runs for the module were performed.\n- Retried (using option `-r/--retry`) with additional filtering options,\n such as:\n\n - --include-filter\n - --exclude-filter\n - -t/--test (Option not yet supported on retry)\n - --retry-type failed\n - --subplan\n\nTo obtain a status of **Module Done** (done=\"true\") for these modules,\nretry the following for the most recent invocation: \n\n run retry --retry \u003csession_id\u003e for Android 9 and later versions\n\n run cts --retry \u003csession_id\u003e for Android 8.1 and previous versions\n\nA module executed without any of the problems mentioned previously (even\nwith 0 remaining tests) is marked **Module Done** in the new report.\n\n#### Exceptions\n\n- CtsNNAPITestCases has a known issue due to linux/OS limitation of args. The module can be rerun in isolation through `run cts -m\n CtsNNAPITestCases` directly.\n\n### How can I avoid test preparation failing behind corporate firewall?\n\nAll automated test suites try to download either the CTS media files or the\nbusiness logic files during runtime. In many corporate environments, a\nfirewall and proxy is typical, which makes the test preparation fail. Execute\nthe following line or add it to .profile (on Ubuntu). \n\n export JAVA_TOOL_OPTIONS='-Djava.net.useSystemProxies=true'\n\n### Do I need a SIM card for CTS for Secure Element?\n\nWhether a SIM card is needed for the test depends on the understanding\nif the feature is supported in the test device.\n\n- If your device **DOES NOT** need to support the Android apps accessing secure elements---either in the [UICC](https://en.wikipedia.org/wiki/Universal_integrated_circuit_card) (e.g., a SIM card) distributed by the mobile network operators (carriers) or embedded in the device---you can configure the HIDL manifest to not include the `android.hardware.secure_element` HAL element. In this case, the [android.se.omapi.SEService.getReaders()](https://developer.android.com/reference/android/se/omapi/SEService.html#getReaders()) API reports an empty list and the CTS test automatically passes and reports a pass for the CTS.\n- If your device **DOES** need to support Android apps accessing either secure elements---either in the [UICC](https://en.wikipedia.org/wiki/Universal_integrated_circuit_card) (e.g., a SIM card) distributed by the mobile network operators (carriers) or embedded in the device---you need to implement secure element properly and test it in-house. [CTS Test for Secure Element](/compatibility/cts/secure-element) outlines how to prepare to run the CTS tests that ensure [android.se.omapi](https://developer.android.com/reference/android/se/omapi/package-summary) API package added in Android 9 is functional. We also recommend performing additional testing on your own since the CTS test coverage is minimal.\n\n### Where can I get the SIM cards for CTS for Secure Element?\n\nYou can reach out to your preferred SIM vendor.\n\n### Why is Orange SIM on the lock screen during CTS execution with token sharding?\n\nThe test case doesn't start because testing the SIM card is locked.\nDisable the **Lock SIM card** in \\*\\*SIM card lock settings before\nexecuting the CTS with token sharding."]]
