Испытательная установка

Тестирование

Чтобы тест был частью 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 .

test_min_api_level: 29,

Если тестовый файл конфигурации настроен, добавьте следующую команду в тестовый XML-файл.

   <object type="module_controller" class="com.android.tradefed.testtype.suite.module.MinApiLevelModuleController">
       <option name="min-api-level" value="29" />
   </object>

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 .

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 образов поставщиков для SoC. Когда уровень API образа поставщика, имеющего ro.board.first_api_level , обновляется, устройство, использующее SoC, должно определить свойство ro.board.api_level с текущим уровнем API образа поставщика вместо обновления ro.board.first_api_level . . Если это свойство не установлено, по умолчанию будет использоваться ro.board.first_api_level .

Чтобы установить ro.board.api_level , определите BOARD_API_LEVEL в файле device.mk с нужным значением.

ro.vendor.api_level

Свойство ro.vendor.api_level было введено в Android 13, чтобы показать уровень API, который должны поддерживать изображения поставщиков. Для этого параметра автоматически устанавливается минимальное значение ro.board.api_level (или ro.board.first_api_level , если ro.board.api_level не определен) и ro.product.first_api_level . Тесты реализации поставщика, требующие обновления образа поставщика, могут быть исключены из требований поставщика к 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 на сегменты и запускает их на нескольких устройствах.

,

Тестирование

Чтобы тест был частью 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 .

test_min_api_level: 29,

Если тестовый файл конфигурации настроен, добавьте следующую команду в тестовый XML-файл.

   <object type="module_controller" class="com.android.tradefed.testtype.suite.module.MinApiLevelModuleController">
       <option name="min-api-level" value="29" />
   </object>

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 .

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 образов поставщиков для SoC. Когда уровень API образа поставщика, имеющего ro.board.first_api_level , обновляется, устройство, использующее SoC, должно определить свойство ro.board.api_level с текущим уровнем API образа поставщика вместо обновления ro.board.first_api_level . . Если это свойство не установлено, по умолчанию будет использоваться ro.board.first_api_level .

Чтобы установить ro.board.api_level , определите BOARD_API_LEVEL в файле device.mk с нужным значением.

ro.vendor.api_level

Свойство ro.vendor.api_level было введено в Android 13, чтобы показать уровень API, который должны поддерживать изображения поставщиков. Для этого параметра автоматически устанавливается минимальное значение ro.board.api_level (или ro.board.first_api_level , если ro.board.api_level не определен) и ro.product.first_api_level . Тесты реализации поставщика, требующие обновления образа поставщика, могут быть исключены из требований поставщика к 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 на сегменты и запускает их на нескольких устройствах.