Zestaw testów
Aby test był częścią VTS, musi mieć w pliku Android.bp to ustawienie.
test_suites: ["vts"],
Dodanie testu do zestawu general-tests umożliwia też jego uwzględnienie w zestawie Test Mapping używanym w ramach kontroli 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 niestandardowego pliku konfiguracji testu
Utworzenie nowego pliku XML testu od zera może być skomplikowane, ponieważ wymaga zrozumienia, jak działa platforma testowa, oraz różnic między poszczególnymi programami do uruchamiania testów. Automatycznie wygenerowany plik konfiguracji testu ma na celu ułatwienie tego procesu.
Jeśli musisz dostosować plik XML testu, możesz użyć automatycznie wygenerowanego pliku jako punktu początkowego.
Aby znaleźć automatycznie wygenerowany plik konfiguracji testu, najpierw uruchom polecenie make, aby skompilować 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
Może istnieć kilka 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 wprowadzać zmiany.
Wymuszanie uruchamiania testu z uprawnieniami roota adb
Większość testów VTS wymaga do uruchomienia uprawnień roota. Jeśli plik konfiguracji testu jest generowany automatycznie, możesz dodać ten atrybut do pliku Android.bp.
require_root: true,
Jeśli plik konfiguracji testu jest dostosowany, dodaj ten atrybut do pliku XML testu.
<target_preparer class="com.android.tradefed.targetprep.RootTargetPreparer"/>
Zatrzymywanie platformy podczas testu
Wiele testów VTS nie wymaga do uruchomienia platformy Androida, a uruchomienie testu z zatrzymaną platformą umożliwia jego stabilne działanie bez wpływu na niestabilność urządzenia. Jeśli plik konfiguracji testu jest generowany automatycznie, możesz dodać ten atrybut do pliku Android.bp.
disable_framework: true,
Jeśli plik konfiguracji testu jest dostosowany, dodaj ten atrybut do pliku XML testu.
<target_preparer class="com.android.tradefed.targetprep.StopServicesSetup"/>
Dodawanie dodatkowych argumentów testu
Uruchomienie niektórych testów gtest może wymagać więcej czasu. W takich przypadkach możesz dodać opcje programu do uruchamiania testów w pliku XML.
Na przykład ustawienie native-test-timeout w tym 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>
Wymaganie minimalnego poziomu interfejsu API
Niektóre testy VTS można uruchamiać tylko na urządzeniach z minimalnym poziomem interfejsu API. Jeśli plik konfiguracji testu jest generowany automatycznie, możesz dodać ten atrybut do pliku Android.bp.
min_shipping_api_level: 29,
lub
vsr_min_shipping_api_level: 202404,
Jeśli plik konfiguracji testu jest dostosowany, dodaj to polecenie do pliku XML testu.
<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 pokazywać poziom interfejsu API obrazów dostawcy na tych urządzeniach. Łącząc te właściwości z właściwością ro.product.first_api_level, zestawy testów wybierają odpowiednie przypadki testowe dla urządzeń.
Android 13 definiuje właściwość ro.vendor.api_level, która jest ustawiana automatycznie 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, gdy obrazy dostawcy dla układu SOC, który kwalifikuje się do zamrożenia dostawcy są po raz pierwszy udostępniane z tą właściwością. Nie zależy to od poziomu interfejsu API uruchamiania 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ć właściwość ro.board.first_api_level, producenci urządzeń mogą zdefiniować właściwość 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 ona właściwość ro.board.first_api_level w pliku vendor/build.prop na urządzeniu. Właściwość jest ustawiana przez proces init dostawcy.
ro.board.api_level
Właściwość ro.board.api_level to bieżący poziom interfejsu API dostawcy obrazów dostawcy, który ma format YYYYMM, w którym interfejs API dostawcy został zamrożony. Jest ona ustawiana automatycznie przez system kompilacji.
ro.vendor.api_level
Właściwość ro.vendor.api_level została wprowadzona w Androidzie 13, aby pokazywać poziom interfejsu API, który muszą obsługiwać obrazy dostawcy. Jest ona automatycznie ustawiana na wartość ro.product.first_api_level lub ro.board.api_level, jeśli właściwość ro.board.first_api_level jest obecna, a właściwość ro.board.api_level jest ustawiona na wcześniejszy poziom interfejsu API niż ro.product.first_api_level. Wersja zostanie zastąpiona odpowiednim poziomem interfejsu API dostawcy, jeśli jest ustawiona na wersję z właściwości ro.product.first_api_level, która jest większa lub równa 35. 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 fragmenty za pomocą VTS
W przypadku Androida w wersji 10 lub nowszej możesz przeprowadzić proces dzielenia na fragmenty na wielu urządzeniach podczas testowania za pomocą planów VTS i CTS-on-GSI, wykonując te 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.