Suíte de teste
Para que um teste faça parte do VTS, ele deve ter a seguinte configuração em Android.bp .
test_suites: ["vts"],
Além disso, adicionar o teste ao conjunto general-tests permite que ele faça parte de um conjunto de mapeamento de testes usado em verificações pré-envio.
Configuração de teste
Na maioria dos casos, a configuração do teste, que é um arquivo XML usado pela Trade Federation para executar um teste VTS, é gerada automaticamente durante a construção. No entanto, você pode personalizar a configuração de teste.
Crie um arquivo de configuração de teste personalizado
Criar um novo arquivo XML de teste do zero pode ser complicado, pois envolve entender como funciona o equipamento de teste, bem como a diferença entre cada executor de teste. O arquivo de configuração de teste gerado automaticamente foi projetado para facilitar esse processo.
Se for necessário customizar o arquivo XML de teste, você poderá usar o arquivo gerado automaticamente como ponto de partida.
Para localizar o arquivo de configuração de teste gerado automaticamente, primeiro execute o comando make para construir a configuração, conforme mostrado abaixo.
$ m VtsHalUsbV1_1TargetTest
No diretório de construção, você pode procurar o arquivo de configuração com base no nome do módulo, conforme mostrado abaixo.
$ find out/ -name VtsHalUsbV1_1TargetTest.config
Pode haver várias cópias do arquivo e você pode usar qualquer uma delas. Copie o arquivo .config para o diretório onde está o arquivo Android.bp .
Se houver apenas um módulo de teste no arquivo Android.bp , você poderá renomear o arquivo XML para AndroidTest.xml e o sistema de compilação usará isso automaticamente como o arquivo de configuração do módulo de teste. Caso contrário, adicione um atributo test_config ao módulo, conforme mostrado no exemplo abaixo.
test_config: "VtsHalUsbV1_1TargetTest.xml",
Agora você tem um arquivo de configuração de teste para trabalhar e implementar a customização.
Forçar a execução do teste com adb root
A maioria dos testes VTS requerem privilégios de root para serem executados. Se o arquivo de configuração de teste for gerado automaticamente, você poderá adicionar o seguinte atributo ao Android.bp .
require_root: true,
Se o arquivo de configuração de teste for customizado, adicione o seguinte ao arquivo XML de teste.
<target_preparer class="com.android.tradefed.targetprep.RootTargetPreparer"/>
Pare a estrutura durante o teste
Muitos testes VTS não requerem a execução da estrutura Android, e executar o teste com a estrutura interrompida permite que o teste seja executado com estabilidade sem ser afetado por falhas do dispositivo. Se o arquivo de configuração de teste for gerado automaticamente, você poderá adicionar o seguinte atributo ao Android.bp .
disable_framework: true,
Se o arquivo de configuração de teste for customizado, adicione o seguinte ao arquivo XML de teste.
<target_preparer class="com.android.tradefed.targetprep.StopServicesSetup"/>
Adicione argumentos de teste adicionais
Alguns testes gtest podem exigir mais tempo para serem executados. Nesses casos, é possível adicionar opções do executor de teste no arquivo XML.
Por exemplo, a configuração native-test-timeout na entrada a seguir permite que o teste seja executado com um tempo limite de 3 minutos, em vez do padrão de 1 minuto.
<test class="com.android.tradefed.testtype.GTest" >
<option name="native-test-device-path" value="/data/local/tmp" />
<option name="module-name" value="VtsHalNfcV1_0TargetTest" />
<option name="native-test-timeout" value="180000"/>
</test>
Exigir nível mínimo de API
Alguns testes VTS podem ser executados apenas em dispositivos com nível mínimo de API. Se o arquivo de configuração de teste for gerado automaticamente, você poderá adicionar o seguinte atributo ao Android.bp .
test_min_api_level: 29,
Se o arquivo de configuração de teste for customizado, inclua o comando a seguir no arquivo XML de teste.
<object type="module_controller" class="com.android.tradefed.testtype.suite.module.MinApiLevelModuleController">
<option name="min-api-level" value="29" />
</object>
O Android 12 define as propriedades ro.board.first_api_level e ro.board.api_level para mostrar o nível de API das imagens do fornecedor nesses dispositivos. Combinando essas propriedades com ro.product.first_api_level , os conjuntos de testes escolhem casos de teste adequados para os dispositivos.
O Android 13 define ro.vendor.api_level que é definido automaticamente calculando o nível de API do fornecedor necessário usando as propriedades ro.product.first_api_level , ro.board.first_api_level e ro.board.api_level .
ro.board.first_api_level
A propriedade ro.board.first_api_level é o nível da API quando as imagens do fornecedor para um SoC são lançadas pela primeira vez com esta propriedade. Isso não depende do nível de API de inicialização do dispositivo, mas apenas do primeiro nível de API do SoC que define esse valor. O valor é permanente durante a vida útil do SoC.
Para definir ro.board.first_api_level , os fabricantes de dispositivos podem definir BOARD_SHIPPING_API_LEVEL em seu arquivo device.mk , conforme mostrado no exemplo a seguir:
# BOARD_SHIPPING_API_LEVEL sets ro.product.first_api_level to indicate
# the first api level that the device has been commercially launched on.
BOARD_SHIPPING_API_LEVEL := 23
Ele definirá automaticamente a propriedade ro.board.first_api_level para vendor/build.prop no dispositivo. A propriedade é definida pelo processo init do fornecedor.
ro.board.api_level
A propriedade ro.board.api_level é o nível de API atual das imagens do fornecedor para um SoC. Quando o nível de API da imagem do fornecedor que possui ro.board.first_api_level é atualizado, o dispositivo que usa o SoC deve definir a propriedade ro.board.api_level com o nível de API atual da imagem do fornecedor em vez de atualizar o ro.board.first_api_level . Se esta propriedade não estiver definida, ro.board.first_api_level será usado por padrão.
Para definir ro.board.api_level , defina BOARD_API_LEVEL no arquivo device.mk com o valor desejado.
ro.vendor.api_level
A propriedade ro.vendor.api_level foi introduzida no Android 13 para mostrar o nível de API que as imagens do fornecedor devem oferecer suporte. Isso é definido automaticamente para o mínimo de ro.board.api_level (ou ro.board.first_api_level se ro.board.api_level não estiver definido) e ro.product.first_api_level . Os testes para implementação do fornecedor que exigem atualização de imagem do fornecedor podem ser excluídos dos requisitos do fornecedor para o SoC referindo-se a esta propriedade.
Processo de fragmentação usando VTS
Para Android versão 10 ou superior, você pode realizar o processo de fragmentação em vários dispositivos enquanto testa com os planos VTS e CTS-on-GSI seguindo as instruções abaixo.
run vts --shard-count <number of devices> -s <device serial> ...
Este comando divide o plano VTS em fragmentos e os executa em vários dispositivos.
run cts-on-gsi --shard-count <number of devices> -s <device serial> -s ...
Este comando divide o plano CTS-on-GSI em fragmentos e os executa em vários dispositivos.