Não: nunca reseta
Atualize à vontade; um build novo mantém seu relógio de 14 dias rodandoNão existe regra de que criar uma nova versão reseta o relógio do teste fechado. O requisito de 14 dias mede se pelo menos 12 testadores continuam participando sem interrupção: não tem a ver com a versão do app, o versionCode nem quantos builds você envia.
Seu número de testadores inscritos cair abaixo de 12.
Se testadores saem formalmente e você fica abaixo do mínimo, a sequência contínua quebra: não porque você atualizou, e sim porque caiu abaixo de 12.
Resposta rápida
Não: atualizar o app durante o teste fechado (closed testing) de 14 dias não reseta o relógio, então você pode enviar builds novos quantas vezes precisar. Enviar um build novo (AAB) para a faixa de teste fechado existente não reinicia os 14 dias. O relógio depende de manter pelo menos 12 testadores participando continuamente, não da versão do app, do versionCode nem da chave de assinatura. A janela contínua só quebra se o número de testadores inscritos cair abaixo de 12 ou se testadores saírem formalmente. Enviar updates é seguro, e o Google até incentiva. A PrimeTestLab mantém pelo menos 12 testadores reais participando continuamente, para o relógio seguir enquanto você envia correções.
É um dos medos mais comuns no teste fechado: você está no meio da janela de 14 dias, encontra um bug e trava, com medo de que enviar a correção apague o progresso e force as duas semanas do zero. Não vai. O relógio de 14 dias observa seus testadores, não seus builds. Este guia separa exatamente o que reseta o timer do teste fechado do que não reseta, oferece duas ferramentas interativas para testar qualquer ação, e explica por que o Google quer ver updates. Atualizado em 30 de junho de 2026.
Neste guia
Atualizar o app reseta o relógio de 14 dias do teste fechado?
Não. Esse é o medo mais comum entre desenvolvedores na janela de teste, e a resposta tranquiliza: enviar um App Bundle novo para a faixa de teste fechado existente não reseta o requisito de 14 dias consecutivos de teste.
O relógio de 14 dias depende dos seus testadores, não do seu build. O requisito do Google mede se você manteve pelo menos 12 testadores inscritos nos últimos 14 dias de forma contínua. O número de versão do app, quantas vezes você envia um AAB novo e o que muda nas notas da versão simplesmente não fazem parte desse timer.
Essa pergunta aparece de novo e de novo na Google Play Developer Community: se criar uma nova versão no teste fechado reseta os 14 dias, ou se o contador zera quando você atualiza o app. Em vez de citar respostas de fórum palavra por palavra que não pudemos verificar de forma independente, este guia se apoia na própria documentação de ajuda da Play Console, que define o requisito só em termos de testadores inscritos e tempo, nunca em uploads de build.
Nos mais de 7.400 apps que acompanhamos nesse processo, um update de build de rotina na mesma faixa fechada sozinho nunca resetou um relógio. Em dúvida sobre uma ação específica? Use o verificador abaixo: escolha o que você vai fazer e ele diz na hora se isso toca no timer de 14 dias.
Qual ação te preocupa?
Com base no requisito publicado da Play Console do Google (testadores inscritos × dias consecutivos) e na experiência amplamente relatada por desenvolvedores. Os dois riscos marcados pela comunidade estão identificados como tal.
O que realmente reseta o timer de 14 dias?
A janela contínua de 14 dias se entende melhor como checagem de consistência, não como contagem passiva de calendário. O Google quer ver que você manteve pelo menos 12 testadores inscritos sem interrupção. Há apenas dois gatilhos confirmados que quebram essa continuidade:
Contagem de inscritos cai abaixo de 12
Se até um testador sai e você cai para 11, a sequência contínua pode quebrar e as duas semanas recomeçam por completo. Esse é o motivo número um de falha de desenvolvedores DIY.
Testadores saem formalmente do teste
Um testador sai abrindo o link web do teste e escolhendo sair. Isso é diferente de desinstalar, e só prejudica o relógio se te empurrar abaixo de 12.
Enviar um build novo não está nessa lista. Nem corrigir um typo na ficha da loja, um testador enviar feedback, nem o app crashar no dispositivo de um testador: esse último é o ponto inteiro do teste. O simulador abaixo deixa a diferença clara: aperte o botão de update à vontade e nada se mexe; perca testadores abaixo de 12 e a sequência desaba.
O que NÃO reseta o relógio
Enviar um AAB novo na mesma faixa
Editar notas da versão ou ficha da loja
Um testador enviar feedback
O app crashar no dispositivo de um testador
Subir o versionCode ou o nome da versão
Um testador desinstalar sem sair do teste
Como envio um update para um teste fechado?
Enviar um update é o mesmo fluxo da sua primeira versão, com uma diferença importante: você cria a nova versão na mesma faixa de teste fechado em que seus testadores já estão inscritos. Você não inicia um teste novo: adiciona um build ao teste que já está rodando, e é exatamente por isso que o relógio de 14 dias continua. Aqui estão os dois passos na Play Console.
Criar uma nova versão na faixa fechada Testing > Closed testing > Manage track
Abra a faixa de teste fechado que você já está rodando, clique em Create new release e envie o App Bundle (AAB) atualizado. Adicione notas curtas da versão descrevendo o que mudou e salve. Fique na mesma faixa: é isso que preserva a janela contínua de 14 dias.
Revisar e lançar o update Review release > Start roll-out
Siga por Next e Review release, depois inicie o roll-out para a faixa fechada (e clique em Send changes for review na Publishing overview se for solicitado). Quando a nova versão estiver ao vivo (o Google observa que uma mudança publicada pode levar até várias horas para chegar aos testadores), os dispositivos atualizam sozinhos para o build novo: sem reinstalar e sem aceitar participar de novo.
Isso nunca reseta o relógio. Porque você lança na mesma faixa fechada em que os testadores já estão inscritos, a janela contínua de 14 dias segue rodando sob o build novo. Você está adicionando um build, não iniciando um teste novo: essa é a resposta inteira à pergunta em torno da qual este guia foi escrito.
Qual a diferença entre testadores convidados e inscritos?
Essa distinção derruba mais publicadores de primeira viagem do que qualquer outra, e é a chave para entender por que builds não importam para o relógio. O sistema do Google move os testadores por um funil, e só os estágios finais pesam.
Convidado
Você adicionou um e-mail à lista de testadores ou a um Google Group. Nada mais aconteceu ainda.
Inscrito
A pessoa abriu o link de convite, entrou com a conta Google e aceitou participar do teste. É o status que o relógio de 14 dias mede.
Instalado e ativo
Baixou o app e continua usando. Isso não muda a contagem bruta, mas é o que o Google pesa no engajamento na hora do acesso de produção.
Como a documentação do Google deixa claro, adicionar um e-mail não basta. Cada testador precisa abrir o link de convite, autenticar e aceitar participar de forma explícita antes de contar. É exatamente por isso que um update do app nunca reseta o progresso: seus testadores não saem do estado de inscritos, então o relógio segue em cada build novo. Para o passo a passo completo, veja nosso guia sobre como convidar testadores corretamente.
Dica de quem gerencia milhares de testes: rode os testadores por um Google Group em vez de uma lista estática de e-mails. Com um Group ligado à Play Console, você troca um testador editando o Group: o link de convite permanece o mesmo e a faixa segue. Isso remove o risco de apagar testadores ativos ao ajustar a lista, uma das poucas coisas que de fato pode quebrar a sequência.
Qual é a redação exata do requisito do Google?
A página oficial de ajuda da Play Console, "App testing requirements for new personal developer accounts", declara com precisão:
"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."
Google Play Console Help · answer 14151465E, em separado, no momento em que você solicita o acesso de produção:
"At least 12 testers must be opted-in to your closed test when you apply for production access. They must have been opted-in for the last 14 days continuously."
Google Play Console Help · answer 14151465O Google também deixa claro, nas próprias palavras, que os dias precisam ser consecutivos: não conta testadores que aceitaram participar, testaram por menos de 14 dias e depois saíram, e mesmo que voltem a aceitar, os 14 dias precisam ser consecutivos para contar. Essa cláusula sozinha mata o mito de que "14 dias são cumulativos", e, com a mesma importância, não diz nada sobre seus builds.
Três fatos para fixar
Enviar updates durante o teste é bom ou ruim?
É aqui que a ansiedade do desenvolvedor vira oportunidade. Enviar updates durante o teste fechado é amplamente visto como sinal positivo de engajamento. Vale separar o que o Google diz oficialmente do que a comunidade de desenvolvedores concluiu, porque as duas coisas se sobrepõem sem ser idênticas:
Continue iterando e corrigindo
A ajuda da Play Console incentiva a iteração contínua: continue usando o teste fechado enquanto corrige problemas e bugs relatados por usuários, e atualizar o app no teste fechado antes de ir para produção é "uma ótima forma de minimizar avaliações e notas de baixa qualidade".
Quando você solicita o acesso de produção, o formulário pede que descreva o engajamento recebido e o que fez com o feedback dos testadores.
Ativo vence congelado
Quem está na prática vai além: um app congelado na versão 1.0 por 14 dias com zero atividade parece só cumprir a cota, enquanto um que envia updates em resposta a feedback parece desenvolvimento de verdade. Alguns desenvolvedores enviam de propósito dois ou três updates pequenos para mostrar responsividade.
Isso é consenso da comunidade e inferência razoável, não uma regra publicada do Google. O Google não definiu um número obrigatório do tipo "envie X updates".
O recado: atualizar é seguro e incentivado, e a história de engajamento que você constrói com isso pode ajudar a responder o formulário de produção. O único risco real vem do que você envia, não do ato de enviar, o que leva à única ressalva de verdade.
Um update ruim pode resetar o relógio de forma indireta?
Sim, e essa é a ressalva que importa. Embora o ato de atualizar nunca resete o timer diretamente, as consequências de um update quebrado podem. Siga a cadeia:
Então a regra é simples: atualize à vontade, mas valide a estabilidade básica de cada build antes de enviar para a faixa fechada. E nunca rode com exatamente 12 testadores, porque uma única saída por um build ruim pode te derrubar. Um buffer de testadores acima de 12 absorve esse risco.
Leia a cadeia com atenção: o reset nunca é causado pelo update. É causado por cair abaixo de 12 testadores inscritos. O build quebrado é só o que disparou as saídas. Mantenha builds estáveis e um buffer, e o risco indireto some também.
Os testadores precisam reinstalar ou aceitar participar de novo depois de um update?
Não. Depois que um testador aceitou participar e instalou o app, o Google cuida dos updates automaticamente. Não há nada para clicar e nada para você reenviar.
Updates saem automaticamente
A ajuda da Play Console, em Set up an open, closed, or internal test (answer 9845334), deixa claro: "Once your testers have installed your app, they'll automatically be updated to use the test version within a few minutes." Os testadores seguem inscritos em cada build: sem reinstalar, sem segundo clique para aceitar participar.
Uma ressalva de tempo da mesma página do Google: quando você publica mudanças adicionais, elas "may not be available for testers for several hours" antes do update automático no dispositivo. Mas o status de inscrição dos testadores, que é o que o relógio de 14 dias mede, segue em cada AAB novo. É exatamente por isso que um update de build não reseta o relógio: os testadores nunca saíram.
Exceção importante Novas permissões podem interromper o update silencioso
Um tipo de build não sempre rola em silêncio: um update que adiciona uma permissão perigosa (sensível) nova, como ACCESS_FINE_LOCATION, câmera ou microfone. Dependendo da permissão e do target API level, o Google Play pode mostrar um botão Update que o testador precisa tocar e aprovar à mão em vez de instalar em segundo plano, e quem ignora fica no build antigo. Mesmo quando instala em silêncio, a permissão nova só é concedida em runtime, então um recurso que depende dela pode parecer quebrado até o testador permitir.
Num teste fechado isso é uma armadilha quieta: envie um update pesado de permissões no dia 5 e os números de testadores ativos podem cair, exatamente o sinal de engajamento que o Google pesa no acesso de produção, porque metade dos testadores nunca viu o prompt. Uma permissão de alto risco nova também pode disparar uma revisão de declaração de permissões que atrasa a publicação do build.
Antes de lançar no meio do teste: compare as permissões do manifesto novo com o build ao vivo. Se o conjunto de permissões mudou, avise os testadores para abrir a Play Store e atualizar manualmente (e conceder o novo prompt), e reserve margem para uma possível revisão de declaração.
Mitos comuns do teste fechado, desmentidos
A maior parte do pânico em torno de atualizar se resume a um punhado de mitos. Aqui estão os cinco que mais roubam o sono de desenvolvedores, com o que é verdade de fato:
Mito 1"Criar uma nova versão reseta o relógio."
Mito 2"Desinstalar é o mesmo que sair do teste."
Mito 3"Os 14 dias são cumulativos."
Mito 4"Exatamente 12 testadores bastam."
Mito 5"Os testadores precisam usar o app todos os dias."
O que reseta o relógio e o que não reseta
Aqui está a pergunta inteira numa tela. Salve, tire print ou envie para quem no time continua perguntando. Tudo ligado ao build é seguro; só o que mexe na contagem de testadores não é.
| Ação | Reseta o relógio de 14 dias? |
|---|---|
| Enviar um AAB novo na mesma faixa fechada | Não |
| Editar notas da versão ou metadados da ficha | Não |
| Um testador enviar feedback | Não |
| O app crashar no dispositivo de um testador | Não |
| Um testador desinstalar (sem sair do teste) | Não* |
| Contagem de inscritos cair abaixo de 12 | Sim |
| Um testador sair formalmente pelo link web | Sim** |
| Enviar build quebrado que gera saídas abaixo de 12 | Indiretamente |
| Pausar a faixa de teste fechado | Risco relatado |
| Sobrescrever a lista e omitir testadores ativos | Risco relatado |
* O timer tecnicamente continua, mas quem desinstala raramente volta a engajar. ** Só se te deixar abaixo de 12. As duas últimas linhas são cautela relatada pela comunidade, não documentação confirmada do Google: trate como "não arrisque" em vez de regra formal. Usar um Google Group evita por completo o risco de sobrescrever a lista.
Como o requisito mudou com o tempo
Se você está lendo tutoriais antigos, é por isso que os números não batem. A duração sempre foi 14 dias consecutivos; só a contagem de testadores se moveu.
Antes de novembro de 2023 não havia teste fechado obrigatório para chegar à produção. Você podia publicar sem recrutar testadores.
Contas pessoais criadas após 13 de novembro de 2023 precisavam rodar um teste fechado com 20 testadores inscritos por 14 dias consecutivos. Contas organizacionais ficavam isentas.
Em 11 de dezembro de 2024 o mínimo caiu de 20 para 12, com a duração de 14 dias inalterada. Contas organizacionais seguem isentas.
Qualquer guia que ainda diga para recrutar 20 testadores está desatualizado. Cobrimos a mudança em detalhe em o que mudou de 20 para 12 testadores (em inglês).
Mudanças de política de 2026 que você deve conhecer
O teste fechado não existe no vácuo. Alguns prazos de 2026 podem cruzar com seu cronograma de lançamento: nenhum muda como o relógio de 14 dias funciona, mas podem colidir com a janela se você não olhar o calendário:
Prazos de 2026 que cruzam com seu cronograma
Datas conforme a ajuda da Google Play Console (target API level) e o Android Developers Blog (developer verification). O timing da verificação é faseado e pode se expandir em 2026-2027, então confirme nas páginas oficiais antes de planejar em cima delas. Nosso guia de requisitos de publicação 2026 acompanha a lista completa.
Como a PrimeTestLab mantém o relógio rodando
A parte mais difícil do teste fechado não é entender as regras; é manter 12 ou mais pessoas reais inscritas e engajadas por 14 dias seguidos enquanto você itera. É exatamente para isso que a PrimeTestLab existe. Fornecemos testadores em dispositivos reais, que aceitam participar, e guiamos a configuração na Play Console para o relógio começar limpo e seguir enquanto você envia correções. Veja o serviço de teste fechado do Google Play completo. Mantemos taxa de sucesso de 99,9% em mais de 7.400 apps, com teste ao vivo em 4-6 horas.
Você adiciona nossos testadores na Play Console, compartilha a URL do teste, e o relógio começa. Daí em diante pode atualizar o build quantas vezes quiser: os testadores continuam inscritos, e a sequência segue por baixo.
+5% de taxa de serviço · Novo teste grátis ou reembolso total
A maioria dos desenvolvedores escolhe mais do que o mínimo de 12 testadores exatamente para que uma única saída, inclusive por um build ruim, não os deixe abaixo de 12 e resete o relógio. Um buffer é o seguro mais barato contra a única coisa que realmente quebra a sequência.
Perguntas frequentes
Posso atualizar o app no teste fechado sem reiniciar os 14 dias?
Sim. Enviar um build novo para a faixa de teste fechado existente não reinicia a janela contínua de 14 dias. O relógio depende de manter pelo menos 12 testadores participando continuamente, não da versão do app. Os testadores recebem o update automaticamente e continuam inscritos, então o progresso segue entre builds.
O que é a única coisa que reseta o relógio do teste fechado?
A janela contínua de 14 dias quebra quando o número de testadores inscritos cai abaixo de 12, ou quando testadores saem formalmente e você fica abaixo do mínimo. Updates de build, edições da ficha da loja e crashes não resetam. Manter um buffer de testadores acima de 12 é a forma mais confiável de proteger a sequência.
Qual a diferença entre testadores convidados e inscritos?
Convidado significa que você adicionou o e-mail à lista: isso não conta para nada. Inscrito significa que a pessoa abriu o link, entrou na conta Google e aceitou participar do teste: é o status que o relógio de 14 dias mede. Só testadores inscritos contam para o requisito, então confirme sempre que eles concluíram o passo de aceitar participar.
Os testadores precisam aceitar participar de novo depois de um update?
Não. Depois que um testador aceita participar e instala, o Google entrega seus updates automaticamente em minutos. Eles não reinstalam nem clicam no link de convite de novo. O status de inscrição, que o requisito de 14 dias mede, segue sem interrupção em cada build novo na mesma faixa fechada.
Desinstalar é o mesmo que sair do teste?
Não. Um testador só sai formalmente visitando o link web do teste e escolhendo sair. Se apenas desinstala, o timer tecnicamente continua. Na prática, quem desinstala raramente volta, o que pode enfraquecer o engajamento que você apresenta ao solicitar o acesso de produção, então ainda vale manter os testadores ativos.
O Google quer que eu envie updates durante o teste?
A documentação do Google recomenda continuar corrigindo problemas no teste fechado antes da produção e testar rotineiramente updates futuros. O consenso da comunidade de desenvolvedores vai além e trata updates ativos como sinal positivo de engajamento, em contraste com um app congelado que parece só cumprir a cota. O Google não publicou um número obrigatório de updates, então itere de forma genuína, sem churn artificial.
De quantos testadores eu realmente preciso no teste fechado?
O mínimo do Google são 12 testadores inscritos por 14 dias consecutivos para contas pessoais criadas após 13 de novembro de 2023. Como uma única saída pode te deixar abaixo de 12 e quebrar a sequência, muitos desenvolvedores usam 20 a 25 testadores como buffer. A PrimeTestLab oferece planos com 12, 20 e 25 testadores a partir de $19.99.
Conclusão
Resumo
Atualizar o app durante o teste fechado de 14 dias é seguro, normal e incentivado. O relógio mede se pelo menos 12 testadores continuam participando de forma contínua, então um build novo sozinho nunca o reseta. Os riscos reais são cair abaixo de 12 testadores inscritos, saídas formais ou enviar um build tão quebrado que os testadores desistem. Envie suas correções, itere com o feedback e proteja a contagem com um buffer acima do mínimo. Se você quer um relógio que simplesmente não quebra, a PrimeTestLab mantém de 12 a 25 testadores reais inscritos a partir de $19.99, com teste ao vivo em 4-6 horas. Ver planos de preços →