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

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

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

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

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

Типы испытаний СУДС

VTS включает в себя следующие типы испытаний:

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

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

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

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

• /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.
• manifest.xml устройства.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.
• Ишал . Инструмент на устройстве, который показывает информацию времени выполнения о службах 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, предоставляемые устройством. Ход принятия решения:

Рисунок 1. Проверка контролепригодности для тестов на соответствие VTS

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

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

Рисунок 2. Проверка контролепригодности для тестов на несоответствие СДС

Найдите манифест поставщика

VTS проверяет файл manifest.xml поставщика.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 .)