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

Android 9 Vendor Test Suite (VTS) поддерживает метод времени выполнения для использования конфигурации устройства, чтобы определить, какие тесты 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 non-compliance

Рисунок 2. Проверка тестируемости для испытаний на несоответствие VTS

Расположение манифеста поставщика

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 .)