Resposta rápida
Com base no Relatório Anual de Transparência de 2025 do Google, a proporção de rejeição dos envios no Google Play é de cerca de 7,89%: 1.692.467 envios rejeitados divididos por 21.461.250 analisados. Esse é um cálculo feito sobre as contagens publicadas pelo Google, não uma taxa referente ao ano inteiro de 2026 nem a probabilidade de um app novo ser reprovado na primeira tentativa. Os números de aplicação de políticas que o Google divulga à parte medem resultados diferentes.
Fonte: Relatório Anual de Transparência do Google Play de 2025 (PDF), publicado em 31 de março de 2026, com abrangência global. O relatório de 2024 resulta em 10,13% na mesma base.
Este guia explica os números recentes de envios e de aplicação de políticas do Google, seus limites e as verificações práticas que ajudam você a responder a uma rejeição. Os dados do relatório anual de transparência, os balanços anuais de segurança e todas as páginas de política citadas ao longo do texto foram consultados em 12 de setembro de 2026.
Como ler as etiquetas deste guia
- Relatório do GoogleUm número publicado em um relatório de transparência do Google ou em um balanço anual de segurança, com a fonte citada ao lado.
- CálculoUma conta que este guia faz com as contagens publicadas pelo Google. O próprio Google não divulga o resultado.
- Política do GoogleUm requisito ou processo descrito na Ajuda do Play Console ou nas Políticas do Programa para Desenvolvedores.
- Verificação práticaUm teste que recomendamos com base nos envios que acompanhamos. Não é uma regra do Google nem uma frequência de rejeição medida.
- ExemploUma ilustração criada para mostrar o formato de um registro. Não é um caso de cliente nem uma estatística da plataforma.
Nesta página
Qual é a taxa de rejeição de apps no Google Play em 2026?
O Google não publica nenhuma porcentagem com o nome de “taxa de rejeição”. O que ele publica, uma vez por ano, são as duas contagens necessárias para calcular uma: quantos envios de apps foram analisados e quantos foram rejeitados. O último ano completo é 2025, divulgado em 31 de março de 2026, então um guia de 2026 trabalha com a atividade de 2025.
Os dados anuais de envios mais recentes
Relatório do Google| Ano de atividade | Envios analisados | Envios rejeitados | Rejeitados ÷ analisados | Publicação do relatório |
|---|---|---|---|---|
| 2024 | 19.292.647 | 1.955.305 | 10,13% | 31 de março de 2025 · relatório |
| 2025 | 21.461.250 | 1.692.467 | 7,89% | 31 de março de 2026 · relatório |
Onde encontrar: relatório de 2025, página impressa 3; relatório de 2024, páginas impressas 3 e 4. As porcentagens são calculadas a partir das contagens publicadas (rejeitados ÷ analisados × 100) e arredondadas para duas casas decimais. Os dois relatórios descrevem sua abrangência como global. Dados consultados em 12 de setembro de 2026.
Veja o cálculo por ano
Parcela rejeitada do total de envios analisados
Cerca de 8 em cada 100 envios analisados foram rejeitados em 2025.
Como a proporção é calculada e o que ela não consegue prever
A proporção compara as contagens anuais globais de envios de apps analisados e rejeitados que o Google divulga. Os relatórios não trazem um grupo definido de primeiras tentativas nem um detalhamento por tentativa de envio, então esse agregado não deve ser usado para prever o resultado de um app novo específico.
O que a proporção não comprova
- As chances do seu app. O complemento (cerca de 92%) não é a probabilidade de aprovação de um app novo na primeira tentativa.
- Um número de 2026. Os dados do ano completo de 2026 ainda não estão disponíveis. Trate o número como dados de 2025 disponíveis em 2026.
- Uma taxa de aprovação posterior. O relatório de 2025 também lista aprovações depois de uma rejeição, mas não a contabilidade por grupo necessária para uma taxa de aprovação após correção, então este guia não calcula nenhuma.
- Uma taxa de aprovação do teste fechado ou do acesso de produção. As decisões de acesso para novas contas pessoais são um processo diferente e não aparecem nessas tabelas.
- Uma tendência de rigor. A queda de 10,13% para 7,89% é uma mudança na proporção, não uma prova de que a política ficou mais branda, de que a qualidade da análise mudou ou de que o risco de um desenvolvedor específico diminuiu.
Por que outros sites citam números diferentes
Algumas páginas dizem que o Google não publica nenhum denominador; isso valia para a série dos balanços de segurança, não para os relatórios de transparência. Outras dividem uma contagem de “apps impedidos” do balanço de segurança por um denominador do relatório de transparência, o que mistura duas séries.
As estatísticas de rejeição e de aplicação de políticas do Google
O Google divulga a segurança da plataforma em dois lugares fáceis de confundir: o Relatório Anual de Transparência, uma tabela com contagens de envios e de medidas de aplicação, e o balanço anual de segurança nos blogs do Google, um texto narrativo com números de destaque arredondados.
Envios analisados e rejeitados
Relatório do GoogleAlém das contagens de envios analisados e rejeitados na tabela acima, o relatório de transparência de 2025 lista 2.012.981 remoções e 125.550 contas de desenvolvedor encerradas. Uma remoção atinge um app que já estava disponível; uma rejeição é uma decisão sobre um envio antes de ele entrar no ar.
Fonte: Relatório Anual de Transparência de 2025, página impressa 3.
Apps impedidos de serem publicados, de 2023 a 2025
Relatório do Google| Ano de atividade | Apps que violavam políticas impedidos de publicação | Contas de desenvolvedor nocivas banidas | Fonte |
|---|---|---|---|
| 2023 | 2,28 milhões | 333.000 | balanço de segurança de 2023 (29 de abril de 2024) |
| 2024 | 2,36 milhões | Mais de 158.000 | balanço de segurança de 2024 (29 de janeiro de 2025) |
| 2025 | Mais de 1,75 milhão | Mais de 80.000 | balanço de segurança de 2025 (19 de fevereiro de 2026) |
Os mesmos balanços trazem um contexto que não é uma contagem de rejeições. Em 2023, quase 200.000 envios foram rejeitados ou corrigidos por causa de permissões sensíveis, como localização em segundo plano e SMS. Em 2024, 1,3 milhão de apps foram impedidos de obter acesso desnecessário ou excessivo a dados sensíveis dos usuários; em 2025 esse número foi de mais de 255.000, além de 160 milhões de avaliações e comentários de spam bloqueados. Essas medidas não se somam entre si nem com as da tabela.
O Google também descreve a execução de mais de 10.000 verificações de segurança em apps antes e depois do lançamento. Esse número não significa que todo defeito pequeno vire uma rejeição automática, nem que todas essas verificações funcionem como barreiras anteriores à publicação.
Por que as contagens de rejeição, remoção e prevenção são diferentes
| Fonte | Métrica | Unidade | Período | O que ela não abrange |
|---|---|---|---|---|
| Relatório Anual de Transparência | Envios rejeitados | Envios, e não um conjunto declarado de apps únicos | Ano civil | Se o mesmo app foi aprovado depois |
| Relatório Anual de Transparência | Remoções | Apps removidos depois de publicados | Ano civil | Envios que nunca entraram no ar |
| Balanço anual de segurança | Apps impedidos de serem publicados | Apps, número arredondado | Ano civil | Um denominador; não dá para transformar em taxa |
| Balanço anual de segurança | Contas de desenvolvedor banidas | Contas | Ano civil | Rejeições de apps individuais |
O relatório anual de transparência e o balanço anual de segurança do Google usam nomes de métricas diferentes e informam totais diferentes. Mantenha cada número ligado à sua fonte e à sua definição. Os relatórios consultados não explicam nenhuma conversão direta entre as duas séries, então elas não devem ser combinadas para calcular uma única taxa de rejeição.
Um agregado da plataforma e o resultado medido por um fornecedor podem ser verdadeiros ao mesmo tempo. A taxa de conclusão dos testes gerenciados da PrimeTestLab descreve os testes fechados que ela conduz e mantém com testadores até a data final; a proporção do Google descreve as contagens de envios de apps divulgadas. Nenhuma das duas prevê a outra.
Que tipo de decisão do Google Play você recebeu?
Antes de corrigir qualquer coisa, identifique qual decisão você tem em mãos. A palavra “rejeitado” é usada de forma solta para pelo menos cinco situações, e o próximo passo é diferente em cada uma. O status no Play Console e o e-mail enviado ao titular da conta dizem qual é.
Política do GoogleToque no aviso que você recebeu
| Decisão ou bloqueio | Sua situação | Próximo passo |
|---|---|---|
| App ou atualização rejeitada | As mudanças enviadas não foram aceitas. Na rejeição comum de uma atualização, a versão publicada anteriormente continua disponível enquanto você faz a correção. | Leia o aviso, corrija o envio afetado e envie de novo. Veja depois de uma rejeição. |
| Acesso de produção recusado, ou “More testing required” | Sua solicitação para levar à produção o app de uma conta pessoal nova precisa de mais trabalho; é uma decisão sobre a prontidão do teste fechado. | Siga os passos de teste e prontidão e depois veja como corrigir uma recusa de acesso de produção por causa do teste. |
| App removido | A ficha da loja não está mais disponível. O app já tinha sido publicado, e a aplicação das políticas agiu depois disso. | Siga o aviso de aplicação das políticas e envie uma atualização em conformidade pelo caminho que ele indicar. |
| App suspenso, ou conta encerrada | Uma medida mais severa, no nível do app ou no nível da conta, cada uma com seu próprio aviso e suas consequências. | Use o processo de contestação indicado no aviso. Não abra outra conta para republicar; isso é tratado como violação. |
| Bloqueio de upload ou de compatibilidade | O envio não pode seguir do jeito que foi preparado: por exemplo, um nível de API de destino abaixo do mínimo atual ou um bundle que o Console não aceita. | Resolva o requisito técnico indicado e envie de novo. Ainda não houve nenhuma análise. |
Significado dos status: Ajuda do Play Console, Publicar o app e Processo de aplicação das políticas.
O que um status não diz
Um app indisponível não foi necessariamente rejeitado por política: ele pode ter sido despublicado por você ou barrado por uma regra de compatibilidade. E uma recusa de acesso de produção pode ter mais de uma causa, então a linha acima é um caminho, não um diagnóstico. Uma versão publicada em uma faixa fechada também pode passar por análise de política; a solicitação de acesso de produção é a decisão separada sobre a prontidão do teste.
Riscos de rejeição documentados e correções práticas
O Google não publica uma lista de motivos de rejeição ordenada por frequência, e este guia não inventa uma. As oito verificações abaixo estão na ordem em que dá para executá-las, do build para fora, cada uma com a política que a sustenta. Os itens de teste fechado ficam na seção sobre testes: eles são condições de elegibilidade para contas pessoais novas, não rejeições por política.
Estabilidade e funcionalidade útil
Falhas, travamentos e instalações que não funcionam
- O problema
- A política de funcionalidade do Google proíbe apps que apresentam falhas, fecham sozinhos, travam ou funcionam de forma anormal de qualquer outro jeito, inclusive apps que não instalam, que instalam mas não abrem, ou que abrem mas não respondem.
- Um teste observável
- Instale do zero exatamente a versão candidata em dois dispositivos físicos: abra, faça login, complete o fluxo principal, mande para segundo plano e volte. Depois leia o relatório de pré-lançamento em busca de falhas e de ANRs (aplicativo não responde).
- A correção
- Corrija as falhas de inicialização e os ANRs antes de enviar e repita o mesmo fluxo no binário recompilado.
Conteúdo estático sem funcionalidade própria de app
- O problema
- A mesma política trata de funcionalidade ou conteúdo limitados: conteúdo estático sem utilidade própria de um app, conteúdo muito escasso ou um app feito para não fazer nada. O formato sozinho não determina a conformidade; o app continua precisando de utilidade e conteúdo adequados.
- Um teste observável
- Demonstre a função principal do app e explique o resultado útil que ele entrega. Verifique se ele tem conteúdo adequado e funcionalidade relevante, em vez de apenas exibir material estático.
- A correção
- Acrescente a funcionalidade ou o conteúdo que dê ao app utilidade adequada para o uso a que ele se propõe.
Acesso do analista
O analista não consegue chegar à funcionalidade restrita ou principal
- O problema
- O Google pede credenciais de acesso que funcionem e instruções para qualquer recurso que esteja atrás de um login, de uma restrição por região ou de uma autenticação fora do comum. Sem isso, o analista bate em uma parede, e um app que não pode ser analisado não é aprovado.
- Um teste observável
- Instale a versão que você vai enviar em um dispositivo sem histórico e use apenas as credenciais e as instruções que estão na página Conteúdo do app. Se você precisou de mais alguma coisa para entrar, o analista também vai precisar.
- A correção
- Forneça uma conta de análise dedicada que não expire e instruções passo a passo para cada recurso bloqueado. Nem todo app precisa de login; e uma conta que funciona é uma condição prévia para a análise, não uma garantia de aprovação.
Permissões, privacidade e Segurança dos dados
Escopo das permissões e declarações
- O problema
- Permissões sensíveis, como localização em segundo plano e SMS, precisam de um caso de uso que o app entregue de forma visível e, onde existe um formulário de declaração, ele precisa corresponder ao que o app faz. O balanço de segurança do Google referente a 2023 informou quase 200.000 envios rejeitados ou corrigidos exatamente por causa disso.
- Um teste observável
- Liste no manifesto todas as permissões perigosas e, para cada uma, aponte a tela em que o usuário vê por que ela é necessária.
- A correção
- Remova tudo que não tiver um caso de uso visível e faça com que as declarações no Console descrevam o comportamento que o analista vai observar. Um motivo ligado a um recurso não basta sozinho: verifique as restrições de permissão aplicáveis e a divulgação em destaque e o consentimento exigidos antes do acesso.
Fonte política de Dados do usuário · balanço de segurança de 2023
Política de privacidade e exclusão de conta
- O problema
- Informe a URL da política de privacidade no Play Console e um link ou o texto da política dentro do app. A página precisa ser pública, sem bloqueio por região, não pode ser um PDF nem ser editável por visitantes, precisa identificar o app ou o desenvolvedor e descrever os dados realmente coletados. Se os usuários puderem criar uma conta dentro do app, ofereça caminhos fáceis de encontrar para pedir a exclusão, tanto dentro do app quanto fora dele, e informe a retenção necessária.
- Um teste observável
- Abra a URL em um dispositivo sem sessão iniciada, de outro país se der, e leia o que está escrito lá comparando com o formulário de Segurança dos dados.
- A correção
- Publique uma página de política que você controla, informe-a no Play Console e dentro do app e crie os caminhos de pedido de exclusão onde o app cria contas.
Coerência entre Segurança dos dados e os SDKs
- O problema
- A declaração de Segurança dos dados precisa refletir o que o app e cada SDK de terceiros dentro dele coletam e compartilham. SDKs de anúncios, de análise de uso e de relatório de falhas podem coletar ou compartilhar dados sem nenhuma permissão de execução, então um app “sem permissões” não é automaticamente um app “sem dados”, e uma página de privacidade no ar não comprova que o formulário está correto. Verifique a versão específica do SDK, a configuração e o comportamento real.
- Um teste observável
- Exporte a lista de dependências da versão, consulte a declaração de dados de cada SDK e compare com cada resposta do formulário. Observe o tráfego de rede na primeira abertura para ver o que sai do dispositivo antes de o usuário fazer qualquer coisa.
- A correção
- Corrija o formulário para que ele corresponda ao comportamento observado, ou remova o SDK. A responsabilidade pela declaração é sua, inclusive pelo código que você não escreveu.
Ficha da loja, declarações e pagamentos
Ficha da loja, anúncios, público-alvo e declarações de conteúdo
- O problema
- A seção Conteúdo do app pergunta se o app tem anúncios, para qual público ele é direcionado, e pede o questionário de classificação de conteúdo e as demais declarações aplicáveis. Uma ficha da loja que mostra recursos que o build não tem, ou uma declaração que não bate com o app, já é motivo de rejeição por si só.
- Um teste observável
- Revise cada resposta de Conteúdo do app com a versão aberta ao lado e confira cada captura de tela com a interface atual.
- A correção
- Atualize as declarações e os recursos da ficha junto com o build que eles descrevem; uma correção na ficha pode não exigir um novo binário.
Pagamentos e condições dos programas aplicáveis
- O problema
- O sistema de faturamento do Google Play é obrigatório para determinadas compras de bens e serviços digitais feitas dentro do app. Bens físicos, serviços do mundo real e algumas outras categorias ficam de fora, e os programas de faturamento alternativo ou de ofertas externas valem em regiões específicas, com condições próprias.
- Um teste observável
- Para cada fluxo de compra, decida se ele vende conteúdo digital consumido dentro do app; se vender, confirme que ele passa pelo Play Billing ou por um programa em que você está realmente inscrito.
- A correção
- Leve as compras digitais para o Play Billing ou documente a inscrição no programa. Não trate um programa regional como uma isenção global.
Fonte política de Pagamentos
As verificações prévias não são a análise
As verificações prévias do Play Console apontam parte desses problemas antes do envio (credenciais faltando, declarações de permissão, um link de privacidade quebrado), e o relatório de pré-lançamento executa o app em dispositivos de teste. Vale a pena usar os dois; passar neles não garante a aprovação na análise formal do app, e nenhum dos dois mede como os participantes de um teste fechado usaram o app.
Fontes: Detectar problemas do app mais cedo com as verificações prévias · Usar o relatório de pré-lançamento para identificar problemas
Como o teste fechado afeta o acesso de produção
Quem precisa cumprir o requisito de teste?
Política do GoogleContas pessoais de desenvolvedor criadas depois de 13 de novembro de 2023 precisam realizar um teste fechado com pelo menos 12 testadores participando continuamente nos últimos 14 dias antes de poderem solicitar o acesso de produção. Cumprir o mínimo deixa você apto a solicitar; não aprova o app. Contas organizacionais e contas pessoais criadas antes dessa data não estão sujeitas ao requisito.
O teste interno não substitui o teste fechado, por mais tempo que ele dure: os 12 testadores precisam estar participando de uma faixa fechada. Os detalhes de configuração estão no guia de requisitos de teste fechado do Google Play.
Fonte: Requisitos de teste de apps para novas contas de desenvolvedor pessoais.
Evidências, prontidão e o próximo passo
Do teste qualificador à publicação em produção
- 1Conclua o teste fechado qualificador. Pelo menos 12 testadores, participando nos últimos 14 dias sem interrupção.
- 2Solicite o acesso de produção. O formulário pergunta como os testadores usaram o app, que feedback você recebeu e o que mudou por causa disso.
- 3O Google analisa a solicitação, normalmente em 7 dias ou menos, às vezes mais, e então concede o acesso ou pede mais testes. Essa estimativa vale para essa análise, não para todo o seu cronograma de lançamento.
- 4Com o acesso concedido, prepare a versão de produção. A análise dela e o lançamento são etapas separadas dessa decisão; o acesso é elegibilidade, não publicação.
Se um testador sair do teste, o período qualificador dele é interrompido e os dias dele deixam de contar. Os outros testadores não são afetados. O que importa na hora de solicitar é se você ainda tem 12 que se qualificam, e não se alguém saiu em algum momento.
O Google pergunta o que você aprendeu; ele não define um número mínimo de atualizações. A afirmação de prontidão que você precisa conseguir fazer com honestidade é: Analisei o feedback dos testadores, resolvi os problemas onde foi necessário e consigo explicar o que aprendi e por que o app está pronto. Se a resposta honesta for que ninguém usou o app, é provável que a análise chegue à mesma conclusão.
Alguns testadores além dos 12 dão a você uma margem contra desistências e um feedback mais amplo; não afirmamos que isso produza um aumento medido de aprovação. Cubra dispositivos físicos representativos como escolha de QA. Os critérios publicados não dizem nada sobre como os emuladores são contados, então este guia não afirma nada em nenhuma direção. Veja também: planejar uma margem de testadores, as perguntas do formulário de acesso de produção e o que verificar depois de uma recusa.
O que fazer depois que um app ou uma atualização é rejeitada
O aviso diz qual foi a decisão, qual envio foi afetado e qual política ou requisito está envolvido. Trabalhe a partir dele, nesta ordem.
Política do Google- 1Leia a decisão exata e o envio afetado. Qual versão, qual faixa, qual política ou requisito.
- 2Reproduza ou examine o problema citado no build que foi analisado, não no que está na sua máquina.
- 3Corrija o problema e revise os requisitos relacionados da mesma área, para que a próxima análise não encontre o problema vizinho.
- 4Valide o build ou a declaração afetada: refaça o teste observável da verificação correspondente acima.
- 5Envie a correção adequada ou use o caminho de contestação se você acredita que a decisão está errada. Quando for necessário, abra a Visão geral da publicação e selecione Enviar para revisão; salvar uma correção nem sempre a envia automaticamente.
- 6Guarde as evidências e acompanhe o resultado. Aviso, versão, problema, correção, validação, decisão.
Corrigir e enviar de novo, ou contestar
Se a constatação está certa, corrija e envie de novo. A orientação do Google sobre aplicação das políticas é explícita: enviar de novo sem corrigir a violação já é um problema em si. Não envie de novo enquanto a violação citada continuar sem solução; algumas correções mudam a ficha da loja ou as declarações sem mudar o binário. Se você acredita que a decisão está errada, siga as instruções de contestação que estão no aviso e inclua o nome do pacote, a versão afetada, a política citada, o motivo pelo qual você acha que a decisão está errada e capturas de tela ou passos reproduzíveis que demonstrem a conformidade. Não tente republicar por outra conta.
Fontes: Processo de aplicação das políticas · Controlar quando as mudanças do app são analisadas e publicadas.
Correção no binário ou na declaração?
Uma correção na ficha da loja ou em uma declaração pode não exigir um novo binário. Um novo build é necessário quando a correção muda o código empacotado, os recursos, as permissões ou a configuração. Correções no site ou no servidor às vezes resolvem o problema sem recompilar. Siga o aviso e valide o envio afetado.
O Google descreve o processamento geral de mudanças em apps como algo que leva de algumas horas a sete dias, às vezes mais. Esse não é um prazo garantido de solução para a sua rejeição ou contestação, e a análise do acesso de produção é um processo separado; veja o tempo de análise do Google Play. Não existe nenhum número publicado de rejeições permitidas nem de probabilidade de sucesso em contestações, e nada disso é prometido aqui.
Como é um registro de rejeição útil
ExemploDois registros ilustrativos, montados para mostrar o formato das evidências que vale a pena guardar: um para a rejeição de uma atualização e outro para elegibilidade de teste incompleta. Não são casos de clientes nem estatísticas. Guarde o ID do envio, que fica em Atividade de envio no Play Console, junto com o aviso e a versão afetada, para que o suporte consiga identificar exatamente qual foi o envio.
| Aviso | Atualização rejeitada, política de Dados do usuário |
|---|---|
| Versão afetada | 2.4.1 (build 241), faixa de produção |
| Problema | O link da política de privacidade na ficha da loja retornava 404 |
| Correção | A página da política de privacidade foi restaurada na URL que já era usada no Play Console e no app. Nenhuma URL embutida mudou, então não foi preciso um novo binário. |
| Validação | URL aberta em um dispositivo sem sessão iniciada, em dois países; formulário de Segurança dos dados relido em comparação com a página |
| Decisão | Enviado de novo; atualização aprovada |
| Aviso | Elegibilidade de teste incompleta |
|---|---|
| Versão afetada | 1.0.3, faixa fechada |
| Problema | 12 testadores adicionados; só 9 continuaram participando ao longo dos 14 dias |
| Correção | Três testadores substitutos recrutados; cada um começou o próprio período de 14 dias |
| Validação | O Painel mostrou 12 testadores participando nos últimos 14 dias |
| Decisão | Ficou apto a solicitar depois que os testadores substitutos completaram os períodos exigidos |
Checklist antes do envio
Rode o checklist exatamente na versão que você está prestes a enviar, não na que você testou semana passada. Os itens marcados com quando aplicável dependem do que o app faz.
Build e comportamento
Acesso do analista e declarações
Privacidade e dados
Pagamentos
Requisito de teste, apenas para contas pessoais novas
Perguntas e respostas
A proporção anual prevê o resultado da primeira análise do meu app?
Não. A proporção de 7,89% compara as contagens globais de envios de apps analisados e rejeitados que o Google divulgou para 2025. Os relatórios não trazem um grupo definido de primeiras tentativas, então nem a proporção nem o complemento dela são uma probabilidade para um app novo específico.
Por que o número do balanço de segurança é diferente do número do relatório de transparência?
Eles medem coisas diferentes. O balanço anual de segurança informa contagens arredondadas de apps que violavam políticas e foram impedidos de serem publicados; o relatório de transparência conta envios rejeitados e remoções. O Google não publica nenhuma conciliação entre as duas séries, então elas não podem ser combinadas em uma única taxa.
Uma atualização rejeitada afeta a versão que já está publicada?
A rejeição comum de uma atualização não remove a versão publicada; a versão anterior continua disponível enquanto você corrige a atualização. Remoção, suspensão e encerramento de conta são status de aplicação de políticas separados, cada um com seu próprio aviso, e esses sim afetam o app que está no ar.
A recusa do acesso de produção é uma rejeição por política?
Não. A decisão de acesso de produção para uma conta pessoal nova analisa o teste fechado que você realizou e as respostas que você deu. “More testing required” significa que a solicitação precisa de mais trabalho; não é uma penalidade de política contra o app, e mais testadores não resolvem uma rejeição por política de verdade.
Devo contestar ou enviar uma correção?
Não envie de novo enquanto a violação citada continuar sem solução. Algumas correções mudam a ficha da loja ou as declarações sem mudar o binário. Se você acredita que a decisão está errada, siga as instruções de contestação do aviso e apresente evidências de conformidade. Não crie outra conta para republicar; isso é tratado como violação.
Fontes e notas sobre os dados
O próximo passo depende do que trouxe você até aqui. Para citar a taxa, cite 7,89% junto com o ano (atividade de 2025) e o denominador (envios analisados). Para agir a partir de um aviso, encontre a linha dele na tabela de decisões e siga aquele caminho. Se o requisito de teste é o que trava você, o guia de requisitos do teste fechado cobre a configuração do começo ao fim.
Conclusão
A proporção de rejeição dos envios no Google Play em 2025 é de cerca de 7,89%, calculada a partir de 1.692.467 envios rejeitados e 21.461.250 analisados no Relatório Anual de Transparência de 2025 do Google. É um número histórico de toda a plataforma, não as chances do seu app. Um aviso de rejeição indica uma decisão específica: corrija o que ele aponta, envie de novo ou conteste, e trate o requisito de teste das contas pessoais novas como uma etapa de prontidão à parte.
Relatórios anuais de transparência
Balanços anuais de segurança
Políticas e Ajuda do Play Console
Histórico de atualizações
28 de fevereiro de 2026: publicado apenas com a série dos balanços anuais de segurança. 12 de setembro de 2026: incluído o cálculo do relatório de transparência e seus limites, separadas as duas séries do Google, acrescentadas a tabela de decisões e as seções sobre acesso do analista, Segurança dos dados e o que fazer depois de uma rejeição, e retirada a ideia de motivos ordenados por frequência; uma segunda revisão no mesmo dia corrigiu a redação sobre reenvio, funcionalidade e prazos de análise. A próxima atualização anual vem quando o Google publicar o relatório de 2026, prevista para 2027.