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 CTS Verifier (CTS-V). Há dois tipos de testes do lado do host: testes multidisco (introduzidos antes do Android 17) e testes interativos (novidade do 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 manuais de precisão de alcance e de telecomunicações agora são testes multidevice 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 do CTS.

  2. Siga as etapas 2 e 5 de Instalar 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 a 3.11 ou mais recente. Para determinar a versão do Python, execute python3 --version. Se a versão for anterior a 3.11, instale a versão oficial mais recente do Python. Para mais detalhes, consulte a seção "Downloads" de python.org.

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

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

Configurar testes multidevice do lado do host

Siga estas etapas para configurar testes multidisco no host:

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

  2. Siga as etapas 2 e 5 de Instalar 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 a 3.11 ou mais recente. Para determinar a versão do Python, execute python3 --version. Se a versão for anterior a 3.11, instale a versão oficial mais recente do Python. Para mais detalhes, consulte a seção "Downloads" de python.org.

      • Alguns testes exigem que o host tenha o módulo venv do Python. Em sistemas Debian e Ubuntu, esse módulo pode não ser instalado por padrão. Para determinar se a versão do Python para computador tem o módulo venv, execute python3 -m venv venv. Se esse comando falhar, uma mensagem de erro será mostrada. 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, siga para Configurar testes padrão com 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 (link em inglês).
  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 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 ponto de acesso Wi-Fi

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

  • Opção 1: use 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 configurada para o CTS-V

A opção 1 exige um DUT Android na á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 PA programável

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

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

  2. (Opcional) Se você não tiver uma caixa de proteção, recomendamos a 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 em uma caixa de proteção contra 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 em uma caixa de proteção

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

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

Configurar testes de precisão de alcance

Para configurar testes de precisão de alcance:

  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 desktop com 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 um sinal de celular. Se os DUTs estiverem em uma caixa de proteção, o sinal 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 as duas.

Isenção

A cláusula de CDD para a implementação da API de sincronização de permissões exige apenas que ela consiga 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 (do 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 for isento, verifique se atende aos seguintes pré-requisitos.

O canal seguro usa AVF (AttestationVerificationFramework) para verificar a confiabilidade do hardware. As declarações geradas pelas duas partes contêm várias informações sobre si mesmas para verificar se não houve alteração não autorizada 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 bloquear o carregador de inicialização.

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

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

Executar testes do lado do host

Alguns testes em 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 adicional, você pode executá-los 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 multidimensional do lado do host é exibida.

  3. No console do host CTS-V, use o comando a seguir 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 CtsCompanionDeviceManager:

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

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

  4. No console do host CTS-V, use o comando a seguir 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 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 ponto de acesso Wi-Fi

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

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

Opção 1: usar uma rede Wi-Fi configurada para o CTS-V

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

  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 a localização 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 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 PA Wi-Fi em um PA 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 local. Para identificar o endereço IP, consulte Encontrar o endereço IP do AP. O exemplo a seguir mostra a localização 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 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 USB CTS-V que exigem adb por Wi-Fi para serem executados.

Alguns testes de USB exigem o uso do host 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 de adb por Wi-Fi.

Os seguintes acessórios Type-C são necessários se o DUT oferecer suporte a relatórios do tipo BC 1.2 do parceiro de porta ou perfis de energia USB em UsbPort.java:

  • Um carregador USB-C com fornecimento de energia (PD)
  • Uma porta downstream padrão (SDP) USB para carregamento de bateria 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 USB BC 1.2 (CDP). Essas portas podem fornecer 1,5 A de corrente para o DUT e dados. Uma porta Type-C em um laptop ou computador provavelmente é uma CDP.
  • Uma porta de carregamento dedicada (DCP) USB BC 1.2. Essas portas podem fornecer 1,5 A de corrente para o DUT sem dados. O carregador USB-C PD nesta lista provavelmente é um DCP.

  1. Conecte o DUT usando adb por Wi-Fi. Para mais 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 falha se o dispositivo estiver conectado a qualquer host ou acessório USB quando o comando de teste for executado.

  3. Execute este 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 USB do lado do host no app CTS-V

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

Suíte CtsUsbTypecTestCases no app USB CTS-V do lado do host

Figura 7. Suíte CtsUsbTypecTestCases no app USB CTS-V 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, você precisa fornecer explicitamente os números de telefone no comando.

    Por exemplo, para DUT 1 (serial 17011FDEE0002N, número de telefone 555-0000) e DUT 2 (serial R3CN90YNAR, número de telefone 555-1111), adicione 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 poderá 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 em segundo plano ou adicione à lista de permissões os seguintes pacotes:

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 "Sem resposta para GetFirmwareVersion durante testes de NFC"

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

Para corrigir esse problema, identifique o caminho serial usado pela placa NFC PN532 no seu 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

Correção da 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, provavelmente é porque o chip NFC do DUT não consegue detectar o PN532.

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

Para corrigir esse problema, faça o seguinte:

  • 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 o DUT do host.

O caso de teste de 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.