Od 27 marca 2025 r. zalecamy używanie android-latest-release zamiast aosp-main do kompilowania i wspołtworzenia AOSP. Więcej informacji znajdziesz w artykule o zmianach w AOSP.

Ta strona została przetłumaczona przez Cloud Translation API.

Konsola poleceń CTS 2
Zadbaj o dobrą organizację dzięki kolekcji Zapisuj i kategoryzuj treści zgodnie ze swoimi preferencjami.

Korzystanie z konsoli CTS v2

W przypadku Androida 7.0 lub nowszego użyj CTS 2.

Wybieranie abonamentów

Dostępne plany testów:

cts – uruchamia CTS z istniejącej instalacji CTS.
cts-camera – uruchamia CTS-camera z uprzednio zainstalowanego pakietu CTS.
cts-java – uruchamia podstawowe testy Java z dotychczasowej instalacji pakietu CTS.
cts-pdk – uruchamia testy przydatne do sprawdzania kompilacji fuzji PDK.
wszystko – wspólna konfiguracja dla pakietów Compatibility Test Suite.

Inne dostępne konfiguracje to:

basic-reporters – konfiguracja z podstawowymi raportami CTS.
collect-tests-only – uruchamia pakiet CTS z uprzednio zainstalowanego pakietu.
common-compatibility-config – wspólna konfiguracja dla pakietów zgodności.
cts-filtered-sample – wspólna konfiguracja pakietów zgodności.
cts-known-failures – konfiguracja z znanymi błędami w pakiecie CTS.
cts-preconditions – konfiguracje warunków wstępnych CTS.
host – uruchamia pojedynczy test hosta na istniejącym urządzeniu.
instrument – uruchamia pojedynczy test instrumentacji Androida na istniejącym urządzeniu.
native-benchmark – przeprowadza test obciążeniowy natywnej aplikacji na istniejącym urządzeniu.
native-stress – przeprowadzanie testu obciążeniowego natywnego na istniejącym urządzeniu.
recharge – fałszywy test, który czeka na prawie rozładowane urządzenia i zatrzymuje je w celu naładowania.
testdef – uruchamia testy zawarte w plikach test_def.xml na istniejącym urządzeniu.
util/wifi – konfiguracja narzędzi do konfigurowania Wi-Fi na urządzeniu.
util/wipe – czyści dane użytkownika na urządzeniu.

Wszystkie te plany i konfiguracje można wykonać za pomocą polecenia run cts.

Dokumentacja poleceń konsoli CTS w wersji 2

W tej tabeli znajdziesz podsumowanie poleceń konsoli CTS 2 w różnych zastosowaniach.

Zorganizuj	Opis
`help`	wyświetlić podsumowanie najczęściej używanych poleceń;
`help all`	Wyświetlić pełną listę dostępnych poleceń
`version`	Pokaż wersję.
`exit`	Pomyślnie zamknij konsolę CTS. Konsolę zamyka się, gdy wszystkie obecnie wykonywane testy zostaną ukończone.
`extdir`	Skompresowany plik pobierania jest rozpakowywany do `extdir`. Jeśli chcesz pozbyć się rozszerzonego wyjścia, użyj opcji `-q`: `unzip -q android-cts-9.0_r15-linux_x86-arm.zip -d extdir` Jeśli chcesz rozpakować pliki do bieżącego katalogu, nie używaj opcji `-d`, tylko uruchom: `unzip -q android-cts-9.0_r15-linux_x86-arm.zip`
Uruchom	Opis
`run cts`	W Androidzie 10 uruchom domyślny plan CTS i CTS-Instant razem (czyli pełne wywołanie CTS). W przypadku Androida 9 lub starszego uruchom tylko domyślny plan CTS. Użyj tej kompleksowej opcji (w tym warunków wstępnych) do weryfikacji urządzenia. Informacje o włączeniu znajdziesz w pliku cts.xml. Konsola CTS może przyjmować inne polecenia podczas trwania testów. Jeśli żadne urządzenia nie są połączone, maszyna stacjonarna CTS (lub host) będzie czekać na połączenie urządzenia, zanim rozpocznie testy. Jeśli połączonych jest więcej niż 1 urządzenie, host CTS wybierze je automatycznie.
`run cts-instant`	W przypadku Androida 9 uruchom domyślny plan CTS-Instant.
`run cts --module-parameter INSTANT_APP`	W Androidzie 10 uruchom domyślny plan CTS-Instant.
`run cts --module-parameter INSTANT_APP --module/-m test_module_name`	W Androidzie 10 uruchom wskazany moduł testu CTS-Instant lub moduły.
`run retry`	Tylko na Androidzie 9 lub nowszym. Ponowne wykonanie wszystkich testów, które nie powiodły się lub nie zostały wykonane podczas poprzednich sesji. Na przykład `run retry --retry -s` lub `run retry --retry --shard-count` z użyciem podziału na fragmenty TF. `run cts --retry` jest niedozwolony na Androidzie 9 lub nowszym.
`run cts-sim`	Android 11 lub nowszy. Wykonywanie podzbioru testów na urządzeniu z kartą SIM.
`--device-token`	Android 8.1 lub starszy. Określa, że dane urządzenie ma dany token. Na przykład: `--device-token 1a2b3c4d:sim-card`.
`--enable-token-sharding`	Tylko Android 10 lub nowszy Automatycznie dopasowuje test do wymaganego typu karty SIM. Aby wykonać przypadki testowe związane z kartą SIM, nie musisz podawać numeru seryjnego urządzenia. Obsługiwane karty SIM: `SIM_CARD`, `UICC_SIM_CARD` i `SECURE_ELEMENT_SIM_CARD`.
`run cts-dev`	Uruchom domyślny plan CTS (czyli pełne wywołanie CTS), ale pomiń warunki wstępne, aby skrócić czas wykonywania podczas iteracyjnego tworzenia nowego testu. Umożliwia to pominięcie weryfikacji i konfiguracji urządzenia, takiej jak przesyłanie plików multimedialnych czy sprawdzanie połączenia Wi-Fi, które są wykonywane przy użyciu opcji `--skip-preconditions`. To polecenie pomija również zbieranie informacji o urządzeniu oraz wszystkie sprawdzanie stanu systemu. Testy są też przeprowadzane tylko na 1 ABI. W przypadku walidacji urządzenia nie stosuj tej optymalizacji i uwzględnij wszystkie warunki wstępne oraz kontrole. Wykluczenia znajdziesz w pliku cts-dev.xml. Konsola CTS może przyjmować inne polecenia podczas trwania testów. Jeśli żadne urządzenia nie są połączone, maszyna stacjonarna CTS (lub host) będzie czekać na połączenie urządzenia, zanim rozpocznie testy. Jeśli połączonych jest więcej niż 1 urządzenie, host CTS wybierze je automatycznie.
`--subplan subplan_name`	Uruchamia podany plan podrzędny.
`--module/-m test_module_name --test/-t test_name`	Uruchom określony moduł i przeprowadź test. Na przykład: `run cts -m Gesture --test android.gesture.cts.GestureTest#testGetStrokes` uruchom konkretne pakiety, klasy lub testy. Uwaga: nie używaj tej opcji, gdy korzystasz z opcji `--include-filter`.
`--retry`	Ponownie uruchom wszystkie testy, które nie powiodły się lub nie zostały wykonane podczas poprzednich sesji. Aby uzyskać identyfikator sesji, użyj polecenia `list results`.
`--retry-type NOT_EXECUTED`	Ponownie wykonaj tylko testy, które nie zostały wykonane podczas poprzednich sesji. Aby uzyskać identyfikator sesji, użyj polecenia `list results`.
`--shards number_of_shards`	W przypadku Androida 8.1 lub starszego: Podziel test CTS na określoną liczbę niezależnych fragmentów, aby można było go uruchamiać równolegle na wielu urządzeniach.
`--shard-count number_of_shards`	Na Androidzie 9. Podziel test CTS na określoną liczbę niezależnych fragmentów, aby uruchomić go równolegle na wielu urządzeniach.
`--serial/-s deviceID`	Uruchom test CTS na konkretnym urządzeniu.
`--include-filter "test_module_name test_name"`	Uruchom z określonymi modułami lub pakietami testów, klasami i przypadkami testowymi. Na przykład:`run cts --include-filter "CtsCalendarcommon2TestCases android.calendarcommon2.cts.Calendarcommon2Test#testStaticLinking"` zawiera określony moduł. Ta opcja polecenia nie jest obsługiwana podczas ponownego próbowania. Uwaga: nie używaj tej opcji, gdy korzystasz z opcji `--module/-m`.
`--exclude-filter "test_module_name test_name"`	Wyklucz z testu określone moduły lub pakiety testów, klasy i przypadki. Na przykład: `run cts --exclude-filter "CtsCalendarcommon2Test android.calendarcommon2.cts.Calendarcommon2Test#testStaticLinking"` wyklucza określony moduł.
`--log-level-display/-l log_level`	Uruchom z minimalnym określonym poziomem logowania wyświetlanym na `STDOUT`. Prawidłowe wartości: [`VERBOSE`, `DEBUG`, `INFO`, `WARN`, `ERROR`, `ASSERT`].
`--abi abi_name`	Wymuś uruchomienie testu na określonym ABI, 32 lub 64. Domyślnie CTS przeprowadza test raz dla każdego obsługiwanego przez urządzenie interfejsu ABI.
`--logcat-on-failure`, `--bugreport-on-failure`, `--screenshoot-on-failure`	zapewniają większą widoczność błędów i ułatwiają diagnostykę;
`--device-token`	Określa, że dane urządzenie ma dany token, np. `--device-token 1a2b3c4d:sim-card`.
`--skip-device-info`	Pomija zbieranie informacji o urządzeniu. Uwaga: nie używaj tej opcji podczas korzystania z CTS w celu uzyskania zatwierdzenia.
`--skip-preconditions`	Pomiń warunki wstępne, aby skrócić czas wykonywania podczas iteracyjnego tworzenia nowego testu. Umożliwia to pominięcie weryfikacji i konfiguracji urządzenia, np. przesyłania plików multimedialnych lub sprawdzania połączenia Wi-Fi.
Lista	Opis
`list modules`	wyświetlić listę wszystkich dostępnych modułów testowych w repozytorium;
`list plans` lub `list configs`	Wyświetlić wszystkie dostępne plany testów (konfiguracje) w repozytorium.
`list subplans`	Wyświetla listę wszystkich dostępnych subplanów w repozytorium.
`list invocations`	Wyświetla listę poleceń run, które są obecnie wykonywane na urządzeniach.
`list commands`	Wyświetla listę wszystkich poleceń wykonania znajdujących się obecnie w kolejce i oczekujących na przypisanie do urządzeń.
`list results`	Wyświetla wyniki CTS aktualnie przechowywane w repozytorium.
`list devices`	Lista aktualnie połączonych urządzeń i ich stan. Dostępne urządzenia są sprawne, nieużywane i dostępne do przeprowadzania testów. Urządzenia niedostępne to urządzenia widoczne w programie adb, ale nie reagujące na polecenia adb. Nie będą one przydzielane do testów. Wydzielone urządzenia to urządzenia, na których są obecnie przeprowadzane testy.
Zrzuć	Opis
`dump logs`	Wyświetlanie dzienników tradefed dla wszystkich wywołań w trakcie wykonywania.
Dodaj	Opis
`add subplan --name/-n subplan_name --result-type [passed \| failed \| not_executed] [--session session_id]`	Utwórz podplan na podstawie poprzedniej sesji. Ta opcja umożliwia utworzenie podplanu, którego można użyć do wykonania podzbioru testów. Jedyną wymaganą opcją jest `--session`. Pozostałe są opcjonalne, ale jeśli je uwzględnisz, muszą być poprzedzone wartością. Opcja `--result-type` jest powtarzalna, np. `add subplan --session 0 --result-type passed --result-type failed` jest prawidłowa.