Resposta rápida
Em 13 de agosto de 2026, os testadores ainda conseguem instalar um APK bruto que você compartilha diretamente com eles. A aplicação do Google a partir de 30 de setembro de 2026 no Brasil, na Indonésia, em Singapura e na Tailândia alcança de início apenas sete lojas de aplicativos participantes, e as perguntas frequentes do Google de 15 de julho dizem que as instalações diretas ainda não estão cobertas. O Google planeja uma aplicação mais ampla em dispositivos certificados com Android 7 ou superior em 2027, sem anunciar uma data exata. Quando isso valer, os apps registrados com um desenvolvedor verificado mantêm o caminho de instalação de sempre, enquanto os apps não registrados continuam podendo ser instalados pelo ADB ou pelo fluxo avançado do Google. O Firebase App Distribution segue útil para QA, mas não faz a verificação de desenvolvedores Android e não conta como o teste fechado do Google Play, que exige 12 testadores participando continuamente por 14 dias.
Como este post classifica cada afirmação
- Verificado quer dizer que a afirmação vem direto de uma página atual do Google, do Android ou do Firebase. Quase tudo neste post é verificado. Verificado
- Parcial quer dizer que as fontes primárias sustentam a conclusão, mas ela exige um passo de dedução, ou que as próprias páginas do Google não tratam do caso limite. Parcial
- Relatado pela comunidade quer dizer relatos repetidos de desenvolvedores no Stack Overflow, no Reddit ou nos próprios fóruns do Google. Serve para diagnóstico, não para política. Comunidade
- Não documentado quer dizer que o Google não publicou nada sobre aquele cenário específico, e a gente diz isso em vez de chutar. Não documentado
A história que se espalhou em 2025 era simples: o Android está acabando com a instalação direta. A posição que o Google de fato documenta em agosto de 2026 é mais estreita, mais precisa e bem menos útil como manchete. O Google esclareceu e refinou o alcance da primeira fase em junho e julho de 2026 e, em 15 de julho de 2026, escreveu essa redução em uma única frase: o prazo de 30 de setembro "só se aplica às lojas participantes específicas". Boa parte da cobertura de 2025 e do início de 2026 que ainda circula foi publicada antes de essa frase existir e descreve um primeiro lançamento mais amplo do que o que o Google está aplicando.
Por isso este post é organizado em torno da decisão que você realmente precisa tomar, e não em torno da polêmica. Você tem doze amigos, colegas ou testadores e uma versão para colocar no celular deles. Ainda dá para mandar o APK por e-mail? Precisa de ADB? O Firebase App Distribution resolve? E a pergunta que chega quase toda semana na caixa de entrada da PrimeTestLab: alguma dessas coisas conta para o teste fechado de 12 testadores que o Google exige antes do acesso de produção? Cada data, número e mecanismo abaixo foi conferido nas próprias páginas do Google em 13 de agosto de 2026 e, onde o Google não publicou nada, este post marca a lacuna em vez de preenchê-la.
Os testadores ainda conseguem instalar o seu APK depois de 30 de setembro de 2026?
Sim. Pelas regras atuais do Google, um testador ainda consegue instalar um APK que você envia diretamente a ele depois de 30 de setembro de 2026. A data é real, os quatro países são reais e a aplicação é real, mas as perguntas frequentes atuais do Google dizem que o prazo "só se aplica às lojas participantes específicas". Para uma instalação direta, as mesmas perguntas frequentes dizem que ele "ainda não vai valer para o seu app".
As palavras exatas do Google, frase por frase
O prazo "só se aplica às lojas participantes específicas" · para uma instalação direta ele "ainda não vai valer para o seu app" · a aplicação cobre "dispositivos Android certificados com Android 7 ou superior" · o Google vai "expandir a exigência de verificação do Android mundialmente" em 2027
Fragmentos citados um a um das perguntas frequentes da verificação de desenvolvedores Android (atualizadas em 10 de agosto de 2026) e do anúncio de 18 de junho de 2026, ambos acessados em 13 de agosto de 2026 e escritos em inglês no original. Verificado
O que 30 de setembro toca, e o que não toca
Três linhas resolvem a questão para quase todo mundo que lê isto. A linha do meio é a que diverge de boa parte da cobertura anterior sobre essa data.
Alcançado em 30 de setembro de 2026
Instalar por uma das sete lojas participantes no Brasil, na Indonésia, em Singapura ou na TailândiaO app precisa estar registrado com um desenvolvedor verificado para a instalação comum passar. O Google afirma que a parte fora do Play desta aplicação regional inicial vale para os formatos celular e tablet.
Ainda não coberto pela primeira fase
Um APK direto: por e-mail, baixado do seu site, compartilhado no Drive ou instalado por ADBAs perguntas frequentes do Google de 15 de julho dizem que o prazo de 30 de setembro ainda não vale para a instalação direta. As lojas de aplicativos fora da lista participante também estão fora desta primeira fase. A palavra que faz o trabalho nas duas frases é ainda. Um APK do Firebase App Distribution deve herdar a mesma resposta, porque é distribuição direta de um APK assinado, mas o Google não publicou nenhuma decisão específica sobre o Firebase. Parcial, dedução
Igual dos dois jeitos
As próprias regras de publicação do Google PlayO Play exige, à parte, que todo pacote do Play seja registrado, e o teste fechado de 12 testadores para as novas contas pessoais que se enquadram não é tocado por nada disso. A verificação não encurta, não dispensa e não substitui esse teste.
Escopo tirado das perguntas frequentes da verificação de desenvolvedores Android (atualização de 10 de agosto de 2026) e do anúncio de 18 de junho de 2026 que nomeia a data, os quatro países e as sete lojas. A exigência de teste fechado do Play vem da resposta 14151465 da Ajuda do Play Console. Tudo acessado em 13 de agosto de 2026.
Por que isto não é uma brecha
"Ainda não coberto" descreve uma fase de lançamento, não uma isenção permanente, e tratar isso como isenção é o espelho exato do erro que este post está corrigindo. O Google disse que a exigência se expande mundialmente em 2027. A reação certa a esta seção é alívio quanto a setembro e preparação para o ano seguinte, que é exatamente para o que serve o checklist perto do fim. Verificado
O que muda de fato em 30 de setembro de 2026
O Google marcou a data em 18 de junho de 2026 e depois a reduziu por escrito em 15 de julho. A partir de 30 de setembro, uma instalação por uma das sete lojas nomeadas em quatro países nomeados é checada: o app precisa estar registrado com um desenvolvedor verificado. As perguntas frequentes atuais do Google dizem que essa primeira fase vale para as lojas participantes nomeadas, e que a instalação direta e as lojas não participantes ainda não estão cobertas.
Se você publica no Google Play
Registre cada pacote restante até 30 de setembro de 2026. O guia do Google para o Play Console diz para registrar todos os apps que você quer continuar distribuindo a fim de "evitar a remoção global do Google Play". Essa obrigação é global. Não tem nada a ver com os quatro países e vale mesmo que nenhum dos seus usuários more lá.
O que os usuários vivem em 30 de setembro
A aplicação no dispositivo começa só em quatro países. A primeira checagem na instalação cobre as sete lojas participantes no Brasil, Indonésia, Singapura e Tailândia. Não alcança o sideload direto nem lojas fora dessa lista.
São duas obrigações separadas de 30 de setembro, e misturá-las é a forma mais comum de ler essa data errado. O registro de pacotes no Play é global e decide se a sua ficha continua no ar; a aplicação na instalação é regional e decide o que acontece no telefone de um usuário. Verificado
As sete lojas participantes
Nomeie todas exatamente. Descrever isto como uma restrição a todas as lojas de aplicativos é amplo demais diante do texto atual do Google sobre a primeira fase: pela lista que o Google publicou, uma loja que não está nomeada aqui está fora do lançamento de 30 de setembro.
| Empresa | Loja participante | Checada a partir de 30/09 nos quatro países? |
|---|---|---|
| Google Play | Sim | |
| HONOR | HONOR App Market | Sim |
| OPlus | OPPO App Market | Sim |
| Samsung | Galaxy Store | Sim |
| Transsion | Palm Store | Sim |
| vivo | V-Appstore | Sim |
| Xiaomi | GetApps | Sim |
| Você, diretamente | E-mail, link de download, seu site, Drive e, por inferência, um APK pelo Firebase App Distribution | Não, ainda não |
| Qualquer outro | Qualquer loja de aplicativos não nomeada acima | Não, ainda não |
Lista de lojas e países do anúncio do Google de 18 de junho de 2026; a exclusão da instalação direta e das lojas não participantes vem das perguntas frequentes de verificação atualizadas em 10 de agosto de 2026. Acessados em 13 de agosto de 2026. Verificado
Os quatro países, e os formatos de aparelho dentro deles
Dois detalhes estreitam isso ainda mais e vale a pena levar junto. Para a distribuição fora do Google Play, as perguntas frequentes de verificação do Google afirmam que a aplicação nas regiões selecionadas vale de início para os formatos celular e tablet. As mesmas perguntas frequentes dizem que as proteções chegam pelo Google Play services em dispositivos Android certificados com Android 7 ou superior, que é o alcance final de dispositivos, e não um limite exclusivo de setembro.
O que não muda em setembro
A lista abaixo é curta, mas cobre o jeito como a maioria das equipes pequenas realmente move uma versão. Nada disso é afetado pela fase de 30 de setembro.
É instalação direta. Não coberta pela primeira fase.
Também é instalação direta, com a mesma resposta.
Distribuição direta de um APK assinado para testadores convidados. Veja o quadro completo na seção 08. O Google não publica nenhuma decisão específica sobre o Firebase, então isso é uma inferência a partir da regra de sideload direto, não uma isenção declarada. Parcial, dedução
O Google diz que não há mudanças no funcionamento do ADB. Seção 05.
Fora da primeira fase, pela mesma resposta das perguntas frequentes.
Essa é uma exigência do Play por si só, e é mundial. O Google disse em 18 de junho de 2026 que mais de 99% dos apps dos desenvolvedores do Play já tinham sido registrados automaticamente.
O número de 99% tem uma data colada nele
O número de mais de 99% de registro automático vem da atualização do Google de 18 de junho de 2026. Alguns materiais ainda repetem um número antigo de cerca de 98%. Use o mais novo e cite-o com a data junto, e não como um fato atemporal, porque o Google atualiza as estatísticas de adoção conforme o lançamento avança. A página de visão geral atual do Google sobre verificação de desenvolvedores agora arredonda esse mesmo número para 99%, então cite qualquer um dos dois com a fonte e a data em vez de como uma constante exata. Verificado
O que acontece quando a verificação se expande mundialmente em 2027
O Google diz que a exigência se expande mundialmente em 2027 em diante, para apps em dispositivos Android certificados com Android 7 ou superior, entregue pelo Google Play services. Ele não anunciou uma data mundial exata nem um cronograma país a país. Trate qualquer data específica de 2027 como não oficial enquanto o Google não publicar.
A linha do tempo, com o que cada data faz com um APK compartilhado
-
30 de março de 2026
A verificação começa a chegar a todos os desenvolvedores
O Google começou a liberar a verificação de desenvolvedores Android para todo desenvolvedor no Play Console e no Android Developer Console.
APK bruto Nenhuma mudança visível de instalação só por causa desta data. App não verificado Continua instalável pelo comportamento atual do Android. -
Agosto de 2026
O fluxo avançado e as contas de limited distribution vão para o mundo todo
O Google programou o lançamento mundial do fluxo avançado de instalação e das contas de limited distribution para este mês. Até 13 de agosto de 2026, as fontes analisadas nomeiam o mês, mas não um dia exato, e não estabelecem que o fluxo já chegou a todos os usuários. Parcial
APK bruto Continua disponível. App não verificado O fluxo avançado é o mecanismo pensado para preservar a instalação desses apps. -
30 de setembro de 2026
A exigência de registro começa em sete lojas, quatro países
As instalações pelo Google Play, HONOR App Market, OPPO App Market, Samsung Galaxy Store, Transsion Palm Store, vivo V-Appstore e Xiaomi GetApps no Brasil, na Indonésia, em Singapura e na Tailândia exigem que o app esteja registrado com um desenvolvedor verificado. Verificado
APK bruto Ainda não coberto por esta fase inicial. App não verificado Uma instalação por loja participante pode ser restringida; o caminho direto fica intocado nesta fase. -
2027 em diante
Expansão mundial para dispositivos Android certificados
A verificação se expande para o mundo todo nos apps em dispositivos Android certificados com Android 7 ou superior. É nesta fase que a resposta sobre a instalação direta muda. Verificado
APK bruto App registrado: o caminho normal de instalação. App não registrado: fluxo avançado ou ADB, pelo modelo anunciado. App não verificado Fluxo avançado ou ADB continuam sendo o caminho anunciado. -
Data exata em 2027
Não anunciada até 13 de agosto de 2026
O cronograma publicado pelo Google diz 2027 em diante, e nada mais preciso. Também não foi divulgada nenhuma sequência de países. Não documentado
APK bruto Não faça planos em cima de um dia específico. App não verificado Não faça planos em cima de um dia específico.
Cronologia tirada do post de lançamento do Google de 30 de março de 2026, do anúncio de 18 de junho de 2026 e das perguntas frequentes da verificação de desenvolvedores Android atualizadas em 10 de agosto de 2026. Acessados em 13 de agosto de 2026.
O prazo que não existe
"1º de janeiro de 2027" aparece em coberturas secundárias e em respostas de assistentes de IA. Não está em nenhuma fonte do Google analisada para este post. O Google se comprometeu com 2027 em diante sem nomear um dia. Se algum plano seu depende de saber essa data, a situação honesta é que ninguém fora do Google sabe ainda, e a proteção prática é ter os seus pacotes registrados bem antes de o ano começar. Não documentado
APK verificado ou não verificado: o que o Android checa de verdade
"Estou verificado?" é a pergunta errada quando vem sozinha. A verificação de desenvolvedores Android cria o que o Google chama de vínculo formal e verificável entre uma identidade de desenvolvedor, o nome do pacote de um app e a chave ou as chaves de assinatura desse pacote. A verificação de identidade é um elo dessa corrente, não a corrente inteira.
A corrente, elo por elo
Quem você é, confirmado uma vez pelo Play Console ou pelo Android Developer Console.
Uma vez por contaO identificador do app, por exemplo com.example.app, registrado com aquela identidade verificada.
A propriedade é provada enviando um APK assinado com a sua chave privada. O Console permite adicionar e verificar várias chaves para um mesmo pacote.
Por chave, não por versãoOnde a corrente está completa, o Google diz que a experiência normal de instalação dos usuários se mantém quando a aplicação mais ampla valer.
O resultado que você querCorrente descrita nos guias de verificação de desenvolvedores Android do Google, incluindo a descrição da prova de propriedade, e o suporte a várias chaves de assinatura documentado nas perguntas frequentes de verificação. Acessados em 13 de agosto de 2026. Verificado
O Google é explícito ao dizer que a instalação direta é fundamental para o Android e que desenvolvedores verificados podem continuar distribuindo diretamente. A nuance que essa frase esconde é que uma instalação tranquila depende de o app estar registrado, e não apenas de você ter passado por uma checagem de identidade. É por isso que este post diz "registrado com um desenvolvedor verificado" todas as vezes, em vez do mais curto e mais frouxo "app verificado".
E se você usa uma chave de depuração ou uma chave de assinatura separada para QA?
É aqui que as equipes de QA de verdade se enrolam, porque é completamente normal entregar uma versão assinada com a chave de depuração aos testadores internos e uma versão assinada com a chave de lançamento à loja. São certificados diferentes sobre o mesmo nome de pacote.
Auditoria de chaves de assinatura, quatro perguntas
- Qual certificado realmente assina o APK que seus usuários instalam? É esse que deve ser registrado. No Play App Signing, a chave de assinatura do app assina o APK instalado pelo Google Play, enquanto a chave de upload apenas autentica o artefato que você envia ao Play e não é automaticamente o certificado da versão instalada. Uma chave de depuração, de CI, de QA ou de upload só importa para a distribuição direta se for ela que assina o APK entregue aos testadores.
- As relevantes estão registradas no pacote? O Google permite adicionar e verificar várias chaves de assinatura para um mesmo nome de pacote, então você não é obrigado a espremer tudo em uma chave só.
- Não presuma que a verificação de identidade cobre todas as chaves. Passar pela etapa de identidade não abençoa silenciosamente todo certificado que você já usou.
- Dois APKs com o mesmo nome de pacote e assinaturas diferentes não se substituem. Isso é comportamento comum de assinatura de apps Android e é bem anterior à verificação, mas é fácil confundir com um problema de verificação de desenvolvedor. Veja a seção 12.
Cinco casos limite que o Google realmente respondeu
Estas cinco perguntas aparecem o tempo todo e todas têm resposta publicada, então não é preciso adivinhar.
Perguntas de escopo com resposta documentada
- Android 6 ou anterior? Fora do escopo declarado. O Google diz que a aplicação cobre dispositivos Android certificados com Android 7 ou superior, via serviços do Google Play. Verificado
- Dispositivos não certificados ou ROMs personalizadas sem serviços do Google Play? O Google descreve essa aplicação para dispositivos Android certificados, via serviços do Play. Não generalize a regra para qualquer ROM personalizada ou dispositivo não certificado, porque ficam fora do mecanismo que o Google documenta. Não documentado para esses dispositivos
- Apps corporativos em dispositivos gerenciados? Apps distribuídos pela loja da sua organização para dispositivos gerenciados não precisam concluir a verificação, porque o seu administrador de TI já os avaliou. Mesmo assim o Google recomenda registrá-los, caso o app também seja instalado de outra fonte ou em um dispositivo não gerenciado. Verificado
- Onde confiro se um pacote está registrado? Desenvolvedores do Play: a página de verificação de desenvolvedor Android no Play Console, que mostra o status ao lado de cada app. Desenvolvedores fora do Play: a aba Nomes de pacote no Android Developer Console, com Registrado, Não registrado ou Rascunho. O Android Studio Panda 4 e superiores também mostram o status ao gerar um APK ou App Bundle assinado. Verificado
- Desenvolvedores fora do Play pagam 25 dólares? A conta do Android Developer Console com distribuição completa custa 25 dólares. A conta de distribuição limitada é gratuita, não exige documento oficial e para em 20 dispositivos autorizados. Se você já publica no Google Play, gerencia a verificação no Play Console em vez de abrir uma conta separada. Confirme antes a disponibilidade: em 13 de agosto de 2026 o acesso antecipado ainda estava fechado. Disponibilidade parcial
O Firebase também exige assinatura, por outro motivo
O Firebase App Distribution exige que um APK esteja assinado com uma chave de depuração ou uma chave de assinatura de app antes de distribuí-lo. Isso é uma exigência do Firebase sobre a validade da versão, não uma etapa da verificação de desenvolvedores Android. Os dois sistemas usam a palavra "registrar", e manter os dois separados é uma distinção importante em todo este assunto. A seção 08 separa os dois. Verificado
A distinção entre chave de upload e chave de assinatura também explica o chamado de Firebase mais comum. Uma cópia do seu app instalada pelo Play pode estar assinada com a chave de assinatura do Google Play, enquanto o APK do Firebase que você dá ao mesmo testador é assinado localmente com uma chave de upload, de release ou de depuração. O Android não instala um por cima do outro se as identidades de assinatura aceitas não baterem, então o testador vê uma falha que parece problema de verificação e não é. Verificado
O ADB continua liberado, mas é um fluxo de desenvolvedor
O compromisso mais claro do Google em todo este programa, tirado das perguntas frequentes de verificação: não há mudanças no funcionamento do ADB. Desenvolvedores e usuários avançados podem continuar instalando apps por ali, e o período de espera de 24 horas do fluxo avançado não vale para instalações por ADB. É o caminho técnico mais durável deste post, e também o menos adequado para testadores comuns.
Serve para
- Você, no seu próprio aparelho, o dia inteiro
- Uma equipe técnica de QA que já tem o Android Studio instalado
- Pipelines de CI e fazendas de dispositivos
- Instalar uma versão não registrada sem esperar o atraso de um dia do fluxo avançado
- Um colega sentado ao seu lado com um cabo USB
Não serve para
- Doze amigos, parentes ou testadores recrutados
- Qualquer pessoa que você não consiga guiar pelas opções do desenvolvedor por telefone
- Testadores remotos em outros países, sem cabo e sem notebook
- Iteração rápida: cada versão nova exige acesso ao aparelho e mais um comando de instalação, mesmo que o testador não refaça toda a configuração
- Qualquer coisa que você queira que o Google Play conte. As instalações por ADB são invisíveis para as exigências de teste do Play
O que um testador precisa fazer antes
A documentação de ferramentas do próprio Google é direta sobre o pré-requisito: para usar o ADB por USB, você precisa ativar a depuração USB nas opções do desenvolvedor do aparelho. Em um celular atual, isso quer dizer achar o número da versão, tocar nele sete vezes para liberar as opções do desenvolvedor e então ativar a depuração USB dentro de uma tela de configurações que exibe um aviso. Esse fluxo é prático para um testador técnico e pesado para alguém que só se ofereceu para experimentar o seu app.
A configuração não se repete a cada versão, e esse é o detalhe que a maioria dos textos erra. Depois que o testador autoriza sua estação de trabalho, essa autorização continua valendo até ele revogá-la ou esquecer o dispositivo. Uma versão nova custa, então, mais um adb install -r e acesso ao telefone, não outra passagem pelas opções do desenvolvedor. O Android 11 e superiores também têm depuração sem fio: o testador pareia o telefone com a estação uma vez, por QR code ou código de pareamento, e depois você instala pela rede enquanto os dois estiverem nela, sem cabo. Isso tira o cabo, não o pré-requisito técnico.
Os três comandos que cobrem quase toda instalação em testador. Nada aqui é novidade de 2026; é o fluxo que o Google diz estar inalterado.
adb devicesadb install app-release.apkadb install -r app-release.apkO que pega as pessoas de surpresa: o -r só funciona quando o APK novo está assinado com o mesmo certificado do que já está instalado. Uma versão assinada com outra chave precisa ser desinstalada antes, e isso leva junto os dados do app. Isso é comportamento padrão de assinatura de apps Android, não uma regra de verificação.
Use o ADB como plano B, não como plano
Pelo modelo anunciado pelo Google, o ADB é um plano B documentado para instalar apps não verificados, inclusive durante o lançamento mais amplo previsto. É o caminho que continua funcionando quando uma versão não está registrada e o testador não vai esperar um dia inteiro. Ainda assim vale reconferir a política antes de apostar nessa premissa em 2027. O que ele não é: um jeito de embarcar doze pessoas comuns, e ele nunca vai atender à exigência de teste do Google Play para o acesso de produção. Verificado
O que é o fluxo avançado do Android para apps não verificados?
O Google criou um caminho deliberado para o usuário que quer instalar mesmo assim um app de um desenvolvedor não verificado. É uma configuração única com uma etapa de atrito no meio: ativar o modo de desenvolvedor, confirmar que ninguém está orientando você, reiniciar, esperar um dia, se autenticar e então permitir instalações não verificadas por 7 dias ou por tempo indeterminado. A espera de 24 horas faz parte dessa configuração, não é um atraso antes de cada APK.
-
01
Ativar o modo de desenvolvedor
O usuário liga o modo de desenvolvedor ou a configuração equivalente no aparelho dele.
Google: evita acionamentos acidentais e os desvios de um toque usados em golpes sob pressão -
02
Confirmar que ninguém está orientando o usuário
O usuário confirma que nenhuma outra pessoa está guiando essa mudança de segurança.
Google: uma checagem rápida de que ninguém está te convencendo a desligar sua segurança -
03
Reiniciar e entrar de novo na conta
O aparelho reinicia e o usuário faz login novamente.
Google: corta o acesso remoto ou a chamada ativa que um golpista usa para te observar -
04
Esperar 24 horas, uma vez só
O Google descreve isto como uma espera única, de um dia. Ela acontece durante a configuração, e é a etapa que todo mundo relata errado.
Não são 24 horas antes de cada APK. Uma vez, por conta. -
05
Confirmar a identidade no aparelho
O usuário confirma a mudança com biometria ou com o PIN do aparelho.
Google: biometria ou PIN confirma que é o dono do aparelho que está fazendo a mudança -
06
Permitir instalações não verificadas por 7 dias ou por tempo indeterminado
Configuração concluída. O usuário escolhe a duração e, a partir daí, consegue passar pelo aviso de desenvolvedor não verificado na hora de instalar.
A escolha é dele, o risco é dele, o aparelho é dele
Sequência, redação e opções de duração tiradas das perguntas frequentes da verificação de desenvolvedores Android, acessadas em 13 de agosto de 2026. O Google publica um motivo para cada etapa deste fluxo, então as notas acima reproduzem essa justificativa em vez de deduzi-la. Verificado
Três coisas que as pessoas entendem errado
"Então toda instalação precisa de uma espera de 24 horas?"
Não. O Google descreve uma espera única, de um dia, dentro da configuração. Depois disso o usuário escolhe 7 dias ou tempo indeterminado para o período em que as instalações não verificadas continuam permitidas.
"Eles refazem isso a cada celular novo?"
O Google diz que não. As perguntas frequentes descrevem a configuração como uma vez por conta, valendo em um aparelho novo.
"O ADB também precisa da espera?"
Não. O Google afirma explicitamente que o período de espera de 24 horas não vale para instalações por ADB. Seção 05.
As opções do desenvolvedor não precisam continuar ligadas
Um testador pode desligar de novo as opções do desenvolvedor assim que o fluxo avançado estiver ativado. As perguntas frequentes do Google dizem isso diretamente: não é preciso manter as opções do desenvolvedor ligadas, porque assim que você faz a mudança no aparelho a configuração fica ativa. Isso importa para testadores cujos apps bancários ou corporativos reclamam quando as opções do desenvolvedor ficam ligadas. O Google também diz que a configuração é feita uma vez por conta e passa para um aparelho novo, então não se repete a cada app nem a cada telefone. Verificado
Já está no ar agora?
Status honesto em 13 de agosto de 2026
O Google programou o lançamento do fluxo avançado para o mundo todo em agosto de 2026. As fontes analisadas para este post nomeiam o mês, mas não um dia exato, e nenhuma delas estabelece que o fluxo já chegou a todos os usuários. Então o certo a dizer a um testador hoje é que o caminho existe e está programado, e não que ele com certeza vai conseguir usar hoje à tarde. Confira as páginas de verificação do Google antes de montar um roteiro de suporte em cima disso. Parcial
A leitura prática para um desenvolvedor: o fluxo avançado é uma resposta real e documentada para "um usuário ainda consegue instalar o meu app não verificado?" e uma resposta ruim para "como eu levo uma versão a doze testadores esta semana?". Um atraso de segurança de um dia no meio do embarque acrescenta atrito de verdade para testadores casuais ou remotos. Se os seus testadores são usuários comuns, os caminhos que respeitam o tempo deles estão comparados na seção 09.
O que acontece com os APKs que já estão instalados?
A documentação do Google trata de instalar e atualizar. Quando a aplicação valer, um app não registrado não pode ser instalado nem atualizado normalmente, e o Google diz que uma atualização comum "vai falhar" sem o fluxo avançado ou o ADB. O que a documentação analisada não diz é que as cópias já instaladas no celular das pessoas serão removidas ou impedidas de abrir.
| Situação quando a aplicação mais ampla valer | Resultado documentado | Evidência |
|---|---|---|
| O app já está instalado e o usuário simplesmente abre | A documentação do Google que analisamos não anuncia remoção forçada nem bloqueio de execução. Ela trata de instalação e de atualizações. | Parcial |
| Um usuário tenta instalar um app não registrado do jeito normal | A instalação normal é restringida. | Verificado |
| O usuário ativou o fluxo avançado | O app não registrado pode ser instalado. | Verificado |
| A instalação passa pelo ADB | O app não registrado pode ser instalado. Nenhuma espera do fluxo avançado se aplica. | Verificado |
| Um app não registrado já instalado recebe uma atualização comum, com o fluxo avançado desligado | O Google diz que a atualização falha. | Verificado |
| Esse mesmo app é atualizado pelo ADB | Permitido, pela exceção anunciada pelo Google. | Verificado |
Comportamento tirado das perguntas frequentes da verificação de desenvolvedores Android, acessadas em 13 de agosto de 2026. A primeira linha registra a ausência de um mecanismo anunciado, o que não é a mesma coisa que a promessa de que o comportamento nunca vai mudar.
Não escreva "o seu app vai ser apagado"
É a afirmação mais viral deste assunto e ela não se sustenta. A formulação correta, usada em todo este post, é: o Google documenta restrições de instalação e de atualização; ele não anunciou que as cópias já instaladas serão removidas dos aparelhos nem impedidas de abrir. Relatar a ausência de uma fonte é honesto. Transformar essa ausência em garantia de segurança ou em previsão de exclusão em massa não é. Parcial, ausência de fonte
A distinção muda o que você deve fazer na prática. Uma atualização bloqueada é um problema operacional real e documentado: um testador afetado pode ficar preso em uma versão antiga porque a atualização não instala pelo caminho normal, e ele talvez nunca conte isso, porque do lado dele não aconteceu nada. Uma desinstalação em massa seria uma emergência de outro tipo, exigindo uma comunicação completamente diferente. Só uma das duas está documentada.
Onde o Firebase App Distribution entra depois da verificação
O Firebase App Distribution é um jeito de colocar versões de pré-lançamento nos aparelhos dos testadores. Ele não é um sistema de verificação, não é uma faixa de teste do Google Play e não isenta nada da verificação de desenvolvedores Android. O que ele faz bem é tirar o trabalho manual de entregar uma versão assinada a uma lista de pessoas.
Como o fluxo de APK funciona na prática
Você envia um APK assinado ao console do Firebase. O Firebase exige que ele esteja assinado com uma chave de depuração ou uma chave de assinatura de app.
Selecione grupos de testadores ou testadores individuais para aquela versão.
Os testadores recebem o convite e instalam a versão distribuída.
As versões distribuídas ficam disponíveis por 150 dias. Os convites aos testadores expiram depois de 30 dias, e o Firebase avisa 5 dias antes disso.
Fluxo, exigência de assinatura, retenção de 150 dias das versões e expiração dos convites em 30 dias tirados da documentação Android do Firebase App Distribution, acessada em 13 de agosto de 2026. Verificado
Dois relógios de expiração, dois chamados de suporte diferentes
A expiração do convite em 30 dias e a retenção da versão por 150 dias são coisas separadas. Um testador que ignora o e-mail por cinco semanas fica com o convite vencido mesmo com a versão continuando perfeitamente viva. Isso gera aquela mensagem confusa de "o link está quebrado" que não tem nada a ver com verificação, com assinatura nem com o Android. Verificado
O Firebase continua funcionando durante a fase de setembro?
Quase certamente sim, e importa como se chega a essa conclusão. O fluxo de APK do Firebase é distribuição direta de um APK assinado a testadores convidados. As perguntas frequentes do Google dizem que a instalação direta não está coberta pela fase de 30 de setembro. Junte os dois fatos e a distribuição de APK pelo Firebase deve continuar utilizável durante essa primeira fase.
Essa conclusão é uma dedução, e está marcada como tal
Nenhuma fonte do Google cita o Firebase App Distribution e lhe concede uma isenção. A conclusão acima decorre de dois fatos verificados: as instalações diretas estão fora da aplicação inicial de setembro, e o fluxo de APK do Firebase é distribuição direta. É uma dedução sólida e continua sendo uma dedução, e é por isso que este post a classifica em vez de afirmá-la sem ressalva. Parcial, dedução
Distribuir APK e distribuir AAB pelo Firebase não são a mesma coisa
Esta é a nuance que quase todo artigo achata. O Firebase aceita os dois, e eles seguem caminhos diferentes até o celular do testador.
| Fluxo do Firebase | Como a versão chega ao testador | Como pensar nisso para a verificação |
|---|---|---|
| APK | O Firebase distribui o APK assinado direto aos testadores convidados. | Distribuição direta. Se comporta como a via da instalação direta, inclusive em setembro. Parcial |
| Android App Bundle (AAB) | O fluxo de AAB do Firebase se integra ao internal app sharing do Google Play. | É um caminho ligado ao Play, então não raciocine sobre ele como se fosse a via do APK bruto. O Google não afirmou como ele é tratado na aplicação de setembro. Integração verificada Aplicação não documentada |
Um AAB não pode ser instalado diretamente
Antes de qualquer pergunta sobre verificação existe uma mais simples em que muita gente tropeça: um Android App Bundle não pode ser instalado diretamente em um telefone. Um arquivo .aab é um formato de publicação, não um pacote pronto para o dispositivo. O Google Play, o fluxo AAB do Firebase ligado ao Play, ou o bundletool precisa transformá-lo em APKs antes. Então, se você precisa de um arquivo para enviar por e-mail, subir no Drive ou entregar direto a um testador, gere um APK. A própria documentação de build do Android diz que um app bundle não pode ser implantado diretamente em um dispositivo. Verificado
Ou seja, "o Firebase continua funcionando?" tem duas respostas, dependendo do arquivo que você envia. Quando escrever sobre isso, ou quando perguntar a um colega, especifique distribuição de APK pelo Firebase ou distribuição de AAB pelo Firebase. A forma abreviada esconde um detalhe que muda a análise de verdade.
O Firebase App Distribution conta para a regra dos 12 testadores?
Não. A exigência do Google para o acesso de produção nas contas que se enquadram pede pelo menos 12 testadores participando de um teste fechado do Google Play, sem interrupção, nos 14 dias anteriores. Os testadores do Firebase não estão participando de um teste fechado do Play, então testar pelo Firebase não atende à exigência, por mais gente que participe e por mais a fundo que teste.
| Pergunta | Firebase App Distribution | Teste fechado do Google Play |
|---|---|---|
| Para que serve? | Levar versões de pré-lançamento aos testadores rapidamente | Cumprir a etapa do Play antes da produção, e testar na loja |
| Onde os testadores entram? | Em um e-mail de convite do Firebase | Em um link de adesão do Play, na faixa fechada |
| Registra o seu app para a verificação de desenvolvedores Android? | Não o "registrar o seu app" do Firebase é um processo completamente diferente | Não o registro de pacotes é uma tarefa à parte |
| Atende à exigência de 12 testadores por 14 dias seguidos? | Não | Sim para os testadores e as contas que se enquadram |
| Ainda vale a pena usar? | Sim como canal de QA, ao lado do teste fechado | Sim é o caminho exigido |
Exigência do Play na resposta 14151465 da Ajuda do Play Console; comportamento do Firebase na documentação do Firebase App Distribution. Ambos acessados em 13 de agosto de 2026. Os dois produtos definem processos diferentes que dividem a palavra "registrar". Verificado
O padrão que isso cria merece nome, porque custa duas semanas às pessoas. Um desenvolvedor faz um teste realmente rigoroso no Firebase, com quinze testadores engajados, conclui que a etapa de teste está resolvida, abre o Play Console para solicitar o acesso de produção e descobre que o relógio de 14 dias nem começou. A seção 10 coloca as duas exigências lado a lado para que isso não aconteça com você.
O melhor jeito de levar uma versão a 12 testadores em 2026
Não existe um vencedor único, porque os métodos resolvem problemas diferentes. Um APK bruto é a coisa mais simples que funciona hoje. O ADB é o mais durável e o menos usável. O Firebase é o melhor canal puro de QA. E só um método desta página atende à exigência do Google Play para o acesso de produção, que é o que decide de fato a sua data de lançamento.
Verificador de método de distribuição
Nada é enviado a lugar nenhum. A lógica roda no seu navegador usando o escopo publicado pelo Google, a documentação do Firebase e a regra de acesso de produção do Play.
1 Como você está levando a versão até eles?
2 Onde estão os seus testadores?
3 O app está registrado com um desenvolvedor verificado?
Escopo tirado das perguntas frequentes de verificação do Google (10 de agosto de 2026), da documentação do Firebase App Distribution e da resposta 14151465 da Ajuda do Play Console. Acessados em 13 de agosto de 2026.
Os sete métodos, lado a lado
A ferramenta responde a uma situação. Esta tabela responde a todas, incluindo as duas colunas que as pessoas pulam até ser tarde demais: o comportamento anunciado para 2027 e se o método faz alguma coisa pela sua solicitação de acesso de produção no Play.
| Método | O que o testador precisa fazer | Primeira fase de 30/09/2026 | Modelo anunciado para 2027 | Conta para os 12/14 do Play? | Veredito prático |
|---|---|---|---|---|---|
| APK bruto por e-mail, Drive ou site | Baixar o APK e permitir a instalação a partir daquela origem | Continua viável a instalação direta ainda não está coberta | Um app registrado instala normalmente; espera-se que um não registrado precise do fluxo avançado ou do ADB | Não | Ótimo para um QA pontual hoje. Não é o teste do acesso de produção. |
| ADB | Ativar as opções do desenvolvedor e a depuração USB, conectar e instalar com as ferramentas de desenvolvimento | Sim | Sim o Google preserva o ADB explicitamente | Não | Durável, mas técnico demais para testadores comuns. |
| Firebase App Distribution, APK | Aceitar o e-mail de convite e instalar a versão distribuída | Provavelmente não afetado pela regra de sideload direto. Nenhuma decisão específica sobre o Firebase. Parcial | Um pacote registrado deve continuar tranquilo; um não registrado segue o modelo mais amplo da instalação direta | Não | Excelente fluxo de QA. Não substitui o teste do Play. |
| Firebase App Distribution, AAB | Recebe a versão por um fluxo integrado ao internal app sharing do Play | Não documentado é ligado ao Play pelo internal app sharing; o Google não afirmou como esse caminho é tratado Não documentado | Depende do Play e do registro do pacote | Não | Útil, e merece explicação própria em vez de ser jogado no mesmo balaio do APK pelo Firebase. |
| Teste interno do Google Play | Entrar no teste interno e instalar pelo Play | Viável para um app do Play devidamente registrado | Viável | Não não substitui o teste fechado exigido | Bom QA rápido dentro do Play. Até 100 testadores. |
| Teste fechado do Google Play | Entrar pelo link do teste fechado e continuar participando | Viável | Viável | Sim para os testadores e as contas que se enquadram | O caminho exigido para as novas contas pessoais atingidas que buscam o acesso de produção. |
| Limited distribution do Android | O aparelho dele precisa estar autorizado dentro do sistema de limited distribution | Programado para agosto de 2026, acesso antecipado ainda fechado Parcial | Pensado como um caminho durável para públicos pequenos | Não | Para quem faz app por hobby e compartilha com até 20 aparelhos. Gratuito, sem documento oficial, não publica no Play. |
Fontes: as perguntas frequentes e os guias de verificação do Google, a documentação de ferramentas do ADB, a documentação do Firebase App Distribution, a página de limited distribution, e a Ajuda do Play Console sobre teste interno e sobre as exigências de teste para o acesso de produção. Tudo acessado em 13 de agosto de 2026.
A recomendação honesta
Toque duas frentes em paralelo, porque elas respondem a perguntas diferentes. Use o que colocar a versão nos aparelhos mais rápido para o QA de verdade: um APK bruto para um colega, o Firebase para um grupo, o ADB quando você precisa passar por cima de tudo. Depois, separadamente e começando o quanto antes, rode o teste fechado do Play se a sua conta está sujeita à exigência do acesso de produção, porque esse é medido em dias de calendário e não dá para comprimir trabalhando mais.
O erro que vale evitar é tratar as duas frentes como sequenciais. Terminar um teste completo no Firebase não adianta um único dia no contador de 14 dias.
A verificação de desenvolvedor não substitui o teste fechado do Google Play
São duas exigências sem relação entre si que as pessoas fundem em uma única caixinha mental. A verificação responde "quem fez e assinou este pacote?". O teste fechado responde "esta conta cumpriu o teste do Google antes da produção?". Cumprir uma delas não faz absolutamente nada pela outra.
Modelo de verificação tirado dos guias de verificação de desenvolvedores Android do Google; exigência de teste tirada da resposta 14151465 da Ajuda do Play Console e da página de teste interno (resposta 9845334). Acessados em 13 de agosto de 2026.
Por que "o teste interno conta, afinal é um teste do Play" está errado
O Google permite até 100 testadores em um teste interno, o que faz dele parecer a opção mais séria. Mas a exigência para o acesso de produção é escrita em torno de uma faixa específica: os testadores que contam precisam ter participado de um teste fechado nos últimos 14 dias seguidos. O teste interno é outra faixa, então ele não atende a essa frase.
Uma nota sobre a fonte desta afirmação
O Google não publica uma frase dizendo "o teste interno não conta". O que ele publica é uma exigência que especifica um teste fechado. A conclusão vem da definição, e não de uma citação, e este post a apresenta assim em vez de colocar palavras na boca do Google. Verificado pela definição da exigência
Os números, e de onde eles vieram
Dois pedaços de história resolvem dúvidas que aparecem o tempo todo. O Google anunciou a exigência em 9 de novembro de 2023, e a política atual a aplica às contas pessoais criadas depois de 13 de novembro de 2023: são duas datas diferentes que querem dizer coisas diferentes. E o mínimo era originalmente 20 pessoas por pelo menos duas semanas; o próprio guia comunitário do Google diz que a redução para 12 aconteceu em dezembro de 2024. Relatos de desenvolvedores da época situam a mudança no Play Console em 11 de dezembro de 2024, mas não foi possível localizar nenhum anúncio datado do Google para esse dia exato, então trate o dia como relatado, e não como oficial. Parcial
As contas de organização ficam fora desta etapa específica: a exigência mira as contas pessoais que se enquadram. E a taxa é a mesma nos dois casos, um registro único de US$ 25 no Google Play. Se você quer a comparação completa dos tipos de conta em vez de um parágrafo, isso está no post conta pessoal ou conta de organização.
Dez afirmações sobre isto que estão desatualizadas
Boa parte da cobertura sobre a verificação de desenvolvedores Android foi escrita antes de o Google reduzir o alcance da primeira fase em junho e julho de 2026. As afirmações abaixo não são mentiras; várias eram corretas quando foram publicadas. Elas apenas descrevem uma versão da política que não corresponde mais às páginas atuais do Google.
Afirmação Toda instalação direta de APK fica bloqueada a partir de 30 de setembro nos quatro países.
Regra atual Falso diante das perguntas frequentes do Google de 15 de julho de 2026. 30 de setembro cobre sete lojas participantes. As instalações diretas ainda não estão cobertas. Verificado
Afirmação A verificação de desenvolvedor significa que você não consegue instalar um app de um desenvolvedor não verificado.
Regra atual Absoluto demais. O ADB continua disponível, e o Google criou o fluxo avançado justamente para apps não verificados. Verificado
Afirmação O prazo mundial é 1º de janeiro de 2027.
Regra atual Sem respaldo. O Google anunciou "2027 em diante" e nenhuma data mundial exata. Não documentado
Afirmação Depois que a sua identidade é verificada, qualquer APK que você assinar está em ordem.
Regra atual Incompleto. O nome do pacote e as chaves de assinatura relevantes também precisam estar registrados. Verificado
Afirmação O Firebase App Distribution verifica o seu app Android.
Regra atual Confusão entre coisas diferentes. O "registrar o seu app" do Firebase e o registro da verificação de desenvolvedores Android são sistemas distintos. Verificado
Afirmação Os testadores do Firebase contam para os 12 testadores do Google.
Regra atual Falso. O Google exige 12 testadores participando do teste fechado do Play. Verificado
Afirmação O teste interno do Play conta, porque também é um teste do Play.
Regra atual Não para esta etapa. A exigência do acesso de produção nomeia especificamente um teste fechado. Verificado pela definição
Afirmação Os apps não verificados que já estão instalados vão ser apagados.
Regra atual Sem respaldo. O Google documenta restrições de instalação e de atualização e não anuncia nenhuma remoção automática das cópias instaladas. Parcial, ausência de fonte
Afirmação O fluxo avançado com certeza já está no ar em todo lugar, porque estamos em agosto.
Regra atual Forte demais. O Google programou um lançamento mundial em agosto de 2026 sem publicar um dia exato de entrada no ar. Parcial
Afirmação Cerca de 98% dos apps do Play foram registrados automaticamente.
Regra atual Desatualizado. A atualização do Google de 18 de junho de 2026 diz mais de 99%. Verificado
Onde as duas páginas do Google parecem se contradizer
Vale nomear isto porque quem lê com atenção vai esbarrar. O texto geral da Ajuda do Google diz que os apps cujos desenvolvedores não cumpriram a exigência ficam indisponíveis para novas instalações nos países aplicáveis, o que soa mais amplo do que a exceção limitada às lojas. As perguntas frequentes, mais específicas e atualizadas em 10 de agosto de 2026, dizem que o prazo de 30 de setembro vale só para as lojas participantes e ainda não alcança a instalação direta.
Como este post resolve isso, e por que é um julgamento editorial
Interpretação editorial. Para a primeira fase de 30 de setembro, este post segue a resposta mais recente e específica das perguntas frequentes, porque ela cita explicitamente o sideload direto e as lojas não participantes em vez de deixá-los implícitos, e porque a resposta sobre sideload direto tem data de 15 de julho de 2026. O texto de ajuda geral descreve o programa como um todo. O Google não publicou nenhuma regra formal dizendo que uma fonte se sobrepõe à outra, então esta é a nossa escolha editorial, dita abertamente em vez de escondida. As duas páginas se leem melhor como descrições de camadas diferentes do mesmo lançamento do que como uma contradição. Interpretação editorial
Do sintoma à solução: o que está errado de verdade
Ache a frase que você ou o seu testador realmente disse. Uma causa comum de falha na instalação ou na atualização em um testador é uma incompatibilidade de certificado de assinatura, que é comportamento normal do Android, não tem nada a ver com a verificação de desenvolvedor e é uma década mais antiga que ela.
"Meu amigo não consegue instalar o APK depois da verificação"
Explicação provável. Quase certamente não é a verificação de desenvolvedor. Antes do lançamento mais amplo de 2027, uma instalação direta de APK que falha não é causada pela regra de 30 de setembro, porque essa regra ainda não alcança o caminho direto. A causa real mais comum é uma incompatibilidade de certificado de assinatura: o telefone já tem uma cópia do app assinada com outro certificado.
A checagem mais segura, nesta ordem. Percorra primeiro as falhas comuns de instalação do Android: uma cópia instalada assinada com outro certificado, um versionCode menor que o da versão instalada, uma versão do Android ou arquitetura de CPU sem suporte, um download truncado ou corrompido, falta de armazenamento, a permissão de origem de instalação não concedida ao app que entrega o arquivo, ou um aviso do Play Protect que o testador dispensou. Depois, e só se a instalação passar por uma loja participante ou se a aplicação mais ampla já tiver começado, confira o registro do pacote e da chave de assinatura.
Conceito verificado
"O Firebase diz que a instalação falhou por cima da minha versão do Play"
Explicação provável. Um testador que já tem instalada uma versão assinada pelo Play não consegue atualizá-la por cima com um APK do Firebase assinado por outro certificado. Desenvolvedores relataram exatamente isso, e os testadores quase nunca entendem a mensagem de erro.
Próxima checagem mais segura. Compare os certificados de assinatura dos dois arquivos. Ou use um caminho de assinatura compatível, ou peça ao testador para desinstalar a versão antiga primeiro, o que leva junto os dados dela, então avise a pessoa.
Exemplo relatado pela comunidade
"Preciso esperar 24 horas para instalar com o ADB?"
Resposta. Não. O Google afirma que o período de espera de 24 horas do fluxo avançado não vale para instalações por ADB.
Próximo passo. Use o fluxo normal do ADB. Os comandos estão na seção 05.
Verificado
"Meu app não registrado já estava instalado, mas não atualiza"
Explicação provável. Quando a aplicação valer para aquele caminho de instalação, o Google diz que atualizar um app não registrado exige o fluxo avançado ou o ADB, e que uma atualização comum falha.
Próxima checagem mais segura. Registre o pacote direito. Enquanto isso, o testador pode ativar o fluxo avançado ou você pode empurrar a atualização por ADB.
Verificado
"Testei com 12 pessoas no Firebase, mas o Play ainda não me deixa solicitar a produção"
Explicação provável. Os testadores do Firebase não estão participando de uma faixa de teste fechado do Play, então nada desse teste é contabilizado na exigência do acesso de produção.
Próxima checagem mais segura. Rode o teste fechado do Play: pelo menos 12 testadores que se enquadram, participando e continuando participando, por 14 dias seguidos. O relógio começa quando eles estão de fato inscritos, não quando você começou a testar.
Verificado
"Usei 12 pessoas no teste interno do Play, mas a produção continua travada"
Explicação provável. O teste interno não é a faixa que a exigência do acesso de produção nomeia. A regra pede um teste fechado.
Próxima checagem mais segura. Mova o teste que vale para uma faixa de teste fechado do Play. O teste interno continua útil para um QA rápido em paralelo.
Verificado pela definição da política
"Meu testador nunca recebeu o convite do Firebase, ou diz que o link está morto"
Explicação provável. Os convites de testador do Firebase expiram depois de 30 dias, com um aviso 5 dias antes. Um testador que deixou o e-mail parado por um mês está com o convite vencido mesmo com a versão em si continuando disponível por 150 dias.
Próxima checagem mais segura. Reenvie o convite antes de presumir qualquer coisa sobre assinatura, verificação ou aparelho. As falhas de embarque no App Distribution costumam ser relatadas como problemas de conta, de convite ou de origem de instalação, e não como problemas da versão.
Verificado Padrão relatado pela comunidade
"Um artigo diz que toda instalação direta acaba em 30 de setembro"
Explicação provável. Ele se apoia em coberturas de 2025 ou do começo de 2026, escritas antes de o Google reduzir o alcance inicial.
Próxima checagem mais segura. Leia as perguntas frequentes de verificação do Google direto na fonte. A resposta atual é que o prazo de 30 de setembro vale para as lojas participantes e ainda não alcança a instalação direta.
Correção verificada
A regra que mais economiza tempo de suporte
Dois APKs com o mesmo nome de pacote e assinaturas sem relação não se substituem, e nunca se substituíram. Antes de diagnosticar qualquer coisa como problema de verificação de desenvolvedor, veja se você não está simplesmente pedindo ao Android para trocar um app por um impostor dele mesmo assinado de outro jeito. A arquitetura da verificação reforça por que a identidade de assinatura importa, mas essa falha é fácil de confundir com um problema de verificação de desenvolvedor quando ela não é nova nem tem relação com isso.
O que você deve fazer de fato antes de 30 de setembro
Se você só distribui APKs de forma direta, a primeira fase de 30 de setembro não aplica a verificação de desenvolvedor nesse caminho. Isso é temporário, não permanente: o Google recomenda concluir a verificação antes de o lançamento global começar em 2027. Se você publica no Google Play, ele pede uma coisa: todos os pacotes registrados. E, separado dos dois, se a sua conta enfrenta a etapa do acesso de produção, o relógio de 14 dias é o item que decide a sua data de lançamento, então ele já deveria estar correndo.
Rastreador para antes do prazo
Doze itens na ordem em que acontecem de verdade. Marque conforme avança; nada é salvo, então termine de uma vez ou deixe a aba aberta.
0 / 12 concluídos
Nada marcado ainda. Comece descobrindo em qual via você está.
Quando este post fica desatualizado
Este é um artigo excepcionalmente perecível e seria desonesto apresentá-lo como atemporal. Abaixo estão as coisas com mais chance de mudar primeiro, e o que tornaria cada uma delas errada.
O gatilho de atualização mais importante da página. Se o Google reescrever a resposta das perguntas frequentes que hoje diz que a instalação direta ainda não está coberta, a primeira metade inteira deste post muda.
Sete lojas, quatro países. O Google pode acrescentar lojas ou esclarecer o comportamento no próprio dia. Vale conferir em 29 de setembro, no dia em si e uma semana depois.
Os dois estavam programados para um lançamento mundial em agosto de 2026 sem dia publicado. O status deles pode mudar sem nenhuma mudança de política.
No momento em que o Google nomear países ou datas de 2027, este post vai precisar de uma tabela de países que hoje, corretamente, ele não tem.
As documentações de APK e de AAB do Firebase andam de forma independente uma da outra, e a exigência do Play de 12 testadores por 14 dias vive em uma página de Ajuda que o Google revisa sem anunciar.
Ritmo de atualização adotado para este post: semanal até 30 de setembro de 2026, depois na data de entrada em vigor e cerca de uma semana depois dela para esclarecimentos de implementação, e então mensal até o Google publicar um cronograma concreto para 2027. Esse ritmo é uma escolha editorial baseada na frequência com que o Google revisou este programa durante 2026, não um cronograma oficial do Google.
Onde a PrimeTestLab entra e onde não entra
Primeiro o limite, porque é a parte honesta. PrimeTestLab não verifica a sua identidade, não registra os seus nomes de pacote nem transforma um teste no Firebase em um teste fechado do Play. Isso é com você, e este artigo é toda a nossa contribuição para essa parte. O que a gente cobre é a única exigência desta página feita de tempo de calendário e não de papelada: 12 testadores reais participando continuamente por 14 dias em uma faixa de teste fechado do Play. O Google até publica APIs e delegação OAuth pelas quais uma plataforma autorizada pode ajudar um desenvolvedor no registro, mas esse acesso teria de ser concedido por você e a responsabilidade pela conta e pela identidade do app continua sendo sua.
Essa distinção tem exatamente o formato do problema que este artigo existe para resolver. Um desenvolvedor distribui os builds muito bem: grupos no Firebase, notas de versão organizadas, testadores engajados, relatos de bug de verdade. Depois abre o Play Console para solicitar o acesso de produção e descobre que nada disso contou. Distribuir é um problema resolvido. A janela de 14 dias de participação é a parte que você não encurta se organizando melhor.
Tocar o teste fechado sozinho ou delegar
O Google decide sobre o registro de pacotes, a verificação de identidade e o acesso de produção. Nenhum dos três é algo que fazemos por você. O que um teste gerenciado tira é o risco de recrutamento e de continuidade dos testadores, que é a etapa em que a maioria de quem publica pela primeira vez realmente trava. Taxa de sucesso em 7.400+ apps testados: 99,9%, em 120+ países.
Três planos, um pagamento
Starter
12 testadores $19.99 +5% de taxa de serviçoExatamente o mínimo do Google, para um único app que precisa passar pela exigência.
Professional
20 testadores $29.99 +5% de taxa de serviçoFolga acima do mínimo, para que uma desistência não encerre o teste.
Enterprise
25 testadores $27.99 +5% de taxa de serviçoPara mais cobertura de dispositivos e regiões ao longo dos 14 dias.
Todos os planos usam testadores reais em dispositivos reais pelo período completo de 14 dias, o teste costuma começar em 4-6 horas, e se um teste não der resultado você tem novo teste grátis ou reembolso total. A gente não promete a aprovação do Google, porque ninguém pode.
Perguntas frequentes
Meus amigos ainda vão conseguir instalar um APK que eu mandar por e-mail depois de 30 de setembro de 2026?
Sim, pelas regras atuais do lançamento inicial do Google. O prazo de 30 de setembro no Brasil, na Indonésia, em Singapura e na Tailândia vale para sete lojas de aplicativos participantes, e as perguntas frequentes do Google de 15 de julho de 2026 dizem explicitamente que a instalação direta ainda não está coberta. A exigência mais ampla continua prevista para se expandir mundialmente em 2027, então trate isso como um limite da primeira fase, e não como uma isenção permanente.
O Google vai bloquear toda instalação direta no Brasil, na Indonésia, em Singapura e na Tailândia em 30 de setembro?
Não, e esta é a correção mais importante às reportagens antigas. A aplicação inicial se limita ao Google Play, HONOR App Market, OPPO App Market, Samsung Galaxy Store, Transsion Palm Store, vivo V-Appstore e Xiaomi GetApps. A instalação direta e as lojas fora dessa lista estão explicitamente fora da primeira fase. Para a distribuição fora do Play, o Google afirma que a aplicação nas regiões selecionadas vale de início para os formatos celular e tablet.
Ainda vou conseguir instalar APK direto depois do lançamento mundial?
Para um app devidamente registrado com um desenvolvedor verificado, o Google diz que a experiência normal de instalação dos usuários deve continuar igual. Para um app não verificado ou não registrado, o Google preservou dois caminhos: o ADB e um fluxo avançado pelo qual o usuário pode escolher deliberadamente instalar o app. O Google não anunciou uma data mundial exata para essa fase mais ampla, apenas 2027 em diante.
Preciso da verificação de desenvolvedores Android para usar o ADB?
Não. O Google diz que desenvolvedores e usuários avançados podem continuar usando o ADB para instalar apps não verificados, e que o período de espera de 24 horas do fluxo avançado não vale para o ADB. O ADB por USB exige que as opções do desenvolvedor e a depuração USB estejam ativadas no aparelho, então ele serve muito melhor a desenvolvedores e testadores técnicos do que a usuários comuns.
O fluxo avançado me faz esperar 24 horas a cada APK?
Não. O Google descreve o atraso de 24 horas como parte da configuração única do fluxo avançado. Terminada essa configuração, o usuário pode permitir a instalação de apps de desenvolvedores não verificados por sete dias ou por tempo indeterminado. O Google também descreve a configuração como uma vez por conta, valendo em um aparelho novo.
O Android vai apagar um app não verificado que já está instalado?
A documentação do Google que analisamos não diz que as cópias existentes serão desinstaladas automaticamente nem impedidas de abrir. Ela diz que, quando a aplicação valer, um app não registrado não pode ser instalado nem atualizado normalmente sem o fluxo avançado ou o ADB, e que uma atualização comum falha. O jeito correto de descrever isso é como restrição de instalação e de atualização, e não como exclusão.
O Firebase App Distribution dribla a verificação de desenvolvedores?
Não. O Firebase é um serviço de distribuição de versões de teste, e registrar um app no Firebase não é a mesma coisa que a verificação de desenvolvedores Android, que liga um desenvolvedor verificado a nomes de pacote e chaves de assinatura. A distribuição de APK pelo Firebase deve ficar fora da aplicação inicial das lojas em setembro, porque as perguntas frequentes do Google dizem que a instalação direta ainda não está coberta, mas isso é uma dedução a partir da regra de instalação direta, e não uma isenção específica do Firebase, então prepare mesmo assim o registro dos pacotes para o lançamento de 2027.
Os testadores do Firebase App Distribution contam para a exigência de 12 testadores do Google?
Não. O Google exige que as contas afetadas tenham pelo menos 12 testadores participando de um teste fechado do Google Play nos 14 dias seguidos anteriores antes de solicitar o acesso de produção. O Firebase App Distribution é útil para encontrar bugs, mas esses testadores não estão participando de uma faixa de teste fechado do Play e não atendem a essa exigência.
O teste interno do Play conta para os 12 testadores?
Não, o teste interno não substitui o teste fechado exigido. O Google permite até 100 testadores em um teste interno, mas a exigência para o acesso de produção diz especificamente que os testadores que contam precisam ter participado de um teste fechado por 14 dias seguidos. O teste interno continua útil para um controle de qualidade rápido, em paralelo ao teste fechado.
Já verifiquei a minha identidade. Qualquer APK que eu gerar está automaticamente em ordem?
Não parta desse princípio. A verificação de desenvolvedores Android também envolve registrar o nome do pacote e a chave ou as chaves de assinatura dele, e o Google permite adicionar e verificar várias chaves de assinatura para um mesmo pacote. Isso pesa principalmente quando as versões de QA ou de depuração e as versões de lançamento usam certificados de assinatura diferentes, um arranjo completamente normal que a verificação de identidade sozinha não cobre.
A verificação faz o meu APK instalado direto ter que seguir todas as políticas do Google Play?
A documentação de verificação do Google descreve a confirmação de identidade e o registro de pacotes, não a extensão de todas as políticas de publicação do Play a toda distribuição direta. O Google também separa verificar quem é um desenvolvedor da triagem de segurança aplicada ao conteúdo do app. Estabelecer a identidade não é o mesmo que aprovar o que você publicou, então não trate a distribuição fora do Play como equivalente a uma análise da Play Store.
Resumo
Resumo
Em 13 de agosto de 2026, os seus testadores ainda conseguem instalar um APK bruto que você compartilha diretamente. A aplicação a partir de 30 de setembro de 2026 no Brasil, na Indonésia, em Singapura e na Tailândia alcança de início apenas sete lojas de aplicativos participantes, e as perguntas frequentes do Google de 15 de julho dizem que a instalação direta ainda não está coberta. O Google planeja uma aplicação mais ampla em dispositivos certificados com Android 7 ou superior em 2027, sem anunciar uma data mundial exata. Quando isso valer, os apps registrados com um desenvolvedor verificado mantêm o caminho de instalação direta de sempre, enquanto apps não registrados continuam instaláveis via ADB, que não tem espera de 24 horas, ou pelo fluxo avançado do Google, cujo atraso de 24 horas é uma etapa de configuração feita uma única vez. O Firebase App Distribution segue sendo um ótimo canal de QA, mas não faz a verificação de desenvolvedores Android, os fluxos de APK e AAB se comportam de formas diferentes, e ele não é o teste fechado do Google Play que exige 12 testadores participando continuamente por 14 dias. Se é essa etapa de teste que está travando o seu lançamento, a PrimeTestLab fornece 12 testadores reais a partir de $19.99 mais 5% de taxa de serviço. Ver os planos →
Fontes primárias usadas neste artigo
Última checagem de políticas: 13 de agosto de 2026. A página de perguntas frequentes do Google sobre verificação de desenvolvedores foi atualizada pela última vez em 10 de agosto de 2026, a resposta sobre sideload direto nela é de 15 de julho de 2026, e a documentação Android do Firebase App Distribution foi atualizada pela última vez em 11 de agosto de 2026. A verificação de desenvolvedores Android está em lançamento ativo, então o escopo de 30 de setembro, a lista de lojas participantes, a disponibilidade do fluxo avançado e o cronograma de 2027 devem ser reconferidos nas próprias páginas do Google antes de você agir. Este artigo tem reverificação programada semanalmente até 30 de setembro de 2026, de novo no dia em que entra em vigor e cerca de uma semana depois, e depois mensalmente até o Google publicar uma geografia ou uma data concretas para 2027.