Verificação de Testabilidade HAL

O Android 9 Vendor Test Suite (VTS) oferece suporte a um método de tempo de execução para usar a configuração do dispositivo para identificar quais testes VTS devem ser ignorados para esse destino de dispositivo.

Flexibilidade de teste VTS

A partir do Android 8.0, os testes VTS são necessários para todos os dispositivos lançados com Android 8.0 e superior. No entanto, nem todos os testes VTS se aplicam a todos os destinos de dispositivo. Por exemplo:

• Se um dispositivo específico não oferece suporte a um teste de HAL (por exemplo, IR), o VTS não precisa executar testes para esse teste de HAL em relação a esse dispositivo de destino.
• Se vários dispositivos compartilharem o mesmo SoC e imagem de fornecedor, mas tiverem funcionalidades de hardware diferentes, o VTS deverá determinar se um teste deve ser executado ou ignorado para um destino de dispositivo específico.

Tipos de teste VTS

O VTS inclui os seguintes tipos de teste:

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

Se um teste é um teste de conformidade ou não depende de qual plano ele pertence. Os testes executados com o plano VTS são considerados testes de conformidade.

Determinando HALs compatíveis

O VTS pode usar os seguintes arquivos para determinar se o destino do dispositivo oferece suporte a um HAL específico:

• /system/compatibility_matrix.xml . Reivindica as instâncias HAL exigidas pela estrutura. 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 a HAL é estritamente exigida pela estrutura.
  • 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 de version para a mesma entrada, indicando que a estrutura 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 superior a 1.1.
• Dispositivo manifest.xml . Reivindica as instâncias 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 de version única para uma entrada, a versão 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 HAL registrados no hwservicemanager . Exemplo:

  android.hardware.vibrator@1.0::IVibrator/default
  

  
  lshal também mostra todos os HALs com implementações de passagem (ou seja, com 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 conformidade, o VTS conta com o manifesto do fornecedor para determinar (e testar) todas as instâncias HAL fornecidas pelo dispositivo. Fluxo de decisão:

Testes de não conformidade

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

Localizando o manifesto do fornecedor

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

1. /vendor/etc/vintf/manifest.xml + manifesto ODM (se o mesmo HAL for definido em ambos os locais, o manifesto ODM substituirá aquele em /vendor/etc/vintf/manifest.xml )
2. /vendor/etc/vintf/manifest.xml
3. Arquivo manifest.xml 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 testabilidade VTS

O vts_testibility_checker é um binário empacotado com VTS e usado pela estrutura de teste VTS em tempo de execução para determinar se um determinado teste HAL é testável 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 vts_testability_check :

• Para um teste de conformidade:

  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>}

Determinando HALs acessados

Para determinar quais HALs são acessadas pelos testes VTS, certifique-se de que cada teste HAL use o modelo VtsHalHidlTargetTestEnvBase para registrar os HALs acessados ​​no teste. A estrutura de teste VTS pode então extrair as HALs registradas ao pré-processar o teste.

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