No: non azzera mai
Aggiorna pure; un build nuovo lascia il tuo orologio di 14 giorni in corsaNon esiste una regola per cui creare una nuova versione azzera l’orologio del test chiuso. Il requisito di 14 giorni misura se almeno 12 tester restano attivati senza interruzioni: non c’entra la versione dell’app, il versionCode né quanti build invii.
Il numero di tester attivati scende sotto i 12.
Se i tester escono formalmente e resti sotto il minimo, la sequenza continua si interrompe: non perché hai aggiornato, ma perché sei sceso sotto i 12.
Risposta rapida
No: aggiornare l’app durante il test chiuso (closed testing) di 14 giorni non azzera l’orologio, quindi puoi inviare build nuovi quante volte serve. Inviare un build nuovo (AAB) sul canale di test chiuso esistente non riavvia i 14 giorni. L’orologio dipende dal mantenere almeno 12 tester attivati continuamente, non dalla versione dell’app, dal versionCode né dalla chiave di firma. La finestra continua si interrompe solo se il numero di tester attivati scende sotto i 12 o se i tester escono formalmente. Inviare update è sicuro, e Google lo incoraggia pure. PrimeTestLab mantiene almeno 12 tester reali attivati continuamente, così l’orologio avanza mentre tu invii correzioni.
È una delle paure più comuni nel test chiuso: sei a metà della finestra di 14 giorni, trovi un bug e ti blocchi, temendo che inviare la correzione cancelli i progressi e forzi le due settimane da zero. Non succede. L’orologio di 14 giorni osserva i tuoi tester, non i tuoi build. Questa guida separa esattamente cosa azzera il timer del test chiuso da cosa no, offre due strumenti interattivi per provare qualsiasi azione, e spiega perché Google vuole vedere update. Aggiornato il 30 giugno 2026.
In questa guida
Aggiornare l’app azzera l’orologio di 14 giorni del test chiuso?
No. È la paura più comune tra gli sviluppatori nella finestra di test, e la risposta rassicura: inviare un App Bundle nuovo al canale di test chiuso esistente non azzera il requisito di 14 giorni consecutivi di test.
L’orologio di 14 giorni dipende dai tuoi tester, non dal tuo build. Il requisito di Google misura se hai mantenuto almeno 12 tester attivati negli ultimi 14 giorni in modo continuo. Il numero di versione dell’app, quante volte invii un AAB nuovo e cosa cambia nelle note di versione semplicemente non fanno parte di quel timer.
Questa domanda torna di continuo nella Google Play Developer Community: se creare una nuova versione nel test chiuso azzera i 14 giorni, o se il contatore si azzera quando aggiorni l’app. Invece di citare risposte di forum parola per parola che non abbiamo potuto verificare in modo indipendente, questa guida si appoggia alla documentazione di aiuto della Play Console, che definisce il requisito solo in termini di tester attivati e tempo, mai di upload di build.
Nei più di 7.400 app che abbiamo seguito in questo processo, un update di build di routine sullo stesso canale chiuso da solo non ha mai azzerato un orologio. Dubbi su un’azione specifica? Usa il verificatore qui sotto: scegli cosa farai e ti dice subito se tocca il timer di 14 giorni.
Quale azione ti preoccupa?
Basato sul requisito pubblicato della Play Console di Google (tester attivati × giorni consecutivi) e sull’esperienza ampiamente riportata dagli sviluppatori. I due rischi segnalati dalla community sono identificati come tali.
Cosa azzera davvero il timer di 14 giorni?
La finestra continua di 14 giorni si capisce meglio come controllo di coerenza, non come conteggio passivo del calendario. Google vuole vedere che hai mantenuto almeno 12 tester attivati senza interruzioni. Ci sono solo due trigger confermati che interrompono quella continuità:
Il conteggio degli attivati scende sotto i 12
Se anche un solo tester esce e scendi a 11, la sequenza continua può interrompersi e le due settimane ripartono da capo. Questo è il motivo numero uno di fallimento degli sviluppatori fai-da-te.
I tester escono formalmente dal test
Un tester esce aprendo il link web del test e scegliendo di uscire. È diverso dalla disinstallazione, e danneggia l’orologio solo se ti spinge sotto i 12.
Inviare un build nuovo non è in questa lista. Né correggere un typo nella scheda dello store, un tester che invia feedback, né l’app che va in crash sul dispositivo di un tester: quest’ultimo è proprio il punto del test. Il simulatore qui sotto rende chiara la differenza: premi pure il pulsante di update e non si muove nulla; perdi tester sotto i 12 e la sequenza crolla.
Cosa NON azzera l’orologio
Inviare un AAB nuovo sullo stesso canale
Modificare note di versione o scheda dello store
Un tester che invia feedback
L’app che va in crash sul dispositivo di un tester
Alzare il versionCode o il nome della versione
Un tester che disinstalla senza uscire dal test
Come invio un update a un test chiuso?
Inviare un update è lo stesso flusso della tua prima versione, con una differenza importante: crei la nuova versione sullo stesso canale di test chiuso in cui i tuoi tester sono già attivati. Non avvii un test nuovo: aggiungi un build al test che sta già girando, ed è proprio per questo che l’orologio di 14 giorni continua. Ecco i due passaggi in Play Console.
Creare una nuova versione sul canale chiuso Testing > Closed testing > Manage track
Apri il canale di test chiuso che stai già usando, clicca su Create new release e invia l’App Bundle (AAB) aggiornato. Aggiungi note di versione brevi che descrivono cosa è cambiato e salva. Resta sullo stesso canale: è questo che preserva la finestra continua di 14 giorni.
Rivedere e lanciare l’update Review release > Start roll-out
Procedi con Next e Review release, poi avvia il roll-out sul canale chiuso (e clicca su Send changes for review in Publishing overview se richiesto). Quando la nuova versione è live (Google osserva che una modifica pubblicata può impiegare fino a diverse ore per arrivare ai tester), i dispositivi si aggiornano da soli al build nuovo: senza reinstallare e senza attivare di nuovo il test.
Questo non azzera mai l’orologio. Perché lanci sullo stesso canale chiuso in cui i tester sono già attivati, la finestra continua di 14 giorni segue a correre sotto il build nuovo. Stai aggiungendo un build, non avviando un test nuovo: questa è l’intera risposta alla domanda intorno a cui è scritta questa guida.
Qual è la differenza tra tester invitati e attivati?
Questa distinzione fa fallire più pubblicatori al primo colpo di qualsiasi altra cosa, ed è la chiave per capire perché i build non contano per l’orologio. Il sistema di Google muove i tester in un funnel, e solo le fasi finali pesano.
Invitato
Hai aggiunto un’email all’elenco dei tester o a un Google Group. Nient’altro è ancora successo.
Attivato
La persona ha aperto il link di invito, ha effettuato l’accesso con l’account Google e ha attivato il test. È lo status che l’orologio di 14 giorni misura.
Installato e attivo
Ha scaricato l’app e continua a usarla. Non cambia il conteggio grezzo, ma è ciò che Google pesa nell’engagement al momento dell’accesso in produzione.
Come lascia chiaro la documentazione di Google, aggiungere un’email non basta. Ogni tester deve aprire il link di invito, autenticarsi e attivare il test in modo esplicito prima di contare. È esattamente per questo che un update dell’app non azzera mai i progressi: i tuoi tester non escono dallo stato di attivati, quindi l’orologio avanza su ogni build nuovo. Per la guida passo passo completa, vedi come invitare i tester correttamente.
Consiglio di chi gestisce migliaia di test: fai passare i tester da un Google Group invece che da un elenco statico di email. Con un Group collegato a Play Console, sostituisci un tester modificando il Group: il link di invito resta lo stesso e il canale prosegue. Così elimini il rischio di cancellare tester attivi quando regoli l’elenco, una delle poche cose che può davvero interrompere la sequenza.
Qual è la formulazione esatta del requisito di Google?
La pagina ufficiale di aiuto di Play Console, "App testing requirements for new personal developer accounts", dichiara con precisione:
"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, separatamente, nel momento in cui richiedi l’accesso in produzione:
"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 14151465Google lascia anche chiaro, con le sue parole, che i giorni devono essere consecutivi: non contano i tester che hanno attivato il test, testato per meno di 14 giorni e poi uscito, e anche se tornano ad attivare, i 14 giorni devono essere consecutivi per contare. Quella clausola da sola uccide il mito che "i 14 giorni sono cumulativi" e, con la stessa importanza, non dice nulla sui tuoi build.
Tre fatti da fissare
Inviare update durante il test è buono o cattivo?
Qui l’ansia dello sviluppatore diventa opportunità. Inviare update durante il test chiuso è ampiamente visto come segnale positivo di engagement. Vale separare cosa dice Google ufficialmente da cosa ha concluso la community di sviluppatori, perché le due cose si sovrappongono senza essere identiche:
Continua a iterare e correggere
L’aiuto di Play Console incoraggia l’iterazione continua: continua a usare il test chiuso mentre correggi problemi e bug segnalati dagli utenti, e aggiornare l’app nel test chiuso prima di andare in produzione è "un ottimo modo per ridurre recensioni e valutazioni di bassa qualità".
Quando richiedi l’accesso in produzione, il modulo chiede di descrivere l’engagement ricevuto e cosa hai fatto con il feedback dei tester.
Attivo batte congelato
Chi è sul campo va oltre: un’app congelata alla versione 1.0 per 14 giorni a zero attività sembra solo adempiere la quota, mentre una che invia update in risposta al feedback sembra sviluppo vero. Alcuni sviluppatori inviano di proposito due o tre update piccoli per mostrare reattività.
Questo è consenso della community e inferenza ragionevole, non una regola pubblicata di Google. Google non ha definito un numero obbligatorio del tipo "invia X update".
Il messaggio: aggiornare è sicuro e incoraggiato, e la storia di engagement che costruisci con questo può aiutarti a rispondere al modulo di produzione. L’unico rischio reale viene da cosa invii, non dall’atto di inviare, e questo porta all’unica vera riserva.
Un update cattivo può azzerare l’orologio in modo indiretto?
Sì, ed è la riserva che conta. Sebbene l’atto di aggiornare non azzeri mai il timer in modo diretto, le conseguenze di un update rotto possono. Segui la catena:
Quindi la regola è semplice: aggiorna pure, ma valida la stabilità di base di ogni build prima di inviarlo al canale chiuso. E non correre mai con esattamente 12 tester, perché una sola uscita per un build cattivo può farti scendere. Un buffer di tester sopra i 12 assorbe quel rischio.
Leggi la catena con attenzione: l’azzeramento non è mai causato dall’update. È causato dal scendere sotto i 12 tester attivati. Il build rotto è solo ciò che ha scatenato le uscite. Mantieni build stabili e un buffer, e sparisce anche il rischio indiretto.
I tester devono reinstallare o attivare di nuovo dopo un update?
No. Dopo che un tester ha attivato il test e installato l’app, Google gestisce gli update automaticamente. Non c’è nulla da cliccare e nulla da reinoltrare da parte tua.
Gli update partono automaticamente
L’aiuto di Play Console, in Set up an open, closed, or internal test (answer 9845334), lo dice chiaro: "Once your testers have installed your app, they'll automatically be updated to use the test version within a few minutes." I tester restano attivati su ogni build: senza reinstallare, senza un secondo clic per attivare il test.
Una riserva di tempo dalla stessa pagina di Google: quando pubblichi modifiche aggiuntive, "may not be available for testers for several hours" prima dell’update automatico sul dispositivo. Ma lo status di attivazione dei tester, che è ciò che l’orologio di 14 giorni misura, prosegue su ogni AAB nuovo. È esattamente per questo che un update di build non azzera l’orologio: i tester non sono mai usciti.
Eccezione importante Nuove autorizzazioni possono interrompere l’update silenzioso
Un tipo di build non sempre si distribuisce in silenzio: un update che aggiunge una autorizzazione pericolosa (sensibile) nuova, come ACCESS_FINE_LOCATION, fotocamera o microfono. A seconda dell’autorizzazione e del target API level, Google Play può mostrare un pulsante Update che il tester deve toccare e approvare a mano invece di installare in background, e chi lo ignora resta sul build vecchio. Anche quando l’installazione è silenziosa, l’autorizzazione nuova viene concessa solo a runtime, quindi una funzione che ne dipende può sembrare rotta finché il tester non la concede.
In un test chiuso è una trappola silenziosa: invia un update pesante di autorizzazioni al giorno 5 e i numeri di tester attivi possono scendere, proprio il segnale di engagement che Google pesa nell’accesso in produzione, perché metà dei tester non ha mai visto il prompt. Un’autorizzazione ad alto rischio nuova può anche far scattare una revisione della dichiarazione delle autorizzazioni che ritarda la pubblicazione del build.
Prima di lanciare a metà test: confronta le autorizzazioni del manifesto nuovo con il build live. Se l’insieme delle autorizzazioni è cambiato, avvisa i tester di aprire Play Store e aggiornare manualmente (e concedere il nuovo prompt), e lascia margine per una possibile revisione della dichiarazione.
Miti comuni del test chiuso, smentiti
Gran parte del panico intorno all’aggiornare si riduce a una manciata di miti. Ecco i cinque che rubano più sonno agli sviluppatori, con ciò che è vero davvero:
Mito 1"Creare una nuova versione azzera l’orologio."
Mito 2"Disinstallare è uguale a uscire dal test."
Mito 3"I 14 giorni sono cumulativi."
Mito 4"Esattamente 12 tester bastano."
Mito 5"I tester devono usare l’app ogni giorno."
Cosa azzera l’orologio e cosa no
Ecco l’intera domanda in una schermata. Salvala, fai uno screenshot o inviala a chi nel team continua a chiedere. Tutto legato al build è sicuro; solo ciò che muove il conteggio dei tester non lo è.
| Azione | Azzera l’orologio di 14 giorni? |
|---|---|
| Inviare un AAB nuovo sullo stesso canale chiuso | No |
| Modificare note di versione o metadati della scheda | No |
| Un tester che invia feedback | No |
| L’app che va in crash sul dispositivo di un tester | No |
| Un tester che disinstalla (senza uscire dal test) | No* |
| Il conteggio degli attivati scende sotto i 12 | Sì |
| Un tester che esce formalmente dal link web | Sì** |
| Inviare un build rotto che genera uscite sotto i 12 | Indirettamente |
| Mettere in pausa il canale di test chiuso | Rischio segnalato |
| Sovrascrivere l’elenco e omettere tester attivi | Rischio segnalato |
* Il timer tecnicamente continua, ma chi disinstalla raramente torna a fare engagement. ** Solo se ti lascia sotto i 12. Le ultime due righe sono cautela riportata dalla community, non documentazione confermata di Google: trattale come "non rischiare" invece che come regola formale. Usare un Google Group evita del tutto il rischio di sovrascrivere l’elenco.
Come il requisito è cambiato nel tempo
Se stai leggendo tutorial vecchi, ecco perché i numeri non tornano. La durata è sempre stata 14 giorni consecutivi; solo il conteggio dei tester si è mosso.
Prima di novembre 2023 non c’era un test chiuso obbligatorio per arrivare in produzione. Potevi pubblicare senza reclutare tester.
Gli account personali creati dopo il 13 novembre 2023 dovevano eseguire un test chiuso con 20 tester attivati per 14 giorni consecutivi. Gli account dell’organizzazione restavano esenti.
L’11 dicembre 2024 il minimo è sceso da 20 a 12, con la durata di 14 giorni invariata. Gli account dell’organizzazione restano esenti.
Qualsiasi guida che dica ancora di reclutare 20 tester è obsoleta. Abbiamo coperto il cambio in dettaglio in cosa è cambiato da 20 a 12 tester (in inglese).
Cambiamenti di policy del 2026 che devi conoscere
Il test chiuso non esiste nel vuoto. Alcune scadenze del 2026 possono incrociare il tuo calendario di lancio: nessuna cambia come funziona l’orologio di 14 giorni, ma possono collidere con la finestra se non guardi il calendario:
Scadenze 2026 che incrociano il tuo calendario
Date secondo l’aiuto di Google Play Console (target API level) e l’Android Developers Blog (developer verification). I tempi della verifica sono a fasi e possono espandersi nel 2026-2027, quindi conferma sulle pagine ufficiali prima di pianificare su di esse. La nostra guida ai requisiti di pubblicazione 2026 segue l’elenco completo.
Come PrimeTestLab mantiene l’orologio in corsa
La parte più difficile del test chiuso non è capire le regole; è tenere 12 o più persone reali attivate e con engagement per 14 giorni di fila mentre tu iteri. È esattamente per questo che esiste PrimeTestLab. Forniamo tester su dispositivi reali, che attivano il test, e guidiamo la configurazione in Play Console così l’orologio parte pulito e avanza mentre invii correzioni. Vedi il servizio di test chiuso di Google Play completo. Manteniamo un tasso di successo del 99,9% su oltre 7.400 app, con test live in 4-6 ore.
Aggiungi i nostri tester in Play Console, condividi l’URL del test, e l’orologio parte. Da lì puoi aggiornare il build quante volte vuoi: i tester restano attivati, e la sequenza avanza sotto.
+5% di commissione di servizio · Nuovo test gratuito o rimborso completo
La maggior parte degli sviluppatori sceglie più del minimo di 12 tester proprio perché una sola uscita, anche per un build cattivo, non li lasci sotto i 12 e azzeri l’orologio. Un buffer è l’assicurazione più economica contro l’unica cosa che interrompe davvero la sequenza.
Domande frequenti
Posso aggiornare l’app nel test chiuso senza riavviare i 14 giorni?
Sì. Inviare un build nuovo sul canale di test chiuso esistente non riavvia la finestra continua di 14 giorni. L’orologio dipende dal mantenere almeno 12 tester attivati continuamente, non dalla versione dell’app. I tester ricevono l’update automaticamente e restano attivati, quindi i progressi proseguono tra i build.
Qual è l’unica cosa che azzera l’orologio del test chiuso?
La finestra continua di 14 giorni si interrompe quando il numero di tester attivati scende sotto i 12, o quando i tester escono formalmente e resti sotto il minimo. Gli update di build, le modifiche alla scheda dello store e i crash non azzerano. Tenere un buffer di tester sopra i 12 è il modo più affidabile per proteggere la sequenza.
Qual è la differenza tra tester invitati e attivati?
Invitato significa che hai aggiunto l’email all’elenco: non conta per nulla. Attivato significa che la persona ha aperto il link, ha effettuato l’accesso con l’account Google e ha attivato il test: è lo status che l’orologio di 14 giorni misura. Solo i tester attivati contano per il requisito, quindi verifica sempre che abbiano completato il passo di attivazione.
I tester devono attivare di nuovo dopo un update?
No. Dopo che un tester attiva il test e installa, Google consegna i tuoi update automaticamente in pochi minuti. Non reinstallano né cliccano di nuovo sul link di attivazione. Lo status di attivazione, che il requisito di 14 giorni misura, prosegue senza interruzioni su ogni build nuovo sullo stesso canale chiuso.
Disinstallare è uguale a uscire dal test?
No. Un tester esce formalmente solo visitando il link web del test e scegliendo di uscire. Se disinstalla soltanto, il timer tecnicamente continua. In pratica chi disinstalla raramente torna, e questo può indebolire l’engagement che presenti quando richiedi l’accesso in produzione, quindi conviene comunque tenere i tester attivi.
Google vuole che invii update durante il test?
La documentazione di Google raccomanda di continuare a correggere i problemi nel test chiuso prima della produzione e di testare di routine gli update futuri. Il consenso della community di sviluppatori va oltre e tratta gli update attivi come segnale positivo di engagement, in contrasto con un’app congelata che sembra solo adempiere la quota. Google non ha pubblicato un numero obbligatorio di update, quindi itera in modo genuino, senza churn artificiale.
Di quanti tester ho davvero bisogno nel test chiuso?
Il minimo di Google è 12 tester attivati per 14 giorni consecutivi per gli account personali creati dopo il 13 novembre 2023. Poiché una sola uscita può lasciarti sotto i 12 e interrompere la sequenza, molti sviluppatori usano 20-25 tester come buffer. PrimeTestLab offre piani con 12, 20 e 25 tester a partire da $19.99.
Conclusione
Riepilogo
Aggiornare l’app durante il test chiuso di 14 giorni è sicuro, normale e incoraggiato. L’orologio misura se almeno 12 tester restano attivati in modo continuo, quindi un build nuovo da solo non lo azzera mai. I rischi reali sono scendere sotto i 12 tester attivati, le uscite formali o inviare un build così rotto che i tester abbandonano. Invia le tue correzioni, itera con il feedback e proteggi il conteggio con un buffer sopra il minimo. Se vuoi un orologio che semplicemente non si interrompe, PrimeTestLab mantiene da 12 a 25 tester reali attivati a partire da $19.99, con test live in 4-6 ore. Vedi i piani di prezzo →