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 teste usado em verificações de pré-envio.
Configuração de teste
Na maioria dos casos, a configuração de 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 do teste.
Crie um arquivo de configuração de teste personalizado
Criar um novo arquivo XML de teste a partir do zero pode ser complicado, pois envolve entender como o equipamento de teste funciona, 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 você precisar personalizar o arquivo XML de teste, 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 criar a configuração, conforme mostrado abaixo.
$ m VtsHalUsbV1_1TargetTest
No diretório de compilaçã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 o usará 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 requer privilégio de root para executar. Se o arquivo de configuração de teste for gerado automaticamente, você poderá adicionar o seguinte atributo a Android.bp .
require_root: true,
Se o arquivo de configuração de teste for customizado, inclua o seguinte no arquivo XML de teste.
<target_preparer class="com.android.tradefed.targetprep.RootTargetPreparer"/>
Parar framework durante o teste
Muitos testes VTS não exigem a execução do framework Android, e executar o teste com o framework parado permite que o teste seja executado com estabilidade sem ser afetado por flakes do dispositivo. Se o arquivo de configuração de teste for gerado automaticamente, você poderá adicionar o seguinte atributo a Android.bp .
disable_framework: true,
Se o arquivo de configuração de teste for customizado, inclua o seguinte no arquivo XML de teste.
<target_preparer class="com.android.tradefed.targetprep.StopServicesSetup"/>
Adicionar argumentos de teste adicionais
Alguns testes gtest podem exigir mais tempo para serem executados. Nesses casos, você pode 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 a Android.bp .
test_min_api_level: 29,
Se o arquivo de configuração de teste for customizado, inclua o seguinte comando 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 teste escolhem os 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 depende 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 o 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 for definida, ro.board.first_api_level será usado por padrão.
Para definir o 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 ao qual 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 . Testes para implementação do fornecedor que requerem 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 executar o processo de sharding em vários dispositivos durante o teste 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.