Тестовый набор
Чтобы тест стал частью VTS, он должен иметь следующую настройку в Android.bp .
test_suites: ["vts"],
Кроме того, добавление теста в набор general-tests позволяет сделать его частью набора сопоставления тестов, используемого при проверках перед отправкой.
Тестовая конфигурация
В большинстве случаев тестовая конфигурация, которая представляет собой XML-файл, используемый Trade Federation для запуска теста VTS, автоматически генерируется во время сборки. Однако вы можете настроить тестовую конфигурацию.
Создайте индивидуальный файл конфигурации теста
Создание нового тестового XML-файла с нуля может быть сложным, поскольку это требует понимания того, как работает тестовая среда, а также различий между каждым исполнителем тестов. Автоматически сгенерированный тестовый конфигурационный файл призван облегчить этот процесс.
Если вам необходимо настроить тестовый XML-файл, вы можете использовать автоматически сгенерированный файл в качестве отправной точки.
Чтобы найти автоматически сгенерированный тестовый файл конфигурации, сначала выполните команду make для создания конфигурации, как показано ниже.
$ m VtsHalUsbV1_1TargetTest
В каталоге сборки вы можете найти файл конфигурации по имени модуля, как показано ниже.
$ find out/ -name VtsHalUsbV1_1TargetTest.config
Может быть несколько копий файла, и вы можете использовать любую из них. Скопируйте файл .config в каталог, где находится файл Android.bp .
Если в файле Android.bp только один тестовый модуль, вы можете переименовать XML-файл в AndroidTest.xml , и система сборки автоматически использует его в качестве файла конфигурации тестового модуля. В противном случае добавьте атрибут test_config к модулю, как показано в примере ниже.
test_config: "VtsHalUsbV1_1TargetTest.xml",
Теперь у вас есть тестовый файл конфигурации, с которым можно работать и выполнять настройку.
Принудительно запустить тест с помощью adb root
Для запуска большинства тестов VTS требуются права root. Если файл конфигурации теста сгенерирован автоматически, вы можете добавить следующий атрибут в Android.bp .
require_root: true,
Если тестовый файл конфигурации настроен, добавьте в тестовый XML-файл следующее.
<target_preparer class="com.android.tradefed.targetprep.RootTargetPreparer"/>
Остановить фреймворк во время теста
Многие тесты VTS не требуют запуска фреймворка Android, а запуск теста с остановленным фреймворком позволяет тесту работать стабильно, не подвергаясь влиянию сбоев устройства. Если файл конфигурации теста генерируется автоматически, вы можете добавить следующий атрибут в Android.bp .
disable_framework: true,
Если тестовый файл конфигурации настроен, добавьте в тестовый XML-файл следующее.
<target_preparer class="com.android.tradefed.targetprep.StopServicesSetup"/>
Добавить дополнительные тестовые аргументы
Некоторые тесты gtest могут потребовать больше времени для запуска. В таких случаях вы можете добавить опции тестового раннера в XML-файл.
Например, настройка native-test-timeout в следующей записи позволяет запустить тест с тайм-аутом 3 минуты вместо значения по умолчанию 1 минута.
<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>
Требуемый минимальный уровень API
Некоторые тесты VTS могут работать только на устройствах с минимальным уровнем API. Если файл конфигурации теста генерируется автоматически, вы можете добавить следующий атрибут в Android.bp .
min_shipping_api_level: 29,
или
vsr_min_shipping_api_level: 202404,
Если тестовый файл конфигурации настроен, добавьте следующую команду в тестовый XML-файл.
<object type="module_controller" class="com.android.tradefed.testtype.suite.module.ShippingApiLevelModuleController">
<option name="min-api-level" value="29" />
</object>
или
<object type="module_controller" class="com.android.tradefed.testtype.suite.module.ShippingApiLevelModuleController">
<option name="vsr-min-api-level" value="202404" />
</object>
Свойства уровня API
Android 12 определяет свойства ro.board.first_api_level и ro.board.api_level для отображения уровня API образов поставщика на этих устройствах. Объединяя эти свойства с ro.product.first_api_level , тестовые наборы выбирают соответствующие тестовые случаи для устройств.
Android 13 определяет ro.vendor.api_level , который автоматически устанавливается путем расчета требуемого уровня API поставщика с использованием свойств ro.product.first_api_level , ro.board.first_api_level и ro.board.api_level .
Более подробную информацию см. в разделе Уровень API поставщика .
ro.board.первый_уровень_api
Свойство ro.board.first_api_level — это уровень API, когда образы поставщика для SoC, квалифицированного для заморозки поставщиком, впервые выпускаются с этим свойством. Это не зависит от уровня API запуска устройства, а зависит только от первого уровня API SoC, который определяет это значение. Значение является постоянным на протяжении всего срока службы SoC.
Чтобы задать ro.board.first_api_level , производители устройств могут определить BOARD_SHIPPING_API_LEVEL в своем файле device.mk , как показано в следующем примере:
# 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
Он автоматически определит свойство ro.board.first_api_level для vendor/build.prop на устройстве. Свойство устанавливается процессом init поставщика.
ro.board.api_level
Свойство ro.board.api_level — это текущий уровень API поставщика для образов поставщика, который имеет формат YYYYMM , в котором API поставщика было заморожено. Он автоматически устанавливается системой сборки.
ro.vendor.api_level
Свойство ro.vendor.api_level было введено в Android 13 для отображения уровня API, который должны поддерживать образы поставщика. Оно автоматически устанавливается на ro.product.first_api_level или ro.board.api_level , если присутствует ro.board.first_api_level и ro.board.api_level установлен на более ранний уровень API, чем ro.product.first_api_level . Версия будет заменена соответствующим уровнем API поставщика, если она установлена на версию из ro.product.first_api_level , которая больше или равна 35 . Тесты для реализации поставщика, требующие обновления образа поставщика, могут быть исключены из требований поставщика для SoC путем ссылки на это свойство.
Процесс шардинга с использованием VTS
Для Android версии 10 или выше вы можете выполнить процесс шардинга на нескольких устройствах при тестировании с планами VTS и CTS-on-GSI, следуя инструкциям ниже.
run vts --shard-count <number of devices> -s <device serial> ...
Эта команда разбивает план VTS на части и запускает их на нескольких устройствах.
run cts-on-gsi --shard-count <number of devices> -s <device serial> -s ...
Эта команда разбивает план CTS-on-GSI на части и запускает их на нескольких устройствах.