Plattformcode mit „atest“ testen

Android Studio for Platform (ASfP) lässt sich in atest und Soong-Testmodule einbinden, sodass Sie Plattformtests auf Ihrem Linux-Hostcomputer, verbundenen Gerät oder virtuellen Cuttlefish-Gerät über die IDE ausführen und debuggen können.

Vorbereitung

• Öffnen Sie ein ASfP-Projekt, das mit Ihrem AOSP-Checkout und dem lunch-Ziel konfiguriert ist.
• Für Gerätetests müssen Sie ein physisches Gerät anschließen oder ein virtuelles Cuttlefish-Gerät mit einem passenden Build starten.

Tests ausführen und Fehler beheben

Sie können Plattformtests und Debug-Sitzungen an verschiedenen Stellen in ASfP starten:

• Android.bp-Testziele: Öffnen Sie eine Android.bp-Datei und klicken Sie in der Spalte neben einem beliebigen Testmodul (*_test oder *_test_host) auf Ausführen:
  • Ausführen: Verfügbar für alle Soong-Testmodultypen (android_test, java_test_host, cc_test, rust_test, python_test, sh_test und android_robolectric_test).
  • Debuggen: Verfügbar für android_test-Module (die mit dem Java-Debugger über atest --wait-for-debugger angehängt werden) und C++- oder Rust-Testmodule (cc_test, cc_test_host, rust_test und rust_test_host, die mit dem integrierten LLDB-Debugger von ASfP gestartet werden).
• Rinnensymbole für Quelldateien: Klicken Sie neben einer Testklasse oder @Test-Methode in Ihrem Quellcode auf Ausführen, um diesen bestimmten Test auszuführen oder zu debuggen.
• Kontextmenü (Rechtsklick): Klicken Sie mit der rechten Maustaste auf eine Testdatei, ‑klasse, ‑methode oder ein Android.bp-Modul und wählen Sie Ausführen oder Debuggen aus.
• Integrierter Agent (KI in Android Studio): Im Toolfenster Agent kann der integrierte Agent atest-Ziele ausführen, um Änderungen nach der Bearbeitung von Code zu überprüfen.
• Integriertes Terminal: Öffnen Sie Ansicht > Toolfenster > Terminal, um atest-Befehle direkt auszuführen.

Konfiguration und Fehlerbehebung von Smart-Tests

Wenn Sie einen Test über den Gutter oder das Kontextmenü starten, erstellt und konfiguriert ASfP eine Soong-Testkonfiguration mit Ihrem Android.bp-Modulgraphen.

android_test-Java- und Kotlin-Ziele debuggen

Klicken Sie in Android.bp auf das Rinnensymbol neben einem android_test-Modul oder neben einer Java- oder Kotlin-JUnit-Klasse oder einer @Test-Methode und wählen Sie dann Debug '<TestName>' aus. Aus einer Quellcodedatei-Rinne wählt ASfP das nächstgelegene einschließende android_test-Modul aus, dessen srcs die Datei enthält, und benennt die Konfiguration <module>, <module>:<SimpleClass> oder <module>:<SimpleClass>#<method>.

ASfP führt atest mit --wait-for-debugger aus, liest das Zielattribut package aus dem AndroidManifest.xml des Moduls, wartet auf diesen Prozess auf dem verbundenen Gerät und hängt den Java-Debugger an.

Fehler bei cc_test- und rust_test-Zielen mit LLDB beheben

Wenn Sie ein C++- oder Rust-Testmodul (cc_test, cc_test_host, rust_test oder rust_test_host) debuggen möchten, klicken Sie auf das Gutter-Symbol Android.bp und wählen Sie Debug '<TestName>' aus. ASfP führt die kompilierte Testbinärdatei mit dem integrierten LLDB-Debugger aus, anstatt sie über atest auszuführen.

Soong-Testlaufkonfiguration konfigurieren

Öffnen Sie Run > Edit Configurations (Ausführen > Konfigurationen bearbeiten) und wählen Sie eine Soong Test-Konfiguration aus, um anzupassen, wie Tests erstellt, bereitgestellt und gestartet werden:

• Automatische Vervollständigung von Modulen und Android.bp-Navigation: Das Feld Module wird automatisch mit indexierten Soong-Testmodulen in Ihrem Projekt vervollständigt. Klicken Sie neben dem Feld auf Go to Android.bp, um zur Deklaration des Moduls in Android.bp zu springen.
• Ausführen auf: Gerät oder Host (einschließlich host_supported: true): ASfP wertet die Modulregel und die transitive defaults-Kette aus (host_supported, device_supported, enabled, target.android.enabled und target.host.enabled):
  • Tests mit zwei Zielgeräten (cc_test und rust_test mit host_supported: true): Die Optionsfelder Gerät und Host sind beide verfügbar (standardmäßig ist Gerät ausgewählt). Gerät und Host haben jeweils eine eigene unabhängige LLDB-Debuggervorlage. Wenn Sie Ausführen auf zwischen Gerät und Host wechseln, wird zwischen der Konfiguration des Remote-Geräts lldb-server und der Konfiguration der lokalen Host-Binärdatei gewechselt. Anpassungen, die für die einzelnen Ziele vorgenommen wurden, bleiben dabei erhalten.
  • Tests mit einem Ziel: Wenn ein C++- oder Rust-Test nur für eine Umgebung erstellt wird (z. B. nur für ein Gerät cc_test oder nur für einen Host cc_test_host oder rust_test_host), wählt ASfP das unterstützte Ziel aus und deaktiviert das nicht unterstützte Optionsfeld mit einem erklärenden Kurzinfo-Text: „<module> (<ruleType>) doesn't build for the host or device.“.
• Aufgaben vor dem Start (Build Native Test Module und Deploy with atest): Jede Soong Test-Konfiguration enthält standardmäßig zwei Before launch-Aufgaben:
  • Build Native Test Module: Erstellt <module>-target (für Device) oder <module>-host (für Host), bevor LLDB gestartet wird.
  • Mit „atest“ bereitstellen: Beim Debuggen auf Device wird atest <module> --collect-tests-only --disable-teardown -it -s <serial> -- --abi <abi> ausgeführt. Tradefed überträgt also Testabhängigkeiten und führt Zielvorbereitungen aus, bevor LLDB die Binärdatei startet. Bewegen Sie den Mauszeiger auf den Chip Mit Atest bereitstellen, um den genauen atest-Befehl in der Vorschau zu sehen. Wenn die Abhängigkeiten bereits auf dem Gerät vorhanden sind, können Sie die Iteration beschleunigen, indem Sie Mit atest bereitstellen entfernen. So wird nur die Testbinärdatei direkt übertragen. Wenn Sie Ausführen auf: Host auswählen, überspringt ASfP automatisch Mit atest bereitstellen.
• Optionen ändern und Debugger (LLDB-Optionskarten): Mit Optionen ändern können Sie optionale Konfigurationsfelder hinzufügen:
  • Programmargumente (Betriebssystem, nur C++- und Rust-Tests): Zusätzliche Argumente, die beim Debuggen direkt an die Binärdatei cc_test oder rust_test nach dem Filter --gtest_filter oder libtest übergeben werden.
  • atest-Argumente (Test): Zusätzliche Flags, die an atest übergeben werden, wenn der Test ausgeführt oder ein Gerät mit Mit atest bereitstellen vorbereitet wird.
  • Debugger (nur für C++- und Rust-Tests): Wird angezeigt, wenn Module ein cc_test*- oder rust_test*-Ziel ist. Klicken Sie auf Auf Standardeinstellungen zurücksetzen, um die aktive Geräte- oder Host-Vorlage zurückzusetzen. Sie können auch LLDB-Optionen-Karten (z. B. Bei Eintritt anhalten, Symbole über Sitzungen hinweg im Cache speichern, Symbole bei Bedarf laden oder Mit Rust-Visualisierungen für Rust-Tests) ein- oder ausblenden und über Optionen ändern > Debugger Symbolverzeichnisse, Init-, Pre-run-, Post-run- oder Exit-Befehle und Launch-JSON (DAP-Einstellungen) hinzufügen.

Testergebnisse abrufen

Der Fortschritt der Testausführung, der Status „Bestanden“ oder „Fehlgeschlagen“, Stacktraces und Geräteprotokolle werden in Echtzeit im Toolfenster Run (Ausführen) oder Debug (Debuggen) in ASfP angezeigt.

Tipps zum Testen

• Gezielte Tests ausführen: Sie können einzelne Methoden über den Editorrand testen, ohne eine ganze Testsuite auszuführen.
• Cuttlefish-Snapshots verwenden: Wenn Sie Gerätetests auf virtuellen Cuttlefish-Geräten ausführen, verwenden Sie Snapshots, um zwischen den Ausführungen einen sauberen Gerätestatus wiederherzustellen.
• Soong-Build-Logs prüfen: Wenn ein Test vor der Ausführung nicht kompiliert werden kann, sehen Sie im Soong-Toolfenster nach Compilerdiagnosen.