Como configurar o teste

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.