A partir de 27 de março de 2025, recomendamos usar android-latest-release em vez de aosp-main para criar e contribuir com o AOSP. Para mais informações, consulte Mudanças no AOSP.

Esta página foi traduzida pela API Cloud Translation.

Como configurar o teste
Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.

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 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 harness 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, 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 a configuração do teste arquivo for gerado automaticamente, será possível adicionar o seguinte atributo a Android.bp.

require_root: true,

Se o arquivo de configuração de teste for personalizado, adicione a seguir 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 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 de teste.

<target_preparer class="com.android.tradefed.targetprep.StopServicesSetup"/>

Adicionar outros argumentos de teste

Alguns testes gtest podem exigir mais tempo para serem executados. Nesses casos, você pode adicionar opções do executor de testes no arquivo XML.

Por exemplo, a configuração native-test-timeout no permite que o teste seja executado com um tempo limite de três 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 da API

Alguns testes do VTS só podem ser executados em dispositivos com nível mínimo de API. Se o de configuração de teste é gerado automaticamente, você pode adicionar os seguintes para Android.bp.

min_shipping_api_level: 29,

vsr_min_shipping_api_level: 202404,

Se o arquivo de configuração de teste for personalizado, adicione o 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>

   <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 a ro.vendor.api_level, que é definido automaticamente calculando o nível necessário da API do fornecedor usando o 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 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 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 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. imagens com 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 for definida como a versão de ro.product.first_api_level que é maior ou igual a 35. Testes para implementações que exigem upgrade da imagem do fornecedor podem ser excluídas dos requisitos do fornecedor para o SoC, referindo-se a esta 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 de 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.

Como configurar o teste Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.