Набор тестов
Для того чтобы тест стал частью 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",
Теперь у вас есть тестовый конфигурационный файл, с которым можно работать и внедрять изменения.
Принудительное выполнение теста с правами root через adb
Для запуска большинства тестов 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 на сегменты и запускает их на нескольких устройствах.