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.

Executar testes de vários dispositivos do CTS Verifier

Esta página contém instruções para usar os testes do Better Together CTS Verifier (CTS-V) para o Android 16 QPR2 ou versões mais recentes.

Configurar testes multidevice do lado do host

Esta seção explica como configurar testes em vários dispositivos.

Verifique se seu computador atende aos requisitos de sistema operacional do CTS.
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 precisa ser 3.11 ou mais recente. Para determinar a versão do Python, execute python3 --version. Se a versão for inferior a 3.11, instale a versão oficial mais recente do Python. Para mais informações, consulte a seção Downloads do 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 sua versão 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.
Prepare dois dispositivos em teste (DUTs) correspondentes, cada um com o CTS-V configurado.
- Para informações sobre como configurar um DUT, consulte Configurar o DUT.
- Para instruções sobre como configurar o CTS-V, consulte Configuração.
Acesse a seção de configuração do seu tipo de teste:
- Para testes de NFC, acesse Configurar testes de NFC.
- Para testes de conexão de AP Wi-Fi, acesse Configurar testes de conexão de AP Wi-Fi.
- Para testar o módulo CDM, acesse Configurar testes padrão de dois dispositivos e depois Configurar testes de CDM.
Se o teste não estiver nessa lista, acesse Configurar testes padrão com dois dispositivos.

Configurar testes de NFC

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

Para configurar testes de NFC:

Compre um chip NFC PN532. Recomendamos o All-In-One PN532.
No DUT, navegue até o app Configurações.
Ative a NFC.
Posicione o chip NFC:
- Para smartphones, posicione o leitor NFC do DUT conforme mostrado na Figura 1:
  
  Figura 1. Posicionamento do chip NFC.
- Para outros tipos de dispositivo, posicione o chip perto da antena NFC.
Conecte o chip NFC PN532 à estação de trabalho de teste usando um cabo USB.

Opcional: configurar testes de conexão de ponto de acesso Wi-Fi

Os testes de conexão do ponto de acesso (AP) Wi-Fi (CtsWifiConnectionTests) testam a conectividade entre um DUT e um AP. Recomendamos que você execute esses testes, mas eles não são obrigatórios no CTS-V Android 16 16 QPR2.

Esses testes exigem um DUT e um ponto de acesso OpenWrt Banana Pi R3.

Para configurar testes de conexão de ponto de acesso Wi-Fi:

Compre o Banana Pi R3 AP e os acessórios listados nesta tabela:

Item	Quantidade
Placa BPi-R3, semelhante à placa de roteador Banana Pi BPI-R3 com suporte a design de chip MediaTek MT7986 Wi-Fi 6 ,RAM DDR de 2G ,flash eMMC de 8G integrado	1
Caixa de alumínio BPi-R3, semelhante à caixa de ferro BPI-R3	1
Dissipador de calor de alumínio BPi-R3 (ventilador de resfriamento), semelhante ao dissipador de calor de alumínio BPI-R3 com ventilador	1
Antena de 2 e 5 GHz com cabo, semelhante à antena de 5 dB na loja da BPI	8
Adaptador de energia, semelhante à fonte de alimentação de 12 V/2 A CC	1

Para fazer sua compra, consulte a seção Fácil de comprar da página do Banana Pi BPI-R3.

Configure o ponto de acesso. Para informações sobre como configurar o ponto de acesso, consulte Configurar o PA Banana Pi BPI-R3.
Opcional: se você não tiver uma caixa de proteção, recomendamos o modelo JTP-SR101. Compre a 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

Observação: uma caixa de proteção permite o isolamento de sinal externo e que um DUT e um AP fiquem a 10 cm de distância.
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:

Figura 2. DUT e AP em uma caixa de proteção.
Use o SSH para verificar se o AP está acessível no host.

Configurar testes padrão com dois dispositivos

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

Coloque dois DUTs Android correspondentes a aproximadamente 20 cm de distância.
Para configurar um ambiente limpo, coloque os dois dispositivos em uma caixa de proteção.

Observação: se você tiver problemas com esses testes e precisar de ajuda, verifique se eles foram executados com os dois dispositivos em uma caixa de proteção.
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 os OEMs testem ambas as versões depuráveis (userdebug ou eng) e não depuráveis (user) e que os testes sejam aprovados para as duas.

Exoneraçã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 suporte ao 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 pelas cláusulas de isenção anteriores, verifique se atende aos pré-requisitos a seguir.

O canal seguro usa o 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 garantir que 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 precisa ser assinado com uma chave de lançamento, não uma chave de desenvolvimento.
O carregador de inicialização do dispositivo está bloqueado. Para instruções detalhadas, consulte como bloquear o carregador de inicialização.
Os níveis de patch do SO, da inicialização e do fornecedor de chaves estão dentro de 12 meses. Não use um 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 multidisco no lado do host (AOSP 16 ou mais recente)

O CTS Verifier 16 apresenta suporte para testes multidispositivo do lado do host. Esses testes podem ser executados usando scripts automatizados no host, em vez da operação de teste manual no dispositivo. Depois que cada teste é concluído, os resultados são enviados automaticamente para o DUT e exibidos no app CTS Verifier.

Esta seção explica como executar os testes multidevice do lado do host.

Executar testes em vários dispositivos

Para executar um teste em vários dispositivos:

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
```
No app CTS Verifier no DUT, clique em Testes do lado do host. A Figura 3 mostra os testes do lado do host no app CTS Verifier:

Figura 3. Testes de vários dispositivos do lado do host no app CTS Verifier.

Uma lista de módulos de teste multidevice do lado do host será exibida.
Identifique o nome do módulo de teste que você quer executar. Por exemplo, o módulo CompanionDeviceManager é listado como CtsCompanionDeviceManagerMultiDeviceTestCases.

Observação: se você tocar em um módulo do lado do host no app CTS Verifier, não vai aparecer uma lista de casos de teste individuais. Em vez disso, a interface é preenchida automaticamente com os resultados do caso de teste depois que o módulo é executado no host.
No console cts-v-host, execute o seguinte comando:
```
run cts-v-host -m test_module_name
```
Exemplo:
```
run cts-v-host -m CtsCompanionDeviceManagerMultiDeviceTestCases
```
Observação: se você executar cts-v-host sem usar o -m test_module_name, o comando tentará executar todos os módulos de teste, ignorando desvios nos requisitos de dispositivo e hardware. Em vez disso, execute o comando run cts-v-host-default-devices para executar os testes com a configuração padrão como um único subplano.
Observação: você pode indicar os DUTs específicos para testar usando os números de série: run cts-v-host -m test_module_name -s\ device1_serial -s device2_serial ...

Depois que o console xTS terminar de executar os testes, os resultados vão aparecer no app CTS Verifier. Os testes marcados em verde foram aprovados. Os testes marcados em vermelho falharam. A Figura 4 mostra exemplos de resultados para os testes CtsCompanionDeviceManager:

Figura 4. Resultados de testes multidevice do lado do host no app CTS Verifier.

Observação: os resultados do lado do host são adicionados automaticamente ao relatório geral do teste CTS-V.

Opcional: execute testes de conexão do ponto de acesso Wi-Fi

Siga estas etapas para executar testes de conexão de ponto de acesso Wi-Fi:

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:
```
./android-cts-verifier/android-cts-v-host/testcases/CtsWifiConnectionTests/x86_64/connection/WifiConnectionTestbed.yaml
```
Mude o valor do campo hostname para o endereço IP do AP, com base nas configurações SSH locais. Para identificar o endereço IP, consulte Encontrar o endereço IP do AP.

O exemplo a seguir mostra a localização do campo hostname no arquivo WifiConnectionTestbed.yaml:
```
TestBeds:
- Name: WifiConnectionTestbed
  Controllers:
    # Specify settings for the AP.
    OpenWrtDevice:
    - hostname: AP-IP
      skip_init_reboot: True
```
No console cts-v-host, execute o seguinte comando:
```
run everything -m CtsWifiConnectionTests
```
Observação: para mais informações sobre o console cts-v-host, consulte Executar testes em vários dispositivos.

Resolver problemas de testes em vários dispositivos

Nesta seção, você encontra ajuda para resolver possíveis problemas.

Correção de "Nenhuma 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, eles 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

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 uma das seguintes ações:

Defina o número de série correto do DUT no comando de teste do host usando a flag -s.
Desconecte todos os dispositivos que não são DUT do host.

O caso de teste `test_permissions_sync` do CDM foi 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.