Pacote de testes
Para que um teste faça parte do VTS, ele precisa ter a seguinte configuração
em Android.bp.
test_suites: ["vts"],
Além disso, adicionar o teste ao pacote general-tests permite que ele faça
parte de um conjunto de mapeamento de teste usado nas verificações de pré-envio.
Configuração do 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 o build. No entanto, é possível personalizar a configuração do teste.
Criar um arquivo de configuração de teste personalizado
Criar um novo arquivo XML de teste do zero pode ser complicado, porque envolve entender como o conjunto de testes 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, use 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 build, você pode pesquisar o arquivo de configuração com base no nome do módulo, conforme mostrado abaixo.
$ find out/ -name VtsHalUsbV1_1TargetTest.config
É possível ter várias cópias do arquivo, e você pode usar qualquer uma delas.
Copie o arquivo .config para o diretório
em que o arquivo Android.bp está.
Se houver apenas um módulo de teste no arquivo Android.bp, renomeie o arquivo XML para AndroidTest.xml. O sistema de build vai usar esse arquivo como o arquivo de configuração do módulo de teste automaticamente. 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 personalização.
Forçar a execução do teste com a raiz do adb
A maioria dos testes VTS exige privilégio raiz para ser executada. Se o arquivo de configuração
do teste for gerado automaticamente, adicione o atributo a seguir a Android.bp.
require_root: true,
Se o arquivo de configuração de teste for personalizado, adicione o seguinte ao arquivo XML de teste.
<target_preparer class="com.android.tradefed.targetprep.RootTargetPreparer"/>
Interromper framework durante o teste
Muitos testes do VTS não exigem que o framework do Android seja executado. A execução do
teste com o framework interrompido permite que o teste seja executado com estabilidade
sem ser afetado por falhas do dispositivo. Se o arquivo de configuração
do teste for gerado automaticamente, adicione o atributo a seguir a Android.bp.
disable_framework: true,
Se o arquivo de configuração do teste for personalizado, adicione o seguinte ao arquivo XML do teste.
<target_preparer class="com.android.tradefed.targetprep.StopServicesSetup"/>
Adicionar outros argumentos de teste
Alguns testes gtest podem levar mais tempo para serem executados. Nesses casos, é possível adicionar opções de execução 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 um nível mínimo de API
Alguns testes do VTS só podem ser executados em dispositivos com nível mínimo de API. Se o
arquivo de configuração de teste for gerado automaticamente, adicione o atributo
a seguir a Android.bp.
min_shipping_api_level: 29,
ou
vsr_min_shipping_api_level: 202404,
Se o arquivo de configuração de teste for personalizado, adicione o comando abaixo ao arquivo XML de teste.
<object type="module_controller" class="com.android.tradefed.testtype.suite.module.ShippingApiLevelModuleController">
<option name="min-api-level" value="29" />
</object>
ou
<object type="module_controller" class="com.android.tradefed.testtype.suite.module.ShippingApiLevelModuleController">
<option name="vsr-min-api-level" value="202404" />
</object>
Propriedades no nível da API
O Android 12 define as propriedades ro.board.first_api_level e
ro.board.api_level para mostrar o nível da API das imagens do fornecedor
nesses dispositivos. Combinando essas propriedades com ro.product.first_api_level,
os pacotes de testes escolhem os casos de teste adequados para os dispositivos.
O Android 13 define ro.vendor.api_level, que é
definido automaticamente calculando o nível da API do fornecedor necessário usando as
propriedades ro.product.first_api_level, ro.board.first_api_level e
ro.board.api_level.
Para mais detalhes, consulte Nível da API do fornecedor.
ro.board.first_api_level
A propriedade ro.board.first_api_level é o nível da API quando as imagens do fornecedor
de um SoC qualificado para
bloqueio do fornecedor são lançadas
pela primeira vez com essa propriedade. Isso não depende do nível da API de inicialização do dispositivo,
mas depende apenas do primeiro nível da 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 no arquivo device.mk, conforme mostrado no exemplo
abaixo:
# 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 vai definir automaticamente a propriedade ro.board.first_api_level como
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 atual da API do fornecedor das imagens
do fornecedor que tem o formato YYYYMM em que a API do fornecedor foi congelada. Ele é
definido automaticamente pelo sistema de build.
ro.vendor.api_level
A propriedade ro.vendor.api_level foi introduzida no
Android 13 para mostrar o nível da API que as imagens do fornecedor
precisam oferecer suporte. Ele é definido automaticamente como
ro.product.first_api_level ou ro.board.api_level se
ro.board.first_api_level estiver presente e ro.board.api_level estiver definido como um
nível de API anterior a ro.product.first_api_level. A versão será
substituída pelo nível correspondente da API do fornecedor se estiver definida como a versão
de ro.product.first_api_level, que é maior ou igual a 35. Os testes
para implementação do fornecedor que exigem upgrade de imagem do fornecedor podem ser excluídos
dos requisitos do fornecedor para o SoC ao se referir a essa propriedade.
Processo de fragmentação usando VTS
No Android versão 10 ou mais recente, é possível realizar o processo de fragmentação em vários dispositivos enquanto testa com planos VTS e CTS-on-GSI seguindo as instruções abaixo.
run vts --shard-count <number of devices> -s <device serial> ...
Esse comando divide o plano do VTS em fragmentos e os executa em vários dispositivos.
run cts-on-gsi --shard-count <number of devices> -s <device serial> -s ...
Esse comando divide o plano CTS-on-GSI em fragmentos e os executa em vários dispositivos.