Resposta rápida
Uma rejeição por Broken Functionality significa que o revisor do Google constatou que a versão enviada travou, fechou à força, congelou ou funcionou de forma anormal de alguma outra maneira; os exemplos do próprio Google são apps que não instalam, que instalam mas não carregam, ou que carregam mas não respondem. É uma decisão de política sobre uma versão, não uma recusa do acesso de produção, e o Google afirma que uma rejeição, por si só, não afeta a situação da sua conta de desenvolvedor. Reproduza o problema no build que o Play distribui, confirme que os revisores conseguem entrar pelo Sign-in details (antes App access), corrija todas as faixas afetadas e envie a versão corrigida para revisão. Conteste apenas quando puder mostrar que a constatação estava errada.
Atualizado em 16 de outubro de 2026. Cada regra desta página foi conferida nas páginas de políticas do Google Play e na Central de Ajuda do Play Console nessa data, e cada uma tem link onde é usada. Os relatos de desenvolvedores citados abaixo são evidências do que desenvolvedores viram em 2026, não o diagnóstico do Google sobre os apps deles, e não há ranking de causas porque nenhum conjunto de dados público sustenta um.
Este artigo trata de rejeições de versões pela política de Broken Functionality. Se o Google recusou o acesso de produção depois do seu teste fechado, ou disse que são necessários mais testes, essa é uma decisão diferente, com uma correção diferente: leia o que fazer quando o Google Play diz que são necessários mais testes e por que pedidos após o teste fechado são rejeitados.
O que este artigo cobre
O que significa Broken Functionality no Google Play?
É uma das duas seções da política de funcionalidade, conteúdo e experiência do usuário do Google. A outra seção, Limited Functionality and Content, trata de apps com pouco propósito. Broken Functionality trata de um app que não funciona como foi enviado.
Não permitimos apps que travam, fecham à força, congelam ou funcionam de forma anormal de alguma outra maneira.
O Google lista três exemplos de violações comuns logo abaixo dessa frase: apps que não instalam, apps que instalam mas não carregam e apps que carregam mas não respondem. Leia isso como três lugares onde procurar. Um revisor que não consegue instalar o build, que vê uma tela em branco ou um carregamento sem fim, ou que toca em um controle e nada acontece, pode gerar o mesmo aviso.
Você ainda pode encontrar o nome Minimum Functionality em links antigos da Central de Ajuda e em tópicos de fóruns. A seção atual da política se chama Limited Functionality and Content e cobre apps de texto estático ou PDF, apps com pouquíssimo conteúdo e apps feitos para não fazer nada. Um aviso pode citar qualquer uma das duas seções, e as correções são diferentes, então leia qual delas seu aviso cita antes de mudar qualquer coisa.
Quatro decisões que são confundidas entre si
| Decisão | Do que se trata | Por onde começar |
|---|---|---|
| Broken Functionality | Do que se trataA versão enviada travou, congelou, não carregou ou não respondeu para o revisor. | Por onde começarReproduza no build que o Play distribui, corrija em todas as faixas afetadas e reenvie. |
| Limited Functionality and Content | Do que se trataO app roda, mas oferece pouco propósito ou conteúdo próprio. | Por onde começarAdicione funcionalidade real. Só corrigir um bug não resolve esta. |
| Sign-in details ausentes ou que não funcionam | Do que se trataOs revisores não conseguiram passar de um login, assinatura, paywall, código de uso único ou verificação de região. | Por onde começarAtualize o Sign-in details em App content e envie a alteração para revisão. |
| Acesso de produção não concedido | Do que se trataDepois do teste fechado, o Google decidiu que o app precisa de mais testes ou não está pronto para a produção. | Por onde começarUm processo separado, sem aviso sobre o código. Veja mais testes necessários. |
Onde o Google mostra o que estava com falha?
Comece pelo e-mail de aplicação da política e pela página Policy status no Play Console. Juntos, eles citam a política e a versão afetada, e o Google diz que a Policy status também mostra qualquer informação adicional disponível. Capturas de tela, detalhes do dispositivo e stack traces não são prometidos, então não fique esperando por eles.
Abra o Play Console, selecione o app e abra a página Policy status. Anote quatro coisas antes de mexer no código: a seção da política citada, o version code e a faixa que foram analisados, a data e qualquer evidência anexada. Confira também o e-mail e as notificações do Play Console, porque é ali que o Google informa qual política a versão violou.
Como os avisos de 2026 realmente são
Não existe um único e-mail de Broken Functionality que todo mundo recebe, e qualquer página que publica um como o modelo exato está chutando. Desenvolvedores que publicaram seus avisos em 2026 descrevem níveis de detalhe bem diferentes:
- Um rótulo de aviso com o texto "Broken Functionality: Unresponsive UI elements" (elementos da interface sem resposta), publicado em 2 de setembro de 2026 por um desenvolvedor cujo app mostrava uma tela de nova tentativa offline durante a primeira sincronização de dados (Comunidade de Ajuda do Play Console).
- Um exemplo do revisor com o texto "For example, your app does not open or load." (por exemplo, seu app não abre nem carrega), citado em junho de 2026 por um desenvolvedor de jogos cuja tela de título carregava, sim. O autor relatou depois que o jogo foi publicado após mudar a forma como o botão Voltar do Android saía dele.
- Um aviso que um desenvolvedor descreveu em agosto de 2026 como apenas duas palavras, "Broken functionality", e nada mais.
São trechos reproduzidos por desenvolvedores, não e-mails autenticados do Google, e cada um é um caso isolado. Eles mostram a variedade de detalhes que você pode receber, não o que o seu aviso vai dizer nem por que o seu app falhou.
Se o seu aviso for vago
Trate a política citada como um sintoma a reproduzir, não como um diagnóstico. As cinco verificações da próxima seção estão ordenadas para que cada uma descarte um lugar diferente onde a falha pode estar escondida.
O que verificar primeiro depois de uma rejeição por Broken Functionality?
Faça cinco verificações na versão exata que o Google analisou. Elas estão ordenadas da mais barata de descartar para a mais difícil, não pela frequência de cada causa, porque nenhum dado público mostra com que frequência cada uma acontece.
Cinco verificações, em ordem
Instale o build que o Play distribui, não o seu build de debug
Instale a partir da sua faixa de teste em um dispositivo limpo, conectado a uma Conta do Google que nunca rodou o app, e abra o app como um revisor abriria. O Google Play assina os builds que distribui com a sua chave de assinatura do app (Usar a assinatura de apps do Google Play), então qualquer serviço que confere a impressão digital de um certificado, como Google Sign-In, Maps ou uma chave de API restrita por nome de pacote e SHA-1, pode funcionar no seu build de debug e falhar no build da loja. Um desenvolvedor, em 2025, rastreou uma falha que só acontecia na versão de release até uma permissão de internet ausente no manifesto de produção.
Confirme que o revisor consegue entrar
Se alguma parte do app fica atrás de um login, assinatura, localização ou outro bloqueio, o Google exige que você forneça os dados de acesso. Confira se o Sign-in details (antes App access) tem credenciais que funcionam hoje, de qualquer país, sem código de uso único. A próxima seção explica o passo a passo.
Teste o backend de fora da sua própria rede
Telas de login e telas de dados falham quando o servidor não pode ser acessado da rede do revisor. Desenvolvedores, em 2026, rastrearam falhas até uma regra de firewall acidental que bloqueava um pedido de código de login e relataram um erro de confiança de certificado exibido em uma tela de login. Teste pelos dados móveis e por outra rede, e de outro país se o seu servidor filtra o tráfego por região.
Toque em cada controle visível e abra cada tela vazia
Cada botão e link deve responder com conteúdo adequado. A própria lista de verificação de Broken Functionality do Google na Comunidade de Ajuda do Play Console diz: "Verifique se o seu app não tem páginas vazias ou em branco sem avisos ou mensagens de erro adequados." Remova recursos inacabados em vez de publicar um botão que não faz nada, e confira se cada recurso que a sua página na loja promete realmente funciona no build. Para uma lista legitimamente vazia, como nenhum item salvo ainda, coloque uma frase que explique isso e uma próxima ação. Se a sua navegação for incomum, como tocar em qualquer lugar para continuar, adicione uma indicação visível que um usuário de primeira viagem não tenha como deixar passar.
Confira a abertura, o botão Voltar e os relatórios que o Play já tem
Abra o app a frio, gire a tela, mande o app para segundo plano e traga de volta, e pressione Voltar em cada tela. Depois, leia o relatório de pré-lançamento e o Android vitals da versão analisada. Uma falha registrada ali é a evidência mais forte que você vai conseguir, e um relatório limpo tem limites, que a seção depois da próxima explica.
Como fornecer dados de login aos revisores do Google?
No Play Console, vá em Policy and programs, depois App content e depois Sign-in details. A seção se chamava App access, então artigos mais antigos e algumas páginas traduzidas da Central de Ajuda ainda usam esse nome.
Se o app inteiro ou partes dele forem restritos com base em credenciais de login, dados de login, assinaturas, localização ou outras formas de autenticação, você precisa fornecer todos os dados necessários para permitir o acesso ao app.
Adicione ou atualize as instruções
- Abra o Play Console e vá até a página App content (Policy and programs > App content).
- Em Sign-in details, selecione Start, ou Manage se você já adicionou instruções antes.
- Selecione + Add new instructions e informe os dados de acesso. Use o campo Any other instructions para qualquer coisa incomum, como uma senha de uso único, autenticação multifator ou um login com mais de dois campos.
- Salve as alterações. Você pode adicionar até cinco conjuntos de instruções.
- Vá até Publishing overview, encontre a alteração em Changes ready to send for review e selecione Send for review. Só salvar não envia nada.
O que conta como acesso que funciona
Os requisitos do Play Console do Google pedem que você "forneça uma conta de demonstração ativa, informações de login e todos os outros recursos necessários para que o Google Play analise o app". Os requisitos de dados de login do Google explicam o que isso significa:
- Uma conta ativa e reutilizável, não um convite de uso único nem um teste grátis que expira durante a análise.
- Credenciais que passam por códigos de uso único e verificação em duas etapas, porque o revisor não consegue receber o código que você envia para um celular ou uma caixa de entrada.
- Acesso que funciona de qualquer localização, se o app restringe por região, e acesso completo aos recursos pagos ou bloqueados que o revisor precisa ver, sem ser cobrado.
- Dados escritos em inglês e mantidos atualizados. Se você trocar a senha ou excluir a conta de teste, atualize o Sign-in details no mesmo dia.
- Se o login exige algo que não é texto, como um QR code ou código de barras, gere um URL estático para ele e adicione ao Sign-in details. Se o app pede que os usuários definam o próprio PIN ou usa login social, explique nas instruções como um revisor consegue passar.
Falta de acesso não é o mesmo que login com falha
Se o aviso cita Sign-in details, nenhuma mudança no código ajuda até que os dados de acesso sejam corrigidos e enviados para revisão. Se as credenciais estavam certas e o próprio login falhou, isso é um problema de Broken Functionality, e a verificação de backend acima é onde procurar.
E se o app funciona no seu celular e o Google não enviou captura de tela?
Então o seu celular não é o ambiente que falhou. Reproduza no build da loja, em um dispositivo limpo e em outra rede, e leia os dois relatórios que o Play Console já tem dessa versão antes de decidir qualquer coisa.
O relatório de pré-lançamento
Ele fica em Test and release > Testing > Pre-launch report. O Google o gera automaticamente quando você envia um app bundle ou APK, conforme a capacidade disponível, rodando o app em dispositivos de teste. Confira quais telas o rastreamento realmente alcançou: se ele parou na sua tela de login, nunca viu o resto do app. O Google acrescenta um limite que vale conhecer: "As credenciais só podem ser inseridas automaticamente em apps Android que usam widgets padrão do Android." (Usar um relatório de pré-lançamento para identificar problemas). Um relatório limpo é evidência, não aprovação. O Google diz o mesmo das suas verificações pré-revisão: "Passar em todas as verificações pré-revisão não garante passar no processo formal de revisão do app".
Android vitals
Ele fica em Monitor and improve > Android vitals > Crashes and ANRs. O Google coleta esses dados apenas de usuários que aceitaram compartilhar dados de uso e diagnóstico (Monitorar a qualidade técnica com o Android vitals), então um app novo em um teste pequeno pode não mostrar nada. Uma página do Android vitals vazia não prova que o app nunca travou.
Pessoas reais em dispositivos reais
Um teste fechado existe para encontrar esse tipo de problema antes de um lançamento público. Testadores com celulares, versões do Android e redes diferentes chegam às telas que um revisor alcança, e o feedback deles mostra onde as coisas quebram. Isso ajuda você a encontrar e corrigir defeitos; não muda a forma como o Google analisa o app. Se você precisa do básico sobre a própria faixa, veja como funciona o teste fechado do Google Play.
Você deve corrigir e reenviar, ou contestar?
Corrija e reenvie quando conseguir reproduzir uma falha ou encontrar uma causa plausível. Conteste quando tiver evidências de que a constatação citada está errada. Nunca reenvie o mesmo build sem mudanças: o Google orienta os desenvolvedores a não publicar novamente um app recusado até que a violação seja corrigida.
Corrigir, esclarecer ou contestar?
Responda a três perguntas sobre o seu aviso e os seus próprios testes. Nada do que você escolher sai desta página.
Responda às perguntas para ver uma recomendação. Se você não consegue reproduzir uma falha, a terceira pergunta decide.
Corrija e depois reenvie em todas as faixas
Corrigir e reenviarVocê tem uma falha reproduzível, que é a melhor situação possível. Corrija, teste a correção no build da loja e depois siga as etapas de reenvio abaixo para que nenhum bundle fora de conformidade continue ativo em nenhuma faixa.
Teste o build da loja antes de decidir
Teste primeiroUm build de debug não é o que o revisor rodou. Instale a partir da sua faixa de teste em um dispositivo limpo com uma conta nova, em uma rede que você não controla, e faça as cinco verificações. Só decida depois disso.
Corrija o Sign-in details e envie para revisão
Correção de acessoAtualize as instruções com credenciais reutilizáveis que dispensem códigos de uso único, salve e envie a alteração para revisão pelo Publishing overview. O Google diz que você pode fazer isso sem entrar em contato com a equipe de suporte de políticas nem esperar por ela.
Adicione propósito, não só correções
ReformularLimited Functionality and Content trata de quanto o app faz. Adicione recursos ou conteúdo reais e próprios do app antes de reenviar; uma correção de estabilidade não responde a essa constatação.
Deixe o design evidente e depois decida
EsclarecerSe uma tela offline, um estado vazio ou um gesto incomum é proposital, um revisor ainda pode interpretar isso como falha. Adicione uma indicação visível, uma explicação e uma próxima ação. Você pode contestar com evidências, mas uma tela mais clara também tira a dúvida do próximo revisor.
Conteste com evidências
ContestarVocê testou o build da loja em um dispositivo limpo e em outra rede e não encontrou nada errado. Conteste uma vez, com o version code, o dispositivo e a versão do Android, as etapas exatas e uma gravação de tela do fluxo que o aviso cita.
Reenviando uma versão corrigida
As etapas de reenvio do Google vão além de enviar um novo version code:
- Leia a política citada no e-mail e nas suas notificações, e confira o app em relação às outras políticas também; o Google avisa que novas violações podem levar a novas ações de aplicação.
- Atualize todos os tipos de versão que contêm a versão afetada, não só a de produção: incluindo as faixas de teste aberto, fechado e interno.
- Envie o app bundle corrigido e desative os que estão fora de conformidade. O Google avisa que, se você não os desativar, o reenvio falha e as versões publicadas podem ser removidas.
- Em cada faixa afetada, selecione Manage track e Create new release, adicione o bundle corrigido (ou descarte um rascunho que contenha o bundle em violação) e confirme que a versão fora de conformidade aparece em Not included.
- Salve, selecione Review release e faça o lançamento.
Depois disso, a alteração aguarda processamento. O Google diz: "O processamento pode levar algumas horas ou até sete dias (ou mais em casos excepcionais)" (Controlar quando as alterações do app são revisadas e publicadas).
Corrigido, mas o aviso continua lá
Se uma versão corrigida está publicada e a Policy status ainda mostra o problema, compare os version codes e as faixas que o aviso cita com o que está ativo agora: um bundle fora de conformidade esquecido em uma faixa de teste é a primeira coisa a descartar. Uma versão mais nova não limpa automaticamente todos os registros de aplicação da política. Se tudo bater, entre em contato com o suporte do Play Console com os version codes, as faixas afetadas e qualquer referência de caso anterior.
Contestando a decisão
O Google restabelece apps quando cometeu um erro e conclui que o app não viola as políticas dele. Para contestar, siga as instruções do e-mail de aplicação da política ou use o formulário de contestação do Google. Você pode enviar uma contestação por ação de aplicação (Gerenciar violações de política e contestações), e o Google responde contestações em chinês, inglês, japonês e coreano. O Google não publica um prazo de resposta para contestações, e os relatos de desenvolvedores misturam respostas a contestações com revisões posteriores de versões, então planeje sem contar com uma data.
Escreva a contestação como evidência, não como desabafo: o version code que foi analisado, o dispositivo e a versão do Android em que você testou, as etapas exatas, uma gravação de tela do fluxo que o aviso cita e o que você mudou, se mudou algo.
Uma rejeição por Broken Functionality prejudica sua conta ou seu teste fechado?
Uma rejeição, por si só, não afeta a situação da sua conta de desenvolvedor. Rejeições repetidas podem levar à suspensão, e suspensões contam como advertências, então corrija antes de reenviar. O que uma rejeição faz com um teste fechado em andamento não está documentado.
A página Processo de aplicação do Google explica a diferença:
- "As rejeições não afetam a situação da sua conta de desenvolvedor do Google Play."
- "Se a atualização de um app existente for rejeitada, a versão do app publicada antes da atualização vai continuar disponível no Google Play."
- "A suspensão pode ocorrer como resultado de violações de política graves ou múltiplas, assim como de rejeições ou remoções repetidas de apps."
O Google não publica um número de rejeições que seja seguro. Reenviar a mesma falha é exatamente o padrão que a terceira frase descreve.
E o teste fechado de 14 dias?
O requisito de teste do Google exige que contas pessoais criadas após 13 de novembro de 2023 tenham no mínimo 12 testadores participando continuamente por pelo menos 14 dias antes de solicitar o acesso de produção. Ele não diz se uma rejeição por política de uma versão na faixa fechada reinicia, pausa ou mantém esse período, e as afirmações em fóruns, para um lado ou para o outro, são palpites. O que você pode verificar: se os seus testadores ainda têm uma versão aprovada na faixa e o que o Painel mostra sobre o acesso de produção. Mantenha os testadores participando enquanto corrige e pergunte ao suporte do Play Console sobre o seu caso se o Painel mudar. A regra em si é explicada em o que significam 14 dias consecutivos.
O Google vai rejeitar um app WebView ou TWA como quebrado?
Não por causa da tecnologia. O Google documenta tanto as Trusted Web Activities quanto a WebView para apps Android, e nenhuma política proíbe essa arquitetura. As perguntas são se o app funciona, se ele tem propósito suficiente e se você tem o direito de encapsular o site.
Não permitimos apps cujo objetivo principal seja direcionar tráfego de afiliados para um site ou oferecer uma webview de um site sem a permissão do proprietário ou administrador do site.
Para um app baseado na web, as verificações de Broken Functionality são as mesmas de qualquer outro app: o site precisa carregar dentro do app a partir de uma instalação limpa, os estados offline e de erro precisam se explicar e cada link precisa levar a algum lugar. Se o app é basicamente uma visualização simples de um site, a seção Limited Functionality and Content é o risco maior. Trocar uma TWA por uma WebView, ou o contrário, não demonstrou corrigir uma rejeição por si só.
Como a PrimeTestLab ajuda antes da próxima análise?
Não podemos corrigir o seu código nem mudar a decisão do Google. O que fornecemos é o lado do teste: pessoas reais em dispositivos reais que usam o seu app pelo seu teste fechado, para que problemas como os descritos acima apareçam no feedback delas antes que um revisor os encontre.
A PrimeTestLab fornece 12 ou mais testadores reais em dispositivos reais, cobrindo do Android 7 ao 17, participando durante os 14 dias completos, com o teste começando em 4-6 horas. Já fizemos testes gerenciados para 12.100+ apps com testadores em 120+ países.
Teste por conta própria ou teste gerenciado
| Tarefa | Por conta própria | Com a PrimeTestLab |
|---|---|---|
| Encontrar testadores | Por conta própriaAmigos, grupos e fóruns, geralmente com celulares parecidos | Com a PrimeTestLabTestadores reais em dispositivos reais, designados para o seu app |
| Variedade de dispositivos e versões do Android | Por conta própriaO que os seus voluntários tiverem | Com a PrimeTestLabDispositivos do Android 7 ao 17 |
| Uso diário e feedback | Por conta própriaDepende da boa vontade | Com a PrimeTestLabOs testadores usam o app e relatam o que quebra |
| Manter 12 participando por 14 dias | Por conta própriaVocê mesmo corre atrás de quem desiste | Com a PrimeTestLabQuem desiste é substituído para manter a contagem |
| Corrigir o código e o aviso | Por conta própriaVocê | Com a PrimeTestLabContinua sendo você; relatamos o que os testadores encontraram |
| A decisão do Google | Por conta própriaGoogle | Com a PrimeTestLabContinua sendo o Google; ninguém pode prometer aprovação |
Se o Google não concedeu o acesso de produção depois do seu teste completo com a PrimeTestLab, você escolhe entre um novo teste grátis ou um reembolso total; veja a política de reembolso e novo teste grátis. Isso cobre o requisito de teste, não uma rejeição por política do seu código. Os planos começam em $19.99, mais 5% de taxa de serviço no checkout (mínimo de $1.50), e a taxa de registro única de $25 do Google é cobrada à parte. Compare os planos na página de preços.
Perguntas frequentes
O que é a política de Broken Functionality no Google Play?
É uma seção da política de funcionalidade, conteúdo e experiência do usuário do Google Play. O Google não permite apps que travam, fecham à força, congelam ou funcionam de forma anormal de alguma outra maneira, e lista como violações comuns apps que não instalam, apps que instalam mas não carregam e apps que carregam mas não respondem.
Broken Functionality é o mesmo que Minimum Functionality?
Não. Minimum Functionality é o nome antigo do que o Google agora chama de Limited Functionality and Content, que cobre apps com pouco propósito ou conteúdo. Broken Functionality cobre apps que não funcionam como foram enviados. As duas estão na mesma política, mas exigem correções diferentes.
Onde adiciono credenciais de demonstração para a revisão do Google Play?
No Play Console, vá em Policy and programs, depois App content e depois Sign-in details (antes App access). Selecione Start ou Manage, adicione as instruções e salve, depois envie a alteração para revisão pela página Publishing overview. As credenciais devem ser reutilizáveis e não podem depender de um código de uso único enviado para o seu celular.
Uma rejeição conta como advertência na minha conta de desenvolvedor?
O Google diz que as rejeições não afetam a situação da sua conta de desenvolvedor. Suspensões contam como advertências, e o Google lista rejeições ou remoções repetidas de apps entre os motivos de suspensão, então corrija o problema citado antes de reenviar.
Quanto tempo leva a revisão depois que reenvio um app corrigido?
O Google diz que as alterações do app podem levar algumas horas ou até sete dias para serem processadas, ou mais em casos excepcionais. Essa é a revisão da versão corrigida. O Google não publica um prazo de resposta para contestações.
Posso contestar uma rejeição por Broken Functionality?
Sim, se você acredita que a constatação está errada. Siga as instruções do e-mail de aplicação da política ou use o formulário de contestação do Google. Você pode enviar uma contestação por ação de aplicação, então inclua o version code analisado, o dispositivo e as etapas que você testou e uma gravação do fluxo que o aviso cita.
Uma rejeição por Broken Functionality reinicia o meu teste fechado de 14 dias?
O Google não documenta isso. O requisito dele é de no mínimo 12 testadores participando continuamente por pelo menos 14 dias antes de você solicitar o acesso de produção. Mantenha os testadores participando enquanto corrige a versão, acompanhe o Painel e pergunte ao suporte do Play Console se a sua qualificação mudar.
Por que meu app foi rejeitado se ele funciona no meu celular?
O seu celular cobre um build, uma conta, um conjunto de dados e uma rede. Instale a versão que o Play distribui em um dispositivo limpo com uma conta nova e depois teste conteúdo vazio e solicitações de rede que falham. Um build da loja assinado com a chave de assinatura do app pode falhar onde o seu build de debug funciona, então teste o build que o revisor instalou.
Meu app usa Google Sign-In ou um código de uso único. O que devo fornecer aos revisores?
O Google exige dados de login reutilizáveis, que funcionem de qualquer localização e dispensem senhas de uso único ou verificação em duas etapas. Forneça aos revisores uma conta de teste e instruções que alcancem todos os recursos restritos, incluindo os pagos. Depois, teste você mesmo os dados exatos que forneceu; explicar como um usuário comum recebe um código não é um acesso que funciona.
O Google não enviou captura de tela nem log de falha. E agora?
Confira a Policy status e o e-mail de aplicação da política para ver a versão afetada e qualquer detalhe que o Google tenha adicionado. Depois, reproduza a jornada principal na versão enviada e grave o seu próprio vídeo e os seus logs. Uma página do Android vitals limpa ou um relatório de pré-lançamento limpo não prova que cada tela e cada solicitação ao backend funcionaram para o revisor.
Apps TWA e WebView são rejeitados automaticamente?
Não. O Google documenta as duas tecnologias e nenhuma política as proíbe. O Google restringe, sim, apps que encapsulam um site sem a permissão do proprietário e apps com funcionalidade ou conteúdo insuficientes. Diagnostique a falha real, como erros de login, de navegação ou de rede; trocar um wrapper pelo outro não é uma correção documentada.
Resumo final
Resumo final
Uma rejeição por Broken Functionality diz que a versão analisada pelo Google não funcionou: ela travou, congelou, não carregou ou não respondeu. Leia qual política o aviso cita, reproduza no build que o Play distribui, confirme que os revisores conseguem entrar pelo Sign-in details, teste o backend de fora da sua rede e faça cada controle e cada tela vazia se explicarem. Corrija todas as faixas afetadas e envie a versão corrigida para revisão. Conteste apenas com evidências de que a constatação estava errada. Uma rejeição sozinha não é uma advertência, mas reenvios repetidos sem correção podem levar a uma.
Se você quer que pessoas reais em dispositivos reais encontrem a tela com falha antes do próximo revisor, a PrimeTestLab cuida do lado do teste fechado enquanto você corrige o app.
Documentação oficial do Google
O que pode mudar nesta página
- Os rótulos do Play Console mudam. O Sign-in details se chamava App access até pouco tempo atrás, e algumas páginas traduzidas da Central de Ajuda ainda usam o nome antigo.
- O texto dos avisos não é publicado como modelo e muda de um caso para outro; confie no seu próprio e-mail e na sua página Policy status mais do que em qualquer exemplo daqui.
- O Google não documenta o que uma rejeição por política faz com um teste fechado em andamento. Se ele publicar uma regra, esta página vai segui-la.
Fontes conferidas em 16 de outubro de 2026.