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.

Diese Seite wurde von der Cloud Translation API übersetzt.

CTS v2-Befehlskonsole
Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

CTS v2-Konsole verwenden

Verwenden Sie für Android 7.0 oder höher CTS v2.

Tarife auswählen

Zu den verfügbaren Testplänen gehören:

cts: Führt CTS aus einer vorhandenen CTS-Installation aus.
cts-camera: Führt CTS-Kamera aus einer vorhandenen CTS-Installation aus.
cts-java: Führt Core Java-Tests aus einer vorhandenen CTS-Installation aus.
cts-pdk: Führt Tests aus, die für die Validierung eines PDK-Fusions-Builds nützlich sind.
everything: Gemeinsame Konfiguration für Kompatibilitätssuiten.

Weitere verfügbare Konfigurationen:

basic-reporters: Konfiguration mit grundlegenden CTS-Meldern.
collect-tests-only: Führt CTS über eine vorhandene CTS-Installation aus.
common-compatibility-config: Gemeinsame Konfiguration für Kompatibilitätssuiten.
cts-filtered-sample: Gemeinsame Konfiguration für Kompatibilitätssuiten.
cts-known-failures: Konfiguration mit bekannten CTS-Fehlern.
cts-preconditions: CTS-Voraussetzungskonfigurationen.
host: Damit wird ein einzelner hostbasierter Test auf einem vorhandenen Gerät ausgeführt.
instrument: Führt einen einzelnen Android-Instrumentierungstest auf einem vorhandenen Gerät aus.
native-benchmark: Führt einen nativen Stresstest auf einem vorhandenen Gerät aus.
native-stress: Führt einen nativen Stresstest auf einem vorhandenen Gerät aus.
recharge: Ein Scheintest, bei dem auf fast entladene Geräte gewartet und sie zum Laden gehalten werden.
testdef: Führt Tests aus, die in test_def.xml-Dateien auf einem vorhandenen Gerät enthalten sind.
util/wifi: Dienstprogrammkonfiguration zum Konfigurieren des WLANs auf dem Gerät.
util/wipe: Löscht die Nutzerdaten auf dem Gerät.

Alle diese Pläne und Konfigurationen können mit dem Befehl run cts ausgeführt werden.

CTS v2-Konsolenbefehlsreferenz

In dieser Tabelle sind die Konsolenbefehle für CTS v2 für verschiedene Anwendungsfälle zusammengefasst.

Host	Beschreibung
`help`	Zusammenfassung der am häufigsten verwendeten Befehle anzeigen
`help all`	Vollständige Liste der verfügbaren Befehle anzeigen
`version`	Version anzeigen
`exit`	Beenden Sie die CTS-Konsole ordnungsgemäß. Die Konsole wird geschlossen, wenn alle derzeit laufenden Tests abgeschlossen sind.
`extdir`	Die gezippte Downloaddatei wird in `extdir` dekomprimiert. Wenn Sie die aufgeblähte Ausgabe entfernen möchten, verwenden Sie die Option `-q`: `unzip -q android-cts-9.0_r15-linux_x86-arm.zip -d extdir` Wenn Sie das Archiv im aktuellen Verzeichnis entpacken möchten, verwenden Sie nicht die Option `-d`, sondern führen Sie einfach Folgendes aus: `unzip -q android-cts-9.0_r15-linux_x86-arm.zip`
Laufen	Beschreibung
`run cts`	Führen Sie unter Android 10 den Standard-CTS-Plan und CTS-Instant zusammen aus (d. h. die vollständige CTS-Aufrufung). Bei Android 9 oder niedriger darf nur der Standard-CTS-Plan ausgeführt werden. Verwenden Sie diese umfassende Option (einschließlich Vorbedingungen) für die Geräteüberprüfung. Informationen zu Einschlüssen finden Sie in cts.xml. Die CTS-Konsole kann während laufender Tests weitere Befehle annehmen. Wenn keine Geräte verbunden sind, wartet der CTS-Desktopcomputer (oder Host) auf eine Verbindung, bevor er mit den Tests beginnt. Wenn mehrere Geräte verbunden sind, wählt der CTS-Host automatisch ein Gerät aus.
`run cts-instant`	Führen Sie für Android 9 den Standard-CTS-Instant-Plan aus.
`run cts --module-parameter INSTANT_APP`	Führen Sie unter Android 10 den Standard-CTS-Instant-Plan aus.
`run cts --module-parameter INSTANT_APP --module/-m test_module_name`	Führen Sie unter Android 10 das oder die angegebenen CTS-Instant-Testmodule aus.
`run retry`	Nur für Android 9 oder höher. Wiederholen Sie alle Tests, die in den vorherigen Sitzungen fehlgeschlagen oder nicht ausgeführt wurden. Beispiel: `run retry --retry -s` oder `run retry --retry --shard-count` mit TF-Sharding. `run cts --retry` ist für Android 9 oder höher nicht zulässig.
`run cts-sim`	Für Android 11 oder höher Führt die Teilmenge der Tests auf einem Gerät mit SIM-Karte aus.
`--device-token`	Für Android 8.1 oder niedriger Gibt an, dass ein bestimmtes Gerät das angegebene Token hat. Beispiel: `--device-token 1a2b3c4d:sim-card`.
`--enable-token-sharding`	Nur für Android 10 oder höher Der Test, für den der jeweilige SIM-Typ erforderlich ist, wird automatisch ausgewählt. Sie müssen keine Geräteseriennummer angeben, um SIM-bezogene Testfälle auszuführen. Unterstützte SIM-Karten: `SIM_CARD`, `UICC_SIM_CARD` und `SECURE_ELEMENT_SIM_CARD`.
`run cts-dev`	Führen Sie den Standard-CTS-Plan (d. h. die vollständige CTS-Aufruf) aus, überspringen Sie aber die Vorbedingungen, um die Ausführungszeit für die iterative Entwicklung eines neuen Tests zu sparen. Dadurch werden die Überprüfung und Einrichtung der Gerätekonfiguration umgangen, z. B. das Pushen von Mediendateien oder die Prüfung der WLAN-Verbindung, wie es bei der Option `--skip-preconditions` der Fall ist. Außerdem werden mit diesem Befehl die Erfassung von Geräteinformationen und alle Systemstatusprüfungen übersprungen. Außerdem werden die Tests nur für ein einziges ABI ausgeführt. Verwenden Sie diese Optimierung nicht für die Geräteüberprüfung und fügen Sie alle Voraussetzungen und Prüfungen hinzu. Ausschlüsse finden Sie in cts-dev.xml. Die CTS-Konsole kann während laufender Tests weitere Befehle annehmen. Wenn keine Geräte verbunden sind, wartet der CTS-Desktopcomputer (oder Host) auf eine Verbindung, bevor die Tests gestartet werden. Wenn mehrere Geräte verbunden sind, wählt der CTS-Host automatisch ein Gerät aus.
`--subplan subplan_name`	Führen Sie den angegebenen untergeordneten Plan aus.
`--module/-m test_module_name --test/-t test_name`	Führen Sie das angegebene Modul und den Test aus. Mit `run cts -m Gesture --test android.gesture.cts.GestureTest#testGetStrokes` wird beispielsweise das jeweilige Paket, die jeweilige Klasse oder der jeweilige Test ausgeführt. Achtung: Verwenden Sie diese Option nicht, wenn Sie die Option `--include-filter` verwenden.
`--retry`	Alle Tests wiederholen, die in den vorherigen Sitzungen fehlgeschlagen oder nicht ausgeführt wurden Verwenden Sie `list results`, um die Sitzungs-ID abzurufen.
`--retry-type NOT_EXECUTED`	Wiederholen Sie nur Tests, die in den vorherigen Sitzungen nicht ausgeführt wurden. Verwenden Sie `list results`, um die Sitzungs-ID abzurufen.
`--shards number_of_shards`	Für Android 8.1 oder niedriger Eine CTS-Ausführung in eine bestimmte Anzahl unabhängiger Chunks aufteilen, um sie parallel auf mehreren Geräten auszuführen.
`--shard-count number_of_shards`	Für Android 9 Eine CTS-Ausführung in eine bestimmte Anzahl unabhängiger Chunks aufteilen, um sie parallel auf mehreren Geräten auszuführen.
`--serial/-s deviceID`	Führen Sie CTS auf dem jeweiligen Gerät aus.
`--include-filter "test_module_name test_name"`	Mit den angegebenen Modulen ausführen oder Pakete, Klassen und Fälle testen. `run cts --include-filter "CtsCalendarcommon2TestCases android.calendarcommon2.cts.Calendarcommon2Test#testStaticLinking"` enthält beispielsweise das angegebene Modul. Diese Befehlsoption wird beim Ausführen eines Wiederholungsversuchs nicht unterstützt. Achtung: Verwenden Sie diese Option nicht, wenn Sie die Option `--module/-m` verwenden.
`--exclude-filter "test_module_name test_name"`	Die angegebenen Module oder Testpakete, ‑klassen und ‑fälle von der Ausführung ausschließen. Mit `run cts --exclude-filter "CtsCalendarcommon2Test android.calendarcommon2.cts.Calendarcommon2Test#testStaticLinking"` wird beispielsweise das angegebene Modul ausgeschlossen.
`--log-level-display/-l log_level`	Wird mit der angegebenen Mindestprotokollebene ausgeführt, die in `STDOUT` angezeigt wird. Gültige Werte: [`VERBOSE`, `DEBUG`, `INFO`, `WARN`, `ERROR`, `ASSERT`].
`--abi abi_name`	Erzwingen, dass der Test mit dem angegebenen ABI (32 oder 64) ausgeführt wird. Standardmäßig führt CTS einmal einen Test für jedes ABI aus, das das Gerät unterstützt.
`--logcat-on-failure`, `--bugreport-on-failure`, `--screenshoot-on-failure`	Sie bieten einen besseren Überblick über Fehler und können bei der Diagnose helfen.
`--device-token`	Gibt an, dass ein bestimmtes Gerät das angegebene Token hat, z. B. `--device-token 1a2b3c4d:sim-card`.
`--skip-device-info`	Die Erfassung von Informationen zum Gerät wird übersprungen. Achtung: Verwenden Sie diese Option nicht, wenn Sie CTS zur Genehmigung ausführen.
`--skip-preconditions`	Vorbedingungen überspringen, um die Ausführungszeit für die iterative Entwicklung eines neuen Tests zu sparen. Dadurch werden die Überprüfung und Einrichtung der Gerätekonfiguration umgangen, z. B. das Pushen von Mediendateien oder die Prüfung der WLAN-Verbindung.
Liste	Beschreibung
`list modules`	Listet alle verfügbaren Testmodule im Repository auf.
`list plans` oder `list configs`	Listet alle verfügbaren Testpläne (Konfigurationen) im Repository auf.
`list subplans`	Listet alle verfügbaren untergeordneten Pläne im Repository auf.
`list invocations`	Listet run-Befehle auf, die derzeit auf Geräten ausgeführt werden.
`list commands`	Listet alle run-Befehle auf, die sich derzeit in der Warteschlange befinden und Geräten zugewiesen werden sollen.
`list results`	Liste der CTS-Ergebnisse, die derzeit im Repository gespeichert sind.
`list devices`	Liste der aktuell verbundenen Geräte und deren Status. Verfügbare Geräte sind funktionsfähige, inaktive Geräte, die für die Durchführung von Tests verfügbar sind. Geräte, die als Nicht verfügbar gekennzeichnet sind, sind über ADB zwar sichtbar, reagieren aber nicht auf ADB-Befehle und werden nicht für Tests zugewiesen. Zugewiesene Geräte sind Geräte, auf denen derzeit Tests ausgeführt werden.
Erfassen	Beschreibung
`dump logs`	Dumpe die Tradefed-Protokolle für alle laufenden Aufrufe.
Hinzufügen	Beschreibung
`add subplan --name/-n subplan_name --result-type [passed \| failed \| not_executed] [--session session_id]`	Erstellen Sie einen Unterplan, der aus der vorherigen Sitzung abgeleitet wird. Mit dieser Option wird ein Unterplan generiert, mit dem eine Teilmenge von Tests ausgeführt werden kann. Die einzige erforderliche Option ist `--session`. Andere sind optional, müssen aber bei Angabe von einem Wert gefolgt sein. Die Option `--result-type` kann wiederholt werden. Beispiel: `add subplan --session 0 --result-type passed --result-type failed` ist gültig.