Zestaw testów
Aby test był częścią VTS, musi mieć te ustawienia 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 testowa, czyli plik XML używany przez federację handlową do przeprowadzania testu VTS, jest generowana automatycznie podczas kompilacji. Możesz jednak dostosować konfigurację testu.
Tworzenie niestandardowego pliku konfiguracji testu
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. Automatycznie generowany testowy plik konfiguracji ma ułatwić ten proces.
Jeśli musisz dostosować testowy plik XML, jako punktu wyjścia możesz użyć 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 plik Android.bp zawiera tylko jeden moduł testowy, możesz zmienić nazwę pliku XML na AndroidTest.xml – wtedy system kompilacji automatycznie użyje jej 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 testowy plik konfiguracji, z którym możesz pracować i wdrożyć personalizację.
Wymuś uruchomienie testu za pomocą adb root.
Większość testów VTS wymaga uprawnień roota. Jeśli plik konfiguracji testu zostanie wygenerowany automatycznie, możesz dodać do Android.bp poniższy atrybut.
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 ramki 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"/>
Dodaj kolejne argumenty testowe
Wykonanie niektórych testów gtest może zająć więcej czasu. W takim przypadku możesz dodać opcje uruchamiania testów w pliku XML.
Na przykład ustawienie native-test-timeout w poniższym wpisie umożliwia uruchomienie testu z upływem czasu oczekiwania wynoszącego 3 minuty, a nie z domyślnym limitem 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ć do niego ten atrybut: 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 pokazywać poziom interfejsu API obrazów dostawców na tych urządzeniach. Łącząc te właściwości z funkcją ro.product.first_api_level, pakiety testowe wybierają odpowiednie przypadki testowe dla urządzeń.
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 tym artykule.
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 trwał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 parametr ro.board.first_api_level na wartość vendor/build.prop. Właściwość jest ustawiana przez proces dostawcy init.
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 wyświetlać poziom interfejsu API, który musi obsługiwać obraz dostawcy. Jest on automatycznie ustawiany na wartość ro.product.first_api_level lub ro.board.api_level, jeśli występuje zmienna ro.board.first_api_level, a wartość zmiennej 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 zostanie ustawiona na wersję z ro.product.first_api_level, która jest co najmniej 35. 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 fragmenty na wielu urządzeniach podczas testowania w ramach planów 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.