Executar testes do CTS Verifier no host

Esta página contém instruções para configurar e executar testes do Android 16 QPR2 e do Android 17 no lado do host do Verificador do CTS (CTS-V). Há dois tipos de testes do lado do host: testes de vários dispositivos (introduzidos antes do Android 17) e testes interativos (novos no Android 17):

  • Os testes em vários dispositivos são totalmente automatizados.
  • Os testes interativos são semiautomatizados e exigem que você execute algumas etapas manuais no dispositivo em teste (DUT, na sigla em inglês).

Além dos novos testes interativos, os testes de precisão de alcance manual e de telecomunicações agora são testes de vários dispositivos do lado do host, e os testes de conexão Wi-Fi são obrigatórios.

Configurar testes do lado do host

Siga estas etapas para configurar testes do lado do host (testes em vários dispositivos exigem configuração adicional):

  1. Verifique se o computador atende aos requisitos do sistema operacional para o CTS.

  2. Siga as etapas 2 e 5 de Instalar o software para computador para instalar e verificar se o adb, o AAPT2 e o Python estão instalados corretamente no computador.

    • A versão do Python para computador precisa ser 3.11 ou mais recente. Para determinar a versão do Python, execute python3 --version. Se a versão for anterior à 3.11, instale a versão oficial mais recente do Python. Para mais detalhes, consulte a seção de downloads do python.org.

    • Alguns testes exigem que o host tenha o módulo venv do Python. Nos sistemas Debian e Ubuntu, esse módulo pode não ser instalado por padrão. Para determinar se a versão para computador do Python tem o módulo venv, execute python3 -m venv venv. Se esse comando falhar, uma mensagem de erro será exibida. Siga as instruções para instalar o pacote python3.x-venv.

Se você executar apenas os testes interativos do lado do host, prossiga para Executar testes do lado do host. No entanto, se você quiser executar testes em vários dispositivos, prossiga para Configurar testes em vários dispositivos do lado do host.

Configurar testes de vários dispositivos do lado do host

Siga estas etapas para configurar testes de vários dispositivos do lado do host:

  1. Verifique se o computador atende aos requisitos do sistema operacional para o CTS.

  2. Siga as etapas 2 e 5 de Instalar o software para computador para instalar e verificar se o adb, o AAPT2 e o Python estão instalados corretamente no computador.

    • A versão do Python para computador precisa ser 3.11 ou mais recente. Para determinar a versão do Python, execute python3 --version. Se a versão for anterior à 3.11, instale a versão oficial mais recente do Python. Para mais detalhes, consulte a seção de downloads do python.org.

      • Alguns testes exigem que o host tenha o módulo venv do Python. Nos sistemas Debian e Ubuntu, esse módulo pode não ser instalado por padrão. Para determinar se a versão para computador do Python tem o módulo venv, execute python3 -m venv venv. Se esse comando falhar, uma mensagem de erro será exibida. Siga as instruções para instalar o pacote python3.x-venv.

  3. Prepare dois DUTs correspondentes, cada um com o CTS-V configurado.

  4. Acesse a seção de configuração do seu tipo de teste:

Se o teste não estiver nessa lista, prossiga para Configurar testes padrão de dois dispositivos.

Configurar testes de NFC

Os testes de NFC usam um DUT e um chip de NFC PN532.

Para configurar testes de NFC:

  1. Compre um chip de NFC PN532. Recomendamos o All-In-One PN532.
  2. No DUT, acesse o app Configurações.
  3. Ative a NFC.

  4. Posicione o chip de NFC:

    • Para smartphones, posicione o leitor de NFC do DUT conforme mostrado na Figura 1:

      Posicionamento do chip de NFC

      Figura 1. Posicionamento do chip de NFC.

    • Para outros tipos de dispositivo, posicione o chip ao lado da antena NFC do dispositivo.

  5. Conecte o chip de NFC PN532 à estação de trabalho de teste usando um cabo USB.

Configurar testes de conexão de AP Wi-Fi

Os testes de conexão do ponto de acesso (AP) Wi-Fi (CtsWifiConnectionTests) testam a conectividade entre um DUT e um AP. É possível configurar esses testes de duas maneiras:

  • Opção 1: usar uma rede Wi-Fi que você configurou para o CTS-V.
  • Opção 2: configurar um ponto de acesso (AP) programável.

Para o Android 17, recomendamos a opção 2, mas ela não é obrigatória. As duas seções a seguir explicam cada opção.

Opção 1: usar uma rede Wi-Fi que você configurou para o CTS-V

A opção 1 requer um DUT Android dentro da área de cobertura da rede Wi-Fi. Se o DUT estiver em uma caixa de proteção e não puder se conectar à rede Wi-Fi, remova-o da caixa.

Opção 2: configurar um AP programável

Para configurar um AP programável para os testes de conexão Wi-Fi:

  1. Compre o AP Banana Pi R3 e configure-o. Para informações sobre como comprar e configurar o AP Banana Pi R3, consulte Configurar o AP Banana Pi BPI-R3.

  2. (Opcional) Se você não tiver uma caixa de proteção, recomendamos a caixa de proteção JTP-SR101. Compre esta caixa usando as seguintes informações:

    Dong Guan Zheng Sheng Electronics Technology Co., LTD

    Bohui Industrial Park, Panlong Road, Liaobu Town, Dongguan City, Guangdong Province, China

    Contato: Forest Pan

    E-mail: forest.pan@jtpmak.cn

    Telefone (China): +86 18676993556

  3. Conecte o DUT e o AP ao host e coloque-os em uma caixa de proteção de RF. O DUT e o AP precisam estar a pelo menos 10 cm de distância. A Figura 2 mostra essa configuração:

    DUT e AP na caixa de proteção

    Figura 2. DUT e AP na caixa de proteção.

  4. Use o SSH para verificar se o AP está acessível no host.

Configurar testes de precisão de medição de distância

Para configurar testes de precisão de medição:

  1. Coloque dois DUTs Android correspondentes a 1 metro de distância, na mesma altura, com linha de visão direta e com a parte de trás de cada dispositivo voltada uma para a outra. A Figura 3 mostra essa orientação:

    Orientação do dispositivo

    Figura 3. Orientação do dispositivo.

  2. Conecte os dois dispositivos ao computador usando cabos USB.

Configurar testes padrão com dois dispositivos

Para a configuração padrão de dois dispositivos:

  1. Coloque dois DUTs Android correspondentes a aproximadamente 20 cm de distância.

  2. Altamente recomendável: coloque os dois dispositivos em uma caixa de proteção. A caixa de proteção melhora a estabilidade do teste e facilita a depuração de falhas.

  3. Para testes de telecomunicações, cada DUT precisa ter um chip e sinal de celular. Se os DUTs estiverem em uma caixa de proteção, o sinal de celular precisará ser acoplado à caixa. Caso contrário, remova os dispositivos da caixa de proteção.

  4. Opcional: configure um sniffer OTA para depuração de Wi-Fi.

Configurar testes de CDM

O caso de teste test_permissions_sync tem um comportamento diferente dependendo do tipo de build dos dispositivos em que o teste é executado. É fundamental que ambas as versões depuráveis (userdebug ou eng) e não depuráveis (user) sejam testadas pelos OEMs e que os testes sejam aprovados para ambas.

Isenção

A cláusula do CDD para a implementação da API de sincronização de permissões exige apenas que ela seja capaz de transferir dados entre dispositivos por um canal seguro. Como a implementação do canal seguro não é um requisito de conformidade do CDD, esse teste pode ser ignorado em builds não depuráveis (usuário), mas apenas se você quiser desativar o recurso de sincronização de permissões do CDM.

Os testes precisam ser aprovados em builds depuráveis sem exceção.

Pré-requisitos para testes em builds não depuráveis

Se você não estiver isento, verifique se atende aos seguintes pré-requisitos.

O canal seguro usa o AVF (AttestationVerificationFramework) para verificar a confiabilidade do hardware. Os atestados gerados por ambas as partes contêm várias informações sobre si mesmas para verificar se não houve alterações não autorizadas no sistema. O AVF verifica os seguintes estados durante o processo de verificação:

  • O dispositivo tem acesso à Internet

  • O dispositivo usa a inicialização verificada, e o build é assinado com uma chave de lançamento (não uma chave de desenvolvimento)

  • O carregador de inicialização do dispositivo está bloqueado. Para mais detalhes, consulte Como bloquear o carregador de inicialização.

  • Os níveis de patch do SO, da inicialização de chaves e do fornecedor de chaves estão dentro de 12 meses. Não use uma versão com mais de um ano.

  • O atestado do dispositivo é respaldado por um dos certificados raiz aprovados pelo fornecedor. Especifique os certificados raiz confiáveis na sobreposição de recursos vendor_required_attestation_certificates.xml.

Executar testes do lado do host

Alguns testes de vários dispositivos, como os de NFC, exigem configuração adicional. Para testes que exigem configuração adicional, cada teste é executado separadamente. Para testes que não exigem configuração extra, é possível executar os testes em um grupo.

  1. Na estação de trabalho de teste, inicie o console cts-v-host no diretório em que o pacote ZIP do CTS-V foi descompactado:

    ./android-cts-verifier/android-cts-v-host/tools/cts-v-host-tradefed

  2. No app CTS-V no DUT, clique em Testes do lado do host. A Figura 4 mostra os testes do lado do host no app CTS-V:

    Testes do lado do host no app CTS-V

    Figura 4. Testes do lado do host no app CTS-V.

    Uma lista de módulos de teste de vários dispositivos do lado do host é exibida.

  3. No console do host do CTS-V, use o comando abaixo para executar testes multidispositivo que usam uma configuração padrão de dois dispositivos:

    run cts-v-host-multidevice-default

    Os resultados aparecem em cada módulo de teste no app CTS-V no DUT. Os testes marcados em verde foram aprovados, e os marcados em vermelho foram reprovados.

    A Figura 5 mostra exemplos de resultados para os testes do CtsCompanionDeviceManager:

    Resultados de testes multidispositivo do lado do host no app CTS-V

    Figura 5. Resultados do teste multidispositivo do lado do host no app CTS-V.

  4. No console do host do CTS-V, use o seguinte comando para executar os testes interativos:

    run cts-v-host-interactive

    Os resultados aparecem em cada módulo de teste no app CTS-V no DUT. Os testes marcados em verde foram aprovados, e os marcados em vermelho foram reprovados.

  5. Para cada teste que exigiu configuração adicional, execute o teste separadamente usando o seguinte comando:

    run cts-v-host -m test_module_name

    Por exemplo, para executar os testes de NFC, use este comando:

    run cts-v-host -m CtsNfcHceMultiDeviceTestCases

    Os resultados aparecem em cada módulo de teste no app CTS-V no DUT. Os testes marcados em verde foram aprovados, e os marcados em vermelho foram reprovados.

Executar testes de conexão do AP Wi-Fi

É possível executar os testes de conexão do AP Wi-Fi de duas maneiras:

  • Opção 1: usar uma rede Wi-Fi que você configurou para o CTS-V.
  • Opção 2: configurar um AP programável.

Opção 1: usar uma rede Wi-Fi que você configurou para o CTS-V

Para executar os testes de conexão do AP de Wi-Fi em uma rede Wi-Fi:

  1. Edite o arquivo de configuração do ambiente de teste (WifiConnectionTestbed.yaml). Esse arquivo está no diretório em que o CTS-Verifier foi descompactado. Exemplo:

    ./android-cts-verifier/android-cts-v-host/testcases/CtsWifiConnectionTests/x86_64/connection/WifiConnectionTestbed.yaml

  2. Mude o valor dos campos wifi_ssid e wifi_password para o SSID e a senha da rede Wi-Fi. O exemplo a seguir mostra o local dessas configurações:

    TestBeds:
-   Name: WifiConnectionTestbed
Controllers:
  AndroidDevice: '*'
TestParams:
  use_programmable_ap: False
  wifi_ssid: WIFI-SSID
  wifi_password: WIFI-PASSWORD

  3. No console do host do CTS-V, execute o seguinte comando:

    run cts-v-host -m CtsWifiConnectionTests

Opção 2: executar com um AP programável

Para executar os testes de conexão do AP Wi-Fi em um AP programável:

  1. Edite o arquivo de configuração do ambiente de teste (WifiConnectionTestbed.yaml). Esse arquivo está no diretório em que o CTS-Verifier foi descompactado. Exemplo:

    ./android-cts-verifier/android-cts-v-host/testcases/CtsWifiConnectionTests/x86_64/connection/WifiConnectionTestbed.yaml

  2. Mude o valor de hostname para o endereço IP do AP, com base nas configurações de SSH locais. Para identificar o endereço IP, consulte Encontrar o endereço IP do AP. O exemplo a seguir mostra o local da configuração hostname:

    TestBeds:
-   Name: WifiConnectionTestbed
  Controllers:
    AndroidDevice: '*'
    # Specify settings for the AP.
    OpenWrtDevice:
    -   hostname: AP-IP
      skip_init_reboot: True
  TestParams:
    use_programmable_ap: True

  3. No console do host do CTS-V, execute o seguinte comando:

    run cts-v-host -m CtsWifiConnectionTests

Executar testes do lado do host USB

O Android 17 inclui testes do lado do host do CTS-V USB que exigem o adb por Wi-Fi para serem executados.

Alguns testes de USB exigem o uso do host do CTS-V para acessar SystemAPIs que têm permissões que o app CTS-V normal não pode acessar. Esses testes são independentes e exigem o uso do adb por Wi-Fi.

Os seguintes acessórios Type-C serão necessários se o DUT for compatível com a geração de relatórios do tipo BC 1.2 do parceiro de porta ou dos perfis de energia USB em UsbPort.java:

  • Um carregador USB-C com Power Delivery (PD)
  • Uma porta downstream padrão (SDP) de carregamento de bateria USB 1.2 (BC 1.2). Essas portas são limitadas a fornecer 500 mA ou 900 mA ao DUT e são encontradas com frequência nas portas USB de hubs externos.
  • Uma porta de carregamento downstream (CDP) USB BC 1.2. Essas portas podem fornecer 1,5 A de corrente para o DUT e os dados. Uma porta tipo C em um laptop ou computador provavelmente é uma CDP.
  • Uma porta de carregamento dedicada (DCP, na sigla em inglês) USB BC 1.2. Essas portas podem fornecer 1,5 A de corrente ao DUT sem dados. O carregador USB-C PD nesta lista provavelmente é um DCP.

  1. Conecte o DUT usando adb por Wi-Fi. Para detalhes sobre a configuração, consulte Conectar-se a um dispositivo por Wi-Fi.

  2. Desconecte fisicamente o dispositivo de todas as conexões USB. O teste vai falhar se o dispositivo estiver conectado a qualquer host ou acessório USB quando o comando de teste for executado.

  3. Execute o seguinte comando de teste:

    run cts-v-host -m CtsUsbTypecTestCases

Após os testes, os resultados aparecem no app CTS-V em Testes do lado do host, conforme mostrado nas figuras a seguir:

Testes de USB do lado do host no app CTS-V

Figura 6. Testes de USB do lado do host no app CTS-V.

Conjunto CtsUsbTypecTestCases no app CTS-V de USB do lado do host

Figura 7. Conjunto CtsUsbTypecTestCases no app CTS-V de USB do lado do host.

Resolver problemas de testes em vários dispositivos

Esta seção ajuda a resolver problemas comuns.

Falha ao receber o número de telefone durante o CtsTelecomTest

Se você receber a mensagem de erro Failed to get phone number for <serial>, siga estas etapas:

  1. Verifique se cada DUT tem um chip instalado.

  2. Se o erro persistir, talvez os chips não sejam compatíveis com a recuperação automática de números. Nesse caso, é necessário fornecer explicitamente os números de telefone no comando.

    Por exemplo, para o DUT 1 (número de série 17011FDEE0002N, número de telefone 555-0000) e o DUT 2 (número de série R3CN90YNAR, número de telefone 555-1111), anexe os seguintes argumentos ao comando run cts-v-host:

    --module-arg CtsTelecomTest:dut_serial:17011FDEE0002N \
--module-arg CtsTelecomTest:dut_phone_number:555-0000 \
--module-arg CtsTelecomTest:ref_phone_number:555-1111

Nenhuma resposta do servidor durante CtsMultiDeviceGenericRangingAccuracyTests

Se você receber a seguinte mensagem de erro, o app de teste pode ser congelado ou encerrado pelo gerenciamento de processos em segundo plano específico do OEM em determinados dispositivos:

mobly.snippet.errors.ProtocolError: <AndroidDevice|Initiator> No response from server. Check the device logcat for crashes.

Para resolver esse problema, desative as restrições de segundo plano ou coloque os seguintes pacotes na lista de permissões:

Pacote Nome de exibição
com.google.snippet.uwb CtsUwbSnippetApp
com.google.snippet.ranging CtsRangingSnippetApp
com.google.snippet.bluetooth CtsBluetoothMultiDeviceSnippetApp
com.google.android.mobly.snippet.bundled androidx.multidex.MultDexApplication

Correção de "Nenhuma resposta para GetFirmwareVersion" durante os testes de NFC

Se você receber a mensagem verify_firmware_version RuntimeError: No response for GetFirmwareVersion ao executar os testes em vários dispositivos, os testes não poderão acessar a placa NFC PN532.

Para corrigir esse problema, identifique o caminho serial usado pela placa NFC PN532 no host, como dev/ttyUSB1, e especifique-o manualmente usando o argumento --module-arg no console:

run cts-v-host -m CtsNfcHceMultiDeviceTestCases --module-arg CtsNfcHceMultiDeviceTestCases:pn532_serial_path:/dev/ttyUSB1

Corrigir a mensagem de erro "Falha na transação" durante os testes de NFC

Se você receber a mensagem Transaction failed, check device logs for more information. para todos os casos de teste de NFC, é provável que o chip de NFC do DUT não consiga detectar o PN532.

Se você tiver vários dispositivos conectados ao host e alguns deles não tiverem um PN532 colocado na parte de cima, talvez o DUT errado tenha sido selecionado. Para mais informações, consulte Configurar testes de NFC.

Para corrigir esse problema, siga um destes procedimentos:

  • Defina o número de série correto do DUT no comando de teste do lado do host usando a flag -s.

  • Desconecte todos os dispositivos que não são DUTs do host.

O caso de teste do CDM test_permissions_sync é ignorado

Se o teste estiver sendo executado em dispositivos não depuráveis, verifique se você está isento. Caso contrário, verifique se os dois dispositivos atendem aos pré-requisitos.