Políticas do Google Play em 2026: lista antes de publicar

Comece pela conta e pelas datas obrigatórias

Os problemas mais incómodos no Google Play nem sempre começam com uma infração evidente. A versão está pronta, as imagens foram aprovadas e, de repente, alguém percebe que a Segurança dos dados não coincide com um SDK ou que a conta de teste pede um código ao qual o revisor não tem acesso. Um pequeno desencontro obriga várias equipas a voltar atrás.

Por isso, as políticas do Google Play não são apenas burocracia no fim do projeto. Podem exigir alterações reais: um caminho para eliminar a conta, um pedido de localização mais limitado, uma forma específica de vender serviços digitais ou ferramentas para denunciar conteúdos. Descobrir tudo isto na semana do lançamento significa reabrir desenvolvimento, texto jurídico e materiais da loja ao mesmo tempo.

Esta lista foi revista em 8 de setembro de 2026. Como o Google atualiza regras e prazos, abra as fontes no final da página antes de cada envio. O processo recomendado permanece válido: documente o comportamento da versão assinada e faça com que todas as declarações reflitam essa versão.

Uma conta pessoal nova pode não ter acesso imediato à produção. Para contas criadas depois de 13 de novembro de 2023, o Google normalmente exige um teste fechado com pelo menos 12 participantes inscritos por 14 dias consecutivos. Depois, o proprietário solicita acesso à produção e responde sobre o teste realizado. Reunir instalações sem uso real não ajuda. Entregue tarefas, mantenha um canal de retorno e registre os problemas corrigidos.

A versão também tem uma data importante. A partir de 31 de agosto de 2026, as novas aplicações e atualizações para telemóveis e tablets precisam, em regra, de usar Android 16 / API 36 ou superior como destino. Wear OS e Android Automotive exigem API 35; Android TV e Android XR, API 34. As aplicações existentes têm uma regra própria de disponibilidade para novos utilizadores. Consulte a página atual da API de destino ao planear cada versão.

A próxima etapa da verificação de programadores Android começa em 30 de setembro de 2026, mas não é um prazo universal. O arranque regional abrange primeiro Brasil, Indonésia, Singapura e Tailândia, nas lojas participantes e em dispositivos certificados com Android 7 ou posterior. A expansão global está prevista para 2027. Confirme o estado do pacote no Play Console, sem presumir que o registo automático resolveu todas as pendências.

Use um registro único para todo o lançamento

Os conflitos aparecem quando cada área guarda uma versão diferente do produto. A equipa técnica conhece as permissões, o marketing escreve a descrição, outra pessoa publica a política e o titular da conta responde à Segurança dos dados sem consultar a versão final. Separadamente, tudo parece plausível; em conjunto, as peças deixam de encaixar.

Preferimos uma matriz curta, verificada na aplicação assinada e atribuída a uma pessoa responsável. Não precisa de se transformar num processo pesado:

Vincule esse registro ao candidato de lançamento. Se um SDK de anúncios ou medição for adicionado depois, as respostas precisam ser revisadas. Se um recurso for adiado, ele também deve sair da descrição e das capturas.

Segurança dos dados deve partir do código e dos SDKs

A política de privacidade traz uma explicação pública detalhada. Segurança dos dados apresenta uma declaração estruturada na loja. As duas precisam concordar, mas não devem ser preenchidas uma a partir da outra sem verificar o produto.

Mapeie o registo, os eventos de análise, os relatórios de falhas, os identificadores, a localização, os ficheiros, o apoio ao cliente e o estado dos pagamentos. Inclua serviços de atribuição, anúncios, mapas, chat, diagnóstico e qualquer biblioteca de terceiros. O programador responsável pela publicação responde também pelo comportamento destes componentes.

Registe a finalidade. Um e-mail usado no início de sessão não é igual ao mesmo e-mail enviado para uma plataforma de marketing. Indique se a informação sai do dispositivo, se a recolha é opcional, como ocorre a transmissão e como funciona a eliminação. Guardar esta lista com cada versão evita que a equipa tente reconstruir tudo meses depois.

O guia sobre a política de privacidade de uma aplicação aprofunda este alinhamento. Produtos de saúde, finanças, crianças ou identidade precisam também de uma análise jurídica específica para os mercados em que serão distribuídos.

A eliminação da conta tem de funcionar em todos os sistemas

Se uma pessoa consegue criar uma conta na app, o Google Play exige um percurso de eliminação dentro da aplicação e uma opção na web indicada no Play Console. Um endereço genérico de apoio, sem instruções claras, não substitui este processo.

Crie uma conta e percorra o processo de eliminação. A opção é fácil de encontrar? A página externa identifica a app e a empresa? Informa o que será eliminado, o que poderá ser mantido e durante quanto tempo? O backend remove ou anonimiza a autenticação, os ficheiros, o CRM, o apoio e as ferramentas de marketing?

Subscrições, pedidos em curso, comprovativos ou litígios podem exigir um tratamento específico. A decisão não deve ficar escondida no código. O produto e a assessoria definem o resultado correto; o desenvolvimento implementa a regra em todos os serviços.

Peça somente a permissão necessária

Compare o manifesto Android, os pedidos apresentados durante a utilização e as respostas do Play Console. Remova permissões deixadas por bibliotecas antigas ou funções canceladas. Para cada acesso sensível, a equipa deve explicar que ação visível para o utilizador depende dele.

Prefira recursos com escopo reduzido. Para anexar uma imagem, o seletor de fotos costuma ser melhor do que acesso amplo à galeria. Convidar um contato não significa ler a agenda inteira. A localização contínua pode fazer sentido durante uma entrega ativa, mas não para localizar uma loja uma única vez.

O Google anunciou novas políticas de contatos e localização precisa para o fim de outubro de 2026, além de verificações antes da análise. Projetos voltados ao Android 17 devem estudar com antecedência o Contact Picker e o botão de localização. Proteção de chaves, armazenamento e autorização no servidor estão no checklist de segurança Android.

Forneça acesso durável para a análise

As funções protegidas por início de sessão, subscrição, região ou perfil têm de ficar disponíveis para a equipa do Google. As credenciais devem ser reutilizáveis, funcionar a partir de qualquer local e permanecer ativas. Um código de utilização única, um período de teste expirado ou um servidor acessível apenas a partir da rede do escritório podem bloquear a avaliação.

Além do utilizador e da palavra-passe, escreva um roteiro curto em inglês: como entrar, escolher o perfil, abrir a função principal, aceder ao conteúdo pago e realizar uma operação de teste. Se a interface estiver em português, coloque entre parênteses os rótulos que aparecerão no ecrã.

Peça a uma pessoa fora do projeto que siga o roteiro em um aparelho limpo. Se ela precisar falar com o programador, a instrução ainda não é suficiente.

A página do Google Play deve provar cada promessa

A política de metadados se aplica a todas as traduções. Nome, descrição curta, texto completo, ícone, arte de destaque, capturas e vídeo precisam representar o produto disponível. Evite prêmios sem comprovação, funções planejadas como se estivessem prontas e repetição artificial de palavras-chave.

As capturas podem receber uma composição promocional, mas o ecrã apresentado tem de existir. Localize o texto dentro das imagens e verifique a moeda, as datas e as condições de pagamento. Consulte os requisitos das capturas no Google Play e a lista de localização da loja para organizar as variações.

Reveja cada frase como se tivesse de a demonstrar no telemóvel. A subscrição deixa o preço e o período claros antes da compra? Um serviço manual não parece instantâneo? Uma imagem não mostra uma função reservada para uma fase futura?

Preencha as declarações correspondentes ao modelo do app

O Play Console mostra questões diferentes conforme a aplicação: anúncios, público-alvo, classificação etária, notícias, saúde, finanças, ligação com governo e outras áreas sensíveis. Não escolha uma categoria mais simples apenas para evitar perguntas. Funções, conteúdo e público real determinam a resposta.

As aplicações com conteúdo de utilizadores precisam de termos, denúncia, bloqueio e uma rotina efetiva de moderação. Se houver crianças entre o público, aplicam-se as regras para famílias. Saúde e finanças exigem especial cuidado com alegações. Para vender conteúdos ou funções digitais, verifique a política de pagamentos e as exceções aplicáveis antes de criar uma cobrança externa.

Tudo isto faz parte do desenvolvimento. Um chat privado envolve denúncia, bloqueio, acesso do apoio e retenção. Uma subscrição exige restauro, cancelamento, estados de acesso e testes de compra. O questionário de estimativa da Appfyl ajuda a revelar estas dependências antes do planeamento.

Teste o pacote assinado que será enviado

Use o app bundle assinado, ligado a uma infraestrutura semelhante à de produção. Teste uma instalação limpa, atualização, registo, recuperação, eliminação, recusa de permissões, rede fraca, compra ou reserva principal, ligações profundas e todos os perfis entregues ao Google. Confirme que um pagamento de teste não pode gerar uma cobrança real por engano.

As verificações prévias do Play Console são úteis, mas abrangem apenas parte das políticas. Para estabilidade, falhas, dispositivos e experiência, complete-as com a lista de qualidade do Google Play e a lista de testes da aplicação.

As últimas 48 horas antes do envio

Dois dias antes, pare de adicionar SDK opcionais e novas promessas. No primeiro dia, o desenvolvimento confirma o pacote, a assinatura, a API, as permissões, as bibliotecas, a eliminação e o acesso de demonstração. O produto revê compras, perfis, moderação e declarações especiais. O marketing compara os textos e as imagens com a app instalada.

No segundo dia, uma pessoa independente executa o roteiro destinado ao Google. O responsável abre todos os links públicos, compara a Segurança dos dados com o inventário de SDK, guarda uma cópia das declarações e verifica que a empresa mantém o controlo da conta.

Inclua margem no calendário, porque o prazo de análise não é garantido. A lista de lançamento acrescenta análise, apoio e acompanhamento da primeira semana. Se a app já foi recusada, siga o guia para corrigir rejeições antes de a reenviar.

Um exemplo de registo de preparação

Para uma aplicação fictícia de reservas, indique a compilação, o nome do pacote e a data do teste. Registe um problema concreto: «A eliminação de conta está nas definições, mas a ligação pública abre a página de início de sessão». Atribua a correção ao responsável pelo site. O ponto continua aberto até as informações necessárias estarem disponíveis sem conta. Uma caixa genérica de «privacidade concluída» esconderia a falha.

Faça o mesmo com o acesso da equipa de revisão. Registe que uma instalação limpa permite abrir uma aula paga de demonstração com a conta indicada, sem código descartável nem cobrança real. Se uma alteração do servidor inutilizar a conta, a prova anterior deixa de confirmar a preparação. Repita o teste afetado e guarde o resultado.

A lista apoia a decisão de envio, mas não garante aprovação. Mantenha o identificador da compilação junto dos problemas abertos. Ao discutir o projeto com a Appfyl, esclareça quem conserva estas verificações e as atualiza depois de alterações.

Perguntas frequentes