Configurar o CTS

Para executar o CTS, primeiro prepare o ambiente físico, a máquina de desktop e o dispositivo Android que você está usando para testes.

Ambiente físico

Sensores Bluetooth LE

Se o dispositivo em teste (DUT, na sigla em inglês) for compatível com o Bluetooth LE, coloque pelo menos três sensores Bluetooth LE a até 5 metros do DUT para testes de verificação do Bluetooth LE. Esses beacons não precisam ser configurados ou emitir nada específico e podem ser de qualquer tipo, incluindo iBeacon, Eddystone ou até mesmo dispositivos que simulam beacons BLE.

Banda ultralarga

Se o DUT oferecer suporte à banda ultralarga (UWB), outro dispositivo com suporte a UWB precisará ser posicionado o suficiente e orientado para não ter antenas e uma zona morta de rádio. Para os testes de precisão de distância, há necessidades específicas de posicionamento e orientação. Para detalhes sobre a configuração, consulte Requisitos de UWB. O teste UWB precisa ser executado manualmente, especificando na linha de comando quais dois dispositivos estão a um metro de distância. Para saber mais sobre o sharding necessário para esse teste, consulte Sharding local.

Cameras

Ao executar o CTS da câmera, use condições de iluminação normais com um gráfico de padrão de teste (como um padrão de xadrez). Coloque o gráfico do padrão de teste de acordo com a distância mínima de foco do DUT para garantir que ele não esteja muito próximo da lente.

Aponte os sensores da câmera para uma cena com iluminação suficiente para permitir que os sensores em teste alcancem e permaneçam no máximo de frames de destino configurados por segundo (QPS), conforme especificado em CONTROL_AE_TARGET_FPS_RANGE. Isso se aplica a todos os sensores de câmera informados por getCameraIdList, já que o teste itera sobre os dispositivos listados e mede o desempenho individualmente.

Se o DUT oferecer suporte a câmeras externas, como webcams USB, conecte uma câmera externa ao executar o CTS. Caso contrário, os testes de CTS falham.

GPS/GNSS

Se o DUT for compatível com o recurso de sistema de posicionamento global/sistema de satélite de navegação global (GPS/GNSS, na sigla em inglês), forneça um sinal de GPS/GNSS ao DUT em um nível de sinal adequado para a recepção e o cálculo da localização do GPS. A parte do GPS precisa ser compatível com o ICD-GPS-200C. Caso contrário, o sinal de GPS/GNSS pode ser de qualquer tipo, incluindo um simulador de satélite ou um repetidor de GPS/GNSS de sinais externos. Também é possível colocar o DUT perto o suficiente de uma janela para que ele receba diretamente um sinal de GPS/GNSS suficiente.

Cuidado: para o teste de GPS, a configuração de conexão de Internet não pode bloquear conexões para a porta supl.google.com 7276. Essa porta faz o download de dados de assistência do GPS para testar o cálculo da posição no dispositivo local.

Wi-Fi e IPv6

Os testes do CTS exigem uma rede Wi-Fi compatível com IPv4 e IPv6, uma conexão de Internet com DNS em funcionamento para IPv4 e IPv6, suporte a IP multicast e a capacidade de tratar o DUT como um cliente isolado. Um cliente isolado é uma configuração em que o DUT não tem visibilidade para as mensagens de transmissão/várias redes nessa sub-rede. Isso ocorre com uma configuração de ponto de acesso Wi-Fi (AP) ou executando o DUT em uma subrede isolada sem outros dispositivos conectados.

Se você não tiver acesso a uma rede IPv6 nativa, a uma rede de operadora IPv6 ou a uma VPN para passar em alguns testes dependendo do IPv6, use um ponto de acesso Wi-Fi e um túnel IPv6.

Para passar no CTS, o DUT precisa das sinalizações UP, BROADCAST e MULTICAST definidas na interface do Wi-Fi. A interface Wi-Fi precisa ter endereços IPv4 e IPv6 atribuídos. Verifique as propriedades da interface Wi-Fi com adb shell ifconfig.

Para dispositivos com suporte à simultaneidade de STA/STA Wi-Fi, várias redes Wi-Fi (pelo menos duas) são necessárias. Para serem aprovadas no CTS, as redes Wi-Fi precisam funcionar em bandas diferentes com SSIDs distintos ou no mesmo SSID, com BSSIDs diferentes.

RTT do Wi-Fi

O Android inclui a API Wi-Fi RTT para um recurso de tempo de retorno do Wi-Fi (RTT). Isso permite que os dispositivos meçam a distância até os pontos de acesso com uma precisão de 1 a 2 metros, aumentando significativamente a precisão da localização interna. Dois dispositivos recomendados que oferecem suporte a Wi-Fi RTT são o Google Wifi e o ponto de acesso fitlet2 da Compulab (definido para largura de banda de 40 MHz a 5 GHz).

Os pontos de acesso precisam estar ligados, mas não precisam de uma conexão de rede. Os pontos de acesso não precisam estar ao lado do dispositivo de teste, mas é recomendável que fiquem a até 12 metros do DUT. Normalmente, um ponto de acesso é suficiente.

Configuração da máquina de computador

Atenção: o CTS oferece suporte a máquinas Linux de 64 bits. O CTS não é compatível com o SO Windows ou o MacOS.

FFMPEG

Instale o pacote ffmpeg versão 5.1.3 (ou mais recente) na máquina host.

Requisito da máquina host

O requisito mínimo para a máquina host do CTS é de 32 GiB de RAM e 256 GiB de capacidade de disco. Isso é necessário para acomodar o aumento do número de casos de teste do CTS e um aumento na reserva de espaço de heap Java no Tradefed.

ADB e AAPT2

Observação: para o CTS 8.0, use a versão 1.0.39 do adb.

Antes de executar o CTS, verifique se você instalou as versões recentes do Android Debug Bridge (adb) e da Android Asset Packaging Tool (AAPT2) e adicionou o local dessas ferramentas ao caminho do sistema da sua máquina.

Para instalar o ADB e o AAPT2, faça o download das Android SDK Platform Tools e do Android SDK Build Tools mais recentes no SDK Manager do Android Studio ou na ferramenta de linha de comando sdkmanager.

Verifique se adb e aapt2 estão no caminho do sistema. O comando a seguir pressupõe que você fez o download dos arquivos do pacote em um subdiretório chamado android-sdk no diretório inicial:

export PATH=$PATH:$HOME/android-sdk/platform-tools:$HOME/android-sdk/build-tools/<tools version number>

Observação: verifique se o caminho inicial e o nome do diretório estão corretos.

Kit de desenvolvimento Java para Ubuntu

Instale a versão correta do Java Development Kit (JDK).

• Para o Android 11, instale o OpenJDK11.
• Para o Android 9 e 10, instale o OpenJDK9.
• Para o Android 7.0, 7.1, 8.0 e 8.1, instale o OpenJDK8.

Para mais detalhes, consulte os requisitos do JDK.

Configuração do suporte a Python

Instale o virtualenv para sua plataforma seguindo as instruções de instalação.

Para verificar se a instalação foi concluída, invoque virtualenv -h.

Arquivos CTS

Faça o download e abra os pacotes CTS em Downloads do conjunto de teste de compatibilidade (em inglês) que correspondem à versão do Android do dispositivo e a todas as interfaces binárias do aplicativo (ABIs) compatíveis.

Faça o download e abra a versão mais recente dos arquivos de mídia do CTS.

Fazer o download de arquivos CTS relacionados à linha principal (opcional)

Quando você executa uma versão do CTS pela primeira vez, o CTS faz o download dinâmico de alguns arquivos do CTS relacionados à linha principal, o que adiciona pelo menos 10 minutos ao tempo de execução, dependendo da velocidade da sua rede.

Para evitar esse tempo de execução extra do CTS, faça o download dos arquivos do CTS relacionados à Mainline antes de executar a versão do CTS seguindo estas instruções:

1. Para saber o nível da API Android no dispositivo, execute:

   adb shell getprop ro.build.version.sdk
   

2. Siga as instruções no script download_mcts.sh para fazer o download dos arquivos da CTS principal.

   O download leva pelo menos 10 minutos, dependendo da velocidade da rede.

Detecção de dispositivos

Siga a etapa para configurar o sistema para detectar o dispositivo.

Limite de memória

Talvez seja necessário aumentar a memória máxima disponível durante a execução de teste no script cts-tradefed. Consulte o exemplo CL para mais informações.

Configuração de dispositivos Android

Builds do usuário

Um dispositivo compatível é definido como um dispositivo com um build assinado por chave de usuário/versão. O dispositivo precisa estar executando uma imagem do sistema baseada no build do usuário compatível (Android 4.0 ou mais recente) em Nomes de código, tags e números de build.

Cuidado: quando usado para confirmar a compatibilidade do Android com sua imagem final do sistema, o CTS precisa ser executado em dispositivos com um build do usuário.

Primeira propriedade de build do nível da API

Alguns requisitos do CTS dependem do build com que um dispositivo foi enviado originalmente. Por exemplo, os dispositivos que são enviados originalmente com builds anteriores podem ser excluídos dos requisitos do sistema que se aplicam a dispositivos enviados com builds mais recentes.

Para disponibilizar essas informações ao CTS, os fabricantes de dispositivos podem ter definido a propriedade ro.product.first_api_level no tempo de build. O valor dessa propriedade é o primeiro nível de API com que o dispositivo foi lançado comercialmente.

Os fabricantes de dispositivos podem reutilizar a implementação comum para lançar um novo produto como um upgrade de um produto existente no mesmo grupo de dispositivos. Os fabricantes de dispositivos podem definir o nível da API do produto atual como ro.product.first_api_level, para que os requisitos de upgrade sejam aplicados ao CTS e ao Treble/VTS.

Os fabricantes de dispositivos podem definir PRODUCT_SHIPPING_API_LEVEL no arquivo device.mk para definir essa propriedade, conforme mostrado no exemplo abaixo:

# PRODUCT_SHIPPING_API_LEVEL sets ro.product.first_api_level to indicate
# the first api level that the device has been commercially launched on.
PRODUCT_SHIPPING_API_LEVEL := 21

Primeiro nível da API para o Android 9 ou versões mais recentes

Para dispositivos lançados com o Android 9 ou mais recente, defina a propriedade ro.product.first_api_level como um valor válido em Codinomes, tags e números de build.

Primeiro nível da API para o Android 8.x ou versões anteriores

Para dispositivos lançados no Android 8.x ou versões anteriores, desative (remova) a propriedade ro.product.first_api_level para o primeiro build do produto. Para todos os builds subsequentes, defina ro.product.first_api_level como o valor correto do nível da API. Isso permite que a propriedade identifique corretamente um novo produto e preserve as informações sobre o primeiro nível da API do produto. Se a flag não for definida, o Android vai atribuir Build.VERSION.SDK_INT a ro.product.first_api_level.

Pacotes de paliativo do CTS

O Android 10 ou versões mais recentes incluem um formato de pacote chamado APEX. Para executar testes CTS para APIs de gerenciamento de APEX, como atualizar para uma nova versão ou informar APEXes ativos, pré-instale um pacote CtsShimApex em uma partição /system.

O teste de validação do shim APEX verifica a implementação de CtsShimApex.

Requisitos do ro.apex.updatable

• Se a propriedade ro.apex.updatable estiver definida como true, CtsShimApex será necessário para todos os dispositivos com suporte ao gerenciamento de pacotes APEX.

• Se a propriedade ro.apex.updatable estiver ausente ou não for definida, o CtsShimApex não precisará ser pré-instalado em um dispositivo.

O teste de validação do shim APEX verifica a implementação de CtsShimApex.

Pré-instalações e pré-carregamentos do CtsShim

A partir do Android 11, CtsShimApex contém dois apps pré-criados (criados a partir de fontes de build), que não contêm nenhum código, exceto o manifesto. O CTS usa esses apps para testar privilégios e permissões.

Se o dispositivo não oferecer suporte ao gerenciamento de pacotes APEX, ou seja, se a propriedade ro.apex.updatable estiver ausente ou não estiver definida, ou se o dispositivo estiver executando a versão 10 ou anterior, os dois apps pré-criados vão precisar ser pré-instalados no sistema separadamente.

Se o APEX tiver suporte, as pré-instalações da versão adequada precisarão ser colocadas como /system/apex/com.android.apex.cts.shim.apex.

Se apps pré-criados normais forem usados, CtsShim e CtsShimPriv para a versão apropriada precisam ser colocados como /system/app/CtsShimPrebuilt.apk e /system/priv-app/CtsShimPrivPrebuilt.apk, respectivamente.

A tabela a seguir lista as pré-instalações e pré-carregamentos disponíveis para cada versão e arquitetura do dispositivo.

Versão do dispositivo	Pré-instalar (se o APEX for compatível)		Pré-carregar
	ARM	x86	ARM	x86
Android 15	android15-arm-release	android15-x86-release	android15-arm-CtsShim.apk (link em inglês) android15-arm-CtsShimPriv.apk	android15-x86-CtsShim.apk android15-x86-CtsShimPriv.apk
Android 14	android14-arm-release	android14-x86-release	android14-arm-CtsShim.apk android14-arm-CtsShimPriv.apk	android14-x86-CtsShim.apk (link em inglês) android14-x86-CtsShimPriv.apk
Android 13	android13-arm-release	android13-x86-release	android13-arm-CtsShim.apk (link em inglês) android13-arm-CtsShimPriv.apk	android13-x86-CtsShim.apk (link em inglês) android13-x86-CtsShimPriv.apk
Android 12	android12-arm-release	android12-x86-release	android12-arm-CtsShim.apk (link em inglês) android12-arm-CtsShimPriv.apk	android12-x86-CtsShim.apk android12-x86-CtsShimPriv.apk (link em inglês)
Android 11	android11-arm-release	android11-x86-release	android11-arm-CtsShim.apk android11-arm-CtsShimPriv.apk	android11-x86-CtsShim.apk android11-x86-CtsShimPriv.apk
Android 10	android10-release		android10-arm-CtsShim.apk android10-arm-CtsShimPriv.apk	android10-x86-CtsShim.apk android10-x86-CtsShimPriv.apk
Android 9, O e O-MR1	N/A	N/A	arm-CtsShim.apk arm-CtsShimPriv.apk	x86-CtsShim.apk x86-CtsShimPriv.apk

Para passar nos testes, pré-carregue os apps nos diretórios apropriados na imagem do sistema sem assinar novamente os apps.

Exemplo de applet

O Android 9 introduziu as APIs Open Mobile. Para dispositivos que informam mais de um elemento seguro, o CTS adiciona casos de teste para validar o comportamento das APIs Open Mobile. Esses casos de teste exigem a instalação única de um applet de exemplo no elemento de segurança integrado (eSE) do DUT ou no chip usado pelo DUT. O applet de exemplo do eSE e o applet de exemplo do SIM podem ser encontrados no AOSP.

Consulte Teste do CTS para elemento seguro para informações mais detalhadas sobre casos de teste da API Open Mobile e de controle de acesso.

Requisitos de armazenamento

Os testes de estresse de mídia do CTS exigem que os videoclipes estejam em um armazenamento externo (/sdcard). A maioria dos clipes é de Big Buck Bunny, que tem direitos autorais da Liquider Foundation sob a licença Creative Commons Attribution 3.0 (link em inglês).

O espaço necessário depende da resolução máxima de reprodução de vídeo com suporte do dispositivo. Consulte a seção 5 do documento de definição de compatibilidade do Android para saber a versão da plataforma das resoluções necessárias.

Observação: os recursos de reprodução de vídeo do DUT são verificados pelas APIs android.media.CamcorderProfile para versões anteriores do Android e pelas APIs android.media.MediaCodecInfo.CodecCapabilities do Android 5.0.

Confira os requisitos de armazenamento por resolução máxima de reprodução de vídeo:

• 480x360: 98 MB
• 720 x 480: 193 MB
• 1280x720: 606 MB
• 1.920 x 1.080: 1.863 MB

Tela e armazenamento

• Qualquer dispositivo que não tenha uma tela integrada precisa ser conectado a uma tela.

• Se o dispositivo tiver um slot para cartão de memória, conecte um cartão SD vazio. Use um cartão SD compatível com barramento de ultravelocidade (UHS) com capacidade SDHC ou SDXC ou um com pelo menos a classe de velocidade 10 ou mais recente para garantir que ele possa passar no CTS.

  Aviso: o CTS pode modificar/apagar dados no cartão SD conectado ao dispositivo.

• Se o dispositivo tiver slots para chip, conecte um deles a cada slot. Se o dispositivo for compatível com SMS, cada chip precisa ter o próprio campo de número preenchido. Para dispositivos com o Android 12 ou mais recente, todos os chips precisam oferecer suporte ao armazenamento de números de discagem abreviados (ADN, na sigla em inglês). Os cartões GSM e USIM com o arquivo dedicado de telecomunicações (DF_Telecom) atendem a esse requisito.

  Aviso: o CTS pode modificar/apagar dados nos chips conectados ao dispositivo.

UICC do desenvolvedor

Para executar testes de API da operadora do CTS, o dispositivo precisa usar um chip com privilégios de operadora do CTS que atendam aos requisitos especificados em Como preparar o UICC.

Configuração do dispositivo Android

1. Redefinir o dispositivo para a configuração original: Configurações > Fazer backup e redefinir > Redefinição para configuração original.

   Aviso: essa redefinição limpa todos os dados do usuário do dispositivo.

2. Defina o idioma do dispositivo como inglês (Estados Unidos): Configurações > Idioma e entrada > Idioma.

3. Se o dispositivo oferecer suporte à personalização de fontes padrão, defina a família de fontes sans-serif padrão como Roboto (a família de fontes sans-serif padrão usada em builds do AOSP).

4. Ative a configuração de localização se houver um recurso de GPS ou rede Wi-Fi/celular no dispositivo: Configurações > Localização > Ativado.

5. Conecte-se a uma rede Wi-Fi compatível com IPv6, que pode tratar o DUT como um cliente isolado (consulte Ambiente físico acima) e que tenha uma conexão de Internet: Configurações > Wi-Fi.

6. Verifique se nenhum padrão de bloqueio ou senha está definido no dispositivo: Configurações > Segurança > Bloqueio de tela > Nenhum.

7. Ative a Depuração USB no dispositivo: Configurações > Opções do desenvolvedor > Depuração USB.

   Observação: no Android 4.2 e em versões mais recentes, as Opções do desenvolvedor ficam ocultas por padrão. Para torná-las disponíveis, acesse Configurações > Sobre o dispositivo e toque em Número da versão sete vezes. Retorne à tela anterior para encontrar as Opções do desenvolvedor. Consulte Configurar um dispositivo para desenvolvimento para mais detalhes.

8. Defina a hora para o formato de 12 horas: Configurações > Data e hora > Usar formato de 24 horas > Desativado.

9. Configure o dispositivo para permanecer ativo: Configurações > Opções do desenvolvedor > Manter ativo > Ativado.

10. No Android 5.x e 4.4.x, configure o dispositivo para permitir locais fictícios: Configurações > Opções do desenvolvedor > Permitir locais fictícios > Ativado.

11. No Android 4.2 ou mais recente, desative a verificação de apps USB: Configurações > Opções do desenvolvedor > Verificar apps via USB > Desativado.

12. No Android 13 ou mais recente, configure o dispositivo para permitir o modem simulado: Configurações > Opções do desenvolvedor > Permitir modem simulado > Ativado.

    Observação: no Android 13 ou versões mais recentes, a Telefonia adicionou alguns testes de CTS que usam um modem simulado em vez de um modem real. Essa configuração precisa ser ativada nos builds do usuário para passar nos testes de CTS que precisam do modem simulado.

13. Inicie o navegador e feche qualquer tela de inicialização/configuração.

14. Conecte a máquina de desktop que será usada para testar o dispositivo com um cabo USB.

    Observação: ao conectar um dispositivo com o Android 4.2.2 ou versões mais recentes ao computador, o sistema vai mostrar uma caixa de diálogo perguntando se o usuário quer aceitar uma Chave RSA que permite a depuração pelo computador. Selecione Permitir a depuração USB.

15. Antes de executar o CTS, defina Roboto2 como a fonte sem serifa usando uma configuração de affordance acessível ao usuário (não oculta).

Instalação de arquivos

Instale e configure apps auxiliares no dispositivo.

1. Configure o dispositivo de acordo com a versão do CTS:

   • Versões 2.1 R2 a 4.2 R4 do CTS:configure seu dispositivo (ou emulador) para executar os testes de acessibilidade com: adb install -r android-cts/repository/testcases/CtsDelegatingAccessibilityService.apk

     No dispositivo, ative a delegação: Configurações > Acessibilidade > Acessibilidade > Delegação do serviço de acessibilidade.

   • Versões 6.x ou anteriores do CTS:em dispositivos que declaram android.software.device_admin, configure o dispositivo para executar o teste de administração usando: adb install -r android-cts/repository/testcases/CtsDeviceAdmin.apk`

     Em Configurações > Segurança > Selecionar administradores do dispositivo, ative os dois administradores do dispositivo android.deviceadmin.cts.CtsDeviceAdminReceiver*. Confira se android.deviceadmin.cts.CtsDeviceAdminDeactivatedReceiver e qualquer outro administrador de dispositivo pré-carregado permanecem desativados.

2. Copie os arquivos de mídia do CTS para o dispositivo da seguinte forma:

   Observação: para o CTS 2.3 R12 ou mais recente, se o dispositivo oferece suporte a codecs de vídeo, os arquivos de mídia do CTS precisam ser copiados para o dispositivo.
   1. Navegue (cd) até o caminho em que os arquivos de mídia são transferidos por download e descompactados.

   2. Mude as permissões do arquivo: chmod u+x copy_media.sh

   3. Copie os arquivos necessários:

      • Para copiar clipes com resolução de até 720x480, execute:

        ./copy_media.sh 720x480
        

      • Se você não tiver certeza da resolução máxima, copie todos os arquivos:

        ./copy_media.sh all
        

      • Se houver vários dispositivos no adb, adicione a opção serial (-s) de um dispositivo específico ao final. Por exemplo, para copiar até 720x480 para o dispositivo com o número de série 1234567, execute:

        ./copy_media.sh 720x480 -s 1234567