Набор тестов
Чтобы тест был частью 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. Если версия приложения ro.product.first_api_level больше или равна 35, она будет заменена на соответствующий уровень API поставщика. Тесты для реализации поставщика, требующие обновления образа поставщика, могут быть исключены из требований поставщика для 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 на фрагменты и запускает их на нескольких устройствах.