Como a regra de fato escala
Cada app novo precisa do próprio teste fechado, mas as mesmas pessoas podem aceitar participar de todos: não precisam ser humanos diferentes.
O portão se repete por app. Os testadores, não.
Resposta rápida
Para cada app de fato novo em conta pessoal de desenvolvedor criada após 13 de nov. de 2023, espere rodar um teste fechado (closed testing) novo com no mínimo 12 testadores participando por 14 dias contínuos antes de solicitar o acesso de produção: a produção se libera por app, não por conta. Você não precisa de um novo teste de 12 testadores para publicar um update de rotina em um app que já tem acesso de produção, e os mesmos testadores podem ser reutilizados em todos os seus apps. Quando precisar passar por esse portão com rapidez, a PrimeTestLab fornece testadores reais, participando, em dispositivos reais a partir de $19.99.
É uma das dúvidas mais comuns de quem tem mais de um app no pipeline: depois de atravessar o hoop de 12 testadores e 14 dias do Google uma vez, é preciso fazer tudo de novo no próximo app? Ou é um marco único da conta que nunca se repete? A resposta honesta tem três partes, e este guia separa o que o Google diz literalmente do que é consenso da comunidade, para você saber o quanto confiar em cada afirmação. Atualizado em 1 de julho de 2026.
O que este post cobre
O requisito de 12 testadores é por app ou por conta?
Ele é tratado por app, não por conta. A primeira aprovação de produção é o grande marco de onboarding, mas cada app novo que você publica ainda tem o próprio caminho até a produção: trate cada nome de pacote novo (cada applicationId novo) como precisando do próprio teste fechado, a menos que o Play Console mostre claramente o contrário.
É aqui que a maioria dos desenvolvedores se confunde, então vai a versão honesta. O Google não publica uma frase que diga, palavra por palavra, "você deve repetir isso para cada app". Também não publica uma frase dizendo "depois que o primeiro app for aprovado, todos os futuros estão isentos". O que o Google diz é que o requisito se aplica a "seu app", que a produção se libera ao solicitar a partir do Painel daquele app específico, e que a política existe para ajudar novos desenvolvedores com conta pessoal a preparar o app para distribuição.
Junte esses fatos e a leitura mais defensável é que o acesso de produção vive no nível do app, não como um checkbox único da conta. Há uma nuance para apps posteriores: quando a conta já tem um app em produção com sucesso, os seguintes podem enfrentar outro nível de escrutínio, mas a Central de Ajuda pública do Google não promete isenção ampla e permanente da conta para todo app futuro. Então o hábito seguro depois da primeira aprovação é simples: confira o status de cada app novo no Play Console em vez de assumir que a conta inteira está desbloqueada para sempre.
"Passei uma vez, então a conta está liberada para sempre."
Desenvolvedores assumem que o teste fechado é um portão único da conta. Depois o segundo app fica no Play Console com Produção travada, e o relógio de 14 dias recomeça do zero: uma surpresa que pode custar a janela de lançamento.
O acesso de produção é concedido app a app.
Cada nome de pacote novo começa com Produção travada e precisa atender de forma independente ao teste fechado de 12 testadores e 14 dias. O alívio: os mesmos testadores podem servir a todos os seus apps, então você nunca recruta do zero de novo.
Como ler os níveis de confiança neste post. Perguntas de política do Google atraem muita afirmação confiante em blogs. Para manter você seguro, tudo abaixo está marcado pelo quão sólida é a fonte: assim você sabe no que pode se apoiar e o que conferir no seu próprio Play Console.
Declarado de forma literal nas páginas de ajuda do Play Console. O requisito em si, a definição de participação e a recomendação sobre updates moram aqui.
Consistente com o texto do Google e amplamente relatado por desenvolvedores, mas não escrito palavra por palavra. A leitura por app e a mecânica de reinício ficam aqui.
Repetidas por alguns serviços de teste, mas ausentes na documentação do Google (ex.: filtragem de testadores por sensor). Trate com ceticismo; não repetimos isso como fato.
O que o Google exige oficialmente hoje?
Uma conta pessoal de desenvolvedor recém-criada precisa rodar um teste fechado com no mínimo 12 testadores que estejam participando continuamente há pelo menos os últimos 14 dias. Atenda a isso e você pode solicitar o acesso de produção a partir do Painel no Play Console.
Ajuda do Google Play Console
"If you have a newly created personal developer account, you must run a closed test for your app with a minimum of 12 testers who have been opted-in for at least the last 14 days continuously."
Play Console Help, answer 14151465 (Testing requirements for production access)
Alguns detalhes que valem fixar, todos da documentação do próprio Google:
Confirmado pelo Google
- O mínimo atual é 12 testadores: reduzido de 20 em 11 de dezembro de 2024, com a duração de 14 dias inalterada.
- A regra vale para contas pessoais criadas após 13 de novembro de 2023. Contas organizacionais são isentas.
- Depois que você solicita, a análise de acesso de produção geralmente leva até sete dias, embora ocasionalmente possa demorar um pouco mais.
Onde os apps ficam retidos
- O Google pode pedir que você continue testando se não tiver 12 testadores participando.
- Ou se os testadores não estiverem suficientemente engajados durante o teste fechado.
- Tutoriais antigos ainda dizem "20 testadores": esse número mudou e não está mais correto.
Esse último ponto importa. Passar não é só contagem de cabeças: o Google olha se testadores reais de fato usaram o app. É exatamente por isso que a redução de 20 para 12 não tornou o requisito trivial: o engajamento ainda conta, e por isso cobrimos por que o número caiu no nosso explicativo 20 para 12 testadores (em inglês).
Quando você não precisa de 12 testadores novos?
Se o app já tem acesso de produção e você está enviando um update normal para esse mesmo app, você não precisa recrutar 12 testadores novos e esperar outros 14 dias só para publicar. O teste fechado é um portão para o primeiro acesso de produção, não um pedágio recorrente em cada release.
O Google diz que, depois de uma solicitação de acesso de produção bem-sucedida, você pode publicar em produção, e que recomenda testar updates futuros de forma rotineira. A palavra "recomenda" faz trabalho real aqui: o teste contínuo é boa prática, não um portão obrigatório novo a cada update de produção. A documentação de testes do Google também nota que, quando você roda teste fechado de um app já publicado, só os usuários do grupo de teste recebem o build do teste fechado como update, o que só faz sentido porque o app já existe em produção.
Nome de pacote de fato novo
Espere um teste fechado novo de 14 dias
- Um
applicationIdnovo, nunca publicado antes - Produção travada até você concluir o teste
- Precisa de 12+ testadores participando por 14 dias contínuos
Update de um app já aprovado
Sem novo teste de 12 testadores
- Mesmo nome de pacote, já em produção
- Basta enviar a nova versão para produção
- Testar updates futuros é recomendado, não obrigatório
Então a regra limpa é: app novo, espere sim; update de um app já em produção, não. Se nada mudou além da versão do mesmo anúncio e do mesmo nome de pacote, um teste fechado novo com 12 pessoas não é o requisito padrão. Um detalhe a sinalizar: enviar um build novo durante o seu primeiro teste fechado é diferente de atualizar um app já aprovado: desatamos isso em atualizar reinicia o teste fechado?.
Os testadores precisam ser pessoas novas toda vez?
Não. Mesmo quando um app novo precisa de teste fechado, os 12 testadores não precisam ser 12 pessoas completamente diferentes. O Google permite reutilizar a mesma lista de e-mails de testadores em testes futuros de qualquer um dos seus apps: a mesma conta Google pode ser testador de quantos apps seus você quiser.
Esse é o sinal oficial mais claro de que um conjunto de testadores pode servir ao catálogo inteiro. O que importa de fato não é novidade. É que, no app que você está levando à produção, pelo menos 12 testadores estejam participando ativamente do teste fechado daquele app e permaneçam participando por 14 dias consecutivos.
Então cada app ainda roda o próprio portão de 14 dias, mas as pessoas que o preenchem podem ser as mesmas toda vez. Isso reformula o problema inteiro: monte um pool confiável de testadores uma vez, e cada lançamento futuro o reutiliza. Veja o que isso significa para um roadmap multi-app:
Interativo
Planejador de portfólio
Quantos testes fechados o roadmap vai precisar, e quantos testadores?
3 apps = 3 testes fechados separados, mas ainda só um pool de 12 testadores se você os reutilizar. Rode os testes em paralelo e o tempo de calendário encolhe: só são 42 dias se você rodar estritamente um após o outro.
O que conta como testador participando por 14 dias?
Os 14 dias precisam ser consecutivos. O Google não conta testadores que aceitam participar, testam por menos de 14 dias e depois saem, mesmo que voltem a participar depois para que o total some 14 dias.
Ajuda do Google Play Console
"This means that we won't count testers who opted in, tested for less than 14 days, and then opted out. Even if they opt back in so that they are opted in for a total of 14 days, these 14 days must be consecutive to count."
Play Console Help, answer 14151465 (FAQ)
Duas implicações práticas seguem, e as duas pegam quem é de primeira viagem:
Isso conta
- Um testador que clica no link de convite oficial e aceita em um dispositivo com aquela conta Google.
- Permanecer participando pelos 14 dias contínuos completos sem sair do teste.
- Engajamento genuíno e contínuo: abrir e usar o app de fato.
Isso NÃO conta
- Só adicionar um e-mail à lista de testadores: a pessoa ainda precisa aceitar participar.
- Uma sequência quebrada: sair no meio da janela e voltar reinicia a contagem consecutiva.
- Um testador preso no teste interno: ele precisa sair do interno antes de entrar no teste fechado.
A regra da margem (consenso da comunidade)
Se testadores se afastam e a contagem ativa cai abaixo de 12 no meio da janela, a sequência contínua pode quebrar e, na prática, reiniciar o relógio. O Google não publica o algoritmo exato de reinício, mas esse comportamento é coerente com a redação "continuamente", e é por isso que desenvolvedores experientes recrutam uma margem de 15 a 25 testadores em vez de exatamente 12. Detalhamos a mecânica da sequência no guia dos 14 dias consecutivos.
Você precisa de um novo teste com 12 testadores? Descubra
Cada situação é um pouco diferente. Escolha a que combina com a sua e receba uma resposta direta, mais o próximo passo.
Interativo
O verificador de novo teste
Escolha o cenário para ver se um teste fechado novo de 14 dias se aplica.
Sim: rode um teste fechado completo
Novo teste necessárioEsse é o caso clássico. Antes de solicitar o acesso de produção, você precisa de pelo menos 12 testadores participando por 14 dias contínuos. Comece no dia 1: é a etapa fixa mais longa do lançamento inteiro.
Próximo passo: recrute uma margem de 15 ou mais para que uma única saída nunca reinicie o relógio.
Sim para o app, mas reutilize os testadores
Novo teste, mesmas pessoasCada nome de pacote novo ganha o próprio teste fechado de 14 dias, então planeje um. A boa notícia: a mesma lista de testadores pode aceitar participar deste app também: você não precisa de 12 humanos novos.
Próximo passo: aponte o pool de testadores existente para o link de convite do app novo e confirme que pelo menos 12 estão ativos.
Não: basta publicar o update
Sem novo testeUm app que já tem acesso de produção não precisa reconquistá-lo. Enviar um update de rotina para o mesmo nome de pacote não dispara um teste fechado novo. Testar updates é recomendado, não obrigatório.
Próximo passo: publique a nova versão em produção normalmente.
Não: sua conta é anterior à regra
IsentoO requisito de teste fechado vale para contas pessoais criadas após 13 de novembro de 2023. Uma conta criada nessa data ou antes não está sujeita a ele.
Próximo passo: confirme a data de criação da conta no Play Console antes de confiar nisso.
Não: contas organizacionais são isentas
IsentoContas organizacionais / empresariais não estão sujeitas ao requisito de teste fechado de 14 dias. O trade-off é um setup mais pesado: empresa registrada e número D-U-N-S.
Próximo passo: pese a papelada no nosso guia de conta pessoal vs. organizacional.
Como se encaixam as faixas interna, fechada e aberta?
O Google oferece três faixas de teste, mas só uma, o teste fechado, atende ao requisito de acesso de produção. O teste interno não conta para isso, e o teste aberto só se libera depois que você já tem acesso de produção.
Interno
Até 100 testadores, builds mais rápidos
- Ótimo para QA rápido e smoke tests
- Entrega builds quase na hora
- Testadores precisam sair antes de entrar no teste fechado
NÃO conta para o requisito
Fechado
12+ testadores, 14 dias contínuos
- A faixa obrigatória para contas pessoais novas
- Roda por app, em cada nome de pacote novo
- Testadores podem ser reutilizados em todos os apps
Obrigatório antes de solicitar produção
Aberto
Público, qualquer um pode entrar
- Bom para feedback de beta em escala
- Listado publicamente na página da loja
- Só disponível depois do acesso de produção
Libera depois do acesso de produção
O fato de o teste aberto só aparecer depois do acesso de produção é outra confirmação silenciosa de que a liberação de produção está atada ao setup de release de cada app, e não é concedida para a conta inteira. Se você está escolhendo entre faixas, nosso comparativo de teste interno vs. fechado vs. aberto aprofunda cada uma.
Como funciona a revisão de acesso de produção?
Depois de ter 12 ou mais testadores participando continuamente por 14 dias, você solicita o acesso de produção a partir do Painel. O formulário do Google cobre três áreas, e a análise geralmente leva até sete dias.
O formulário pergunta sobre o teste fechado, sobre o app e sobre a prontidão para produção. O Google usa essas respostas para confirmar que os apps foram testados de forma adequada antes de chegar ao público. Se pedirem que você continue testando, os dois motivos mais comuns que o Google cita são não ter 12 testadores participando e testadores que não estavam engajados com o app durante o teste.
O movimento de quem já sabe
Como o acesso de produção é concedido por app, suas respostas do formulário importam em cada app novo, não só no primeiro. Mantenha um modelo curto descrevendo como você recrutou testadores e como eles se engajaram, e adapte em cada lançamento. Respostas vagas de uma linha são motivo comum de a primeira solicitação voltar.
Dois prazos de 2026 para manter no radar
Eles são separados do requisito de teste fechado, mas afetam o mesmo cronograma de lançamento: então planeje em torno deles. Note os selos de confiança: um é o plano declarado do Google, o outro é um programa confirmado.
O nível de API de destino sobe para 36
Planejado para agosto de 2026
O Google planeja exigir que apps novos e updates miriem o Android 16 (API level 36), seguindo o ritmo anual usual. Em meados de 2026 a data exata ainda não havia substituído o requisito anterior na página oficial de política de API de destino: trate como plano declarado do Google e confirme a data vigente no Play Console antes de se apoiar nela.
Verificação de Desenvolvedor Android
30 de setembro de 2026
O Google começará a exigir o registro de apps por desenvolvedores verificados no Brasil, Indonésia, Singapura e Tailândia, com expansão global mais ampla em 2027 e além. É uma checagem de identidade que confirma quem você é: totalmente separada de provar que o app funciona pelo teste fechado.
Mantenha os dois separados: a verificação de desenvolvedor confirma quem você é; o teste fechado confirma que o app funciona. Nenhum substitui o outro. Para o checklist completo de lançamento 2026, veja nosso guia de requisitos de publicação no Google Play.
Como a PrimeTestLab ajuda você a passar, app após app
Como o teste fechado se repete em cada app novo, uma fonte confiável e repetível de testadores reais se paga no catálogo inteiro, não só uma vez. A PrimeTestLab fornece testadores humanos reais, participando, em dispositivos Android reais, cobrindo Android 7 a Android 17 e 120+ países, para você atender ao requisito de 12 testadores sem perseguir amigos e colegas a cada lançamento. O teste começa em 4-6 horas, e já apoiamos mais de 7.400 apps com taxa de sucesso de 99,9%.
Você compartilha o link de convite do teste fechado. Nós cuidamos do convite, da verificação de participação e da retenção pelos 14 dias completos, para que a saída de um testador nunca quebre a sequência e reinicie o relógio. Todo plano usa testadores reais com engajamento genuíno, exatamente o que o Google avalia.
Pacotes atuais
- Atende ao mínimo do Google
- Dispositivos Android reais
- Cobertura completa de 14 dias
- Margem absorve saídas
- Melhor diversidade de dispositivos
- Maior taxa na primeira tentativa
- Margem de segurança incluída
- Melhor diversidade de dispositivos
- Mais segurança no pedido de produção
+5% de taxa de serviço nos planos
Perguntas frequentes
Preciso de 12 testadores para cada app que publico no Google Play?
Para um app novo em conta pessoal de desenvolvedor criada após 13 de novembro de 2023, espere que sim: cada app novo precisa do próprio teste fechado com no mínimo 12 testadores participando por 14 dias contínuos antes de solicitar o acesso de produção. Updates de rotina em um app que já tem acesso de produção não exigem um teste novo de 12 testadores.
Posso reutilizar os mesmos testadores em vários apps?
Sim. O Google permite reutilizar a mesma lista de e-mails de testadores em testes futuros de qualquer um dos seus apps, então os 12 testadores não precisam ser 12 pessoas diferentes toda vez. O que importa é que pelo menos 12 deles estejam participando ativamente do app específico que você está levando à produção, e que permaneçam participando por 14 dias consecutivos.
Atualizar o app reinicia o relógio de 14 dias?
Não. Depois que um app tem acesso de produção, enviar um update de rotina para o mesmo nome de pacote não dispara um teste fechado novo. O Google recomenda testar updates futuros como boa prática, mas não exige reconquistar o acesso de produção cada vez que você publica um update de um app já aprovado. Detalhes completos.
Contas organizacionais também precisam de 12 testadores?
Não. O requisito de teste fechado vale para contas pessoais de desenvolvedor criadas após 13 de novembro de 2023. Contas organizacionais não estão sujeitas a ele, embora configurar uma exija empresa registrada e número D-U-N-S, o que tem tempo e papelada próprios. Compare os tipos de conta.
O que acontece se a contagem de testadores cair abaixo do mínimo durante os 14 dias?
Se a contagem ativa de quem está participando cair abaixo de 12 no meio da janela, a sequência contínua pode quebrar e o relógio, na prática, reinicia. O Google não publica a mecânica exata de reinício, mas isso combina com a linguagem de "continuamente". Recrutar uma margem de 15 a 25 testadores em vez de exatamente 12 protege você de uma saída custar duas semanas.
Pagar por testadores viola as regras do Google?
Recrutar testadores reais, inclusive por um provedor pago, não é proibido, e o próprio formulário de acesso de produção do Google lista um provedor de testes pago como exemplo. O que as políticas do Google proíbem são contas falsas, emuladores e engajamento simulado, que arriscam suspensão da conta. Por isso testadores reais em dispositivos reais com engajamento genuíno é a abordagem em conformidade.
Conclusão
Resumo
Você não precisa de 12 testadores de fato novos toda vez que toca no Google Play. Para um app novo em conta pessoal nova, assuma que ele precisa passar pelo teste fechado de 12 testadores e 14 dias antes da produção, porque o Google controla o acesso de produção em torno de cada app individual. Depois que um app já tem acesso de produção, updates de rotina não exigem um teste fechado novo, e os mesmos testadores podem ser reutilizados entre apps. Quando precisar passar por esse portão com rapidez e segurança, a PrimeTestLab fornece testadores reais, participando, em dispositivos reais a partir de $19.99. Ver planos de preços →