Se o seu aplicativo está "em revisão" na Google Play há muito tempo, na maioria dos casos não é culpa do seu build. A revisão fica em uma fila do lado do Google, e o tempo varia conforme a conta e o tipo de mudança. A maioria das atualizações sai em algumas horas a poucos dias, e o Google diz oficialmente que a revisão pode levar "sete dias ou mais em casos excepcionais". Se passou de sete dias sem mudança, pare de reenviar e comece a diagnosticar, porque enviar uma nova versão reinicia a revisão do zero.
Resposta rápida
"Em revisão" significa que o Google está avaliando o app antes de publicar, de forma automática e às vezes manual. O normal é de algumas horas a poucos dias; o Google indica que a revisão pode levar "sete dias ou mais em casos excepcionais", segundo a ajuda da Google Play sobre tempos de revisão. Contas novas ou sinalizadas passam por uma revisão mais cuidadosa. Reenviar não acelera e reinicia o processo. Verifique a publicação gerenciada e a Central de Políticas, e fale com o suporte se passar desse prazo sem mudança.
O que significa "em revisão" na Google Play?
"Em revisão" quer dizer que o seu envio está sendo avaliado e ainda não foi publicado. As atualizações passam pela publicação padrão, em que o Google processa as mudanças "o mais rápido possível", mas cada envio passa por verificações automáticas e, quando algo exige, por uma revisão manual que leva mais tempo. Enquanto isso, a versão anterior continua disponível para os usuários, então um travamento não tira seu app da loja.
Vale distinguir duas situações que se confundem. Uma coisa é a revisão demorar por causa da fila ou de um exame mais cuidadoso; outra bem diferente é o app estar retido por uma possível violação de política, que aparece na Central de Políticas do console. A segunda não se resolve esperando: exige ler o aviso e corrigir exatamente o que foi apontado. Tratar uma retenção por política como se fosse só uma demora é um dos motivos mais comuns de ficar semanas sem avançar.
Quanto tempo é normal e quando é demais?
O normal é de algumas horas a poucos dias, com sete dias como referência máxima para casos excepcionais. Qualquer número exato é uma média observada, não uma garantia do Google. Duas semanas está claramente acima do esperado e justifica investigar as causas e falar com o suporte. A tabela abaixo organiza os intervalos e os sinais de alerta.
| Estado ou situação | Tempo normal | Sinal de alerta |
|---|---|---|
| Atualização pela publicação padrão | Horas a 3 dias | Mais de 7 dias sem mudança |
| Primeira publicação de um app | 1 a 7 dias | Mais de 7 dias |
| Conta nova ou sinalizada | Até 7 dias ou mais | Claramente acima de 7 dias |
| Retenção por política | Até corrigir o aviso | Aviso não lido na Central de Políticas |
| Duas semanas sem avançar | Não é normal | Fale com o suporte de imediato |
Em períodos de grande volume, uma espera longa nem sempre indica problema no app. Mas passando de sete dias, e ainda mais às duas semanas, não basta esperar: é hora de descartar ativamente um bloqueio por política, um requisito de conta pendente ou a publicação gerenciada. Cada um desses casos tem uma ação concreta, e nenhum se resolve subindo outra versão.
Por que o aplicativo fica preso?
A maioria dos travamentos vem da conta, de uma política ou de uma configuração, não da qualidade do código. As causas mais comuns são uma conta nova ou sinalizada para revisão mais rígida, permissões sensíveis como localização ou acesso a dados do usuário, mudanças na declaração de segurança de dados ou na classificação indicativa e, principalmente, uma retenção por política que espera uma correção sua.
Há dois casos que pegam muita gente. O primeiro é a publicação gerenciada ativada, que faz o Google aprovar o app mas não publicar até você liberar manualmente. O segundo afeta contas pessoais novas: antes de publicar em produção, o Google exige um teste fechado com pelo menos 12 testadores por 14 dias seguidos, segundo os requisitos do Google para contas novas. Esses 14 dias precisam ser contínuos. Essa espera não é uma revisão, mas costuma ser confundida com uma, e explica muitos casos em que alguém acha que está preso na revisão quando, na verdade, a conta ainda não tem acesso à produção.
Devo esperar, cancelar ou reenviar?
A resposta curta é: não reenvie, e só cancele se for corrigir algo. Enviar um novo build da mesma versão substitui o que está em revisão e reinicia o processo do zero, então você perde o progresso e o lugar na fila. Reenviar só faz sentido se você realmente corrigiu um problema que causaria uma recusa ou uma violação de política.
Esperar é o certo dentro do intervalo normal, mas às duas semanas não é mais. Nesse ponto, a ação útil não é reenviar nem cancelar sem motivo, e sim diagnosticar: verificar a Central de Políticas, conferir a publicação gerenciada e, se nada explicar o travamento, falar com o suporte com provas. Pense em cancelar apenas como passo antes de subir uma correção real, nunca como uma forma de "reiniciar a sorte".
Passos para destravar
Antes de reenviar, siga uma ordem de diagnóstico que descarta as causas mais comuns. A tabela abaixo resume os passos na ordem que convém seguir.
| Passo | Ação |
|---|---|
| 1. Verificar a Central de Políticas | Procure avisos ou violações que estejam retendo o app |
| 2. Conferir a publicação gerenciada | Se estiver ativa, publique você mesmo a versão aprovada |
| 3. Checar os requisitos de conta | Confirme se cumpriu o teste fechado se a conta for nova |
| 4. Revisar a segurança de dados | Garanta que o formulário esteja completo e coerente |
| 5. Não reenviar sem motivo | Evite subir versões novas que reiniciem a revisão |
| 6. Falar com o suporte | Após 7 dias, ou às 2 semanas, abra um caso com datas e prints |
Faça os passos em ordem e anote o que encontrar. Muitos travamentos que parecem falha do Google acabam sendo um aviso de política não lido, um formulário de segurança de dados incompleto ou a publicação gerenciada esperando o seu clique. Descartar essas causas primeiro evita escalar por algo que você mesmo resolve em minutos.
Quando falar com o suporte da Google Play?
Fale com o suporte quando passar claramente dos sete dias sem mudança, e sem dúvida às duas semanas. Use a ajuda do Google Play Console para abrir um caso e inclua o nome do pacote, o número da versão, a data e a hora do envio e prints do estado e de qualquer aviso da Central de Políticas. Quanto mais completo o caso, menor a chance de ele atrasar por falta de informação.
Tenha expectativas realistas. O suporte pode confirmar o estado e encaminhar o caso, mas nem sempre responde rápido, e não acelera uma revisão que segue o seu curso. Ainda assim, às duas semanas é o passo certo, porque um silêncio tão longo não se resolve sozinho e vale registrar por escrito, caso o caso se estenda.
Antes de enviar, verifique o build
A forma mais segura de não repetir a espera é não gastar um ciclo de revisão com um app que seria recusado. Cada recusa ou violação te manda de volta ao início, então um problema evitável, como uma chave secreta embutida, uma permissão sem justificativa ou uma configuração de rede insegura, pode custar outra espera inteira justo quando você já esperou demais.
Um scanner de segurança como o PTKD.com analisa o .aab ou o .apk antes do envio e devolve um relatório ordenado por gravidade e mapeado para o OWASP MASVS, para você corrigir o que dispararia uma recusa antes de entrar na fila. É preciso ser honesto sobre o limite: um scanner não acelera a revisão do Google nem substitui uma auditoria manual em apps de alto risco ou regulados. O que ele faz é evitar as recusas previsíveis que obrigam a repetir a espera, que é justamente o que você quer depois de ficar preso por dias.
Pontos principais
- Algumas horas a poucos dias é o normal; sete dias é a referência máxima, e duas semanas não é normal.
- Distinga uma fila lenta de uma retenção por política; a segunda só se resolve lendo o aviso e corrigindo.
- Não reenvie por impaciência, porque reinicia a revisão; verifique antes a publicação gerenciada e os requisitos de conta.
- Fale com o suporte após sete dias ou às duas semanas, com nome do pacote, datas e prints.
- Antes de enviar, verifique o build com o PTKD.com para não repetir a espera por uma recusa evitável.
