Requisitos de publicação no Google Play para novos desenvolvedores em 2026

O Google Play não concede uma aprovação única. Ele prende uma versão atrás de uma sequência de barreiras independentes, e cada barreira tem a própria regra de aplicabilidade, ou seja, boa parte do que vem a seguir não vai valer para você.

Todo requisito abaixo traz as mesmas quatro informações: a quem ele se aplica, o que você faz, o que comprova que ele está concluído e a página oficial de onde ele vem. Onde as próprias páginas do Google se contradizem, e aqui isso acontece em dois pontos, você recebe as duas versões em vez do nosso palpite.

Os requisitos de publicação no Google Play em resumo

Todas as barreiras estão abaixo, com a regra que decide se cada uma chega até você e o item do Play Console que comprova a conclusão dela. As linhas marcadas como condicional são puladas por completo por alguns desenvolvedores.

A ordem em que isso realmente acontece

São oito etapas, e a ordem não é uma preferência: três delas são pré-requisitos rígidos da etapa seguinte.

1. Escolher e verificar sua conta de desenvolvedor Tipo de conta, a taxa, a identidade e a verificação de dispositivo onde o Console pedir.
2. Criar o app e preparar um build em conformidade Registro do app e ID do aplicativo, App Bundle e assinatura, API de destino, verificações prévias do build.
3. Verificar o registro de desenvolvedor Android Uma checagem de status no Play Console depois que o app e o pacote já existem.
4. Completar a ficha da loja e os recursos Limites de texto, imagens obrigatórias, a máscara do ícone, declarações de recursos gerados por IA.
5. Completar o Conteúdo do app e o acesso dos revisores Privacidade, Segurança dos dados, exclusão, classificação, público-alvo, anúncios, as duas declarações universais e as instruções de login.
6. Rodar o teste fechado qualificador 12 testadores participando por 14 dias consecutivos. Apenas contas pessoais criadas depois de 13 de novembro de 2023 precisam disso.
7. Solicitar o acesso de produção O questionário em três partes sobre o seu teste, o seu app e a prontidão dele.
8. Enviar e publicar a versão de produção Países, preços, o bundle, as notas da versão, o envio para análise e, então, a publicação.

1. Escolha e verifique sua conta de desenvolvedor

Você precisa de uma Conta do Google com a verificação em duas etapas ativada, e aceita o Contrato de Distribuição para Desenvolvedores e os Termos de Serviço do Play Console no cadastro. Três coisas então precisam ser liberadas antes de você publicar: a taxa, a sua identidade e, onde o Console mostrar, uma verificação de dispositivo.

O que a taxa de US$ 25 é, e o que ela não é

A taxa é paga somente com cartão de crédito ou débito. Os tipos de cartão aceitos variam conforme o local, e o Google diz de forma explícita que cartões pré-pagos não são aceitos.

Pessoal ou de organização, e quando a escolha já está feita

Faça primeiro a pergunta da categoria, porque para alguns apps não há escolha nenhuma.

Se nenhuma dessas categorias alcança você, a escolha é sua. Os dois tipos podem publicar e monetizar, então parte da diferença está só no que o Google verifica a seu respeito, mas não é apenas papelada. Uma conta pessoal criada depois de 13 de novembro de 2023 também deve um teste fechado qualificador, o item fixo mais longo deste guia. Comparação completa: contas pessoais e de organização.

O que a verificação da conta exige, e por que o prazo varia

O Google verifica quem você é no nível da conta antes de você poder publicar. Uma conta pessoal apresenta um documento de identidade oficial emitido pelo governo; uma conta de organização apresenta os dados dela junto com um documento desses. O que é pedido pode depender do que o seu perfil de pagamentos já verifica, e é por isso que duas pessoas seguindo o mesmo guia recebem pedidos diferentes. Verificar sua identidade de desenvolvedor

O Google não publica nenhum prazo garantido de processamento para a análise de identidade da conta no Play, e o famoso “até 5 dias” não é um deles: esse número vem da documentação de pagamentos do Google, não da página de identidade do Play. Conclua as tarefas que o Console mostrar e reserve tempo para checagens extras de documentos. A verificação da forma de pagamento é outra coisa ainda: um exame de comerciante ligado a receber pagamentos, não uma etapa que todo desenvolvedor de app gratuito precisa iniciar. Informações da conta e verificações de comerciante

Concluído quando: O Play Console para de mostrar a tarefa de verificação de identidade da sua conta. Trate enviado e aprovado como dois estados diferentes: um documento enviado não libera a publicação.

Verificação de dispositivo: a barreira que a maioria dos guias esquece

Novas contas pessoais de desenvolvedor têm uma tarefa de dispositivo separada. Você comprova acesso a um aparelho Android físico, sem root e com Android 10 ou mais recente, usando o app Play Console no celular e conectado como proprietário da conta. Requisitos de verificação de dispositivo

O que ela não é: a checagem de identidade, o teste fechado qualificador ou uma regra sobre os seus testadores. Nada aqui diz que as 12 pessoas do seu teste fechado precisam dessa especificação de aparelho. É um item próprio na página inicial do Console, e um emulador não resolve.

Concluído quando: A tarefa de verificação de dispositivo some da página inicial do seu Play Console.

Mudar o tipo de conta depois

Dá para converter uma conta pessoal de desenvolvedor em conta de organização pelo fluxo de verificação do Google: verifique o site da organização, crie ou selecione e verifique o perfil de pagamentos dela e conclua a mudança dentro da conta que já existe. O Google recomenda esperar pelo menos 72 horas depois da conversão antes de enviar apps novos. O caminho contrário, de organização para pessoal, esse sim exige uma conta nova. Conversão do tipo de conta

2. Crie seu app e prepare um build em conformidade

São duas metades: o registro do app que você cria no Play Console e o artefato que você envia para dentro dele. Uma decisão aqui acompanha o app pela vida inteira, então vale trinta segundos agora.

As decisões que são permanentes

Criar o app no Play Console define o nome dele, o idioma padrão, o tipo app ou jogo e se é gratuito ou pago. O ID do aplicativo é outra coisa: ele fica na configuração do seu build, não naquele formulário do Console, e os dois se encontram na hora do envio. Então confira o ID do aplicativo no seu build antes de enviá-lo, em vez de supor que um registro vazio no Console já o deixou definido. Criar e configurar seu appID do aplicativo

O Android App Bundle e os dois papéis de assinatura

Para um app público novo e comum, o Google Play aceita o Android App Bundle (.aab) em vez de um APK, e o app usa o Play App Signing. Vale enunciar esse escopo uma vez, em vez de tratá-lo como algo absoluto: apps legados que se qualificam ainda têm fluxos com APK, todos os apps de Android TV exigem bundles desde junho de 2023, e a distribuição corporativa de apps particulares é diferente de novo. App BundlesApps particulares

O Play App Signing separa dois papéis, o que não é o mesmo que duas chaves físicas na sua mão. A chave de assinatura do app é gerenciada pelo Google e assina o que os usuários instalam. A chave de upload assina o seu bundle antes do envio, para o Google saber que ele veio de você. Os dois papéis podem usar a mesma chave ou chaves separadas; uma chave de upload separada é a configuração recomendada, porque dá para redefini-la se você a perder. Assinar seu app

Nível da API de destino, por formato de dispositivo

Este é o requisito com mais chance de bloquear um envio de cara, e não é um número só: ele varia conforme o que você está enviando.

O Google documenta janelas de prorrogação que vão até 1º de novembro de 2026 em algumas circunstâncias, mas a elegibilidade é decidida para o seu app específico dentro do Play Console. Requisitos da API de destino Os detalhes da migração estão no guia da API de destino.

Verificações prévias: o que pode rejeitar um bundle aparentemente válido

Duas checagens pegam projetos que, de resto, parecem prontos. As duas são condicionais: se nenhuma alcança o seu app, pule esta parte e siga em frente.

Bibliotecas nativas: 64 bits e tamanho de página de 16 KB

Se o seu app leva código nativo, direto, por meio de um SDK ou gerado por um construtor de apps, confira nele o suporte a 64 bits e a compatibilidade com o tamanho de página de 16 KB, e teste-o em um ambiente de 16 KB. Apps escritos só em Java ou Kotlin, dependências incluídas, já são compatíveis com o tamanho de página relevante. Confira o bundle que você de fato envia: uma dependência pode reintroduzir uma biblioteca de 32 bits ou alinhada em 4 KB sem nenhuma mudança da sua parte. Tamanhos de página de 16 KB64 bits

Versão da Play Billing Library

Se, e somente se, o seu app integra o Play Billing, novos envios normalmente precisam da Billing Library na versão 8 ou mais recente. O prazo comum da versão 7 foi 31 de agosto de 2026, e uma prorrogação aplicável pode ir até 1º de novembro de 2026. Nada disso alcança um app sem essa integração, e nada disso significa que apps mais antigos já instalados param de funcionar. Cronograma de descontinuação do Billing

Concluído quando: Um .aab assinado é enviado sem erro de API de destino nem de formato, o código da versão é maior que qualquer um que você já tenha enviado e, se o app leva código nativo, as suas checagens de compatibilidade e uma execução em ambiente de 16 KB passam as duas. O Play Console validar um envio não é o mesmo que as suas dependências terem sido testadas; resolva os problemas bloqueantes e leia os avisos.

3. Verifique o registro de desenvolvedor Android no Play Console

Esta etapa vem depois da anterior porque precisa que o app exista: o registro vincula um app, com o nome do pacote e a impressão digital da chave de assinatura, a uma identidade de desenvolvedor verificada, em todo o ecossistema Android e não só no Google Play. É coisa diferente da checagem de identidade no nível da conta, feita na etapa 1, que prova quem você é para poder ter uma conta.

Para quem publica no Play, a pergunta prática é estreita: o seu app está registrado? Confira o status dele na página Verificação de desenvolvedor Android do Play Console. O Google tenta o registro automático e reaproveita a verificação de identidade que você já concluiu, então, para a maioria de quem publica no Play, isto é uma checagem de status e não uma tarefa: você não precisa de uma conta separada no Android Developer Console e não repete a verificação de identidade. Confirme o registro e conclua qualquer ação pendente que ele mostrar. Registrar nomes de pacote do Play

A partir de 30 de setembro de 2026 os apps que continuarem sem registro correm risco de remoção do Google Play no mundo todo, algo fácil de deixar passar, porque a maior parte da cobertura dessa data descreve só a fase de instalação em quatro países, que é outra parte do mesmo programa. Duas coisas que você pode ignorar: a conta gratuita de Distribuição Limitada é para entusiastas que entregam para um punhado de aparelhos e não é uma rota gratuita para o Google Play; e o piso de versão do Android no verificador do aparelho está documentado de forma inconsistente (o FAQ do Android Developers diz 7 ou mais recente, a Ajuda do Android diz 8 ou mais recente), o que é um conflito não resolvido entre duas páginas do Google, e não um requisito sobre o qual agir. Ajuda do Android

Concluído quando: A página Verificação de desenvolvedor Android do Play Console mostra o app como registrado, sem nenhuma ação pendente listada para ele.

4. Complete a ficha da loja e os recursos

A ficha é o que usuários e revisores veem primeiro, e ela tem limites rígidos que travam o salvamento. A linha útil de traçar é entre o que o Google exige para publicar e o que ele recomenda para ganhar destaque; as duas coisas estão separadas abaixo.

Exigido para publicar

Google Play Console · captura real

Recomendado, mas não é barreira para publicar

As orientações do Google sobre recursos de visualização também descrevem o que torna uma ficha elegível para as superfícies de formato grande e de recomendação: mais capturas de tela, resoluções maiores, conjuntos para as classes de aparelho em que você quer aparecer. Deixar de fazer qualquer uma dessas coisas não bloqueia uma versão. Fichas de Wear OS, TV e XR têm regras próprias de recursos por cima. Recursos de visualização

A máscara de cantos do ícone

Você envia um ícone quadrado inteiro e o Google Play aplica uma máscara dinâmica de cantos com raio equivalente a 30% do tamanho do ícone, de modo que tudo que estiver perto de um canto é cortado no resultado exibido. Esta é a especificação atual, e não, como se repete por aí, uma mudança introduzida em 2026. A data de modificação de uma página de origem não é prova de quando uma regra passou a valer. Especificações de design do ícone

Declarações de IA para recursos da loja gerados

Se você gera ou edita imagens, vídeo ou material promocional da ficha com IA, o Play Console agora inclui autodeclarações por recurso nos fluxos de criação de conteúdo, com rótulos aplicados aos recursos que caem no escopo regulatório aplicável. A página de ajuda do Google não indica data de início nem uma lista exaustiva das regras que ela cobre, então não vamos inventar nem uma coisa nem outra. Isto é sobre recursos da loja, algo separado da política que rege o que um app generativo produz para os usuários. Declarar conteúdo gerado por IA

Regras de metadados que fazem fichas serem rejeitadas

As orientações do Google para a ficha são rígidas quanto a linguagem promocional nos campos que aparecem nos resultados de busca e nas prateleiras: o título, o ícone, o nome do desenvolvedor e a descrição breve.

Concluído quando: A ficha principal da loja é salva sem erro de recurso faltando, e as imagens que você enviou continuam legíveis depois da máscara de cantos.

5. Complete o Conteúdo do app e o acesso dos revisores

Conteúdo do app é a parte que quem publica pela primeira vez subestima, porque nada ali é engenharia e tudo ali bloqueia. É uma pilha de declarações, e uma resposta incompleta ou imprecisa é uma das razões mais comuns para um lançamento travar.

Política de privacidade: todo app, em dois lugares

Todo app precisa de uma política de privacidade, e não só os apps voltados a crianças, que é como isso costuma ser descrito. Informe o link no Play Console e um link ou o texto da política dentro do app. Use uma URL ativa, pública e sem bloqueio geográfico, não um PDF. Um app que não coleta dado nenhum também precisa de uma, e “não coletamos nada” não é uma política: ela ainda tem de identificar o app e o desenvolvedor, dar um contato de privacidade e descrever como qualquer dado que ela toque é tratado e por quanto tempo fica guardado. Política de dados do usuário

Segurança dos dados

Todo app nas faixas de teste fechado, teste aberto ou produção preenche o formulário de Segurança dos dados. Apps que só rodam na faixa de teste interno estão isentos, e esse é um motivo genuíno para usar o teste interno cedo. Um app que não coleta nada também preenche o formulário e diz isso. Segurança dos dados

Declare o que o seu app de fato coleta e compartilha, incluindo o que os seus SDKs fazem em seu nome. É essa a parte que mais sai errada: um SDK de analytics, de anúncios ou de relatório de falhas coleta dados tenha você escrito aquele código ou não, e a declaração é sua. Leia a documentação de cada SDK em vez de supor que um fornecedor inteiro se comporta de um jeito só.

Exclusão de conta e de dados

Se os usuários podem criar uma conta no seu app, você precisa deixar que eles peçam a exclusão de dentro do app e de fora dele, por uma URL pública acessível, e excluir a conta precisa excluir os dados associados. Onde a lei ou uma razão legítima de negócio obriga você a guardar algo, informe isso.

Todo o resto no Conteúdo do app

Além de privacidade, Segurança dos dados, exclusão e Acesso ao app, vistos acima, restam estes. Dois deles pegam as pessoas de surpresa porque o nome soa condicional: as declarações de apps de saúde e de recursos financeiros são exigidas de um app público comum nas faixas de teste fechado, teste aberto ou produção mesmo quando ele não tem nenhum dos dois tipos de recurso. As duas têm uma resposta para quem não tem esses recursos, e preencher uma delas não faz regras de licenciamento médico ou financeiro passarem a valer para você. Declaração de apps de saúdeDeclaração de recursos financeiros

Google Play Console · captura real

Dê aos revisores um acesso que funcione

Se qualquer parte do seu app fica atrás de um login ou de outra barreira, preencha o Acesso ao app. O Play Console aceita até cinco conjuntos de instruções: conjuntos de instruções, não necessariamente cinco conjuntos de credenciais, o que importa se você tem um login só e vários caminhos protegidos. Preparar seu app para análise

Antes de enviar, confira se as credenciais ainda funcionam e se todo recurso protegido é alcançável por alguém que não seja você. Contas vencidas, códigos de uso único que chegam no seu celular e recursos que só abrem para uma conta interna são as falhas de sempre.

Concluído quando: O Conteúdo do app não mostra nenhuma tarefa pendente, e alguém que não seja você consegue entrar com exatamente o que você escreveu no Acesso ao app.

Declarações específicas de categoria

Além dos formulários acima, algumas políticas se prendem ao que o app de fato faz. Estas são condicionais de verdade:

• Apps de saúde, além da declaração. Se o app realmente tem recursos de saúde, a política de Conteúdo e serviços de saúde acrescenta rotulagem de dispositivo médico e a exigência de um aviso legal para apps de saúde não regulamentados, e apps de saúde dos tipos especificados exigem conta de organização. Conteúdo e serviços de saúde
• Apps de IA generativa. Impeça saídas proibidas e dê aos usuários uma forma de denunciar ou sinalizar isso dentro do app. Aqui a questão é o que o app produz, algo separado das declarações de recursos da loja acima, e não uma regra de que todo app assistido por IA leva um rótulo. Política de conteúdo gerado por IA
• Permissões de fotos e vídeos. Peça acesso amplo apenas onde um recurso central precisa dele; caso contrário, use o seletor de fotos do sistema.
• Localização e contatos. Os dois têm requisitos de escopo mínimo a caminho, com datas reais e um escopo estreito: veja prazos e mudanças condicionais.
• Outras categorias. Notícias e revistas, serviços financeiros, apps governamentais e outros têm, cada um, uma página de política com link no Conteúdo do app.

6. Conclua o teste fechado obrigatório, se ele se aplica a você

Aplica-se a: contas pessoais de desenvolvedor criadas depois de 13 de novembro de 2023. Contas de organização e contas pessoais criadas antes dessa data não têm esse requisito, então, se é o seu caso, pule para o envio da versão.

A regra é curta: rode um teste fechado com pelo menos 12 testadores participando ao longo dos 14 dias consecutivos que antecedem a sua solicitação de acesso de produção. A redução de 20 para 12 testadores entrou em vigor em 11 de dezembro de 2024 e manteve os mesmos 14 dias. Requisitos de testeA mudança de 20 para 12

Google Play Console · captura real

Três faixas, e só uma delas conta

O teste interno parece o atalho óbvio e é genuinamente útil, só que não para isto.

O Google avalia duas coisas: a sua contagem de testadores e o engajamento deles. Entre os próprios exemplos que ele dá de motivo para pedir mais testes estão testadores que não se engajaram com o app durante o teste, então 12 nomes numa lista não são o requisito. O que o Google não publica é qualquer regra sobre minutos por dia ou sessões: se você leu um número diário específico, ele não veio do Google, e o seu teste não deve ser planejado em torno dele.

Como de fato atender a isso

Todo outro requisito aqui é papelada ou engenharia que você controla. Este precisa de 12 pessoas reais, em aparelhos Android reais, que entrem no teste e continuem participando por 14 dias sem interrupção.

Concluído quando: O Play Console mostra 12 ou mais testadores participando e o teste fechado rodando por pelo menos 14 dias consecutivos, e a ação Solicitar acesso de produção fica disponível no Painel.

7. Solicite o acesso de produção, se for necessário

Aplica-se a: as mesmas contas do teste fechado, ou seja, contas pessoais criadas depois de 13 de novembro de 2023. Todos os demais vão direto para a versão.

Atender aos critérios do teste fechado não leva você à produção por si só. Você faz a solicitação no painel do Play Console e responde a um questionário. Por aí ele é descrito como um formulário fixo de dez perguntas; o Google muda a redação com o tempo, então guarde na cabeça três assuntos em vez disso.

Escreva a partir do teste que você realmente rodou. Nenhuma formulação garante a aprovação; o que ajuda é detalhe concreto sobre testes reais e mudanças reais. Respostas genéricas são um caminho conhecido para receber um pedido de mais testes. Exemplos comentados existem para mostrar como descrever o seu próprio teste, não para dar um roteiro pronto.

O Google diz que essa análise costuma levar sete dias ou menos, mas pode ocasionalmente demorar mais: planeje para sete e não trate isso como um teto. Prazos de análise do acesso de produção Se o acesso for recusado, o resultado comum é um pedido de mais testes e não uma rejeição, e o seu teste fechado não precisa parar enquanto você se prepara para solicitar de novo. O que fazer depois de “mais testes necessários”.

Concluído quando: O Play Console mostra o acesso de produção concedido. Nada antes desse ponto, nem um checklist completo, nem 14 dias inteiros, é a concessão em si; a decisão é do Google.

8. Envie e publique a versão de produção

O acesso de produção, onde ele se aplica, destrava a faixa, mas não publica nada. A versão é uma sequência à parte, e é onde as pessoas chegam com tudo completo e nada no ar. Preparar e lançar uma versão

1. Países e regiões Comece estreito e amplie depois, se quiser.
2. Preços Defina antes da primeira versão. Um app gratuito não pode virar pago depois com o mesmo nome de pacote.
3. Adicione o bundle da versão Selecione um bundle elegível que você já enviou para teste ou envie um build novo com código da versão maior. Levar um artefato já testado para a versão de produção não exige, por si só, compilá-lo de novo.
4. Nome da versão e notas da versão O nome é interno; as notas são o que os usuários veem nesta versão.
5. Leia os erros e os avisos O Console bloqueia nos erros e deixa os avisos passarem. Leia os dois: muitas vezes é o aviso que importa mais tarde.
6. Envie as alterações para análise Nada é submetido até você fazer isso. Uma página de versão pronta com alterações não enviadas é uma das formas mais silenciosas de um lançamento travar.
7. Acompanhe a análise e a publicação Em análise, pronto para publicar e no ar são três estados diferentes. Se a publicação gerenciada estiver disponível e ativada, as alterações aprovadas esperam até você escolher Publicar alterações: aprovação sozinha não é publicação. A ficha ainda pode levar um tempo para aparecer.

Concluído quando: A visão geral da publicação não mostra alterações não enviadas, e a versão de produção aparece como no ar, não apenas como aprovada. Onde a publicação gerenciada se aplica, esse último passo é você quem dispara. Publicação gerenciada e estados de publicação

Quanto tempo a publicação leva e o que pode se sobrepor

Duas análises ficam perto da linha de chegada e são separadas: a análise do acesso de produção, depois do seu questionário, e a análise da versão em si. O Google diz que a análise do acesso costuma levar sete dias ou menos, mas pode demorar mais, e que a análise do app também pode passar de sete dias em casos excepcionais. Nenhuma das duas tem teto de uma semana. Prazos de análise e publicação Números etapa por etapa: o guia de prazos de análise.

O que de fato bloqueia o quê

A maior parte disso pode ser feita em qualquer ordem. Quatro coisas não podem, e saber quais são as quatro é a diferença entre um lançamento de três semanas e um de seis.

Uma estimativa de planejamento, rotulada com todas as letras

De três a cinco semanas ou mais é um plano razoável para uma conta pessoal nova. Essa é a nossa estimativa de planejamento, não um nível de serviço do Google, e ela pressupõe um app já bastante construído, testadores que entram no teste sem demora e nenhum retrabalho grande. Construir o app não está dentro desse número, e uma rodada de retrabalho soma a ele.

O que o Console está dizendo, e onde resolver

Quase todo travamento aparece como uma de seis mensagens. Leia qual é a sua, em vez de reenviar e torcer.

Seu checklist de prontidão por etapa

Diga a ele que conta você tem e para onde está trabalhando. Ele separa três coisas que o checklist de sempre embaralha: o que você precisa agora, o que é exigido depois e o que não se aplica a você de jeito nenhum. É um acompanhamento para uso próprio: ele não enxerga o seu Play Console, e terminá-lo não é uma aprovação.

Prazos atuais e mudanças condicionais de política

Estes são os itens com data que podem mudar o que você constrói ou quando você lança. A maior parte deles não vai alcançar o seu app: leia a terceira coluna antes de agir sobre qualquer um.

Requisitos permanentes, sem prazo associado

Em vigor agora e fora de qualquer lista de “o que mudou”, e é por isso que eles pegam quem aprendeu este processo um ou dois anos atrás.

• Teste fechado: 12 testadores, 14 dias consecutivos, para contas pessoais criadas depois de 13 de novembro de 2023. O número caiu de 20 para 12 em 11 de dezembro de 2024.
• As transferências de propriedade de conta passam pelo fluxo de transferência do Play Console. A transferência direta de proprietário cobre organizações e contas pessoais que não monetizam; uma conta pessoal que monetiza usa outra rota, com conta nova e transferência de apps. Comprar, alugar ou vender contas por meio de terceiros é proibido. Transferir a propriedade de uma conta
• As contas de organização são obrigatórias para determinados apps de serviços financeiros, de saúde, com VpnService aprovado e governamentais.
• As permissões de fotos e vídeos já são exigidas hoje. Acesso amplo apenas onde um recurso central precisa dele; caso contrário, o seletor de fotos do sistema.

PolicyBytes: atualizações de política de abril de 2026

O time de Experiência do Desenvolvedor do Google fala sobre as políticas de contatos e de transferência de conta e sobre as atualizações de localização e de conteúdo com restrição de idade citadas acima. Opcional; a tabela tem a versão acionável.

YouTube

Como a PrimeTestLab ajuda no teste fechado

Sete das oito etapas são papelada e engenharia que você controla. Uma precisa de 12 pessoas reais, em aparelhos Android reais, participando e genuinamente ativas ao longo de 14 dias sem interrupção: é a etapa em que os desenvolvedores solo travam, e é a única parte que nós fazemos.

Você compartilha o link de participação do seu teste fechado. Nós cuidamos do convite, da confirmação de participação, do monitoramento diário de engajamento e da retenção completa dos 14 dias, substituindo quem sair. Qualquer idioma de app, com segmentação flexível de país.

Pacotes atuais

Garantia de reembolso · O teste costuma começar em 4-6 horas · Sem assinatura

Perguntas frequentes

O que fazer agora

De onde vem cada requisito

Toda afirmação relevante acima traz o link da fonte no ponto em que ela aparece; esta é a versão em diretório. As páginas de ajuda do Google em geral não têm data, então a data de modificação de uma página não é prova de quando uma política passou a valer.

O que mudou nesta revisão

11 de setembro de 2026

Reconstruído com base na documentação do Google conferida em 8 de setembro e revisado de novo depois de uma reauditoria dessa reconstrução. Corrigidos: o requisito de API de destino (agora uma matriz por formato de dispositivo); a ordem dos pré-requisitos do teste fechado; a conversão de conta pessoal para conta de organização; o prazo do D-U-N-S; o escopo do prazo de registro de 30 de setembro de 2026 e a rota dele, que é uma checagem de status no Play Console depois que o app existe; contatos e localização para 27 de janeiro de 2027 em API 37+, com implementação e declaração cumulativas; as especificações de ícone, capturas de tela e vídeo de prévia; o acesso dos revisores como cinco conjuntos de instruções; o ID do aplicativo como propriedade do build, e não do registro no Console; e a mecânica da versão, já que um bundle testado e elegível pode ser reaproveitado e a aprovação não é publicação onde vale a publicação gerenciada. Adicionados: a verificação de dispositivo, as etapas de criar o app e de lançar a versão, as verificações prévias de código nativo e do Play Billing, as declarações de IA para recursos da loja, as declarações de apps de saúde e de recursos financeiros (obrigatórias mesmo sem esses recursos), uma tabela de bloqueios e uma fonte ao lado de cada afirmação relevante. Removidos por falta de sustentação: a data de 28 de janeiro de 2026 para a migração de contas de saúde, o mito dos “cinco dias” da identidade, a explicação do ID de desenvolvedor Android de abril de 2025, o teto de 1 MB da imagem de destaque e o ranking de “rejeição evitável nº 1”. O checklist de prontidão foi reconstruído duas vezes: agora ele separa “exigido depois” de “não se aplica”, e não lê mais um trabalho enviado como concluído.

24 de junho de 2026

Primeira publicação.