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