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

Набор тестов поставщика 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.
• Файл 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 .)