Zestaw testowy
Aby test był częścią VTS musi mieć następujące ustawienie w Android.bp .
test_suites: ["vts"],
Dodatkowo dodanie testu do pakietu general-tests pozwala mu stać się częścią pakietu mapowania testów używanego podczas kontroli przed przesłaniem.
Konfiguracja testowa
W większości przypadków konfiguracja testu, która jest plikiem XML używanym przez Federację Handlową do przeprowadzenia testu VTS, jest generowana automatycznie podczas kompilacji. Można jednak dostosować konfigurację testu.
Utwórz dostosowany plik konfiguracyjny testu
Tworzenie od podstaw nowego testowego pliku XML może być skomplikowane, ponieważ wymaga zrozumienia sposobu działania wiązki testowej, a także różnic między każdym uczestnikiem testu. Wygenerowany automatycznie plik konfiguracyjny testu ma na celu ułatwienie tego procesu.
Jeśli musisz dostosować testowy plik XML, możesz użyć automatycznie wygenerowanego pliku jako punktu wyjścia.
Aby zlokalizować automatycznie wygenerowany plik konfiguracyjny testu, najpierw uruchom polecenie make w celu zbudowania konfiguracji, 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 znajduje się tylko jeden 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 atrybut test_config do modułu, jak pokazano w przykładzie poniżej.
test_config: "VtsHalUsbV1_1TargetTest.xml",
Teraz masz testowy plik konfiguracyjny, z którym możesz pracować i wdrażać dostosowanie.
Wymuś uruchomienie testu z rootem adb
Większość testów VTS wymaga do uruchomienia uprawnień roota. Jeśli testowy plik konfiguracyjny został wygenerowany automatycznie, możesz dodać następujący atrybut do Android.bp .
require_root: true,
Jeśli plik konfiguracyjny testu jest dostosowany, dodaj następujące elementy do testowego pliku XML.
<target_preparer class="com.android.tradefed.targetprep.RootTargetPreparer"/>
Zatrzymaj framework na czas testu
Wiele testów VTS nie wymaga do działania frameworku Android, a uruchomienie testu przy zatrzymanym frameworku pozwala na stabilne działanie testu, bez wpływu na błędy urządzenia. Jeśli testowy plik konfiguracyjny został wygenerowany automatycznie, możesz dodać następujący atrybut do Android.bp .
disable_framework: true,
Jeśli plik konfiguracyjny testu jest dostosowany, dodaj następujące elementy do testowego pliku XML.
<target_preparer class="com.android.tradefed.targetprep.StopServicesSetup"/>
Dodaj dodatkowe argumenty testowe
Wykonanie niektórych testów gtest może wymagać więcej czasu. W takich przypadkach można dodać opcje modułu uruchamiającego test w pliku XML.
Na przykład ustawienie native-test-timeout w poniższym wpisie umożliwia uruchomienie testu z limitem czasu wynoszącym 3 minuty zamiast domyślnej wartości 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 API
Niektóre testy VTS można uruchomić tylko na urządzeniach z minimalnym poziomem API. Jeśli testowy plik konfiguracyjny został wygenerowany automatycznie, możesz dodać następujący atrybut do Android.bp .
test_min_api_level: 29,
Jeśli plik konfiguracyjny testu jest dostosowany, dodaj następujące polecenie do testowego pliku XML.
<object type="module_controller" class="com.android.tradefed.testtype.suite.module.MinApiLevelModuleController">
<option name="min-api-level" value="29" />
</object>
Android 12 definiuje właściwości ro.board.first_api_level i ro.board.api_level , aby pokazać poziom API obrazów dostawców na tych urządzeniach. Łącząc te właściwości z ro.product.first_api_level , zestawy testów wybierają odpowiednie przypadki testowe dla urządzeń.
Android 13 definiuje ro.vendor.api_level , który jest ustawiany automatycznie poprzez obliczenie wymaganego poziomu API dostawcy przy użyciu właściwości ro.product.first_api_level , ro.board.first_api_level i ro.board.api_level .
ro.board.first_api_level
Właściwość ro.board.first_api_level to poziom interfejsu API, kiedy obrazy dostawców dla SoC są po raz pierwszy publikowane z tą właściwością. Nie zależy to od poziomu API uruchamiania urządzenia, ale zależy jedynie od pierwszego poziomu API SoC, który definiuje tę wartość. Wartość jest stała przez cały okres użytkowania SoC.
Aby ustawić ro.board.first_api_level , producenci urządzeń mogą zdefiniować BOARD_SHIPPING_API_LEVEL w swoim pliku device.mk , jak pokazano w poniższym 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 właściwość ro.board.first_api_level w 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 określa bieżący poziom API obrazów dostawców dla SoC. Po zaktualizowaniu poziomu API obrazu dostawcy, który ma poziom ro.board.first_api_level , urządzenie korzystające z SoC musi zdefiniować właściwość ro.board.api_level przy użyciu bieżącego poziomu API obrazu dostawcy zamiast aktualizować poziom ro.board.first_api_level . Jeśli ta właściwość nie jest ustawiona, domyślnie używany będzie ro.board.first_api_level .
Aby ustawić ro.board.api_level , zdefiniuj BOARD_API_LEVEL w pliku device.mk żądaną wartością.
ro.vendor.api_level
Właściwość ro.vendor.api_level została wprowadzona w systemie Android 13, aby pokazać poziom interfejsu API, który muszą obsługiwać obrazy dostawców. Jest to automatycznie ustawiane na minimum ro.board.api_level (lub ro.board.first_api_level , jeśli ro.board.api_level nie jest zdefiniowane) i ro.product.first_api_level . Testy implementacji dostawcy wymagające aktualizacji obrazu dostawcy mogą zostać wyłączone z wymagań dostawcy dotyczących SoC poprzez odniesienie się do tej właściwości.
Proces shardingu przy użyciu VTS
W przypadku systemu Android w wersji 10 lub nowszej możesz przeprowadzić proces fragmentowania na wielu urządzeniach podczas testowania zarówno z planami VTS, jak 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.