自 2025 年 3 月 27 日起，我们建议您使用 android-latest-release 而非 aosp-main 构建 AOSP 并为其做出贡献。如需了解详情，请参阅 AOSP 的变更。
由开发者提供支持的 CTS
使用集合让一切井井有条
根据您的偏好保存内容并对其进行分类。
本页面将介绍由开发者提供支持的 CTS (CTS-D) 的使用指南。
测试覆盖率
与 CTS 和 CTS 验证程序相似，CTS-D 只能强制执行以下各项：
- 开发者 SDK (developer.android.com) 中描述的适用于特定 API 级别的所有公共 API。
- 针对特定 API 级别的 Android 兼容性定义文档 (CDD) 中包含的所有强制性要求。
非强制性要求（例如：强烈建议、应该、可以）是可选要求，无法使用 CTS 进行测试。
由于所有 API 和 CDD 要求都与特定 API 级别相关联，因此所有 CTS 测试（CTS、CTS-D 和 CTS 验证程序）都会关联到与其关联的 API 或要求相同的 API 级别。如果特定 API 被废弃或更改，其相应的测试必须废弃或更新。
CTS 测试创建规则
- 测试必须一致地产生相同的目标结果。
- 测试必须通过对设备进行一次开箱测试来确定设备是合格还是不合格。
- 测试创建者必须去除可能会影响测试结果的所有可能因素。
- 如果设备需要特定的硬件条件/环境/设置，则必须在提交消息中明确定义相应设置。如需查看示例设置说明，请参阅设置 CTS。
- 测试的每次运行时长不能超过 6 小时。如果需要运行更长时间，请在测试方案中附上原因，以便我们进行审核。
以下是一组用于测试应用限制的测试条件示例：
- Wi-Fi 连接稳定（适用于依赖 Wi-Fi 的测试）。
- 设备在测试期间保持静止状态（或不保持静止，具体取决于测试）。
- 在设备电池电量为百分之 X 时将设备从任意电源中拔出。
- 除 CTS 之外，不运行任何应用、前台服务或后台服务。
- 运行 CTS 时屏幕处于关闭状态。
- 设备并非
isLowRamDevice。
- 未从“开箱”状态更改省电模式/应用限制
测试资格条件
我们接受符合以下条件的新测试：会强制执行现有 CTS、CTS 验证程序或 CTS-D 测试未测试的行为。任何会检查不在我们的测试覆盖率范围之内行为的测试都会被拒绝。
CTS 提交流程
- 编写测试方案：应用开发者要使用 Google 问题跟踪器提交测试方案，在方案中说明已发现的问题并建议通过测试来检查问题。方案必须包含关联的 CDD 要求 ID。Android 团队会审核方案。
- 制定 CTS 测试：方案获得批准后，其提交者会在 AOSP 上的主要 (AOSP/main) 分支上创建 CTS 测试。Android 团队会审核该代码。
- 发布测试：在
AOSP/main 上提交您的 CL，然后为最新的 androidx-tests-dev 分支择优挑选您的 CL。该测试现已公开发布。
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 警告和建议。
- 将您的更改 rebase 到
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 和/或其关联公司的注册商标。
最后更新时间 (UTC)：2025-05-08。
[[["易于理解","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"]],["最后更新时间 (UTC)：2025-05-08。"],[],[],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."]]
