Zestaw testów
Aby test był częścią VTS, musi mieć takie ustawienie w Android.bp.
test_suites: ["vts"],
Dodanie testu do pakietu general-tests pozwala na jego uwzględnienie w pakiecie mapowania testów używanym w sprawdzeniu przed przesłaniem.
Testowanie konfiguracji
W większości przypadków konfiguracja testu, czyli plik XML używany przez Trade Federation do przeprowadzania testu VTS, jest generowany automatycznie podczas kompilacji. Możesz jednak dostosować konfigurację testu.
Tworzenie niestandardowego pliku konfiguracji testów
Tworzenie nowego pliku XML testu od podstaw może być skomplikowane, ponieważ wymaga zrozumienia działania testu oraz różnic między poszczególnymi narzędziami do testowania. Wygenerowany automatycznie plik konfiguracji testu ma ułatwić ten proces.
Jeśli musisz dostosować testowy plik XML, możesz użyć jako punktu wyjścia pliku wygenerowanego automatycznie.
Aby znaleźć wygenerowany automatycznie plik konfiguracji testowej, najpierw uruchom polecenie make, aby utworzyć konfigurację, jak pokazano poniżej.
$ m VtsHalUsbV1_1TargetTest
W katalogu kompilacji możesz wyszukać plik konfiguracji na podstawie nazwy modułu, jak pokazano poniżej.
$ find out/ -name VtsHalUsbV1_1TargetTest.config
Plik może mieć wiele kopii i możesz użyć dowolnej z nich.
Skopiuj plik .config do katalogu, w którym znajduje się plik Android.bp.
Jeśli w pliku Android.bp jest tylko 1 moduł testowy, możesz zmienić nazwę pliku XML na AndroidTest.xml, a system kompilacji automatycznie użyje go jako pliku konfiguracyjnego modułu testowego. W przeciwnym razie dodaj do modułu atrybut test_config, jak pokazano w przykładzie poniżej.
test_config: "VtsHalUsbV1_1TargetTest.xml",
Masz teraz testowy plik konfiguracji, z którym możesz pracować i wdrożyć dostosowywanie.
Wymuś uruchomienie testu za pomocą adb root.
Większość testów VTS wymaga uprawnień roota. Jeśli plik konfiguracji testu jest generowany automatycznie, możesz dodać do niego ten atrybut: Android.bp.
require_root: true,
Jeśli plik konfiguracji testu jest niestandardowy, dodaj do pliku XML testu następujące informacje.
<target_preparer class="com.android.tradefed.targetprep.RootTargetPreparer"/>
Zatrzymywanie platformy podczas testu
Wiele testów VTS nie wymaga uruchamiania platformy Android, a przeprowadzenie testu przy zatrzymanej platformie pozwala na stabilne przeprowadzanie testu bez wpływu problemów z urządzeniami. Jeśli plik konfiguracji testu jest generowany automatycznie, możesz dodać do niego ten atrybut: Android.bp.
disable_framework: true,
Jeśli plik konfiguracji testu jest niestandardowy, dodaj do pliku XML testu następujące informacje.
<target_preparer class="com.android.tradefed.targetprep.StopServicesSetup"/>
Dodawanie dodatkowych argumentów testu
Niektóre testy gtest mogą wymagać więcej czasu. W takich przypadkach możesz dodać opcje testów w pliku XML.
Na przykład ustawienie native-test-timeout w poniższym wpisie pozwala na uruchomienie testu z czasem oczekiwania wynoszącym 3 minuty zamiast domyślnej 1 minuty.
<test class="com.android.tradefed.testtype.GTest" >
<option name="native-test-device-path" value="/data/local/tmp" />
<option name="module-name" value="VtsHalNfcV1_0TargetTest" />
<option name="native-test-timeout" value="180000"/>
</test>
Wymaganie minimalnego poziomu interfejsu API
Niektóre testy VTS można przeprowadzać tylko na urządzeniach z minimalnym poziomem interfejsu API. Jeśli plik konfiguracji testu jest generowany automatycznie, możesz dodać ten atrybut do Android.bp.
min_shipping_api_level: 29,
lub
vsr_min_shipping_api_level: 202404,
Jeśli plik konfiguracji testu jest dostosowany, dodaj do pliku XML testu następujące polecenie.
<object type="module_controller" class="com.android.tradefed.testtype.suite.module.ShippingApiLevelModuleController">
<option name="min-api-level" value="29" />
</object>
lub
<object type="module_controller" class="com.android.tradefed.testtype.suite.module.ShippingApiLevelModuleController">
<option name="vsr-min-api-level" value="202404" />
</object>
Właściwości poziomu interfejsu API
Android 12 definiuje właściwości ro.board.first_api_level i ro.board.api_level, aby wyświetlać poziom interfejsu API obrazów dostawcy na tych urządzeniach. Połączenie tych właściwości z informacjami o urządzeniach pozwala testom wybierać odpowiednie przypadki testowe dla urządzeń.ro.product.first_api_level
Android 13 definiuje wartość ro.vendor.api_level, która jest automatycznie ustawiana przez obliczenie wymaganego poziomu interfejsu API dostawcy za pomocą właściwości ro.product.first_api_level, ro.board.first_api_level i ro.board.api_level.
Więcej informacji znajdziesz w artykule Poziom interfejsu API dostawcy.
ro.board.first_api_level
Właściwość ro.board.first_api_level to poziom interfejsu API, na którym obrazy dostawcy dla SoC kwalifikujące się do zamrożenia dostawcy są po raz pierwszy publikowane z tą usługą. Nie zależy to od poziomu interfejsu API używanego przez urządzenie, ale tylko od pierwszego poziomu interfejsu API w systemie SoC, który definiuje tę wartość. Wartość ta jest stała przez cały okres istnienia SoC.
Aby ustawić ro.board.first_api_level, producenci urządzeń mogą zdefiniować BOARD_SHIPPING_API_LEVEL w pliku device.mk, jak w tym przykładzie:
# BOARD_SHIPPING_API_LEVEL sets ro.product.first_api_level to indicate
# the first api level that the device has been commercially launched on.
BOARD_SHIPPING_API_LEVEL := 23
Na urządzeniu automatycznie zdefiniuje ona właściwość ro.board.first_api_level na wartość vendor/build.prop. Właściwość jest ustawiana przez dostawcę initprocesu.
ro.board.api_level
Właściwość ro.board.api_level to bieżący poziom interfejsu API dostawcy w formacie YYYYMM, w którym został on zamrożony. Jest on automatycznie ustawiany przez system kompilacji.
ro.vendor.api_level
Właściwość ro.vendor.api_level została wprowadzona w Androidzie 13, aby wskazywać poziom interfejsu API, który muszą obsługiwać obrazy dostawcy. Jest on automatycznie ustawiany na wartość ro.product.first_api_level lub ro.board.api_level, jeśli występuje wartość ro.board.first_api_level, a wartość ro.board.api_level jest ustawiona na poziom interfejsu API wcześniejszy niż ro.product.first_api_level. Jeśli wersja jest ustawiona na ro.product.first_api_level, która jest większa lub równa 35, zostanie zastąpiona odpowiednim poziomem interfejsu API dostawcy. Testy implementacji dostawcy, które wymagają uaktualnienia obrazu dostawcy, mogą być wykluczone z wymagań dostawcy dotyczących SoC przez odniesienie do tej właściwości.
Proces dzielenia za pomocą VTS
W przypadku Androida w wersji 10 lub nowszej możesz przeprowadzić proces dzielenia na wiele urządzeń podczas testowania z planami VTS i CTS-on-GSI, wykonując podane niżej instrukcje.
run vts --shard-count <number of devices> -s <device serial> ...
To polecenie dzieli plan VTS na fragmenty i uruchamia je na wielu urządzeniach.
run cts-on-gsi --shard-count <number of devices> -s <device serial> -s ...
To polecenie dzieli plan CTS-on-GSI na fragmenty i uruchamia je na wielu urządzeniach.