Zestaw testów
Aby test był częścią VTS, musi mieć w Android.bp to ustawienie:
test_suites: ["vts"],
Dodanie testu do pakietu general-tests umożliwia włączenie go do pakietu Test Mapping używanego w ramach sprawdzania przed przesłaniem.
Testowanie konfiguracji
W większości przypadków konfiguracja testu, czyli plik XML używany przez Trade Federation do uruchamiania testu VTS, jest generowana automatycznie podczas kompilacji. Możesz jednak dostosować konfigurację testu.
Tworzenie dostosowanego pliku konfiguracji testu
Utworzenie nowego pliku XML testu od zera może być skomplikowane, ponieważ wymaga zrozumienia działania platformy testowej oraz różnic między poszczególnymi programami do uruchamiania testów. Automatycznie generowany plik konfiguracji testu ma ułatwić ten proces.
Jeśli musisz dostosować testowy plik XML, możesz użyć automatycznie wygenerowanego pliku jako punktu wyjścia.
Aby znaleźć automatycznie wygenerowany plik konfiguracji testu, najpierw uruchom polecenie make, aby utworzyć konfigurację, jak pokazano poniżej.
$ m VtsHalUsbV1_1TargetTest
W katalogu kompilacji możesz wyszukać plik konfiguracyjny na podstawie nazwy modułu, jak pokazano poniżej.
$ find out/ -name VtsHalUsbV1_1TargetTest.config
Może istnieć wiele kopii pliku 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 konfiguracji 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 plik konfiguracji testu, z którym możesz pracować i wdrażać dostosowywanie.
Wymuszanie uruchomienia 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 elementu Android.bp ten atrybut:
require_root: true,
Jeśli plik konfiguracji testu jest dostosowany, dodaj do pliku XML testu następujący kod:
<target_preparer class="com.android.tradefed.targetprep.RootTargetPreparer"/>
Zatrzymywanie platformy podczas testu
Wiele testów VTS nie wymaga działania platformy Android, a przeprowadzanie testu przy zatrzymanej platformie pozwala na stabilne działanie testu bez wpływu na niestabilność urządzenia. Jeśli plik konfiguracji testu jest generowany automatycznie, możesz dodać do elementu Android.bp ten atrybut:
disable_framework: true,
Jeśli plik konfiguracji testu jest dostosowany, dodaj do pliku XML testu następujący kod:
<target_preparer class="com.android.tradefed.targetprep.StopServicesSetup"/>
Dodawanie dodatkowych argumentów testu
Uruchomienie niektórych testów gtest może zająć więcej czasu. W takich przypadkach możesz dodać opcje narzędzia do uruchamiania testów w pliku XML.
Na przykład ustawienie native-test-timeout w poniższym wpisie umożliwia uruchomienie testu z limitem czasu 3 minut 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>
Wymagaj minimalnego poziomu interfejsu API
Niektóre testy VTS można uruchamiać tylko na urządzeniach z minimalnym poziomem API. Jeśli plik konfiguracji testu jest generowany automatycznie, możesz dodać ten atrybut do elementu 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 to 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 ro.product.first_api_level,
zestawami testów pozwala wybrać odpowiednie przypadki testowe dla urządzeń.
Android 13 definiuje ro.vendor.api_level, który jest ustawiany automatycznie przez obliczenie wymaganego poziomu interfejsu API dostawcy na podstawie właściwości ro.product.first_api_level, ro.board.first_api_level i ro.board.api_level.
Więcej informacji znajdziesz w sekcji Poziom interfejsu API dostawcy.
ro.board.first_api_level
Właściwość ro.board.first_api_level jest poziomem interfejsu API, gdy obrazy dostawcy dla układu SoC, który kwalifikuje się do zamrożenia wersji dostawcy, są po raz pierwszy udostępniane z tą właściwością. Nie zależy to od poziomu interfejsu API urządzenia, ale tylko od pierwszego poziomu interfejsu API układu SoC, który definiuje tę wartość. Wartość jest stała przez cały okres eksploatacji układu SoC.
Aby ustawić ro.board.first_api_level, producenci urządzeń mogą zdefiniować BOARD_SHIPPING_API_LEVEL w pliku device.mk, jak pokazano 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
Automatycznie zdefiniuje na urządzeniu właściwość ro.board.first_api_level jako vendor/build.prop. Właściwość jest ustawiana przez dostawcę init
procesu.
ro.board.api_level
Właściwość ro.board.api_level to bieżący poziom interfejsu API dostawcy obrazów dostawcy w formacie YYYYMM, w którym interfejs API dostawcy został 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 API, który muszą obsługiwać obrazy dostawcy. Jest on automatycznie ustawiany na ro.product.first_api_level lub ro.board.api_level, jeśli występuje ro.board.first_api_level, a ro.board.api_level jest ustawiony na wcześniejszy poziom interfejsu API niż ro.product.first_api_level. Jeśli wersja jest ustawiona na wersję z 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ą zostać wykluczone
z wymagań dostawcy dotyczących układu SoC przez odwołanie się do tej właściwości.
Proces dzielenia na partycje za pomocą VTS
W przypadku Androida w wersji 10 lub nowszej możesz przeprowadzić proces dzielenia na partycje na wielu urządzeniach podczas testowania za pomocą planów VTS i CTS-on-GSI, postępując zgodnie z poniższymi instrukcjami.
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.