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.
- O atributo
- 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:
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:
Localizar o manifesto do fornecedor
O VTS verifica o arquivo manifest.xml
do fornecedor nos seguintes
locais e na seguinte ordem:
/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
)/vendor/etc/vintf/manifest.xml
- Arquivo
manifest.xml
do ODM, carregado dos seguintes arquivos na seguinte ordem:/odm/etc/vintf/manifest_$(ro.boot.product.hardware.sku).xml
/odm/etc/vintf/manifest.xml
/odm/etc/manifest_$(ro.boot.product.hardware.sku).xml
/odm/etc/manifest.xml
/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
.