Ab dem 27. März 2025 empfehlen wir, android-latest-release anstelle von aosp-main zu verwenden, um AOSP zu erstellen und Beiträge dazu zu leisten. Weitere Informationen finden Sie unter Änderungen am AOSP.
CTS von Entwicklern
Mit Sammlungen den Überblick behalten
Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.
Auf dieser Seite werden die Nutzungsrichtlinien für CTS-D (von Entwicklern unterstützte CTS) beschrieben.
Testabdeckung
CTS-D kann wie CTS und CTS Verifier nur Folgendes erzwingen:
- Alle öffentlichen APIs, die im Entwickler-SDK (developer.android.com) für eine bestimmte API-Ebene beschrieben sind.
- Alle MUST-Anforderungen, die im Android Compatibility Definition Document (CDD) für eine bestimmte API-Ebene enthalten sind.
Nicht verbindliche Anforderungen wie „EMPFOHLENE METHODE“, „SOLLTE“ und „KANN“ sind optional und können nicht mit CTS getestet werden.
Da alle APIs und CDD-Anforderungen an eine bestimmte API-Ebene gebunden sind, sind alle CTS-Tests (CTS, CTS-D und CTS Verifier) an dieselbe API-Ebene gebunden wie die zugehörigen APIs oder Anforderungen. Wenn eine bestimmte API eingestellt oder geändert wird, muss der entsprechende Test eingestellt oder aktualisiert werden.
Regeln für die Erstellung von CTS-Tests
- Ein Test muss immer dasselbe objektive Ergebnis liefern.
- Bei einem Test muss festgestellt werden, ob ein Gerät bestanden oder nicht bestanden hat. Dazu muss das Gerät einmal direkt nach dem Auspacken getestet werden.
- Die Tester müssen alle Faktoren entfernen, die sich auf die Testergebnisse auswirken könnten.
- Wenn für ein Gerät eine bestimmte Hardwarekonfiguration oder -umgebung erforderlich ist, muss diese Konfiguration in der Commit-Nachricht klar definiert sein. Eine Beispielanleitung zur Einrichtung finden Sie unter CTS einrichten.
- Der Test darf nicht länger als 6 Stunden am Stück laufen. Wenn der Test länger laufen muss, geben Sie bitte in Ihrem Testvorschlag den Grund dafür an, damit wir ihn prüfen können.
Im Folgenden finden Sie ein Beispiel für Testbedingungen zum Testen einer App-Einschränkung:
- Das WLAN ist stabil (bei einem Test, der auf WLAN basiert).
- Das Gerät bleibt während des Tests stationär (je nach Test).
- Das Gerät ist von der Stromversorgung getrennt und der Akkustand beträgt X %.
- Es werden keine Apps, Dienste im Vordergrund oder Dienste im Hintergrund ausgeführt, mit Ausnahme von CTS.
- Das Display ist während der Ausführung von CTS ausgeschaltet.
- Das Gerät ist KEIN
isLowRamDevice.
- Die Einschränkungen für den Energiesparmodus und Apps wurden nicht geändert.
Voraussetzungen für den Test
Wir akzeptieren neue Tests, die ein Verhalten erzwingen, das nicht durch vorhandene CTS-, CTS Verifier- oder CTS-D-Tests geprüft wird. Alle Tests, bei denen ein Verhalten geprüft wird, das nicht in den Testumfang fällt, werden abgelehnt.
CTS-Einreichungsprozess
- Testvorschlag verfassen: Ein App-Entwickler reicht über den Google Issue Tracker einen Testvorschlag ein, in dem er das erkannte Problem beschreibt und einen Test vorschlägt, um es zu prüfen. Der Vorschlag muss die zugehörige CDD-Anforderungen-ID enthalten.
Das Android-Team prüft den Vorschlag.
- CTS-Test entwickeln:Nachdem ein Vorschlag genehmigt wurde, erstellt der Einreicher einen CTS-Test in AOSP im neuesten Release-Branch von Android (
android16-release). Das Android-Team prüft den Code und wählt die Änderung aus, falls sie akzeptiert wird, und führt sie in den internen Entwicklungszweig ein. Weitere Informationen finden Sie unter Wo sollte ich Änderungen am AOSP vorschlagen?.
CTS-D-Testrichtlinien
- Beachten Sie den Java-Code-Styleguide.
- Führen Sie alle Schritte aus, die unter CTS-Entwicklung beschrieben sind.
- Fügen Sie Ihre Tests dem entsprechenden Testplan hinzu:
- Fügen Sie mit
include-filters Ihre neuen Tests dem CTS-D-Testplan hinzu: platform/cts/tools/cts-tradefed/res/config/cts-developer.xml.
- Verwenden Sie
exclude-filters, um Ihre neuen Tests aus dem Haupt-CTS-Testplan auszuschließen: platform/cts/tools/cts-tradefed/res/config/cts-developer-exclude.xml.
- Bearbeiten Sie alle
errorprone-Warnungen und build_error.log-Vorschläge.
- Nehmen Sie einen neuen Basiszweig auf
head vor. Dazu gehören die Testpläne cts-developer.xml und cts-developer-exclude.xml.
- Wenden Sie sich an Ihren Google-Entwickler, um festzustellen, ob Ihr Testfall in ein vorhandenes CTS-Modul aufgenommen werden kann. Andernfalls helfen sie Ihnen, ein neues Modul zu erstellen.
- Erstellen Sie für jedes neue Testmodul eine OWNERS-Datei im Verzeichnis des neuen Testmoduls.
- Die OWNERS-Datei sollte die folgenden Informationen enthalten, die Sie von Ihrem Google-Testverantwortlichen erhalten haben:
# Bug component: xxx- Google-Testinhaber ldap
- Geben Sie unter
AndroidTest.xml die folgenden Parameter an. In den Beispieldateien (1, 2) finden Sie Beispiele:
Instant_app oder not_instant_appsecondary_user oder not_secondary_userall_foldable_states oder no_foldable_states
- Informationen zum Angeben der richtigen minSDK finden Sie in der Dokumentation zu <uses-sdk>.
- Wenn Sie neue Testmethoden, ‑klassen oder ‑module einchecken, fügen Sie sie dem CTS-D-Testplan hinzu und schließen Sie sie wie bei neuen Tests aus dem Haupt-CTS-Testplan aus.
CTS-D-Test ausführen
Führen Sie den CTS-D-Testplan über die Befehlszeile mit run cts --plan cts-developer aus.
Verwenden Sie run cts --include-filter "test_module_name test_name", um einen bestimmten Testfall auszuführen.
Informationen zum Ausführen des vollständigen CTS finden Sie unter CTS-Tests ausführen.
Akzeptanz und Freigabe
Nachdem eine Testanfrage eingereicht wurde, prüft ein internes Team, ob damit eine CDD-Anforderung oder ein dokumentiertes API-Verhalten getestet wird. Wenn der Test auf eine gültige Anforderung oder ein gültiges Verhalten prüft, leitet das Team diesen Testfall zur weiteren Überprüfung an einen Google-Entwickler weiter. Der Google-Entwickler wird sich mit Ihnen in Verbindung setzen und Ihnen Feedback dazu geben, wie der Test verbessert werden kann, bevor er in CTS aufgenommen werden kann.
Weitere Informationen zum CTS-Veröffentlichungszeitplan finden Sie unter Veröffentlichungszeitplan und Informationen zu Branches.
Alle Inhalte und Codebeispiele auf dieser Seite unterliegen den Lizenzen wie im Abschnitt Inhaltslizenz beschrieben. Java und OpenJDK sind Marken oder eingetragene Marken von Oracle und/oder seinen Tochtergesellschaften.
Zuletzt aktualisiert: 2025-07-27 (UTC).
[[["Leicht verständlich","easyToUnderstand","thumb-up"],["Mein Problem wurde gelöst","solvedMyProblem","thumb-up"],["Sonstiges","otherUp","thumb-up"]],[["Benötigte Informationen nicht gefunden","missingTheInformationINeed","thumb-down"],["Zu umständlich/zu viele Schritte","tooComplicatedTooManySteps","thumb-down"],["Nicht mehr aktuell","outOfDate","thumb-down"],["Problem mit der Übersetzung","translationIssue","thumb-down"],["Problem mit Beispielen/Code","samplesCodeIssue","thumb-down"],["Sonstiges","otherDown","thumb-down"]],["Zuletzt aktualisiert: 2025-07-27 (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."]]
