Тестовый набор
Чтобы тест был частью 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.first_api_level
Свойство 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 на сегменты и запускает их на нескольких устройствах.