Проверка тестируемости 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, предоставляемые устройством. Ход принятия решения:

Testability check for compliance

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

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

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

Testability check for noncompliance

Рисунок 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 .)