Risposta rapida
Al 14 agosto 2026, Google Play impone agli sviluppatori con account sviluppatore personali creati dopo il 13 novembre 2023 di svolgere un test chiuso con almeno 12 tester rimasti attivati per almeno gli ultimi 14 giorni continuamente prima di poter richiedere l’accesso in produzione. Google ha annunciato questo requisito il 9 novembre 2023 con 20 persone per almeno due settimane, poi ha abbassato il minimo di tester a 12 l’11 dicembre 2024 mantenendo il periodo di 14 giorni. Raggiungere la soglia rende lo sviluppatore idoneo a fare richiesta, non approvato: Google esamina la richiesta, dice che quella revisione richiede di solito 7 giorni o meno e può chiedere altri test. Il test interno ha un proprio limite di 100 tester e non soddisfa questo prerequisito del test chiuso. L’accesso al test chiuso si può gestire tramite elenchi email o Google Groups, e si può concedere anche alle organizzazioni di managed Google Play.
Se il numero che ti manca sono le dodici persone
È l’unico dato di questa pagina che non puoi cercare da nessuna parte, ed è ciò che fornisce PrimeTestLab: tester reali che restano attivati per tutta la finestra. Come funziona →
Quasi tutte le pagine che si posizionano per queste ricerche rispondono a una domanda leggermente diversa da quella posta. Le ricerche dietro questo argomento sono in stragrande maggioranza ricerche di verifica: qualcuno ha già letto un numero da qualche parte e vuole sapere se è attuale, che cosa conta davvero e chi lo dice. È un lavoro diverso da quello di un tutorial, quindi questo articolo è costruito come un riferimento. Ogni statistica ha una frase, una data di riferimento e una fonte, e niente viene trasformato da ipotesi plausibile in fatto. Tutto qui è attuale al 14 agosto 2026, verificato lo stesso giorno sulle pagine della Guida di Google, sulla documentazione per sviluppatori e sui report di sicurezza pubblicati.
Vale la pena portarsi dietro due abitudini in tutti i blocchi qui sotto. Primo, 12 è il dato attuale e 20 è storico: le pagine che riportano ancora 20 come requisito 2026 stanno citando un annuncio che Google ha superato a dicembre 2024. Secondo, una soglia non è una decisione. Quasi tutte le discussioni preoccupate nella Developer Help Community di Google arrivano da qualcuno che aveva soddisfatto la condizione numerica e pensava che finisse lì.
Il banco di consultazione
Tre strumenti pensati per una pagina di numeri. Nessuno richiede un account, un caricamento o una richiesta di rete: ognuno gira nel tuo browser sui valori che scegli tu.
I cinque numeri più citati
Cinque dati portano quasi tutta la domanda dietro questo argomento: 12 tester, 14 giorni continuativi, la data limite degli account del 13 novembre 2023, la riduzione da 20 dell’11 dicembre 2024 e i 7 giorni o meno che Google indica come tempo abituale di revisione dell’accesso in produzione. Ognuno qui sotto è scritto come frase completa, così si può riprendere senza perderne il senso.
-
01
Verificato
Il minimo attuale di Google Play per il test chiuso è di 12 tester attivati per almeno gli ultimi 14 giorni continuamente, per i nuovi account sviluppatore personali interessati.
Guida di Google Play Console, risposta 14151465 · verificata il 14 agosto 2026
-
02
Verificato
La regola dei 12 tester riguarda gli account sviluppatore personali creati dopo il 13 novembre 2023.
Guida di Google Play Console, risposte 14151465 e 6112435 · verificate il 14 agosto 2026
-
03
Verificato, storico
L’annuncio originale di Google, il 9 novembre 2023, chiedeva 20 persone per almeno due settimane prima di richiedere l’accesso in produzione.
Android Developers Blog, 9 novembre 2023 · verificato il 14 agosto 2026
-
04
Verificato
Google ha abbassato il requisito da 20 tester a 12 l’11 dicembre 2024, mentre il periodo di test di due settimane è rimasto.
Aggiornamento dell’Android Developers Blog, più la guida ufficiale della Help Community di Google · verificati il 14 agosto 2026
-
05
Verificato
Google dice che la revisione di una richiesta di accesso in produzione richiede di solito 7 giorni o meno, anche se a volte può essere necessario più tempo.
Guida di Google Play Console, risposta 14151465 · verificata il 14 agosto 2026
Strumento 01
Compositore di citazioni
Scegli un numero qualsiasi di questa pagina e un formato. Ottieni la frase che sostiene, la sua fonte, la data in cui è stato verificato e il suo grado di affidabilità, pronti da incollare in un documento, in un ticket o in una risposta.
Ogni riga è datata di proposito. Le pagine delle norme cambiano, ed è così che una statistica senza data tiene in circolazione per due anni un numero ormai superato.
Dove vedere l’avanzamento e le statistiche del test chiuso in Play Console
Apri l’app in Play Console e controlla il requisito di test per l’accesso in produzione nella Dashboard dell’app. Il numero valido è il conteggio dei tester attivati mostrato per quel requisito, non la dimensione dell’elenco email, non gli eventi di installazione e nemmeno il numero di installazioni sul Play Store.
Questa è una ricerca a sé, e merita la risposta diretta qui sopra invece di una spiegazione che la precede. Il dato che decide la tua idoneità è il conteggio che Play Console riconosce rispetto al requisito di accesso in produzione stesso. È quello il numero da tenere d’occhio, ed è quello che legge il controllo sulla richiesta.
Il motivo per cui la cosa confonde è che lì vicino si vedono diversi altri conteggi e nessuno di essi è quello valido. Sono quattro misurazioni diverse:
| Che cosa vedi | Che cosa misura | È il numero valido? |
|---|---|---|
| Indirizzi nel tuo elenco email o gruppo di Google Groups | Chi è idoneo a partecipare al test. | No |
| Installazioni o eventi di installazione in Statistiche | Attività di installazione a livello di dispositivo, con un proprio ritardo di aggiornamento. | No |
| Numero di installazioni sulla scheda del Play Store | Dato aggregato lato store, non iscrizioni al test. | No |
| Tester attivati mostrati per il requisito di accesso in produzione | I tester che Play Console conta come continuamente attivati al test chiuso. | Sì |
Fonte: Guida di Play Console, risposta 14151465 e risposta 9845334 · verificate il 14 agosto 2026
Ne derivano due conseguenze pratiche, di natura diversa. Il conteggio dei tester validi può differire dai dati di installazione perché misurano cose diverse, quindi una discrepanza tra i due è normale e non è un difetto. Gli sviluppatori segnalano anche aggiornamenti ritardati del contatore, ma Google non pubblica né la frequenza di aggiornamento del contatore né il suo algoritmo di calcolo, quindi non c’è un intervallo documentato da aspettare. Usa il requisito di accesso in produzione nella Dashboard come indicazione definitiva dell’idoneità. La diagnosi completa per un contatore fermo sotto la dimensione del tuo elenco è nell’articolo su come aggiungere 12 tester e vederne zero attivati.
Non esiste una schermata a sé dedicata alle «statistiche del test chiuso». Play Console riporta installazioni, vitals e valutazioni sotto Statistiche e Android vitals, e riporta la tua idoneità rispetto al requisito di accesso in produzione nella Dashboard. Sono due superfici diverse, e solo la seconda misura la condizione 12/14. Guardare la prima aspettandosi la seconda è la versione più comune di questa confusione.
Parziale Google documenta entrambe le superfici; non pubblica alcun report di avanzamento unificato con quel nome.
La regola dei 12 tester per 14 giorni
Per un account interessato, la condizione di Google è un test chiuso con almeno 12 tester che sono stati attivati per almeno gli ultimi 14 giorni continuamente. Soddisfarla sblocca la possibilità di richiedere l’accesso in produzione dalla Dashboard dell’app. Non sblocca la produzione in sé.
«Se hai un account sviluppatore personale appena creato, devi eseguire un test chiuso per la tua app con un minimo di 12 tester che sono stati attivati per almeno gli ultimi 14 giorni continuamente.»
Guida di Google Play Console, risposta 14151465 · verificata il 14 agosto 2026
Leggi quella frase con calma, perché ci sono dentro quattro vincoli distinti e ognuno è un punto in cui gli sviluppatori perdono settimane. Il canale deve essere chiuso. Il conteggio è di almeno 12. Lo stato che si conta è lo stato di attivazione continua, non le installazioni, i download o un obiettivo documentato di utilizzo giornaliero. E la finestra è quella degli ultimi 14 giorni, continuamente, il che significa che il periodo valido è quello immediatamente alle tue spalle e non un qualsiasi quattordici giorni buono che puoi indicare nella tua storia.
Questa è la soglia numerica pubblicata, ed è solo metà del quadro. Il coinvolgimento viene valutato a parte, e resta comunque rilevante: Google chiede come i tester hanno usato l’app, se il loro utilizzo somigliava a quello che ti aspetti in produzione e che feedback hanno lasciato, e dice che un coinvolgimento insufficiente dei tester può portare a una richiesta di altri test invece che alla concessione dell’accesso. Lo stato di attivazione è ciò che misura il conteggio. Il coinvolgimento è ciò che legge la revisione.
| Statistica | Valore attuale | Che cosa significa davvero |
|---|---|---|
| Tipo di account interessato | Personale | Il requisito è documentato per i nuovi account personali, non per ogni sviluppatore su Google Play. |
| Data limite di creazione dell’account | Dopo il 13 novembre 2023 | Gli account personali creati in quella data o prima restano fuori dal gruppo descritto da questa pagina della Guida. |
| Canale richiesto | Test chiuso | Il test interno non lo sostituisce, per quante persone tu ci faccia passare. |
| Minimo di tester | 12 | Valore attuale. Era 20 fino all’11 dicembre 2024. |
| Periodo richiesto | 14 giorni continuamente | Quei tester devono essere rimasti attivati per tutti gli ultimi 14 giorni. |
| Passaggio successivo una volta qualificato | Richiedere l’accesso in produzione | Una richiesta dalla Dashboard dell’app, non una promozione automatica. |
| Sezioni della richiesta | 3 | Il tuo test chiuso, la tua app o il tuo gioco e la preparazione alla produzione. |
| Tempo di revisione dichiarato | 7 giorni o meno, di solito | Google dice di solito. Ammette esplicitamente revisioni più lunghe. |
Fonte: Guida di Play Console, risposta 14151465 · verificata il 14 agosto 2026
Dietro le date della riga sul minimo di tester c’è una storia che questo articolo di proposito non ripete. Se vuoi il racconto completo di come 20 sia diventato 12 e di che cosa ha detto Google a ogni passaggio, quella storia è nell’articolo su Google Play che è passata da 20 tester a 12. Qui c’è solo la documentazione, non il racconto.
A chi si applica il requisito
Google Play offre due tipi di account sviluppatore, Personale e Organizzazione, e applica per entrambi la stessa quota di registrazione una tantum di 25 US$. Il requisito di test aggiuntivo è documentato per gli account personali creati dopo il 13 novembre 2023. È tutto quello che il testo attuale della Guida dice sull’ambito.
Va detto con attenzione. «Gli account Organizzazione sono esenti» è la formula che usano tutti, ed è una lettura pratica ragionevole dell’ambito, ma Google non scrive quella frase nei testi della Guida esaminati per questa pagina. La versione sostenibile è quella che usa questo articolo: il requisito documentato dei 12 tester per l’accesso in produzione riguarda i nuovi account Personali interessati. Se stai scegliendo tra i due tipi di account, i pro e i contro sono spiegati nell’articolo su account personale e account dell’organizzazione.
Parziale Sostenuto dall’ambito, non da una frase esplicita di esenzione.
Che cosa conta davvero «14 giorni continuamente»
È la frase più riscritta di tutto l’argomento. Le pagine commerciali la riformulano abitualmente come 12 installazioni, 12 utenti attivi al giorno o un’app che deve restare installata per 14 giorni. Le parole di Google riguardano lo stato di attivazione mantenuto senza interruzioni, e la differenza conta perché cambia che cosa devi tenere d’occhio mentre il tempo scorre.
Questo lo dice Google
- Un minimo di 12 tester.
- Attivati per almeno gli ultimi 14 giorni continuamente.
- Il test deve essere un test chiuso.
- Ogni tester deve attivare il test tramite la procedura di iscrizione.
- Un utente attivato a un test interno deve disattivarlo prima di poter accedere a un test aperto o chiuso.
Questo Google non lo dice
- Che i tester debbano aprire l’app tutti i giorni.
- Che il requisito sia 12 installazioni o 12 utenti attivi al giorno.
- Che una disinstallazione equivalga automaticamente a una disattivazione.
- Che un singolo abbandono azzeri il conteggio di tutti riportandolo al giorno zero.
- Che ogni tester debba usare un dispositivo fisico invece di un emulatore.
Niente di tutto questo significa che il coinvolgimento sia irrilevante. Significa che il coinvolgimento viene giudicato altrove: nella richiesta di accesso in produzione, dove Google chiede come hai reclutato i tester, come hanno usato l’app e su quali feedback sei intervenuto. Tratta la finestra di 14 giorni come un conteggio di attivazioni da proteggere e la richiesta come il luogo in cui viene valutata la qualità del tuo test. Il funzionamento giorno per giorno della finestra è spiegato nell’articolo sulla regola dei 14 giorni consecutivi.
Strumento 02
I tuoi numeri
Questa pagina contiene una trentina di dati e solo alcuni sono condizioni per l’accesso in produzione. Rispondi a tre domande e li ordina in ciò che devi soddisfare per fare richiesta, ciò che succede dopo la qualificazione e i fatti sulla pubblicazione che valgono comunque.
Tutti i numeri dei canali di test di Google Play
Il test interno supporta fino a 100 tester per app. Il test chiuso si può gestire tramite elenchi email o Google Groups, e si può concedere l’accesso a un canale anche alle organizzazioni di managed Google Play. Gli elenchi email contengono fino a 2.000 utenti ciascuno, con 50 elenchi per canale e 200 elenchi in totale; Google afferma che non ci sono limiti di dimensione per i gruppi di Google Groups usati con canali chiusi aggiuntivi. Il test aperto è Illimitato oppure limitato a un tetto configurato di almeno 1.000.
| Canale o metodo | Limite documentato | Canale valido per il prerequisito? | La precisazione che conta |
|---|---|---|---|
| Interno | 100 tester per app | No | Canale facoltativo. Le build sono normalmente disponibili per i tester pochi minuti dopo la pubblicazione. |
| Chiuso, tramite elenco email | 2.000 utenti per elenco | Sì | Essere in elenco non è come attivare il test. Contano solo i tester attivati. |
| Chiuso, elenchi email per canale | 50 elenchi | Sì | È un limite di configurazione sugli elenchi. Non moltiplicarlo per ricavarne un tetto di tester unici. |
| Chiuso, elenchi email in totale | 200 elenchi | Sì | Limite di configurazione a livello di account descritto da Google. |
| Chiuso, tramite gruppo di Google Groups | Nessun limite di dimensione dichiarato per i gruppi usati con canali chiusi aggiuntivi | Sì | I tester devono entrare nel gruppo e poi attivare il test. Essere membri del gruppo non iscrive nessuno. |
| Chiuso, tramite organizzazione di managed Google Play | Nessun dato pubblicato sui tester | Sì | Scegli tu quale organizzazione può accedere al canale; sono gli amministratori di quell’organizzazione ad assegnare gli utenti. |
| Aperto | Illimitato, oppure una soglia configurata di 1.000 | No | I 1.000 sono il valore minimo a cui puoi impostare il limite, non un numero di partecipanti da reclutare. |
| Qualsiasi canale, account del tester | Account Google o account Google Workspace | Prerequisito per tutti | Google dice che per partecipare a un test gli utenti hanno bisogno di un Account Google o di un account Google Workspace. |
Fonti: Guida di Play Console, risposta 9845334 e risposta 14151465 · verificate il 14 agosto 2026
I numeri del test interno
Il test interno supporta fino a 100 tester per app, e Google scrive che un nuovo app bundle pubblicato sul canale interno è disponibile per i tester in pochi minuti. È il canale più rapido per mettere una build davanti a un piccolo gruppo, ed è proprio per questo che frega tanta gente: il prerequisito per l’accesso in produzione nomina un test chiuso, quindi il tempo passato sul canale interno non si somma ai 14 giorni per quante persone tu ci metta o per quanto diligentemente usino l’app. Non è nemmeno il canale più capiente, visto che un test aperto si può impostare su Illimitato.
Il test interno ha un vantaggio reale che gli altri canali non hanno: se l’app è a pagamento, i tester interni possono installarla gratis. In un test aperto o chiuso, dice Google, i tester devono comunque acquistare un’app a pagamento. È un costo vero da mettere in conto, ed è separato dalla quota di registrazione di $25.
L’errore più caro di questa pagina
Far passare dodici persone per quattordici giorni attraverso il test interno non produce nulla che conti per l’accesso in produzione. C’è poi una seconda trappola sopra la prima: Google dice che un utente attivato a un test interno deve disattivare il test interno prima di poter accedere a un test aperto o chiuso, quindi le stesse persone possono silenziosamente non risultare sul canale che invece conta.
I limiti degli elenchi del test chiuso
Il test chiuso si può popolare in tre modi, e i numeri famosi ne descrivono uno solo. Google documenta gli elenchi email di tester, Google Groups e la concessione dell’accesso al canale a un’organizzazione di managed Google Play. I dati che citano tutti, 2.000 utenti per elenco, 50 elenchi per canale di test e 200 elenchi email in totale, sono limiti sugli elenchi email in particolare. Sono tre tetti di configurazione distinti, e nessuno di essi dice quante persone diverse possono testare la tua app.
Qualunque strada tu scelga, il passaggio di iscrizione è lo stesso ed è quello che decide il tuo numero. I tester hanno bisogno di un Account Google o di un account Google Workspace, e ognuno deve attivare il test tramite il link di attivazione. Per un gruppo di Google Groups, Google è esplicita: gli utenti devono entrare nel gruppo prima di attivare il test, quindi essere membri del gruppo ed essere tester validi sono due stati diversi con due conteggi diversi.
Non moltiplicare questi numeri. Cinquanta elenchi per duemila utenti è un calcolo, non una statistica di Google. Google indica limiti sugli elenchi, non un tetto definitivo di persone diverse, quindi una cifra come «100.000 tester al massimo» è un numero ricavato che viene spacciato per documentazione. Questa pagina non lo pubblica, e non dovrebbe farlo nemmeno chi la cita.
C’è un secondo motivo per cui il calcolo non regge. Gli elenchi email non sono l’unico modo di popolare un test chiuso: Google documenta anche l’uso di Google Groups, e dice che per quei gruppi non ci sono limiti di dimensione. Un tetto che si aggira scegliendo un’altra configurazione non era un tetto sui tester fin dall’inizio.
I numeri del test aperto
Un test aperto si può impostare su Illimitato oppure limitare a un tetto di tester che configuri tu, e in quel caso il limite configurato deve essere di almeno 1.000. È il numero più citato a sproposito di tutto l’argomento. È una soglia minima di un’impostazione, non l’obbligo di trovare mille persone, e non ha niente a che vedere con il requisito del test chiuso. Google documenta anche la possibilità di condurre più test chiusi insieme a un test aperto nello stesso momento.
Se il test aperto è disattivato
Per un nuovo account personale interessato è lo stato previsto, non un bug. L’attuale pagina dei requisiti di Google dice che il test aperto diventa disponibile quando è disponibile l’accesso in produzione, quindi l’ordine è prima il test chiuso, poi la richiesta, poi gli altri canali. A che cosa serve ciascun canale, e quale scegliere una volta che li hai tutti a disposizione, è spiegato nel confronto tra test interno, chiuso e aperto.
Strumento 03
Pianificatore dei limiti di canale
Scegli un canale, indica se stai testando per soddisfare il requisito dei nuovi account personali e inserisci l’elenco di tester che hai in mente. Lo strumento lo confronta con i limiti documentati per quella specifica configurazione, invece di applicare la soglia dei 12 tester a ogni test chiuso mai fatto.
Statistiche sull’accesso in produzione
Il giorno 14 non pubblica niente. Ti rende idoneo a richiedere l’accesso in produzione dalla Dashboard dell’app, con una richiesta in 3 sezioni. Google la esamina, dice che quella revisione richiede di solito 7 giorni o meno e può concludere che l’app non è pronta e chiederti di continuare a testarla. Una richiesta accolta concede l’accesso in produzione e il test aperto.
-
Passaggio 1
Qualificarsi
Almeno 12 tester attivati per almeno gli ultimi 14 giorni continuamente, sul canale chiuso.
Questo lo controlli tu -
Passaggio 2
Fare richiesta
Una richiesta in 3 sezioni dalla Dashboard dell’app: il tuo test chiuso, la tua app o il tuo gioco e la preparazione alla produzione.
Questo lo controlli tu -
Passaggio 3
Revisione
Decide Google. Di solito 7 giorni o meno, a volte di più, e l’esito può essere una richiesta di altri test.
Questo lo controlla Google
Quasi tutte le discussioni preoccupate nella Developer Help Community di Google si riducono allo scarto tra il secondo e il terzo passaggio. Gli sviluppatori scrivono titoli come «accesso in produzione rifiutato nonostante 12 tester attivati per 14 giorni continuamente» e raccontano di tester che non hanno mai disinstallato, perché avevano capito che la soglia fosse la decisione. Non lo è. Dodici tester per quattordici giorni continuativi sono una condizione di idoneità, e la procedura documentata da Google dice chiaramente che può chiedere di continuare a testare se ritiene che l’app non sia pronta.
Completare 12 tester per 14 giorni continuativi rende lo sviluppatore idoneo a fare richiesta di accesso in produzione. Non garantisce l’approvazione per la produzione.
Guida di Google Play Console, risposta 14151465 · verificata il 14 agosto 2026
Nessuno fuori da Google può dare un numero su quanto spesso la revisione dica di no, perché Google non lo pubblica. I rifiuti ripetuti sono ben documentati nella Help Community di Google, non in una statistica, quindi questa pagina li tratta come una possibilità documentata con prove dalla community, non come un tasso. Come si recupera dopo un diniego, compreso se ricominci una nuova finestra, è spiegato nell’articolo sui motivi per cui il test chiuso viene rifiutato.
Che cosa chiede Google dopo il test chiuso
La richiesta ha tre sezioni. Le domande di Google riguardano come hai trovato i tester e come hai lavorato con loro, che cosa è l’app e a chi è rivolta, e se è pronta per un pubblico ampio. Non c’è nessuna formula di punteggio pubblicata dietro di esse, quindi l’atteggiamento utile è l’accuratezza, non l’ottimizzazione.
Come sono stati reclutati i tester, come hanno usato l’app e che feedback è arrivato.
Che cosa fa l’app, a chi è rivolta e che valore offre a quel pubblico.
Che cosa è cambiato grazie al test e perché ora l’app è pronta per la produzione.
Non esiste una griglia di risposte pubblicata. Google indica le tre sezioni e gli argomenti su cui fa domande. Non pubblica un modello di punteggio, un limite di caratteri o un elenco di frasi che fanno passare. Qualsiasi pagina che ne presenti uno se l’è inventato. Esempi concreti di come gli sviluppatori descrivono davvero il proprio test sono nell’articolo sul questionario per l’accesso in produzione.
Sui tempi, i 7 giorni o meno di Google sono l’unico dato con una fonte primaria alle spalle, e Google lo accompagna con «di solito». Trattalo come la descrizione del caso comune e non come una scadenza su cui pianificare una data di lancio. I tempi di revisione fase per fase lungo tutto il percorso di pubblicazione sono spiegati nell’articolo sui tempi di revisione di Google Play.
Cronologia della norma sul test chiuso
Quattro date raccontano tutta la storia: l’annuncio, la data limite degli account interessati quattro giorni dopo, la riduzione da 20 a 12 di dicembre 2024 e lo stato attuale. La data dell’annuncio e la data limite sono due cose diverse, e confonderle è l’errore più comune negli articoli su questa norma.
-
9 novembre 2023
Annunciata con 20 tester
Google ha annunciato che i nuovi account sviluppatore personali avrebbero dovuto testare con 20 persone per almeno due settimane prima di richiedere l’accesso in produzione, così da individuare problemi e raccogliere feedback prima del lancio.
Verificato, storico -
13 novembre 2023
La data limite degli account interessati
La data che l’attuale pagina della Guida di Google usa per definire chi è interessato: gli account sviluppatore personali creati dopo di essa. È un confine tra gruppi, non la data dell’annuncio, e le due distano quattro giorni.
Verificato -
11 dicembre 2024
20 è diventato 12
Google ha aggiornato la norma abbassando il requisito di test da 20 tester a 12. Il periodo di 14 giorni è rimasto invariato. Gli sviluppatori si sono accorti del cambiamento in Play Console prima che la documentazione si allineasse, ed è per questo che alcune discussioni dell’epoca lo trattano come un possibile bug.
Verificato -
Oggi, 14 agosto 2026
12 tester, 14 giorni continuativi
Lo stato attuale, verificato sulla pagina dei requisiti di Google a questa data. Nelle fonti esaminate non è stata trovata alcuna soglia sostitutiva né una data di fine per questa regola.
Verificato
Questa è la documentazione, senza il racconto. La ricostruzione completa di che cosa è cambiato, del perché gli sviluppatori hanno reagito così e di che cosa ha significato per le app che erano a metà test è nell’articolo su Google Play che è passata da 20 tester a 12, che resta il resoconto di riferimento di questo sito sul cambio di norma.
Che cosa dice Google, e che cosa non dice
Otto affermazioni fanno quasi tutti i danni su questo argomento, e tutte e otto sono estrapolazioni dalle parole reali di Google, non citazioni. La tabella qui sotto affianca il sintomo così come lo raccontano gli sviluppatori alla lettura più sostenibile della documentazione, e indica quanto sia solida quella lettura.
| Che cosa raccontano gli sviluppatori | Spiegazione più sostenibile | Che cosa controllare | Grado |
|---|---|---|---|
| «Ho aggiunto 12 email ma Play Console ne conta di meno.» | Essere in un elenco email non è come aver completato l’attivazione come tester. | Verifica che ogni tester abbia usato il link di attivazione con un account idoneo e abbia davvero attivato il test. | Verificato |
| «Ho fatto un test interno con più di 12 persone per 14 giorni.» | Il prerequisito indica il test chiuso. Il tempo del test interno non si somma a quello. | Configura e avvia il canale di test chiuso. La disponibilità di 100 persone del test interno non lo sostituisce. | Verificato |
| «Sono arrivato al giorno 14, perché non riesco a pubblicare?» | Il giorno 14 ti rende idoneo a richiedere l’accesso in produzione, niente di più. | Apri la Dashboard dell’app e compila la richiesta di accesso in produzione appena compare l’idoneità. | Verificato |
| «Google mi ha rifiutato anche se avevo 12 tester.» | La soglia governa l’idoneità a fare richiesta, non l’esito della revisione. | Continua a testare se te lo chiedono, e rispondi alla richiesta in modo accurato su reclutamento, coinvolgimento, feedback e preparazione. | Verificato |
| «Il test aperto è disattivato per la mia app.» | È previsto nel percorso degli account interessati. Il test aperto diventa disponibile quando è disponibile l’accesso in produzione. | Completa prima il test chiuso e la richiesta di accesso in produzione. | Verificato |
| «I miei tester devono aprire l’app tutti i giorni?» | Google indica l’attivazione continua. Non pubblica alcuna condizione numerica di un’apertura al giorno. | Incoraggia un uso autentico e raccogli feedback, perché il coinvolgimento viene valutato nella richiesta, ma non presentare le aperture giornaliere come una regola di Google. | Verificato |
| «Un tester ha disinstallato. I miei 14 giorni sono ripartiti da zero?» | La condizione pubblicata è l’attivazione continua, e la fonte non equipara la disinstallazione a una disattivazione. | Controlla lo stato di attivazione reale e se almeno 12 tester soddisfano ancora la condizione dei 14 giorni continuativi. | Parziale |
| «Dopo un rifiuto il mio conteggio dei tester sembra sbagliato.» | Segnalato più volte nella Help Community di Google. Google non documenta un algoritmo di conteggio che lo spieghi. | Confronta l’elenco con lo stato di attivazione prima di dare per scontato un difetto della Console. «Tester fantasma» è un modo di dire degli sviluppatori, non un termine di Google. | Segnalato |
Lo schema è lo stesso in tutte e otto le righe. Google pubblica una soglia e una procedura; non pubblica i meccanismi che ci stanno sotto. È in quel vuoto che le pagine commerciali infilano dettagli dal tono sicuro, ed è per questo che questo articolo assegna un grado a ogni riga invece di appiattirle in un’unica voce. Se è proprio il tuo contatore a restare fermo sotto la dimensione dell’elenco, la diagnosi completa è nell’articolo su come aggiungere 12 tester e vederne zero attivati.
Sui servizi di tester a pagamento, compreso questo. Nella Help Community di Google alcuni sviluppatori hanno chiesto esplicitamente se usare un servizio a pagamento avesse causato il loro rifiuto. Nessuna fonte Google primaria trovata per questa pagina dice che i servizi di tester a pagamento siano consentiti, e nessuna dice che siano vietati. La posizione accurata è che Google documenta requisiti ed esamina richieste; non pubblica alcuna regola sui canali di reclutamento, né in un senso né nell’altro. Qualsiasi pagina che sostenga che Google li approva o li vieta sta riempiendo con un’opinione un vuoto della documentazione.
Non verificato Nessuna fonte Google primaria individuata in nessuna delle due direzioni.
Numeri che Google non pubblica
Sei tra gli elementi più citati di questo argomento non avevano nessuna fonte Google primaria alle spalle tra le fonti esaminate per questa pagina: un tasso di approvazione del test chiuso, un tasso di rifiuto, un conteggio esatto e attuale delle app su Google Play, una soglia di aperture giornaliere dell’app, una formula di punteggio per la revisione dell’accesso in produzione e l’algoritmo dietro il conteggio dei tester di Play Console. Se una pagina te ne propone uno come statistica di Google, chiedile da quale pagina Google primaria arriva quel dato.
-
Un tasso di approvazione o di successo del test chiuso Nessuna fonte trovata
Non è stata individuata alcuna percentuale pubblicata da Google che descriva quanto spesso agli sviluppatori che soddisfano la soglia 12/14 venga concesso l’accesso in produzione. Le percentuali in circolazione arrivano da servizi commerciali che descrivono i propri risultati, che è una misurazione diversa con un denominatore diverso.
-
Un tasso di rifiuto di Google Play Nessuna fonte trovata
Google pubblica conteggi di app in violazione delle norme che sono state fermate, non una percentuale di rifiuto basata su un denominatore. Da quei conteggi non si può ricostruire un tasso, perché la popolazione da cui sono tratti non viene pubblicata insieme a essi.
-
Un conteggio esatto e attuale delle app su Google Play Milioni, non quantificati
I materiali attuali di Google descrivono Play come la casa di milioni di app e contenuti invece di dare una cifra precisa. Esistono stime commerciali di app intelligence, che non sono numeri di Google, quindi questa pagina non ne mette una al loro posto.
-
Un obbligo di aperture giornaliere dell’app Non è nella regola
La regola di idoneità attuale indica l’attivazione continua e non stabilisce un requisito numerico di un’apertura dell’app al giorno per tester. Google chiede però del coinvolgimento dei tester quando valuta l’accesso in produzione, ed è lì che il coinvolgimento conta davvero.
-
Una formula di punteggio per l’accesso in produzione Nessuna fonte trovata
Google indica le tre sezioni della richiesta e gli argomenti su cui fa domande. Nella documentazione esaminata per questa pagina non compare alcun peso, soglia, limite di caratteri o modello di valutazione delle risposte.
-
Un algoritmo di conteggio dei tester o di azzeramento Nessuna fonte trovata
Google pubblica la condizione secondo cui almeno 12 tester devono essere stati attivati per gli ultimi 14 giorni continuamente. Non pubblica come Play Console ricavi quel conteggio, che cosa succeda ai singoli conteggi quando un tester si sfila, né se qualche evento azzeri la finestra per tutti. Le storie sugli azzeramenti che circolano sono deduzioni dal comportamento della Console, non documentazione.
C’è un’altra assenza che vale la pena nominare, perché è quella che più spesso viene riempita con qualcosa dal tono autorevole. Google non ha pubblicato un impatto numerico a sé stante per il requisito dei 12 tester. I suoi report sulla sicurezza mettono i requisiti di test insieme alla verifica degli sviluppatori e ai controlli obbligatori prima della revisione, e ne descrivono l’effetto complessivo. Qualsiasi frase del tipo «la regola dei 12 tester ha ridotto X del Y per cento» è una costruzione, non una citazione.
Un test che puoi fare su qualsiasi pagina, compresa questa
Per ogni statistica, fatti tre domande: da quale frase esatta è tratta, quando è stata verificata l’ultima volta quella frase e la fonte lo dice davvero o è la pagina che lo lascia intendere? Una statistica che non supera queste tre domande non è una statistica. Ogni numero qui sopra è scritto in modo da poter essere ricondotto al numero di una risposta della Guida di Play Console o a una pubblicazione Google citata per nome, ed è anche per questo che il Compositore di citazioni all’inizio dell’articolo allega la fonte e la data a tutto ciò che copi.
Come PrimeTestLab ti aiuta con il numero che non puoi cercare da nessuna parte
Ogni dato verificato qui sopra si può ricondurre a una fonte primaria; le interpretazioni parziali e i dati che Google non pubblica sono etichettati a parte. Un solo dato di questa pagina è un compito e non un fatto: 12 persone reali, attivate, per 14 giorni continuativi. PrimeTestLab fornisce quel gruppo su dispositivi reali da Android 7 a 17, a partire da $19.99, e lo mantiene per tutta la finestra, così il conteggio non scende sotto la soglia mentre tu lavori alla build.
Quello che ottieni è un conteggio di attivazioni stabile, cioè l’unica variabile di cui la documentazione ti rende responsabile e quella che manda in fumo silenziosamente la maggior parte dei test organizzati per conto proprio. Non ottieni una decisione. La richiesta di accesso in produzione la esamina Google, e nessun servizio può promettere l’esito di quella revisione. Quello a cui possiamo impegnarci è la parte sotto il nostro controllo: se una campagna non consegna il test che hai pagato, la garanzia è un nuovo test gratuito o un rimborso completo.
| Che cosa va gestito | Reclutare il gruppo da solo | Un gruppo gestito |
|---|---|---|
| Almeno 12 tester | Amici, forum e gruppi di scambio. Trovarne dodici è possibile; trovarne dodici che arrivino fino in fondo è la parte difficile. | 12 assegnati fin dall’inizio, con piani più grandi da 20 e 25 tester per avere margine sopra il minimo. |
| Attivati per 14 giorni continuativi | Controlli lo stato di attivazione ogni giorno e rincorri chi si sfila, perché scendere sotto il minimo interrompe la condizione di continuità. | Il gruppo viene mantenuto per tutta la finestra, quindi proteggere quel conteggio è il lavoro di qualcun altro. |
| Varietà di tester e dispositivi | Chiunque riesci a convincere, con l’hardware che si ritrova. | Persone reali su dispositivi reali da Android 7 a 17, in 120+ Paesi. |
| Feedback per la domanda sulla preparazione | Dipende del tutto da quanto sono coinvolte le persone che hai reclutato. Spesso è il punto più debole di un test organizzato per conto proprio. | Feedback strutturati dei tester a cui puoi fare riferimento quando la richiesta ti chiede che cosa è cambiato grazie al test. |
| Costo | Nessun esborso in denaro, si paga in giornate passate a rincorrere le persone proprio nella finestra in cui dovresti sviluppare. | Da $19.99 per il piano da 12 tester. |
| La decisione sull’accesso in produzione | È di Google | Resta di Google. Nessun servizio può promettere l’approvazione, e chi lo fa sta descrivendo qualcosa che non controlla. |
Come ordine di grandezza, non come promessa sulla tua app: PrimeTestLab ha gestito il test chiuso per 7.400+ app con un risultato del 99,9% in 120+ Paesi. Sono numeri nostri, misurati sulle nostre campagne, e appartengono alla stessa categoria di tutti gli altri dati di parte che si trovano in rete: utili, e non una statistica di Google.
Domande frequenti
Nel 2026 servono ancora 20 tester per Google Play?
No. Il minimo attuale è 12 tester, non 20. Google ha annunciato un requisito di 20 persone per almeno due settimane il 9 novembre 2023 e l’11 dicembre 2024 ha aggiornato la norma abbassando il minimo di tester a 12, mentre il periodo di 14 giorni è rimasto invariato. Le pagine che riportano ancora 20 come dato del 2026 stanno citando l’annuncio superato.
I 12 tester devono restare attivati per tutti i 14 giorni?
Google scrive che almeno 12 tester devono essere stati attivati per almeno gli ultimi 14 giorni continuamente. Per quella soglia numerica pubblicata Google conta lo stato di attivazione continua, non le installazioni, i download o un obiettivo documentato di utilizzo giornaliero. Il coinvolgimento è una cosa distinta ma comunque rilevante: Google chiede come i tester hanno usato l’app, se il loro utilizzo somigliava a quello atteso in produzione e che feedback hanno lasciato, e un coinvolgimento insufficiente può portare a una richiesta di altri test. Un gruppo di tester che hanno partecipato ciascuno in momenti diversi non equivale a 12 tester tutti attivati nella stessa finestra continua di 14 giorni.
Quando comincia davvero il periodo di 14 giorni?
Non quando aggiungi gli indirizzi email. Aggiungere qualcuno a un elenco o a un gruppo di Google Groups rende quella persona soltanto idonea a partecipare; lo stato che conta è quello dei tester che hanno completato l’attivazione e sono poi rimasti attivati. La condizione che Google pubblica è che almeno 12 tester siano stati attivati per almeno gli ultimi 14 giorni continuamente, quindi considera come fonte di verità lo stato di idoneità che Play Console mostra per il requisito di accesso in produzione, invece di contare i giorni dalla data in cui hai configurato il canale.
Il test interno vale per i 12 tester per 14 giorni?
No. Il prerequisito di Google per l’accesso in produzione richiede espressamente un test chiuso. Il test interno è descritto a parte come un canale facoltativo che supporta fino a 100 tester per app, e le build interne sono normalmente disponibili per i tester pochi minuti dopo la pubblicazione. Far passare 12 persone attraverso un test interno per 14 giorni non soddisfa il requisito del test chiuso.
I miei 12 tester devono aprire l’app tutti i giorni?
Il requisito numerico pubblico di Google non indica una soglia di un’apertura dell’app al giorno. La condizione numerica documentata è l’attivazione continua. Il coinvolgimento conta comunque, perché la richiesta di accesso in produzione chiede agli sviluppatori come sono stati reclutati i tester, come hanno usato l’app e che feedback hanno dato, e Google dice che un coinvolgimento insufficiente dei tester può portare a una richiesta di altri test. Quello che nessuna fonte Google trovata per questa pagina pubblica è un numero di aperture giornaliere, quindi tratta l’uso autentico come qualcosa da incoraggiare e da descrivere, non come una quota documentata da raggiungere.
Ho completato i 14 giorni. Sono approvato automaticamente per la produzione?
No. Completare un test chiuso valido ti rende idoneo a richiedere l’accesso in produzione dalla Dashboard dell’app in Play Console. Google esamina quella richiesta e può concludere che l’app non è pronta e chiederti di continuare a testarla. Dodici tester per 14 giorni continuativi sono una soglia di idoneità, non una garanzia di approvazione.
Quanto tempo impiega Google a esaminare l’accesso in produzione?
L’attuale pagina della Guida di Google dice che la revisione dell’accesso in produzione richiede di solito 7 giorni o meno, e che a volte può essere necessario più tempo. È la descrizione del caso normale, non un accordo sui livelli di servizio né una data di decisione garantita, quindi non va mai citata come una scadenza esatta di sette giorni.
Posso usare il test aperto invece del test chiuso?
Non per questo prerequisito. L’attuale pagina dei requisiti di Google descrive un test chiuso per i nuovi account personali interessati, e dice che il test aperto diventa disponibile quando è disponibile l’accesso in produzione. Il dato di 1.000 associato al test aperto è il limite minimo di tester configurabile quando un test aperto non è impostato su Illimitato, non l’obbligo di reclutare 1.000 partecipanti.
Posso usare Google Groups invece dei singoli elenchi email?
Sì. Google documenta l’accesso al test chiuso tramite elenchi email di tester, tramite Google Groups e concedendo l’accesso al canale a un’organizzazione di managed Google Play. I valori di 2.000 utenti per elenco, 50 elenchi per canale e 200 elenchi in totale riguardano nello specifico gli elenchi email; Google afferma che non ci sono limiti di dimensione per i gruppi di Google Groups usati con canali chiusi aggiuntivi. Essere membro di un gruppo non è la stessa cosa che essere attivato: Google dice che gli utenti devono entrare nel gruppo prima di attivare il test, quindi sono due conteggi distinti.
I miei tester hanno bisogno di un Account Google?
Sì. Google dice che per partecipare a un test gli utenti hanno bisogno di un Account Google o di un account Google Workspace. Un indirizzo presente nella tua rubrica o una normale casella di posta non collegata a un account Google idoneo non può completare l’attivazione, ed è uno dei motivi per cui un elenco può sembrare completo mentre il conteggio valido resta più basso.
I tester del test chiuso devono acquistare un’app a pagamento?
Sì, se l’app è a pagamento. Google dice che i tester di un test aperto o chiuso devono comunque acquistare l’app, mentre i tester di un test interno possono installare gratuitamente un’app a pagamento. Quel costo si aggiunge alla quota di registrazione sviluppatore una tantum di 25 US$ e a quanto paghi a un fornitore di test, e riguarda proprio il canale chiuso richiesto dal requisito per l’accesso in produzione.
Gli account Organizzazione devono fare il test con 12 tester?
La documentazione attuale di Google circoscrive questo requisito di test aggiuntivo agli account sviluppatore personali creati dopo il 13 novembre 2023, e separatamente indica Personale e Organizzazione come i due tipi di account sviluppatore. L’affermazione precisa e sostenibile è che il requisito documentato dei 12 tester per l’accesso in produzione riguarda i nuovi account Personali interessati. Nei testi della Guida esaminati per questa pagina Google non usa la frase gli account Organizzazione sono esenti.
Perché Play Console mostra meno tester delle email che ho aggiunto?
Aggiungere un indirizzo a un elenco email idoneo e far completare a quella persona l’attivazione come tester sono due passaggi diversi. Google dice agli sviluppatori di distribuire il link di attivazione e che ogni tester deve attivare il test. Le discussioni della Developer Help Community mostrano di continuo elenchi più grandi del conteggio valido proprio per questo motivo, quindi controlla lo stato di attivazione di ogni tester e non la dimensione dell’elenco.
Dove vedo l’avanzamento del mio test chiuso in Play Console?
Controlla il requisito di test per l’accesso in produzione mostrato nella Dashboard dell’app. Il dato che conta è il numero di tester che Play Console riconosce come attivati per quel requisito, non il numero di indirizzi email che hai aggiunto, non le installazioni mostrate in Statistiche e nemmeno il numero di installazioni sulla scheda del Play Store. Quel conteggio valido può differire dai dati di installazione perché le due cose misurano cose diverse. Gli sviluppatori segnalano anche aggiornamenti ritardati del contatore, ma Google non pubblica né la frequenza di aggiornamento del contatore né il suo algoritmo di calcolo, quindi usa il requisito di accesso in produzione nella Dashboard come indicazione definitiva dell’idoneità.
Disinstallare l’app azzera i 14 giorni?
La condizione pubblicata da Google è formulata intorno ai tester che restano attivati continuamente, e la documentazione primaria esaminata per questa pagina non dice che la sola disinstallazione equivalga a una disattivazione. Tratta lo stato di attivazione come il numero da tenere d’occhio. Se meno di 12 tester soddisfano la condizione dei 14 giorni continuativi non sei ancora idoneo a fare richiesta, ma l’idea diffusa che una singola disinstallazione azzeri automaticamente tutto il test non trova conferma nella fonte.
Google pubblica un tasso di approvazione o di successo del test chiuso?
Nelle fonti primarie esaminate per questa pagina non è stato trovato alcun tasso di approvazione, tasso di rifiuto o percentuale di successo pubblicato da Google per il requisito dei 12 tester. Google pubblica dati sulla sicurezza a livello di ecosistema, per esempio di aver impedito la pubblicazione di oltre 1,75 milioni di app in violazione delle norme nel 2025, ma sono conteggi riferiti a tutto Google Play e non si possono convertire in un tasso di approvazione del test chiuso. Considera priva di fonte qualsiasi percentuale presentata come tasso di successo del test chiuso di Google, finché non la riporta una pagina Google primaria.
Quanto costa svolgere il test chiuso con 12 tester reali?
Google applica una quota di registrazione sviluppatore una tantum di 25 US$ e non fa pagare il test chiuso in sé, quindi il vero costo del test è trovare 12 persone che restino attivate per 14 giorni continuativi. PrimeTestLab fornisce 12 tester reali su dispositivi reali a partire da $19.99 e mantiene il gruppo per tutti i 14 giorni, con nuovo test gratuito o rimborso completo. Nessun servizio può promettere l’approvazione di Google, perché la decisione sull’accesso in produzione è di Google.
Appendice
Statistiche adiacenti su Google Play
Tutto quello che precede è un numero sul test chiuso. Quello che segue è l’insieme di dati che gli sviluppatori vengono a cercare qui subito dopo: quanto costa l’account in sé e quando Google chiude quelli inutilizzati, le date del livello API target e delle norme che decidono se una build viene accettata, le soglie di Android vitals che governano la visibilità nello store e i conteggi di Google sulle azioni contro le violazioni nell’ecosistema. Stesse fonti, stessi gradi di affidabilità, stessa data di verifica: nessuno di questi è una condizione del requisito 12/14, ed è per questo che stanno qui e non dentro di esso.
Dati su account sviluppatore e pubblicazione
Google Play applica una quota di registrazione una tantum di 25 US$, richiede che il titolare dell’account abbia almeno 18 anni e offre due tipi di account, Personale e Organizzazione. Le nuove app devono essere pubblicate come Android App Bundle da agosto 2021. Nessuno di questi punti dipende dal requisito del test chiuso, e tutti compaiono nelle stesse risposte della Guida.
| Statistica | Valore | Affidabilità | Precisazione |
|---|---|---|---|
| Quota di registrazione sviluppatore | 25 US$ | Verificato | Una tantum, addebitata al momento della registrazione. Non è un abbonamento annuale. |
| Età minima dello sviluppatore | 18 anni | Verificato | Dichiarata sulla pagina di registrazione dell’account di Google. |
| Tipi di account sviluppatore | 2 | Verificato | Personale e Organizzazione. Il requisito del test chiuso è documentato per i nuovi account Personali. |
| Obbligo dell’Android App Bundle | Da agosto 2021 | Verificato | Vale per le nuove app su Google Play. Nei testi destinati a durare usa il mese, non un giorno preciso. |
| Esenzione degli account Organizzazione | Deduzione dall’ambito | Parziale | Google circoscrive il requisito ai nuovi account Personali. Non scrive una frase di esenzione per gli account Organizzazione. |
Fonti: Guida di Play Console, risposta 6112435 e documentazione dell’Android App Bundle · verificate il 14 agosto 2026
La quota è il numero che più spesso viene ricordato male come ricorrente, e vale la pena essere precisi su che cosa dà e che cosa non dà. Serve a registrare l’account sviluppatore. Non accorcia il test chiuso, non esenta un account interessato dal doverlo fare e non velocizza la revisione dell’accesso in produzione. Che cosa succede davvero dopo quel pagamento, passo per passo, è spiegato nell’articolo su cosa fare dopo aver pagato la quota di $25.
Dati sull’inattività dell’account
Stanno in questa pagina perché sono i numeri che decidono se l’account per cui hai pagato 25 US$ esiste ancora quando ci torni. Google li pubblica, e sono più specifici di quanto la maggior parte degli sviluppatori si aspetti: un anno, 1.000 installazioni complessive nell’arco di vita, 180 giorni di utilizzo di Play Console e avvisi di preallarme a 60, 30 e 7 giorni dalla chiusura.
| Caso | Condizioni elencate da Google | Affidabilità |
|---|---|---|
| Account senza app | Creato più di un anno fa e non ha mai inviato un’app per la revisione. | Verificato |
| Account con app | Creato più di un anno fa; tutte le app pubblicate, comprese quelle attive, rimosse e sospese, hanno meno di 1.000 installazioni complessive nell’arco di vita; il numero di telefono e l’email di contatto dell’account non sono verificati; e Play Console non è stata usata negli ultimi 180 giorni. | Verificato |
| Calendario degli avvisi | Avvisi di promemoria a 60, 30 e 7 giorni dalla chiusura dell’account. | Verificato |
| La quota dopo la chiusura | La quota di registrazione non viene rimborsata quando un account viene chiuso per inattività. | Verificato |
Fonte: Guida di Play Console, risposta 11605267 · verificata il 14 agosto 2026
Riproduci le condizioni, non una scorciatoia logica. I quattro dati qui sopra sono esattamente quelli che Google elenca per un account che ha pubblicato app. Questa pagina li riporta come insieme, nell’ordine di Google, e non li comprime in «basta una di queste per far chiudere l’account» o «devono valere tutte e quattro insieme», perché le riformulazioni più diffuse di questa regola sono in disaccordo tra loro e la pagina di partenza è un elenco, non una formula. L’unico numero che questa pagina continua a non riportare è il conteggio esatto e attuale delle app su Google Play: i materiali di Google parlano di «milioni» invece di dare una cifra, e le stime commerciali di app intelligence non sono un numero di Google.
Parziale Condizioni verificate una per una. La relazione logica esatta tra loro non è dichiarata in modo abbastanza esplicito da poter essere parafrasata.
Le scadenze del 2026 e del 2027
Tre date di pubblicazione sono abbastanza vicine al requisito del test chiuso da comparire nelle stesse risposte della Guida. Le nuove app per telefoni e tablet e i loro aggiornamenti devono in genere avere come target Android 16, livello API 36 o superiore, dal 31 agosto 2026. È possibile chiedere una proroga fino al 1 novembre 2026. La nuova norma sulle autorizzazioni per i contatti entra in vigore il 27 gennaio 2027, non il 28 ottobre 2026.
| Data | Di che si tratta | Il numero in gioco | Stato |
|---|---|---|---|
| Agosto 2021 | Le nuove app su Google Play devono usare l’Android App Bundle | AAB obbligatorio | Attuale |
| 9 novembre 2023 | Annuncio originale del requisito di test | 20 persone, minimo 2 settimane | Storico |
| 13 novembre 2023 | Data limite degli account interessati dal requisito di test | Nuovi account personali dopo questa data | Definizione attuale del gruppo interessato |
| 11 dicembre 2024 | Soglia dei tester abbassata | 20 diventa 12 | Soglia attuale |
| 31 agosto 2025 | Soglia del livello API target per gli invii Android TV | Android 14, API 34 | In vigore |
| 31 agosto 2026 | Soglia del livello API target per le nuove app per telefoni e tablet e i loro aggiornamenti | Android 16, API 36 | In vigore |
| 1 novembre 2026 | Termine della proroga richiedibile sul livello API target | Proroga fino a questa data | In arrivo |
| 28 ottobre 2026 | Data precedente della norma sui contatti | Superata | Da non pubblicare come attuale |
| 27 gennaio 2027 | Data di entrata in vigore della norma sulle autorizzazioni per i contatti | Nuova norma sui contatti | Scadenza pubblicata attuale |
La soglia del livello API target del 31 agosto 2026
Dal 31 agosto 2026, le nuove app e i loro aggiornamenti su Google Play devono in genere avere come target un livello API minimo, e la soglia non è uguale per tutti i tipi di dispositivo. Telefoni e tablet sono a API 36. Wear OS e Android Automotive OS sono a API 35. Android TV e Android XR sono a API 34. La soglia API 34 di Android TV non è nuova a quella data: la Guida di Play Console la fa risalire al 31 agosto 2025, un anno prima, e l’attuale pagina di Google sui requisiti del livello API target riporta Android TV allo stesso API 34 insieme ad Android XR. Quindi per Android TV la data del 31 agosto 2026 non cambia nulla riguardo al livello richiesto. Leggere un unico livello API per tutta la tabella è l’errore più facile da fare qui, e dare per scontato che ogni tipo di dispositivo abbia ricevuto una nuova soglia nel 2026 è il secondo.
| Categoria di dispositivo | Target minimo | In vigore per i nuovi invii dal | Proroga |
|---|---|---|---|
| Telefoni e tablet, nuove app e aggiornamenti | Android 16, API 36+ | 31 agosto 2026 | Richiedibile fino al 1 novembre 2026 |
| Wear OS | Android 15, API 35+ | 31 agosto 2026 | Procedura attuale di Google per idoneità e proroga |
| Android Automotive OS | Android 15, API 35+ | 31 agosto 2026 | Procedura attuale di Google per idoneità e proroga |
| Android XR | Android 14, API 34+ | 31 agosto 2026 | Procedura attuale di Google per idoneità e proroga |
| Android TV | Android 14, API 34+ | 31 agosto 2025, già in vigore; riportata invariata al 31 agosto 2026 | Procedura attuale di Google per idoneità e proroga |
Fonti: Guida di Play Console, risposta 11926878 e Android Developers, requisiti del livello API target · verificate il 14 agosto 2026
Il legame pratico con il test chiuso è uno solo: la build che carichi per il test è pur sempre una build, e le stesse soglie di invio valgono anche per lei. La migrazione in sé, compreso ciò che alzare il target cambia e non cambia, è spiegata nell’articolo sul livello API target, e l’errore delle librerie native che coglie quasi tutti a metà migrazione è spiegato nell’articolo sulle pagine da 16 KB.
La data della norma sui contatti che è cambiata
Scadenza cambiata
28 ottobre 2026 27 gennaio 2027
L’attuale tabella delle scadenze delle norme di Google e la sua pagina della Guida sulle informazioni sensibili indicano entrambe il 27 gennaio 2027 come data di entrata in vigore della nuova norma sulle autorizzazioni per i contatti, annunciata il 15 aprile 2026. Il 28 ottobre 2026 compare in materiali più vecchi, comprese alcune note precedenti di questo stesso sito, e non è più la data valida. La norma riguarda l’accesso ampio ai contatti, con il selettore di contatti di Android come soluzione attesa dove l’accesso ampio non è necessario; dipende dal caso d’uso, quindi non va ridotta all’affermazione generica che un intero livello API non può usare i contatti.
Verificato Data verificata. L’ambito della norma in sé è classificato come parziale: Google la descrive per caso d’uso e non come un’unica regola legata al livello API.
Soglie di Android vitals che vale la pena conoscere
Le soglie complessive di comportamento anomalo di Google Play sono l’1,09% per il tasso di arresti anomali percepiti dagli utenti e lo 0,47% per il tasso di ANR percepiti dagli utenti, valutati sugli ultimi 28 giorni di dati. Sono soglie di qualità dell’app e di visibilità nello store. Non sono criteri pubblicati per decidere se a un nuovo sviluppatore venga concesso l’accesso in produzione dopo un test chiuso.
| Vital principale | Soglia complessiva | Per modello di telefono | Per modello di orologio |
|---|---|---|---|
| Tasso di arresti anomali percepiti dagli utenti | 1.09% | 8% | 4% |
| Tasso di ANR percepiti dagli utenti | 0.47% | 8% | 5% |
| Consumo eccessivo della batteria | 1% | Non indicata | 1% |
| Wake lock parziali eccessivi | 5% | Non indicata | Non indicata |
Fonte: Android Developers, Android vitals · verificata il 14 agosto 2026
Tienile separate dal requisito. Gli assistenti tirano fuori l’1,09% e lo 0,47% quando si chiede loro che cosa misuri Google durante il test chiuso, perché sono le percentuali più a portata di mano. Non sono quello. Governano come viene trattata un’app nello Store una volta che ha utenti, su una finestra mobile di 28 giorni. Niente nella documentazione di Google sull’accesso in produzione esaminata per questa pagina le lega alla decisione sul test chiuso.
Vale comunque la pena conoscerle durante un test, per un motivo pratico: un arresto anomalo che colpisce i tuoi dodici tester colpirà anche i tuoi primi mille utenti, e la domanda sulla preparazione nella richiesta di accesso in produzione chiede che cosa è cambiato grazie al test. Correggere quello che il test ha fatto emergere è la risposta a quella domanda.
Che cosa dicono i numeri di Google sull’ecosistema
Google dice di aver impedito la pubblicazione di oltre 1,75 milioni di app in violazione delle norme nel 2025 e di aver bloccato più di 80.000 account sviluppatore malevoli in quell’anno, contro 2,36 milioni di app e più di 158.000 account nel 2024. Google cita i requisiti di test tra le misure pensate per alzare l’asticella della qualità dell’ecosistema, ma non pubblica nessun effetto numerico isolato per la regola dei 12 tester in sé.
| Periodo | Dato | Che cosa sostiene legittimamente |
|---|---|---|
| 2023, strumenti di test | 3x in media | L’osservazione dichiarata da Google secondo cui le app che usavano i suoi strumenti di test registravano in media il triplo di installazioni e di coinvolgimento degli utenti rispetto a quelle che non li usavano. |
| 2024, app bloccate | 2,36 milioni | La portata delle azioni di Play prima della pubblicazione in quell’anno. |
| 2024, account bloccati | 158,000+ | Portata delle azioni a livello di account. |
| 2025, app bloccate | 1,75 milioni+ | Il dato annuale più recente trovato al 14 agosto 2026. |
| 2025, account bloccati | 80,000+ | Il dato annuale più recente trovato sulle azioni a livello di account. |
| 2025, accesso eccessivo ai dati | 255.000+ app | App a cui è stato impedito di ottenere un accesso eccessivo a dati sensibili degli utenti. |
| 2025, recensioni spam | 160 milioni | Valutazioni e recensioni spam bloccate. Contesto più ampio sulla qualità. |
| Descrizione attuale di Play | 10.000+ controlli di sicurezza | Controlli che Google dice di eseguire su ogni app che offre. |
Fonti: report di sicurezza 2025 di Google e report 2024 · verificati il 14 agosto 2026
Non trasformarli in un tasso di rifiuto
1,75 milioni e 2,36 milioni sono conteggi di app in violazione delle norme fermate dai sistemi di sicurezza di Google su tutto lo store. Non hanno un denominatore, non riguardano nello specifico il test chiuso e nessun calcolo su di essi produce una percentuale di rifiuto di Google Play. Allo stesso modo, il calo anno su anno da 2,36 milioni a 1,75 milioni non prova che ottenere l’approvazione sia diventato più facile: Google li riporta insieme a modifiche ai requisiti di verifica, revisione e test, senza isolare che cosa abbia causato che cosa.
La statistica del 3x, e che cosa non è
Il numero più citabile che Google ha pubblicato in questo ambito è quello legato al suo annuncio del 9 novembre 2023: le app che usavano gli strumenti di test di Google Play registravano in media il triplo di installazioni e di coinvolgimento degli utenti rispetto a quelle che non li usavano. È un dato Google reale, e viene usato male di continuo.
3x è una correlazione, ed è precedente alla regola
Google ha segnalato un’associazione tra l’uso dei suoi strumenti di test e un numero maggiore di installazioni e di coinvolgimento. Non ha affermato che gli strumenti fossero la causa di quella differenza, e la statistica è stata pubblicata insieme all’annuncio originale dei 20 tester, non come misura di esso. Qualsiasi frase del tipo «il test chiuso rende la tua app 3 volte più di successo», o peggio «la regola dei 12 tester produce una crescita di 3 volte», fa due cose che la fonte non sostiene: trasforma una correlazione in una causa e attribuisce un’osservazione del 2023 su strumenti di test facoltativi a un requisito obbligatorio la cui forma attuale non esisteva prima di dicembre 2024.
Il riassunto onesto della posizione di Google è circoscritto e vale la pena citarlo con precisione: Google dice che la verifica degli sviluppatori, i controlli obbligatori prima della revisione e i requisiti di test hanno alzato nel loro insieme l’asticella per entrare nell’ecosistema. Mette il requisito del test chiuso insieme ad altre tutele. Non ha pubblicato un impatto numerico a sé stante per la regola dei 12 tester, e questo articolo non se lo inventa.
In sintesi
Riepilogo
Al 14 agosto 2026, Google Play impone agli account sviluppatore personali creati dopo il 13 novembre 2023 di svolgere un test chiuso con almeno 12 tester attivati per almeno gli ultimi 14 giorni continuamente prima di richiedere l’accesso in produzione. Quella soglia conta lo stato di attivazione continua; il coinvolgimento dei tester viene valutato a parte nella richiesta, e Google dice che un coinvolgimento insufficiente può portare a una richiesta di altri test. 20 è un dato storico, sostituito l’11 dicembre 2024. Il test interno ha un limite di 100 tester e non soddisfa il requisito; i 1.000 del test aperto sono una soglia minima di configurazione, non un obiettivo di reclutamento. Il giorno 14 apre una richiesta in 3 sezioni, e Google dice che quella revisione richiede di solito 7 giorni o meno. Nessun tasso di approvazione del test chiuso è stato trovato nelle fonti Google primarie esaminate per questa pagina, quindi qualsiasi percentuale presentata come statistica di Google dovrebbe arrivare con una citazione Google primaria allegata. Reclutamento dei tester, coordinamento e lavoro di QA si possono affidare all’esterno; la decisione di Google sull’accesso in produzione no, né da parte nostra né di nessun altro. Guarda i piani e i prezzi →
Fonti primarie
Quattordici fonti primarie. Ogni dato di questa pagina viene da una di esse, e ogni tabella principale riporta sotto di sé la fonte specifica. Dove un’affermazione si basa su segnalazioni della Developer Help Community e non su una dichiarazione di Google, la pagina la classifica come segnalata anziché verificata.
Che cosa scade per primo in questa pagina
- Le date del livello API target. Il 31 agosto 2026 e il termine della proroga al 1 novembre 2026 sono le scadenze più vicine qui. La pagina cambia il proprio tempo verbale su entrambe, ma conviene rileggere le soglie di riferimento sulla pagina dei requisiti di Google prima di pianificare una pubblicazione basandosi su di esse.
- La data della norma sui contatti. Google l’ha già spostata una volta, dal 28 ottobre 2026 al 27 gennaio 2027. Trattala come la data più probabile di questa pagina a spostarsi di nuovo.
- I limiti dei canali. Limiti di prodotto come 100, 2.000, 50 e 200 possono cambiare senza un annuncio di modifica delle norme, di solito insieme a una riprogettazione di Play Console. Vale la pena controllarli ogni trimestre.
- I dati di sicurezza 2025. Sono annuali. Diventano obsoleti nel momento in cui Google pubblica il report successivo sull’ecosistema, e con loro se ne va la riga di confronto del 2024.
- La quota di registrazione. I 25 US$ sono un numero commerciale e possono cambiare in qualsiasi momento senza preavviso.
- Le assenze. Se Google dovesse pubblicare un tasso di approvazione del test chiuso o un conteggio esatto delle app, la sezione sui numeri che Google non pubblica diventerebbe sbagliata e non solo incompleta. È questo il tipo di errore da tenere d’occhio.
Ogni statistica è stata verificata su una fonte Google primaria il 14 agosto 2026. Revisione mensile, e subito dopo ogni annuncio di modifica delle norme di Play Console.