Para executar o CTS, primeiro prepare o ambiente físico, a máquina desktop e o dispositivo Android usado nos testes.
Ambiente físico
Beacons Bluetooth LE
Se o dispositivo em teste (DUT) for compatível com Bluetooth LE, coloque pelo menos três Sensores Bluetooth LE a 5 metros do DUT para 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 tiver suporte para banda ultralarga (UWB), outro dispositivo a UWB de suporte precisa estar posicionada perto o suficiente e orientada para não ter uma zona morta de rádio e antenas. 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 estão a um metro de distância. Para detalhes sobre a fragmentação, que é necessária para este teste, consulte Fragmentação local.
Cameras
Ao executar o CTS da câmera, use condições de iluminação normais com um padrão de teste gráfico (como um padrão quadriculado). Posicione o gráfico de padrões de teste de acordo à distância mínima de foco do DUT para garantir que não fique muito próximo do lente.
Aponte os sensores da câmera para uma cena com iluminação suficiente para que o
sensores em teste para alcançar e permanecer nos frames-alvo máximos configurados
por segundo (QPS), conforme especificado
CONTROL_AE_TARGET_FPS_RANGE
Isso se aplica a todos os sensores de câmera informados por
getCameraIdList
à medida que o teste itera nos dispositivos listados e mede o desempenho
individualmente.
Se o DUT for compatível com câmeras externas, como webcams USB, conecte um câmera ao executar o CTS. Caso contrário, os testes de CTS falham.
GPS/GNSS
Se o DUT for compatível com o sistema de posicionamento global/satélite de navegação global GPS/GNSS, forneça um sinal de GPS/GNSS ao DUT em um nível de sinal para recepção e cálculo de localização de GPS. A parte do GPS deve ser em conformidade com a ICD-GPS-200C. Caso contrário, o sinal GPS/GNSS pode ser de qualquer tipo, incluindo um simulador de satélite ou um repetidor de GPS/GNSS de sinais externos, ou é possível colocar o DUT perto o suficiente de uma janela para que ele possa receber sinal de GPS/GNSS suficiente.
Wi-Fi e IPv6
Os testes CTS exigem uma rede Wi-Fi com suporte a IPv4 e IPv6, tenha uma conexão com DNS ativo para IPv4 e IPv6, tem suporte a multicast de IP e pode trate o DUT como um cliente isolado. Um cliente isolado é uma configuração em que o DUT não tem visibilidade das mensagens de transmissão/multirrede nessa sub-rede. Isso ocorre com uma configuração de ponto de acesso (AP) Wi-Fi ou executando o DUT em um 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 uma VPN para passar em alguns testes dependendo do IPv6, é possível usar um ponto de acesso um túnel IPv6.
Para transmitir o CTS, o DUT precisa das flags UP, BROADCAST e MULTICAST definidas em
a 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 do Wi-Fi STA/STA, várias redes Wi-Fi (pelo menos duas) são necessárias. Para passar no CTS, a conexão Wi-Fi precisam funcionar em bandas diferentes com SSIDs diferentes ou no mesmo SSID com BSSIDs diferentes.
RTT do Wi-Fi
O Android inclui o API Wi-Fi RTT para um tempo de retorno (RTT) do Wi-Fi. capacidade de processamento. 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 compatíveis com Wi-Fi RTT são Google Wifi e Ponto de acesso Fitlet2 da Compulab (definida 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 são recomendados para estar a menos de 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 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 ambos Android Debug Bridge (adb) e Android Asset Packaging Tool (AAPT2) e adicionamos o local dessas ferramentas ao caminho do sistema da sua máquina.
Para instalar o ADB e o AAPT2, faça o download da versão mais recente Android SDK Platform-Tools e Ferramentas de build do SDK do Android da biblioteca de cliente SDK Manager ou no sdkmanager (em inglês) ferramenta de linha de comando.
Verifique se adb e aapt2 estão no caminho do sistema. O comando a seguir
presume que você fez o download dos arquivos do pacote em um subdiretório chamado
android-sdk no seu diretório principal:
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, 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
Instalação
instruções.
Para verificar se a instalação foi bem-sucedida, invoque virtualenv -h.
Arquivos CTS
Faça o download e abra os pacotes CTS Downloads do conjunto de teste de compatibilidade correspondendo aos seus dispositivos Versão do Android e todas as interfaces binárias do aplicativo (ABIs) compatíveis com seus dispositivos.
Baixe e abra a versão mais recente do 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 à linha principal, que adicionam pelo menos 10 minutos ao tempo de execução, dependendo da velocidade da rede.
Para evitar esse tempo de execução adicional do CTS, faça o download do CTS relacionado à linha principal 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.sh. para fazer o download dos arquivos Mainline CTS.O download leva pelo menos 10 minutos, dependendo da velocidade da sua rede.
Detecção de dispositivos
Siga a etapa para configurar seu sistema para detectar seu dispositivo.
Limite de memória
Aumente a memória disponível durante a execução do teste no cts-tradefed (em inglês) script. 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 sistema conhecido por ser compatível versão do usuário (Android 4.0 ou superior) a partir Codinomes, tags e números de build.
Propriedade de build de primeiro nível da API
Alguns requisitos do CTS dependem da versão original do dispositivo. enviado. Por exemplo, dispositivos que vêm com builds anteriores. podem ser excluídos dos requisitos do sistema que se aplicam a dispositivos que são enviados com builds posteriores.
Para disponibilizar essas informações para o CTS, os fabricantes de dispositivos podem ter
definiu a propriedade de tempo de build ro.product.first_api_level. O valor dessa
é o primeiro nível de 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 dispositivo
grupo. Os fabricantes de dispositivos podem definir o nível da API dos
produto para ro.product.first_api_level, de modo que os requisitos de upgrade sejam
aplicadas ao CTS e Treble/VTS.
Os fabricantes de dispositivos podem definir PRODUCT_SHIPPING_API_LEVEL nas próprias
device.mk para definir essa propriedade, conforme mostrado no exemplo a seguir:
# 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 o
a propriedade ro.product.first_api_level como um valor válido
Codinomes, tags e números de build.
Primeiro nível da API para Android 8.x ou anterior
Para dispositivos lançados com Android 8.x ou versões anteriores, defina (remover) a configuração
ro.product.first_api_level para o primeiro build do produto. Para
em todos os builds subsequentes, defina ro.product.first_api_level como o nível correto da API.
. Isso permite que a propriedade identifique corretamente um novo produto e
preserva informações sobre o primeiro nível de API do produto. Se a sinalização for
não definida, o Android atribui 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 (em inglês). Para executar testes CTS para gerenciamento de APEX
APIs (como atualizar para uma nova versão ou relatar APEXs ativos), você precisa
pré-instale 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,CtsShimApexserá necessário para todos os dispositivos com suporte ao gerenciamento de pacotes APEX.Se a propriedade
ro.apex.updatableestiver ausente ou não estiver definida,CtsShimApexnão precisa 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
e pré-criados (criados a partir
origem do build),
que não contêm nenhum código, exceto o manifesto. O CTS usa esses aplicativos para
para testar as permissões e os privilégios.
Se o dispositivo não oferecer suporte ao gerenciamento de pacotes APEX (ou seja, o
A propriedade ro.apex.updatable está ausente ou não foi definida, ou se o dispositivo está
executando a versão 10 ou inferior, os dois apps pré-criados precisam
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 para a
versão apropriada deve ser colocada 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.
Para passar nos testes, pré-carregue os aplicativos nos diretórios apropriados no imagem do sistema sem assinar novamente os apps.
miniaplicativo de exemplo
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 do APIs de terceiros. Esses casos de teste exigem a instalação única de um miniaplicativo de amostra no elemento de segurança incorporado (eSE) do DUT ou no chip usado pelo DURANTE. A Applet de exemplo eSE (em inglês) e o Applet de exemplo do chip podem ser encontrados no AOSP.
Consulte Teste CTS para elemento de segurança para informações mais detalhadas sobre os casos de teste da Open Mobile API e o teste de controle de acesso casos de uso diferentes.
Requisitos de armazenamento
Os testes de estresse de mídia do CTS exigem que os videoclipes estejam no armazenamento externo
(/sdcard). A maioria dos clipes vem de
Big Buck Bunny, que é protegida por direitos autorais
pela Liquider Foundation, no
Licença Creative Commons Atribuição 3.0.
O espaço necessário depende da resolução máxima de reprodução de vídeo suportada pelo o dispositivo. Consulte a seção 5 nos documento de definição de compatibilidade do Android para os e a versão mais recente 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 um tela.
Se o dispositivo tiver um slot para cartão de memória, conecte um cartão SD vazio. Usar um SD compatível com barramentos de velocidade ultra-alta (UHS) com capacidade SDHC ou SDXC ou um com classe de velocidade mínima 10 ou superior para garantir que possa passar pela a CTS.
Se o dispositivo tiver slots para chip, conecte um deles a cada slot. Se o dispositivo permitir SMS, cada chip precisará ter seu próprio campo de número preenchida. Para dispositivos com o Android 12 ou superior, todos os chips devem aceitar o armazenamento de discagem abreviada ou ADN (na sigla em inglês). 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 CTS, o dispositivo precisa usar um chip com operadora CTS privilégios que atendem aos requisitos especificados Como preparar o UICC.
Configuração do dispositivo Android
Redefinir o dispositivo para a configuração original: Configurações > Backup e redefinir > Dados de fábrica redefinir.
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 o padrão Família de fontes
sans-serifparaRoboto(a família de fontes padrãosans-serif) usados em builds do AOSP).Ative a configuração de localização se houver um GPS ou uma rede Wi-Fi/celular no dispositivo: Configurações > Local > Ativada.
Conectar-se a uma rede Wi-Fi que ofereça suporte a IPv6 e possa tratar o DUT como um Cliente isolado (consulte Ambiente físico acima), e tenha uma conexão com a 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 vez > Usar 24 horas formato > Desativado.
Configure o dispositivo para permanecer ativado: Configurações > Opções do desenvolvedor > Manter ativado > Ativada.
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 > Ativada.
No Android 4.2 ou superior, desative a verificação de apps USB: Configurações > Opções do desenvolvedor > Verificar apps por 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 > Ativada.
Inicie o navegador e dispense qualquer tela de inicialização/configuração.
Conecte o computador que será usado para testar o dispositivo com um USB. cabo.
Antes de executar o CTS, defina Roboto2 como a fonte sans-serif usando um configuração de affordance acessível (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.apkAtive a delegação no dispositivo: Configurações > Acessibilidade > Acessibilidade > Delegar o serviço de acessibilidade.
CTS versões 6.x ou anteriores:em dispositivos que declaram
android.software.device_admin, configure seu dispositivo para executá-lo teste de administração usando:adb install -r android-cts/repository/testcases/CtsDeviceAdmin.apk`Em Configurações > Segurança > Selecione os administradores do dispositivo, ative a dois dispositivos
android.deviceadmin.cts.CtsDeviceAdminReceiver*administradores. Verifique seandroid.deviceadmin.cts.CtsDeviceAdminDeactivatedReceivere qualquer e 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 onde é feito o download dos arquivos de mídia e descompactado. 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 (