Проверка тестируемости 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 или выше.
  • Несоблюдение тесты поставщиков помогают улучшить качество продукции (производительность / Fuzzing и т.д.). Эти тесты не являются обязательными для поставщиков.

Является ли тест проверкой на соответствие или нет, зависит от того, к какому плану он принадлежит. Тесты , которые выполняются с целью СДС считаются тесты на соответствие.

Определение поддерживаемых 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 также показывает все Хальса , что со сквозными реализаций (т.е. имеющих соответствующий -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. Тестируемость для испытаний соответствия СДС

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

Для испытаний несоблюдения, СДС зависит от манифеста поставщика и lshal выходов , чтобы определить (и тест) экспериментальные ГАЛС не заявленный в manifest.xml файл. Процесс принятия решений:

Testability check for non-compliance

Рисунок 2. Проверка Тестируемости для испытаний несоблюдения СДСА

Поиск манифеста поставщика

СДС проверяет поставщик 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 и используется тест рамках СДС во время выполнения , чтобы определить , является ли данный тест 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 ), Хальса объявлены в /system/manifest.xml .)