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

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

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

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

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

Типы тестов 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. Заявляет права на экземпляры 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 проверяет файл поставщика 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.)