Verifica sviluppatore Android 2026: date e passaggi

Quasi tutto quello che è stato scritto sulla verifica sviluppatore Android nel 2025 oggi è sbagliato in almeno un punto importante, e lo è anche una quantità sorprendente di quanto è stato scritto a inizio 2026. Il disegno del programma è cambiato dopo l’annuncio originale, la data esatta di applicazione è arrivata solo a giugno 2026 e l’ambito è stato ristretto nero su bianco il 22 luglio 2026. Intanto la domanda che gli sviluppatori digitano davvero nella ricerca non è "che cos’è la verifica sviluppatore?". È: Google dice che non ha funzionato, che cosa c’è di sbagliato esattamente, adesso che succede e non l’avevo già fatto?

Per questo l’articolo è scritto come una risposta a un incidente, non come un commento sulle policy. Risponde prima alla domanda "l’ho già fatto?", ti dà il percorso preciso dentro Play Console invece di consigli vaghi, separa i due livelli di applicazione che ogni altra pagina fonde in un’unica frase spaventosa ed è esplicito sui punti in cui Google non ha pubblicato nulla. Traccia anche una linea netta tra la verifica e il requisito separato del test chiuso con 12 tester, perché quella confusione arriva nella casella di PrimeTestLab quasi ogni settimana. Ogni data e ogni cifra qui sotto sono state controllate sulle pagine di Google il 9 agosto 2026.

La verifica sviluppatore Android sono due compiti, non uno

Se pubblichi su Google Play, la verifica sviluppatore Android ti chiede due cose distinte: verificare la tua identità e registrare i nomi pacchetto delle tue app. Quasi tutti gli sviluppatori Play già attivi hanno soddisfatto la prima e, nella stragrande maggioranza dei casi, la seconda è avvenuta in automatico. Per molti account il lavoro che resta è controllare due schermate, anche se Google non pubblica nessun tempo di completamento valido per tutti e un problema sui documenti o sull’account può richiedere molto più tempo.

Che cosa stabilisce davvero ciascuna porta

I due compiti rispondono a due domande diverse, e superarne uno non dice a Google niente sull’altro. Tenerli separati è la cosa di maggior valore che puoi portarti via da questa pagina, perché i modi in cui falliscono, le soluzioni e persino le schermate di Play Console sono diversi.

Un account può quindi avere l’identità completamente verificata e avere lo stesso un pacchetto non registrato fermo in silenzio nell’elenco. È proprio questa combinazione a saltare fuori il giorno della scadenza, perché lo sviluppatore ha guardato la schermata che dice "verificato" e non ha mai aperto quella che elenca le app.

La risposta di un minuto per chi ha già Play Console

Se pubblichi già su Google Play, ecco tutto il percorso di conformità nell’ordine in cui va controllato. Quasi tutti i lettori si fermano al secondo passaggio.

1. 01

   Conferma lo stato della tua identità

   Apri Account sviluppatore in Play Console. La guida Google alla verifica descrive il percorso come Impostazioni › Account sviluppatore, mentre la documentazione più recente sulla gestione dell’account usa Account sviluppatore › Informazioni su di te. In ogni caso Google afferma che, se hai già completato con successo la verifica dell’identità, non dovrai rifare quel passaggio. Verificato

2. 02

   Conferma che ogni pacchetto sia registrato

   Apri la pagina Verifica sviluppatore Android in Play Console e guarda lo stato di registrazione di ogni app. Anche la home di Play Console può mostrare informazioni sulla registrazione delle app. Se tutti i tuoi nomi pacchetto sono stati registrati automaticamente, Google dice che per quelle app non serve nessun altro intervento di registrazione. Verificato

3. 03

   Rivendica quello che resta prima del 30 settembre

   Per un pacchetto che non è stato registrato automaticamente, segui la registrazione manuale di Google. La forma che assume dipende dal nome pacchetto: un nome che Android non ha mai visto richiede solo i dati del pacchetto e il tuo certificato pubblico di firma, mentre un nome che ha già installazioni richiede un APK di verifica firmato che dimostri il possesso della chiave privata. Entrambi i percorsi sono nella sezione 05.

Se pubblichi su Google Play, usa Play Console

È la trappola che manda gli sviluppatori in una deviazione da un’ora. In questo programma ci sono due console. Play Console è dove gli sviluppatori Google Play completano entrambi i compiti. L'Android Developer Console è una superficie separata per chi distribuisce fuori da Google Play, e le sue pagine di assistenza descrivono un percorso diverso, che comprende la verifica del sito dell’organizzazione tramite Google Search Console. Le due serie di istruzioni si posizionano sulle stesse ricerche.

Quattro rotte di distribuzione, quattro risposte. Trova la tua riga prima di leggere un’altra parola della documentazione di Google, perché la riga sbagliata ti costa un pomeriggio:

Mappatura delle rotte dalla guida di verifica per Play Console e dalla guida alla distribuzione limitata di Google, consultate il 13 agosto 2026. Verificato

La cronologia della verifica nel 2026, e l’unica data che gli articoli continuano a sbagliare

La verifica non è arrivata con un solo annuncio. È arrivata con cinque, ognuno dei quali ha ristretto o corretto il precedente. La cronologia qui sotto prende come fonte di riferimento il materiale Google di giugno e luglio 2026, e la cosa conta perché la previsione di marzo, quella più citata, è stata superata.

Come è arrivato davvero il programma, tappa per tappa

Ogni voce mette accanto quello che Google ha pubblicato e quello che uno sviluppatore Play dovrebbe ricavarne, perché diverse di queste date vengono citate isolate altrove e si leggono in modo molto diverso quando si vede la sequenza intera.

1. Novembre 2025

   Apre l’accesso anticipato

   Gli sviluppatori invitati all’accesso anticipato potevano iniziare a verificare le app distribuite fuori da Google Play.

   Cosa ricavarne: è solo una tappa storica. Qui non nasce nessun obbligo per uno sviluppatore Play di oggi.

2. 30 marzo 2026

   Inizia la distribuzione a tutti gli sviluppatori

   Google ha annunciato che stava iniziando a distribuire la verifica sviluppatore Android a tutti gli sviluppatori, sia in Play Console sia nell’Android Developer Console, e ha detto agli sviluppatori Play di aspettarsi l’accesso nelle settimane successive. Verificato

   Cosa ricavarne: non leggerlo come "ogni account Play ha ricevuto la verifica il 30 marzo". Le parole di Google dicono che la distribuzione è iniziata quel giorno.

3. Giugno 2026

   Arriva il servizio di sistema Android Developer Verifier

   La cronologia aggiornata di Google colloca a giugno 2026 la distribuzione del servizio di sistema di verifica. Verificato

   Cosa ricavarne: usa giugno. Il post del 30 marzo prevedeva aprile, e diversi articoli di terzi ancora online ripetono quella previsione come se fosse storia.

4. 18 giugno 2026

   Arriva la data esatta dell’applicazione

   Google ha annunciato il 30 settembre 2026 come prima data di applicazione, ha elencato i sette store partecipanti e ha detto che oltre il 99% delle app degli sviluppatori Play era già registrato. Verificato

   Cosa ricavarne: è la fonte singola più solida sia per la data sia per la cifra della registrazione automatica. Tutto ciò che è stato pubblicato prima tira a indovinare sulla data.

5. Luglio 2026

   Strumenti: ID Status API e Console API

   L’Android Developer ID Status API è stata distribuita in tutto il mondo, con la Console API e la distribuzione limitata in accesso anticipato.

   Cosa ricavarne: riguarda i team che si occupano di automazione e strumenti, non chi pubblica per la prima volta lavorando a mano dentro Play Console.

6. 15 luglio 2026

   Vengono pubblicate le guide attuali

   La guida generale alla verifica e quella per Play Console sono state aggiornate, con l’ambito iniziale degli store e le istruzioni per la registrazione dei pacchetti Play. Verificato

   Cosa ricavarne: considera queste due pagine come la documentazione attuale di riferimento per qualunque cosa operativa.

7. 22 luglio 2026

   Le FAQ restringono l’ambito nero su bianco

   Le FAQ di Google hanno chiarito che gli store fuori dall’elenco dei partecipanti e l’installazione diretta non rientrano nella fase del 30 settembre. Verificato

   Cosa ricavarne: è la frase che manda in pensione la lettura del 2025, quella del "Google chiude l’installazione diretta in quella data". È il limite di una prima fase, non un’esenzione permanente.

8. Agosto 2026

   Programmato per la disponibilità globale: distribuzione limitata e flusso avanzato

   La pagina di verifica di Google elenca gli account a distribuzione limitata, l’API dell’Android Developer Console e il flusso di installazione avanzato tra i lanci di agosto 2026. Al 13 agosto 2026 la sua guida dedicata alla distribuzione limitata dice ancora che le iscrizioni all’accesso anticipato sono chiuse e che altre informazioni arriveranno ad agosto 2026, perciò questa riga è disegnata come programmata, non consegnata. Parziale, lancio non confermato

   Cosa dedurne: è la voce che si muove più in fretta in questa pagina, e il fatto che il calendario sia entrato in agosto non dimostra che sia uscita. Controlla la pagina di verifica di Google per lo stato attuale invece di fidarti di un articolo pubblicato a metà mese, questo compreso.

9. 30 settembre 2026

   Nello stesso giorno succedono due cose

   La registrazione delle app diventa obbligatoria per le installazioni tramite i sette store partecipanti in Brasile, Indonesia, Singapore e Thailandia. Separatamente, per i requisiti di Play Console, tutti i pacchetti Play devono essere registrati, e Google dice che le app non registrate verranno rimosse da Google Play. Verificato

   Cosa ricavarne: una data, due conseguenze indipendenti. La sezione 03 le separa come si deve.

10. 2027 e oltre

    Estensione mondiale, data non annunciata

    Google dice che le protezioni si estenderanno a tutto il mondo nel 2027. Al 9 agosto 2026 non è stata annunciata nessuna data mondiale precisa né nessun altro calendario per Paese. Verificato

    Cosa ricavarne: considera qualunque scadenza "1 gennaio 2027" o "inizio 2027" che leggi altrove come una previsione. Google non ne ha pubblicata nessuna.

Il 30 settembre 2026 è una scadenza mondiale?

No per l’applicazione a livello di dispositivo, sì per la scadenza di registrazione dei pacchetti su Google Play. Sono due regole diverse che per caso condividono una data, e quasi ogni articolo su questo programma le fonde. La regola sul dispositivo parte in quattro Paesi tramite sette store. La regola Play riguarda la tua scheda su Play, e Google descrive la conseguenza di mancarla come rimozione mondiale da Google Play.

I quattro Paesi e i sette store

Google elenca entrambe le liste in modo preciso, quindi non serve interpretare niente. La prima fase di applicazione copre le installazioni di app in questi quattro Paesi:

E vale per le installazioni tramite questi sette store partecipanti:

Entrambi gli elenchi sono ripresi dall’annuncio Google del 18 giugno 2026 e dalla guida alla verifica del 15 luglio 2026, consultati il 9 agosto 2026. Google può aggiungere store o regioni, quindi ricontrolla la fonte prima di agire su questo elenco a ridosso della data.

Il 30 settembre riguarda anche te? Risolvi il tuo canale

Rispondi a due domande e lo strumento qui sotto applica entrambi i livelli al tuo canale di distribuzione. È volutamente diretto sui casi in cui la risposta di Google è "non ancora", perché "non ancora" non vuol dire "mai".

Come controllare se sei già verificato

Due schermate rispondono a tutta la domanda. Account sviluppatore contiene la tua identità e i dati dell’account. La pagina Verifica sviluppatore Android contiene lo stato di registrazione di ogni app. Se apri solo la prima, puoi superare un controllo che in realtà non hai superato.

I quattro punti in cui può comparire uno stato

Dallo stato all’azione, senza inventare etichette

Google pubblica dove guardare e cosa fare. Non pubblica un glossario esaustivo delle etichette di stato dell’identità su Play, quindi questo articolo non se lo inventa. La tabella qui sotto è organizzata per che cosa stai controllando e com’è fatto quando è a posto, che è la parte che Google documenta davvero.

Percorsi e definizioni di "a posto" dalla guida di Play Console risposta 16984799, dalla guida Google alla verifica in Play Console e dalla pagina di assistenza sulle informazioni dell’account sviluppatore; la riga sul test chiuso dalla guida di Play Console risposta 14151465. Tutte consultate il 9 agosto 2026. Le voci di navigazione qui sono date in italiano perché Play Console è localizzato: la tua console potrebbe mostrare parole leggermente diverse, e le pagine di Google usano oggi due formulazioni diverse per il percorso dell’identità. La navigazione di Play Console cambia spesso, quindi considera ogni percorso come valido al momento della verifica, non come definitivo.

Cosa vuol dire davvero "registrato automaticamente"

La registrazione automatica riguarda un rapporto molto stretto: il legame tra il nome pacchetto di un’app e le credenziali di firma che dimostrano chi la controlla. Google dice che le app idonee che usano Play App Signing rientrano nel processo di registrazione automatica, perché Google ha già le informazioni di titolarità e di firma che le servono.

Se tutti i tuoi nomi pacchetto sono stati registrati automaticamente con successo, Google dice che per le app Play corrispondenti non serve nessun altro intervento di registrazione. Quella frase fa esattamente il lavoro che dichiara e niente di più.

È l’ultimo punto quello su cui vale la pena fermarsi. La registrazione vale per pacchetto, quindi un account con sei app può essere a quattro sesti e non mostrare niente di allarmante da nessuna parte, tranne che nell’unica pagina che le elenca. Google inquadra inoltre la verifica come la conferma di chi è lo sviluppatore e la descrive come cosa distinta dai controlli di sicurezza applicati ai contenuti dell’app, quindi niente di tutto questo dice se la tua app rispetta le policy di Play.

Cosa fare quando un’app non è stata registrata automaticamente

La registrazione manuale ha due forme, e quale ti tocchi dipende dal nome pacchetto, non da te. Per un nome pacchetto che Android non ha mai visto, fornisci i dati del pacchetto e il certificato pubblico della tua chiave di firma. Per un nome pacchetto che ha già installazioni, dimostri inoltre di possedere la chiave privata corrispondente caricando un APK che contiene una stringa fornita da Google. Solo il secondo caso richiede un APK di verifica firmato, e nessuno dei due richiede il tuo vero APK di produzione.

Prima capisci in quale caso ti trovi

Cinque righe, e oggi appartieni esattamente a una. Sbagliare qui è l’errore più costoso di questa sezione, perché la strada dell’APK di verifica è lavoro di compilazione e tre di queste righe non ne hanno alcun bisogno.

Distinzione dei casi dalla guida di Play Console, "Registering Android package names" (risposta 16761053), consultata il 13 agosto 2026. Verificato

A. Registrare un nome pacchetto nuovo

Il percorso breve. Tutto avviene dentro Play Console, niente sfiora il tuo ambiente di compilazione e non c’è alcun APK da produrre.

1. 01

   Apri la pagina Verifica sviluppatore Android

   In Play Console, apri la pagina Verifica sviluppatore Android e controlla lo stato di registrazione di ogni nome pacchetto dell’account. Anche la home di Play Console può mostrare informazioni di registrazione delle app.

2. 02

   Scegli Registra nome pacchetto

   Questo avvia una registrazione nuova invece di una richiesta su un nome già esistente.

3. 03

   Inserisci il nome pacchetto e un nome descrittivo

   Il nome descrittivo è un’etichetta interna per il tuo elenco. Non è quello che gli utenti vedono sulla tua scheda dello Store.

4. 04

   Scegli Aggiungi chiave

   Qui inizia l’associazione tra una chiave di firma che controlli e il nome pacchetto che stai registrando.

5. 05

   Fornisci il certificato pubblico di firma

   Consegna il certificato pubblico della coppia di chiavi di firma della tua app. Poiché Android non ha mai visto questo nome pacchetto, il certificato è tutto ciò che serve a Google. La tua chiave privata non lascia mai la tua macchina.

6. 06

   Invia e attendi la conferma

   Google invia un’email quando il nome pacchetto è registrato correttamente, e lo stato aggiornato diventa visibile in Play Console.

B. Registrare un nome pacchetto esistente

È il percorso lungo, quello che ogni articolo descrive come se fosse l’unico. Si applica quando il nome pacchetto ha già installazioni su Android, perché in quel caso Google non ti crede sulla parola: devi dimostrare il controllo della chiave privata. Due di questi passaggi avvengono fuori da Play Console, quindi tieni aperto l’ambiente di compilazione prima di iniziare.

1. 01

   Inserisci i dati del pacchetto

   Nella pagina Verifica sviluppatore Android, avvia la registrazione del nome pacchetto che stai rivendicando.

2. 02

   Apri Seleziona chiave

   Google propone i certificati che considera idonei per quel nome pacchetto, sulla base delle prove di installazione.

3. 03

   Scegli un’impronta di certificato pubblico idonea

   Prendi l’impronta della chiave che possiedi davvero. Se non compare nulla di idoneo, fermati qui e leggi le regole di idoneità più sotto prima di tentare altro.

4. 04

   Avvia il flusso di proprietà e copia la stringa di Google

   Google genera una stringa unica per questa richiesta. Copiala esattamente. È il valore che dimostra che l’APK che stai per compilare è stato fatto per questa verifica specifica.

5. 05

   Crea assets/adi-registration.properties

   Nella cartella assets di un progetto APK, crea un file chiamato esattamente adi-registration.properties. Il percorso e il nome del file sono entrambi letterali. Un errore di battitura qui è il modo più comune in cui questo passaggio fallisce.

6. 06

   Incolla la stringa in quel file

   Non serve altro dentro. Il file esiste solo per trasportare la stringa.

7. 07

   Compila un APK di release

   Google dice che puoi compilarlo dall’applicazione reale oppure da un progetto vuoto che usa lo stesso nome pacchetto. Il progetto vuoto di solito è più rapido e più sicuro, perché non è coinvolto nulla del tuo codice di produzione.

8. 08

   Firmalo con la chiave privata corrispondente

   È tutto il senso dell’operazione. La prova è la firma, non il contenuto.

9. 09

   Caricalo tramite Play Console

   Carica l’APK di verifica firmato dentro il flusso di proprietà. Non è una release, non raggiunge alcun utente e il tuo artefatto di produzione resta fuori.

10. 10

    Tieni d’occhio lo stato e l’email di conferma

    Google invia un’email quando il nome pacchetto è registrato correttamente, e lo stato aggiornato diventa visibile in Play Console.

C. Se la tua chiave di firma è in mano a un altro store

Alcuni store firmano al posto dello sviluppatore, quindi non puoi produrre da solo un APK di verifica firmato correttamente. Google documenta un percorso apposito, ed è breve:

1. 01

   Compila la release e caricala su quello store

   Fai passare la build che contiene la stringa attraverso il normale processo di pubblicazione di quella piattaforma.

2. 02

   Scarica da quello store l’APK finale firmato

   Ti serve l’artefatto così come lo ha firmato lo store, non quello che hai caricato tu.

3. 03

   Carica su Play Console quell’APK firmato dallo store

   È la firma dello store a soddisfare il controllo di proprietà.

Passaggi del flusso dalla guida di Play Console, "Registering Android package names" (risposta 16761053), consultata il 13 agosto 2026. Verificato

Aggiungere altre chiavi in seguito

Un nome pacchetto può avere più di una chiave di firma associata. Google dice che la console permette di aggiungere e verificare più chiavi di firma per un singolo pacchetto, e la procedura ricalca il percorso B: creare assets/adi-registration.properties con la stringa di quella chiave, compilare e firmare un APK di release con la chiave privata corrispondente, poi caricarlo. Prima registra il nome pacchetto, poi aggiungi le chiavi extra.

Se non viene proposta nessuna chiave idonea: le regole di priorità

La maggior parte degli sviluppatori non lo vede mai. Conta quando un nome pacchetto è stato firmato da più chiavi nel corso della sua vita, o quando più parti hanno una rivendicazione plausibile. Google lo risolve con una gerarchia basata sulle installazioni.

Gerarchia di idoneità dalla guida di Play Console risposta 16761053, consultata il 13 agosto 2026. Verificato

La lettura pratica, detta con precisione: se la tua chiave di firma soddisfa chiaramente la gerarchia qui sopra, dovrebbe comparire come direttamente idonea per la richiesta. Questo decide se Google ti lascia registrare direttamente invece di passare da una richiesta esaminata. Non completa la registrazione al posto tuo. Un pacchetto rimasto fuori dalla registrazione automatica deve comunque passare dal percorso B, a mano. Il livello in ordine di arrivo è quello su cui muoversi in fretta, perché si decide su chi agisce e non su chi ha ragione.

Cosa devono inviare gli account sviluppatore personali

Due livelli: le informazioni valide ovunque e i documenti che dipendono dal Paese. La parte valida ovunque è che i tuoi dati identificativi legali e il tuo indirizzo devono coincidere esattamente con il profilo Google Payments collegato all’account. La parte sui documenti dipende interamente dal Paese o dalla regione indicati in quel profilo, ed è per questo che nessun articolo onesto può darti una sola checklist valida in tutto il mondo.

La parte uguale ovunque

Gli account personali forniscono i dati identificativi legali e le informazioni dell’account, e l’attuale guida di Play elenca tra questi il nome legale e l’indirizzo legale. Il processo di verifica usa il profilo Google Payments collegato, e la pagina Google sui requisiti dei documenti afferma che i dati identificativi personali, il nome dell’organizzazione dove serve e le informazioni sull’indirizzo devono coincidere esattamente con quelli del tuo profilo pagamenti.

Quella parola, "esattamente", è ciò che regge tutta questa sezione, ed è il motivo per cui esiste lo strumento che segue.

La parte che cambia da Paese a Paese

La pagina di Google dice che i documenti accettati dipendono dalla tua posizione geografica. Il selettore di Paese su quella pagina è l’autorità per il tuo caso, non un elenco riprodotto altrove. Per rendere concreta la forma del requisito senza far finta che valga ovunque, ecco cosa chiede oggi la pagina Google per gli Stati Uniti a chi si presenta come persona fisica:

I requisiti sull’immagine che Google dichiara apertamente

Valgono per il documento con foto e non lasciano spazio a interpretazioni, il che li rende i fallimenti più economici da eliminare prima di caricare qualunque cosa:

• Il documento con foto rilasciato dalle autorità deve essere valido e non scaduto.
• L’immagine deve essere a colori.
• L’immagine deve essere nitida e ben illuminata.
• L’immagine non deve essere una fotocopia.

Google afferma inoltre che la sua attuale pagina sui requisiti dei documenti indica i documenti non accettati come motivo principale dei fallimenti nella verifica sviluppatore, e che documenti falsi o modificati possono portare a provvedimenti severi, compresa la rimozione dell’account e delle app. Niente in questa pagina vale il rischio.

Il controllo da fare prima di caricare qualsiasi cosa

Google non pubblica quanti tentativi di verifica hai a disposizione, e gli sviluppatori raccontano regolarmente di arrivare a uno stato in cui il comando per riprovare semplicemente non si vede più. Questa combinazione rende un invio fatto con leggerezza davvero costoso. Fai prima questa verifica.

L’errore da controllare prima di caricare qualunque cosa

Se da questo articolo porti via una sola istruzione, porta via questa: apri il tuo profilo Google Payments e confronta nome legale e indirizzo con i tuoi documenti, campo per campo, prima di toccare il pulsante di caricamento. Google richiede che le informazioni corrispondano; non pubblica una regola sul singolo carattere o sulla punteggiatura, quindi considera il "campo per campo" come il modo pratico di soddisfare il requisito, non come una regola a sé.

La prima metà è il requisito dichiarato da Google. La seconda metà è quello di cui sono pieni i forum di assistenza del 2026. Le discussioni di aprile, giugno, luglio e agosto 2026 hanno tutte la stessa forma: uno sviluppatore è sicuro che i documenti siano corretti, la verifica non riesce senza un motivo preciso e la comunità rimanda a una discordanza tra l’identità inviata e il profilo pagamenti. In diverse di quelle discussioni lo sviluppatore ha scoperto il problema sul nome nel profilo solo dopo un ricorso non andato a buon fine.

Cosa serve agli account dell’organizzazione

Le organizzazioni si verificano con i dati legali dell’organizzazione invece che con un’identità personale, e in genere hanno bisogno di un numero D-U-N-S: un identificativo unico di nove cifre rilasciato da Dun and Bradstreet. La documentazione Play di Google indica delle eccezioni per certi enti pubblici. Google dice che chi non lo ha può ottenerlo gratuitamente, ma avverte che possono volerci settimane, e questo lo rende l’unico elemento della pagina con dei tempi di attesa reali. Le pagine di Google non concordano su quante: le FAQ sulla verifica Android dicono fino a 28 giorni e l’attuale guida account di Play Console dice fino a 30. Questo articolo pianifica su 30.

Cos’altro prepara un’organizzazione

• I dati legali dell’organizzazione che coincidono con i tuoi documenti di registrazione, più il rappresentante autorizzato e le informazioni dell’account.
• Il numero D-U-N-S di nove cifre, gratuito da ottenere presso Dun and Bradstreet e soggetto alle eccezioni dichiarate da Google per certi enti pubblici. Sono eccezioni strette: non vogliono dire che gli enti pubblici saltano la verifica.
• La documentazione dell’organizzazione pertinente e i documenti identificativi del rappresentante, seguendo le stesse regole di coincidenza esatta e di specificità per Paese che valgono per gli account personali.
• Un sito verificato, se sei un’organizzazione che distribuisce interamente fuori da Google Play. La guida Google alla verifica dice che le organizzazioni forniscono un sito che deve essere verificato tramite Google Search Console. Quel passaggio appartiene al percorso dell’Android Developer Console, non a Play Console.

Una cosa che un account dell’organizzazione non cambia: se pubblichi anche su Google Play, il lavoro resta dentro Play Console. E se stai valutando personale contro organizzazione per un account nuovo, i vantaggi e gli svantaggi vanno ben oltre la verifica: è una decisione che il confronto tra account personale e account dell’organizzazione affronta per bene.

Cosa succede davvero se al 30 settembre non sei verificato

Quattro cose diverse, a seconda di come la tua app arriva agli utenti. Google documenta limitazioni sulle nuove installazioni, sugli aggiornamenti dove i controlli sono in vigore e la rimozione da Google Play per i pacchetti Play non registrati. Non documenta la disinstallazione forzata delle app già presenti sui telefoni delle persone.

Conseguenze dalla guida di Play Console risposta 16984799, dalla guida Google alla verifica in Play Console, dal post del 30 marzo sull’avvio della distribuzione, dalla cronologia nella guida dell’Android Developer Console e dalle FAQ del 22 luglio. Tutte consultate il 9 agosto 2026.

L’affermazione da maneggiare con più cura

Non è pignoleria. Cambia quello che devi fare questo mese. Una rimozione da Play è un’emergenza di distribuzione che si risolve registrando un pacchetto. Un’ipotetica disinstallazione di massa sarebbe un’emergenza di rapporto con i clienti, e richiederebbe una comunicazione completamente diversa. Solo una delle due è documentata.

Come funziona davvero il flusso avanzato

Google documenta il flusso avanzato come un percorso lento di proposito, non come un interruttore, e l’attrito è proprio il punto: ogni passaggio esiste per impedire che qualcuno te lo detti al telefono mentre la chiamata è ancora aperta.

1. 01

   Attiva la modalità sviluppatore nelle impostazioni di sistema

   Un primo gesto deliberato, così niente qui si innesca per sbaglio o con una scorciatoia a un tocco come nelle truffe.

2. 02

   Conferma che nessuno ti sta guidando

   Un controllo rapido che nessuno ti stia spingendo a disattivare una protezione.

3. 03

   Riavvia il telefono e autenticati di nuovo

   Questo taglia l’accesso remoto o una chiamata in corso che qualcuno potrebbe usare per seguire quello che fai dopo.

4. 04

   Torna dopo il periodo di attesa protettivo

   Google lo descrive come un’attesa di un giorno, una sola volta. Poi confermi con autenticazione biometrica o con il PIN del dispositivo.

5. 05

   Installa da sviluppatori non verificati

   Puoi consentirlo per sette giorni o a tempo indeterminato. L’avviso continua a comparire a ogni installazione e sei tu a confermarlo.

Passaggi del flusso avanzato dalle FAQ di Google sulla verifica sviluppatore Android, consultate il 13 agosto 2026. Verificato

La questione dell’installazione diretta, in un paragrafo

La fase del 30 settembre non si applica ancora all’installazione diretta né agli app store fuori dall’elenco dei partecipanti di Google, e Google continua a supportare l’installazione via ADB oltre a un flusso avanzato per gli utenti che scelgono consapevolmente di installare da sviluppatori non verificati. È la posizione attuale e documentata al 9 agosto 2026, ed è sostanzialmente diversa dalla lettura del "Google chiude l’installazione diretta" che circolava dopo l’annuncio originale del 2025. È anche dichiaratamente una prima fase, quindi considerarla un esito acquisito sarebbe l’errore speculare. Se quello che ti ha portato qui sono le conseguenze per l’installazione diretta e per un ecosistema aperto, e non una scadenza Play, merita una trattazione a sé e non un paragrafo dentro un articolo sulla conformità.

La verifica non sostituisce il test chiuso con 12 tester

Sono due requisiti che non c’entrano niente l’uno con l’altro e che vanno soddisfatti entrambi quando ti riguardano entrambi. La verifica sviluppatore Android risponde a "di chi sono questo account e questo pacchetto?". La regola sull’accesso in produzione risponde a "quest’app è stata provata da persone vere?". Puoi superare perfettamente l’uno e restare completamente bloccato dall’altro.

Il requisito di Google per gli account sviluppatore personali nuovi che vi rientrano non è cambiato di una virgola per via del programma di verifica: almeno 12 tester che hanno attivato il test in modo continuativo per i 14 giorni precedenti al momento in cui richiedi l’accesso in produzione.

Colonne sulla verifica dalla guida Google alla verifica e dalla guida di Play Console risposta 16984799; colonne sul test chiuso dalla guida di Play Console risposta 14151465 e dalla pagina di assistenza sul test interno. Tutte consultate il 9 agosto 2026. Verificato

Perché ci si casca

Perché si chiamano entrambi "requisiti", stanno entrambi in Play Console ed entrambi si frappongono tra uno sviluppatore e un’app pubblicata. Così un account che ha appena superato la verifica dell’identità si sente arrivato. Poi l’accesso in produzione viene rifiutato e nelle schermate della verifica non c’è niente che spieghi perché, perché non è lì che vive quella risposta.

La sequenza che porta davvero online un account personale nuovo è: identità verificata, ogni pacchetto registrato e, a parte, un test chiuso con almeno 12 tester che hanno attivato il test in modo continuativo per 14 giorni prima di chiedere l’accesso in produzione. La regola dei 14 giorni continuativi ha più casi limite di quanti quasi tutti si aspettino, ed è la parte di questa sequenza che non si comprime lavorando di più.

Il test interno vale come alternativa?

No, e vale la pena essere precisi sul perché, perché anche "il test interno è inutile" è sbagliato. Google permette il test interno con fino a 100 tester ed è un modo davvero valido per trovare in fretta i problemi. Ma il requisito per l’accesso in produzione nomina espressamente un test chiuso che soddisfi la condizione dei 12 tester per 14 giorni. Il test interno è un canale separato, quindi parteciparvi non è il test valido per questo preciso requisito.

Anche gli account dell’organizzazione meritano qui una frase di chiarimento: il requisito di test per l’accesso in produzione è scritto espressamente per gli account sviluppatore personali nuovi, quindi gli account dell’organizzazione non sono la categoria coperta da questa specifica regola dei 12 tester. È una questione distinta dalla verifica, che invece riguarda entrambi i tipi di account.

Se la verifica non è riuscita, controlla queste cose prima di riprovare

Gli sviluppatori raccontano spesso di messaggi di rifiuto che non dicono niente di preciso, e Google non documenta la causa di ogni singolo rifiuto. Quindi la mossa utile non è tirare a indovinare sul messaggio ma passare in rassegna i requisiti che Google pubblica davvero. Scegli qui sotto il sintomo che stai vedendo. Ognuno apre la prima cosa da controllare, quanto è solida la prova dietro quel consiglio e l’azione sicura da fare dopo.

Parti dal sintomo che vedi davvero

Le dieci voci qui sotto sono scritte come le scrivono gli sviluppatori nei forum di assistenza di Google, comprese quelle scritte alle due di notte. Sceglierne una ti dà il controllo di maggior valore per quel sintomo, invece di un elenco di tutto ciò che in teoria potrebbe non andare.

Cosa sostengono le prove e cosa no

Gli schemi di fallimento qui sotto vengono dalle discussioni della Google Play Developer Help Community nel corso del 2026, compresi casi da Brasile, India, Uzbekistan e diverse discussioni in portoghese, più segnalazioni più vecchie su Reddit e Stack Overflow. Sono raggruppati in base a quanto è solida la prova, perché è questo a cambiare cosa devi farne.

La checklist prima della scadenza

Cinque stati decidono se il 30 settembre sarà una data sul tuo calendario o un problema nella tua casella di posta. Quattro valgono per ogni sviluppatore Play. Il quinto vale solo se il tuo account è soggetto alla regola del test chiuso, ed è quello che consuma tempo di calendario vero.

I quattro punti da chiudere

Spuntali con onestà, non con ottimismo. Ogni riga rimanda alla sezione che la risolve, quindi una casella non spuntata è una deviazione di due minuti, non un vicolo cieco. Due sono condizionali, quindi sono scritti in modo da poter essere spuntati quando non ti hanno mai riguardato: chi ha avuto tutte le app registrate in automatico non ha nessuna richiesta manuale da chiudere, e chi era già verificato senza alcuna contestazione sui documenti non ha nulla da correggere.

Dove si inserisce PrimeTestLab, e dove no

Prima chiariamo il confine: nessuno può verificare la tua identità al posto tuo. Caricare i documenti, allineare il profilo pagamenti e rivendicare i nomi pacchetto sono cose che può fare solo chi possiede l’account, e questo articolo è tutto il nostro contributo su quel fronte. Quello di cui ci occupiamo è il requisito che arriva subito dopo la verifica per un account personale nuovo: i 12 tester reali, con il test attivo per 14 giorni consecutivi.

È il bivio che ci arriva in casella sempre nella stessa forma. Uno sviluppatore supera la verifica dell’identità, vede il verde in Play Console, dà per scontato che la strada sia aperta, e poi scopre che l’accesso in produzione è una porta completamente diversa con due settimane di minimo attaccate. La verifica è burocrazia, e quanto dura dipende dai tuoi documenti e dal tuo account. Il test chiuso è tempo di calendario che non si comprime.

Gestire il test chiuso da solo oppure affidarlo

L’ordine che costa meno tempo

Se hai davanti sia la verifica sia il test chiuso, portali avanti in parallelo, non uno dopo l’altro. I 14 giorni di attivazione continuativa dei tester sono tempo reale che parte solo quando hai davvero 12 persone iscritte, quindi è la voce che decide la tua vera data di lancio. Fai partire quel conteggio mentre sbrighi i documenti, non dopo.

Domande frequenti

In sintesi

Ultimo controllo delle policy: 13 agosto 2026. La distribuzione Google del 30 settembre e l’estensione del 2027 sono ancora in movimento, quindi date e Paesi coperti vanno ricontrollati sulla pagina Google della verifica sviluppatore Android prima di agire. Questo articolo è programmato per una nuova verifica il 30 settembre 2026 e subito dopo l’inizio dell’applicazione, e di nuovo ogni volta che Google pubblicherà una data o un’area geografica per il 2027.