Android Studio for Platform (ASfP) integruje się z modułami testowymi atest i Soong, dzięki czemu możesz uruchamiać i debugować testy platformy na komputerze hosta z systemem Linux, podłączonym urządzeniu lub wirtualnym urządzeniu Cuttlefish z poziomu IDE.
Wymagania wstępne
- Otwórz projekt ASfP skonfigurowany z wersją AOSP i
lunch. - W przypadku testów urządzeń podłącz urządzenie fizyczne lub uruchom wirtualne urządzenie Cuttlefish z odpowiednią kompilacją.
Uruchamianie i debugowanie testów
Testy platformy i sesje debugowania możesz uruchamiać w kilku miejscach w ASfP:
Android.bpcele testu: otwórz plikAndroid.bpi kliknij Uruchom w marginesie obok dowolnego modułu testowego (*_testlub*_test_host):- Uruchom: dostępne dla wszystkich typów modułów testowych Soong (
android_test,java_test_host,cc_test,rust_test,python_test,sh_testiandroid_robolectric_test). - Debug: dostępne w przypadku modułów
android_test(dołączonych do debugera Java za pomocąatest --wait-for-debugger) i modułów testowych C++ lub Rust (cc_test,cc_test_host,rust_testirust_test_host, uruchamianych w ramach wbudowanego debugera LLDB w ASfP).
- Uruchom: dostępne dla wszystkich typów modułów testowych Soong (
- Ikony w kolumnie pliku źródłowego: kliknij Uruchom obok klasy testowej lub
@Testmetody w kodzie źródłowym, aby uruchomić lub debugować konkretny test. - Menu kontekstowe po kliknięciu prawym przyciskiem myszy: kliknij prawym przyciskiem myszy plik testowy, klasę, metodę lub moduł
Android.bpi wybierz Uruchom lub Debuguj. - Wbudowany agent (AI w Android Studio): w oknie narzędziowym Agent
wbudowany agent może uruchamiać
atestcele, aby weryfikować zmiany po edycji kodu. - Zintegrowany terminal: otwórz Widok > Okna narzędzi > Terminal, aby bezpośrednio uruchamiać polecenia
atest.
Konfigurowanie i debugowanie testu inteligentnego
Gdy uruchomisz test z marginesu lub menu kontekstowego, ASfP utworzy i skonfiguruje konfigurację uruchamiania testu Soong za pomocą wykresu modułu Android.bp.
Debugowanie android_test celów Java i Kotlin
Kliknij ikonę rynny obok modułu android_test w Android.bp lub obok klasy JUnit w języku Java lub Kotlin albo metody @Test, a potem wybierz Debuguj „<TestName>”. W przypadku rynny pliku źródłowego ASfP wybiera najbliższy moduł android_test, którego srcs obejmuje plik, i nadaje konfiguracji nazwę <module>, <module>:<SimpleClass> lub <module>:<SimpleClass>#<method>.
ASfP uruchamia atest z parametrem --wait-for-debugger, odczytuje atrybut package z AndroidManifest.xml modułu, czeka na zakończenie tego procesu na podłączonym urządzeniu i dołącza debuger języka Java.

Debugowanie celów cc_test i rust_test w LLDB
Aby debugować moduł testowy C++ lub Rust (cc_test, cc_test_host, rust_test lub rust_test_host), kliknij ikonę Android.bp na marginesie i wybierz Debuguj „<TestName>”. ASfP uruchomi skompilowany plik binarny testu w wbudowanym debuggerze LLDB zamiast uruchamiać go za pomocą atest.
Skonfiguruj konfigurację testu Soong
Otwórz Uruchom > Edytuj konfiguracje i wybierz konfigurację Test Soong, aby dostosować sposób kompilowania, wdrażania i uruchamiania testów:
- Automatyczne uzupełnianie modułów i
Android.bpnawigacja: pole Moduł automatycznie uzupełnia się na podstawie zindeksowanych modułów testowych Soong w projekcie. Kliknij Go to Android.bp (Przejdź do Android.bp) obok pola, aby przejść do deklaracji modułu wAndroid.bp. - Uruchomienie: urządzenie lub host (w tym
host_supported: true): ASfP ocenia regułę modułu i jej przechodni łańcuchdefaults(host_supported,device_supported,enabled,target.android.enableditarget.host.enabled):- Testy z 2 rodzajami kierowania (
cc_testirust_testzhost_supported: true): dostępne są oba przyciski radiowe Urządzenie i Host (domyślnie wybrany jest przycisk Urządzenie). Urządzenie i Host mają własne, niezależne szablony debugera LLDB. Przełączanie opcji Uruchom między Urządzeniem a Hostem powoduje przełączanie się między konfiguracją urządzenia zdalnegolldb-servera konfiguracją lokalnego pliku binarnego hostalldb-serverz zachowaniem dostosowań wprowadzonych w każdym miejscu docelowym. - Testy z jednym celem: jeśli test w C++ lub Rust jest kompilowany tylko w jednym środowisku (np. tylko na urządzeniu
cc_testlub tylko na hościecc_test_hostalborust_test_host), ASfP wybiera obsługiwany cel i wyłącza nieobsługiwany przycisk opcji z wyjaśniającą etykietką: „<module> (<ruleType>) doesn't build for the host or device.”.
- Testy z 2 rodzajami kierowania (
- Zadania przed uruchomieniem (Build Native Test Module i Deploy with atest):
każda konfiguracja testu Soong domyślnie zawiera 2 zadania przed uruchomieniem:
- Build Native Test Module (Skompiluj natywny moduł testowy): przed uruchomieniem LLDB kompiluje
<module>-target(w przypadku urządzenia) lub<module>-host(w przypadku hosta). - Wdrażanie za pomocą polecenia atest: podczas debugowania na urządzeniu uruchamia
atest <module> --collect-tests-only --disable-teardown -it -s <serial> -- --abi <abi>, dzięki czemu Tradefed przesyła zależności testowe i wykonuje preparatory docelowe przed uruchomieniem pliku binarnego przez LLDB. Najedź wskaźnikiem na element Wdróż za pomocą atestu, aby wyświetlić podgląd dokładnego poleceniaatest. Aby przyspieszyć iterację, gdy zależności są już na urządzeniu, usuń Deploy with atest, aby ASfP przesyłał bezpośrednio tylko plik binarny testu. Jeśli wybierzesz Uruchom na: host, ASfP automatycznie pominie opcję Wdróż z testem.
- Build Native Test Module (Skompiluj natywny moduł testowy): przed uruchomieniem LLDB kompiluje
- Opcje modyfikacji i debugger (karty opcji LLDB): użyj opcji Modyfikuj opcje, aby dodać opcjonalne pola konfiguracji:
- Argumenty programu (system operacyjny, tylko testy C++ i Rust): dodatkowe argumenty przekazywane bezpośrednio do pliku binarnego
cc_testlubrust_testpo filtrze--gtest_filterlublibtestpodczas debugowania. - atest arguments (Test): dodatkowe flagi przekazywane do
atestpodczas uruchamiania testu lub przygotowywania urządzenia za pomocą opcji Deploy with atest (Wdróż za pomocą atest). - Debuger (tylko testy w C++ i Rust): wyświetla się, gdy Moduł jest celem
cc_test*lubrust_test*. Przełącz karty LLDB options (Opcje LLDB) (np. Stop on entry (Zatrzymaj przy wejściu), Cache symbols across sessions (Buforuj symbole w różnych sesjach), Load symbols on demand (Wczytuj symbole na żądanie) lub With Rust visualizers (Z wizualizatorami Rust) w przypadku testów Rust), kliknij Reset to defaults (Przywróć ustawienia domyślne), aby zresetować aktywny szablon Device (Urządzenie) lub Host (Host), albo dodaj Symbol directories (Katalogi symboli), Init, Pre-run, Post-run, or Exit commands (Polecenia inicjowania, przed uruchomieniem, po uruchomieniu lub wyjścia) i Launch JSON (DAP Settings) (Ustawienia DAP) w sekcji Modify options > Debugger (Modyfikuj opcje > Debuger).
- Argumenty programu (system operacyjny, tylko testy C++ i Rust): dodatkowe argumenty przekazywane bezpośrednio do pliku binarnego

Wyświetlanie wyników testu
Postępy wykonywania testu, stan (sukces lub niepowodzenie), zrzuty stosu i dzienniki urządzeń są wyświetlane w czasie rzeczywistym w oknie narzędzia Uruchom lub Debuguj w ASfP.
Wskazówki dotyczące testowania
- Przeprowadzanie ukierunkowanych testów: testuj poszczególne metody z marginesu edytora bez uruchamiania całego zestawu testów.
- Używaj migawek Cuttlefish: podczas przeprowadzania testów urządzeń na wirtualnych urządzeniach Cuttlefish używaj migawek, aby przywracać czysty stan urządzenia między kolejnymi uruchomieniami.
- Sprawdzanie dzienników kompilacji Soong: jeśli test nie skompiluje się przed uruchomieniem, sprawdź okno narzędzia Soong pod kątem diagnostyki kompilatora.