自 2025 年 3 月 27 日起，我們建議您使用 android-latest-release 而非 aosp-main 建構及貢獻 AOSP。詳情請參閱「Android 開放原始碼計畫變更」。
開發人員推動的 CTS
透過集合功能整理內容
你可以依據偏好儲存及分類內容。
本頁面概略說明開發人員輔助 CTS (CTS-D) 的使用指南。
測試涵蓋率
與 CTS 和 CTS 驗證工具一樣，CTS-D 只能強制執行下列項目：
- 針對特定 API 級別，在開發人員 SDK (developer.android.com) 中說明的所有公用 API。
- 針對特定 API 級別，Android 相容性定義說明文件 (CDD) 中列出的所有必要規定。
非必要規定 (例如強烈建議、應、可) 為選用規定，無法使用 CTS 進行測試。
由於所有 API 和 CDD 規定都與特定 API 級別綁定，因此所有 CTS 測試 (CTS、CTS-D 和 CTS Verifier) 都會與相關聯的 API 或規定綁定至相同的 API 級別。如果特定 API 已淘汰或變更，則必須淘汰或更新相應的測試。
CTS 測試建立規則
- 測試必須一再產生相同的客觀結果。
- 測試必須透過一次開箱測試，判斷裝置是否通過或失敗。
- 測試建立者必須移除所有可能影響測試結果的因素。
- 如果裝置需要特定的硬體條件/環境/設定，則必須在提交訊息中明確定義該設定。如需設定操作說明的範例，請參閱「設定 CTS」。
- 每次測試時間不得超過 6 小時。如果需要更長的時間執行，請在測試提案中附上原因，以便我們審查。
以下是測試應用程式限制的一組測試條件範例：
- Wi-Fi 穩定 (適用於依賴 Wi-Fi 的測試)。
- 裝置在測試期間保持靜止 (視測試而定)。
- 裝置已拔除電源線，電池電量為 X 個百分比。
- 除了 CTS 之外，沒有任何應用程式、前景服務或背景服務正在執行。
- 執行 CTS 時，螢幕會關閉。
- 裝置不是
isLowRamDevice。
- 省電模式 / 應用程式限制未從「開箱即用」狀態變更。
測試資格
我們接受新測試，這些測試會強制執行現有 CTS、CTS Verifier 或 CTS-D 測試未測試的行為。任何檢查 測試涵蓋範圍以外行為的測試都會遭到拒絕。
CTS 提交程序
- 撰寫測試提案：應用程式開發人員使用 Google Issue Tracker 提交測試提案，說明已識別的問題，並提出測試以檢查該問題。提案必須包含相關的 CDD 需求 ID。Android 團隊會審查提案。
- 開發 CTS 測試：提案獲得核准後，提交者會在 Android 最新版本分支 (
android16-release) 的 Android 開放原始碼計畫中建立 CTS 測試。Android 團隊會審查程式碼，如果接受，就會挑選變更並合併至內部開發分支。詳情請參閱「我該向 AOSP 提議哪些變更？」。
CTS-D 測試作文指南
- 請遵循 Java 程式碼樣式指南。
- 按照「CTS 開發」一文所述的步驟操作。
- 將測試新增至適當的測試計畫：
- 使用
include-filters 將新測試加入 CTS-D 測試計畫：platform/cts/tools/cts-tradefed/res/config/cts-developer.xml。
- 使用
exclude-filters 將新測試排除在主要 CTS 測試計畫之外：platform/cts/tools/cts-tradefed/res/config/cts-developer-exclude.xml。
- 在
build_error.log 中處理所有 errorprone 警告和建議。
- 將變更重新接至
head。包括 cts-developer.xml 和 cts-developer-exclude.xml 測試計畫。
- 請與 Google 工程聯絡窗口合作，判斷您的測試案例是否可納入現有的 CTS 模組。如果無法，他們會協助您建立新模組。
- 針對每個建立的新測試模組，請在新測試模組目錄中建立 OWNERS 檔案。
- OWNERS 檔案應包含下列資訊，這些資訊可從您合作的 Google 測試人員取得：
# Bug component: xxx- Google 測試擁有者 LDAP
- 在
AndroidTest.xml 中指定下列參數。請參閱範例檔案 (1、2) 瞭解示例：
Instant_app 或 not_instant_appsecondary_user 或 not_secondary_userall_foldable_states 或 no_foldable_states
- 如要指定正確的 minSDK，請參閱 <uses-sdk> 說明文件。
- 當您提交新的測試方法、類別或模組時，請將這些項目新增至 CTS-D 測試計畫，並以與新測試相同的方式，將這些項目從主要 CTS 測試計畫中排除。
執行 CTS-D 測試
使用 run cts --plan cts-developer 從指令列執行 CTS-D 測試計畫。
如要執行特定測試案例，請使用 run cts --include-filter "test_module_name test_name"。
如要瞭解如何執行完整的 CTS，請參閱「執行 CTS 測試」。
接受和發布
提交測試要求後，內部團隊會審查該要求，確保測試的是 CDD 規定或已記錄的 API 行為。如果系統判定測試是檢查有效的規範或行為，團隊會將此測試案例轉交給 Google 工程師進一步審查。Google 工程師會與您聯絡，提供意見回饋，說明如何改善測試，以便接受 CTS 認證。
如要進一步瞭解 CTS 發布時程，請參閱發布時程和分支資訊。
這個頁面中的內容和程式碼範例均受《內容授權》中的授權所規範。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,["# Developer-Powered CTS\n\nThis page outlines the usage guidelines for Developer-Powered CTS (CTS-D).\n\nTest coverage\n-------------\n\nCTS-D, like CTS \\& CTS Verifier, can only enforce the following:\n\n- All public APIs that are described in the developer SDK (developer.android.com) for a certain API level.\n- All MUST requirements that are included in the Android Compatibility Definition Document (CDD) for a certain API level.\n\nNon-MUST requirements, such as STRONGLY RECOMMENDED, SHOULD, MAY, are optional\nand can't be tested using CTS.\n\nBecause all APIs and CDD requirements are tied to a specific API level, all CTS\ntests (CTS, CTS-D, and CTS Verifier) are tied to the same API level as their\nassociated APIs or requirements. If a specific API is deprecated or changed,\nits corresponding test must be deprecated or updated.\n\nCTS test creation rules\n-----------------------\n\n- A test must produce the same objective result consistently.\n- A test must determine whether a device passes or fails by testing that device one time out of the box.\n- Test creators must remove all possible factors that could affect test results.\n- If a device needs a certain hardware condition/environment/setup, that setup must be clearly defined in the commit message. For example setup instructions, see [Setting Up CTS](/docs/compatibility/cts/setup).\n- The test must not run for more than 6 hours at a time. If it needs to run for longer, please include the reasoning in your test proposal so that we can review it.\n\nThe following is an example set of test conditions for testing an app\nrestriction:\n\n- Wifi is stable (for a test that relies on Wifi).\n- The device remains stationary during the test (or not, depending on the test).\n- The device is unplugged from any power source with X percent of battery level.\n- No apps, foreground services, or background services are running, except for CTS.\n- The screen is off while running CTS.\n- The device is NOT `isLowRamDevice`.\n- Battery saver / app restrictions have not been changed from the \"out-of-the-box\" state.\n\n### Test eligibility\n\nWe accept new tests that enforce a behavior that isn't tested by existing CTS,\nCTS Verifier, or CTS-D tests. Any test that checks a behavior outside the scope\nof [our test coverage](#coverage) will be rejected.\n\nCTS submission process\n----------------------\n\n1. **Write a test proposal:** An app developer submits a test proposal using [Google Issue Tracker](https://issuetracker.google.com/issues/new?component=1124973&template=1633344), describing the issue that has been identified and proposing a test to check for it. The proposal must include the associated [CDD requirement ID](/docs/compatibility/cts/development#annotation). The Android team reviews the proposal.\n2. **Develop a CTS test:** After a proposal is approved, its submitter creates a CTS test on AOSP on the Android latest release branch (`android16-release`). The Android team reviews the code and if accepted, cherrypicks the change and merges it into the internal development branch. For details, see [Where should I propose changes to AOSP?](/docs/setup/about/faqs#changes-aosp).\n\nCTS-D test writing guidelines\n-----------------------------\n\n- Follow the [Java Code Style Guide](/docs/setup/contribute/code-style).\n- Follow all the steps described in [CTS Development](/docs/compatibility/cts/development).\n- Add your tests to the appropriate test plan:\n - Use `include-filters` to add your new tests to the CTS-D test plan: `platform/cts/tools/cts-tradefed/res/config/cts-developer.xml`.\n - Use `exclude-filters` to exclude your new tests from the main CTS test plan: `platform/cts/tools/cts-tradefed/res/config/cts-developer-exclude.xml`.\n- Handle all `errorprone` warnings and suggestions in `build_error.log`.\n- Rebase your changes to `head`. This includes the `cts-developer.xml` and `cts-developer-exclude.xml` test plans.\n- Work with your Google engineering contact to determine whether your test case can be included in an existing CTS module. If it can't, they'll help you create a new module.\n- For each new test module created, create an OWNERS file in the new test module directory.\n - Your OWNERS file should contain the following information, obtained from the Google test owner you're working with:\n - `# Bug component: xxx`\n - Google test owner ldap\n- In `AndroidTest.xml`, specify the following parameters. Refer to the sample files ([1](https://cs.android.com/android/platform/superproject/+/android-latest-release:cts/tests/sample/), [2](https://cs.android.com/android/platform/superproject/+/android-latest-release:cts/hostsidetests/sample/)) for examples:\n - `Instant_app` or `not_instant_app`\n - `secondary_user` or `not_secondary_user`\n - `all_foldable_states` or `no_foldable_states`\n- To specify the correct minSDK, refer to [the \\\u003cuses-sdk\\\u003e documentation](https://developer.android.com/guide/topics/manifest/uses-sdk-element).\n- When checking in new test methods, classes, or modules, add them to the CTS-D test plan and exclude them from the main CTS test plan in the same way as for new tests.\n\nRun your CTS-D test\n-------------------\n\nRun the CTS-D test plan [from the command line](/docs/compatibility/cts/command-console-v2)\nusing `run cts --plan cts-developer`.\n\nTo run a specific test case, use `run cts --include-filter \"test_module_name test_name\"`.\n\nFor information on running the full CTS, see [Run CTS tests](/docs/compatibility/cts/run).\n\nAcceptance and release\n----------------------\n\nOnce a test request is submitted, an internal team will review it to make sure\nit tests a CDD requirement or a documented API behavior. If the test is\ndetermined to be checking for a valid requirement or behavior, the team\nwill forward this test case to a Google engineer for further review. The Google\nengineer will reach out to you with feedback on how the test can be improved\nbefore it can be accepted into CTS.\n\nSee\n[Release schedule and branch information](/docs/compatibility/cts/development#release-schedule)\nfor details on the CTS release schedule."]]
