Проверка тестируемости HAL

Набор тестов Android 9 Vendor Test Suite (VTS) поддерживает метод, позволяющий во время выполнения использовать конфигурацию устройства для определения того, какие тесты VTS следует пропустить для целевого устройства.

гибкость тестирования VTS

Начиная с Android 8.0, VTS-тесты требуются для всех устройств, выпущенных с Android 8.0 и выше. Однако не все VTS-тесты применимы ко всем целевым устройствам. Например:

• Если конкретное устройство не поддерживает тестовый HAL (например, ИК-порт), VTS не нужно запускать тесты для этого HAL на целевом устройстве.
• Если несколько устройств используют один и тот же SoC и образ производителя, но имеют разные аппаратные функции, VTS должен определить, следует ли запускать тест для конкретного целевого устройства или пропустить его.

типы тестов VTS

В рамках системы VTS проводятся следующие виды испытаний:

• Тесты на соответствие требованиям обеспечивают совместимость между разделами фреймворка и поставщика. Эти тесты необходимо запускать (и успешно проходить) на устройствах, выпущенных под управлением Android 8.0 или выше.
• Тестирование на несоответствие стандартам помогает поставщикам улучшить качество продукции (производительность/фаззинг и т. д.). Для поставщиков эти тесты являются необязательными.

Является ли тест проверкой на соответствие требованиям или нет, зависит от того, к какому тарифному плану он относится. Тесты, выполняемые в рамках плана VTS, считаются проверками на соответствие требованиям.

Определите поддерживаемые HAL.

Для определения того, поддерживает ли целевое устройство определенный HAL, VTS может использовать следующие файлы:

• /system/compatibility_matrix.xml . Запрашивает экземпляры HAL, необходимые для работы фреймворка. Пример:

  <hal format="hidl" optional="true">
      <name>android.hardware.vibrator</name>
      <version>1.0-1</version>
      <interface>
         <name>IVibrator</name>
         <instance>default</instance>
      </interface>
  </hal>

  • Этот optional атрибут указывает, является ли HAL обязательным для использования данной платформой.
  • Файл может содержать несколько записей для одного и того же HAL (с одинаковым именем), но с разными версиями и интерфейсами.
  • Файл может содержать несколько конфигураций version для одной и той же записи, что указывает на то, что фреймворк может работать с разными версиями.
  • version1.0-1 означает, что фреймворк может работать с самой ранней версией 1.0 и не требует версии выше 1.1.
• Файл device manifest.xml . Запрашивает экземпляры HAL, предоставленные поставщиком. Пример:

  <hal format="hidl">
      <name>android.hardware.vibrator</name>
      <transport>hwbinder</transport>
      <version>1.2</version>
      <interface>
          <name>IVibrator</name>
         <instance>default</instance>
      </interface>
  </hal>

  • Файл может содержать несколько записей для одного и того же HAL (с одинаковым именем), но с разными версиями и интерфейсами.
  • Если файл содержит только конфигурацию одной version для записи, version1.2 означает, что поставщик поддерживает все версии от 1.0 до 1.2.
• lshal . Инструмент на устройстве, отображающий информацию о службах HAL, зарегистрированных в hwservicemanager , в режиме реального времени. Пример:

  android.hardware.vibrator@1.0::IVibrator/default

  
  lshal также отображает все HAL с реализацией сквозной передачи (т.е. имеющие соответствующий файл -impl.so на устройстве). Пример:

  android.hardware.nfc@1.0::I*/* (/vendor/lib/hw/)
  android.hardware.nfc@1.0::I*/* (/vendor/lib64/hw/)

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

Для проверки соответствия требованиям VTS использует манифест поставщика для определения (и проверки) всех экземпляров HAL, предоставляемых устройством. Последовательность принятия решений:

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

Для проверки на несоответствие требованиям VTS использует манифест поставщика и выходные данные lshal для определения (и проверки) экспериментальных HAL, не указанных в файле manifest.xml . Схема принятия решений:

Найдите список поставщиков.

VTS проверяет наличие файла vendor manifest.xml в следующих местах в указанном порядке:

1. /vendor/etc/vintf/manifest.xml + манифест ODM (Если в обоих местах определен один и тот же HAL, манифест ODM переопределяет манифест в /vendor/etc/vintf/manifest.xml )
2. /vendor/etc/vintf/manifest.xml
3. Файл ODM manifest.xml загружается из следующих файлов в указанном порядке:
   1. /odm/etc/vintf/manifest_$(ro.boot.product.hardware.sku).xml
   2. /odm/etc/vintf/manifest.xml
   3. /odm/etc/manifest_$(ro.boot.product.hardware.sku).xml
   4. /odm/etc/manifest.xml
   5. /vendor/manifest.xml

Проверка тестируемости VTS

vts_testibility_checker — это исполняемый файл, входящий в состав VTS и используемый тестовой средой VTS во время выполнения для определения того, можно ли тестировать тот или иной HAL-тест. Он основан на libvintf для загрузки и анализа файла манифеста поставщика и реализует алгоритм принятия решений, описанный в предыдущем разделе.

Для использования функции vts_testability_check :

• Для проверки на соответствие требованиям:

  vts_testability_check -c -b <bitness>  <hal@version>

• Для проверки на несоответствие:

  vts_testability_check -b <bitness>  <hal@version>

Результат работы функции vts_testability_check имеет следующий формат JSON:

{testable: <True/False> Instances: <list of instance names of HAL service>}

Определите доступные HAL-ы

Чтобы определить, к каким HAL обращаются тесты VTS, убедитесь, что каждый тест HAL использует шаблон VtsHalHidlTargetTestEnvBase для регистрации HAL(-ов), к которым осуществляется доступ в тесте. Затем тестовая среда VTS сможет извлечь зарегистрированные HAL при предварительной обработке теста.

Для проверки соответствия требованиям можно также проверить файл /system/etc/vintf/manifest.xml . Если HAL определен здесь, VTS должен его проверить. (Для служб HAL, предоставляемых системой (например, graphics.composer/vr ), HAL объявляются в файле /system/manifest.xml .)