Para engenheiros de controle de qualidade: como usar o Android Debug Bridge no teste de aplicativos móveis

Olá, Hackernoon! Meu nome é Alexander Karpenko e trabalho como engenheiro de controle de qualidade na inDrive . Eu preparei este artigo para especialistas iniciantes em controle de qualidade. Abaixo, mostrarei como usar o Android Debug Bridge (ADB) em testes de aplicativos móveis e por que ele é necessário em primeiro lugar.

Imagino que você já tenha conhecimento básico sobre fundamentos de teste, então vou pular o processo de preparação e configuração de projetos.

Os recursos do ADB estão em constante expansão, mas vou compartilhar algumas técnicas valiosas que irão melhorar seu fluxo de trabalho diário. Como minha história é sobre testes de aplicativos móveis, vou me concentrar no macOS, que permite que você trabalhe de maneira eficaz com todas as plataformas móveis populares. Para outros sistemas operacionais, os exemplos podem ser um pouco diferentes, mas espero que os usuários do Windows não usem isso contra mim.

Para começar, vamos tocar nos comandos mais básicos para garantir que os pontos posteriores sejam apresentados em uma sequência lógica.

Exibindo uma lista de dispositivos conectados e conectando-se ao dispositivo

Normalmente, trabalhamos com um dispositivo, mas às vezes vários dispositivos estão conectados, por exemplo, via TCP/IP. Nesse caso, temos que especificar manualmente o dispositivo no qual queremos executar o comando.

Exibir a lista de todos os dispositivos conectados para obter um identificador

adb devices — exibe a lista de dispositivos conectados (usar a opção -l abre uma lista estendida de propriedades). Isso é útil se vários dispositivos estiverem conectados e não for imediatamente claro qual deles precisamos.

Para informar ao ADB qual dispositivo visar, o número de série do dispositivo deve ser especificado após a opção -s :

adb -s <serial_number> <command> , onde <serial_number> é o número de série do dispositivo da lista e <command> é o comando a ser executado no dispositivo.

Por exemplo, instalar um aplicativo em um dispositivo específico da lista:

adb -s 32312b96 install user/download/app.apk

Outro cenário frequente é quando a operação envolve simultaneamente um dispositivo real e um emulador, por exemplo, para as diferentes funções de executor/originador. Nesse caso, os dispositivos são facilmente distinguíveis não por seu número de série, mas com base nas opções —d —e após o comando adb. Exemplo:

adb —d install user/download/app.apk — o comando será executado no dispositivo real, com a opção —е no emulador.

Também podemos nos conectar ao dispositivo por TCP/IP quando ele usa a mesma rede Wi-Fi. Para fazer isso, conecte o dispositivo ao PC com um cabo e altere o modo de operação do dispositivo de USB para TCP/IP usando o comando:

adb tcpip 5555

Determine o endereço IP do dispositivo por qualquer método disponível

Por exemplo, através das configurações do telefone em Informações Gerais ou com o comando:

adb shell ifconfig wlan0

Se o seu dispositivo já estiver desconectado do PC neste momento, certifique-se de especificar adicionalmente o S/N do dispositivo. Em seguida, nos conectamos a ele:

adb connect ip_address:5555

O dispositivo pode ser desabilitado com o comando:

adb disconnect ip_address:5555

adb disconnect — para desabilitar todos os nossos dispositivos TCP/IP.

Para retornar ao modo USB, use o comando:

adb usb (minúsculas são importantes).

Instalar e desinstalar o aplicativo e localizar o pacote no dispositivo

O aplicativo é instalado usando o comando:

adb install <apk_path> , onde <apk_path> é o caminho absoluto para nosso arquivo de aplicativo APK.

Aqui estão algumas opções úteis após o comando de instalação que são frequentemente usadas:

—d — reinstala com uma versão rebaixada. Caso contrário, haverá uma falha (erro) [INSTALL_FAILED_VERSION_DOWNGRADE] ).

—r — reinstala o aplicativo com os dados salvos.

—g — concede todas as permissões especificadas no manifesto do aplicativo durante o processo de instalação.

Por exemplo, um aplicativo instalado com esta opção não solicitará que você permita o acesso à geolocalização ou espaço de armazenamento para baixar fotos.

O aplicativo é desinstalado com base no nome do pacote. Para fazer isso, você precisa saber como o aplicativo está registrado no sistema. Use o Shell e o Gerenciador de Pacotes (pm).

Execute o seguinte comando para exibir a lista de todos os aplicativos instalados:

adb shell pm list packages

A lista pode ser filtrada pelo nome do aplicativo. Você precisará disso se a lista for muito grande, mas sabemos qual palavra está contida no nome do pacote:

adb shell pm list packages | grep com.myApp

Você também pode enviar para um arquivo separado e encontrar o pacote necessário lá:

adb shell pm list packages > /Users/username/packages.txt

Agora que sabemos como descobrir o nome do pacote do aplicativo, vamos voltar a como removê-lo do dispositivo. Isso pode ser feito usando o comando:

adb uninstall com.myApp

adb uninstall -k com.myApp — exclui o aplicativo, mas salva os dados e os arquivos de cache.

Vou apresentar separadamente um comando que muitas vezes pode ser útil:

adb shell pm clear com.myApp — limpa o cache e os dados do aplicativo.

Baixando o arquivo APK do dispositivo

Acho que é uma situação rara de se encontrar. Mas isso pode ser útil para alguém, assim como já foi para mim. Todos os aplicativos instalados armazenam seus arquivos APK na pasta /data/app. Como você sabe o nome do pacote, pode encontrar o local onde o aplicativo está instalado e baixar seu APK de lá. Para fazer isso, execute o seguinte comando:

adb shell pm path com.myApp — exibe o diretório de instalação do aplicativo.

Isso pode não parecer tão apresentável:

package:/data/app/~~YcTsnr19yQR6ENa0q2EMag==/com.myApp—IHasf91SDB0erQLagc8j0Q==/base.apk

Mas é exatamente assim que precisamos que esse caminho pareça. Vamos avançar um pouco e ver como podemos copiar o arquivo que precisamos para o PC a partir do telefone. Isso pode ser feito usando o comando:

adb pull <crazyPath> /Users/username/ , onde <crazyPath> é a saída do nosso comando anterior, /Users/username/ é o caminho no PC para onde você deseja copiar nosso arquivo.

Campos de texto

Vamos falar brevemente sobre a verificação de campos de texto. Por exemplo, você deve verificar o limite do número máximo de caracteres que podem ser inseridos em um campo de texto. Se você usar um único dispositivo, diferentes conjuntos de dados transferidos podem ser armazenados no telefone ou na nuvem. No entanto, se o teste tiver que ser feito em dispositivos diferentes, os dados do teste podem ser armazenados no PC e transferidos para os dispositivos por meio dos seguintes comandos:

adb shell input text <text>

Exemplo:

adb shell input text test%stest — a string "test test" será inserida. Substitua os espaços pelos caracteres especiais %s , caso contrário, apenas a parte anterior ao espaço será enviada ao dispositivo. Se usarmos caracteres especiais como !@# no texto que está sendo transmitido, eles devem ser marcados inserindo uma barra invertida ( \ ) na frente deles.

Por exemplo, o comando:

adb shell input text test\!\@\#\$%stest exibirá “test!@#$ test” na tela

(ADB não funciona com caracteres cirílicos e gera um erro NullPointerException).

O conteúdo de uma área de transferência pode ser transferido desta forma:

adb shell input text $(pbpaste)

Lembre-se de que alguns caracteres podem não ser transmitidos conforme aparecem no PC. O problema pode ser resolvido usando um editor de texto streaming (sed). Aqui está um exemplo de um comando estendido onde substituímos todos os espaços no buffer pelos caracteres especiais necessários para garantir que o texto seja transferido para o dispositivo da maneira correta:

adb shell input text $(pbpaste | sed -e 's/ /\%s/g')

pbpaste é o texto contido no buffer.

A ”—e” —permite que você execute os comandos necessários para editar o texto.

“s/take this/change_it_to/option” é o modelo (padrão) a ser usado.

/g é o sinalizador para substituir todas as correspondências de um modelo específico, sem exceção.

Links profundos

Lembre-se de que é melhor quando o teste é feito em um ambiente o mais próximo possível da vida real, mas é útil saber que essa opção também está disponível.

Essa estratégia ajudará você a verificar os links profundos para as telas necessárias, quando várias telas forem usadas, ou se tivermos problemas com a infraestrutura e nenhuma notificação push chegar, ou se nenhuma delas chegou ainda, mas você precisa verificar como o aplicativo se comporta.

Você também pode verificar se o aplicativo funciona corretamente e não trava se um link profundo inválido aparecer no alerta de notificação por push. Ou ao lidar com uma situação em que seguimos um link profundo para uma tela que não existe mais, ou cujo status mudou, ou se não deveríamos ter acesso a essa tela em primeiro lugar, porque o alerta de envio foi no notificações por um longo tempo. Pode haver muitas situações como esta.

No Shell ADB, podemos usar o Activity Manager (AM) para executar comandos.

Iniciamos nossa atividade e enviamos o deep link que queremos verificar. O deep link geralmente contém o caractere “&”, que separa as telas. Portanto, ao abrir através de um terminal, uma barra invertida (\) deve ser inserida na frente dele.

adb shell am start -W -a android.intent.action.VIEW -d “myApp://open/client/trip\&last_trip=test” com.myApp

am — chama o Activity Manager.

W — aguardando o download antes de executar um comando.

a — determina qual ação deve ser tomada. Neste caso, é action.View .

d — dados necessários para a execução. Nesse caso, estamos falando do deep link em si e depois do aplicativo que deve ser usado para abri-lo.

Pode ser necessário reinserir as aspas manualmente ou substituí-las por aspas simples ao transferir o comando para o terminal. Se houver um erro de sintaxe, você poderá receber uma mensagem apropriada.

Criando capturas de tela e gravando vídeos da tela do dispositivo

Use este comando para tirar uma captura de tela:

adb shell screencap -p <device_path/screenshot_name.png>

Exemplo:

adb shell screencap -p /sdcard/screencap.png — faz uma captura de tela e salva um arquivo chamado screencap.png no dispositivo na pasta /sdcard/screencap.png .

Você pode salvar a captura de tela em seu computador da seguinte maneira:

adb pull /sdcard/screencap.png — por padrão, o arquivo é copiado para o diretório do usuário atual, ou seja, /Users/username/screencap.png .

Ou você pode executar o comando inteiro de uma só vez:

adb shell screencap -p /sdcard/screencap.png && adb pull /sdcard/screencap.png

Nas versões mais recentes do ADB, o seguinte comando pode ser usado para obter uma captura de tela:

adb exec—out screencap —p > screen.png — o arquivo de captura de tela também aparecerá no diretório do usuário atual no PC.

O caminho padrão pode ser alterado manualmente sendo adicionado ao final do comando:

adb exec—out screencap -p > downloads/test/screen.png — e a captura de tela aparecerá na pasta /Users/username/downloads/test/screen.png .

Se estiver interessado, você também pode automatizar um pouco esse processo adicionando um alias a bash_profile . No macOS, você pode usar o Automator Service para criar e configurar teclas de atalho.

Use este comando para gravar um vídeo:

adb shell screenrecord device_path .

Exemplo:

adb shell screenrecord /sdcard/screenrecord.mp4 — use este comando para iniciar a gravação da tela do dispositivo com base nas configurações padrão por três minutos e salve o resultado no arquivo /sdcard/screenrecord.mp4 no dispositivo.

Você pode especificar manualmente o tempo de gravação usando o interruptor —time—limit time (em segundos, mas a duração da gravação ainda é limitada a 180 segundos).

A gravação pode ser interrompida antes do tempo pressionando CTRL + C

O arquivo também pode ser copiado usando o comando pull, de maneira semelhante ao procedimento de captura de tela.

Você também pode verificar os recursos adicionais desse utilitário usando a opção --help . Aliás, é capaz de alterar a resolução de gravação e taxa de bits, bem como adicionar dados adicionais para o relatório de bug.

É útil usar a opção -bugreport , que adiciona informações sobre o sistema usado para a gravação como o primeiro quadro do vídeo.

Agora que abordamos como baixar algum conteúdo do dispositivo, vamos nos concentrar um pouco em como fazer upload de algo para ele.

Abrimos no nosso PC, ajustamos o formato e o conteúdo, fizemos o download para o nosso telefone e verificamos se o aplicativo responde corretamente a formatos desconhecidos e limites de tamanho excessivo. Para fazer upload de um arquivo para o seu telefone a partir do seu PC, você pode usar este comando:

adb push /Users/username/file <device_path>

Vamos executar o comando:

adb push /Users/username/screen.png sdcard — isso copiará nosso arquivo screen.png para o cartão SD do telefone.

Verificando se o estado do aplicativo foi restaurado após sua exclusão pelo sistema

Outro exemplo de experiência diz respeito a verificar se o estado do aplicativo foi restaurado após sua exclusão pelo sistema. Recolher o aplicativo, encerrar o processo - esta ação simula a situação em que o sistema interrompe o processo porque não há memória suficiente disponível:

adb shell am kill com.myApp

Execute-o novamente e verifique se tudo está funcionando bem.

Nos deparamos com este cenário: um usuário minimiza um aplicativo enquanto está em uma determinada tela. Depois de um tempo, o sistema desacelera o processo e armazena em cache seu estado. Quando o usuário tenta expandir o aplicativo, ele falha. Isso acontece quando os dados do cache são acessados, pois os fragmentos estão restaurando sua pilha e seu estado, mas o cache já está vazio. Infelizmente, esse bug passou despercebido durante a fase de testes, pois não o havíamos encontrado antes, e acabou entrando em produção. Agora que você sabe que é possível, pode garantir que não repetirá nossos erros.

Histórico

É uma boa ideia verificar os logs ao tentar descobrir o que causou a falha de um aplicativo. Se você deseja salvar o conteúdo do buffer de log atual, isso pode ser feito usando o seguinte comando:

adb logcat — exibe logs em tempo real.

adb logcat —d — exibe informações de log no momento em que o comando é executado, sem adicionar eventos reais no dispositivo. Também é possível enviar o log para um arquivo separado usando o comando: adb logcat —d > file.log (o arquivo é criado no diretório do usuário atual).

E o comando adb logcat >> file.log irá gravar o log diretamente no arquivo, adicionando todos os eventos reais no dispositivo.

Existem vários níveis em ordem crescente de prioridade: V — Verbose, D — Debug, I — Info, W — Warn, E — Error, F — Fatal, S — Silent, por exemplo:

adb logcat '*:E' — produzirá logs com erros e um nível superior.

Agora vamos nos deter brevemente na formatação e filtros de saída. Você pode alterar o formato da saída para o console usando a opção -v, por exemplo:

adb logcat -v time — emite logs sequencialmente registrando pontos de tempo.

adb logcat -v color — exibe cada nível de logs em uma cor diferente (o que é útil durante a leitura).

adb logcat -v brief — exibe a prioridade do processo, tag e PID.

Cada mensagem de log possui um tag e sua respectiva prioridade. Você pode usá-los para reduzir a quantidade de saída para o console:

adb logcat SwrveSDK:I '*:S' — exibirá os eventos analíticos que enviamos por meio do serviço swrve. O parâmetro *:S (-s) indica que a saída de log está limitada à expressão de filtro que especificamos explicitamente.

E como sempre, você pode usar o utilitário grep para filtrar a saída:

adb logcat '*:E' —v color | grep com.myApp

Tradicionalmente, para obter mais informações, você sempre pode recorrer ao seu assistente adb logcat --help

Agora vamos ver como usá-lo

Por exemplo, se um bug for reproduzido enquanto o dispositivo não estiver conectado, você pode conectá-lo imediatamente e redirecionar o log para um arquivo.

Para depuração adicional, antes de coletar logs, você pode pré-limpar o buffer de log antes de reproduzir o bug para eliminar dados supérfluos. Isso pode ser feito através do comando:

adb logcat —c , então reproduzimos o bug e executamos adb logcat —d

Para aqueles que gostam de vasculhar pilhas de logs, há outra ferramenta a considerar - ADB bugreport. Essa ferramenta permite criar arquivos zip com informações completas de depuração em formato de texto simples ( .txt ).

adb bugreport /Users/username — cria um arquivo zip no diretório especificado.

Copia todas as informações sobre o dispositivo, como dumpstate, dumpsys e dados logcat para a pasta especificada. Por padrão, os relatórios de erros são armazenados em /bugreports e podem ser visualizados por meio de:

adb shell ls /bugreports/

As informações mais importantes para nós estão armazenadas em bugreport-BUILD_ID-DATE.txt

O monitoramento de falhas e ANR (Application Not Responding) é outra ferramenta interessante para trabalhar com falhas. Execute-o usando este comando:

adb shell am monitor e, em seguida, reproduzimos nosso crash. O console exibirá informações sobre a falha sem nenhum detalhe redundante e três opções para continuar nossos esforços de monitoramento: (c)ontinue: show crash dialog, (k)ill: immediately kill app, (q)uit: finish monitoring .

emuladores

Exibindo uma lista de emuladores configurados:

emulator -list-avds

Rodando o emulador precisamos:

emulator @avdname

Ao trabalhar com emuladores, às vezes é necessário reiniciar os serviços e o servidor deve ser reinicializado assim que o emulador for iniciado, mas muitas vezes até um comando é suficiente: adb kill-server . Se isso não ajudar, execute o script inteiro:

emulator -list-avds — exibe uma lista de emuladores configurados.

adb kill-server — para o servidor.

emulator -avd avdname (ou emulator @avdname )— onde avdname é o nome do emulador.

adb start—server — reinicia o servidor.

adb devices — exibe a lista de dispositivos conectados onde nosso emulador perdido deve aparecer.

Para os mais preguiçosos, um emulador pode ser criado a partir da linha de comando. Por exemplo, o seguinte comando cria um emulador chamado "test" usando uma imagem de sistema x86 com API 25:):

avdmanager create avd —n test —k "system—images;android—25;google_apis;x86"

Se a imagem desejada não estiver disponível, você pode pré-instalá-la com o comando:

sdkmanager --install "system—images;android—25;google_apis;x86"

sdkmanager --list | grep system—images — exibe uma lista de imagens disponíveis para download

Com emuladores, às vezes também ocorrem problemas “fantasmas” durante a operação, e um comando usado com frequência que ajuda aqui é “inicializar a frio” o emulador sem abrir o instantâneo automático. O instantâneo feito na saída será o seguinte:

emulator @avdname —no—snapshot—load

Aqui estão mais algumas opções úteis a serem consideradas ao iniciar o emulador:

-no-snapshot-save — nenhum instantâneo automático será salvo

-no-snapshot — nenhum instantâneo será baixado ou salvo

Se o emulador ainda não funcionar corretamente, pode ser limpo usando a opção que retorna o emulador ao seu estado original: -wipe-data

A criação de instantâneos é um recurso muito útil para salvar os diferentes estados do dispositivo. Manualmente, isso pode ser feito nas configurações do emulador ou executando este comando:

adb emu avd snapshot save test — salva o estado do emulador onde test é o nome do snapshot a ser armazenado no dispositivo

emulator @avdname —snapshot—list — executa nosso emulador chamado @avd e exibe a lista de instantâneos no console

Em seguida, você pode carregar um instantâneo salvo anteriormente usando este comando:

adb emu avd snapshot load test — onde test é o nome de um snapshot salvo anteriormente

adb emu avd snapshot delete test — exclui o instantâneo chamado teste

Também é possível executar imediatamente o emulador com o instantâneo que precisamos:

emulator @avdname -snapshot test

Você também pode usar o comando pull para obter um instantâneo do dispositivo:

adb emu avd snapshot pull test /Users/username/

Nosso emulador pode ser operado através do console telnet . Mas primeiro você tem que instalá-lo. A maneira mais fácil de fazer isso é através do gerenciador de pacotes de brew , se você o tiver. Se não, então é hora de descobrir o que é e como usá-lo. Portanto, instale o telnet usando o comando: brew install telnet.

Em seguida, execute nosso emulador e, em outra aba do terminal, conecte-se a ele com o comando: telnet localhost port, Exemplo:

telnet localhost 5554 — conecta-se ao nosso emulador que usa a porta 5554

Depois de concluir o comando, podemos fazer todo tipo de coisas úteis com nosso emulador, incluindo trabalhar com geo (por exemplo, o comando geo fix 40.748840 -73.984279 definirá nosso local desejado nas coordenadas especificadas), a rede ou a bateria, enquanto um a lista completa de comandos, como sempre, pode ser encontrada em help.

Por exemplo, o mesmo procedimento com snapshots é um tanto simplificado, enquanto os comandos descritos na seção anterior são reduzidos a avd snapshot <command> .

Alterando a resolução no dispositivo

O gerenciador de janelas (wm) possui alguns comandos úteis para garantir que os elementos na tela do dispositivo sejam exibidos corretamente. Eles permitem ajustar a resolução da densidade de pixels para que você possa percorrer todas as opções necessárias de tamanhos de tela e ver como nosso app se adapta a eles, sem ter o número adequado de dispositivos em mãos:

adb shell wm size 1080x1920 — define a resolução de tela personalizada, com uma largura de 1080 e uma altura de 1920.

adb shell wm size reset — redefine todas as nossas configurações alteradas.

adb shell wm density X — altera a densidade de pixels, onde o valor mínimo é 72. Quanto maior o valor, maiores os elementos na tela.

adb shell wm density reset — redefine todas as nossas configurações alteradas.

Se executarmos nossos comandos sem nenhum argumento, obteremos de volta a resolução atual da tela e a densidade de pixels do dispositivo/emulador conectado.

Macaco

Separadamente, podemos citar o Monkey - uma ferramenta que gera eventos aleatórios do usuário no emulador ou dispositivo, como cliques, toques e gestos, além de vários eventos no nível do sistema que se assemelham aos movimentos de um macaco bobo. O macaco pode ser usado para testes de estresse.

adb shell monkey — exibe todos os parâmetros do Monkey.

Exemplo de cenário completo:

adb shell monkey ——throttle 100 ——pct—syskeys 0 —p com.myApp —v 10

A tecla --throttle — define o atraso entre as ações em milissegundos. Como o Macaco realiza todas as ações rapidamente, esse switch (tecla) costuma ser usado quando queremos controlar visualmente o que está acontecendo na tela.

A tecla --pct-syskeys — define a porcentagem de botões do sistema que serão pressionados durante um cenário. Neste exemplo, é definido como 0, o que implica que nenhum botão do sistema será pressionado.

A opção -p — o nome do pacote que está sendo transmitido

A opção -v — o número de ações a serem executadas

Permissões do aplicativo

Normalmente, as operações envolvidas aqui implicam na revogação de permissões do app, porque as permissões geralmente são concedidas por meio de uma solicitação do app - algo que pode ser feito de maneira rápida e fácil - enquanto a revogação de permissões é feita por meio de configurações do sistema.

adb shell dumpsys package com.MyApp | grep permission — exibe uma lista de permissões de aplicativos disponíveis, por exemplo, permissões de install permissions obrigatórias que são concedidas ao instalar o aplicativo, permissões de tempo de runtime permissions — permissões solicitadas em um momento específico, por exemplo, ao acessar o armazenamento de arquivos. Observe que, se uma permissão estiver faltando na lista de permissões solicitadas, você não poderá conceder acesso a ela.

Portanto, o seguinte comando deve ser executado para revogar a permissão do nosso aplicativo:

adb shell pm revoke packageName permissionName , exemplo:

adb shell pm revoke com.MyApp android.permission.CAMERA — revoga o acesso de com.myApp à câmera. Assim que retornarmos ao aplicativo e tentarmos usar a câmera por meio dele, veremos um novo pedido de permissão.

O comando grant dá permissão ao aplicativo, por exemplo:

adb shell pm grant com.myApp android.permission.CAMERA — concede acesso à câmera do telefone para nosso aplicativo.

a bateria

Vamos dar uma breve olhada aqui na bateria e no modo de espera.

adb shell dumpsys battery — exibe informações sobre a bateria.

adb shell dumpsys battery set level X — define o nível de carga da bateria, onde X é a porcentagem de carga.

adb shell dumpsys battery unplug — simula uma bateria desconectada.

adb shell dumpsys battery reset — redefine todas as nossas configurações alteradas.

Agora vamos ver os modos de espera. A partir do Android 6, existe a função conhecida como Doze Mode, para economizar bateria e prolongar a vida útil da bateria, limitando a atividade do aplicativo após o usuário não interagir com o dispositivo por algum tempo e quando o dispositivo não estiver carregando.

O sistema sai periodicamente do modo Soneca para concluir tarefas pendentes em segundo plano. App Standby é outro recurso similar do Android. Ao contrário do modo Doze, ele rastreia o estado de um aplicativo específico que ficou ocioso por um determinado período de tempo e, em seguida, ativa o modo de espera. Nosso trabalho é garantir que o aplicativo se recupere normalmente após sair desses dois modos de economia de energia, que não trave, que as notificações continuem chegando, etc.

Para alternar o dispositivo para o modo Doze, execute os seguintes comandos:

adb shell dumpsys battery unplug — desconecta a bateria .

adb shell dumpsys deviceidle step — o comando pode ter que ser executado várias vezes até que seja exibido: Stepped to deep: IDLE .

Depois de todas as rotinas que fizemos com a bateria, o melhor é executar o comando:

adb shell dumpsys battery reset — que retorna ao seu estado original.

Este comando também pode ser usado para forçar o dispositivo no modo Doze:

adb shell dumpsys deviceidle force—idle — às vezes, antes disso, você deve executar o comando: adb shell dumpsys deviceidle enable.

Você pode reativá-lo no modo Doze com o comando:

adb shell dumpsys deviceidle unforce - e não se esqueça de redefinir o status da bateria:

adb shell dumpsys battery reset .

Agora um pouco sobre App Standby. Para implantar o aplicativo neste modo, os seguintes comandos precisam ser executados:

adb shell dumpsys battery unplug — desconecta a bateria como no caso anterior.

adb shell am set—inactive com.myApp true — implementa o aplicativo no modo App Standby.

Em seguida, tire nosso aplicativo do modo App Standby usando este comando:

adb shell am set—inactive com.myApp false .

Você pode verificar o status do aplicativo executando este comando:

adb shell am get—inactive com.myApp

Mais alguns comandos úteis a serem considerados

adb reboot — reinicia o dispositivo (relevante também para o dispositivo real).

adb shell dumpsys package com.myApp — exibe informações completas sobre um aplicativo específico.

adb shell dumpsys meminfo com.myApp — para verificar o uso de memória do aplicativo no dispositivo, desde o espaço ocupado até a exibição dos bancos de dados usados por este aplicativo, bem como o caminho até eles.

adb shell getprop — mostra uma lista de propriedades de dispositivo disponíveis (fabricante, modelo de dispositivo, especificações de hardware, etc.)

Exiba a lista de atividades acessíveis para o aplicativo:

adb shell dumpsys package com.myApp | grep —i Activity .

Exiba o nome da atividade em execução:

adb shell dumpsys window | grep Focused .

Execute a atividade de aplicativo selecionada:

adb shell am start —n com.myApp/.ActivityClass — desta forma você pode executar qualquer aplicativo instalado, incluindo aplicativos do sistema. Exemplo: adb shell am start -n com.android.settings/.Settings exibe as configurações do telefone.

Faça uma chamada para o número de telefone especificado:

adb shell am start —a android.intent.action.CALL tel:+790900000XX .

Abra uma página em seu navegador da Web:

adb shell am start —a android.intent.action.VIEW 'https://indriver.com'

Pensamentos finais

Gostaria de salientar que é impossível reunir todos os recursos do Android Debug Bridge em um artigo ou realizar um estudo completo sobre eles. As mudanças ocorrem constantemente: o que funciona hoje pode parar de funcionar amanhã de repente, e a necessidade de conhecimento de certas ferramentas surgirá à medida que buscamos soluções para questões específicas. Mas posso dizer com confiança que o material que cobrimos hoje é suficiente para você começar e continuar por um tempo.

Boa sorte em seus empreendimentos e espero que goste de mergulhar no excitante mundo dos testes de software!