Risposta rapida
Google Play applica a un gioco Android lo stesso prerequisito di test chiuso (closed testing) per l’accesso in produzione che applica a qualunque altra app. Se il gioco viene pubblicato da un account sviluppatore personale creato dopo il 13 novembre 2023, almeno 12 tester devono essere attivati su un test chiuso per almeno gli ultimi 14 giorni continuamente prima che tu possa richiedere l’accesso in produzione. In origine Google richiedeva 20 tester e ha ridotto il minimo a 12 l’11 dicembre 2024; nella sua documentazione attuale non compare nessun conteggio di tester, nessuna durata e nessuna esenzione separata per i giochi. Raggiungere il numero non è l’approvazione, perché Google chiede anche come si sono impegnati i tester, quali feedback hanno dato e che cosa hai cambiato, e può richiedere altri test. I giochi si portano poi dietro rischi di pubblicazione che quel contatore non misura mai: consegna degli asset, tempo di frame, codice nativo a 64 bit, test degli acquisti in-app e autorizzazione di Play Games Services. Se la parte che non riesci a coprire è quella dei tester, PrimeTestLab la gestisce con tester reali su dispositivi reali.
Attivo in questo momento anche per chi pubblica giochi
Il 31 agosto 2026 è passato: i giochi mobile nuovi e aggiornati devono avere come target Android 16 (livello API 36) o successivo, e la Play Billing Library 7 ha superato la scadenza per le nuove app e per gli aggiornamenti. Gli invii per Wear OS e Android Automotive OS richiedono l’API 35, mentre Android TV e Android XR richiedono l’API 34. Se hai una proroga, vale fino al 1° novembre 2026. Nessuna delle due cose fa parte del requisito sui tester, ed entrambe possono bloccare proprio il rilascio che il requisito sui tester dovrebbe sbloccare.
La maggior parte delle guide esistenti risponde a metà del problema. Le pagine generiche sul test chiuso spiegano il requisito dei 12 tester senza toccare i rischi di pubblicazione specifici di un gioco, mentre le pagine di QA per i giochi parlano di prestazioni e di device lab senza spiegare la barriera dell’accesso in produzione che è ciò che sta davvero bloccando il lancio. I thread della community riempiono lo spazio tra le due cose con folklore raccontato con sicurezza: giocare una volta al giorno, pubblicare tre aggiornamenti, trenta minuti a sessione, un numero minimo di livelli. Nessuna di queste è una regola pubblicata da Google, e questo articolo lo dice ogni volta che una di esse salta fuori. Tutto ciò che leggi qui è aggiornato al 12 agosto 2026, con le date di scadenza delle norme riverificate il 14 agosto 2026, ed è tutto tracciato fino alla documentazione primaria di Google; dove la risposta onesta è «Google non lo pubblica», la pagina scrive quello invece di un numero.
L’ordine qui sotto segue il modo in cui il problema si risolve davvero. Prima la barriera in sé, perché non puoi pianificare niente finché non sai se ti riguarda e che cosa conta esattamente. Poi lo strato che riguarda i giochi: che cosa si lascia sfuggire un test che accumula soltanto account attivati, e come mettere alla prova ciascuno di quei rischi prima che i revisori di Google ne vedano il risultato.
Il banco di prova
Tre strumenti costruiti per le tre domande a cui uno sviluppatore di giochi non può rispondere con la sola documentazione di Google. Ognuno gira interamente nel tuo browser, sui valori che digiti tu. Non viene caricato nulla e non serve nessun account.
Indice
Google Play richiede il test chiuso per i giochi Android?
Sì, alle stesse condizioni di qualunque altra app. Se il gioco viene pubblicato da un account sviluppatore personale creato dopo il 13 novembre 2023, devi eseguire un test chiuso con almeno 12 tester attivati negli ultimi 14 giorni continuamente prima di poter richiedere l’accesso in produzione. Google non pubblica nessun conteggio di tester separato, nessuna durata più breve e nessuna esenzione per i giochi.
«Se hai creato di recente un account sviluppatore personale, 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 Play Console, risposta 14151465
Leggi quella frase per quello che non dice. Non nomina le categorie di app. L’innesco è legato all’account, non a quello che carichi, quindi il fatto che il tuo bundle sia classificato come gioco non cambia niente sul fatto che la barriera si applichi. I materiali di Google sul test chiuso parlano di app e di giochi dentro lo stesso processo di accesso in produzione, e citano esplicitamente il test pre-lancio per i giochi mobile come uno degli usi dei canali di test.
Rileggila ancora una volta per l’espressione la tua app. La data di creazione dell’account decide se il requisito ti riguarda, ma il test valido e la richiesta di accesso in produzione si completano per una singola app. Superare il processo per un gioco non si trasferisce al pacchetto successivo che pubblichi dallo stesso account: un secondo gioco ha il suo test chiuso, i suoi 12 tester e le sue due settimane. Questa conclusione si appoggia sul fatto che Google scrive la condizione su «la tua app» e che l’accesso in produzione si richiede per singolo pacchetto, non su una frase pubblicata che escluda il riporto; metti in conto un test nuovo per ogni gioco e controlla la dashboard della Console per l’app specifica prima di dare per scontata una cosa o l’altra.
Risultato negativo «Non esiste un’esenzione per i giochi» è una conclusione tratta dalla sua assenza nella documentazione attuale di Google, non una frase che Google pubblica. È una distinzione significativa e questo articolo la mantiene: in tutto il materiale attuale sull’accesso in produzione non è stato trovato nessun conteggio di tester alternativo né alcuna durata alternativa per i giochi, quindi la lettura prudente è che gli account personali interessati usino lo stesso prerequisito, qualunque cosa pubblichino.
Che cosa conta davvero la regola
12
Tester, minimoAccount individuali che hanno completato l’attivazione. Non le persone a cui hai scritto, non le persone che ti hanno detto di sì.
14
Giorni continuativiOgnuno di quegli 12 account deve essere stato attivato per tutti gli ultimi 14 giorni nel momento in cui fai richiesta.
1
Ambito account, test per appÈ l’account a decidere se la regola si applica. Il test valido, invece, si esegue per singola app.
Se hai letto che il numero è 20, quella pagina non è aggiornata. In origine Google aveva fissato la soglia a 20 tester e l’ha ridotta a 12 l’11 dicembre 2024, descrivendo il cambiamento con parole sue come la richiesta di «12 tester invece di 20» e lasciando intatto il periodo di due settimane. La storia è raccontata in dettaglio nel post sul passaggio da 20 a 12 tester, e i meccanismi del requisito nel post sul requisito dei 12 tester. Questo articolo dà per acquisite entrambe le cose e resta su ciò che è diverso in un gioco.
Quali sviluppatori di giochi hanno davvero bisogno di 12 tester?
Il prerequisito riguarda soltanto gli account sviluppatore personali creati dopo il 13 novembre 2023. Gli account dell’organizzazione e gli account personali più vecchi restano fuori da questo requisito specifico. Caricare un gioco invece di un’app non ti ci fa rientrare né ti ci fa uscire, e fare un test interno con un massimo di 100 persone non lo soddisfa.
| La tua situazione | 12 tester, 14 giorni? | La spiegazione sicura |
|---|---|---|
| Account personale creato dopo il 13 nov 2023 | Sì | Esegui un test chiuso con almeno 12 tester attivati continuamente negli ultimi 14 giorni, poi richiedi l’accesso in produzione. |
| Account personale creato prima di quella data limite | Non per questa regola | Google limita il requisito agli account personali creati dopo il 13 novembre 2023. |
| Account dell’organizzazione | Non per questa regola | Il requisito è scritto espressamente per gli account personali interessati. Non è la stessa cosa che essere esenti dai test, dagli standard di qualità o dalla revisione delle norme. |
| Un gioco invece di un’app qualsiasi | Nessun caso speciale | Nella documentazione attuale di Google sull’accesso in produzione non compare nessun numero di tester né nessuna durata alternativi per i giochi. |
| Hai già fatto un test interno con 100 persone | Serve comunque | Il test interno e il test chiuso sono canali separati. Il prerequisito richiede espressamente un test chiuso. |
| Hai già soddisfatto il requisito per un altro gioco sullo stesso account | Serve comunque | Google scrive il requisito come un test chiuso «per la tua app». È l’account a decidere se la regola si applica; il test che qualifica va completato per ogni nome pacchetto. |
«Gli account dell’organizzazione sono esenti» è la frase sbagliata
Un account dell’organizzazione resta fuori da questo specifico prerequisito per i nuovi account personali. Deve però rispettare ogni obbligo normale: revisione, norme sui contenuti, standard di qualità, dichiarazioni e regole di distribuzione. Registrarsi come organizzazione per aggirare un requisito sui tester significa anche assumersi la verifica dell’organizzazione, e il tipo di account che scegli ha conseguenze che vanno ben oltre questo singolo passaggio. I compromessi sono spiegati nell’articolo sull’account personale rispetto a quello dell’organizzazione.
Un elemento di contesto generale sull’account, perché salta fuori nello stesso discorso e viene spesso confuso con il costo dei test: Google applica una quota di registrazione una tantum di 25 $ per aprire un account sviluppatore. Quella quota non ha nulla a che vedere con il requisito di test. Eseguire un test chiuso non costa nulla in Play Console; quello che costa è trovare dodici persone che restino.
Ed è questo il vero problema per un gioco. Rispetto a un’app di utilità, un gioco di solito ha bisogno di sessioni più profonde prima che i suoi difetti vengano a galla: progressione e salvataggi, consegna degli asset, comportamento termico e monetizzazione si comportano male soltanto quando qualcuno ha giocato abbastanza a lungo da avere qualcosa da perdere. Nessuna delle due categorie viene testata in modo affidabile da persone che installano una build e la lasciano lì per due settimane, e Google valuta il coinvolgimento e i feedback tanto per le app quanto per i giochi. Un gioco rende soltanto più costosa la versione superficiale di quell’errore, perché ti servono persone che giochino davvero, su hardware simile a quello di un giocatore, abbastanza a lungo da arrivare al secondo atto. È di questo divario che parla il resto dell’articolo.
Come funziona il test chiuso di 14 giorni per un gioco?
Pubblica un rilascio sul canale chiuso, porta almeno 12 tester a completare l’attivazione e mantienili attivati mentre giocano davvero. Quando fai richiesta, almeno 12 di loro devono essere stati attivati ciascuno per gli ultimi 14 giorni continuamente. Poi richiedi l’accesso in produzione dalla dashboard di Play Console. Il test interno supporta fino a 100 tester ed è utile, ma non soddisfa questo passaggio.
Fonte: il requisito del test chiuso per i nuovi account personali (risposta 14151465). Il minimo di 12 tester ha sostituito 20 l’11 dicembre 2024; il periodo continuativo di 14 giorni non è cambiato.
-
01
Prima del giorno uno
Pubblica il rilascio del test chiuso e rendilo disponibile ai tuoi tester. Verifica che la build consegnata da Play si installi e funzioni, che i pacchetti di asset arrivino, che l’accesso a Play Games funzioni e che tutto ciò che il test deve raggiungere sia raggiungibile. Una build che funziona dalla tua macchina non dice nulla sulla build che assembla Play.
-
02
Attivazione
Ogni tester deve accettare l’invito, non limitarsi a comparire in un elenco. È un inciampo continuo: aggiungere qualcuno a una mailing list o a un Google Group è un’azione tua, l’attivazione è la sua. Conta solo gli account che l’hanno completata.
-
03
Dal giorno uno al giorno quattordici
Almeno 12 tester restano attivati continuamente mentre giocano. Recluta sopra il minimo, così una singola disattivazione non ti lascia scoperto. Quando fai richiesta Google chiede del coinvolgimento e dei feedback, quindi il risultato utile di queste due settimane è un elenco di cose che le persone ti hanno detto, non lo screenshot di un contatore.
-
04
Durante il test
Correggi i difetti reali e continua ad aggiornare la build. Caricare nuovi rilasci durante la finestra è normale e non fa ripartire nulla: la condizione da soddisfare è scritta sulla storia di attivazione dei tester, non sull’età di una build congelata. Discende dalla formulazione di Google sull’attivazione continua per singolo tester; Google non pubblica una regola separata sugli aggiornamenti della build, né in un senso né nell’altro. Metti alla prova i percorsi di installazione e aggiornamento, i progressi e i salvataggi, i download degli asset, gli arresti anomali, le prestazioni, gli acquisti e Play Games così come li usa il tuo gioco.
-
05
Dopo la finestra di qualificazione
Vai su Dashboard > Apply for production e rispondi onestamente su chi ha testato, come si è impegnato, che cosa ha detto, che cosa hai cambiato e perché il gioco è pronto.
-
06
Revisione
Google dice che di solito richiede 7 giorni o meno e che a volte può volerci di più. Non è un accordo sul livello di servizio e nessuno può prometterti una data.
Una correzione da fare subito, perché costa due settimane a chi la ignora. Il test interno è un canale diverso con un tetto molto più alto: fino a 100 tester, disponibile in fretta. È davvero utile per mettere in fretta una build in mano alle persone. Non sostituisce il test chiuso che il prerequisito indica. Le differenze tra i tre canali sono trattate nel post su test interno, chiuso e aperto, e il test aperto diventa disponibile solo una volta ottenuto l’accesso in produzione.
I tester devono giocare tutti i giorni?
È qui che sbaglia quasi ogni risposta della community, quindi ecco le tre categorie tenute separate.
Obbligatorio, e pubblicato
- Almeno 12 tester attivati.
- Attivati per gli ultimi 14 giorni continuamente.
- Un test chiuso nello specifico, non interno.
- Risposte oneste nella richiesta di accesso in produzione.
Buona pratica, non una regola
- Tester che arrivano davvero al ciclo di gioco principale, non alla schermata del titolo.
- Sessioni abbastanza lunghe da far emergere il calore e la pressione sulla memoria.
- Feedback scritti che puoi citare quando fai richiesta.
- Correzioni pubblicate durante la finestra, quando i feedback le giustificano.
Non è una regola pubblicata
- Aprire il gioco una volta al giorno.
- Un numero minimo di minuti per sessione.
- Un numero obbligatorio di build durante il test.
- Un numero minimo di livelli, schermate o meccaniche.
Google richiede l’attivazione continua e dice che il coinvolgimento conta quando esamina la tua richiesta. Non pubblica una quota di aperture giornaliere, una cifra di minuti per sessione o un numero di aggiornamenti. Prendi la colonna di destra per quello che è: consigli induriti in folklore perché ripetuti con sicurezza. Punta al test vero e soddisfi la colonna centrale senza aver bisogno della terza.
Se un tester si disattiva, le due settimane ripartono?
Non di per sé, ed è la regola più esagerata in circolazione. La condizione di Google si misura nel momento in cui fai richiesta: almeno 12 tester, ciascuno dei quali attivato per i 14 giorni precedenti continuamente. Non è un requisito che un unico gruppo intatto di esattamente dodici persone sopravviva immutato alle due settimane.
Quindi l’aritmetica funziona per singolo tester, non per gruppo. Parti con esattamente 12 e ne perdi uno il nono giorno: sei scoperto, perché ora hai undici account in grado di mostrare la finestra completa, e il dodicesimo, quello sostitutivo, deve completare i suoi 14 giorni continuativi prima che tu possa fare richiesta. Parti con quindici e ne perdi uno, e i quattordici rimasti possono ancora soddisfare ciascuno la condizione, quindi non hai perso nulla se non un margine. È tutto qui l’argomento per reclutare sopra il minimo invece che esattamente al minimo.
Come lo sappiamo Questa lettura discende dalla formulazione di Google sull’attivazione continua per singolo tester, che è ciò su cui il requisito è scritto. Google non pubblica una regola separata sul ripristino del gruppo che dica, in questi termini, che l’uscita di un tester preserva il periodo di tutti gli altri: trattala quindi come una lettura attenta della condizione pubblicata, non come una frase da citare a un revisore. Il consiglio pratico non cambia in nessuno dei due casi: recluta sopra 12, così alla domanda non dovrai mai rispondere.
Che cosa succede dopo il giorno 14?
Fai richiesta e Google legge le risposte. La richiesta di accesso in produzione chiede come i tester si sono impegnati con il gioco, quali feedback hanno dato, che cosa hai cambiato di conseguenza e perché lo consideri pronto. Per un gioco c’è anche una richiesta specifica di categoria: descrivere che cosa lo rende diverso dagli altri. Nemmeno quella domanda è una formalità: è lì che un gioco funzionalmente a posto ma che non ha niente da dire su di sé inizia a sembrare un gioco che nessuno ha testato sul serio.
Scrivi le risposte durante il test, non dopo
Le domande riguardano cose successe nell’arco di quattordici giorni. Se aspetti il quindicesimo giorno per pensarci, le ricostruirai a memoria, e si vede. Tieni una nota aggiornata di quello che i tester hanno segnalato e di quello che hai pubblicato in risposta; la richiesta ti prende poi venti minuti e dice qualcosa di vero. C’è una guida completa al questionario nel post sulle risposte al questionario per l’accesso in produzione.
Cosa non vede di un gioco un test pensato per un’app qualsiasi?
Un test costruito attorno a «installalo e lascialo attivato» misura il contatore e nient’altro. I giochi tengono CPU e GPU sotto carico prolungato, spediscono grandi payload di asset attraverso un sistema di distribuzione con modalità di guasto proprie, di solito contengono binari nativi, conservano lo stato della progressione tra una sessione e l’altra e spesso incassano denaro. Ognuno di questi è un punto in cui una build passa sulla tua scrivania e fallisce sul telefono di un giocatore.
Nessuno di questi rischi è esclusivo dei giochi, e questo articolo non sostiene il contrario: moltissime app comuni contengono librerie native, vendono abbonamenti o distribuiscono asset di grandi dimensioni. Ciò che è caratteristico è la concentrazione. Un gioco di solito incontra quasi tutta questa lista in una volta sola, nella stessa build, nelle stesse due settimane: ecco perché una checklist scritta per un’app qualsiasi lascia gran parte di un gioco senza test.
Qui sotto trovi la mappa del resto dell’articolo. La colonna di destra è la parte che si sbaglia in entrambe le direzioni: alcune voci sono requisiti di Google con conseguenze reali, altre sono normale pratica di qualità che nessuna norma cita. Trattare una pratica come una regola ti fa sprecare le due settimane; trattare una regola come una pratica ti costa la pubblicazione.
| Area di rischio | Perché un gioco è diverso | Stato |
|---|---|---|
| Consegna degli asset e dimensioni | Payload di grandi dimensioni suddivisi tra pacchetti install-time, fast-follow e on-demand, ognuno con limiti propri e un proprio modo di arrivare in ritardo o di non arrivare affatto. | Limiti di Google |
| Tempo di frame e calore | Il carico di rendering prolungato scalda il dispositivo, il sistema riduce le prestazioni e i tempi dei frame si allungano al sesto minuto di una sessione che al primo sembrava a posto. | Metrica di vitals |
| Codice nativo e 64 bit | Motori e plugin contengono binari compilati. Una copertura a 64 bit mancante o un’ABI sbagliata mette fuori gioco intere famiglie di dispositivi, non una singola funzionalità. | Requisito di Google |
| Acquisti in-app | Far parte di un canale di test non rende gratuiti gli acquisti, e un acquisto di prova non confermato sparisce dopo tre minuti. | Meccanismo di Google |
| Play Games Services | Un secondo livello di autorizzazione con un proprio elenco di tester, che fallisce con errori OAuth e 404 quando non è configurato. | Requisito di Google |
| Norme su monetizzazione e contenuti | La comunicazione delle probabilità sugli elementi randomizzati, le meccaniche con denaro reale e l’accuratezza del questionario di classificazione sono un’esposizione normativa tipica dei giochi, che una comune app di utilità non incontra mai. | Norme di Google |
| Progressione e salvataggi | Uscita, ripresa, reinstallazione e cambio di dispositivo devono tutti conservare i progressi, e un bug di salvataggio resta invisibile finché qualcuno non gioca abbastanza a lungo da avere qualcosa da perdere. | Pratica di QA |
| Profondità della sessione | I guasti che contano stanno oltre il tutorial. Un tester che apre il gioco una volta sola non produce alcuna prova su nessuna delle righe qui sopra. | Pratica di QA |
Nota che cosa non c’è in quella tabella: un numero di dispositivi richiesto, una durata di sessione richiesta, un frame rate richiesto o un numero minimo di livelli. Sono cose che si affermano di continuo e nessuna di esse è pubblicata. Ciò che Google pubblica davvero sono limiti, soglie, meccanismi e norme, e ognuno di questi è verificabile nelle stesse due settimane che stai già dedicando al contatore.
Quanto può essere grande il tuo gioco su Google Play?
Al 12 agosto 2026, la Guida di Play Console indica 500 MB per il modulo di base, 500 MB per modulo di funzionalità, 1,5 GB per pacchetto di asset, 4 GB per tutti i moduli più i pacchetti di asset install-time, 30 GB per i pacchetti fast-follow e on-demand e un massimo complessivo di 34 GB. Ognuno di questi valori è una dimensione di download compressa calcolata da Play Console, non la dimensione del file .aab che hai sul disco.
È il dato che ha più probabilità di essere sbagliato in qualunque cosa tu abbia letto prima di arrivare qui. La cifra di 200 MB che continua a circolare era il limite di base anni fa, e alcune delle pagine più vecchie di Google sui giochi Android non si sono allineate alla pagina della Guida di Play Console che governa i caricamenti reali. Quando due pagine di Google non concordano, la pagina dedicata ai limiti di dimensione nella Guida di Play Console è quella specifica e aggiornata su ciò che la Console accetta. Controllala di nuovo prima di pianificare una pubblicazione attorno a uno qualsiasi dei numeri qui sotto.
Strumento 01
Misuratore del budget di build
Inserisci le tue dimensioni di download compresse in megabyte. Tutto gira in questa pagina; non viene caricato nulla. Questo calcolatore usa 1 GB = 1024 MB.
Limiti verificati sulla Guida di Play Console il 12 agosto 2026. Google li calcola sulla dimensione di download compressa che ricava dal tuo bundle, quindi la dimensione del file che hai in locale è solo un’approssimazione di ciò che verrà misurato. Fonti: limiti massimi di dimensione delle app (risposta 9859372) e Play Asset Delivery.
La tabella completa dei limiti
| Componente | Limite attuale | A che cosa si applica |
|---|---|---|
| Modulo di base | 500 MB | Il modulo di base del bundle da solo. |
| Modulo di funzionalità | 500 MB | Ogni singolo modulo di funzionalità, misurato separatamente. |
| Pacchetto di asset | 1,5 GB | Ogni singolo pacchetto di asset, misurato separatamente. |
| Moduli più pacchetti install-time | 4 GB | Totale cumulativo di tutto ciò che viene consegnato durante l’installazione. |
| Pacchetti fast-follow più on-demand | 30 GB | Totale cumulativo di tutto ciò che viene consegnato dopo l’installazione. |
| Download totale | 34 GB | Dimensione di download compressa massima complessiva. |
| Pacchetti di asset per bundle | 100 | Numero massimo di pacchetti di asset in un singolo app bundle. |
| App oltre 1 GB | minSdk 21 | Tutto ciò che supera 1 GB deve avere come target almeno Android 5.0 Lollipop. |
| Avviso su rete mobile | 200 MB | Oltre questa soglia, le installazioni su rete mobile mostrano una finestra non bloccante sulle dimensioni elevate. |
| APK legacy | 100 MB | Massimo per un singolo APK con la pubblicazione APK legacy. |
Limiti di dimensione di Google Play verificati il 12 agosto 2026. Tutti i valori sono dimensioni di download compresse calcolate da Play Console. Fonti: limiti massimi di dimensione delle app (risposta 9859372) e Play Asset Delivery.
Quale modalità di Play Asset Delivery deve testare il tuo gioco?
Play Asset Delivery ha tre modalità, e ciascuna si rompe in un punto diverso. La modalità che hai scelto nella build determina quali casi di test contano davvero, quindi scorri questa tabella e testa solo le righe che il tuo gioco usa realmente.
| Modalità | Quando arriva | Pronto al lancio? | Nella dimensione indicata nello Store? | Il caso di test che trova i bug |
|---|---|---|---|---|
| Install-time | Consegnato durante l’installazione sotto forma di split APK. | Sì | Sì | Il primo avvio, il percorso di aggiornamento e l’installazione con il dispositivo quasi senza spazio di archiviazione. |
| Fast-follow | Si scarica automaticamente subito dopo l’installazione, senza bloccare l’ingresso nel gioco. | Non necessariamente | No | Un giocatore che apre il gioco prima che il pacchetto sia arrivato, e il recupero da un download interrotto. |
| On-demand | Si scarica mentre il gioco è in esecuzione, quando lo richiede il tuo codice. | Solo dopo la richiesta | No | L’ingresso nel livello o nella funzionalità prima che il suo pacchetto sia disponibile, più i tentativi ripetuti e le interruzioni. |
Non dare per scontato che i pacchetti restino dove li hai lasciati
Google avverte che i file di archivio fast-follow e on-demand possono essere eliminati dall’utente o spostati dalla libreria di Play Asset Delivery tra una sessione e l’altra, quindi un gioco non deve dare per scontato che un pacchetto presente ieri si trovi ancora nello stesso posto oggi. Testa il secondo e il terzo avvio, non solo il primo, e verifica che cosa succede quando un aggiornamento invalida un pacchetto. Il targeting per formato di compressione delle texture aggiunge un’altra dimensione: Play può consegnare asset di texture diversi a seconda di ciò che il dispositivo supporta, quindi gli asset che riceve il tuo dispositivo di test possono non essere quelli che riceve un altro dispositivo.
Il test in locale della consegna degli asset non riproduce esattamente la consegna di Play. Google documenta che in un test locale un pacchetto fast-follow si comporta come un pacchetto on-demand e che certi comportamenti di rete e di attesa del Wi-Fi non sono affatto riproducibili in locale. È questo l’argomento a favore del testare la build che Play consegna davvero a un tester del canale chiuso, invece della build prodotta dal tuo editor, ed è uno dei pochi punti in cui il test chiuso fa davvero lavoro di QA anziché soddisfare un contatore.
Quali numeri su frame rate e arresti anomali pubblica davvero Google?
Android vitals pubblica una soglia del tasso di arresti anomali percepiti dagli utenti dell’1,09% complessivo e dell’8% per modello di telefono, e un tasso di ANR percepiti dagli utenti dello 0,47% complessivo e dell’8% per modello di telefono. Per i giochi in particolare definisce una sessione lenta come una sessione in cui più del 25% dei frame è lento, misurata rispetto a 50 ms (20 FPS) come metrica principale e a 34 ms (circa 30 FPS) come metrica secondaria. Nessuno di questi numeri è una soglia pubblicata di approvazione del test chiuso.
La distinzione conta perché viene persa di continuo. Le soglie di vitals descrivono la qualità tecnica, e Google ha dichiarato che col tempo Play allontanerà gli utenti dai giochi che non riescono a raggiungere i 20 FPS sul loro telefono. È un meccanismo di visibilità e qualità. Non è la revisione per l’accesso in produzione, e nessuna fonte di Google trasforma un frame rate in un voto di sufficienza per il test di 14 giorni. Le due cose possono essere vere insieme: il tuo gioco può superare il requisito dei tester e restare comunque un gioco che Play smetterà silenziosamente di consigliare.
Strumento 02
Laboratorio sessioni lente
Quaranta frame di una singola sessione di gioco. Sposta il cursore per indicare quanti di essi sono stati renderizzati lentamente e il laboratorio applica al risultato la definizione di Google.
Android vitals inizia a monitorare il frame rate di un gioco solo dopo che il gioco è rimasto in esecuzione per 1 minuto, ed è anche il motivo per cui un tester che apre il gioco e lo chiude non produce alcun segnale utile sulle prestazioni. Un minuto è il punto di inizio della misurazione, non la durata richiesta di una sessione di gioco reale. Fonte: Sessioni lente in Android vitals.
I numeri, e ciò che ciascuno di essi non è
| Metrica | Valore di Google | Cosa significa | Cosa non significa |
|---|---|---|---|
| Tasso di arresti anomali percepiti dagli utenti | 1.09% | Soglia di qualità tecnica di Android vitals, misurata complessivamente. | Non è una soglia del test chiuso di alcun tipo. |
| Tasso di arresti anomali per modello di telefono | 8% | La soglia di vitals specifica per dispositivo. | Non è il permesso di tollerare l’8% di arresti anomali nel tuo controllo qualità. |
| Tasso di ANR percepiti dagli utenti | 0.47% | Soglia di qualità tecnica di Android vitals, misurata complessivamente. | Non fa parte della formula per l’accesso in produzione. |
| Tasso di ANR per modello di telefono | 8% | La soglia di vitals specifica per dispositivo. | Non è un obiettivo verso cui progettare. |
| Sessione lenta | >25% di frame lenti | La definizione di qualità dei frame valida solo per i giochi. | Non è una misura del coinvolgimento dei tester. |
| Frame lento, principale | 50 ms, 20 FPS | Il riferimento temporale principale delle sessioni lente. | Non è un FPS minimo pubblicato per l’accesso in produzione. |
| Frame lento, secondario | 34 ms, circa 30 FPS | Una metrica aggiuntiva delle sessioni lente che vitals riporta. | Non è la prova che Google richieda a ogni gioco di girare a 30 FPS. |
| Inizio del monitoraggio | Dopo 1 minuto | La raccolta del frame rate inizia dopo un minuto di esecuzione del gioco. | Non è la durata richiesta da Google per una sessione di gioco reale. |
Il bug che compare solo al sesto minuto
Google elenca il surriscaldamento e il throttling termico tra le cause documentate dei frame lenti: un carico prolungato di CPU e GPU scalda il dispositivo, il sistema riduce le prestazioni e i tempi dei frame si allungano. Questa modalità di guasto è invisibile in uno smoke test di due minuti ed è lampante in una sessione di venti minuti su un telefono caldo. È anche l’esempio più chiaro del perché un gioco abbia bisogno di tester che giocano davvero e non di tester che si limitano a installare. Se stai facendo profiling, l’Android Dynamic Performance Framework (ADPF) espone i segnali di gestione termica, della CPU e della GPU proprio per questo scopo, così il gioco può adattarsi prima che il throttling diventi grave.
Librerie native e 64 bit
I giochi realizzati con Unity, Unreal, Cocos o con qualunque motore dotato di plugin nativi contengono binari compilati, e quei binari hanno regole di compatibilità proprie, indipendenti da tutto ciò che c’è in questo articolo. Google Play richiede che le app supportino le architetture a 64 bit: quando è supportata un’architettura nativa a 32 bit, deve essere inclusa anche la corrispondente architettura a 64 bit. Fai i test in un ambiente a 64 bit e considera ogni plugin di terze parti capace di portarsi dietro un proprio binario incompatibile, a prescindere da ciò che dichiara la versione del tuo motore.
Se durante questo lavoro la tua build fa scattare anche l’avviso sulla dimensione delle pagine di memoria da 16 KB, si tratta di un requisito a parte, con una scadenza propria e un proprio percorso di risoluzione, trattato nell’articolo su come correggere l’errore della dimensione di pagina da 16 KB.
Non è una regola pubblicata Google non pubblica alcun numero di dispositivi, versioni di Android o famiglie di GPU su cui un gioco debba essere testato per ottenere l’accesso in produzione. Chi cita «cinque telefoni e tre versioni di Android» sta citando una preferenza, non una norma. Copri la gamma che il tuo gioco supporta davvero, pesata in base all’hardware che il tuo pubblico ha probabilmente in mano, e ricorda che gli emulatori non ti dicono nulla di utile sul comportamento termico.
Come si testano gli acquisti in-app senza addebitare nulla ai tester?
Aggiungi ogni account che farà un acquisto di test in Settings > License testing in Play Console. Essere sul tuo canale chiuso non rende gli acquisti gratuiti. Un tester normale che tocca Acquista nel tuo gioco non ancora pubblicato può vedersi addebitare soldi veri, e l’unica cosa che lo cambia è lo stato di license tester sull’account che effettua l’acquisto.
«Gli utenti sostengono addebiti reali ... a meno che l’utente non sia un license tester.»
Google Play Billing, documentazione sul test della fatturazione in-app
Due elenchi separati controllano due cose separate. L’elenco dei tester del canale chiuso controlla chi può installare la build non pubblicata. L’elenco dei license tester controlla quali acquisti passano dai metodi di pagamento di test di Google invece che da una carta vera. Uno sviluppatore che aggiunge dodici persone al primo elenco e nessuna al secondo ha costruito un test in cui ogni acquisto è reale, e di solito il primo a scoprirlo è un tester che chiede il rimborso.
Strumento 03
Verifica addebiti ai tester
Rispondi per il dispositivo e per l’account specifici che stanno per fare l’acquisto. Il verdetto cambia per ogni account, non per ogni build.
Tester del canale chiuso o license tester
| Situazione | Sul canale chiuso? | License tester? | Che cosa succede quando acquista |
|---|---|---|---|
| Un normale tester invitato | Sì | No | Può installare la build non pubblicata, e gli acquisti possono essere transazioni con addebito reale. |
| Un license tester che è anche sul canale | Sì | Sì | Installa la build chiusa e ottiene i metodi di pagamento di test di Google. |
| Un license tester con una build locale dal pacchetto corrispondente | Non necessariamente | Sì | Google consente ai license tester di testare la fatturazione senza il normale requisito della build caricata e firmata, quando le condizioni su pacchetto e account sono soddisfatte. |
| Un dispositivo con più account Google | Indifferente | Dipende da quale account | L’acquisto usa normalmente l’account che ha scaricato l’app; se non l’ha scaricata nessuno, Google usa il primo account. |
| Un acquisto di test mai confermato | Indifferente | Sì | Rimborsato automaticamente dopo 3 minuti nell’ambiente di test accelerato. |
I test di acquisto che un gioco monetizzato dovrebbe eseguire
| Test | Meccanismo | Comportamento atteso |
|---|---|---|
| Acquisto consumabile riuscito | Lo strumento di test che approva sempre. | Oggetto concesso, poi confermato o consumato correttamente. |
| Acquisto rifiutato | Lo strumento di test che rifiuta sempre. | Nessun oggetto concesso e nessuno stato parziale lasciato indietro. |
| Consumabile ripetuto | Acquista di nuovo lo stesso consumabile. | Il secondo e il terzo acquisto funzionano esattamente come il primo. |
| Non consumabile | Un acquisto di test riuscito. | Concesso una sola volta, con il riacquisto involontario impedito. |
| In sospeso che poi riesce | Il metodo di test che approva con ritardo. | Niente viene concesso finché lo stato non diventa acquistato, poi viene concesso una sola volta. |
| In sospeso che fallisce | Il metodo di test che rifiuta con ritardo. | Il diritto d’uso non viene mai concesso in nessun momento. |
| Riavvio a metà acquisto | Chiudi e riapri il gioco durante uno stato in sospeso. | Al riavvio lo stato del diritto d’uso si riallinea correttamente. |
| Conferma | Un acquisto riuscito lasciato lì fermo. | Sopravvive oltre i 3 minuti invece di essere rimborsato automaticamente. |
| Account sbagliato | Un dispositivo con più account Google collegati. | L’account di fatturazione è il license tester che avevi previsto. |
Prima che tutto questo funzioni
Il license testing si trova in Settings > License testing in Play Console, e l’elenco di indirizzi email lì accetta fino a 2.000 indirizzi, mentre un Google Group si può usare senza quel limite di elenco utenti. Anche i tuoi prodotti una tantum e i tuoi abbonamenti devono essere configurati e pubblicati come richiesto prima di poter essere testati come si deve: un prodotto non pubblicato produce errori che sembrano bug della fatturazione e sono invece lacune di configurazione.
Tempistiche della billing library: la Play Billing Library 7 ha superato la scadenza per le nuove app e per gli aggiornamenti il 31 agosto 2026. Se hai una proroga, vale fino al 1° novembre 2026; altrimenti i nuovi rilasci richiedono una versione successiva supportata. Essere la release più recente non è la stessa cosa che essere la versione minima consentita, quindi punta a una versione supportata e mantenuta invece di dare per scontato che l’ultima sia obbligatoria. Fonte: Testare la fatturazione in-app, compresi i license tester.
I loot box rendono il tuo gioco un’app di gioco d’azzardo?
No. Google distingue gli elementi virtuali randomizzati acquistati dal gioco d’azzardo con denaro reale. Se i giocatori spendono denaro o valore acquistato per elementi virtuali randomizzati come i loot box, devi comunicare chiaramente le probabilità prima dell’acquisto e vicino ad esso. Pagare per avere una possibilità di vincere un premio reale ricade in un regime di norme diverso, con regole proprie di idoneità e di licenza.
| La tua meccanica | Quali norme tocca | Cosa devi fare |
|---|---|---|
| Il giocatore compra un elemento virtuale noto e fisso | Le normali regole sugli acquisti digitali. | Testa l’acquisto come si deve e rispetta le regole di fatturazione di Play applicabili. Niente di speciale. |
| Il giocatore spende denaro o valore per un elemento virtuale randomizzato | Le norme sugli elementi randomizzati, che citano esplicitamente i loot box. | Comunica le probabilità prima dell’acquisto e vicino ad esso, dove il giocatore possa davvero vederle. |
| Il gioco rappresenta gioco d’azzardo simulato | Classificazione dei contenuti. | Rispondi al questionario di classificazione in modo accurato. La classificazione che ne risulta dipende dall’ente e dal questionario applicabili. |
| Il giocatore paga per avere una possibilità di vincere un premio reale | Le norme separate su gioco d’azzardo, giochi e concorsi con denaro reale. | Trattalo come una categoria soggetta a limitazioni, non come una normale monetizzazione con loot box. |
| Prodotto di gioco d’azzardo con denaro reale e licenza | Regole specifiche di idoneità, di paese e di licenza. | Fuori dalla portata dei consigli per un normale gioco indie. Lavora direttamente sulle norme specifiche di Google sul gioco d’azzardo. |
Il questionario di classificazione dei contenuti non è una formalità
Ogni gioco ha bisogno di risposte accurate e complete al questionario di classificazione dei contenuti, che si raggiunge da Policy > App content in Play Console, e va aggiornato quando cambiano i contenuti o le funzionalità che descrive. Dichiarare il falso su ciò che contiene un gioco può portare alla rimozione o alla sospensione, il che rende un questionario inesatto un errore molto più costoso di un frame lento.
I giochi toccano più parti del questionario rispetto alle app: violenza, gioco d’azzardo simulato, acquisti in-game, comunicazione tra utenti, contenuti generati dagli utenti. Se durante il test chiuso aggiungi una chat o una ricompensa randomizzata nella seconda settimana, le risposte che hai dato nella prima settimana sono ormai sbagliate. Riapri il questionario prima di richiedere l’accesso in produzione, non dopo che qualcuno se ne accorge.
Sotto tutto questo ci sono le norme sulla funzionalità e sulla qualità di base: app e giochi devono offrire esperienze stabili, reattive e sufficientemente funzionali, e qualcosa che va in crash, non si carica o è di fatto non funzionante può violarle. Non è una regola pubblicata Non esiste un numero minimo pubblicato di livelli, schermate, meccaniche o minuti di gioco. Un gioco breve non è un problema di norme; un gioco rotto sì.
Fonte: le norme di Google Play sugli elementi virtuali randomizzati (risposta 9858738), che impongono di comunicare le probabilità prima dell’acquisto e vicino ad esso.
Perché l’accesso a Play Games non funziona durante il test chiuso?
Perché Play Games Services ha un proprio elenco di tester. Finché la tua configurazione di Play Games Services non è pubblicata, i tester devono essere autorizzati singolarmente oppure tramite un canale di pubblicazione abilitato, altrimenti Google dice che incontreranno errori OAuth e 404. Essere sul canale chiuso dà al tester la build. Non gli dà il livello Play Games.
Il sintomo è caratteristico e ingannevole: l’accesso funziona sulla tua macchina, funziona per te su un dispositivo e poi fallisce per tutti gli altri nel momento in cui la build arriva da Play. Sembra una versione difettosa, e questo spinge gli sviluppatori a ricostruire qualcosa che non era mai stato sbagliato.
La configurazione che lo risolve
-
01
Apri l’elenco dei tester di Play Games Services
In Play Console: Grow users > Play Games Services > Setup and management > Testers. Questo elenco è separato da quello dei tester del canale chiuso e non ne eredita nulla.
-
02
Autorizza i tester, oppure abilita il canale
Aggiungi gli account uno per uno, oppure abilita il canale di pubblicazione di Play Console pertinente per i test di Play Games Services, così chiunque abbia accesso alla build di test ottiene anche l’accesso a Play Games. La seconda opzione è quella che regge oltre una manciata di persone.
-
03
Verifica che le credenziali corrispondano alla build
L’autenticazione fallisce quando il nome pacchetto configurato o l’impronta del certificato di firma non corrisponde a ciò che è stato caricato. Con Play App Signing in gioco, l’impronta di cui ha bisogno la tua configurazione di Play Games è quella che usa Play, non quella presente sulla tua postazione di lavoro.
-
04
Testa ogni funzionalità che hai effettivamente attivato
Prima l’accesso, poi obiettivi, classifiche e partite salvate, nel modo in cui il tuo gioco li usa. Le partite salvate meritano particolare attenzione perché interagiscono con la progressione: un salvataggio che non si ripristina è un bug che i tuoi tester troveranno solo se arrivano abbastanza avanti da avere progressi che valga la pena ripristinare.
| Sistema | Cosa controlla | Sostituisce il test chiuso 12/14? | Dove si configura |
|---|---|---|---|
| Test chiuso | Chi può ricevere il gioco non ancora pubblicato e, per gli account personali interessati, il prerequisito stesso per l’accesso in produzione. | È questo il requisito obbligatorio. | Canale di test chiuso di Play Console. |
| Test di Play Games Services | L’accesso a una configurazione di Play Games Services non pubblicata e alle sue API. | No | Grow users > Play Games Services > Setup and management > Testers. |
| Test interno | Distribuzione iniziale rapida fino a 100 tester. | No | Un canale di test separato e facoltativo. |
| Preregistrazione | Una campagna sullo store per creare attesa attorno al lancio. | No | Inizialmente disattivata per gli sviluppatori soggetti al prerequisito di test. |
Quattro sistemi, quattro elenchi, un solo gioco. Questa sezione esiste soltanto perché tre di quei quattro sono invisibili dalla schermata del canale chiuso, e quindi chi ha configurato correttamente l’unico che vede dà ragionevolmente per scontato che gli altri seguano. Non è così.
Fonte: Configurazione della console di Play Games Services e autorizzazione dei tester, che documenta l’elenco dei tester, l’alternativa del canale abilitato e gli errori OAuth e 404 che vede un tester non autorizzato.
Puoi usare la preregistrazione mentre il tuo gioco è in test chiuso?
Non all’inizio. Per gli sviluppatori soggetti al requisito di test dei nuovi account personali, la preregistrazione è tra le funzionalità disattivate finché il requisito non è soddisfatto. Quando diventa disponibile, una campagna di preregistrazione può durare fino a 90 giorni, e uno sviluppatore può avere al massimo 2 app o giochi in preregistrazione nello stesso momento.
Questo pesa più sui giochi che sulle app, perché la preregistrazione è uno strumento di lancio e il lancio di un gioco di solito si pianifica a ritroso a partire da una data. Se il tuo piano prevedeva una campagna di preregistrazione in parallelo al test chiuso, quel piano va riordinato: prima soddisfa il prerequisito, poi lancia la campagna, poi pubblica.
| Fase | Test chiuso | Preregistrazione |
|---|---|---|
| Prima che il requisito sia soddisfatto | In corso: è questa la finestra che qualifica. | Disattivata per gli account interessati. |
| Dopo che l’accesso in produzione è stato concesso | Facoltativo, e comunque utile per gli aggiornamenti futuri. | Disponibile, fino a 90 giorni per campagna. |
| Gestire più titoli | Ogni nuova app deve soddisfare il requisito per il proprio nome pacchetto. | Al massimo 2 titoli in preregistrazione alla volta. |
| Test aperto | Il canale indicato dal prerequisito è quello chiuso. | Il test aperto diventa disponibile una volta ottenuto l’accesso in produzione. |
La sequenza pratica per un primo gioco: avvia il test chiuso appena la build è giocabile, invece di aspettare che sembri finita, perché le due settimane scorrono in parallelo al lavoro che stai già facendo. Il marketing che dipende dalle funzionalità dello store viene dopo, non durante.
Fonte: il requisito di test chiuso per i nuovi account personali (risposta 14151465), dove Google afferma che l’accesso in produzione e la preregistrazione restano limitati finché il requisito non è soddisfatto.
Che cosa devono fare davvero i tuoi tester con il gioco?
Percorri le strade in cui un gioco si rompe diversamente da un’app: l’installazione consegnata da Play, il tutorial, il ciclo di gioco principale, i progressi salvati tra un riavvio e l’altro, una sessione abbastanza lunga da scaldare il dispositivo, il passaggio in background e il ripristino, i download degli asset, gli acquisti e l’accesso a Play Games. Google non pubblica un numero di dispositivi né una durata di sessione obbligatori, quindi copri la gamma che il tuo gioco supporta davvero e spendi la profondità dove il tuo gioco è particolare.
| Area di test | Che cosa coprire | Perché vale il tempo | Stato |
|---|---|---|---|
| Installazione e primo avvio | Un’installazione pulita da Play, le autorizzazioni e la prima consegna degli asset. | Un gioco che si installa in locale può comunque fallire con il comportamento degli split e degli asset consegnati da Play. | Pratica di QA |
| Tutorial e onboarding | Ogni passaggio, più la navigazione indietro e i percorsi che le persone prendono per sbaglio. | L’accesso in produzione chiede come si sono impegnati i tester, e i primi minuti sono quello che la maggior parte di loro vedrà. | Pratica di QA |
| Ciclo di gioco principale | Abbastanza gioco da mettere alla prova i comandi, una vittoria, una sconfitta, un riavvio e una progressione normale. | È questa la differenza tra un test significativo e un’installazione passiva. | Pratica di QA |
| Progressione e salvataggi | Esci, riprendi, riavvia l’app, riavvia il dispositivo e ricarica i progressi. | La perdita dei salvataggi è il difetto che i giocatori puniscono di più, e richiede qualcuno che abbia dei progressi da perdere. | Pratica di QA |
| Prestazioni prolungate | Gioca ben oltre il primo minuto e tieni d’occhio il degrado dei frame e gli scatti. | Vitals inizia a misurare il frame rate dopo un minuto, e il calore arriva più tardi di così. | Metrica vitals |
| Varietà di dispositivi | Dispositivi reali che coprono la gamma supportata dal tuo gioco, pesata su quello che hanno in mano i tuoi giocatori. | La copertura va decisa in base al rischio; non è pubblicato nessun numero fisso di dispositivi o di GPU. | Pratica di QA |
| Percorsi grafici | I percorsi di rendering e le varianti di texture che la tua build distribuisce davvero. | Il targeting della compressione delle texture fa sì che dispositivi diversi possano ricevere asset diversi. | Pratica di QA |
| Memoria e stabilità | Cambi di livello, riavvii ripetuti, scene pesanti e sessioni lunghe. | Gli arresti anomali e gli ANR sono metriche di qualità misurate da Play, con soglie pubblicate. | Metrica vitals |
| Background e ripristino | Tasto Home, una notifica che interrompe, schermo spento e riacceso, ricreazione del processo dove è praticabile. | I giochi perdono lo stato e il contesto di rendering intorno ai cambi del ciclo di vita più spesso delle app. | Pratica di QA |
| Consegna degli asset | Qualunque modalità tra install-time, fast-follow e on-demand usi il tuo gioco, download interrotti compresi. | Le modalità si comportano in modo diverso e il test in locale non riproduce la consegna di Play. | Limiti di Google |
| 64 bit | La build in esecuzione in un ambiente a 64 bit, soprattutto in presenza di plugin nativi. | Google Play richiede il supporto a 64 bit per le app pubblicate. | Requisito Google |
| Acquisti in-app | Approvato, rifiutato, in sospeso, consumabile ripetuto, diritto d’uso e conferma. | Google mette a disposizione gli strumenti di pagamento per i license tester proprio per questi scenari. | Meccanismo Google |
| Play Games Services | L’accesso più ogni obiettivo, classifica e funzione di partita salvata che hai abilitato. | Le configurazioni non pubblicate richiedono un’autorizzazione separata dei tester e credenziali corrispondenti. | Requisito Google |
| Dichiarazioni sui contenuti | Il questionario di classificazione, il pubblico di destinazione e qualsiasi comportamento legato alle probabilità degli oggetti casuali. | Classificazioni inesatte o divulgazioni mancanti sono un rischio per le norme, indipendente dal test. | Norme di Google |
Dai ai tester un percorso, non un generico «provalo»
Il modo più rapido per trasformare dodici installazioni in dodici report utili è consegnare alle persone un breve percorso numerato dentro il gioco, con una cosa da notare a ogni tappa e una domanda a cui vuoi davvero una risposta. I tester a cui viene detto di esplorare non segnalano niente; i tester a cui viene detto «arriva al livello tre, poi chiudi il gioco, poi riaprilo e dimmi se i tuoi progressi sono ancora lì» segnalano il bug dei salvataggi il secondo giorno invece che il tredicesimo. Gli emulatori non possono aiutarti con le righe qui sopra che dipendono dal calore, dalle GPU vere o dalle condizioni di rete reali, e i rischi di affidarsi a loro sono trattati nel post sugli emulatori nel test chiuso.
Perché Google chiede altri 14 giorni dopo che sei arrivato a 12?
Perché l’accesso in produzione valuta la qualità del test, non solo il contatore. Google chiede che cosa hanno fatto i tester, quali feedback hanno dato e che cosa hai cambiato, e indica i tester che non si sono impegnati con la tua app come uno dei motivi per cui può richiedere altri test. Arrivare a 12 e a 14 è la soglia minima di idoneità, non un’approvazione.
Gli sviluppatori raccontano regolarmente questo esito: i numeri erano rispettati, la richiesta è partita e la risposta è stata altri test. Segnalato dalla community I thread sono coerenti sull’esperienza e molto meno affidabili sulla causa, dato che nessuno fuori da Google vede il ragionamento. Quello che si può dire in base alla documentazione di Google è che il coinvolgimento e i feedback fanno parte di ciò che viene valutato, ed è abbastanza per lavorarci.
| Sintomo | Prima cosa da controllare | Il rimedio concreto |
|---|---|---|
| Play dice che non ci sono abbastanza tester idonei | Qualcuno non ha mai completato l’attivazione, qualcuno è uscito, oppure la finestra continuativa non è finita. | Verifica che almeno 12 account idonei siano rimasti attivati continuamente per tutta la finestra richiesta. |
| 12 tester e 14 giorni fatti, accesso rifiutato | Google ha ritenuto che servissero altri test, e questo può dipendere da un coinvolgimento debole o da una raccolta di feedback povera. | Leggi la risposta, continua a testare in modo significativo, raccogli feedback reali, correggi ciò che indicano e rispondi alla richiesta in modo accurato. |
| Il gioco funziona in locale, gli asset falliscono da Play | La modalità di consegna degli asset, il comportamento degli aggiornamenti o la pressione sullo spazio di archiviazione sono diversi dal tuo ambiente locale. | Testa la build consegnata da Play e gestisci la disponibilità dei pacchetti e gli stati di aggiornamento, invece di dare per scontato che valga il comportamento locale. |
| Il gioco inizia a scattare dopo un uso prolungato | Collo di bottiglia della CPU o della GPU, throttling termico, frame pacing o frequenza di aggiornamento non allineata. | Profila le sessioni lunghe e lo stato termico invece di quelle brevi, usando gli strumenti Android per le prestazioni dei giochi. |
| La finestra di acquisto mostra una carta vera | L’account non sta operando come license tester, oppure sul dispositivo sta acquistando un altro account. | Aggiungi l’account previsto in Settings > License testing e verifica quale account ha scaricato la build. |
| Acquisto di test rimborsato pochi minuti dopo | L’acquisto non è mai stato confermato. | Correggi la logica di conferma o di consumo. Gli acquisti in license test vengono rimborsati automaticamente dopo 3 minuti se non confermati. |
| L’accesso a Play Games restituisce un errore OAuth o 404 | Il tester non è autorizzato per la configurazione di Play Games non pubblicata. | Aggiungi il singolo tester di Play Games oppure abilita il canale di rilascio per i test di Play Games. |
| Play Games funzionava, poi si è rotto dopo il caricamento | Il nome pacchetto o il certificato di firma non corrispondono tra la configurazione e la build caricata. | Verifica l’impronta di Play App Signing, il nome pacchetto e la credenziale collegata. |
| Il gioco nativo manca su alcuni dispositivi | Una lacuna nell’ABI o nel supporto a 64 bit. | Verifica che esista una libreria a 64 bit corrispondente per ogni architettura nativa supportata e prova in un ambiente a 64 bit. |
| Segnalato per funzionalità non funzionanti o insufficienti | Il gioco va in crash, non si carica oppure non offre funzionalità realmente utilizzabili. | Correggi i problemi funzionali. Non metterti a cercare un numero minimo di livelli inventato da soddisfare. |
| Acquisto di oggetti casuali contestato | Le probabilità degli oggetti casuali acquistabili non sono indicate dove i giocatori le vedono. | Mostra le probabilità prima dell’acquisto e vicino al punto in cui avviene. |
Come dovrebbe essere un secondo ciclo
Se ti viene chiesto altro test, la tentazione è ripetere la prima tornata con lo stesso schema di installazioni passive sperando in una risposta diversa. Un secondo ciclo più utile cambia qualcosa di concreto: tieni stabile il gruppo, dai ai tester un percorso vero dentro il gioco, raccogli per iscritto quello che segnalano, pubblica le correzioni che i feedback giustificano e descrivi tutto questo con chiarezza quando ripresenti la richiesta. Non per caso, è anche ciò che produce un gioco migliore.
Quello che non dovrebbe includere è un rituale inventato. Non esiste un numero pubblicato di avvii, non esiste un numero obbligatorio di aggiornamenti e non esiste una quota di gioco quotidiana che trasformi un rifiuto in un’approvazione, e nessuno può prometterti che un certo schema di attività cambierà la decisione di Google. Altro sugli schemi di rifiuto in generale nel post sul perché il test chiuso viene rifiutato.
Scadenze chiave di Google Play per chi pubblica giochi nel 2026 e all’inizio del 2027
Il 31 agosto 2026 è passato: i giochi mobile nuovi e aggiornati devono avere come target Android 16 (livello API 36) o versioni successive, e Play Billing Library 7 ha superato la sua scadenza per le nuove app e per gli aggiornamenti. Se hai una proroga, questa dura fino al 1° novembre 2026, tra 57 giorni.
Ce ne sono altre tre lì intorno: il 30 settembre 2026 per la registrazione del nome pacchetto su Play e per la prima ondata di applicazione della verifica degli sviluppatori, e il 1° febbraio 2027 per le pagine di memoria da 16 KB, che è quella con più probabilità di cogliere di sorpresa un gioco costruito su un motore. Nessuna di queste fa parte del requisito sui tester, e ognuna di esse può bloccare proprio il rilascio che quel requisito dovrebbe sbloccare.
| Data | Requisito | Che cosa significa per un gioco |
|---|---|---|
| 31 agosto 2026 | Livello API target | I giochi mobile nuovi e aggiornati devono avere come target Android 16, livello API 36 o successivo. Gli altri form factor sono diversi: Wear OS e Android Automotive OS richiedono l’API 35, Android TV e Android XR l’API 34. Quadro completo nel post sul livello API target. |
| 31 agosto 2026 | Play Billing Library | La Play Billing Library 7 raggiunge la scadenza per le nuove app e per gli aggiornamenti. I giochi monetizzati hanno bisogno di una versione successiva supportata per i nuovi rilasci, a meno che non valga una proroga. |
| 30 settembre 2026 | Registrazione del nome pacchetto su Play | Qualsiasi app o gioco su Play il cui nome pacchetto risulti ancora non registrato a questa data rischia la rimozione da Play. Vale a livello globale e non ha niente a che fare con l’età del tuo account. |
| 30 settembre 2026 | Verifica degli sviluppatori, prima ondata | Prima applicazione della verifica degli sviluppatori Android, per le installazioni tramite gli store partecipanti in Brasile, Indonesia, Singapore e Thailandia. Non è uno spegnimento mondiale. Dettagli nel post sulla verifica degli sviluppatori. |
| 1° novembre 2026 | Termine della proroga | L’ultima data coperta dalla proroga disponibile, sia per il requisito di targeting sia per la Play Billing Library 7. Le proroghe si richiedono dall’avviso corrispondente in Play Console, non vengono concesse in automatico. |
| 1° febbraio 2027 | Pagine di memoria da 16 KB | Gli aggiornamenti interessati che hanno come target il livello API 35 o successivo e che includono codice nativo non possono essere rilasciati senza la compatibilità con le pagine di memoria da 16 KB. I binari del motore e dei plugin sono esattamente il punto in cui questo morde. Percorso di riparazione nel post sull’errore dei 16 KB. |
| 27 gennaio 2027 | Autorizzazioni per i contatti | Vale solo per le app che hanno come target Android 17, livello API 37 o successivo, e che usano l’accesso esteso ai contatti interessato, che la maggior parte dei giochi non richiede mai. La cronologia delle norme di Google e la tabella delle scadenze della Guida di Play Console adesso riportano entrambe questa data. |
Queste date si spostano senza annunci
Ricontrolla prima di pianificare Google pubblica le scadenze delle norme su due superfici che divergono e poi vengono riallineate in silenzio. Le scadenze su contatti e posizione qui sopra riportavano il 28 ottobre 2026 sulla cronologia di Android Developers fino a metà agosto 2026, quando quella pagina è stata modificata in 27 gennaio 2027 per allinearsi alla Guida di Play Console, senza nessuna voce nel changelog. Le vecchie newsletter di Google citano ancora la data ritirata. Confronta la tabella delle scadenze della Guida di Play Console con la cronologia delle norme prima di costruire un piano di rilascio su una qualsiasi riga qui sopra, e non fidarti né di una newsletter né di un articolo più che delle pagine attive. Una riga è ancora in disaccordo oggi: gli Standard per la sicurezza dei minori danno il 26 agosto 2026 nella tabella della Guida e il 28 ottobre 2026 sulla cronologia. Pianifica per il 26 agosto.
Fonti: requisiti del livello API target (risposta 11926878) per le date di targeting del 31 agosto e per i livelli dei diversi form factor, e le due superfici delle norme di Google per il resto: la tabella delle scadenze della Guida di Play Console e la cronologia delle norme di Android Developers.
Vale la pena dirlo chiaramente, perché è la sequenza a cogliere di sorpresa: nessuna di queste date ha a che fare con il requisito sui tester, e superare il requisito sui tester non ti esenta da nessuna di esse. Un gioco può completare un test chiuso di 14 giorni impeccabile e restare comunque impossibilitato a pubblicare perché la build ha come target il livello API sbagliato. Controlla i requisiti che bloccano il rilascio prima di iniziare le due settimane, non dopo.
Dove trovi 12 tester reali per un gioco?
Reclutarli è la parte che la maggior parte degli sviluppatori solitari sottovaluta. Il requisito di test pubblicato da Google non prescrive come i tester debbano essere reclutati, quindi pagare per il QA non è automaticamente squalificante, ma leggilo come l’assenza di un divieto, non come un avallo di Google ai servizi di tester come categoria, perché un avallo del genere Google non l’ha mai pubblicato. Quello che le norme di Google vietano davvero è manipolare valutazioni, recensioni, posizionamento o numero di installazioni con mezzi illegittimi: bot, account falsi, installazioni fraudolente, coinvolgimento manipolato. L’asticella è persone reali che fanno test veri e danno feedback onesti, comunque tu le abbia trovate.
Il motivo per cui le community dei motori di gioco sono piene di post «servono 12 tester» è aritmetico: chi sviluppa un gioco per la prima volta di solito non conosce dodici persone che abbiano un telefono Android, che completino l’attivazione e che siano ancora attivate due settimane dopo. Gli amici lo installano, giocano una volta per cortesia e si perdono per strada. Non c’è nessun difetto di carattere in tutto questo. È solo che un favore ha un tempo di dimezzamento di circa tre giorni e il requisito dura quattordici.
I gruppi di scambio tester risolvono il conteggio e spesso poco altro, perché chi scambia ha il tuo stesso incentivo: attivarsi, restare attivato e passare oltre. Questo soddisfa il contatore producendo esattamente quello schema di coinvolgimento passivo su cui Google fa domande nel modulo di richiesta. Per un gioco è peggio che per un’app, perché i difetti che contano stanno diverse sessioni più in profondità e un tester reciproco non ci arriverà mai.
Che cosa copre un test gestito
PrimeTestLab fornisce 12 tester reali su dispositivi reali da Android 7 a 17, attivati e mantenuti per tutti i 14 giorni, con il test che parte entro 4-6 ore. Lo abbiamo fatto su 7.400+ app in 120+ paesi con un tasso di successo del 99,9%, e il test è coperto da un nuovo test gratuito o dal rimborso completo. I piani partono da $19.99.
Diciamolo chiaramente, il confine, perché un gioco ha parti che nessuno può prendersi in carico al posto tuo: un test gestito tiene il lato tester delle due settimane. Non ricostruisce i tuoi pacchetti di asset, non ottimizza i tuoi tempi di frame, non implementa la conferma nel tuo codice di fatturazione e non risponde al tuo questionario di classificazione. Quelle cose restano tue, e le sezioni qui sopra esistono per accorciarle. Quello che sparisce è la corsa al reclutamento e il rischio che il gruppo crolli il nono giorno.
Reclutare da solo o affidarsi a un test gestito
| Il requisito di Google | Reclutare da solo | Un test gestito |
|---|---|---|
| Almeno 12 tester attivati | Trova, istruisci e insegui persone reali, poi spera che ognuna di loro completi l’attivazione. | 12 forniti e mantenuti per tutta la finestra. |
| 14 giorni continuativi | Una disattivazione ti costa il test solo se lascia meno di 12 tester in grado di mostrare ciascuno 14 giorni continuativi quando fai richiesta. | Il gruppo viene monitorato perché la finestra resti intatta. |
| Dispositivi reali, persone reali | Emulatori e account dormienti sono la scorciatoia abituale, e il motivo abituale per cui un test non produce niente da raccontare. | Dispositivi reali da Android 7 a 17. |
| Coinvolgimento di cui poter parlare a Google | Dipende interamente dal fatto che i tuoi tester giochino davvero oltre il tutorial. | Tester che giocano al gioco invece di parcheggiarlo su una schermata Home. |
| Tempo alla prima attivazione | Giorni, a seconda di chi ti risponde. | Il test parte entro 4-6 ore. |
| Costo | Il tuo tempo, durante le due settimane che stai già spendendo sulla build. | Da $19.99, con un nuovo test gratuito o il rimborso completo. |
Una cosa che nessun servizio può offrire, e su cui dovresti diffidare di chiunque lo faccia: l’accesso in produzione in sé. Lo decide Google, che valuta la qualità del tuo test oltre al conteggio e può chiedere un altro ciclo. Quello che si può promettere è il gruppo di tester, le due settimane e la garanzia che le accompagna. Guarda i piani e che cosa include ciascuno →
Domande frequenti
I giochi hanno bisogno di 12 tester per 14 giorni su Google Play?
Sì, quando il gioco viene pubblicato da un account sviluppatore personale di Google Play creato dopo il 13 novembre 2023. Google richiede almeno 12 tester attivati continuamente su un test chiuso per almeno gli ultimi 14 giorni prima che quello sviluppatore possa richiedere l’accesso in produzione, e in tutta la documentazione attuale non compare nessun minimo di tester specifico per i giochi. Google tratta app e giochi all’interno dello stesso processo di accesso in produzione.
Online continuo a leggere 20 tester. Nel 2026 sono 12 o 20?
Sono 12. In origine Google richiedeva 20 tester e ha ridotto ufficialmente il minimo a 12 l’11 dicembre 2024, descrivendo la modifica come la richiesta di 12 tester invece di 20. Il periodo di test continuativo di due settimane è rimasto invariato. Le pagine che citano ancora 20 sono state scritte prima di quel cambiamento.
Ogni nuovo gioco ha bisogno di un proprio test chiuso?
Sì, per gli account sviluppatore personali interessati. È la data di creazione dell’account a decidere se il requisito si applica a te, ma Google scrive la condizione come un test chiuso «per la tua app», e la richiesta di accesso in produzione si invia per un singolo nome pacchetto. Un test valido per un gioco non si trasferisce al gioco successivo che pubblichi dallo stesso account.
I miei 12 tester devono giocare tutti i giorni?
La regola esplicita è l’attivazione continuativa. Google richiede che i tester validi restino attivati senza interruzioni e dice che il coinvolgimento dei tester conta quando esamina l’accesso in produzione, ma non pubblica nessuna regola del tipo apri il gioco una volta al giorno oppure gioca un certo numero di minuti. L’obiettivo sicuro è un gioco reale e significativo con feedback utili. Una quota di gioco giornaliera è folklore della community, non una norma.
Se un tester se ne va, i 14 giorni ripartono da capo?
Non automaticamente. Quando fai la richiesta, almeno 12 tester devono essere rimasti attivati ciascuno per i 14 giorni continuativi precedenti. Se sei partito con più di 12 e hai ancora quel numero di tester validi, una disattivazione non invalida il test. Se la disattivazione ti lascia con undici, devi aspettare che un tester sostitutivo abbia completato il proprio periodo continuativo di 14 giorni. È questo il motivo per reclutare oltre il minimo.
Posso caricare una nuova build del gioco durante il test di 14 giorni?
Sì. La condizione pubblicata da Google si basa sulla storia di attivazione dei tester, non sul mantenere una build congelata per 14 giorni, quindi pubblicare una nuova versione non cancella di per sé il periodo di attivazione continuativa dei tester. Lascia alla nuova versione il tempo di completare l’elaborazione, chiedi ai tester di aggiornare e continua a documentare i feedback e le correzioni che ne sono derivate. Google segnala che le modifiche a un test possono richiedere diverse ore prima di diventare disponibili per i tester.
Basta tenere il gioco installato per 14 giorni?
Non considerare la sola installazione come prova di aver testato. Il prerequisito numerico è l’attivazione continuativa, ma la richiesta di accesso in produzione chiede come i tester si sono impegnati con il gioco, quali feedback sono stati raccolti e che cosa è cambiato di conseguenza. Google indica i tester che non si sono impegnati con la tua app come un motivo per cui può richiedere ulteriori test.
Disinstallare il gioco azzera il test di 14 giorni?
Google non pubblica una regola separata secondo cui una disinstallazione di per sé azzeri il periodo di attivazione; il requisito numerico esplicito è l’attivazione continuativa. Ma un gioco disinstallato non produce partite, né feedback, né prove dei test, e Google può richiedere ulteriori test quando il coinvolgimento è insufficiente. Restare attivati senza mai aprire il gioco non è una strategia sicura e, per un gioco, significa anche che nessuno sta mettendo alla prova i percorsi di salvataggio, di consegna degli asset e di prestazioni che si rompono davvero.
Posso usare il test interno al posto del test chiuso con 12 persone?
Non per questo prerequisito. Il test interno è un canale separato che supporta fino a 100 tester, ma il requisito di Google per i nuovi account personali interessati richiede espressamente un test chiuso valido prima di richiedere l’accesso in produzione. Il test interno è utile per una distribuzione iniziale rapida; non soddisfa il passaggio obbligatorio del test chiuso.
Quanto può essere grande il mio gioco Android su Google Play nel 2026?
La Guida di Play Console indica 500 MB per il modulo di base, 500 MB per modulo di funzionalità, 1,5 GB per pacchetto di asset, 4 GB cumulativi per tutti i moduli più i pacchetti di asset install-time, 30 GB cumulativi per i pacchetti fast-follow e on-demand e un massimo totale di 34 GB di dimensione di download compressa, con un massimo di 100 pacchetti di asset per bundle. Sono dimensioni di download compresse calcolate da Play Console e non la dimensione del bundle sul tuo disco. Valori verificati il 12 agosto 2026.
I tester devono acquistare un gioco a pagamento durante il test chiuso?
Sì. I tester di un test aperto o chiuso devono comunque acquistare un gioco a pagamento. I tester del canale di test interno possono installare gratuitamente un gioco a pagamento. È un meccanismo distinto dal license testing per gli acquisti in-app, che decide se un IAP usa i metodi di pagamento di prova di Google invece di addebitare denaro reale.
Perché Google Play addebita gli acquisti in-app ai giocatori del mio test chiuso?
Far parte del canale chiuso e il license testing della fatturazione sono due cose diverse. Google afferma che gli utenti sostengono addebiti reali a meno che l’utente non sia un license tester, quindi un normale tester del tuo canale chiuso può vedersi addebitare denaro vero. Aggiungi gli account destinati ai test di acquisto in Settings e License testing per ottenere i metodi di pagamento di prova di Google, compresi gli scenari di approvazione sempre positiva, di rifiuto sempre e di pagamento ritardato.
Perché l’accesso a Google Play Games non funziona nel mio gioco in test chiuso?
Play Games Services ha un proprio livello di accesso. Finché la configurazione di Play Games Services non è pubblicata, i tester devono essere autorizzati singolarmente oppure tramite un canale di pubblicazione abilitato di Play Console, altrimenti Google dice che i tester incontreranno errori OAuth e 404. Aggiungili in Grow users, Play Games Services, Setup and management, Testers, e verifica che il nome pacchetto e l’impronta del certificato di firma corrispondano alla build.
Un gioco piccolo o semplice viene rifiutato per funzionalità minima?
Google ha norme sulla funzionalità e sulla qualità che richiedono esperienze stabili, reattive e sufficientemente funzionali, e le app o i giochi che vanno in crash, non si caricano o sono di fatto non funzionanti possono violarle. Nessuna fonte primaria di Google pubblica un numero minimo fisso di livelli, schermate, meccaniche o minuti di gioco. Considera folklore qualunque numero preciso tu legga e correggi invece i problemi funzionali reali.
I loot box rendono automaticamente un gioco Android un’app di gioco d’azzardo?
No. Le norme di Google separano gli elementi virtuali randomizzati acquistati dal gioco d’azzardo con denaro reale. I giochi che offrono elementi virtuali randomizzati come i loot box devono comunicare chiaramente le probabilità prima dell’acquisto e vicino ad esso. Pagare denaro o valore acquistato per avere una possibilità di vincere un premio reale ricade nelle norme separate di Google su gioco d’azzardo, giochi e concorsi con denaro reale, che sono un regime diverso con requisiti propri di idoneità e di licenza.
Può fornire qualcun altro i 12 tester per il mio gioco?
Sì. Il requisito di test di Google non prescrive come vadano reclutati i tester, quindi pagare per il QA non è di per sé squalificante. Leggilo come l’assenza di un divieto e non come un avallo di Google ai servizi di tester, che non c’è mai stato. Ciò che viola le norme è manipolare valutazioni, recensioni, posizionamento o numero di installazioni con mezzi illegittimi, come bot, account falsi o installazioni fraudolente. PrimeTestLab fornisce 12 tester reali su dispositivi reali a partire da $19.99, tiene il gruppo attivato per tutti i 14 giorni e sostiene il ciclo con un nuovo test gratuito o un rimborso completo. Nessuno può promettere l’accesso in produzione, perché quella decisione spetta a Google, che valuta la qualità dei tuoi test oltre al numero.
Conclusione
In sintesi
Google Play non ha nessuna clausola per i giochi. Un account sviluppatore personale creato dopo il 13 novembre 2023 ha bisogno di 12 tester attivati per 14 giorni continuativi prima di poter richiedere l’accesso in produzione, che pubblichi un gioco o una calcolatrice, e la cifra 20 che ancora circola è stata sostituita l’11 dicembre 2024. Superare quel contatore è il minimo, non il verdetto: Google chiede che cosa hanno fatto i tuoi tester, che cosa ti hanno detto e che cosa hai cambiato. Un gioco affronta poi un secondo strato che il contatore non tocca mai, ed è qui che le due settimane valgono davvero qualcosa: pacchetti di asset che si comportano male solo quando li consegna Play, frame che rallentano dopo che il telefono si è scaldato, binari nativi a 64 bit, tester a cui vengono addebitati soldi veri perché nessuno li ha aggiunti in Settings > License testing, l’accesso a Play Games che restituisce 404 a tutti tranne che a te, e la divulgazione delle probabilità sugli oggetti casuali. Prova tutto questo durante le due settimane che stai già spendendo. Se la parte che non riesci a coprire è quella dei tester, PrimeTestLab fornisce 12 tester reali a partire da $19.99 con un nuovo test gratuito o il rimborso completo. Guarda i piani e i prezzi →
Fonti primarie
Che cosa di questa pagina diventerà obsoleto per primo
- I limiti di dimensione. È la tabella più a rischio di questa pagina. La pagina di Play Console dedicata alle dimensioni e alcune vecchie pagine per i giochi Android sono già in disaccordo, e i tetti di fast-follow e on-demand sembrano ampliati di recente. Ricontrolla la pagina sulle dimensioni prima di pianificare un rilascio intorno ai 30 GB o ai 34 GB.
- Le date della fatturazione. Le finestre di supporto della Play Billing Library si spostano di versione in versione, e le date del 31 agosto e del 1° novembre presenti in questa pagina cambiano significato nel momento stesso in cui passano. Questa pagina cambia da sola la propria formulazione a quelle date; la tabella di supporto sottostante va comunque riletta.
- Le date di scadenza delle norme. È l’elemento che cambia più spesso in questa pagina. A metà agosto 2026 Google ha spostato le scadenze su contatti e posizione dal 28 ottobre 2026 al 27 gennaio 2027 su una sola superficie, senza annunciarlo, e le sue stesse newsletter hanno continuato a citare la data ritirata anche dopo. Qualsiasi data qui va risolta sulle due pagine delle norme attive di Google, non su una newsletter o su un articolo, questo compreso.
- I percorsi nella Console. Settings > License testing, Policy > App content e il percorso dei tester di Play Games Services sono la formulazione attuale, e la navigazione di Play Console cambia indipendentemente dalle norme.
- Le soglie di Android vitals. I valori di arresti anomali, ANR e sessioni lente sono soglie di qualità che Google può rivedere secondo i suoi tempi, separatamente da qualsiasi cosa riguardi i requisiti di test.
- I numeri dei tester. Sono i meno a rischio del gruppo, ma 20 è già diventato 12 una volta. Se un numero qui non coincide con la pagina di Google, ha ragione la pagina di Google e questa è vecchia.
Verificato sulla documentazione di Google il 12 agosto 2026. Le date di scadenza delle norme sono state riverificate il 14 agosto 2026.