Verificação de desenvolvedores Android 2026: datas e passos

Quase tudo o que foi escrito sobre a verificação de desenvolvedores do Android em 2025 hoje está errado em pelo menos um ponto importante, e uma quantidade surpreendente do que foi escrito no início de 2026 também. O desenho do programa mudou depois do anúncio original, a data exata de vigência só apareceu em junho de 2026 e o escopo foi reduzido por escrito em 22 de julho de 2026. Enquanto isso, a pergunta que os desenvolvedores realmente digitam na busca não é "o que é a verificação de desenvolvedores?". É: o Google diz que eu falhei, o que exatamente está errado, o que acontece agora e eu não tinha feito isso já?

Por isso este post foi escrito como resposta a incidente, e não como comentário de política. Ele responde primeiro à pergunta "já está feito?", dá a navegação exata do Play Console em vez de conselhos vagos, separa as duas camadas de vigência que todas as outras páginas fundem em uma única frase assustadora e é explícito sobre os pontos em que o Google não publicou nada. Ele também traça uma linha firme entre a verificação e a regra separada do teste fechado com 12 testadores, porque essa confusão chega à caixa de entrada da PrimeTestLab quase toda semana. Cada data e cada número abaixo foram conferidos nas próprias páginas do Google em 9 de agosto de 2026.

A verificação de desenvolvedores do Android são duas tarefas, não uma

Se você publica no Google Play, a verificação de desenvolvedores do Android pede duas coisas distintas: verificar sua identidade e registrar os nomes de pacote dos seus apps. A maioria dos desenvolvedores do Play que já existem cumpriu a primeira e, na imensa maioria dos casos, a segunda aconteceu sozinha. Para muitas contas o que sobra é conferir duas telas, embora o Google não publique um prazo universal de conclusão e um problema de documento ou de conta possa levar bem mais tempo.

O que cada porta realmente estabelece

As duas tarefas respondem a duas perguntas diferentes, e passar em uma não diz nada ao Google sobre a outra. Mantê-las separadas é a coisa mais valiosa que esta página pode fazer por você, porque os modos de falha, as correções e até as telas do Play Console são diferentes.

Uma conta pode então estar totalmente verificada na identidade e ainda ter um pacote sem registro parado na lista. Essa combinação é exatamente a que dá errado em um dia de prazo, porque o desenvolvedor olhou a tela que diz "verificado" e nunca abriu a que lista os apps.

A resposta de um minuto para quem já usa o Play Console

Se você já publica no Google Play, este é todo o caminho de conformidade na ordem em que deve ser conferido. A maioria dos leitores para no passo dois.

1. 01

   Confirme o status da sua identidade

   Abra Conta de desenvolvedor no Play Console. O guia de verificação do Google descreve o caminho como Configurações › Conta de desenvolvedor, enquanto a documentação mais nova de gerenciamento de conta usa Conta de desenvolvedor › Sobre você. De qualquer forma, o Google afirma que, se você já concluiu a verificação de identidade com sucesso, não precisará repetir essa etapa. Verificado

2. 02

   Confirme que cada pacote está registrado

   Abra a página Verificação de desenvolvedores do Android no Play Console e olhe o status de registro de cada app. A página inicial do Play Console também pode mostrar informações de registro dos apps. Se todos os seus nomes de pacote foram registrados automaticamente, o Google afirma que nenhuma ação de registro adicional é necessária para esses apps. Verificado

3. 03

   Reivindique o que sobrou antes de 30 de setembro

   Para um pacote que não foi registrado automaticamente, siga o registro manual do Google. A forma que ele toma depende do nome de pacote: um nome que o Android nunca viu precisa apenas dos dados do pacote e do seu certificado público de assinatura, enquanto um nome que já tem instalações precisa de um APK de comprovação assinado provando que você tem a chave privada. Os dois fluxos estão na seção 05.

Se você publica no Google Play, use o Play Console

Esta é a armadilha que manda o desenvolvedor para um desvio de uma hora. Existem dois consoles neste programa. O Play Console é onde quem publica no Google Play conclui as duas tarefas. O Android Developer Console é uma superfície separada, para quem distribui fora do Google Play, e suas páginas de ajuda descrevem um fluxo diferente, inclusive a verificação do site da organização pelo Google Search Console. Os dois conjuntos de instruções aparecem nas mesmas buscas.

Quatro rotas de distribuição, quatro respostas. Ache a sua linha antes de ler mais uma palavra da documentação do Google, porque a linha errada custa uma tarde:

Mapeamento das rotas tirado do guia de verificação para Play Console e do guia de distribuição limitada do Google, acessados em 13 de agosto de 2026. Verificado

A cronologia de verificação de 2026 e a data que os artigos ainda erram

A verificação não chegou em um anúncio. Chegou em cinco, e cada um estreitou ou corrigiu o anterior. A cronologia abaixo usa o material do próprio Google de junho e julho de 2026 como fonte de referência, o que importa porque a previsão de março, muito citada, foi superada.

Como o programa realmente chegou, marco a marco

Cada entrada junta o que o Google publicou com o que um desenvolvedor do Play deve tirar dali, porque várias dessas datas são citadas isoladas em outros lugares e se leem de forma muito diferente quando a sequência aparece.

1. novembro de 2025

   Abre o acesso antecipado

   Desenvolvedores convidados para o acesso antecipado puderam começar a verificar apps distribuídos fora do Google Play.

   O que inferir: apenas um marco histórico. Nada aqui cria obrigação para um desenvolvedor do Play hoje.

2. 30 de março de 2026

   Começa a distribuição para todos os desenvolvedores

   O Google anunciou que estava começando a distribuir a verificação de desenvolvedores do Android para todos os desenvolvedores, tanto no Play Console quanto no Android Developer Console, e disse aos desenvolvedores do Play para ficarem de olho no acesso nas semanas seguintes. Verificado

   O que inferir: não leia isso como "toda conta do Play recebeu a verificação em 30 de março". A própria redação do Google é que a distribuição começou naquele dia.

3. junho de 2026

   O serviço de sistema Android Developer Verifier é distribuído

   A cronologia atualizada do Google coloca a distribuição do serviço de sistema de verificação em junho de 2026. Verificado

   O que inferir: use junho. O post de 30 de março tinha previsto abril, e vários artigos de terceiros atuais ainda repetem essa previsão como se fosse história.

4. 18 de junho de 2026

   A data exata de vigência aparece

   O Google anunciou 30 de setembro de 2026 como primeira data de vigência, nomeou as sete lojas participantes e disse que mais de 99% dos apps dos desenvolvedores do Play já estavam registrados. Verificado

   O que inferir: esta é a fonte única mais sólida tanto para a data quanto para o número de registro automático. Tudo o que foi publicado antes está chutando a data.

5. julho de 2026

   Ferramentas: a ID Status API e a Console API

   A Android Developer ID Status API foi distribuída globalmente, com a Console API e a distribuição limitada em acesso antecipado.

   O que inferir: relevante para times de automação e ferramentas, não para quem publica pela primeira vez e avança na mão pelo Play Console.

6. 15 de julho de 2026

   Os guias atuais são publicados

   O guia geral de verificação do Google e o guia do Play Console foram atualizados, incluindo o escopo inicial por loja e as instruções de registro de pacotes do Play. Verificado

   O que inferir: trate essas duas páginas como a documentação atual de referência para qualquer coisa operacional.

7. 22 de julho de 2026

   As perguntas frequentes estreitam o escopo por escrito

   As perguntas frequentes do Google esclareceram que lojas fora da lista participante e a instalação direta de APK não entram na fase de 30 de setembro. Verificado

   O que inferir: esta é a frase que aposenta a narrativa de 2025 de que "o Google vai acabar com o sideloading nessa data". É um limite de primeira fase, não uma isenção permanente.

8. agosto de 2026

   Programado para disponibilidade global: distribuição limitada e fluxo avançado

   A página de verificação do Google lista as contas de distribuição limitada, a API do Android Developer Console e o fluxo de instalação avançado como lançamentos de agosto de 2026. Em 13 de agosto de 2026 o próprio guia de distribuição limitada ainda diz que a inscrição no acesso antecipado está fechada e que mais informações vêm em agosto de 2026, então esta linha é desenhada como programada, não entregue. Parcial, lançamento não confirmado

   O que inferir: é o item que muda mais rápido nesta página, e o calendário ter entrado em agosto não prova que saiu. Confira a página de verificação do Google para o status atual em vez de confiar em qualquer artigo publicado no meio do mês, inclusive este.

9. 30 de setembro de 2026

   Duas coisas acontecem no mesmo dia

   O registro de apps passa a ser obrigatório para instalações pelas sete lojas participantes no Brasil, na Indonésia, em Singapura e na Tailândia. Em separado, pelos requisitos do Play Console, todos os pacotes do Play precisam estar registrados, e o Google afirma que apps não registrados serão removidos do Google Play. Verificado

   O que inferir: uma data, duas consequências independentes. A seção 03 separa as duas como deve ser.

10. 2027 em diante

    Expansão mundial, data não anunciada

    O Google diz que as proteções se expandem para o mundo todo em 2027. Em 9 de agosto de 2026, nenhuma data mundial exata e nenhum calendário adicional de países haviam sido anunciados. Verificado

    O que inferir: trate qualquer "1º de janeiro de 2027" ou "início de 2027" que você leia em outro lugar como previsão. O Google não publicou nenhuma.

30 de setembro de 2026 é um prazo mundial?

Não para a vigência no nível do dispositivo Android e sim para o prazo de registro de pacotes do Google Play. São duas regras diferentes que por acaso dividem uma data, e quase todo artigo sobre este programa junta as duas. A regra de dispositivo começa em quatro países por sete lojas. A regra do Play vale para a sua ficha do Play, e o Google descreve a consequência de perder o prazo como remoção mundial do Google Play.

Os quatro países e as sete lojas

O Google nomeia as duas listas com precisão, então não há nada a interpretar. A primeira fase de vigência cobre instalações de apps nestes quatro países:

E vale para instalações por estas sete lojas de apps participantes:

As duas listas foram tiradas do anúncio do Google de 18 de junho de 2026 e do guia de verificação de 15 de julho de 2026, acessados em 9 de agosto de 2026. O Google pode acrescentar lojas ou regiões, então confira a fonte de novo antes de agir com base nesta lista perto da data.

30 de setembro vale para você? Resolva o seu próprio canal

Responda duas perguntas e a ferramenta abaixo aplica as duas camadas ao seu canal de distribuição específico. Ela é deliberadamente direta nos casos em que a resposta do Google é "ainda não", porque "ainda não" não é o mesmo que "nunca".

Como saber se você já está verificado

Duas telas respondem à pergunta inteira. Conta de desenvolvedor guarda sua identidade e os dados da conta. A página Verificação de desenvolvedores do Android guarda o status de registro de cada app. Se você só abrir a primeira, pode passar em uma auditoria que na verdade não passou.

Os quatro lugares em que um status pode aparecer

Do status para a ação, sem inventar rótulos

O Google publica onde olhar e o que fazer. O que ele não publica é um glossário exaustivo dos rótulos de status de identidade do Play, então este post não inventa nenhum. A tabela abaixo está organizada por o que você está conferindo e como é o feito, que é justamente a parte que o Google documenta.

Navegação e definições de "feito" vindas da ajuda do Play Console resposta 16984799, do guia de verificação do Play Console do Google e da página de ajuda sobre os dados da conta de desenvolvedor; a linha do teste fechado vem da ajuda do Play Console resposta 14151465. Todas acessadas em 9 de agosto de 2026. As próprias páginas do Google hoje usam duas formulações diferentes para o caminho de identidade, a navegação do Play Console muda com frequência e aqui os rótulos aparecem em português enquanto o seu Console pode exibir um texto um pouco diferente: trate cada caminho como válido nesta data e não como permanente.

O que "registrado automaticamente" quer dizer de fato

O registro automático trata de uma relação bem estreita: o vínculo entre o nome de pacote de um app e as credenciais de assinatura que provam quem o controla. O Google afirma que apps elegíveis que usam Play App Signing fazem parte do processo de registro automático, porque o Google já tem as informações de propriedade e de assinatura de que precisa.

Se todos os seus nomes de pacote foram registrados automaticamente com sucesso, o Google diz que nenhuma ação de registro adicional é necessária para os apps do Play correspondentes. Essa frase faz exatamente o trabalho que ela anuncia e nem um grama a mais.

Vale parar nesse último ponto. O registro é por pacote, então uma conta com seis apps pode estar quatro sextos pronta e não mostrar nada alarmante em lugar nenhum, exceto na única página que os lista. O Google também enquadra a verificação como a confirmação de quem é o desenvolvedor e a descreve como separada da triagem de segurança aplicada ao conteúdo dos apps, então nada disso diz se o seu app está em conformidade com as políticas do Play.

O que fazer quando um app não foi registrado automaticamente

O registro manual tem duas formas, e qual delas cabe a você depende do nome de pacote, não de você. Para um nome de pacote que o Android nunca viu, você fornece os dados do pacote e o certificado público da sua chave de assinatura. Para um nome de pacote que já tem instalações, você ainda prova que possui a chave privada correspondente enviando um APK que contém um trecho fornecido pelo Google. Só o segundo caso precisa de um APK de comprovação assinado, e nenhum dos dois precisa do seu APK de produção real.

Primeiro, descubra em qual caso você está

Cinco linhas, e hoje você pertence a exatamente uma delas. Errar aqui é o engano mais caro desta seção, porque a rota do APK de comprovação é trabalho de compilação e três dessas linhas não precisam dela.

Separação dos casos tirada da ajuda do Play Console, "Registering Android package names" (resposta 16761053), acessada em 13 de agosto de 2026. Verificado

A. Registrar um nome de pacote novo

O caminho curto. Tudo acontece dentro do Play Console, nada chega perto do seu ambiente de compilação e não existe APK para produzir.

1. 01

   Abra a página Verificação de desenvolvedores do Android

   No Play Console, abra a página Verificação de desenvolvedores do Android e revise o status de registro de cada nome de pacote da conta. A página inicial do Play Console também pode mostrar informações de registro de apps.

2. 02

   Escolha Registrar nome de pacote

   Isso inicia um registro novo em vez de uma reivindicação sobre um nome que já existe.

3. 03

   Informe o nome de pacote e um nome amigável

   O nome amigável é um rótulo interno para a sua própria lista. Não é o que os usuários veem na sua ficha da loja.

4. 04

   Escolha Adicionar chave

   Aqui começa a associação entre uma chave de assinatura que você controla e o nome de pacote que está registrando.

5. 05

   Forneça o certificado público de assinatura

   Entregue o certificado público do par de chaves de assinatura do seu app. Como o Android nunca viu esse nome de pacote, o certificado é tudo de que o Google precisa. Sua chave privada nunca sai da sua máquina.

6. 06

   Envie e aguarde a confirmação

   O Google envia um e-mail quando o nome de pacote é registrado com sucesso, e o status atualizado fica visível no Play Console.

B. Registrar um nome de pacote existente

É o caminho longo, e o que todo artigo descreve como se fosse o único. Ele vale quando o nome de pacote já tem instalações no Android, porque aí o Google não aceita sua palavra: você precisa demonstrar o controle da chave privada. Dois desses passos acontecem fora do Play Console, então deixe seu ambiente de compilação aberto antes de começar.

1. 01

   Informe os dados do pacote

   Na página Verificação de desenvolvedores do Android, inicie o registro do nome de pacote que você está reivindicando.

2. 02

   Abra Selecionar chave

   O Google oferece os certificados que considera elegíveis para esse nome de pacote, com base nas evidências de instalação.

3. 03

   Escolha uma impressão digital de certificado público elegível

   Pegue a impressão digital da chave que você realmente tem. Se nada elegível aparecer, pare aqui e leia as regras de elegibilidade mais abaixo antes de tentar outra coisa.

4. 04

   Inicie o fluxo de propriedade e copie o trecho do Google

   O Google gera um trecho único para essa reivindicação. Copie exatamente. É o valor que prova que o APK que você vai compilar foi feito para essa comprovação específica.

5. 05

   Crie assets/adi-registration.properties

   Dentro da pasta assets de um projeto de APK, crie um arquivo chamado exatamente adi-registration.properties. O caminho e o nome do arquivo são literais. Um erro de digitação aqui é a forma mais comum de esse passo falhar.

6. 06

   Cole o trecho nesse arquivo

   Nada mais precisa entrar nele. O arquivo existe apenas para carregar a string.

7. 07

   Compile um APK de versão

   O Google diz que você pode compilá-lo a partir do aplicativo real ou de um projeto vazio que use o mesmo nome de pacote. O projeto vazio costuma ser mais rápido e mais seguro, porque nada do seu código de produção entra nisso.

8. 08

   Assine com a chave privada correspondente

   É esse o sentido de todo o exercício. A prova é a assinatura, não o conteúdo.

9. 09

   Envie pelo Play Console

   Envie o APK de comprovação assinado dentro do fluxo de propriedade. Não é um lançamento, não chega a nenhum usuário e o seu artefato de produção real fica de fora.

10. 10

    Acompanhe o status e o e-mail de confirmação

    O Google envia um e-mail quando o nome de pacote é registrado com sucesso, e o status atualizado fica visível no Play Console.

C. Se a sua chave de assinatura está com outra loja de apps

Algumas lojas assinam em nome do desenvolvedor, e aí você não consegue produzir sozinho um APK de comprovação assinado corretamente. O Google documenta uma rota específica para isso, e ela é curta:

1. 01

   Compile a versão e envie para essa loja

   Passe o build que carrega o trecho pelo processo normal de publicação daquela plataforma.

2. 02

   Baixe dessa loja o APK final assinado

   Você precisa do artefato como a loja o assinou, não do que você enviou.

3. 03

   Envie esse APK assinado pela loja ao Play Console

   É a assinatura da loja que satisfaz a checagem de propriedade.

Passos do fluxo tirados da ajuda do Play Console, "Registering Android package names" (resposta 16761053), acessada em 13 de agosto de 2026. Verificado

Adicionar mais chaves depois

Um nome de pacote pode ter mais de uma chave de assinatura associada. O Google diz que o console permite adicionar e verificar várias chaves de assinatura para um único pacote, e o procedimento repete o caminho B: criar assets/adi-registration.properties com o trecho daquela chave, compilar e assinar um APK de versão com a chave privada correspondente e enviá-lo. Registre primeiro o nome de pacote e depois acrescente as chaves extras.

Se nenhuma chave elegível aparecer: as regras de prioridade

A maioria dos desenvolvedores nunca vê isso. Importa quando um nome de pacote foi assinado por mais de uma chave ao longo da vida, ou quando mais de uma parte tem uma reivindicação plausível sobre ele. O Google resolve isso com uma hierarquia baseada em instalações.

Hierarquia de elegibilidade tirada da ajuda do Play Console resposta 16761053, acessada em 13 de agosto de 2026. Verificado

A leitura prática, dita com cuidado: se a sua chave de assinatura atende claramente à hierarquia acima, ela deve aparecer como diretamente elegível para a reivindicação. Isso decide se o Google deixa você registrar direto em vez de passar por um pedido analisado. Isso não conclui o registro por você. Um pacote que ficou de fora do registro automático ainda precisa passar pelo caminho B, na mão. O nível por ordem de chegada é aquele em que convém agir rápido, porque ele se decide por quem age, não por quem tem razão.

O que contas pessoais de desenvolvedor precisam enviar

Duas camadas: informações universais e documentos específicos de cada país. A parte universal é que seus dados de identidade legal e de endereço precisam bater exatamente com o perfil de pagamentos do Google vinculado à conta. A parte documental depende inteiramente do país ou da região desse perfil, e é por isso que nenhum artigo honesto pode entregar a você uma única lista mundial.

A parte que é igual em todo lugar

Contas pessoais fornecem informações de identidade legal e da conta, e a ajuda atual do Play cita entre elas o nome legal e o endereço legal. O processo de verificação usa o perfil de pagamentos do Google vinculado, e a página do Google sobre requisitos de documentos afirma que os dados de identidade pessoal, o nome da organização quando for o caso e as informações de endereço precisam bater exatamente com o que está no seu perfil de pagamentos.

A palavra "exatamente" sustenta esta seção inteira, e é o motivo de a próxima ferramenta existir.

A parte que não é igual em todo lugar

A própria página do Google diz que os documentos aceitos dependem da sua localização geográfica. O seletor de país daquela página é a autoridade para o seu caso, não uma lista reproduzida em outro lugar. Para deixar o formato do requisito concreto sem fingir que ele é universal, veja o que a página dos Estados Unidos do Google pede hoje às pessoas físicas:

Os requisitos de imagem que o Google diz sem rodeios

Eles valem para o documento com foto em si e são inequívocos, o que os torna as falhas mais baratas de eliminar antes de enviar qualquer coisa:

• O documento oficial com foto precisa estar válido e não vencido.
• A imagem precisa estar colorida.
• A imagem precisa estar nítida e bem iluminada.
• A imagem não pode ser uma fotocópia.

O Google também afirma que sua página atual de requisitos de documentos aponta documentos não aceitos como o principal motivo de falha na verificação de desenvolvedores, e que documentos falsos ou alterados podem levar a punições severas, incluindo a remoção da conta e dos apps. Nada nesta página vale esse risco.

A checagem para fazer antes de enviar qualquer coisa

O Google não publica quantas tentativas de verificação você tem, e desenvolvedores relatam com frequência chegar a um ponto em que o botão de nova tentativa simplesmente não aparece mais. Essa combinação torna um envio descuidado realmente caro. Faça esta auditoria primeiro.

O erro para conferir antes de enviar qualquer coisa

Se você levar uma única instrução deste post, leve esta: abra seu perfil de pagamentos do Google e compare o nome legal e o endereço com seus documentos, campo a campo, antes de tocar no botão de envio. O Google exige que as informações correspondam; ele não publica uma regra no nível do caractere ou da pontuação, então trate o "campo a campo" como a forma prática de cumprir o requisito e não como uma regra em si.

A primeira metade disso é o requisito declarado pelo Google. A segunda metade é do que os fóruns de suporte de 2026 estão cheios. As discussões de abril, junho, julho e agosto de 2026 seguem todas o mesmo formato: o desenvolvedor tem certeza de que os documentos estão corretos, a verificação falha sem um motivo específico e a resposta da comunidade aponta de volta para uma divergência entre a identidade enviada e o perfil de pagamentos. Em várias dessas discussões o desenvolvedor só descobriu o problema de nome no perfil depois de uma contestação sem sucesso.

O que contas organizacionais precisam

Organizações se verificam com dados legais da empresa em vez de identidade pessoal e geralmente precisam de um número D-U-N-S: um identificador único de nove dígitos emitido pela Dun and Bradstreet. A documentação do Play do Google prevê exceções para determinadas entidades públicas. O Google diz que quem não tem pode obter o número de graça, mas avisa que pode levar semanas, o que faz disso o único item desta página com prazo de espera real. As próprias páginas do Google divergem sobre quanto: as perguntas frequentes da verificação do Android dizem até 28 dias e a ajuda atual da conta do Play Console diz até 30. Este post planeja por 30.

O que mais uma organização prepara

• Dados legais da organização que batam com os seus registros societários, além do representante autorizado e das informações da conta.
• O número D-U-N-S de nove dígitos, gratuito na Dun and Bradstreet e sujeito às exceções declaradas pelo Google para determinadas organizações públicas. Essas exceções são estreitas: elas não significam que organizações públicas pulam a verificação.
• Documentação pertinente da organização e documentos de identidade do representante, seguindo as mesmas regras específicas por país e de correspondência exata que valem para contas pessoais.
• Um site verificado, se você é uma organização com distribuição completa fora do Google Play. O guia de verificação do Google diz que organizações fornecem um site que precisa ser verificado pelo Google Search Console. Essa etapa pertence ao caminho do Android Developer Console, não ao Play Console.

Uma coisa que uma conta organizacional não muda: se você também publica no Google Play, isso continua sendo trabalho no Play Console. E se você está decidindo entre pessoal e organizacional para uma conta nova, os trade-offs vão muito além da verificação, uma decisão que a comparação entre conta pessoal e conta organizacional desenvolve como deve.

O que acontece de fato se você não estiver verificado em 30 de setembro

Quatro coisas diferentes, dependendo de como o seu app chega aos usuários. O Google documenta restrições à nova instalação, às atualizações onde os controles valem, e a remoção do Google Play para pacotes do Play sem registro. Ele não documenta desinstalar à força apps que já estão nos aparelhos das pessoas.

Consequências tiradas da ajuda do Play Console resposta 16984799, do guia de verificação do Play Console do Google, do post de distribuição de 30 de março, da cronologia na ajuda do Android Developer Console e das perguntas frequentes de 22 de julho. Todas acessadas em 9 de agosto de 2026.

A afirmação com que é preciso ter mais cuidado

Essa distinção não é preciosismo. Ela muda o que você deve fazer neste mês. Uma remoção do Play é uma emergência de distribuição que você resolve registrando um pacote. Uma hipotética desinstalação em massa seria uma emergência de relacionamento com o cliente exigindo uma comunicação completamente diferente. Só uma das duas está documentada.

Como o fluxo avançado funciona de verdade

O Google documenta o fluxo avançado como um caminho lento de propósito, não como um interruptor, e o atrito é justamente o ponto: cada passo existe para impedir que alguém conduza a pessoa por ele com a ligação ainda aberta.

1. 01

   Ative o modo de desenvolvedor nas configurações do sistema

   Um primeiro movimento deliberado, para que nada aqui seja disparado sem querer nem por um atalho de um toque como os usados em golpes.

2. 02

   Confirme que ninguém está te orientando

   Uma checagem rápida de que ninguém está pressionando você a desligar uma proteção.

3. 03

   Reinicie o celular e autentique de novo

   Isso corta o acesso remoto ou uma ligação em curso que alguém pudesse usar para acompanhar o que você faz em seguida.

4. 04

   Volte depois do período de espera de proteção

   O Google descreve como uma espera de um dia, uma única vez. Depois você confirma com autenticação biométrica ou o PIN do aparelho.

5. 05

   Instale de desenvolvedores não verificados

   Você pode permitir por sete dias ou por tempo indeterminado. O aviso continua aparecendo a cada instalação e é você quem confirma.

Passos do fluxo avançado tirados das perguntas frequentes de verificação de desenvolvedores do Android do Google, acessadas em 13 de agosto de 2026. Verificado

A questão do sideloading, em um parágrafo

A fase de 30 de setembro ainda não vale para a instalação direta de APK nem para lojas de apps fora da lista participante do Google, e o Google continua a apoiar a instalação por ADB além de um fluxo avançado para usuários que escolhem conscientemente instalar de desenvolvedores não verificados. Essa é a posição atual e documentada em 9 de agosto de 2026, e é bem diferente da narrativa de que "o Google vai acabar com o sideloading" que circulou depois do anúncio original de 2025. É também explicitamente uma primeira fase, então tratar isso como resultado definitivo seria o erro espelhado. Se foram as implicações para sideloading e ecossistema aberto que trouxeram você aqui, e não um prazo do Play, isso merece um tratamento próprio e não um parágrafo dentro de um post de conformidade.

A verificação não substitui o teste fechado de 12 testadores

São dois requisitos sem relação entre si, e os dois precisam ser cumpridos quando os dois valem para você. A verificação de desenvolvedores do Android responde a "de quem são esta conta e este pacote?". A regra de acesso de produção responde a "este app foi testado por pessoas reais?". Você pode passar em um com folga e continuar completamente travado pelo outro.

O requisito do Google para contas pessoais novas sujeitas à regra não muda em nada com o programa de verificação: pelo menos 12 testadores participando continuamente de um teste fechado há 14 dias no momento em que você se inscreve para o acesso de produção.

As colunas de verificação vêm do guia de verificação do Google e da ajuda do Play Console resposta 16984799; as colunas de teste fechado vêm da ajuda do Play Console resposta 14151465 e da página de ajuda sobre teste interno. Todas acessadas em 9 de agosto de 2026. Verificado

Por que isso pega as pessoas

Porque os dois são chamados de "requisitos", os dois vivem no Play Console e os dois ficam entre um desenvolvedor e um app publicado. Então uma conta que acabou de passar pela verificação de identidade parece pronta. Depois o acesso de produção é negado, e nada nas telas de verificação explica por quê, porque essa resposta não mora ali.

A sequência que de fato coloca uma conta pessoal nova no ar é: identidade verificada, cada pacote registrado e, em separado, um teste fechado com pelo menos 12 testadores participando continuamente por 14 dias antes de se inscrever para o acesso de produção. A regra dos 14 dias consecutivos tem mais casos limite do que a maioria espera, e é a parte desta sequência que não dá para comprimir trabalhando mais.

O teste interno conta no lugar?

Não, e vale ser preciso sobre o motivo, porque "teste interno não serve para nada" também é falso. O Google permite o teste interno com até 100 testadores, e ele é um jeito realmente bom de encontrar problemas rápido. Mas o requisito de acesso de produção nomeia especificamente um teste fechado que cumpra a condição de 12 testadores por 14 dias. O teste interno é uma faixa separada, então participar dele não é o teste válido para este requisito específico.

Contas organizacionais merecem uma frase de esclarecimento aqui também: o requisito de teste para o acesso de produção está escrito expressamente para contas pessoais novas de desenvolvedor, então contas organizacionais não são a classe de conta coberta por esta regra específica dos 12 testadores. Essa é uma questão diferente da verificação, que alcança os dois tipos de conta.

Se a verificação falhou, confira isto antes de tentar de novo

Desenvolvedores relatam com frequência mensagens de recusa pouco específicas, e o Google não documenta a causa de cada recusa individual. Então o movimento útil não é adivinhar a mensagem e sim percorrer os requisitos que o Google de fato publica. Escolha abaixo o sintoma que você está vendo. Cada um leva à primeira coisa a conferir, à força da evidência por trás daquele conselho e à próxima ação segura.

Comece pelo sintoma que você consegue ver

Os dez itens abaixo estão redigidos do jeito que os desenvolvedores escrevem nos fóruns de suporte do Google, incluindo os escritos às duas da manhã. Selecionar um entrega a checagem mais valiosa para aquele sintoma em vez de uma lista de tudo o que teoricamente poderia estar errado.

O que a evidência sustenta e o que não sustenta

Os padrões de falha abaixo vêm de discussões da comunidade de ajuda para desenvolvedores do Google Play ao longo de 2026, incluindo casos do Brasil, da Índia, do Uzbequistão e várias discussões em português, além de relatos mais antigos do Reddit e do Stack Overflow. Estão agrupados pela força real da evidência, porque isso muda o que você deve fazer com eles.

O checklist antes do prazo

Cinco estados decidem se 30 de setembro é uma data na sua agenda ou um problema na sua caixa de entrada. Quatro valem para todo desenvolvedor do Play. O quinto só vale se a sua conta está sujeita à regra do teste fechado, e é o que consome tempo real de calendário.

Os quatro pontos a resolver

Marque com honestidade, não com otimismo. Cada linha liga de volta à seção que a resolve, então uma caixa sem marcar é um desvio de dois minutos e não um beco sem saída. Dois deles são condicionais, então estão escritos para poderem ser marcados quando nunca se aplicaram a você: quem teve todos os apps registrados automaticamente não tem reivindicação manual a fechar, e quem já estava verificado sem nenhuma consulta sobre documentos não tem correção a fazer.

Onde a PrimeTestLab entra e onde não entra

Primeiro o limite, dito com clareza: ninguém pode verificar a sua identidade por você. Enviar seus documentos, alinhar seu perfil de pagamentos e reivindicar seus nomes de pacote são coisas que só o titular da conta consegue fazer, e este post é toda a nossa contribuição nisso. O que cobrimos é o requisito que vem logo depois da verificação para uma conta pessoal nova: os 12 testadores reais, participando por 14 dias consecutivos.

Essa é a divisão que chega à nossa caixa de entrada sempre com o mesmo formato. O desenvolvedor passa na verificação de identidade, vê um estado verde no Play Console, imagina que o caminho está livre e depois descobre que o acesso de produção é uma porta completamente separada com um piso de duas semanas pendurado nela. Verificação é papelada, e quanto tempo leva depende dos seus documentos e da sua conta. O teste fechado é tempo de calendário que você não comprime.

Tocar o teste fechado sozinho ou entregar para alguém

A ordem que custa menos tempo

Se a verificação e o teste fechado estão os dois à sua frente, toque os dois em paralelo, não em sequência. Os 14 dias de participação contínua dos testadores são tempo real que só começa quando você de fato tem 12 pessoas inscritas, então é esse o item que decide a sua data de lançamento de verdade. Ligue esse relógio enquanto resolve os documentos, não depois.

Perguntas frequentes

Resumo

Última checagem das políticas: 13 de agosto de 2026. A distribuição de 30 de setembro do Google e a expansão de 2027 ainda estão em movimento, então datas e cobertura por país devem ser reconferidas na página de verificação de desenvolvedores do Android do Google antes de qualquer ação. Este post está programado para nova verificação em 30 de setembro de 2026 e logo depois do início da vigência, e novamente sempre que o Google publicar qualquer geografia ou data de 2027.