2025 年 3 月 27 日より、AOSP のビルドとコントリビューションには aosp-main ではなく android-latest-release を使用することをおすすめします。詳細については、AOSP の変更をご覧ください。
Developer-Powered CTS
コレクションでコンテンツを整理
必要に応じて、コンテンツの保存と分類を行います。
このページでは、Developer-Powered CTS（CTS-D）の使用ガイドラインについて概説します。
テスト カバレッジ
CTS-D は、CTS や CTS 検証ツールと同様に、以下にのみ適用できます。
- 特定の API レベル向けのデベロッパー SDK（developer.android.com）に記載されているすべての公開 API。
- 特定の API レベル向けの Android 互換性定義ドキュメント（CDD）に含まれているすべての「しなければならない」要件。
「強く推奨される」、「するものとする」、「してもよい」といった、「しなければならない」以外の要件は省略可能であるため、CTS を使ってテストすることはできません。
すべての API と CDD の要件は特定の API レベルに関連付けられているため、CTS テスト（CTS、CTS-D、CTS 検証ツール）はすべて、関連付けられている API または要件と同じ API レベルに関連付けられます。特定の API がサポート終了となったり変更されたりした場合は、対応するテストもサポート終了または更新しなければなりません。
CTS テスト作成ルール
- テストは、目標とする同じ結果が一貫して出るものでなければなりません。
- テストは、初期状態でデバイスを 1 回テストすることにより、そのデバイスが合格か不合格かを判断するものでなければなりません。
- テストの作成者は、テスト結果に影響を与える可能性のある要因をすべて取り除かなければなりません。
- デバイスに特定のハードウェア条件 / 環境 / 設定が必要な場合は、コミット メッセージでその設定を明確に定義しなければなりません。設定手順の例については、CTS のセットアップについての説明をご覧ください。
- テストは一度に 6 時間を超えて実行してはなりません。実行時間の延長が必要な場合は、Google で審査できるようテストプランにその理由の説明を含めてください。
以下に、アプリの制限をテストするためのテスト条件セットの例を示します。
- Wi-Fi が安定している（Wi-Fi を使用するテストの場合）。
- デバイスがテスト中に静止している（または、テストによっては、静止していない）。
- デバイスはバッテリー残量が X% の状態で電源から外されている。
- アプリ、フォアグラウンド サービス、バックグラウンド サービスが実行されていない（CTS を除く）。
- CTS の実行中は画面がオフになる。
- デバイスが
isLowRamDevice ではない。
- バッテリー セーバー / アプリの制限が「初期状態」から変更されていない。
テストの資格要件
Google は、既存の CTS、CTS 検証ツール、CTS-D のテストではテストされていない動作に適用される新しいテストを承認しています。テスト対象の動作がテスト カバレッジの範囲外であるテストは承認されません。
CTS 提出手続き
- テストプランを作成する: アプリ デベロッパーは、Google Issue Tracker を使用してテストプランを提出し、特定された問題を説明して、その問題を調べるためのテストを提案します。関連付けられた CDD の要件 ID を必ずプランに記載してください。Android チームがプランを審査します。
- CTS テストを作成する: プランが承認されると、プランの提出者がメイン（AOSP / メイン）ブランチの AOSP で CTS テストを作成します。Android チームがコードを審査します。
- テストを公開する:
AOSP/main で CL を提出し、最新の androidx-tests-dev ブランチにチェリーピックします。これでテストは一般公開されます。
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 エンジニアに転送し、さらに審査します。テストが CTS として承認される前に、Google エンジニアからテストの改善点についてフィードバックがあります。
CTS のリリース スケジュールについて詳しくは、リリース スケジュールとブランチ情報をご覧ください。
このページのコンテンツやコードサンプルは、コンテンツ ライセンスに記載のライセンスに従います。Java および OpenJDK は Oracle および関連会社の商標または登録商標です。
最終更新日 2025-05-08 UTC。
[[["わかりやすい","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-05-08 UTC。"],[],[],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."]]
