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

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

Гибкость теста VTS

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

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