Verificação da capacidade de teste de HAL

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

Flexibilidade do teste VTS

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

• Se um dispositivo específico não oferecer suporte a um teste de HAL (por exemplo, IR), o VTS oferecerá não precisará executar testes para esse teste de HAL em relação a esse destino de dispositivo.
• Se vários dispositivos compartilham o mesmo SoC e imagem do fornecedor, mas têm diferentes funcionalidades de hardware, a VTS deve determinar se um serviço deve 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 partições de fornecedor. Esses testes precisam ser executados (e aprovados) dispositivos lançados com o Android 8.0 ou superior.
• Os testes de não conformidade ajudam os fornecedores a melhorar qualidade (desempenho/fuzzing etc.). Esses testes são opcionais para os fornecedores.

Se um teste é de compliance ou não depende do plano a que ele pertence Testes executados com VTS são considerados testes de conformidade.

Determinar HALs com suporte

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: Reivindica as instâncias HAL exigidos 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 a HAL é estritamente exigidos pelo framework.
  • O arquivo pode conter várias entradas para a mesma 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 o framework pode funcionar com versões diferentes.
  • version1.0-1 significa que o framework pode trabalhar com a camada versão 1.0 e não exige uma versão posterior à 1.1.
• Dispositivo manifest.xml. Reivindica as instâncias da 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 a mesma HAL (com o mesmo nome) mas com versões e interfaces diferentes.
  • Se o arquivo contiver apenas uma única configuração version para uma entrada, version1.2 significa que o fornecedor oferece suporte a todas as versões de 1.0~1.2.
• lshal. Uma ferramenta no dispositivo que mostra informações sobre o tempo de execução os serviços da HAL registrados no hwservicemanager. Exemplo:

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

  
  lshal também mostra todas as HALs com passagem (ou seja, ter o arquivo -impl.so correspondente em do 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 depende do manifesto do fornecedor para determinar (e teste) todas as instâncias de HAL fornecidas pelo dispositivo. Fluxo de decisão:

.

Testes de não conformidade

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

.

Localizar o manifesto do fornecedor

O VTS verifica o arquivo manifest.xml do fornecedor no seguinte lugares na seguinte ordem:

1. /vendor/etc/vintf/manifest.xml + manifesto ODM (se a mesma HAL for definido nos dois lugares, o manifesto ODM substituirá o /vendor/etc/vintf/manifest.xml)
2. /vendor/etc/vintf/manifest.xml
3. Arquivo ODM manifest.xml, carregado a partir dos seguintes arquivos em 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 testes VTS

A vts_testibility_checker é um binário empacotado com VTS e usado pelo framework de teste VTS em tempo de execução para determinar se um determinado teste HAL é testáveis ou não. Ela é baseada libvintf para carregar e analisar o arquivo de manifesto do fornecedor e implementar o fluxo de decisão descritos na seção anterior.

Para usar o app 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 JSON formato:

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

Determinar as HALs acessadas

Para determinar quais HALs são acessadas pelos testes VTS, verifique se cada teste de HAL usa o VtsHalHidlTargetTestEnvBase para registrar as HALs acessadas no teste. Os testes VTS pode extrair as HALs registradas ao pré-processar o teste.

Para testes de conformidade, também é possível verificar /system/etc/vintf/manifest.xml: Se uma HAL for definida aqui, o VTS deve testá-lo. Para os serviços HAL fornecidos pelo sistema (por exemplo, graphics.composer/vr), as HALs serão declaradas /system/manifest.xml.