Konfiguracja testowa

Zadbaj o dobrą organizację dzięki kolekcji Zapisuj i kategoryzuj treści zgodnie ze swoimi preferencjami.

Zestaw testów

Aby test został częścią VTS, musi mieć to ustawienie w usłudze Android.bp.

test_suites: ["vts"],

Dodanie testu do pakietu general-tests umożliwia 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 dostosowanego testowego pliku konfiguracji

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 ułatwia ten proces.

Jeśli musisz dostosować testowy plik XML, możesz użyć polecenia automatycznie wygenerowanego pliku.

Aby znaleźć wygenerowany automatycznie plik konfiguracji testowej, najpierw uruchom polecenie make, aby utworzyć konfigurację, jak pokazano poniżej.

$ m VtsHalUsbV1_1TargetTest

W katalogu build out możesz wyszukać plik konfiguracji na podstawie nazwy modułu, jak pokazano poniżej.

$ find out/ -name VtsHalUsbV1_1TargetTest.config

Taki plik może mieć wiele kopii i możesz korzystać z każdej 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, zmień nazwę pliku XML na AndroidTest.xml, aby system kompilacji używa go jako pliku konfiguracji modułu testowego. W przeciwnym razie dodaj do modułu atrybut test_config, tak jak w tagu przykład poniżej.

test_config: "VtsHalUsbV1_1TargetTest.xml",

Masz teraz testowy plik konfiguracji, z którym możesz pracować i wdrożyć personalizację.

Wymuś test z użyciem poziomu głównego adb

Uruchamianie większości testów VTS wymaga uprawnień użytkownika root. 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 frameworku podczas testu

Wiele testów VTS nie wymaga platformy Androida do uruchomienia test z zatrzymaną platformą umożliwia działanie testu ze stabilnością i nie pada ofiarą płatków na urządzeniu. 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 następujący sposób pozwala na uruchomienie testu z upływem 3 minut, a nie domyślna wartość to 1 minuta.

   <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 interfejsu API. Jeśli testowy plik konfiguracji jest generowany automatycznie, dla atrybutu Android.bp.

min_shipping_api_level: 29,

lub

vsr_min_shipping_api_level: 202404,

Jeśli plik konfiguracji testu jest dostosowany, dodaj parametr do testowego pliku XML.

   <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 na poziomie 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. Łącząc te właściwości z usługą ro.product.first_api_level, zestawy testowe dobierają odpowiednie przypadki testowe dla urządzeń.

Android 13 definiuje zasadę ro.vendor.api_level, która jest jest ustawiany automatycznie przez obliczenie wymaganego poziomu interfejsu API dostawcy za pomocą ro.product.first_api_level, ro.board.first_api_level i ro.board.api_level usług.

Więcej informacji znajdziesz w artykule Poziom interfejsu Vendor API.

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 udostępniane z tą właściwością. 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ść. jest stała przez cały okres użytkowania układów SOC.

Aby ustawić ro.board.first_api_level, producenci mogą określić BOARD_SHIPPING_API_LEVEL w pliku device.mk, jak w tym przykładzie przykład:

  # 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

Zostaną automatycznie zdefiniowane właściwość ro.board.first_api_level jako vendor/build.prop. Właściwość jest konfigurowana przez dostawcę init proces tworzenia konta.

ro.board.api_level (poziom ro.board.api)

Właściwość ro.board.api_level to aktualny poziom interfejsu API dostawcy. obrazy w formacie YYYYMM, w którym interfejs API dostawcy został zablokowany. Jest ustawiane automatycznie 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. Ta wartość jest automatycznie ustawiona jako ro.product.first_api_level lub ro.board.api_level, jeśli Wartość ro.board.first_api_level jest obecna, a ro.board.api_level ma wartość poprzedni poziom interfejsu API niż ro.product.first_api_level. Wersja zostanie zastąp odpowiednim poziomem interfejsu API dostawcy, jeśli jest ustawiony na wersję od ro.product.first_api_level, która jest większa lub równa 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 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 w wielu urządzenia.