Para executar o CTS, primeiro prepare o ambiente físico, a máquina desktop e o dispositivo Android que você está usando para testes.
Ambiente físico
Beacons Bluetooth LE
Se o dispositivo em teste (DUT) oferecer suporte ao Bluetooth LE, coloque pelo menos três sensores Bluetooth LE a uma distância de até cinco metros do DUT para o teste de verificação do Bluetooth LE. Esses sensores não precisam ser configurados nem emitir nada específico e podem ser de qualquer tipo, incluindo iBeacon, Eddystone ou até mesmo dispositivos que simulam sensores BLE.
Banda ultralarga
Se o DUT oferecer suporte à banda ultralarga (UWB), outro dispositivo com suporte a UWB precisará estar posicionado próximo o suficiente e orientado para não ter antenas e zona sem sinal de rádio. Para os testes de precisão de distância, há necessidades específicas de posicionamento e orientação. Para detalhes de 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 detalhes sobre a fragmentação necessária para este teste, consulte Fragmentação local.
Câmeras
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 quadriculado). Posicione o gráfico de padrão de teste de acordo com a distância mínima de foco do DUT para garantir que ele não esteja muito perto 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 quadros por segundo (QPS)
configurados, conforme especificado em
CONTROL_AE_TARGET_FPS_RANGE.
Isso se aplica a todos os sensores de câmera informados por
getCameraIdList,
à medida que o teste é iterado nos 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 a 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 posicionar o DUT perto o suficiente de uma janela para que ele possa receber diretamente sinais de GPS/GNSS suficientes.
Wi-Fi e IPv6
Os testes CTS exigem uma rede Wi-Fi que ofereça suporte a IPv4 e IPv6, tenha uma conexão de Internet com DNS ativo para IPv4 e IPv6, seja compatível com multicast de IP e possa 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/multirrede nessa sub-rede. Isso ocorre com uma configuração de ponto de acesso (AP, na sigla em inglês) Wi-Fi ou executando o DUT em uma sub-rede isolada sem que outros dispositivos estejam conectados.
Se você não tiver acesso a uma rede IPv6 nativa, a uma rede de operadora de IPv6 ou a uma VPN para passar em alguns testes que dependem de 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 de endereços IPv4 e IPv6 atribuídos.
Verifique as propriedades da interface Wi-Fi com adb shell ifconfig.
Para dispositivos com suporte à simultaneidade de Wi-Fi STA/STA, são necessárias várias redes Wi-Fi (pelo menos duas). 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 oferecer o recurso de tempo de retorno (RTT) do Wi-Fi. 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 devem estar carregados, 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 estejam a até 12 metros do DUT. Normalmente, um ponto de acesso é suficiente.
Configuração da máquina desktop
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 posterior) na máquina host.
Upgrade da máquina host
É altamente recomendável fazer upgrade da RAM da máquina host CTS para 128 GB e no HDD para 256 GB. Ele é necessário para acomodar o aumento do número de casos de teste CTS e um aumento na reserva de espaço de heap Java no Tradefed.
ADB e AAPT2
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 das Android SDK Build Tools 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>
Kit de desenvolvimento Java para Ubuntu
Instale a versão correta do Kit de desenvolvimento em Java (JDK).
- Para o Android 11, instale o OpenJDK11.
- Para o Android 9 e 10, instale o OpenJDK9.
- Para Android 7.0, 7.1, 8.0 e 8.1, instale o OpenJDK8.
Para detalhes, consulte os requisitos do JDK.
Configuração para suporte a Python
Instale o virtualenv na sua plataforma seguindo as
instruções de
instalação.
Para verificar se a instalação foi bem-sucedida, 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 dos arquivos CTS relacionados ao Mainline (opcional)
Quando você executa uma versão do CTS pela primeira vez, ele faz o download dinâmico de alguns arquivos CTS relacionados ao Mainline, o que adiciona pelo menos 10 minutos ao tempo de execução, dependendo da velocidade da rede.
Para evitar esse tempo de execução do CTS, faça o download dos arquivos CTS relacionados ao Mainline antes de executar a versão do CTS seguindo estas instruções:
Para saber o nível da API Android no dispositivo, execute:
adb shell getprop ro.build.version.sdkSiga as instruções no script
download_mcts.shpara fazer o download dos arquivos CTS de linha principal.O download leva pelo menos 10 minutos, dependendo da velocidade da sua rede.
Detecção de dispositivos
Siga a etapa para configurar o sistema para detectar o dispositivo.
Limite de memória
Aumente a memória máxima disponível durante a execução do teste no script cts-tradefed. Consulte o exemplo de CL para mais informações.
Configuração de dispositivos Android
Compilações de usuários
Um dispositivo compatível é definido como um dispositivo com uma versão assinada do usuário/chave de lançamento. O dispositivo precisa executar uma imagem do sistema com base no build de usuário conhecido como compatível (Android 4.0 ou mais recente) em Codinomes, tags e números de build.
Propriedade de build de primeiro nível da API
Alguns requisitos do CTS dependem da versão com que o dispositivo foi originalmente enviado. Por exemplo, dispositivos que foram enviados originalmente com builds anteriores podem ser excluídos dos requisitos do sistema que se aplicam a dispositivos que vêm com builds mais recentes.
Para disponibilizar essas informações para o CTS, os fabricantes de dispositivos podem ter definido a propriedade de tempo de compilação ro.product.first_api_level. O valor dessa
propriedade é o primeiro nível da API com que o dispositivo foi lançado comercialmente.
Os fabricantes de dispositivos podem reutilizar a implementação subjacente 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 Treble/VTS.
Os fabricantes de dispositivos podem definir PRODUCT_SHIPPING_API_LEVEL no
arquivo device.mk para configurar 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 versões mais recentes, defina a propriedade
ro.product.first_api_level como um valor válido de
Codinomes, tags e números de build.
Primeiro nível da API para Android 8.x ou anterior
Para dispositivos lançados com o Android 8.x ou versões anteriores, desmarque (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 com o valor correto de nível
da API. Isso permite que a propriedade identifique corretamente um novo produto e preserve informações sobre o primeiro nível de API do produto. Se a sinalização não for
definida, o Android 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 atualização para uma nova versão ou geração de relatórios de APEXs ativos, é necessário
pré-instalar um pacote CtsShimApex em uma partição /system.
O teste de validação paliativo APEX verifica a implementação de CtsShimApex.
Requisitos do ro.apex.updatable
Se a propriedade
ro.apex.updatablefor definida comotrue, oCtsShimApexserá obrigatório para todos os dispositivos com suporte ao gerenciamento de pacotes APEX.Se a propriedade
ro.apex.updatableestiver ausente ou não estiver definida, oCtsShimApexnão precisará ser pré-instalado em um dispositivo.
O teste de validação paliativo APEX verifica a implementação de CtsShimApex.
Pré-instalações e pré-carregamentos do CtsShim
No Android 11 e versões mais recentes, o CtsShimApex contém dois
apps pré-criados (criados da
origem do build),
que não têm 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 for compatível, 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 comuns forem usados, CtsShim e CtsShimPriv da
versão adequada precisarão ser colocados como /system/app/CtsShimPrebuilt.apk e
/system/priv-app/CtsShimPrivPrebuilt.apk, respectivamente.
A tabela a seguir lista as pré-instalações e os pré-carregamentos disponíveis para cada versão e arquitetura do dispositivo.
Para passar nos testes, pré-carregue os apps nos diretórios apropriados na imagem do sistema sem assinar novamente os apps.
miniaplicativo de exemplo
O Android 9 introduziu as APIs Open Mobile. Para dispositivos que relatam mais de um elemento de segurança, 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 miniaplicativo de amostra no elemento de segurança incorporado (eSE, na sigla em inglês) do DUT ou no chip usado pelo DUT. O applet de exemplo eSE e o miniaplicativo de exemplo do chip podem ser encontrados no AOSP.
Consulte Teste CTS para elemento de segurança para informações mais detalhadas sobre casos de teste da API Open Mobile e casos de teste 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 aceita pelo dispositivo. Consulte a seção 5 no documento Definição de compatibilidade do Android para conferir a versão da plataforma das resoluções necessárias.
Estes são os requisitos de armazenamento por resolução máxima de reprodução de vídeo:
- 480 x 360: 98 MB
- 720 x 480: 193 MB
- 1.280 x 720: 606 MB
- 1.920 x 1.080: 1.863 MB
Tela e armazenamento
- Qualquer dispositivo que não tenha uma tela incorporada precisa ser conectado a uma tela.
Se o dispositivo tiver um slot para cartão de memória, conecte um cartão SD vazio. Para garantir que ele possa transmitir o CTS, use um cartão SD que ofereça suporte a barramentos de velocidade ultra-alta (UHS) com capacidade SDHC ou SDXC ou um que tenha classe de velocidade mínima 10 ou superior.
Se o dispositivo tiver slots para chip, conecte um deles a cada slot. Se o dispositivo aceitar SMS, cada chip precisará ter o próprio campo de número preenchido. Para dispositivos com o Android 12 ou versões mais recentes, todos os chips precisam oferecer suporte ao armazenamento de números de discagem abreviados (ADN). Os cartões GSM e USIM com o arquivo dedicado de telecomunicações (DFTelecom) atendem a esse requisito.
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
Redefinir o dispositivo para a configuração original: Configurações > Fazer backup e redefinir > Redefinição para configuração original.
Defina o idioma do dispositivo como inglês (Estados Unidos): Configurações > Idioma e entrada > Idioma.
Se o dispositivo oferecer suporte à personalização de fontes padrão, defina a família de fontes
sans-serifpadrão comoRoboto(a família de fontessans-serifpadrão usada nos builds do AOSP).Ative a configuração de localização se houver um recurso de GPS ou de rede Wi-Fi/celular no dispositivo: Configurações > Localização > Ativado.
Conecte-se a uma rede Wi-Fi que ofereça suporte a IPv6, possa tratar o DUT como um cliente isolado (consulte Ambiente físico acima) e tenha uma conexão de Internet: Configurações > Wi-Fi.
Verifique se nenhum padrão de bloqueio ou senha está definido no dispositivo: Configurações > Segurança > Bloqueio de tela > Nenhum.
Ative a Depuração USB no dispositivo: Configurações > Opções do desenvolvedor > Depuração USB.
Defina a hora para o formato de 12 horas: Configurações > Data e hora > Usar formato de 24 horas > Desativado.
Configure o dispositivo para permanecer ativado: Configurações > Opções do desenvolvedor > Manter ativado > Ativado.
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.
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.
No Android 13 ou mais recente, configure o dispositivo para permitir um modem simulado: Configurações > Opções do desenvolvedor > Permitir Mock Modem > Ativado.
Inicie o navegador e dispense qualquer tela de inicialização/configuração.
Conecte o computador que será usado para testar o dispositivo com um cabo USB.
Antes de executar o CTS, defina Roboto2 como a fonte sans-serif usando uma configuração de acessibilidade ao usuário (não oculta).
Instalação de arquivos
Instale e configure apps auxiliares no dispositivo.
Configure o dispositivo de acordo com a versão do CTS:
Versões 2.1 R2 a 4.2 R4 do CTS:configure o dispositivo (ou emulador) para executar os testes de acessibilidade com:
adb install -r android-cts/repository/testcases/CtsDelegatingAccessibilityService.apkNo dispositivo, ative a delegação: Settings > Accessibility > Accessibility > Delegating Accessibility Service.
Versão 6.x ou anterior do CTS:em dispositivos que declaram
android.software.device_admin, configure o dispositivo para executar o teste de administração do dispositivo usando:adb install -r android-cts/repository/testcases/CtsDeviceAdmin.apk`Em Configurações > Segurança > Selecionar administradores do dispositivo, ative os dois administradores de dispositivo
android.deviceadmin.cts.CtsDeviceAdminReceiver*. Verifique seandroid.deviceadmin.cts.CtsDeviceAdminDeactivatedReceivere todos os outros administradores de dispositivos pré-carregados permanecem desativados.
Copie os arquivos de mídia do CTS para o dispositivo da seguinte forma:
- Navegue (
cd) até o caminho em que os arquivos de mídia são transferidos por download e descompactados. Mude as permissões do arquivo:
chmod u+x copy_media.shCopie os arquivos necessários:
Para copiar clipes com resolução de 720 x 480, execute:
./copy_media.sh 720x480Se você não tiver certeza da resolução máxima, copie todos os arquivos:
./copy_media.sh allSe 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
- Navegue (