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 pacote de mapeamento de testes usado em verificações de pré-envio.
Configuração do teste
Na maioria dos casos, a configuração de teste, que é um arquivo XML usado pelo Trade Federation para executar um teste do 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 arquivo XML de teste do zero pode ser complicado, já que envolve entender como o ambiente 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, 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, como 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
Pode haver 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 automaticamente esse arquivo como o arquivo de configuração do módulo de teste. Caso contrário, adicione um atributo test_config
ao módulo, como 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 adb root
A maioria dos testes do VTS exige privilégio de root para ser executada. Se o arquivo de configuração de teste for gerado automaticamente, adicione o seguinte atributo 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 a estrutura durante o teste
Muitos testes do VTS não exigem a execução do framework do Android. Executar o teste com o framework parado permite que ele seja executado com estabilidade sem ser afetado por falhas do dispositivo. Se o arquivo de configuração de teste for gerado automaticamente, adicione o seguinte atributo a Android.bp
.
disable_framework: 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.StopServicesSetup"/>
Adicionar outros argumentos de teste
Alguns testes do gtest podem levar mais tempo para serem executados. Nesses casos, é possível adicionar opções de executor de testes 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 três minutos, em vez do padrão de um 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 da API
Alguns testes do VTS só podem ser executados em dispositivos com um nível mínimo de API. Se o arquivo de configuração de teste for gerado automaticamente, adicione o seguinte atributo 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 a seguir 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 de 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. Ao combinar 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
para um SoC qualificado para
congelamento 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 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
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
Ela vai definir automaticamente a propriedade ro.board.first_api_level como
vendor/build.prop
no dispositivo. A propriedade é definida pelo processo do fornecedor init
.
ro.board.api_level
A propriedade ro.board.api_level
é o nível atual da API do fornecedor das imagens
que têm 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 de API do fornecedor correspondente 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 da imagem do fornecedor podem ser excluídos
dos requisitos do fornecedor para o SoC ao consultar essa propriedade.
Processo de fragmentação usando o VTS
Para o Android 10 ou versões mais recentes, é possível realizar o processo de fragmentação em vários dispositivos ao testar 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 no GSI em fragmentos e os executa em vários dispositivos.