Verificação da capacidade de teste de HAL

O pacote de testes do fornecedor (VTS, na sigla em inglês) do Android 9 oferece suporte a um método de tempo de execução para usar a configuração do dispositivo para identificar quais testes do VTS serão ignorados para esse destino de dispositivo.

Flexibilidade de teste do VTS

A partir do Android 8.0, os testes do VTS são necessários para todos os dispositivos lançados com o Android 8.0 e versões mais recentes. No entanto, nem todos os testes do VTS se aplicam a todos os dispositivos de destino. Exemplo:

  • Se um dispositivo específico não oferecer suporte a uma HAL de teste (por exemplo, IR), o VTS não precisará executar testes para essa HAL no destino do dispositivo.
  • Se vários dispositivos compartilham o mesmo SoC e imagem do fornecedor, mas têm funcionalidades de hardware diferentes, a VTS precisa determinar se um teste precisa ser executado ou ignorado para um destino de dispositivo específico.

Tipos de testes VTS

O VTS inclui os seguintes tipos de teste:

  • Os testes de conformidade garantem a compatibilidade entre o framework e as partições do fornecedor. Esses testes precisam ser executados (e aprovados) em dispositivos lançados com o Android 8.0 ou mais recente.
  • Os testes de não conformidade ajudam os fornecedores a melhorar a qualidade do produto (performance/fuzzing etc.). Esses testes são opcionais para fornecedores.

A classificação de um teste como de conformidade depende do plano a que ele pertence. Os testes executados com o plano VTS são considerados de conformidade.

Determinar os HALs compatíveis

O VTS pode usar os seguintes arquivos para determinar se o destino do dispositivo é compatível com uma HAL específica:

  • /system/compatibility_matrix.xml. Declara as instâncias do HAL exigidas pelo framework. Exemplo:
    <hal format="hidl" optional="true">
        <name>android.hardware.vibrator</name>
        <version>1.0-1</version>
        <interface>
           <name>IVibrator</name>
           <instance>default</instance>
        </interface>
    </hal>
    • O atributo optional indica se o HAL é estritamente necessário para o framework.
    • O arquivo pode conter várias entradas para o mesmo HAL (com o mesmo nome), mas com versões e interfaces diferentes.
    • O arquivo pode conter várias configurações version para a mesma entrada, indicando que o framework pode funcionar com versões diferentes.
    • version1.0-1 significa que o framework pode funcionar com a versão 1.0 mais baixa e não requer uma versão mais recente que 1.1.
  • Dispositivo manifest.xml. Declara as instâncias do HAL fornecidas pelo fornecedor. Exemplo:
    <hal format="hidl">
        <name>android.hardware.vibrator</name>
        <transport>hwbinder</transport>
        <version>1.2</version>
        <interface>
            <name>IVibrator</name>
           <instance>default</instance>
        </interface>
    </hal>
    • O arquivo pode conter várias entradas para o mesmo HAL (com o mesmo nome), mas com versões e interfaces diferentes.
    • Se o arquivo contiver apenas uma configuração version para uma entrada, version1.2 significa que o fornecedor oferece suporte a todas as versões de 1.0 a 1.2.
  • lshal. Uma ferramenta no dispositivo que mostra informações de tempo de execução sobre os serviços da HAL registrados com o hwservicemanager. Exemplo:
    android.hardware.vibrator@1.0::IVibrator/default

    lshal também mostra todos os HALs com implementações de transferência direta (ou seja, que têm o arquivo -impl.so correspondente no dispositivo). Exemplo:
    android.hardware.nfc@1.0::I*/* (/vendor/lib/hw/)
    android.hardware.nfc@1.0::I*/* (/vendor/lib64/hw/)

Testes de conformidade

Para testes de compliance, o VTS depende do manifesto do fornecedor para determinar (e testar) todas as instâncias da HAL fornecidas pelo dispositivo. Fluxo de decisão:

Verificação de testabilidade para compliance

Figura 1. Verificação de testabilidade para testes de compliance do VTS

Testes de não conformidade

Para testes de não conformidade, o VTS depende do manifesto do fornecedor e das saídas lshal para determinar (e testar) as HALs experimentais não reivindicadas no arquivo manifest.xml. Fluxo de decisão:

Verificação de não conformidade

Figura 2. Verificação de testabilidade para testes de não conformidade do VTS

Localizar o manifesto do fornecedor

O VTS verifica o arquivo manifest.xml do fornecedor nos seguintes locais e na seguinte ordem:

  1. /vendor/etc/vintf/manifest.xml + Manifesto ODM (se a mesma HAL for definida nos dois lugares, o manifesto ODM vai substituir o que está em /vendor/etc/vintf/manifest.xml)
  2. /vendor/etc/vintf/manifest.xml
  3. Arquivo manifest.xml do ODM, carregado dos seguintes arquivos na seguinte ordem:
    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

Verificador de capacidade de teste de VTS

O vts_testibility_checker é um binário empacotado com o VTS e usado pelo framework de teste do VTS no momento da execução para determinar se um determinado teste HAL pode ser testado ou não. Ele é baseado em libvintf para carregar e analisar o arquivo de manifesto do fornecedor e implementa o fluxo de decisão descrito na seção anterior.

Para usar o app vts_testability_check:

  • Para um teste de compliance:
    vts_testability_check -c -b <bitness>  <hal@version>
  • Para um teste de não conformidade:
    vts_testability_check -b <bitness>  <hal@version>

A saída de vts_testability_check usa o seguinte formato json:

{testable: <True/False> Instances: <list of instance names of HAL service>}

Determinar as HALs acessadas

Para determinar quais HALs são acessados pelos testes VTS, verifique se cada teste HAL usa o modelo VtsHalHidlTargetTestEnvBase para registrar as HALs acessadas no teste. O framework de teste do VTS pode extrair os HALs registrados durante o pré-processamento do teste.

Para testes de compliance, você também pode verificar /system/etc/vintf/manifest.xml. Se um HAL for definido aqui, o VTS vai testá-lo. Para os serviços HAL fornecidos pelo sistema (por exemplo, graphics.composer/vr), os HALs são declarados em /system/manifest.xml.