Neste guia
O relatório de pré-lançamento é uma execução de teste automatizada que o Google Play faz na sua build antes de você lançá-la. Ele roda sem configuração extra da sua parte, então vale a pena lê-lo sempre. Também é fácil lê-lo demais: é um robô, não um usuário.
O que ele faz
Segundo a Central de Ajuda do Play Console do Google, o relatório procura problemas de estabilidade, compatibilidade com Android, desempenho e acessibilidade. Ele roda quando você envia um app bundle ou APK e quando salva uma versão para produção. O app é aberto em aparelhos do laboratório de testes do Google. Depois, um rastreador toca, digita e desliza por vários minutos. Em seguida, os resultados são compilados.
Detalhes da mesma página que influenciam a leitura:
- Os resultados costumam chegar em até uma hora após o envio. Se o relatório não estiver completo após dois dias, envie a build de novo.
- Os aparelhos de teste rodam Android 9 ou superior e incluem celulares, tablets, Wear OS e aparelhos de classe desktop. Android Automotive OS e Android TV não podem ser testados.
- Os aparelhos estão nos Estados Unidos e rodam em retrato por padrão.
- Você pode adicionar até três deep links como pontos de entrada extras, credenciais de conta de teste, um script Robo ou um game loop, e escolher até cinco idiomas.
- Apps sem uma activity principal de inicialização não podem ser testados (o Google cita launchers, widgets, teclados e watch faces).
O escopo muda com o tempo. Abra a página atual antes de confiar em qualquer coisa disso.
O que ele não consegue ver
O rastreador não conhece o seu produto. Ele não consegue julgar se o onboarding faz sentido, se um preço está claro ou se o texto é bom de ler. Ele pode não passar de um login sem credenciais. Qualquer coisa atrás de um pagamento, um estado raro ou uma ação do mundo real (uma entrega, um dispositivo Bluetooth) está fora do alcance dele.
Como fazer a triagem dos achados
O resumo do relatório agrupa os problemas em erros, avisos e problemas menores, e dá uma recomendação de lançamento. Use como ponto de partida, não como veredito.
| Achado | O que fazer |
|---|---|
| Travamento com stack trace no seu código | Reproduza manualmente. Se der, corrija antes do lançamento. |
| Travamento em biblioteca de terceiros | Verifique se afeta um fluxo real; atualize a biblioteca se possível. |
| Travamento só depois de o rastreador fazer algo não natural | Prioridade menor, mas verifique se o app lida com entradas estranhas sem perda de dados. |
| Aviso de acessibilidade (área de toque, contraste, rótulo ausente) | Geralmente barato de corrigir e valioso. Verifique no seu próprio aparelho. |
| Aviso de desempenho | Compare com um celular intermediário real antes de agir. |
| Barreira de login, nada testado | Adicione credenciais de teste e rode de novo. |
Uma regra simples: corrija o que você consegue reproduzir, anote o que não consegue, e não ignore nada sem um motivo escrito.
Use junto com testadores reais
O relatório encontra travamentos e defeitos óbvios em um conjunto fixo de aparelhos, com rapidez. Pessoas encontram fluxos confusos, textos errados e problemas nos próprios celulares. Use os dois. Para o lado dos dados de campo, veja noções básicas do Android vitals; para a comparação, veja testes em dispositivos na nuvem vs. testadores reais.
Parte do guia de teste de app Android.
Precisa de pessoas reais para testar sua build? Comece aqui e receba feedback privado e estruturado.