Ir para o conteúdo

Guia completo 2026

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

Tudo o que um desenvolvedor Android iniciante precisa fazer para colocar um app no ar no Google Play neste ano, na ordem exata em que acontece. A taxa de US$ 25, verificação de identidade e Android Developer Verification, o Android App Bundle e o target API, a ficha da loja, as declarações de conteúdo do app, o teste fechado com 12 testadores e a análise de produção.

$25 Taxa única
12 / 14 Testadores / dias
API 36 A partir de 31 de ago. 2026
99,9% Taxa de sucesso PTL
Requisitos de publicação no Google Play para novos desenvolvedores em 2026: conta de desenvolvedor e taxa de US$ 25, verificação de identidade e Android Developer Verification, Android App Bundle e API 36, ficha da loja, declarações de conteúdo e o teste fechado de 12 testadores por 14 dias
O caminho até a produção, na ordem 7 etapas
Etapa 1 Conta Taxa de US$ 25
Etapa 2 Identidade Verificar você
Etapa 3 Build AAB + API
Etapa 4 Listagem + conteúdo
Etapa 5 Teste fechado 12 / 14 dias
Etapa 6 Produção ~7 dias de análise
Etapa 7 No ar Revisão do app

A etapa destacada (teste fechado) é a que uma conta pessoal não pode pular, e a que mais trava quem está publicando pela primeira vez.

Resposta rápida

Para publicar seu primeiro app no Google Play em 2026 você precisa, nesta ordem: criar uma conta de desenvolvedor (taxa de inscrição única de US$ 25), passar pela verificação de identidade, gerar um Android App Bundle com target de pelo menos API 35 hoje (API 36 a partir de 31 de agosto de 2026), completar a ficha da loja e as declarações de conteúdo do app e, para contas pessoais criadas após 13 de novembro de 2023, rodar um teste fechado (closed testing) de 14 dias com no mínimo 12 testadores participando antes de solicitar o acesso de produção (análise em geral de ~7 dias) e a revisão final do app. Duas grandes mudanças em 2026: o piso do target API sobe para API 36 em 31 de agosto, e o novo programa Android Developer Verification começa a ser aplicado em 30 de setembro de 2026. O único passo que você não automatiza sozinho é o teste fechado com 12 testadores. É exatamente o que a PrimeTestLab resolve, a partir de $19.99.

Publicar no Google Play já foi "pagar US$ 25, enviar um APK, pronto". Em 2026 é uma sequência de portões: conta, identidade, uma segunda camada de Android Developer Verification, formato de build, listagem, um bloco de declarações de política, um teste fechado obrigatório e duas análises separadas. Pule um e o app fica no limbo. Este guia percorre cada requisito na ordem em que você realmente encontra, marca as 5+ maiores mudanças de 2025-2026 e está atualizado em 24 de junho de 2026. Onde as páginas do Google são vagas ou atrasadas, dizemos isso em vez de inventar.

A sequência completa de publicação (e por que a ordem importa)

A aprovação no Google Play não é uma única análise: é uma cadeia de portões, e cada um pode travar o lançamento inteiro. O maior erro de quem está começando é trabalhar fora de ordem: terminar o app primeiro e descobrir que a verificação de identidade leva dias, ou concluir a listagem e só então perceber que uma conta pessoal ainda precisa de um teste de 14 dias. Faça cedo as etapas lentas e bloqueantes e rode o resto em paralelo. Esta é a ordem que realmente funciona em 2026:

1

Criar a conta de desenvolvedor

Pague a taxa única de US$ 25, aceite os termos e escolha conta pessoal ou organizacional. Ir para os detalhes.

2

Passar pela verificação de identidade

Envie um documento oficial de identidade (e um número D-U-N-S para organizações). Isso bloqueia a publicação, então comece no primeiro dia. Ir para os detalhes.

3

Gerar um Android App Bundle no nível de API certo

Envie um .aab assinado com Play App Signing, com target API 35 hoje (API 36 a partir de 31 de agosto de 2026). Ir para os detalhes.

4

Completar a ficha da loja e as declarações de conteúdo

Título, descrições, ícone, feature graphic, capturas de tela, além de Data Safety, classificação de conteúdo, público-alvo, anúncios e App access. Listagem · Declarações.

5

Rodar o teste fechado de 14 dias (contas pessoais)

Pelo menos 12 testadores participando por 14 dias consecutivos. Esta é a etapa fixa mais longa e a que você não acelera sozinho. Ir para os detalhes.

6

Solicitar o acesso de produção

Responda o formulário em três seções sobre o teste, o app e a prontidão. A análise costuma levar cerca de 7 dias. Ir para os detalhes.

7

Passar pela revisão final do app e ir ao ar

Análises padrão são rápidas; algumas levam até 7 dias ou mais. Depois o app está em Produção. Ver o cronograma completo.

O movimento inteligente

As etapas se sobrepõem. Dispare a verificação de identidade e o teste fechado o quanto antes e termine a ficha da loja e as declarações enquanto o relógio de 14 dias já está correndo. Tratar tudo como estritamente sequencial é o que transforma um lançamento de 3 semanas em um de 6.

Etapa 1: a conta de desenvolvedor e a taxa de US$ 25

Tudo começa com uma conta de desenvolvedor no Google Play Console. Você precisa de uma conta Google com a verificação em duas etapas ativada e deve revisar e aceitar o Google Play Developer Distribution Agreement e os Termos de Serviço do Play Console no cadastro.

Play Console · inscrição Pago uma vez
Inscrição de desenvolvedor $25.00
Renovação anual $0 · nenhuma
Apps incluídos Ilimitados
Total, para sempre $25.00

Há uma taxa de inscrição única de US$ 25. Não é reembolsável e não se repete: não existe renovação anual. Esse pagamento único permite publicar um número ilimitado de apps na conta.

Formas de pagamento (é aqui que muita gente trava)

A taxa precisa ser paga com cartão de crédito ou débito apenas. Os tipos aceitos variam por local, mas a orientação oficial do Google lista o seguinte e deixa claro que cartões pré-pagos não são aceitos:

Aceitos

Visa Mastercard American Express Discover (somente EUA) Visa Electron (fora dos EUA)

Não aceitos

Cartões pré-pagos PayPal para a taxa Transferência bancária

Pessoal vs organizacional: o mesmo app, papelada diferente

Você escolhe o tipo de conta no cadastro. Segundo a ajuda oficial do Google, os dois tipos têm acesso às mesmas funcionalidades e ambos podem monetizar com um perfil de pagamentos. A diferença real é a informação que o Google coleta para verificar você.

Pessoal

Individual / indie

Ideal para desenvolvedores solo, hobby e makers independentes.

Nome público de desenvolvedor
E-mail e telefone de contato verificados
Documento oficial de identidade do governo
Nome legal e endereço vindos do perfil de pagamentos do Google
Sujeita ao teste fechado de 14 dias se criada após 13 de novembro de 2023
Organizacional

Empresa / negócio

Obrigatória para apps de finanças, saúde, VPN e governo.

Um número D-U-N-S (ID de 9 dígitos da Dun & Bradstreet)
Nome legal e endereço da empresa
Um site verificado (obrigatório desde fev. de 2024)
Documentos da organização e um documento de identidade
Isenta do requisito de teste fechado de 14 dias

Peça o número D-U-N-S cedo

Se for pela via organizacional, o número D-U-N-S é o gargalo escondido. Segundo a ajuda oficial do Android Developer Console: "The process can take up to 28 days so you should make preparations to obtain a D-U-N-S number." Solicite antes de qualquer outra coisa, ou ele segura o lançamento inteiro.

Mudar de ideia depois não é um interruptor. Você pode trocar o tipo de conta se as circunstâncias mudarem, mas converter uma conta pessoal existente em organizacional não é um simples switch: na prática exige um novo cadastro. Escolha o tipo certo desde o início.

Interativo

Qual tipo de conta você precisa?

Escolha a descrição que combina com você para ver o tipo exigido pelo Google e o que preparar.

Selecione uma situação acima para ver o tipo de conta recomendado.

Conta pessoal

Recomendada para você

A conta pessoal é o caminho mais rápido: você precisa de um nome público de desenvolvedor, e-mail e telefone verificados e um documento de identidade. Sem número D-U-N-S, sem documentos empresariais.

Atenção: se a conta for criada após 13 de novembro de 2023, você precisa concluir o teste fechado de 14 dias com 12+ testadores antes da produção. Planeje isso desde o dia um.

Conta organizacional

Recomendada para você

Cadastre-se como organização para publicar no nome da empresa. Você vai precisar de um número D-U-N-S (comece agora: até 28 dias), um site verificado, documentos empresariais e um documento de identidade.

A vantagem: contas organizacionais são isentas do requisito de teste fechado de 14 dias, então você chega à produção mais rápido depois de verificado.

Conta organizacional (obrigatória)

Exigida, não opcional

Apps de serviços financeiros, saúde, VPN e governo precisam de conta organizacional: uma conta pessoal não é aceita. Organize o número D-U-N-S e os documentos da organização antes de construir o app.

Apps de saúde têm um prazo extra: apps de saúde existentes precisavam migrar para uma conta organizacional verificada até 28 de janeiro de 2026. Veja o resumo das mudanças de 2026.

Etapa 2: verificação de identidade da conta (e o mito dos "5 dias")

Antes de enviar ou publicar qualquer coisa, o Google verifica quem você é no nível da conta. Contas pessoais enviam um documento oficial de identidade; organizações acrescentam um número D-U-N-S e documentos da organização. Pular ou atrasar isso tem consequências reais: você não publica, e perfis de desenvolvedor não verificados e seus apps podem ser removidos do Google Play e bloqueados para republicação até a verificação terminar.

Há um número muito repetido que você deve ignorar. Dezenas de blogs de terceiros dizem que a verificação de identidade "leva até 5 dias". Esse número existe, mas está colado na coisa errada.

A afirmação comum

"A verificação de identidade leva até 5 dias"

Repetida em inúmeros guias. A linha "até 5 dias" vem na verdade da página de verificação de método de pagamento e banco do Google, não da página de documentos de identidade. É a checagem financeira, não a de identidade.

O que o Google realmente diz

A análise de identidade leva "alguns dias" (1-7 dias)

As páginas de identidade do Google dizem que a análise do documento "pode levar alguns dias", e o Google Payments Center afirma que "pode levar de 1 a 7 dias". A página principal de verificação de identidade não dá nenhum prazo fixo.

Conclusão prática: trate a verificação de identidade como "alguns dias, possivelmente até uma semana", e reserve "até 5 dias" só para verificação de pagamento ou banco. De qualquer forma, inicie as duas no momento em que a conta existir: elas rodam em segundo plano enquanto você desenvolve, mas bloqueiam a publicação se não estiverem concluídas.

Mais uma coisa a deixar clara antes da próxima seção: essa checagem de identidade no nível da conta não é o mesmo que o novo programa Android Developer Verification. São duas camadas diferentes que chegaram em 2026, e confundir as duas é fácil. Veja como elas diferem.

Android Developer Verification: a maior mudança de 2026

Esta é a maior mudança estrutural na distribuição Android em anos, e é novidade de 2026. A Android Developer Verification (verificação de desenvolvedor Android) é um programa separado da checagem de identidade da conta que você acabou de ler. Ela exige que apps estejam registrados em uma identidade de desenvolvedor verificada para instalar em dispositivos Android certificados, inclusive apps distribuídos fora do Google Play, como APKs diretos e lojas de terceiros. Primeiro, veja exatamente como as duas camadas diferem:

Camada 1

Verificação de identidade da conta

Provar quem você é para abrir e manter uma conta no Play Console.

  • Acontece no cadastro do Play Console
  • Documento de identidade (e D-U-N-S para orgs)
  • Bloqueia a publicação no Google Play
  • Só sobre o Google Play
Camada 2

Android Developer Verification

Registrar um app a uma identidade verificada para que ele possa instalar em dispositivos.

  • Em todo o ecossistema, programa separado
  • Registrar package name + fingerprint da chave de assinatura
  • Afeta também apps sideloaded e outras lojas
  • Confirma QUEM você é, não o que o app faz

A justificativa declarada pelo Google, no Android Developers Blog de março de 2026, é segurança. O enquadramento é que a verificação é como "uma checagem de identidade no aeroporto": confirma a identidade do desenvolvedor, mas não analisa o conteúdo do app. O dado de destaque que eles citam:

Malware encontrado, por origem

Motivo declarado pelo Google para o programa (Android Developers Blog, março de 2026).

Fontes sideloaded90x mais
mais de 90x o malware
Google Playbaseline

Verbatim: "our recent analysis found over 90 times more malware from sideloaded sources than on Google Play." Esta é a justificativa do Google, não uma medição independente: apresentamos como o racional declarado por eles.

O cronograma de implantação que você precisa acompanhar

O programa abriu em março de 2026 e escala ao longo do ano. A data que mais importa é 30 de setembro de 2026, quando a aplicação começa nos quatro primeiros países.

Março de 2026

Verificação aberta a todos os desenvolvedores

Disponível pelo Play Console e pelo novo Android Developer Console. Apps do Play existentes foram registrados automaticamente: o Google esperava auto-registrar cerca de 98% dos apps do Play, com os ~2% restantes precisando de registro manual. Em junho de 2026, "a maioria dos desenvolvedores do Play já está verificada, e mais de 99% dos apps deles foram registrados."

Abril de 2026

Serviço "Android Developer Verifier" apresentado

Um novo serviço de sistema do Google que verifica se um app está registrado a um desenvolvedor verificado. Aplica-se a dispositivos certificados no Android 7 ou 8 e mais recentes, aparece em Google System services e fica inativo até a aplicação. A distribuição nos dispositivos começou por volta de junho de 2026.

Junho - julho de 2026 Você está aqui

Contas gratuitas e APIs em rollout

Junho: acesso antecipado a contas gratuitas de Limited Distribution. Julho: o Android Developer ID Status API lança globalmente, mais acesso antecipado à API do Android Developer Console.

Agosto de 2026

Limited Distribution e Console API em escala global

Contas de Limited Distribution, a API do Android Developer Console e o fluxo avançado de sideloading lançam globalmente.

30 de setembro de 2026 Aplicação

Aplicação começa em 4 países

As proteções de verificação entram em vigor para usuários no Brasil, Indonésia, Singapura e Tailândia. Lojas participantes incluem Google Play, Samsung Galaxy Store, Xiaomi GetApps, OPPO App Market, vivo V-Appstore, HONOR App Market e Palm Store.

2027 e além

Rollout global

O Google disse que vai "expandir essas proteções globalmente para todos os apps em dispositivos Android certificados em 2027." Ainda não há data global específica anunciada.

Duas formas de se registrar: Full vs Limited Distribution

Se você já pagou a taxa de US$ 25 do Play, está coberto para full distribution. A novidade de 2026 é um tier gratuito voltado a estudantes e hobbyistas.

Full Distribution

$25 + documento de identidade

Apps ilimitados para todos os dispositivos certificados
Documento de identidade obrigatório
Desenvolvedores do Play existentes (que pagaram US$ 25) já estão cobertos
Provar propriedade via package name + fingerprint da chave de assinatura
Novo em 2026

Limited Distribution

Grátis sem documento de identidade

Sem taxa de inscrição
Distribuir para até 20 dispositivos
Sem documento de identidade: só um e-mail para começar
Pensado para estudantes e hobbyistas

Sideloading ainda funciona (com atrito)

Apps não registrados ainda podem ser instalados via adb ou um "fluxo avançado" deliberadamente pesado: ativar o Modo de desenvolvedor, permitir pacotes não verificados, confirmar os riscos, autenticar, reiniciar o dispositivo e esperar cerca de 24 horas antes da instalação completar. É lento de propósito: a ideia é dificultar o sideloading casual de apps não verificados, não torná-lo impossível.

Etapa 3: requisitos de build: App Bundle e target API

Os dias de enviar um APK cru acabaram para apps novos. Dois requisitos no nível do build decidem se o Google Play sequer aceita o upload: o formato e o nível de target API.

Você precisa enviar um Android App Bundle (.aab)

Desde agosto de 2021, apps novos precisam ser publicados como Android App Bundles: APKs não são mais aceitos para apps novos. (Apps existentes baseados em APK ainda podem atualizar via APK, embora a migração seja recomendada.) Junto com isso, o Play App Signing é obrigatório para apps novos: o Google gerencia e protege a chave de assinatura do app, enquanto você mantém uma upload key para assinar o AAB antes do envio.

.aabFormato obrigatório para apps novos
2021APKs fora para apps novos
2Chaves: assinatura do Google + sua upload key
API 35Piso atual de target

Target API level: atual vs próximo

Este é o ponto que mais confunde quem está começando, porque o piso está se movendo. Leia as duas linhas com cuidado:

Piso atual API 35 Android 15 Desde 31 de ago. 2025
Próximo prazo API 36 Android 16 A partir de 31 de ago. 2026
Planejado API 37 Android 17 Esperado em ago. 2027
  • Em vigor hoje (junho de 2026): apps novos e atualizações precisam ter target Android 15 (API 35) ou superior. Wear OS, Android TV e Android Automotive precisam ter target Android 14 (API 34) ou superior. Apps existentes precisam ter target de pelo menos API 34 para continuar descobertos por novos usuários em dispositivos mais novos.
  • A partir de 31 de agosto de 2026: apps novos e atualizações precisam ter target Android 16 (API 36) ou superior.

Nota de precisão: atraso da página de ajuda

No momento desta escrita, a página dedicada de target API do Play Console ainda mostra "API 35" e não foi atualizada de forma visível para API 36. O prazo da API 36 está confirmado no Android Developers Blog (janeiro de 2025): "targeting API 36 will be required in August 2026 and targeting API 37 will be required in August 2027." Se você abrir a página de ajuda e ver API 35, isso é atraso, não contradição: API 35 é o piso hoje; API 36 vira o piso para novos envios em 31 de agosto de 2026.

Etapa 4: ficha da loja e assets

A ficha da loja é o que usuários (e revisores) veem primeiro, e tem limites técnicos rígidos. Erre as especificações e você não publica; erre o conteúdo e é rejeitado. Estes são os requisitos exatos de 2026:

Limites de texto

Nome / título do app30 caracteres
Descrição curta80 caracteres
Descrição completa4.000 caracteres

Ícone do app

Tamanho512 x 512 px
FormatoPNG 32 bits (alpha)
Arquivo máx.1 MB
Formato 2026Quadrado cheio, raio 30%

Feature graphic

Tamanho1024 x 500 px
FormatoJPEG / PNG 24 bits (sem alpha)
Arquivo máx.1 MB
Obrigatório?Sim, para publicar

Capturas de tela

Mínimo2 de telefone (para publicar)
Máximo8 por tipo de dispositivo
Cada lado320 - 3840 px
ProporçãoEntre 1:2 e 2:1
Google Play Console · captura real Clique para ampliar Editor de ficha da loja padrão do Google Play Console mostrando o campo Nome do app (22 de 30 caracteres), Descrição curta (67 de 80), Descrição completa (454 de 4.000) e a seção Gráficos com o ícone de 512px
O editor de ficha da loja no Play Console. Os contadores ao vivo de caracteres no Nome do app (máx. 30), Descrição curta (máx. 80) e Descrição completa (máx. 4.000) são exatamente os limites da tabela acima, e a seção Gráficos é onde ficam o ícone de 512px e o feature graphic.

A mudança de ícone que quase todo mundo perde: raio de canto de 30%

Novo em 2026, segundo a página oficial de especificações de design de ícone do Google (última atualização em 15 de junho de 2026): você envia um ícone quadrado cheio e "o Google Play aplica a máscara de forma dinâmica. O raio será equivalente a 30% do tamanho do ícone." Em linguagem simples, o Google arredonda os cantos por você, de forma bem agressiva. Se o logo ou o texto ficam perto de um canto, são cortados. Mantenha elementos-chave dentro de uma zona segura de cerca de 15 a 18%.

Raio 30%

Como ler o mockup

  • A área xadrez é o canvas quadrado completo de 512 x 512.
  • A forma arredondada é o que os usuários realmente veem após a máscara dinâmica de 30% do Google.
  • A caixa tracejada é a zona segura: mantenha logos, textos e formas-chave dentro dela para nada ser cortado.
  • Envie em 512x512, PNG 32 bits, abaixo de 1 MB.

Quer ficar elegível a featured? Vá além no número de capturas. O portão rígido para publicar são só 2 capturas de telefone. Mas para se qualificar a superfícies de grande formato e recomendação (featuring), a orientação do Google pede pelo menos 4 capturas a 1080px+ (paisagem 16:9 no mínimo 1920x1080, ou retrato 9:16 no mínimo 1080x1920); jogos precisam de pelo menos 3. Capturas de tablet passaram de opcionais a praticamente essenciais (mínimo de 4 por classe de tablet) para colocação otimizada em tablet, e listagens Wear OS precisam de pelo menos uma captura 1:1, mínimo 384x384. Esses mínimos de 4+ são orientação de elegibilidade a featuring, não bloqueio de publicação.

Um vídeo de prévia é opcional: use um link do YouTube público ou não listado (não privado), com anúncios e monetização desativados. Os tipos de dispositivo suportados para capturas cobrem telefones, tablets de 7" e 10", Chromebooks, Android TV, Wear OS, Android Automotive e Android XR.

Regras de metadados que fazem a listagem ser recusada

As boas práticas de listagem do Google são rígidas com linguagem promocional. Mantenha título, ícone, nome de desenvolvedor e descrição curta limpos:

Não use

  • Keyword stuffing ou repetição excessiva
  • Claims de ranking: "#1", "Melhor", "Top"
  • Texto de preço ou promoção: "Grátis", "desconto", "promoção"
  • Chamadas à ação: "Instale agora"
  • Afirmações enganosas sobre o que o app faz

Faça assim

  • Um título que descreva a função com precisão
  • Descrições de recursos claras e honestas
  • Capturas mostrando a experiência real no app
  • Sobreposições de texto em no máximo ~20% da imagem
  • Assets que batem com a funcionalidade real

A regra da precisão

Sua listagem e capturas precisam refletir a funcionalidade real do app. Divergências entre o que você mostra e o que o app faz são causa comum de recusa: as capturas devem mostrar a experiência real no app, não um mockup de recursos que não existem.

Etapa 5: conteúdo do app e declarações de política

Esta é a seção que iniciantes subestimam. A área "App content" do Play Console é uma pilha de declarações obrigatórias, e respostas incompletas ou imprecisas estão entre as razões mais comuns de um lançamento travar ou de uma conta ser sinalizada. Estas são as sete que você mais vai tocar:

Política de privacidade

Uma URL ativa, pública e sem geofence (sem PDFs). Apps para crianças precisam linká-la na listagem e no app.

Obrigatória

Data Safety Form

Declara quais dados você coleta e compartilha. Obrigatória nas faixas fechada, aberta e de produção, mesmo se você não coleta nada.

Obrigatória

Classificação de conteúdo

Um questionário que atribui classificação etária via IARC. Apps sem classificação não são permitidos e podem ser removidos.

Obrigatória

Público-alvo

Declare a(s) faixa(s) etária(s) alvo. Incluir crianças aciona requisitos da política Families (COPPA / GDPR).

Obrigatória

Declaração de anúncios

Informe se o app contém anúncios, inclusive SDKs de terceiros, display, nativos e banners.

Obrigatória

App Access

Demo funcional ou credenciais de login (até cinco conjuntos) para qualquer funcionalidade com acesso restrito, para o revisor entrar.

Se houver login

Conta e exclusão de dados

Se o usuário pode criar conta, você precisa oferecer exclusão de conta no app e via URL web pública, e permitir solicitar a exclusão dos dados.

Se houver contas
Google Play Console · captura real Clique para ampliar Página App content do Google Play Console listando 11 declarações concluídas: Advertising ID, permissões de foto e vídeo, apps de saúde, recursos financeiros, apps governamentais, Data safety, público-alvo e conteúdo, classificações, anúncios, detalhes de login e política de privacidade
A seção App content no Play Console. Toda declaração deste guia vive aqui: as principais e as específicas de categoria, como apps de saúde, recursos financeiros e permissões de foto e vídeo, cada uma precisa ser concluída e mantida atualizada.

Data Safety, com precisão: todo app publicado no Google Play, nas faixas fechada, aberta ou de produção, precisa completar o formulário Data Safety. Apps só de teste interno estão isentos. Apps que não coletam dados ainda preenchem o formulário e linkam uma política de privacidade indicando que não há coleta nem compartilhamento. Uma atualização de 10 de abril de 2025 esclareceu que o Android ID deve ser declarado como identificador de dispositivo e apertou a definição de "compartilhamento" de dados.

A recusa nº 1 evitável: App Access

Se qualquer parte do app estiver atrás de login, você precisa dar ao revisor credenciais que funcionem em App access (até cinco conjuntos). Credenciais inválidas, expiradas ou ausentes são causa clássica de recusa: o revisor literalmente não consegue ver o app e o recusa. Teste o login antes de enviar.

Declarações específicas de categoria (saiba se alguma se aplica a você)

Dependendo do que o app faz, você pode encontrar declarações extras. As mais relevantes em 2026:

  • Apps de saúde: a política Health Content and Services acrescenta rotulagem de dispositivo médico, exigência de disclaimer para apps de saúde não regulados, migração de apps de saúde para uma conta organizacional verificada até 28 de janeiro de 2026 e permissões granulares de saúde no Android 16.
  • Política de conteúdo gerado por IA: apps de IA generativa precisam impedir saída ofensiva, com rotulagem e moderação mais rígidas desde janeiro de 2025.
  • Política de permissões de foto e vídeo (em aplicação ativa): peça acesso amplo a fotos e vídeos só quando o recurso central realmente precisar, caso contrário use o seletor de fotos do sistema. Regras atualizadas de permissão de localização também se aplicam. Uma política separada de permissões de Contatos vem depois, aplicada em 28 de outubro de 2026 e só para apps com target API 37 ou superior.
  • Formulário de declaração de permissões de alto risco: obrigatório para acesso sensível como SMS ou Call Log, além da declaração de Advertising ID.
  • Outras categorias: News & Magazines, Financial Services, apps governamentais (somente contas organizacionais) e declarações de rastreamento ou status de COVID-19.

Etapa 6: teste fechado: 12 testadores por 14 dias

Para a maioria dos novos desenvolvedores, este é o muro. Segundo a política oficial do Google, uma conta pessoal criada após 13 de novembro de 2023 precisa rodar um teste fechado com no mínimo 12 testadores participando continuamente há pelo menos 14 dias antes de solicitar o acesso de produção. Contas organizacionais estão isentas, assim como contas criadas antes dessa data.

Se você leu que o número é 20, isso está desatualizado. Segundo o Android Developers Blog: "starting today, we're requiring 12 instead of 20 testers for personal developer accounts." A redução entrou em vigor em 11 de dezembro de 2024, mantendo os mesmos 14 dias, depois de feedback de que 20 testadores era pesado para desenvolvedores menores.

12+Testadores participando (antes 20)
14Dias consecutivos, sem lacunas
Nov '23Vale para contas depois desta data
0Para contas organizacionais
Google Play Console · captura real Clique para ampliar Página Solicitar acesso de produção do Google Play Console mostrando o checklist de teste fechado: publicar uma versão de teste fechado, ter pelo menos 12 testadores participando e rodar o teste fechado com pelo menos 12 testadores por pelo menos 14 dias, com status ao vivo de 12 testadores participando por 12 dias continuamente
O requisito como aparece no Play Console: pelo menos 12 testadores participando e um teste fechado rodando por pelo menos 14 dias consecutivos. O contador ao vivo (aqui, "12 dias continuamente") mantém o botão "Solicitar o acesso de produção" desabilitado até os dois critérios serem atendidos.

As três faixas de teste (só uma conta)

O Google oferece três faixas, e novos desenvolvedores as confundem o tempo todo. O teste interno parece a opção rápida óbvia, mas não atende ao requisito. Só o teste fechado atende.

Interno

Até 100 testadores, pronto em minutos.

Distribuição mais rápida para checagens rápidas
Disponível em minutos
Não conta para produção

Não atende ao requisito

A que conta

Fechado

Um grupo controlado que você convida.

Atende ao requisito 12 / 14
Compartilhe via listas de e-mails ou Google Groups
Obrigatório antes de solicitar produção

Obrigatório para o acesso de produção

Aberto

Qualquer um pode entrar e dar feedback.

Público, canal privado de feedback
Ótimo para um beta mais amplo
Só disponível depois do acesso de produção

Vem depois da produção

"Participando" não é "adicionado"

Você adiciona e-mails de testadores (via listas de e-mails ou Google Groups) à faixa fechada e compartilha o link de convite, mas cada testador precisa clicar no link e aceitar participar de forma ativa. Só adicionar um e-mail não conta. Testadores que aceitam, testam por menos de 14 dias e depois saem também não contam, porque os 14 dias precisam ser consecutivos. Esse único equívoco zera mais relógios de 14 dias do que qualquer outra coisa.

Na solicitação de produção, o Google avalia duas coisas: sua contagem de testadores (pelo menos 12) e o engajamento dos testadores. Exemplos oficiais de por que pedem continuar testando incluem "não ter 12 testadores participando do teste fechado, ou seus testadores não estarem engajados com o app durante o teste fechado." Em outras palavras, 12 nomes em uma lista não bastam: esses testadores precisam de fato usar o app.

A forma mais eficaz de passar: testadores reais e participando

Todo outro requisito deste guia é algo que você controla diretamente. Este precisa de 12 pessoas reais em dispositivos Android reais, participando e ativas por 14 dias ininterruptos, e é exatamente aí que desenvolvedores solo travam. O caminho confiável é trazer testadores reais que de fato entram e permanecem ativos.

Como passar de forma eficaz

A forma mais confiável de atender ao requisito de teste fechado com 12 testadores por 14 dias do Google Play é usar os testadores reais da PrimeTestLab, participando em dispositivos Android reais, nunca emuladores ou bots. Você compartilha o link de convite do teste fechado e nós cuidamos do resto: 12 ou mais testadores genuínos entram e permanecem ativos por 14 dias consecutivos, com substituição imediata se alguém sair, para a sequência de 14 dias nunca zerar. Funciona para um app em qualquer idioma com segmentação flexível de país, com taxa de sucesso de 99,9% em mais de 7.400+ apps, e o teste costuma começar em cerca de 4 horas (garantido em até 6), a partir de $19.99. Veja como funciona →

Etapa 7: o formulário de acesso de produção

Quando você atende aos critérios do teste fechado, uma conta pessoal não vai direto para Produção: você clica em "Solicitar o acesso de produção" no Painel e responde um formulário. Na internet isso aparece como um "formulário de 10 perguntas." Ignore esse enquadramento: o Google atualiza a redação, e a forma confiável de entender é como três seções, não um número fixo de perguntas.

Parte 1

Sobre o seu teste fechado

  • Quão fácil foi recrutar testadores
  • Como os testadores se engajaram com o app
  • Se o uso refletiu o uso real em produção
  • Um resumo de feedback e como você o coletou
Parte 2

Sobre o seu app ou jogo

  • Funcionalidade central e recursos
  • O que o app realmente faz
  • Instalações esperadas no primeiro ano
Parte 3

Prontidão para produção

  • O que você mudou com base no teste
  • Como decidiu que o app está pronto
  • Por que ele tem qualidade de produção agora

Tempo de análise: Esse processo geralmente leva até sete dias, mas pode demorar um pouco mais. Responda com detalhes específicos do seu teste real: respostas vagas e genéricas ("testamos e funciona") são um jeito conhecido de ser mandado de volta para continuar fazendo testes. Se quiser a redação exata a que os revisores respondem, veja nosso guia de respostas do formulário de produção.

Análise e o cronograma real de ponta a ponta

Na reta final há, na verdade, duas análises: a análise do acesso de produção depois do formulário, e a revisão final do app da versão em si. O Google processa análises padrão "o mais rápido possível", mas avisa que "certos apps podem estar sujeitos a análises estendidas, o que pode resultar em tempos de até 7 dias ou mais em casos excepcionais." Apps voltados a crianças, ou com respostas imprecisas de público-alvo, tendem a receber a olhada mais profunda.

Então quanto tempo o processo inteiro realmente leva para uma conta pessoal novinha? Este é o cronograma empilhado realista, com as sobreposições que desenvolvedores espertos exploram:

Sem. 1Sem. 2Sem. 3Sem. 4Sem. 5
Verificação de identidadeAlguns dias (1-7)
~3-5 dias
Build, listagem, declaraçõesFaça em paralelo
Build + listagem + conteúdo
Teste fechado14 dias, fixo
14 dias consecutivos
Análise do acesso de produçãoCerca de 7 dias ou menos
~7 dias
Revisão final do appAté 7 dias
até 7 dias

Total típico para uma conta pessoal nova: 3 a 5+ semanas. As etapas se sobrepõem para encurtar; uma recusa pode estender.

O que realmente atrasa quem está começando

O total explode quando um destes bate. Quase todos são evitáveis:

  • Verificação de identidade incompleta ou lenta: começou tarde demais e bloqueia o resto.
  • Declarações Data Safety fracas ou ausentes: o formulário é obrigatório também nas faixas de teste.
  • Credenciais de login inválidas para o revisor em App access: o revisor não entra e recusa.
  • Ficha da loja ou capturas que não batem com a funcionalidade real do app.
  • Recrutamento lento de testadores ou engajamento baixo durante o teste fechado de 14 dias.
  • Respostas vagas no formulário de produção que soam genéricas e disparam "continuar fazendo testes".

Checklist de prontidão pré-envio

0 de 8 requisitos prontos (0%)

Marque cada requisito conforme for concluindo. O teste fechado de 14 dias é o mais longo: comece cedo para ele não ser o que segura o lançamento.

Mudanças 2025-2026 em resumo (referência rápida)

Se você só for ler uma seção por cima, que seja esta. Estas são as mudanças que pegam desenvolvedores que aprenderam o processo um ou dois anos atrás:

Target API 36 obrigatória para novos envios

API 35 é o piso hoje; API 36 (Android 16) vira obrigatória para apps novos e atualizações.

31 de ago. 2026

Aplicação da Android Developer Verification

Começa no Brasil, Indonésia, Singapura e Tailândia; global em 2027. Afeta também apps sideloaded.

30 de set. 2026

Ícone com raio de canto dinâmico de 30%

Envie um quadrado cheio; o Google mascara os cantos em 30%. Mantenha a arte-chave numa zona segura de ~15-18%.

Spec atualizada em 15 de jun. 2026

Apps de saúde precisam de conta organizacional

Política Health Content and Services: rotulagem de dispositivo médico, disclaimers e permissões de saúde do Android 16.

Migrar até 28 de jan. 2026

Política de conteúdo gerado por IA

Apps de IA generativa precisam impedir saída ofensiva, com rotulagem e moderação mais rígidas.

Desde jan. 2025

Permissões de foto, vídeo, localização e contatos

Permissões de foto e vídeo e regras atualizadas de localização já estão em aplicação. Uma nova política de permissões de Contatos vem para apps com target API 37 ou superior.

Contatos: 28 de out. 2026

Data Safety: Android ID e "compartilhamento"

O Android ID deve ser declarado como identificador de dispositivo, e a definição de "compartilhamento" de dados foi apertada.

10 de abr. 2025

Teste fechado caiu de 20 para 12 testadores

Contas pessoais agora precisam de 12 (não 20) testadores pelos mesmos 14 dias consecutivos.

11 de dez. 2024

Política de transferência de conta

A propriedade precisa se mover pelo fluxo oficial "Transfer ownership" no Play Console.

Em vigor

Taxas de link externo (pós-Epic)

Atualizações do Play Console introduziram taxas para linkar a pagamentos externos ou lojas alternativas. Só importa se você usa cobrança externa.

Dez. 2025

Assista: atualização oficial de política do Google (PolicyBytes, abril de 2026)

O time de Developer Experience do Google detalha mudanças recentes de política na série PolicyBytes, e o episódio de abril de 2026 é a fonte oficial de vários itens acima: duas políticas novas (permissões de Contatos e transferência de conta) e dois esclarecimentos (conteúdo com restrição etária e permissões de localização). Aqui está o vídeo, com um resumo em linguagem clara embaixo.

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

Canal oficial do Google Play: novas políticas de Contatos e transferência de conta, mais esclarecimentos de idade e localização.

Thumbnail do vídeo: Google Play PolicyBytes - atualizações de política de abril de 2026
O fio comum é o escopo mínimo: o Google quer cada vez mais que os apps usem seletores do sistema (Contact Picker, ShareSheet, o botão de localização) em vez de segurar permissões amplas e sensíveis.

Novo: política de permissão de Contatos

O Google adicionou uma seção de permissões restritas que empurra alternativas de escopo mínimo: use o Contact Picker do Android (e ferramentas como ShareSheet) em vez de pedir acesso bruto a dados pessoais. A regra específica: se o app tem target Android 17 (API 37) ou superior, você só pode usar a permissão READ_CONTACTS quando o Contact Picker realmente não suportar o recurso central, e precisa enviar uma declaração no Play Console explicando o porquê. A aplicação começa em 28 de outubro de 2026.

Novo: política de transferência de conta

Toda mudança de propriedade agora precisa passar pelo fluxo oficial Transfer ownership no Play Console (Users & Permissions → Manage → Make account owner). Os requisitos diferem para contas individuais vs organizacionais, e o novo dono confirma por e-mail e pode precisar verificar um perfil de pagamentos ou detalhes da organização. Existe para frear sequestros de conta: ambas as partes são responsáveis durante a transferência, e comprar, alugar ou vender contas em marketplaces de terceiros é explicitamente proibido.

Esclarecido: conteúdo com restrição etária (recursos de namoro)

Se namoro não é o propósito central do app mas você inclui um recurso de namoro, um público geral ainda pode baixar o app, desde que haja uma restrição etária forte (uma checagem de idade) que mantenha menores fora desse recurso. Mas se a funcionalidade central do app for namoro ou matchmaking, você precisa bloquear menores por completo escolhendo o grupo etário certo na seção Target Audience and Content.

Esclarecido: permissões de localização (escopo mínimo)

Para localização precisa pontual e iniciada pelo usuário, você agora precisa usar o botão de localização do Android com a flag onlyForLocationButton no manifest, em vez de manter ACCESS_FINE_LOCATION. Para necessidades mais regulares, use o botão de localização ou COARSE_LOCATION. O Google só aprova um pedido completo de ACCESS_FINE_LOCATION quando nenhuma alternativa funciona, e você completa uma declaração obrigatória com justificativa clara no console do desenvolvedor.

Por que isso importa para um app novo: tudo isso entra direto nas declarações de conteúdo do app que você já precisa completar. Se pedir contatos, localização precisa ou acesso a foto e vídeo, planeje uma declaração e uma alternativa de escopo mínimo desde o início: é bem mais fácil do que refazer permissões depois de uma recusa.

Onde a PrimeTestLab entra nisso tudo

Olhe de volta para as sete etapas. Seis são papelada e engenharia que você controla: a conta, a identidade, o build, a listagem, as declarações e o formulário. Uma é fundamentalmente diferente: precisa de 12 pessoas reais em dispositivos Android reais, participando e de fato ativas por 14 dias ininterruptos. É nessa etapa que a maioria dos desenvolvedores solo trava, e é exatamente o que a PrimeTestLab resolve.

Você compartilha o link de convite do teste fechado. Nós cuidamos do convite, da verificação de participação, do monitoramento diário de engajamento e da retenção completa de 14 dias, para que a saída de um testador nunca quebre a sequência e zere o relógio. Mais de 7.400+ apps e contando, com taxa de sucesso de 99,9% na primeira tentativa em 120+ países.

A partir de $19.99 12 testadores
4-6 horas Início do teste
7.400+ apps 99,9% de sucesso

Para ser direto

A PrimeTestLab cobre o requisito de testadores: a parte de 12 participando e ativos por 14 dias. Não preenchemos suas declarações, não escolhemos o tipo de conta e não passamos a revisão do app por você. A combinação vencedora é seu app pronto e a listagem completa mais 12 testadores reais pelos 14 dias completos, para o teste fechado nunca ser o motivo da travada.

Planos atuais

Starter

12 testadores

$19.99

Atende ao mínimo do Google
Dispositivos Android reais
Cobertura completa de 14 dias
Ver plano

Professional

20 testadores

$29.99

Buffer de segurança incluso
Melhor diversidade de dispositivos
Mais margem na primeira tentativa
Ver plano

Garantia de reembolso de 100% · Teste começa em 4-6 horas · Sem assinatura · +5% de taxa de serviço

Perguntas frequentes

Quanto custa publicar um app no Google Play em 2026?

Publicar exige uma taxa de inscrição única de US$ 25 na conta de desenvolvedor Google Play. Não é reembolsável e não se repete, e permite publicar apps ilimitados nessa conta. O pagamento é só com cartão de crédito ou débito (Visa, Mastercard, American Express, Discover nos EUA ou Visa Electron fora dos EUA); cartões pré-pagos não são aceitos.

Preciso de conta pessoal ou organizacional de desenvolvedor no Google Play?

Os dois tipos de conta têm a mesma funcionalidade e podem monetizar. A diferença é a informação que o Google coleta. Uma conta pessoal precisa de nome público de desenvolvedor, e-mail e telefone de contato verificados e um documento de identidade. Uma conta organizacional exige ainda um número D-U-N-S (que pode levar até 28 dias), nome legal e endereço da empresa, site verificado e documentos da organização. Conta organizacional é obrigatória para apps de serviços financeiros, saúde, VPN e governo.

Quanto tempo leva a verificação de identidade no Google Play?

O Google descreve a análise do documento de identidade como "alguns dias", e o Google Payments Center diz que a análise do documento pode levar de 1 a 7 dias. O "até 5 dias" muito citado não é o prazo de identidade: refere-se à verificação de método de pagamento e banco. Você não publica até a verificação estar concluída, então comece cedo.

O que é o programa Android Developer Verification e quando começa?

É uma camada separada em todo o ecossistema (distinta de abrir uma conta no Play Console e do teste fechado) que exige que apps estejam registrados a uma identidade de desenvolvedor verificada para instalar em dispositivos Android certificados, inclusive apps distribuídos fora do Google Play. Abriu a todos os desenvolvedores em março de 2026 e a aplicação começa em 30 de setembro de 2026 no Brasil, Indonésia, Singapura e Tailândia, expandindo globalmente em 2027. Uma conta gratuita Limited Distribution permite enviar para até 20 dispositivos sem taxa e sem documento de identidade.

Novos desenvolvedores realmente precisam de 12 testadores por 14 dias?

Sim, se você usa uma conta pessoal criada após 13 de novembro de 2023. É necessário rodar um teste fechado com no mínimo 12 testadores participando continuamente por pelo menos 14 dias antes de solicitar o acesso de produção. Contas organizacionais e contas criadas antes dessa data estão isentas. O requisito caiu de 20 para 12 testadores em 11 de dezembro de 2024.

Qual target API level apps novos precisam no Google Play em 2026?

Em meados de 2026 o piso em vigor é Android 15 (API level 35) para apps novos e atualizações, com Wear OS, Android TV e Android Automotive em Android 14 (API 34). A partir de 31 de agosto de 2026, apps novos e atualizações precisam ter target Android 16 (API level 36) ou superior. Apps novos também precisam ser publicados como Android App Bundle (.aab) com Play App Signing.

Quais são os requisitos de ícone e capturas de tela do Google Play?

O ícone do app é 512 por 512 px, PNG 32 bits com alpha, até 1 MB; em 2026 o Google renderiza ícones como quadrado cheio e aplica um raio de canto dinâmico de 30%, então mantenha elementos-chave numa zona segura de cerca de 15 a 18%. O feature graphic é 1024 por 500 px. Você precisa de no mínimo 2 capturas de telefone para publicar (até 8 por tipo de dispositivo); 4 ou mais a 1080px e acima é orientação de elegibilidade a featuring, não um portão rígido de publicação.

Quanto tempo leva para publicar um app no Google Play do zero?

Um cronograma realista de ponta a ponta para uma conta pessoal novinha costuma ser de 3 a 5+ semanas: verificação de identidade (alguns dias), construir o app e completar listagem e declarações, o teste fechado obrigatório de 14 dias, a análise do acesso de produção (cerca de 7 dias ou menos) e uma revisão final do app (até 7 dias). As etapas podem se sobrepor, e uma recusa pode estender o total.

O que é o formulário de acesso de produção do Google Play?

Depois de atender aos critérios do teste fechado, você clica em "Solicitar o acesso de produção" e responde perguntas em três seções: sobre o teste fechado (recrutamento e engajamento), sobre o app ou jogo (funcionalidade e instalações esperadas) e sobre prontidão para produção (o que mudou e como decidiu que está pronto). Esse processo geralmente leva até sete dias, mas pode demorar um pouco mais. É melhor descrever como três seções, e não um formulário fixo de 10 perguntas.

Por que apps de primeira viagem são recusados com mais frequência?

Os problemas mais comuns de iniciantes são verificação de identidade incompleta ou lenta, declarações Data Safety fracas ou ausentes, credenciais de login inválidas para o revisor em App access, ficha da loja ou capturas que não batem com o app real, recrutamento lento de testadores ou engajamento baixo no teste fechado, e respostas vagas no formulário de produção.

A PrimeTestLab pode me ajudar a atender ao requisito de teste fechado?

Sim. A PrimeTestLab fornece testadores verificados e participando em dispositivos Android reais, que permanecem ativos pelos 14 dias consecutivos completos, o único passo que uma conta pessoal não pode pular. Os preços começam em $19.99 para 12 testadores, o teste costuma começar em cerca de 4 horas (garantido em até 6), e mantemos uma taxa de sucesso de 99,9% em mais de 7.400+ apps.

Resumo final

Resumo

Publicar seu primeiro app Android em 2026 é uma sequência: criar a conta (US$ 25 uma vez), passar pela verificação de identidade, gerar um AAB assinado em API 35 hoje (API 36 a partir de 31 de agosto de 2026), completar a listagem e as declarações de conteúdo do app e, em conta pessoal, cumprir o teste fechado de 14 dias com 12 testadores antes do formulário de produção e da revisão final. Reserve 3 a 5+ semanas, comece primeiro as etapas lentas (identidade, D-U-N-S, o teste fechado) e acompanhe as duas mudanças de 2026: API 36 e Android Developer Verification. O único passo que você não resolve sozinho é o teste fechado: é o que a PrimeTestLab cobre, para o teste nunca ser o gargalo. Ver planos e preços →

Kefayatullah Khadem - Software Engineer & Google Play Publishing Specialist

Escrito por

Kefayatullah Khadem

Software Engineer & Google Play Publishing Specialist

Kefayatullah Khadem is a software engineer with over 8 years of experience building scalable applications. At PrimeTestLab, he helps indie developers clear Google Play's closed testing requirement after seeing how many of them struggled with it. To date, he has helped 7,400+ Android apps get production access with a 99.9% success rate across 120+ countries. When he's not helping developers get published, he writes about Google Play policies, app rejection patterns, and the closed testing process.

7,400+ Apps Tested
99.9% Success Rate
120+ Countries
4.9/5 Rating

Taxa de sucesso de 99,9%

Travado no teste fechado de 14 dias? Nós cuidamos.

Você constrói o app. Nós fornecemos 12+ testadores reais que permanecem ativos pelos 14 dias completos.

A partir de $19.99

Teste começa em 4-6 horas · 120+ países · Garantia de reembolso de 100%

Junte-se a mais de 7.400 desenvolvedores que lançaram com a PrimeTestLab

Consiga 12 testadores · $19.99 WhatsApp