Testar um app Android online

Testar um app Android online significa que o celular está em outro lugar. Você o acessa pela rede, instala o seu build, acompanha a tela no navegador e puxa os logs com adb como se houvesse um cabo ligado. Bem feito, isso substitui quase tudo o que uma gaveta de celulares de teste oferece. Mal feito, é um emulador lento com passos a mais.

Este guia leva um build do APK aos logs de crash em três versões do Android. Ele usa os comandos que eu rodo toda semana, lista os erros de instalação que você vai encontrar e termina com os pontos em que um celular físico ainda é a ferramenta melhor.

Prepare o build

Comece por um build que dá para instalar pela linha de comando. Um build de debug serve para uma primeira rodada:

./gradlew assembleDebug
ls app/build/outputs/apk/debug/

Duas verificações poupam tempo depois. A primeira é a ABI. Se o seu app traz código nativo, garanta que o APK contenha bibliotecas arm64-v8a. Celulares feitos a partir de modelos reais são arm64 e, ao contrário das imagens de emulador x86 do seu notebook, não traduzem código compilado para outra arquitetura.

unzip -l app/build/outputs/apk/debug/app-debug.apk | grep "lib/"

A segunda é a flag testOnly. Quando você aperta Run no Android Studio, a IDE marca o APK com android:testOnly="true", e um adb install comum o recusa. Os builds do assembleDebug não levam essa flag. Se tudo o que você tem é um build da IDE, instale com adb install -t.

Se o artefato de release é um app bundle, transforme-o num conjunto de APKs para o celular conectado com o bundletool:

bundletool build-apks --bundle=app-release.aab --output=app.apks --connected-device
bundletool install-apks --apks=app.apks

Sem --ks, o bundletool assina com a chave de debug. Isso serve para testes, mas o resultado não instala por cima de uma cópia assinada com a sua chave de release.

Escolha três versões do Android, não uma

Um único celular esconde a maioria dos bugs de compatibilidade, porque o Android muda de comportamento de duas formas. Algumas mudanças atingem todos os apps na versão nova. Outras só entram em vigor quando você sobe o targetSdkVersion. Três versões pegam a maior parte das duas:

• A versão mais antiga que você ainda suporta, ou a mais próxima disponível. O Android 12 é um piso sensato para a maioria dos apps em 2026.
• A versão com a maior fatia no seu próprio analytics, muitas vezes a 14 ou a 15.
• A versão mais nova, 16 ou 17, em que mudanças atreladas ao target, como o edge-to-edge obrigatório e o gesto de voltar preditivo, aparecem primeiro.

A lista completa do que muda entre cada par de versões é longa. Testar um app em diferentes versões do Android traz o checklist versão por versão.

Passo 1: crie os celulares

Num serviço de celular na nuvem, você escolhe uma versão do Android e um modelo, e o celular fica pronto em cerca de um minuto. Dê a cada um o nome da versão, por exemplo qa-12, qa-14 e qa-16, para que logs e capturas de tela continuem legíveis uma semana depois. Se você automatiza isso a partir do CI, o seu primeiro aparelho mostra os mesmos passos pela API.

Escolha modelos que os seus usuários realmente têm. Um celular de entrada com tela 720p e um topo de linha com 1440p quebram layouts diferentes, então misturar densidades de tela entre as três versões rende mais cobertura no mesmo tempo.

Passo 2: instale o build

Há três formas de colocar o APK no celular: enviar pelo painel no navegador, mandar pela API REST ou rodar adb install pelo relay ADB. O guia de apps cobre as duas primeiras. Para o adb, ative o relay para o seu endereço IP como descrito na documentação de ADB e conecte:

adb connect HOST:PORT
adb -s HOST:PORT install -r app-debug.apk

As falhas de instalação quase sempre são uma de cinco, e a mensagem de erro diz qual:

Passo 3: faça um teste rápido que dá para repetir

Faça a mesma rodada do mesmo jeito em todas as versões, para que as diferenças que você vê sejam diferenças do Android e não da forma como você tocou na tela. A minha cobre seis coisas:

1. Inicialização a frio. am start -W imprime TotalTime em milissegundos. Compare entre versões, não com um topo de linha físico.
2. Primeira execução. Instale sem -g, para que cada pedido de permissão em tempo de execução apareça como um usuário novo vê.
3. Segundo plano e volta. Aperte Home, abra outros dois apps, volte.
4. Morte do processo. Com o app em segundo plano, am kill encerra o processo como o sistema faz sob pressão de memória. Ao voltar, o app precisa restaurar a tela e o estado dela.
5. Configuração. Modo escuro, uma fonte maior, outro tamanho de exibição.
6. Navegação de voltar. Gesto de voltar a partir de cada tela de nível superior.

Os comandos, com S guardando o endereço do aparelho:

S=HOST:PORT
adb -s $S shell am force-stop com.example.app
adb -s $S shell am start -W -n com.example.app/.MainActivity
adb -s $S shell input keyevent KEYCODE_HOME
adb -s $S shell am kill com.example.app
adb -s $S shell cmd uimode night yes
adb -s $S shell settings put system font_scale 1.3
adb -s $S shell wm density 560
adb -s $S shell wm density reset

Desfaça a escala da fonte com settings put system font_scale 1.0 e o modo escuro com cmd uimode night no antes da próxima rodada, ou redefina o celular.

Passo 4: leia os logs

Limpe o buffer antes de cada cenário e depois leia só o seu próprio processo:

adb -s $S logcat -c
adb -s $S shell am start -W -n com.example.app/.MainActivity
adb -s $S logcat -d --pid=$(adb -s $S shell pidof -s com.example.app)

O pid muda toda vez que o processo reinicia, então um crash durante a inicialização não aparece sob o pid novo. Leia o buffer de crash em vez disso. Ele guarda os crashes Java e nativos de todos os processos:

adb -s $S logcat -d -b crash
adb -s $S logcat -d AndroidRuntime:E "*:S"

Para um ANR, o logcat só dá a manchete. adb bugreport report.zip reúne os stack traces das threads daquele momento junto com o estado do sistema. Leva um ou dois minutos, e é esse o arquivo a anexar ao ticket.

Mantenha os três logs lado a lado. Um aviso que só aparece na versão mais nova costuma ser uma mudança atrelada ao target. Um crash nas três é o seu código.

Passo 5: redefina entre execuções

pm clear apaga os dados do seu app e deixa todo o resto no lugar: outros apps, configurações que você mudou, a conta Google. Para uma comparação limpa entre suítes, volte o celular a um estado limpo e guarde o pm clear para repetições rápidas dentro de uma mesma suíte.

Quando a rodada ficar estável, o lugar dela é o CI. A página de testes de apps mostra os mesmos passos como chamadas de API. Os testes instrumentados são comandos adb comuns, então rodam em qualquer aparelho que o adb alcance:

adb -s $S shell am instrument -w -e class com.example.LoginTest \
  com.example.app.test/androidx.test.runner.AndroidJUnitRunner

Onde um teste online para

Seja honesto sobre o que um celular num data center não consegue dizer:

• Qualidade da câmera, foco automático, a deriva real do GPS e sensores biométricos.
• Desempenho gráfico. O Android virtualizado renderiza por drivers traduzidos ou por software, então tempos de quadro e engasgos não se transferem para um celular físico.
• Consumo de bateria e throttling térmico.
• Software do fabricante. Otimizadores de bateria e configurações de inicialização automática de algumas marcas param o trabalho em segundo plano de formas que o Android puro não para.
• Rádios: pagamentos por NFC, pareamento Bluetooth, recursos da operadora.

Guarde dois ou três celulares físicos para essas verificações e rode a matriz ampla online.

Formas grátis de começar

"Teste em aparelho real online grátis" costuma significar uma de três coisas. O Android Emulator na sua própria máquina não custa nada e é o lugar certo para o ciclo de editar e rodar. Nuvens públicas de aparelhos oferecem pequenas cotas grátis de celulares físicos, sobretudo para execuções automatizadas. Os serviços de celular na nuvem costumam oferecer um teste: o Clousd dá os primeiros 30 minutos grátis, sem cartão, o suficiente para instalar um build e fazer uma primeira rodada; veja o teste grátis.