A URL de política de privacidade de que um app Android precisa
Onde a URL entra, o que a política precisa cobrir e a armadilha dos SDKs que pega desenvolvedores convictos de que o app não coleta nada.
As duas lojas exigem uma URL de política de privacidade publicamente acessível que carregue sem login. No Google Play ela fica em App content → Privacy policy; na Apple é um campo no App Store Connect. A parte difícil não é a URL, e sim o conteúdo: ele precisa cobrir o que cada SDK do seu build coleta.
Resolva isso em poucos minutos
A AppFoyer hospeda as páginas de que este guia trata — política de privacidade, termos, suporte, exclusão de conta e app-ads.txt — em um subdomínio próprio, sem que você precise de domínio ou servidor. Um app é grátis, e nada que uma loja exige jamais fica atrás de um paywall.
Verificado em 19 de setembro de 2026. As políticas das lojas mudam, às vezes sem aviso. Tudo abaixo tem link para a documentação oficial, e é aquela página — não esta — que tem a palavra final. Se as duas divergirem, vale o que a loja diz. Este guia foi traduzido do inglês; as citações da documentação das lojas são mantidas no inglês original.
As duas lojas querem uma URL publicamente acessível para a sua política de privacidade, e as duas a verificam. No Google Play, a política de Dados do usuário diz isso com todas as letras — “all apps must post a privacy policy link in the designated field within Play Console, and a privacy policy link or text within the app itself” (todos os apps devem publicar um link de política de privacidade no campo designado do Play Console e um link ou texto da política de privacidade dentro do próprio app) — e esse campo fica em App content → Privacy policy (Conteúdo do app → Política de privacidade). Do lado da Apple, é um campo obrigatório no App Store Connect. A página precisa carregar sem login, nomear o seu app e a sua empresa, descrever o que o app e tudo dentro dele coleta, e continuar funcionando meses depois — uma página da loja é verificada mais de uma vez.
O requisito não é difícil. O que pega as pessoas é o terceiro item dessa lista, e ele vale o resto desta página.
“Mas o meu app não coleta nada”
Essa é a suposição que custa uma semana.
O seu código pode não coletar nada. Suas dependências quase certamente coletam. Um relator de falhas envia identificadores do dispositivo e stack traces. Um SDK de analytics envia eventos e um ID de publicidade. Um SDK de anúncios envia bastante coisa. Uma biblioteca de push registra um token que, por definição, está ligado a um dispositivo.
Então a pergunta honesta não é “o que eu coleto”, e sim “o que tudo no meu build coleta”. Abra o seu arquivo de dependências e percorra linha por linha — essa lista é a substância da sua política de privacidade, e é com ela que o revisor compara suas respostas de Data safety.
Quando as duas divergem, a loja acredita no SDK.
O que a política precisa cobrir
No mínimo, em linguagem que uma pessoa consiga ler:
- O que é coletado — categorias, não um schema de banco de dados.
- Por quê — a finalidade de cada categoria.
- Quem mais vê os dados — nomeie os terceiros. É aqui que entra a sua lista de SDKs.
- Por quanto tempo são guardados.
- Como entrar em contato com você, e como pedir a exclusão.
Se você tem usuários na UE, no Reino Unido, na Califórnia ou no Brasil, cada regime espera ver coisas específicas. Esta página não tem como dizer quais se aplicam a você — isso realmente depende dos seus usuários e do seu negócio, e vale uma hora de um advogado se houver algo incomum no seu app.
Coisas práticas que levam à rejeição
- Uma URL que exige login, ou que está bloqueada por região.
- Um PDF ou um Google Doc. Às vezes aceito, muitas vezes não, e passa impressão de improviso.
- Uma política que nomeia outro app ou outra empresa — o sinal clássico de copiar e colar. Os revisores percebem.
- Uma política que contradiz o seu formulário de Data safety. Os dois são lidos juntos.
- Um link quebrado. Seis meses depois do lançamento, o host gratuito que você usou não existe mais.
Precisa custar dinheiro?
Não. Uma política de privacidade é texto em uma página; o que custa dinheiro é um domínio, um lugar para hospedá-la que ainda vá existir no ano que vem e o tempo de escrever algo que corresponda ao seu app de verdade.
Desconfie de geradores cobrados por app por mês. O que você está alugando é um modelo — verifique o que acontece com a sua URL quando você para de pagar, porque uma URL de privacidade que sai do ar enquanto está impressa em uma página da loja publicada é um problema do qual você vai saber pela loja, não pelo fornecedor.
O que a AppFoyer faz aqui
Geramos a política a partir dos SDKs encontrados nos seus arquivos de build — com um agente de código que lê o repositório, ou a partir de um formulário curto — e a hospedamos em um subdomínio próprio. O checklist continua avisando você até que o placeholder onde seus terceiros são nomeados seja substituído, porque é essa a parte que o revisor de fato lê.
Os modelos são um ponto de partida, não aconselhamento jurídico, e toda página gerada diz isso.
As fontes oficiais
- Política de Dados do usuário — Ajuda do Google Play. A citação acima é desta página.
- Requisitos da política de privacidade — Ajuda do Google Play, sobre onde fica o campo
- Diretrizes de revisão da App Store, seção 5.1 — Apple