Política Broken Functionality: por que o Google recusa um app que no seu celular funciona perfeitamente

O Google manda uma linha: seu app não está em conformidade com a política Broken Functionality. Sem stack trace, sem captura de tela, sem passos para reproduzir. Você instala a mesma build de release no seu próprio celular e funciona. Então o que mudar antes de reenviar? Normalmente nada no código — o revisor nunca chegou até lá.

Última atualização: julho de 2026

O que a política Broken Functionality diz de verdade

Broken Functionality é uma seção da política do Google Play «Funcionalidade, conteúdo e experiência do usuário». A regra cabe em uma frase: não são permitidos apps que travem, fechem de forma inesperada, congelem ou funcionem de forma anormal. O Google dá exatamente três exemplos — apps que não instalam, apps que instalam mas não carregam e apps que carregam mas não respondem.

Releia e repare no que NÃO está ali. Nada sobre a sua arquitetura, a sua cobertura de testes, o seu framework ou a qualidade do seu código. É uma política de comportamento. Ela descreve o que aconteceu em um aparelho, em uma sessão, em uma rede, durante uma revisão que dura minutos. Essa distinção é o jogo inteiro: não se resolve escrevendo código melhor, e sim fazendo o app sobreviver aos primeiros cinco minutos com um estranho.

Política do Google Play: funcionalidade, conteúdo e experiência do usuário

Ache a sua linha de recusa exata

O corpo do e-mail é um modelo enviado a milhares de desenvolvedores. A linha do problema logo abaixo não é — é a coisa mais parecida com um relatório de bug que você vai receber. Procure a sua na primeira coluna.

A linha que o Google te deu	O que o revisor viu	A causa realmente mais provável	Faça isto antes de reenviar
`App doesn't install`	O artefato nunca virou uma instalação funcional no aparelho de revisão.	Uma falha na instalação, não um bug em tempo de execução: minSdkVersion acima do aparelho de teste, um split de ABI ou de densidade faltando, ou assinatura incompatível.	Instale o artefato que o Google realmente tem — baixe da sua trilha de teste interno, não do Android Studio — em um aparelho compatível com o minSdk que você declara.
`App installs, but doesn't load`	Ele abriu e ficou em uma tela que nunca ficou utilizável.	A splash está esperando algo que a sessão do revisor não tem: um token de autenticação, uma primeira chamada de API, uma busca de configuração remota, um token do FCM.	Inicie o app a frio em modo avião, sem sessão em cache. Se ele travar em vez de mostrar um erro, você acabou de reproduzir a sua recusa.
`App loads, but crashes`	Um travamento nos primeiros minutos da sessão.	Um caminho de primeiro uso em que você nunca esbarra local. Seu aparelho tem dados; o do revisor não, então uma lista vazia ou um perfil nulo derruba a tela.	Relatório de pré-lançamento → aba Estabilidade. O stack trace já está lá, de um aparelho real, do lado do Google.
`App loads, but is not responsive`	Os toques não faziam nada, ou a interface congelou.	Trabalho na thread principal durante a inicialização: uma chamada de rede síncrona, um parse de JSON pesado, uma migração de banco.	Tire isso da thread principal. O Android dispara um ANR aos 5 segundos sem tratar um evento de entrada — um revisor desiste bem antes do sistema.
`App contains icon(s) or button(s) that are not responsive`	Determinados controles não faziam nada ao serem tocados.	Controles mortos: um bloco «Em breve», um botão atrás de uma feature flag desligada, uma linha de menu ligada a nada, um link que dá 404.	Em uma instalação limpa e sem conta, toque em todos os controles do app. Tudo o que não responde é ligado ou removido — não existe terceira opção.

Linhas de problema como aparecem sob o veredito Broken Functionality no Play Console. A primeira, a terceira e a quarta são exemplos publicados pelo próprio Google; as demais são textos recorrentes relatados na comunidade de desenvolvedores do Play.

Broken Functionality não é Limited Functionality

São duas seções diferentes da mesma página de políticas, e as soluções são opostas. Broken Functionality significa que seu app falha. Limited Functionality and Content significa que seu app funciona perfeitamente e mesmo assim não vale a instalação: uma WebView em volta do seu site, uma única tela estática, um visualizador de um PDF só. Confundir as duas te manda construir funcionalidades quando o que precisa é destravar um congelamento.

	Broken Functionality	Limited Functionality and Content
A regra	«Não permitimos apps que travem, fechem de forma inesperada, congelem ou funcionem de forma anormal.»	«Não permitimos apps que tenham apenas funcionalidade e conteúdo limitados.»
O que deu errado	Seu app não fez o que promete.	Seu app fez exatamente o que promete. E é justamente esse o problema.
Gatilho típico	Splash travada, travamento no primeiro uso, botão morto, backend inacessível.	Um site dentro de uma WebView, uma tela de texto, uma casca sem valor nativo.
A correção	Fazer o fluxo existente funcionar em um aparelho limpo.	Construir algo que uma aba de navegador não faz — ou não publicar.
O movimento errado	Adicionar funcionalidades.	Corrigir bugs.

Nosso próprio guia de recusas do Google Play juntava as duas coisas em um único item. Estava errado, e é boa parte do motivo pelo qual esta página existe. Why Google Play rejects apps

Seu app funciona. O revisor mesmo assim não conseguiu entrar.

É aqui que mora de fato a maioria dessas recusas, e quase ninguém escreve sobre isso. Sua build está bem. Sua máquina não é a do revisor. Passe por esta lista antes de mexer em uma linha de código.

Uma tela de login sem credenciais de teste que funcionem. O revisor abre seu app, vê um formulário, não tem o que digitar e fecha. De fora, isso é indistinguível de um app que «instala, mas não carrega».
Código de uso único por SMS ou e-mail. Você forneceu uma conta de demonstração, mas o código vai para um celular na sua mesa. O Google é explícito: se o app normalmente exige verificação em duas etapas ou senha de uso único, você precisa fornecer credenciais reutilizáveis que contornem isso.
Um backend com bloqueio geográfico ou lista de IPs permitidos. A revisão não sai do seu escritório. Se sua API só aceita o CIDR do escritório, ou o app bloqueia países onde você não vende, o revisor cai na sua tela de erro. A redação do próprio Google é que as credenciais devem ser válidas «independentemente da localização do usuário», e que um bloqueio geográfico exige credenciais mestras.
Uma URL base de staging ou localhost na build de release. Parece bobo demais para acontecer e acontece o tempo todo: uma variante de build mal configurada, um .env não trocado, uma URL de debug que sobreviveu a um merge. Seu notebook resolve esse host pela VPN do escritório ou por uma linha no /etc/hosts. O aparelho de revisão não.
Um backend que dorme. Escala a zero e hospedagens gratuitas levam de 5 a 30 segundos para iniciar a frio. Sua primeira requisição da manhã é lenta e você já nem repara. Toda requisição do revisor é uma primeira requisição da manhã.
Uma feature flag que ficou desligada. Você publicou com a flag remota desativada, planejando ligá-la depois da aprovação. O revisor testa o que está na frente dele, encontra uma tela vazia e recusa.
Uma chave de API expirada, ou uma chave do Maps/Firebase restrita ao seu certificado de assinatura de debug. O Play App Signing reassina seu release com um SHA-1 diferente do da sua chave de debug. A partir daí todo bloco e toda chamada falham — só em produção, nunca na sua máquina.

Cada um desses casos produz um app impecável na sua mesa e quebrado na revisão. E nenhum deles vai aparecer nos seus relatórios de falha, porque nada travou.

Como dar uma conta de teste aos revisores do Google Play?

No Play Console, vá em Política e programas → Conteúdo do app → Detalhes de login → Iniciar (ou Gerenciar), clique em «+ Adicionar novas instruções» e preencha os dados de acesso. Dá para cadastrar até cinco conjuntos. Depois abra a página Visão geral da publicação e clique em «Enviar para revisão». Se a única coisa que mudou foram as credenciais, não é preciso subir um novo .aab.

As exigências do Google para esses dados, nas palavras deles:

Acessíveis a qualquer momento, reutilizáveis e válidos independentemente da localização do usuário.
Mantidos o tempo todo e sem erros.
Fornecidos em inglês.
Se o login não for numérico nem alfanumérico — um QR code ou código de barras — gere uma URL estática e envie ao Play Console.
Se o usuário define o próprio PIN ou senha para chegar ao conteúdo do app, dê instruções claras.
Se você depende do login com Google, Facebook ou similares, forneça todas as informações da conta mais instruções detalhadas.

A falha da qual ninguém te avisa: sua conta de demonstração funciona, e depois para de funcionar. Um teste de 30 dias expira. Um limitador de taxa a bloqueia na terceira revisão. Alguém do time reseta o banco de testes numa sexta-feira. «Acessíveis a qualquer momento» está trabalhando muito nessa frase — trate a conta de revisão como dado de produção.

Uma conta só também não basta. O revisor precisa alcançar toda funcionalidade que a sua ficha na loja anuncia. Se a aba premium exige um plano pago, a conta de demonstração precisa já ter esse direito concedido.

Google Play: requisitos para fornecer detalhes de login para a revisão

O relatório de pré-lançamento mente para você se houver tela de login

O teste Robo só consegue digitar suas credenciais de teste em widgets padrão do Android e no Compose. Ele não faz login por um fluxo de autenticação baseado em WebView e não controla elementos que o app desenha em OpenGL. Assim, um app em React Native ou Flutter com login em WebView recebe um relatório limpo, sem travamentos, cobrindo exatamente uma tela: a de login. Relatório verde, app recusado.

Adicione uma conta de teste descartável em Teste e lançamento → Testes → Relatório de pré-lançamento → Configurações. Nunca uma conta real. Depois leia a aba Capturas de tela antes da aba Estabilidade — se as 20 capturas forem a sua tela de login, você achou a sua recusa, e ela nunca foi um travamento.

Google Play: usar um relatório de pré-lançamento para identificar problemas

A partir de quando lento conta como travado?

O Android gera um ANR quando o app não responde a um evento de entrada em 5 segundos. O mesmo limite de 5 segundos vale para um broadcast receiver em primeiro plano e para chamar startForeground() depois de startForegroundService(). Esses são os limites do sistema. A paciência de um revisor é bem mais curta, e contra o tédio não há recurso.

Para dimensionar os números que o próprio Google considera inaceitáveis: os limites de mau comportamento do Android vitals são 1,09 % de taxa de travamento percebida pelo usuário e 0,47 % de taxa de ANR percebida, no conjunto dos aparelhos, ou 8 % em um único modelo. Ultrapassar isso rende um aviso na sua ficha da loja — mas você pode ficar bem abaixo e ser recusado assim mesmo, porque uma revisão é uma sessão, não uma distribuição.

É assim na prática. Um desenvolvedor publicou exatamente o texto «App installs, but doesn't load» no fórum Android Builder, insistindo que nada estava errado; pressionado por detalhes, mencionou que «às vezes a tela 1 fica parada alguns segundos». Sem travamento. Sem ANR. Abaixo do limite de 5 segundos do sistema. Recusado do mesmo jeito.

O que nos leva ao jeito mais eficiente de conquistar essa recusa: a tela de splash que esconde um backend morto. Ela fica idêntica tanto se a sua API respondeu em 200 ms quanto se nunca respondeu. Dê a ela um tempo limite — 3 segundos e então uma tela de erro de verdade com um botão Tentar de novo. Um app que diz «Não foi possível falar com o servidor» é um app que funciona em um dia ruim. Um app que gira para sempre é «installs, but doesn't load».

Android developers: ANRs · Limites do Android vitals

Reproduza em 30 minutos

Entre no estado do revisor. Um emulador zerado ou um aparelho reserva: nenhuma conta logada, nenhuma sessão em cache, sem VPN, sem linha no /etc/hosts, dados móveis em vez do wifi do escritório. Instale o artefato que o Google tem: baixe o .aab da trilha de teste interno em vez de compilar local. Só esse passo já encontra a maioria dos casos.
Abra o relatório de pré-lançamento (Teste e lançamento → Relatório de pré-lançamento). Primeiro a aba Capturas de tela: o robô passou do seu login? Depois Estabilidade para o stack trace e Desempenho para o tempo de inicialização.
Rode adb logcat durante uma inicialização a frio, filtrando pelo seu processo: adb logcat --pid=$(adb shell pidof -s com.your.package). Fique de olho na requisição que nunca volta. É a sua splash travada.
Confira o Crashlytics e o Play Console → Qualidade → Android vitals → Falhas e ANRs, filtrando pelo código de versão que você enviou. Se os dois estiverem vazios, seu problema nunca foi um travamento — volte à lista sobre o ambiente do revisor acima.
Percorra a sua própria ficha da loja. Abra cada captura, leia cada frase de funcionalidade e faça exatamente aquilo no app, no aparelho limpo, na ordem.

Sua ficha na loja é o roteiro de teste

Revisores não adivinham o que o seu app deveria fazer. Eles leem sua ficha e suas capturas de tela, e depois conferem. Isso transforma o seu próprio texto de marketing na especificação pela qual você é avaliado. A captura de uma funcionalidade que sai mês que vem é hoje uma funcionalidade quebrada. O mesmo vale para um bloco «Em breve», uma linha em Configurações que não abre nada e um link de suporte apontando para um 404. Corte a captura ou entregue a funcionalidade.

Reenviar ou recorrer?

Reenvie se você achou uma causa concreta e corrigiu: novo código de versão, Conteúdo do app atualizado, Enviar para revisão. Recorra só quando tiver certeza de que nada está quebrado e conseguir mostrar isso — você tem um recurso por medida de aplicação, e a resposta costuma chegar em cerca de 2 dias úteis.

Conselho direto: a maioria das discussões «não tem nada quebrado no meu app!!!» na comunidade do Play termina com o desenvolvedor achando uma tela de login ou um backend dormindo. Faça primeiro a rodada de 30 minutos. Se você recorrer e estiver errado, gastou seu único recurso e uma semana de receita.

De um jeito ou de outro, diga o que mudou. Os revisores do Google trabalham com a mesma linha única que você. Cole isto no formulário de recurso, ou no campo de instruções dos detalhes de login quando reenviar:

brokenFunctionality.template

A versão da Apple da mesma recusa

A Apple chama isso de Guideline 2.1 — Performance — App Completeness, e é o motivo de recusa mais citado por eles. Mesmas causas de fundo, outro console: a conta de demonstração vai em App Store Connect → seu app → Informações de revisão do app, com o botão «Login obrigatório» ligado, mais o campo Notas para tudo o que um estranho não conseguiria adivinhar. Uma diferença pesa muito na prática: a Apple normalmente diz qual tela falhou e anexa uma captura. O Google te dá uma linha. É essa assimetria que obrigou a existir a tabela de decodificação acima.

Os motivos de recusa mais comuns na App Store

O que podemos checar por você — e o que não podemos

Envie o .aab ou o .apk que você está prestes a submeter e lemos o manifesto dele. Das 24 verificações de Android da ferramenta, 10 rodam automaticamente, e quatro apontam direto para causas de Broken Functionality:

usesCleartextTraffic — uma URL base http:// que funciona na sua máquina e é bloqueada em silêncio em uma build de release no Android 9 ou superior.
android:debuggable — uma build de debug publicada por acidente, o que por si só já é recusa imediata.
Activity MAIN/LAUNCHER — não ter ponto de entrada executável é, literalmente, «app doesn't load».
targetSdkVersion e minSdkVersion — a incompatibilidade por trás de «app doesn't install» em um aparelho de revisão.

As outras 14 são as perguntas que nenhum parser responde por você, e três delas são exatamente esta política: toda funcionalidade está operante, sem espaços reservados nem links quebrados; você testou em aparelhos reais e olhou o Android vitals; e o app faz algo real além de embrulhar um site.

O que não conseguimos fazer, sem rodeios: não executamos seu app. Não temos como dizer que seu backend está dormindo, que sua conta de demonstração venceu na terça passada ou que sua chave do Maps está presa ao SHA-1 errado. Nenhuma ferramenta que lê um binário consegue. É para isso que serve a rodada de 30 minutos.

Perguntas frequentes

O que significa «Your app contains content that isn't compliant with the Broken Functionality policy»?

Significa que o revisor do Google abriu seu app e ele travou, congelou ou nunca ficou utilizável. É um veredito sobre comportamento, não uma revisão de código. A linha curta logo abaixo — por exemplo «App installs, but doesn't load» — é o único diagnóstico que você tem, então comece por ela.

Meu app funciona perfeitamente. Por que o Google diz que está quebrado?

Porque o revisor não está no seu aparelho nem na sua rede. Uma tela de login sem credenciais de teste, uma API restrita ao IP do seu escritório, uma URL de staging na build de release ou um backend dormindo produzem, todos, um app que falha para ele e funciona para você. Nada disso aparece em relatórios de falha.

Preciso subir um .aab novo para corrigir uma recusa por Broken Functionality?

Nem sempre. Se a causa foram detalhes de login ausentes ou vencidos, você os atualiza em Política e programas → Conteúdo do app → Detalhes de login e clica em Enviar para revisão na página Visão geral da publicação — a build existente é reenviada. Se a causa está no app, é preciso um novo código de versão.

O relatório de pré-lançamento pega problemas de Broken Functionality?

Em parte. O teste Robo encontra travamentos e ANRs em aparelhos reais, mas não faz login por uma tela em WebView nem controla elementos desenhados em OpenGL. Se o seu app tem login em WebView, o relatório vai parecer limpo cobrindo apenas a tela de login. Veja a aba Capturas de tela para saber até onde o robô realmente chegou.

Posso recorrer de uma recusa por Broken Functionality?

Pode — um recurso por medida de aplicação, com resposta normalmente em cerca de 2 dias úteis. Só recorra se tiver reproduzido as condições do revisor em um aparelho limpo e realmente não tiver achado nada. Caso contrário, corrija a causa, suba o código de versão e reenvie; é mais rápido do que perder o recurso.

Quanto tempo leva a aprovação depois de reenviar?

O Google não garante prazo, e varia de um dia a algumas semanas conforme a conta e o histórico de violações. Planeje esse reenvio como se fosse o último: uma segunda recusa por Broken Functionality no mesmo app custa muito mais tempo do que teria custado a rodada de diagnóstico de 30 minutos.

Fontes

Verifique sua build antes de enviar

Passe seu .ipa ou .apk pelo App Review Checker e pegue esses problemas em segundos.

Verificar um app