Requisiti di pubblicazione Google Play per nuovi sviluppatori nel 2026

Google Play non rilascia un’unica approvazione. Trattiene la release dietro una catena di passaggi obbligatori distinti e ognuno ha la propria regola di applicabilità: buona parte di ciò che segue, quindi, non riguarderà te.

Ogni requisito qui sotto porta con sé le stesse quattro informazioni: a chi si applica, che cosa devi fare, che cosa dimostra che è completato e la pagina ufficiale da cui arriva. Dove le pagine di Google si contraddicono tra loro, e qui succede su due punti, trovi entrambe le versioni invece della nostra ipotesi.

I requisiti di pubblicazione Google Play in sintesi

Qui sotto trovi tutti i passaggi obbligatori, con la regola che decide se riguardano te e l’elemento di Play Console che dimostra che sono completati. Le righe contrassegnate come condizionale vengono saltate del tutto da una parte degli sviluppatori.

L’ordine in cui succedono davvero

Otto tappe, e l’ordine non è una preferenza: tre di esse sono prerequisiti veri e propri per quella successiva.

1. Scegli e verifica il tuo account sviluppatore Tipo di account, quota, identità e verifica del dispositivo dove la Console la mostra.
2. Crea l’app e prepara una build conforme Record dell’app e ID applicazione, App Bundle e firma, livello API target, controlli preliminari sulla build.
3. Controlla la registrazione dello sviluppatore Android Un controllo di stato in Play Console, una volta che l’app e il suo package esistono.
4. Completa la scheda dello Store e le risorse Limiti di testo, grafica obbligatoria, maschera dell’icona, dichiarazioni sulle risorse generate con l’IA.
5. Completa Contenuti dell’app e l’accesso per i revisori Privacy, Sicurezza dei dati, eliminazione, classificazione, pubblico, annunci, le due dichiarazioni universali, istruzioni di accesso.
6. Esegui il test chiuso valido 12 tester attivati per 14 giorni continuativi. Vale per i soli account personali creati dopo il 13 nov 2023 e per nessun altro.
7. Richiedi l’accesso alla produzione Il questionario in tre parti su test, app e stato di preparazione.
8. Invia e pubblica la release di produzione Paesi, prezzi, bundle, note di rilascio, invio per la revisione e poi pubblicazione.

1. Scegli e verifica il tuo account sviluppatore

Ti serve un account Google con la verifica in due passaggi attiva e, al momento della registrazione, accetti l’Accordo di distribuzione per gli sviluppatori e i Termini di servizio di Play Console. Prima di poter pubblicare devono poi andare a buon fine tre cose: la quota, la tua identità e, dove la Console lo prevede, una verifica del dispositivo.

Che cos’è la quota di 25 USD e che cosa non è

La quota si paga solo con carta di credito o di debito. I tipi di carta accettati variano in base al paese e Google dice esplicitamente che le carte prepagate non sono accettate.

Personale o organizzazione, e quando la scelta è già fatta

Parti dalla domanda sulla categoria, perché per alcune app non c’è nessuna scelta da fare.

Se nessuna di quelle categorie ti riguarda, la scelta è tua. Entrambi i tipi possono pubblicare e monetizzare, quindi una parte della differenza sta solo in ciò che Google verifica su di te, ma non è soltanto burocrazia. Un account personale creato dopo il 13 novembre 2023 deve anche eseguire un test chiuso valido, che è la voce fissa più lunga di questa guida. Confronto completo: account personale e account dell’organizzazione.

Che cosa richiede la verifica dell’account e perché i tempi variano

Prima che tu possa pubblicare, Google verifica chi sei a livello di account. Un account personale fornisce un documento d’identità ufficiale rilasciato dallo Stato; un’organizzazione fornisce i dati dell’organizzazione insieme a un documento. Quello che ti viene chiesto può dipendere da ciò che il tuo profilo dei pagamenti verifica già, ed è per questo che a due persone che seguono la stessa guida vengono chieste cose diverse. Verificare l’identità dello sviluppatore

Google non pubblica alcun tempo di elaborazione garantito per la revisione dell’identità di un account Play, e il «fino a 5 giorni» che si legge ovunque non lo è: quella cifra viene dalla documentazione di Google sui pagamenti, non dalla pagina sull’identità di Play. Completa le attività che la Console ti mostra e metti in conto controlli aggiuntivi sui documenti. La verifica del metodo di pagamento è ancora un’altra cosa: è un controllo da commerciante legato alla riscossione dei pagamenti, non un passaggio che ogni sviluppatore di app gratuite deve avviare. Informazioni sull’account e verifiche per i commercianti

Completato quando: Play Console smette di mostrare l’attività di verifica dell’identità per il tuo account. Considera «inviato» e «approvato» come due stati diversi: un documento inviato non sblocca la pubblicazione.

Verifica del dispositivo: il passaggio che quasi tutte le guide si perdono

I nuovi account sviluppatore personali hanno un’attività dedicata al dispositivo. Verifichi l’accesso a un dispositivo Android mobile fisico, non rooted, con Android 10 o versioni successive, usando l’app mobile Play Console mentre sei connesso come titolare dell’account. Requisiti di verifica del dispositivo

Che cosa non è: non è la verifica dell’identità, non è il test chiuso valido e non è una regola sui tuoi tester, perché da nessuna parte si dice che le 12 persone del tuo test chiuso debbano avere quelle caratteristiche di dispositivo. È una voce a sé sulla pagina Home della Console e un emulatore non la completa.

Completato quando: L’attività di verifica del dispositivo sparisce dalla pagina Home di Play Console.

Cambiare tipo di account in un secondo momento

Puoi convertire un account sviluppatore personale in un account dell’organizzazione attraverso la procedura di verifica di Google: verifichi il sito web dell’organizzazione, crei oppure selezioni e verifichi il suo profilo dei pagamenti, poi completi il cambio nell’account esistente. Google consiglia di aspettare almeno 72 ore dopo la conversione prima di inviare nuove app. Il percorso inverso, da organizzazione a personale, richiede invece un account nuovo. Conversione del tipo di account

2. Crea la tua app e prepara una build conforme

Due metà: il record dell’app che crei in Play Console e l’artefatto che ci carichi dentro. Una decisione presa qui accompagna l’app per tutta la sua vita, quindi vale trenta secondi adesso.

Le decisioni che restano per sempre

Creare l’app in Play Console ne fissa il nome, la lingua predefinita, il tipo app o gioco e lo stato gratuito o a pagamento. L’ID applicazione è un’altra cosa: vive nella configurazione della tua build, non in quel modulo della Console, e i due si incontrano al momento del caricamento. Controlla quindi l’ID applicazione nella tua build prima di caricarla, invece di dare per scontato che un record vuoto in Console lo abbia già fissato. Creare e configurare la tua appID applicazione

Android App Bundle e i due ruoli di firma

Per una normale nuova app pubblica, Google Play accetta l’Android App Bundle (.aab) anziché un APK, e l’app usa Play App Signing. Vale la pena dirlo una volta con il suo ambito preciso, invece che come regola assoluta: le app legacy che ne hanno diritto mantengono flussi basati su APK, gli App Bundle sono obbligatori per tutte le app Android TV da giugno 2023 e la distribuzione privata di app aziendali segue regole ancora diverse. App BundleApp private

Play App Signing separa due ruoli, che non è la stessa cosa di due chiavi fisiche in tuo possesso. La chiave di firma dell’app è gestita da Google e firma ciò che gli utenti installano. La chiave di caricamento firma il tuo bundle prima del caricamento, così Google sa che arriva da te. I due ruoli possono poggiare sulla stessa chiave o su chiavi separate; una chiave di caricamento distinta è la configurazione consigliata, perché può essere reimpostata se la perdi. Firmare la tua app

Livello API target, per tipo di dispositivo

È il requisito che più spesso blocca del tutto un caricamento, e non è un numero solo: cambia in base a che cosa stai inviando.

In alcune circostanze Google documenta finestre di proroga che arrivano fino al 1° novembre 2026: l’idoneità, però, viene decisa per la tua specifica app dentro Play Console. Requisiti relativi al livello API target I dettagli sulla migrazione sono nella guida al livello API target.

Controlli preliminari: che cosa può far rifiutare un bundle apparentemente valido

Due controlli intercettano progetti che per il resto sembrano finiti. Sono entrambi condizionali: se nessuno dei due riguarda la tua app, salta questa parte e vai avanti.

Librerie native: 64 bit e dimensione di pagina da 16 KB

Se la tua app include codice nativo, in modo diretto, tramite un SDK o generato da un app builder, verificane il supporto a 64 bit e la compatibilità con le pagine da 16 KB, e provala in un ambiente a 16 KB. Le app scritte solo in Java o Kotlin, dipendenze comprese, supportano già la dimensione di pagina in questione. Controlla il bundle che carichi davvero: una dipendenza può reintrodurre una libreria a 32 bit o allineata a 4 KB senza che tu abbia cambiato nulla. Dimensioni delle pagine da 16 KB64 bit

Versione della Play Billing Library

Se, e solo se, la tua app integra Play Billing, i nuovi invii richiedono di norma la Billing Library versione 8 o successiva. La scadenza ordinaria della versione 7 era il 31 agosto 2026 e una proroga applicabile può arrivare fino al 1° novembre 2026. Niente di tutto questo riguarda un’app che non ha quell’integrazione, e non significa che le app già installate con versioni precedenti smettano di funzionare. Calendario di deprecazione di Billing

Completato quando: Un file .aab firmato viene caricato senza errori di livello API target o di formato, il codice versione è più alto di qualsiasi altro caricato in precedenza e, se l’app include codice nativo, passano sia i tuoi controlli di compatibilità sia una prova in un ambiente a 16 KB. Il fatto che Play Console convalidi un caricamento non equivale ad avere testato le tue dipendenze: risolvi i problemi bloccanti e leggi gli avvisi.

3. Controlla la registrazione dello sviluppatore Android in Play Console

Questa fase viene dopo la precedente perché richiede che l’app esista: la registrazione collega un’app, con il suo nome del package e l’impronta della chiave di firma, a un’identità di sviluppatore verificata, su tutto l’ecosistema Android e non solo su Google Play. È una cosa diversa dalla verifica dell’identità a livello di account della tappa 1, che dimostra chi sei perché tu possa avere un account.

Per chi pubblica su Play la domanda pratica è una sola: la tua app è registrata? Controllane lo stato nella pagina Android developer verification di Play Console. Google tenta la registrazione automatica e riutilizza la verifica dell’identità che hai già completato, quindi per la maggior parte degli sviluppatori su Play questo è un controllo di stato più che un’attività: non ti serve un account separato sulla Android Developer Console e non ripeti la verifica dell’identità. Conferma la registrazione e completa le eventuali azioni in sospeso che ti vengono indicate. Registrazione dei nomi dei package Play

Dal 30 settembre 2026 le app che restano non registrate rischiano la rimozione da Google Play a livello globale: è facile non accorgersene, perché quasi tutto ciò che si legge su quella data descrive solo la fase dei controlli all’installazione nei quattro paesi, che è un’altra parte dello stesso programma. Due cose che puoi ignorare: l’account gratuito Limited Distribution è pensato per chi distribuisce per hobby a una manciata di dispositivi e non è una via gratuita per arrivare su Google Play; e la versione minima di Android del verificatore lato dispositivo è documentata in modo incoerente (le FAQ di Android Developers dicono 7 e successive, la Guida di Android dice 8 e successive), il che è un conflitto irrisolto tra due pagine di Google più che un requisito su cui agire. Guida di Android

Completato quando: La pagina Android developer verification di Play Console mostra l’app come registrata, senza azioni in sospeso a suo carico.

4. Completa la scheda dello Store e le risorse

La scheda è la prima cosa che vedono utenti e revisori, e ha limiti rigidi che bloccano il salvataggio. La linea utile da tenere è quella tra ciò che Google richiede per pubblicare e ciò che consiglia per essere messi in evidenza; qui sotto le due cose sono separate.

Obbligatorio per pubblicare

Google Play Console · screenshot reale

Consigliato, ma non obbligatorio per pubblicare

Le indicazioni di Google sulle risorse di anteprima descrivono anche che cosa rende una scheda idonea alle superfici in formato grande e a quelle di raccomandazione: più screenshot, risoluzioni più alte, set dedicati alle classi di dispositivi su cui vuoi comparire in evidenza. Se qualcosa di tutto ciò manca, la release non viene bloccata. Le schede per Wear OS, TV e XR hanno in più regole proprie sulle risorse. Risorse di anteprima

La maschera degli angoli dell’icona

Carichi un’icona quadrata intera e Google Play applica una maschera dinamica agli angoli, con un raggio pari al 30% della dimensione dell’icona: tutto ciò che sta vicino a un angolo viene quindi tagliato nel risultato finale. Queste sono le specifiche attuali e non, come si ripete spesso, una novità introdotta nel 2026. La data di modifica di una pagina non dimostra da quando vale una regola. Specifiche di design dell’icona

Dichiarazioni IA per le risorse dello Store generate

Se generi o modifichi con l’IA immagini, video o materiale promozionale della scheda, Play Console include ora autodichiarazioni per singola risorsa nei suoi flussi di creazione dei contenuti, con etichette applicate alle risorse che rientrano nell’ambito normativo pertinente. La pagina di assistenza di Google non indica una data di inizio né un elenco esaustivo delle norme coperte, quindi non ce li inventiamo. Qui si parla di risorse dello Store, cosa distinta dalle norme che regolano ciò che un’app generativa produce per gli utenti. Dichiarare i contenuti generati dall’IA

Le regole sui metadati che fanno rifiutare le schede

Le indicazioni di Google sulla scheda sono rigide sul linguaggio promozionale nei campi che compaiono nei risultati di ricerca e negli scaffali dello Store: titolo, icona, nome dello sviluppatore e descrizione breve.

Completato quando: La scheda dello Store principale si salva senza errori di risorse mancanti e la grafica che hai caricato resta leggibile anche dopo la maschera degli angoli.

5. Completa Contenuti dell’app e l’accesso per i revisori

Contenuti dell’app è la parte che chi pubblica per la prima volta sottovaluta, perché non è lavoro di sviluppo eppure blocca tutto. È una pila di dichiarazioni, e una risposta incompleta o imprecisa è uno dei motivi più frequenti per cui un lancio si ferma.

Informativa sulla privacy: ogni app, in due posti

Ogni app ha bisogno di un’informativa sulla privacy, non solo le app rivolte ai bambini, come invece si racconta spesso. Inserisci il link in Play Console e un link o il testo dell’informativa dentro l’app. Usa un URL attivo, pubblico e non limitato per area geografica, non un PDF. Anche un’app che non raccoglie dati ne ha bisogno, e «non raccogliamo nulla» non è un’informativa: deve comunque identificare l’app e lo sviluppatore, indicare un contatto per la privacy e descrivere come vengono trattati e conservati gli eventuali dati che tocca. Norme sui dati utente

Sicurezza dei dati

Ogni app sul canale di test chiuso, test aperto o produzione compila il modulo Sicurezza dei dati. Le app che restano sempre e solo sul canale di test interno sono esentate, il che è un motivo concreto per usare presto il test interno. Anche un’app che non raccoglie nulla compila il modulo e lo dichiara. Sicurezza dei dati

Dichiara che cosa raccoglie e condivide davvero la tua app, compreso ciò che fanno i tuoi SDK per tuo conto. È la parte sbagliata più spesso: un SDK di analytics, di annunci o di segnalazione dei crash raccoglie dati che tu abbia scritto quel codice o no, e la dichiarazione è tua. Leggi la documentazione di ogni singolo SDK, invece di dare per scontato che un intero fornitore si comporti in un solo modo.

Eliminazione di account e dati

Se gli utenti possono creare un account nella tua app, devi permettere loro di richiederne l’eliminazione sia dall’interno dell’app sia dall’esterno, tramite un URL web pubblicamente raggiungibile, e l’eliminazione dell’account deve eliminare i dati associati. Se una legge o un motivo aziendale legittimo ti impone di conservare qualcosa, dichiaralo.

Tutto il resto in Contenuti dell’app

Oltre a privacy, Sicurezza dei dati, eliminazione e Accesso all’app visti sopra, restano queste. Due traggono in inganno perché il nome suona condizionale: le dichiarazioni App per la salute e Funzionalità finanziarie sono obbligatorie per una normale app pubblica sul canale di test chiuso, test aperto o produzione anche quando non ha né le une né le altre funzionalità. Entrambe prevedono una risposta per l’assenza di funzionalità, e compilarne una non ti fa ricadere sotto le regole di licenza mediche o finanziarie. Dichiarazione App per la saluteDichiarazione Funzionalità finanziarie

Google Play Console · screenshot reale

Dai ai revisori un accesso che funziona

Se una parte qualsiasi della tua app sta dietro un accesso o un’altra barriera, compila Accesso all’app. Play Console supporta fino a cinque set di istruzioni: set di istruzioni, non necessariamente cinque set di credenziali, il che conta se hai un solo login e più percorsi protetti. Preparare l’app per la revisione

Prima di inviare, controlla che le credenziali funzionino ancora e che ogni funzione protetta sia raggiungibile da qualcuno che non sei tu. Account scaduti, codici monouso che arrivano sul tuo telefono e funzioni che si sbloccano solo per un account interno sono gli inciampi tipici.

Completato quando: Contenuti dell’app non mostra attività in sospeso e una persona diversa da te riesce ad accedere esattamente con quello che hai scritto in Accesso all’app.

Dichiarazioni specifiche per categoria

Oltre ai moduli qui sopra, alcune norme dipendono da ciò che l’app fa davvero. Queste sono condizionali sul serio:

• App per la salute, oltre alla dichiarazione. Se l’app ha davvero funzionalità per la salute, le norme Contenuti e servizi per la salute aggiungono l’etichettatura da dispositivo medico e l’obbligo di disclaimer per le app sanitarie non regolamentate, e le app per la salute dei tipi indicati richiedono un account dell’organizzazione. Contenuti e servizi per la salute
• App di IA generativa. Impedisci gli output vietati e dai agli utenti un modo, dentro l’app, per segnalarli. Qui si parla di ciò che l’app produce: è cosa distinta dalle dichiarazioni sulle risorse dello Store viste sopra e non è una regola per cui ogni app che si avvale dell’IA debba portare un’etichetta. Norme sui contenuti generati dall’IA
• Autorizzazioni per foto e video. Richiedi l’accesso ampio solo dove serve a una funzione centrale; altrimenti usa il selettore di foto di sistema.
• Posizione e contatti. Entrambe hanno requisiti di ambito minimo in arrivo, con date precise e un ambito ristretto: vedi scadenze e modifiche condizionali.
• Altre categorie. Notizie e riviste, servizi finanziari, app governative e altre hanno ciascuna una pagina di norme collegata da Contenuti dell’app.

6. Completa il test chiuso richiesto, se ti riguarda

Si applica a: gli account sviluppatore personali creati dopo il 13 novembre 2023. Gli account dell’organizzazione e gli account personali creati prima di quella data non hanno affatto questo requisito: se è il tuo caso, salta all’invio della release.

La regola è breve: esegui un test chiuso con almeno 12 tester attivati nei 14 giorni continuativi che precedono la tua domanda di accesso alla produzione. La riduzione da 20 a 12 tester è entrata in vigore l’11 dicembre 2024 e ha mantenuto gli stessi 14 giorni. Requisiti di testLa modifica da 20 a 12

Google Play Console · screenshot reale

Tre canali, e ne conta uno solo

Il test interno sembra la scorciatoia ovvia ed è davvero utile, ma non per questo.

Google valuta due cose: il numero di tester e il loro engagement. Tra i suoi stessi esempi di motivi per chiedere altri test ci sono i tester che non hanno interagito con l’app durante il test, quindi 12 nomi in un elenco non sono il requisito. Quello che Google non pubblica è una qualsiasi regola su minuti al giorno o sessioni: se hai letto una cifra giornaliera precisa, non viene da Google, e il tuo test non va pianificato su quella.

Come soddisfarlo davvero

Ogni altro requisito di questa guida è burocrazia o lavoro tecnico che controlli tu. Questo richiede 12 persone reali, su dispositivi Android reali, che si attivino e restino attivate per 14 giorni ininterrotti.

Completato quando: Play Console mostra 12 o più tester attivati e il test chiuso in corso da almeno 14 giorni continuativi, e l’azione «Richiedi l’accesso alla produzione» diventa disponibile nella Dashboard.

7. Richiedi l’accesso alla produzione, se ti riguarda

Si applica a: gli stessi account del test chiuso, cioè gli account personali creati dopo il 13 novembre 2023. Tutti gli altri passano direttamente alla release.

Soddisfare i criteri del test chiuso non ti porta in produzione da solo. Fai domanda dalla dashboard di Play Console e rispondi a un questionario. Viene spesso descritto come un modulo fisso di dieci domande; Google ne cambia la formulazione nel tempo, quindi tienilo a mente come tre argomenti anziché come un elenco fisso.

Scrivi le risposte partendo dal test che hai davvero eseguito. Nessuna formulazione garantisce l’approvazione; quello che aiuta sono i dettagli concreti su test reali e modifiche reali. Le risposte generiche sono una via nota per sentirsi chiedere altri test. Gli esempi svolti servono a mostrarti come descrivere il tuo test, non a darti un copione.

Google dice che questa revisione richiede di solito sette giorni o meno, ma che a volte può richiedere di più: pianifica sette giorni, senza considerarli un tetto massimo. Tempi di revisione per l’accesso alla produzione Se l’accesso viene negato, l’esito abituale è una richiesta di altri test più che un rifiuto, e il tuo test chiuso non deve fermarsi mentre ti prepari a ripresentare la domanda. Che cosa fare dopo un «servono altri test».

Completato quando: Play Console mostra l’accesso alla produzione come concesso. Niente di ciò che viene prima, né una checklist completa né 14 giorni interi, è la concessione in sé: la decisione è di Google.

8. Invia e pubblica la release di produzione

L’accesso alla produzione, dove serve, sblocca il canale: non pubblica nulla. La release è una sequenza a sé, ed è il punto in cui ci si ritrova con tutto completo e niente online. Preparare e distribuire una release

1. Paesi e regioni Parti stretto e allarga più avanti, se vuoi.
2. Prezzi Da impostare prima della prima release. Un’app gratuita non può poi diventare a pagamento con lo stesso nome del package.
3. Aggiungi il bundle della release Seleziona un bundle idoneo che hai già caricato per il test, oppure carica una nuova build con un codice versione più alto. Portare nella release di produzione un artefatto già testato non richiede di per sé di ricompilarlo.
4. Nome della release e note di rilascio Il nome è interno; le note sono ciò che gli utenti vedono per questa versione.
5. Leggi errori e avvisi La Console blocca sugli errori e lascia passare gli avvisi. Leggi entrambi: spesso è l’avviso a contare più avanti.
6. Invia le modifiche per la revisione Finché non lo fai, non hai inviato niente. Una pagina della release finita ma con modifiche mai inviate è uno dei modi più silenziosi in cui un lancio si blocca.
7. Seguila fino a revisione e pubblicazione In revisione, pronta per la pubblicazione e online sono tre stati diversi. Se la pubblicazione gestita è disponibile e attiva, le modifiche approvate restano in attesa finché non selezioni «Pubblica modifiche»: l’approvazione da sola non è pubblicazione. La scheda può poi metterci un po’ a comparire.

Completato quando: La panoramica sulla pubblicazione non mostra modifiche non inviate e la release di produzione risulta online, non semplicemente approvata. Dove si applica la pubblicazione gestita, quell’ultimo passo tocca a te. Pubblicazione gestita e stati di pubblicazione

Quanto tempo richiede pubblicare e che cosa può sovrapporsi

Vicino al traguardo ci sono due revisioni, ed è bene tenerle distinte: la revisione dell’accesso alla produzione dopo il tuo questionario e la revisione della release vera e propria. Google dice che la revisione dell’accesso richiede di solito sette giorni o meno, ma può richiedere di più, e che anche la revisione dell’app può superare i sette giorni in casi eccezionali. Nessuna delle due ha un tetto di una settimana. Tempi di revisione e pubblicazione Numeri fase per fase: la guida ai tempi di revisione.

Che cosa blocca davvero che cosa

Quasi tutto si può affrontare in qualsiasi ordine. Quattro cose no, e sapere quali sono è la differenza tra un lancio di tre settimane e uno di sei.

Una stima di pianificazione, dichiarata come tale

Da tre a cinque settimane o più è una previsione ragionevole per un nuovo account personale. È la nostra stima di pianificazione, non un livello di servizio di Google, e presuppone un’app già sostanzialmente sviluppata, tester che si attivano in fretta e nessuna rilavorazione importante. Lo sviluppo dell’app non è compreso nel numero, e un giro di rilavorazione lo allunga.

Che cosa ti sta dicendo la Console e dove si risolve

Quasi ogni blocco si presenta come uno di sei messaggi. Leggi quale ti è capitato, invece di reinviare e sperare.

La tua checklist di preparazione, per la fase in cui sei

Indica che account hai e a che cosa stai lavorando. Separa tre cose che la checklist tipica confonde: ciò che ti serve adesso, ciò che sarà richiesto più avanti e ciò che non ti riguarda affatto. È uno strumento di controllo per te: non vede la tua Play Console e completarla non è un’approvazione.

Scadenze attuali e modifiche condizionali alle norme

Queste sono le voci con una data che possono cambiare che cosa costruisci o quando pubblichi. Quasi nessuna riguarderà la tua app: leggi la terza colonna prima di agire su una qualsiasi di esse.

Requisiti permanenti senza una data di scadenza

In vigore adesso e assenti da qualsiasi elenco di «novità»: è per questo che colgono di sorpresa chi ha imparato questa procedura uno o due anni fa.

• Test chiuso: 12 tester, 14 giorni continuativi, per gli account personali creati dopo il 13 novembre 2023. Il numero è sceso da 20 a 12 l’11 dicembre 2024.
• I trasferimenti di titolarità dell’account passano dalla procedura di trasferimento di Play Console. Il trasferimento diretto del titolare riguarda le organizzazioni e gli account personali che non monetizzano; un account personale che monetizza segue un percorso diverso, con un nuovo account e il trasferimento delle app. Comprare, affittare o vendere account tramite terzi è vietato. Trasferimento della titolarità
• Gli account dell’organizzazione sono obbligatori per le app di servizi finanziari indicate, per quelle per la salute, per le app VpnService approvate e per quelle governative.
• Le autorizzazioni per foto e video sono già applicate. Accesso ampio solo dove serve a una funzione centrale; altrimenti il selettore di foto di sistema.

PolicyBytes: aggiornamenti delle norme di aprile 2026

Il team Developer Experience di Google parla delle norme su contatti e trasferimento degli account e degli aggiornamenti su posizione e contenuti con limiti di età visti sopra. Facoltativo; la tabella ha la versione operativa.

YouTube

Come ti aiuta PrimeTestLab con il test chiuso

Sette delle otto tappe sono burocrazia e lavoro tecnico che controlli tu. Una richiede 12 persone reali, su dispositivi Android reali, attivate e davvero attive per 14 giorni ininterrotti: è il passaggio su cui si bloccano gli sviluppatori singoli, ed è l’unica parte di cui ci occupiamo noi.

Tu condividi il link di attivazione del tuo test chiuso. Noi gestiamo l’invito, la conferma dell’attivazione, il monitoraggio quotidiano dell’engagement e la copertura completa dei 14 giorni, sostituendo chi abbandona. Qualsiasi lingua dell’app, targeting flessibile per paese.

I pacchetti attuali

Garanzia di rimborso · Avvio tipico del test: da 4 a 6 ore · Nessun abbonamento

Domande frequenti

Che cosa fare adesso

Da dove viene ogni requisito

Ogni affermazione rilevante qui sopra collega la propria fonte nel punto in cui compare; questa è la versione a elenco. Le pagine di assistenza di Google sono in gran parte senza data, quindi la data di modifica di una pagina non dimostra da quando una norma è in vigore.

Che cosa è cambiato in questa revisione

11 settembre 2026

Ricostruito sulla documentazione di Google verificata l’8 settembre, poi rivisto di nuovo dopo un secondo audit di quella ricostruzione. Corretti: il requisito sul livello API target (ora una matrice per tipo di dispositivo); l’ordine dei prerequisiti del test chiuso; la conversione da account personale a account dell’organizzazione; i tempi del D-U-N-S; l’ambito della scadenza di registrazione del 30 settembre 2026 e il percorso per rispettarla, che è un controllo di stato in Play Console dopo che l’app esiste; contatti e posizione spostati al 27 gennaio 2027 per le app con target API 37+, con implementazione e dichiarazione cumulative; le specifiche di icona, screenshot e video promozionale; l’accesso per i revisori come cinque set di istruzioni; l’ID applicazione come proprietà della build e non del record in Console; e la meccanica della release, con il riuso di un bundle idoneo già testato e il fatto che l’approvazione non è pubblicazione dove si applica la pubblicazione gestita. Aggiunti: la verifica del dispositivo, le tappe di creazione dell’app e della release, i controlli preliminari su codice nativo e Play Billing, le dichiarazioni IA sulle risorse dello Store, le dichiarazioni App per la salute e Funzionalità finanziarie (obbligatorie anche senza quelle funzionalità), una tabella dei blocchi e una fonte accanto a ogni affermazione rilevante. Rimossi perché non supportati: la data del 28 gennaio 2026 per la migrazione delle app per la salute, il mito dei «cinque giorni» sulla verifica dell’identità, la spiegazione dell’ID sviluppatore Android di aprile 2025, il limite di 1 MB per l’immagine in evidenza e la classifica del «rifiuto evitabile numero 1». La checklist di preparazione è stata ricostruita due volte: ora separa «richiesto più avanti» da «non ti riguarda» e non considera più completato il lavoro solo inviato.

24 giugno 2026

Prima pubblicazione.