Risposta rapida
Al 13 agosto 2026 i tester possono ancora installare un APK grezzo che condividi direttamente con loro. L’entrata in vigore decisa da Google per il 30 settembre 2026 in Brasile, Indonesia, Singapore e Thailandia riguarda inizialmente solo sette app store partecipanti, e le FAQ di Google del 15 luglio dicono che le installazioni dirette non sono ancora coperte. Google prevede di estendere i controlli ai dispositivi certificati con Android 7 o superiore nel 2027, senza aver annunciato una data esatta. Quando entrerà in vigore, le app registrate a nome di uno sviluppatore verificato mantengono il consueto percorso di installazione, mentre le app non registrate restano installabili tramite ADB o tramite il flusso avanzato di Google. Firebase App Distribution resta utile per il QA, ma non esegue la verifica degli sviluppatori Android e non vale come test chiuso (closed testing) di Google Play, che richiede 12 tester attivati per 14 giorni consecutivi.
Come questo post classifica ogni affermazione
- Verificato significa che l’affermazione arriva direttamente da una pagina attuale di Google, Android o Firebase. La maggior parte del post è verificata. Verificato
- Parziale significa che le fonti primarie sostengono la conclusione ma serve un passaggio di deduzione, oppure che le pagine di Google non trattano quel caso limite. Parziale
- Segnalato dalla comunità significa resoconti ripetuti di sviluppatori su Stack Overflow, Reddit o sui forum di Google. Utile per la diagnosi, non per la policy. Comunità
- Non documentato significa che Google non ha pubblicato nulla su quello scenario preciso, e noi lo diciamo invece di tirare a indovinare. Non documentato
La storia che si è diffusa nel 2025 era semplice: Android sta mettendo fine all’installazione diretta. La posizione che Google documenta davvero ad agosto 2026 è più circoscritta, più precisa e molto meno utile come titolo. Google ha precisato e affinato a giugno e luglio 2026 l’ambito della prima fase e il 15 luglio 2026 ha messo per iscritto quella restrizione in una sola frase: la scadenza del 30 settembre "si applica solo agli specifici store partecipanti". Buona parte della copertura del 2025 e dell’inizio 2026 ancora in circolazione è stata pubblicata prima che quella frase esistesse e descrive un primo rollout più ampio di quello che Google sta effettivamente applicando.
Per questo il post è organizzato attorno alla decisione che devi davvero prendere, e non attorno alla polemica. Hai dodici amici, colleghi o tester e una build da mettere sui loro telefoni. Puoi ancora mandare l’APK via email? Ti serve ADB? Firebase App Distribution basta? E la domanda che arriva quasi ogni settimana nella casella di PrimeTestLab: qualcuna di queste cose conta per il test chiuso da 12 tester che Google richiede prima dell’accesso in produzione? Ogni data, cifra e meccanismo qui sotto è stato verificato sulle pagine di Google il 13 agosto 2026 e, dove Google non ha pubblicato nulla, il post segnala il vuoto invece di riempirlo.
I tester possono ancora installare il tuo APK dopo il 30 settembre 2026?
Sì. Con le regole attuali di Google, un tester può ancora installare un APK che gli mandi direttamente dopo il 30 settembre 2026. La data è reale, i quattro Paesi sono reali e l’entrata in vigore è reale, ma le FAQ attuali di Google dicono che la scadenza "si applica solo agli specifici store partecipanti". Per un’installazione diretta, le stesse FAQ dicono che "non si applica ancora alla tua app".
Le parole esatte di Google, frase per frase
La scadenza "si applica solo agli specifici store partecipanti" · per un’installazione diretta "non si applica ancora alla tua app" · l’entrata in vigore riguarda i "dispositivi Android certificati con Android 7 o superiore" · Google "estenderà il requisito di verifica Android a livello mondiale" nel 2027
I frammenti sono citati singolarmente dalle FAQ sulla verifica degli sviluppatori Android (aggiornate al 10 agosto 2026) e dall’annuncio del 18 giugno 2026, entrambi consultati il 13 agosto 2026 e in originale inglese. Verificato
Cosa tocca il 30 settembre e cosa no
Tre righe risolvono la questione per quasi tutti i lettori. Quella centrale è la riga che si discosta da buona parte della copertura precedente su questa data.
Interessato dal 30 settembre 2026
Installare tramite uno dei sette store partecipanti in Brasile, Indonesia, Singapore o ThailandiaL’app deve essere registrata a nome di uno sviluppatore verificato perché l’installazione ordinaria vada a buon fine. Google afferma che la parte fuori dal Play di questa prima fase regionale riguarda i formati smartphone e tablet.
Non ancora coperto dalla prima fase
Un APK diretto: via email, scaricato dal tuo sito, condiviso su Drive o installato via ADBLe FAQ di Google del 15 luglio dicono che la scadenza del 30 settembre non si applica ancora all’installazione diretta. Anche gli app store fuori dall’elenco dei partecipanti restano fuori da questa prima fase. La parola che regge entrambe le frasi è ancora. Un APK di Firebase App Distribution dovrebbe ereditare la stessa risposta, perché è distribuzione diretta di un APK firmato, ma Google non ha pubblicato alcuna decisione specifica su Firebase. Parziale, deduzione
Invariato in ogni caso
Le regole di pubblicazione di Google PlayIl Play, per parte sua, richiede che ogni pacchetto pubblicato lì sia registrato, e il test chiuso da 12 tester per i nuovi account personali interessati non è toccato da niente di tutto questo. La verifica non lo accorcia, non lo elimina e non lo sostituisce.
Ambito dalle FAQ sulla verifica degli sviluppatori Android (aggiornamento del 10 agosto 2026) e dall’annuncio del 18 giugno 2026 che indica la data, i quattro Paesi e i sette store. Il requisito di test chiuso del Play viene dalla risposta 14151465 della Guida di Play Console. Tutto consultato il 13 agosto 2026.
Perché questa non è una scappatoia
"Non ancora coperto" descrive una fase di rilascio, non un’esenzione permanente, e prenderla per un’esenzione è l’immagine speculare dell’errore che questo post sta correggendo. Google ha detto che il requisito si estende a livello mondiale nel 2027. La reazione giusta a questa sezione è sollievo per settembre e preparazione per l’anno dopo, ed è esattamente a questo che serve la checklist verso la fine. Verificato
Cosa cambia davvero il 30 settembre 2026
Google ha fissato la data il 18 giugno 2026 e poi ne ha ristretto l’ambito per iscritto il 15 luglio. Dal 30 settembre, un’installazione tramite uno dei sette store indicati nei quattro Paesi elencati viene controllata: l’app deve essere registrata a nome di uno sviluppatore verificato. Le FAQ attuali di Google dicono che questa prima fase riguarda gli store partecipanti indicati e che l’installazione diretta e gli store non partecipanti non sono ancora coperti.
Se pubblichi su Google Play
Registra ogni pacchetto rimasto entro il 30 settembre 2026. La guida di Google per Play Console dice di registrare tutte le app che vuoi continuare a distribuire per "evitare la rimozione globale da Google Play". Questo obbligo è globale. Non ha nulla a che vedere con i quattro Paesi e vale anche se nessuno dei tuoi utenti vive lì.
Cosa vivono gli utenti il 30 settembre
L’applicazione lato dispositivo parte solo in quattro Paesi. Il primo controllo all’installazione riguarda i sette store partecipanti in Brasile, Indonesia, Singapore e Thailandia. Non tocca né il sideload diretto né gli store fuori da quell’elenco.
Sono due obblighi distinti del 30 settembre, e confonderli è il modo più comune di fraintendere questa data. La registrazione dei pacchetti su Play è globale e decide se la tua scheda resta online; l’applicazione all’installazione è regionale e decide cosa succede sul telefono di un utente. Verificato
I sette store partecipanti
Chiamali per nome, con precisione. Descrivere tutto questo come una restrizione a tutti gli app store è troppo ampio rispetto a come Google descrive oggi la prima fase: secondo l’elenco che Google ha pubblicato, uno store che non è nominato qui resta fuori dal rilascio del 30 settembre.
| Azienda | Store partecipante | Controllato dal 30/09 nei quattro Paesi? |
|---|---|---|
| Google Play | Sì | |
| HONOR | HONOR App Market | Sì |
| OPlus | OPPO App Market | Sì |
| Samsung | Galaxy Store | Sì |
| Transsion | Palm Store | Sì |
| vivo | V-Appstore | Sì |
| Xiaomi | GetApps | Sì |
| Tu, direttamente | Email, link di download, il tuo sito, Drive e, per deduzione, un APK tramite Firebase App Distribution | No, non ancora |
| Chiunque altro | Qualsiasi app store non nominato sopra | No, non ancora |
Elenco degli store e Paesi dall’annuncio di Google del 18 giugno 2026; l’esclusione dell’installazione diretta e degli store non partecipanti dalle FAQ sulla verifica aggiornate al 10 agosto 2026. Consultati il 13 agosto 2026. Verificato
I quattro Paesi e i formati di dispositivo al loro interno
Due dettagli restringono ancora il quadro e vale la pena portarseli dietro. Per la distribuzione fuori da Google Play, le FAQ sulla verifica di Google affermano che l’entrata in vigore nelle aree selezionate riguarda inizialmente i formati smartphone e tablet. Le stesse FAQ dicono che le protezioni arrivano tramite Google Play services sui dispositivi Android certificati con Android 7 o superiore, che è l’ambito finale dei dispositivi e non un limite valido solo a settembre.
Cosa non cambia a settembre
L’elenco qui sotto è corto, ma copre il modo in cui la maggior parte dei piccoli team sposta davvero una build. Niente di tutto questo è toccato dalla fase del 30 settembre.
È un’installazione diretta. Non coperta dalla prima fase.
Anche questa è un’installazione diretta, con la stessa risposta.
Distribuzione diretta di un APK firmato ai tester invitati. Il quadro completo è nella sezione 08. Google non pubblica alcuna decisione specifica su Firebase: è quindi una deduzione dalla regola del sideload diretto, non un’esenzione dichiarata. Parziale, deduzione
Google dice che non ci sono modifiche al funzionamento di ADB. Sezione 05.
Fuori dalla prima fase, secondo la stessa risposta delle FAQ.
È un requisito del Play a sé stante, ed è mondiale. Google ha detto il 18 giugno 2026 che oltre il 99% delle app degli sviluppatori del Play era già stato registrato automaticamente.
Il dato del 99% ha una data precisa
Il numero di oltre il 99% di registrazione automatica viene dall’aggiornamento di Google del 18 giugno 2026. Alcuni materiali ripetono ancora un vecchio dato di circa il 98%. Usa il numero più recente e citalo con la sua data, non come un fatto senza tempo, perché Google aggiorna le statistiche di adozione man mano che il rilascio prosegue. La pagina di panoramica attuale di Google sulla verifica degli sviluppatori arrotonda ora la stessa cifra a 99%, quindi cita l'una o l'altra con fonte e data invece che come una costante esatta. Verificato
Cosa succede quando la verifica si estende a livello mondiale nel 2027
Google dice che il requisito si estende a livello mondiale dal 2027 in poi, alle app sui dispositivi Android certificati con Android 7 o superiore, tramite Google Play services. Non ha annunciato una data mondiale esatta né un calendario Paese per Paese. Considera non ufficiale qualsiasi data specifica del 2027 finché Google non la pubblica.
La cronologia, con l’effetto di ogni data su un APK condiviso
-
30 marzo 2026
La verifica inizia a raggiungere tutti gli sviluppatori
Google ha iniziato a distribuire la verifica degli sviluppatori Android a tutti gli sviluppatori in Play Console e nell’Android Developer Console.
APK grezzo Nessun cambiamento visibile all’installazione solo per questa data. App non verificata Resta installabile secondo il comportamento attuale di Android. -
Agosto 2026
Il flusso avanzato e gli account limited distribution diventano mondiali
Google ha programmato il lancio mondiale del flusso avanzato di installazione e degli account limited distribution per questo mese. Al 13 agosto 2026 le fonti esaminate indicano il mese ma non un giorno esatto, e non dimostrano che il flusso sia già arrivato a tutti gli utenti. Parziale
APK grezzo Resta disponibile. App non verificata Il flusso avanzato è il meccanismo pensato per preservarne l’installazione. -
30 settembre 2026
Inizia l’obbligo di registrazione in sette store, quattro Paesi
Le installazioni tramite Google Play, HONOR App Market, OPPO App Market, Samsung Galaxy Store, Transsion Palm Store, vivo V-Appstore e Xiaomi GetApps in Brasile, Indonesia, Singapore e Thailandia richiedono che l’app sia registrata a nome di uno sviluppatore verificato. Verificato
APK grezzo Non ancora coperto da questa fase iniziale. App non verificata Un’installazione da store partecipante può essere limitata; in questa fase il percorso diretto resta intatto. -
Dal 2027 in poi
Espansione mondiale ai dispositivi Android certificati
La verifica si estende in tutto il mondo per le app sui dispositivi Android certificati con Android 7 o superiore. È la fase in cui cambia la risposta sull’installazione diretta. Verificato
APK grezzo App registrata: il percorso di installazione normale. App non registrata: flusso avanzato o ADB, secondo il modello annunciato. App non verificata Flusso avanzato o ADB restano il percorso annunciato. -
Data esatta nel 2027
Non annunciata al 13 agosto 2026
Il calendario pubblicato da Google dice 2027 e oltre, e niente di più preciso. Non è stata diffusa nemmeno una sequenza di Paesi. Non documentato
APK grezzo Non fare piani su un giorno specifico. App non verificata Non fare piani su un giorno specifico.
Cronologia dal post di lancio di Google del 30 marzo 2026, dall’annuncio del 18 giugno 2026 e dalle FAQ sulla verifica degli sviluppatori Android aggiornate al 10 agosto 2026. Consultati il 13 agosto 2026.
La scadenza che non esiste
"1º gennaio 2027" compare nella copertura secondaria e nelle risposte degli assistenti IA. Non è in nessuna fonte Google esaminata per questo post. Google si è impegnata sul 2027 e oltre senza indicare un giorno. Se un tuo piano dipende dal conoscere quella data, la risposta onesta è che fuori da Google nessuno la conosce ancora, e la protezione pratica è avere i pacchetti registrati ben prima dell’inizio dell’anno. Non documentato
APK verificato o non verificato: cosa controlla davvero Android
"Sono verificato?", presa da sola, è la domanda sbagliata. La verifica degli sviluppatori Android crea quello che Google chiama un collegamento formale e verificabile tra l’identità di uno sviluppatore, il nome del pacchetto di un’app e la chiave o le chiavi di firma di quel pacchetto. La verifica dell’identità è un anello di quella catena, non la catena intera.
La catena, anello per anello
Chi sei, confermato una volta tramite Play Console o l’Android Developer Console.
Una volta per accountL’identificatore dell’app, per esempio com.example.app, registrato a quell’identità verificata.
La proprietà si dimostra inviando un APK firmato con la tua chiave privata. La Console consente di aggiungere e verificare più chiavi per uno stesso pacchetto.
Per chiave, non per buildDove la catena è completa, Google dice che l’esperienza di installazione abituale degli utenti resterà invariata quando l’obbligo più ampio entrerà in vigore.
Il risultato che vuoiCatena descritta nelle guide di Google sulla verifica degli sviluppatori Android, compresa la descrizione della prova di proprietà, e nel supporto a più chiavi di firma documentato nelle FAQ sulla verifica. Consultate il 13 agosto 2026. Verificato
Google è esplicito nel dire che l’installazione diretta è fondamentale per Android e che gli sviluppatori verificati possono continuare a distribuire direttamente. La sfumatura che quella frase nasconde è che un’installazione senza intoppi dipende dal fatto che l’app sia registrata, non semplicemente dall’aver superato un controllo di identità. Per questo il post dice ogni volta "registrata a nome di uno sviluppatore verificato" invece del più breve e vago "app verificata".
E se usi una chiave di debug o una chiave di firma separata per il QA?
È qui che i team di QA veri inciampano, perché è del tutto normale consegnare ai tester interni una build firmata con la chiave di debug e allo store una build firmata con la chiave di rilascio. Sono certificati diversi sullo stesso nome di pacchetto.
Controllo delle chiavi di firma, quattro domande
- Quale certificato firma davvero l’APK che i tuoi utenti installano? È quello da registrare. Con Play App Signing la chiave di firma dell’app firma l’APK installato da Google Play, mentre la chiave di caricamento autentica solo l’artefatto che carichi su Play e non è automaticamente il certificato della versione installata. Una chiave di debug, CI, QA o di caricamento conta per la distribuzione diretta solo se firma l’APK che consegni ai tester.
- Quelle rilevanti sono registrate sul pacchetto? Google consente di aggiungere e verificare più chiavi di firma per uno stesso nome di pacchetto, quindi non sei costretto a far convergere tutto su un’unica chiave.
- Non dare per scontato che la verifica dell’identità copra ogni chiave. Superare il passaggio sull’identità non copre in automatico ogni certificato che hai mai usato.
- Due APK con lo stesso nome di pacchetto ma firme diverse non sono intercambiabili. È il normale comportamento della firma delle app Android ed è molto precedente alla verifica, ma è facile scambiarlo per un problema di verifica dello sviluppatore. Vedi la sezione 12.
Cinque casi limite a cui Google ha davvero risposto
Queste cinque domande tornano di continuo e hanno tutte una risposta pubblicata, quindi non serve tirare a indovinare.
Domande di perimetro con risposta documentata
- Android 6 o precedenti? Fuori dal perimetro dichiarato. Google dice che l’applicazione riguarda i dispositivi Android certificati con Android 7 o superiore, tramite i servizi Google Play. Verificato
- Dispositivi non certificati o ROM personalizzate senza servizi Google Play? Google descrive questa applicazione per i dispositivi Android certificati, tramite i servizi Play. Non generalizzare la regola a ogni ROM personalizzata o dispositivo non certificato: restano fuori dal meccanismo che Google documenta. Non documentato per quei dispositivi
- App aziendali su dispositivi gestiti? Le app distribuite tramite lo store della tua organizzazione verso dispositivi gestiti non devono completare la verifica, perché il tuo amministratore IT le ha già validate. Google consiglia comunque di registrarle, nel caso l’app venga installata anche da un’altra fonte o su un dispositivo non gestito. Verificato
- Dove controllo se un pacchetto è registrato? Sviluppatori Play: la pagina di verifica degli sviluppatori Android in Play Console, che mostra lo stato accanto a ogni app. Sviluppatori fuori da Play: la scheda Nomi pacchetto nella Android Developer Console, con Registrato, Non registrato o Bozza. Anche Android Studio Panda 4 e versioni successive mostrano lo stato quando generi un APK o un App Bundle firmato. Verificato
- Gli sviluppatori fuori da Play pagano 25 dollari? L’account Android Developer Console a distribuzione completa costa 25 dollari. L’account a distribuzione limitata è gratuito, non richiede un documento d’identità e si ferma a 20 dispositivi autorizzati. Se pubblichi già su Google Play gestisci la verifica in Play Console invece di aprire un account separato. Verifica prima la disponibilità: al 13 agosto 2026 l’accesso anticipato era ancora chiuso. Disponibilità parziale
Anche Firebase richiede la firma, ma per un altro motivo
Firebase App Distribution richiede che un APK sia firmato con una chiave di debug o con una chiave di firma dell’app prima di distribuirlo. È un requisito di Firebase sulla validità della build, non un passaggio della verifica degli sviluppatori Android. I due sistemi usano entrambi la parola "registrare", e tenerli distinti è essenziale in tutto questo argomento. La sezione 08 li separa. Verificato
La distinzione tra chiave di caricamento e chiave di firma spiega anche il ticket Firebase più comune. Una copia della tua app installata da Play può essere firmata con la chiave di firma di Google Play, mentre l’APK Firebase che dai allo stesso tester è firmato in locale con una chiave di caricamento, di release o di debug. Android non può installare l’uno sopra l’altro se le identità di firma accettate non coincidono, quindi il tester vede un errore che sembra un problema di verifica e non lo è. Verificato
ADB resta consentito, ma è un flusso da sviluppatori
L’impegno più chiaro di Google in tutto questo programma, dalle sue FAQ sulla verifica: non ci sono modifiche al funzionamento di ADB. Sviluppatori e utenti esperti possono continuare a installare le app in quel modo, e il periodo di attesa di 24 ore del flusso avanzato non si applica alle installazioni via ADB. È il percorso tecnico più duraturo di questo post, e anche il meno adatto ai tester comuni.
Va bene per
- Te, sul tuo dispositivo, tutto il giorno
- Un team tecnico di QA che ha già Android Studio installato
- Pipeline di CI e device farm
- Installare una build non registrata senza aspettare il ritardo di un giorno del flusso avanzato
- Un collega seduto accanto a te con un cavo USB
Non va bene per
- Dodici amici, familiari o tester reclutati
- Chiunque non riesca a seguire le opzioni sviluppatore al telefono con te
- Tester da remoto in altri Paesi, senza cavo e senza computer
- Iterazioni rapide: ogni nuova build richiede accesso al dispositivo e un altro comando di installazione, anche se il tester non rifà tutta la configurazione
- Tutto ciò che vuoi che Google Play conteggi. Le installazioni via ADB sono invisibili ai requisiti di test del Play
Cosa deve fare prima un tester
La documentazione degli strumenti di Google è netta sul prerequisito: per usare ADB via USB devi attivare il debug USB nelle opzioni sviluppatore del dispositivo. Su un telefono moderno significa trovare il numero di build, toccarlo sette volte per sbloccare le opzioni sviluppatore e poi attivare il debug USB in una schermata di impostazioni che mostra un avviso. È un percorso praticabile per un tester tecnico e pesante per chi si è offerto per provare la tua app.
La configurazione non si ripete a ogni build, ed è il dettaglio che quasi tutti gli articoli sbagliano. Una volta che il tester ha autorizzato la tua workstation, quell’autorizzazione resta finché non la revoca o non dimentica il dispositivo. Una nuova build costa quindi un altro adb install -r e l’accesso al telefono, non un altro giro nelle opzioni sviluppatore. Android 11 e versioni successive supportano anche il debug wireless: il tester associa il telefono alla workstation una volta sola con un codice QR o un codice di associazione, poi installi via rete finché entrambi i dispositivi sono sulla stessa rete, senza cavo. Elimina il cavo, non il prerequisito tecnico.
I tre comandi che coprono quasi tutte le installazioni dei tester. Qui non c’è niente di nuovo nel 2026: è il flusso che Google dice essere invariato.
adb devicesadb install app-release.apkadb install -r app-release.apkQuello che sorprende: -r funziona solo quando il nuovo APK è firmato con lo stesso certificato di quello installato. Una build firmata con un’altra chiave va disinstallata prima, e così se ne vanno anche i dati dell’app. È il normale comportamento della firma delle app Android, non una regola della verifica.
Usa ADB come piano B, non come piano
Nel modello annunciato da Google, ADB è una via di riserva documentata per installare app non verificate, anche durante il rilascio più ampio previsto. È il percorso che continua a funzionare quando una build non è registrata e il tester non ha voglia di aspettare un giorno intero. Vale comunque la pena ricontrollare la policy prima di appoggiarsi a quel presupposto nel 2027. Quello che non è: un modo per coinvolgere dodici persone comuni, e non soddisferà mai il requisito di test per l’accesso in produzione di Google Play. Verificato
Che cos’è il flusso avanzato di Android per le app non verificate?
Google ha creato un percorso deliberato per chi vuole comunque installare un’app di uno sviluppatore non verificato. È una configurazione una tantum con un passaggio di attrito nel mezzo: attivare la modalità sviluppatore, confermare che nessuno ti sta guidando, riavviare, aspettare un giorno, autenticarsi e poi consentire le installazioni non verificate per 7 giorni o a tempo indeterminato. L’attesa di 24 ore fa parte di quella configurazione, non è un ritardo prima di ogni APK.
-
01
Attivare la modalità sviluppatore
L’utente attiva la modalità sviluppatore o l’impostazione equivalente sul proprio dispositivo.
Google: impedisce attivazioni accidentali e i bypass con un tocco usati nelle truffe sotto pressione -
02
Confermare che nessuno lo sta guidando
L’utente conferma che nessun’altra persona lo sta accompagnando in questa modifica di sicurezza.
Google: una verifica rapida che nessuno ti stia convincendo a disattivare la sicurezza -
03
Riavviare e accedere di nuovo
Il dispositivo si riavvia e l’utente accede nuovamente.
Google: interrompe l’accesso remoto o la chiamata in corso con cui un truffatore ti osserva -
04
Aspettare 24 ore, una volta sola
Google lo descrive come un’attesa di un giorno, una volta sola. Avviene durante la configurazione, ed è il passaggio che tutti raccontano male.
Non 24 ore prima di ogni APK. Una volta, per account. -
05
Verificare l’identità sul dispositivo
L’utente conferma la modifica con il riconoscimento biometrico o il PIN del dispositivo.
Google: biometria o PIN confermano che è il proprietario del dispositivo a fare la modifica -
06
Consentire le installazioni non verificate per 7 giorni o a tempo indeterminato
Configurazione completata. L’utente sceglie la durata e da lì in poi può superare l’avviso sullo sviluppatore non verificato durante l’installazione.
La sua scelta, il suo rischio, il suo dispositivo
Sequenza, formulazione e opzioni di durata dalle FAQ di Google sulla verifica degli sviluppatori Android, consultate il 13 agosto 2026. Google pubblica una motivazione per ogni passaggio di questo flusso, quindi le note qui sopra riportano la sua spiegazione invece di dedurla. Verificato
Tre cose che si sbagliano spesso
"Quindi ogni installazione richiede un’attesa di 24 ore?"
No. Google descrive un’attesa di un giorno, una volta sola, dentro la configurazione. Dopo, l’utente sceglie 7 giorni o tempo indeterminato per quanto tempo restano consentite le installazioni non verificate.
"Devono rifarlo su ogni telefono nuovo?"
Google dice di no. Le FAQ descrivono la configurazione come una volta per account, e si trasferisce sul nuovo dispositivo.
"Anche ADB richiede l’attesa?"
No. Google afferma esplicitamente che il periodo di attesa di 24 ore non si applica alle installazioni via ADB. Sezione 05.
Le opzioni sviluppatore non devono restare attive
Un tester può disattivare di nuovo le opzioni sviluppatore una volta abilitato il flusso avanzato. Le FAQ di Google lo dicono chiaramente: non serve tenere attive le opzioni sviluppatore, perché una volta fatta la modifica sul dispositivo l’impostazione resta attiva. Conta per i tester le cui app bancarie o aziendali protestano se le opzioni sviluppatore restano accese. Google aggiunge che la configurazione si fa una volta per account e si trasferisce a un nuovo dispositivo, quindi non si ripete per ogni app o per ogni telefono. Verificato
È già attivo adesso?
Situazione onesta al 13 agosto 2026
Google ha programmato il lancio del flusso avanzato a livello mondiale ad agosto 2026. Le fonti esaminate per questo post indicano il mese ma non un giorno esatto, e nessuna dimostra che il flusso sia già arrivato a tutti gli utenti. Quindi la cosa corretta da dire oggi a un tester è che il percorso esiste ed è programmato, non che potrà sicuramente usarlo questo pomeriggio. Controlla le pagine di verifica di Google prima di costruirci sopra uno script di assistenza. Parziale
La lettura pratica per uno sviluppatore: il flusso avanzato è una risposta reale e documentata a "un utente può ancora installare la mia app non verificata?" e una pessima risposta a "come porto una build a dodici tester questa settimana?". Un ritardo di sicurezza di un giorno in mezzo all’onboarding aggiunge attrito vero per i tester occasionali o da remoto. Se i tuoi tester sono utenti comuni, i percorsi che rispettano il loro tempo sono messi a confronto nella sezione 09.
Cosa succede agli APK già installati?
La documentazione di Google copre l’installazione e l’aggiornamento. Quando l’obbligo entrerà in vigore, un’app non registrata non può essere installata né aggiornata normalmente, e Google dice che un aggiornamento ordinario "non andrà a buon fine" senza il flusso avanzato o ADB. Quello che la documentazione esaminata non dice è che le copie già presenti sui telefoni delle persone vengano rimosse o che ne venga bloccato l’avvio.
| Situazione quando vale l’obbligo più ampio | Risultato documentato | Evidenza |
|---|---|---|
| L’app è già installata e l’utente la apre e basta | La documentazione di Google che abbiamo esaminato non annuncia rimozioni forzate né blocchi all’avvio. Parla di installazione e di aggiornamenti. | Parziale |
| Un utente prova a installare un’app non registrata nel modo normale | L’installazione normale viene limitata. | Verificato |
| L’utente ha attivato il flusso avanzato | L’app non registrata può essere installata. | Verificato |
| L’installazione passa da ADB | L’app non registrata può essere installata. Non si applica alcuna attesa del flusso avanzato. | Verificato |
| Un’app non registrata già installata riceve un aggiornamento ordinario, con il flusso avanzato disattivato | Google dice che l’aggiornamento non va a buon fine. | Verificato |
| La stessa app viene aggiornata tramite ADB | Consentito, secondo l’eccezione annunciata da Google. | Verificato |
Comportamenti dalle FAQ di Google sulla verifica degli sviluppatori Android, consultate il 13 agosto 2026. La prima riga registra l’assenza di un meccanismo annunciato, che non è la stessa cosa della promessa che il comportamento non cambierà mai.
Non scrivere "la tua app verrà cancellata"
È l’affermazione più virale su questo argomento e non è sostenuta da nulla. La formulazione corretta, quella usata in tutto il post, è: Google documenta restrizioni su installazione e aggiornamenti; non ha annunciato che le copie già installate verranno rimosse dai dispositivi né bloccate all’avvio. Riportare l’assenza di una fonte è onesto. Trasformare quell’assenza in una garanzia di sicurezza o in una previsione di cancellazioni di massa non lo è. Parziale, assenza di fonte
La distinzione cambia quello che devi fare davvero. Un aggiornamento bloccato è un problema operativo reale e documentato: un tester coinvolto può restare su una build vecchia perché l’aggiornamento non si installa dal percorso normale, e potrebbe non segnalarlo mai, perché dal suo lato non è successo niente. Una disinstallazione di massa sarebbe un’emergenza di tutt’altro tipo, con una comunicazione completamente diversa. Solo una delle due è documentata.
Dove si colloca Firebase App Distribution dopo la verifica
Firebase App Distribution è un modo per far arrivare le build pre-rilascio sui dispositivi dei tester. Non è un sistema di verifica, non è un canale di test di Google Play e non esenta nulla dalla verifica degli sviluppatori Android. Quello che fa bene è togliere il lavoro manuale dal consegnare una build firmata a un elenco di persone.
Come funziona davvero il flusso APK
Carichi un APK firmato sulla console di Firebase. Firebase richiede che sia firmato con una chiave di debug o con una chiave di firma dell’app.
Selezioni i gruppi di tester o i singoli tester per quella versione.
I tester ricevono l’invito e installano la build distribuita.
Le build distribuite restano disponibili per 150 giorni. Gli inviti ai tester scadono dopo 30 giorni, e Firebase avvisa 5 giorni prima.
Flusso, requisito di firma, conservazione delle build per 150 giorni e scadenza degli inviti a 30 giorni dalla documentazione Android di Firebase App Distribution, consultata il 13 agosto 2026. Verificato
Due orologi di scadenza, due richieste di assistenza diverse
La scadenza dell’invito a 30 giorni e la conservazione della build per 150 giorni sono cose separate. Un tester che ignora l’email per cinque settimane ha un invito scaduto anche se la build è ancora perfettamente attiva. Ne esce un messaggio confuso del tipo "il link è rotto" che non ha niente a che vedere con la verifica, con la firma o con Android. Verificato
Firebase funziona ancora durante la fase di settembre?
Quasi certamente sì, e conta come si arriva a questa conclusione. Il flusso APK di Firebase è distribuzione diretta di un APK firmato ai tester invitati. Le FAQ di Google dicono che l’installazione diretta non è coperta dalla fase del 30 settembre. Metti insieme i due fatti e la distribuzione di APK tramite Firebase dovrebbe restare utilizzabile per tutta questa prima fase.
Quella conclusione è una deduzione, ed è etichettata come tale
Nessuna fonte di Google nomina Firebase App Distribution concedendogli un’esenzione. La conclusione qui sopra discende da due fatti verificati: le installazioni dirette sono fuori dalla prima fase di settembre e il flusso APK di Firebase è distribuzione diretta. È una deduzione solida e resta comunque una deduzione, ed è per questo che il post la classifica invece di affermarla senza riserve. Parziale, deduzione
Distribuire APK e distribuire AAB con Firebase non è la stessa cosa
È la sfumatura che quasi tutti gli articoli appiattiscono. Firebase supporta entrambi, e prendono strade diverse fino al telefono del tester.
| Flusso di Firebase | Come la build arriva al tester | Come ragionarci per la verifica |
|---|---|---|
| APK | Firebase distribuisce l’APK firmato direttamente ai tester invitati. | Distribuzione diretta. Si comporta come la corsia dell’installazione diretta, anche a settembre. Parziale |
| Android App Bundle (AAB) | Il flusso AAB di Firebase si integra con l’internal app sharing di Google Play. | È un percorso collegato al Play, quindi non ragionarci come se fosse la via dell’APK grezzo. Google non ha dichiarato come venga trattato nella fase di settembre. Integrazione verificata Trattamento non documentato |
Un AAB non si può sideloadare
Prima ancora delle domande sulla verifica ce n’è una più semplice su cui molti inciampano: un Android App Bundle non si installa direttamente su un telefono. Un file .aab è un formato di pubblicazione, non un pacchetto pronto per il dispositivo. Google Play, il flusso AAB di Firebase collegato a Play, oppure bundletool deve prima trasformarlo in APK. Quindi se ti serve un file da inviare per email, caricare su Drive o consegnare direttamente a un tester, compila un APK. La documentazione di build di Android dice espressamente che un app bundle non può essere distribuito direttamente a un dispositivo. Verificato
Quindi "Firebase funziona ancora?" ha due risposte a seconda dell’artefatto che carichi. Quando ne scrivi, o quando lo chiedi a un collega, specifica distribuzione APK con Firebase o distribuzione AAB con Firebase. La forma abbreviata nasconde un dettaglio che cambia davvero l’analisi.
Firebase App Distribution conta per la regola dei 12 tester?
No. Il requisito di Google per l’accesso in produzione degli account interessati chiede almeno 12 tester attivati su un test chiuso di Google Play, in modo continuo, negli ultimi 14 giorni. I tester di Firebase non sono attivati su un test chiuso del Play, quindi testare con Firebase non soddisfa il requisito, per quante persone partecipino e per quanto a fondo testino.
| Domanda | Firebase App Distribution | Test chiuso di Google Play |
|---|---|---|
| A cosa serve? | Far arrivare in fretta le build pre-rilascio ai tester | Superare la soglia del Play prima della produzione, e testare sullo store |
| Dove si attivano i tester? | Con un’email di invito di Firebase | Con un link di attivazione del Play, sul canale chiuso |
| Registra la tua app per la verifica degli sviluppatori Android? | No il "registra la tua app" di Firebase è un processo del tutto diverso | No la registrazione dei pacchetti è un compito a sé |
| Soddisfa il requisito di 12 tester per 14 giorni consecutivi? | No | Sì per i tester e gli account che rientrano |
| Vale comunque la pena usarlo? | Sì come canale di QA, accanto al test chiuso | Sì è il percorso richiesto |
Requisito del Play dalla risposta 14151465 della Guida di Play Console; comportamento di Firebase dalla documentazione di Firebase App Distribution. Entrambe consultate il 13 agosto 2026. I due prodotti definiscono processi diversi che condividono la parola "registrare". Verificato
Lo schema che ne esce merita di essere descritto, perché costa due settimane a chi ci cade. Uno sviluppatore fa un test su Firebase davvero rigoroso con quindici tester attivi, conclude che la casella del test è spuntata, apre Play Console per richiedere l’accesso in produzione e scopre che l’orologio dei 14 giorni non è nemmeno partito. La sezione 10 mette i due requisiti uno accanto all’altro perché a te non succeda.
Il modo migliore per portare una build a 12 tester nel 2026
Non c’è un vincitore unico, perché i metodi risolvono problemi diversi. Un APK grezzo è la cosa più semplice che funziona oggi. ADB è il più duraturo e il meno usabile. Firebase è il miglior canale puro di QA. E un solo metodo in questa pagina soddisfa il requisito di Google Play per l’accesso in produzione, che è la cosa che decide davvero la tua data di lancio.
Verificatore del metodo di distribuzione
Non viene inviato niente da nessuna parte. La logica gira nel tuo browser usando l’ambito pubblicato da Google, la documentazione di Firebase e la regola del Play sull’accesso in produzione.
1 Come stai facendo arrivare la build?
2 Dove sono i tuoi tester?
3 L’app è registrata a nome di uno sviluppatore verificato?
Ambito dalle FAQ sulla verifica di Google (10 agosto 2026), dalla documentazione di Firebase App Distribution e dalla risposta 14151465 della Guida di Play Console. Consultati il 13 agosto 2026.
Tutti e sette i metodi, uno accanto all’altro
Lo strumento risponde a una situazione. Questa tabella risponde a tutte, comprese le due colonne che si saltano finché non è troppo tardi: il comportamento annunciato per il 2027 e se il metodo serve a qualcosa per la tua richiesta di accesso in produzione sul Play.
| Metodo | Cosa deve fare il tester | Prima fase del 30/09/2026 | Modello annunciato per il 2027 | Conta per i 12/14 del Play? | Verdetto pratico |
|---|---|---|---|---|---|
| APK grezzo via email, Drive o sito | Scaricare l’APK e consentire l’installazione da quella origine | Ancora praticabile l’installazione diretta non è ancora coperta | Un’app registrata si installa normalmente; per una non registrata ci si aspetta il flusso avanzato o ADB | No | Va benissimo per il QA estemporaneo di oggi. Non è il test per l’accesso in produzione. |
| ADB | Attivare le opzioni sviluppatore e il debug USB, collegarsi e installare con gli strumenti di sviluppo | Sì | Sì Google preserva ADB esplicitamente | No | Duraturo, ma troppo tecnico per i tester comuni. |
| Firebase App Distribution, APK | Accettare l’email di invito e installare la build distribuita | Probabilmente non interessato in base alla regola del sideload diretto. Nessuna decisione specifica su Firebase. Parziale | Con un pacchetto registrato dovrebbe filare tutto liscio; uno non registrato segue il modello più ampio dell’installazione diretta | No | Ottimo flusso di QA. Non sostituisce il test del Play. |
| Firebase App Distribution, AAB | Ricevere la build tramite un flusso integrato con l’internal app sharing del Play | Non documentato è collegato al Play tramite l’internal app sharing; Google non ha dichiarato come venga trattato quel percorso Non documentato | Dipende dal Play e dalla registrazione del pacchetto | No | Utile, e merita una spiegazione a parte invece di essere messo nello stesso calderone dell’APK con Firebase. |
| Test interno di Google Play | Entrare nel test interno e installare dal Play | Praticabile per un’app del Play registrata correttamente | Praticabile | No non sostituisce il test chiuso richiesto | Buon QA rapido dentro il Play. Fino a 100 tester. |
| Test chiuso di Google Play | Attivarsi tramite il link del test chiuso e restare attivato | Praticabile | Praticabile | Sì per i tester e gli account che rientrano | Il percorso richiesto per i nuovi account personali interessati che vogliono l’accesso in produzione. |
| Limited distribution di Android | Avere un dispositivo autorizzato nel sistema di limited distribution | Programmato per agosto 2026, accesso anticipato ancora chiuso Parziale | Pensato come percorso duraturo per un pubblico ristretto | No | Per chi sviluppa per hobby e condivide con al massimo 20 dispositivi. Gratuito, senza documento d’identità, ma non può pubblicare sul Play. |
Fonti: le FAQ e le guide sulla verifica di Google, la documentazione degli strumenti ADB, la documentazione di Firebase App Distribution, la pagina su limited distribution e la Guida di Play Console sul test interno e sui requisiti di test per l’accesso in produzione. Tutto consultato il 13 agosto 2026.
La raccomandazione onesta
Porta avanti due binari in parallelo, perché rispondono a domande diverse. Per il QA vero usa qualsiasi cosa metta una build sui dispositivi più in fretta: un APK grezzo per un collega, Firebase per un gruppo, ADB quando devi scavalcare tutto. Poi, separatamente e partendo il prima possibile, fai il test chiuso del Play se il tuo account è soggetto al requisito per l’accesso in produzione, perché quello si misura in giorni di calendario e non si comprime lavorando di più.
L’errore da evitare è trattarli come sequenziali. Finire un test approfondito su Firebase non fa avanzare il contatore dei 14 giorni nemmeno di un giorno.
La verifica dello sviluppatore non sostituisce il test chiuso di Google Play
Sono due requisiti senza relazione tra loro che le persone fondono in una sola casella mentale. La verifica risponde a "chi ha creato e firmato questo pacchetto?". Il test chiuso risponde a "questo account ha completato il test di Google prima della produzione?". Completare uno dei due non fa assolutamente nulla per l’altro.
Modello di verifica dalle guide di Google sulla verifica degli sviluppatori Android; requisito di test dalla risposta 14151465 della Guida di Play Console e dalla pagina sul test interno (risposta 9845334). Consultati il 13 agosto 2026.
Perché "il test interno conta, è pur sempre un test del Play" è sbagliato
Google consente fino a 100 tester su un test interno, il che lo fa sembrare l’opzione più seria. Ma il requisito per l’accesso in produzione è scritto attorno a un canale preciso: i tester che contano devono essere stati attivati su un test chiuso negli ultimi 14 giorni consecutivi. Il test interno è un altro canale, quindi non soddisfa quella frase.
Una nota su come è documentata questa affermazione
Google non pubblica una frase che dice "il test interno non conta". Quello che pubblica è un requisito che specifica un test chiuso. La conclusione discende dalla definizione e non da una citazione, e il post la presenta così invece di mettere parole in bocca a Google. Verificato dalla definizione del requisito
I numeri e da dove arrivano
Due pezzi di storia chiariscono domande che tornano di continuo. Google ha annunciato il requisito il 9 novembre 2023, e la policy attuale lo applica agli account personali creati dopo il 13 novembre 2023: due date diverse che significano cose diverse. E il minimo era originariamente 20 persone per almeno due settimane; la guida della community di Google dice che la riduzione a 12 è avvenuta a dicembre 2024. I resoconti degli sviluppatori dell’epoca collocano la modifica in Play Console l’11 dicembre 2024, ma non è stato possibile trovare un annuncio datato di Google per quel giorno esatto, quindi considera il giorno come riportato e non come ufficiale. Parziale
Gli account dell’organizzazione restano fuori da questa soglia specifica: il requisito riguarda gli account personali interessati. E la quota è la stessa in entrambi i casi, una quota di registrazione forfettaria di 25 $ su Google Play. Se vuoi il confronto completo tra i tipi di account invece di un paragrafo, lo trovi nel post su account personale o dell’organizzazione.
Dieci affermazioni su questo tema che non sono più attuali
Buona parte della copertura sulla verifica degli sviluppatori Android è stata scritta prima che Google restringesse la prima fase a giugno e luglio 2026. Le affermazioni qui sotto non sono bugie; diverse erano corrette quando sono state pubblicate. Descrivono semplicemente una versione della policy che non corrisponde più alle pagine attuali di Google.
Affermazione Dal 30 settembre tutte le installazioni dirette di APK sono bloccate nei quattro Paesi.
Regola attuale Falso secondo le FAQ di Google del 15 luglio 2026. Il 30 settembre copre sette store partecipanti. Le installazioni dirette non sono ancora coperte. Verificato
Affermazione La verifica dello sviluppatore significa che non puoi installare un’app di uno sviluppatore non verificato.
Regola attuale Troppo assoluto. ADB resta disponibile e Google ha costruito il flusso avanzato proprio per le app non verificate. Verificato
Affermazione La scadenza mondiale è il 1º gennaio 2027.
Regola attuale Non supportato. Google ha annunciato "2027 e oltre" e nessuna data mondiale esatta. Non documentato
Affermazione Una volta verificata la tua identità, qualsiasi APK firmi va bene.
Regola attuale Incompleto. Anche il nome del pacchetto e le chiavi di firma pertinenti devono essere registrati. Verificato
Affermazione Firebase App Distribution verifica la tua app Android.
Regola attuale Confusione tra cose diverse. Il "registra la tua app" di Firebase e la registrazione della verifica degli sviluppatori Android sono sistemi distinti. Verificato
Affermazione I tester di Firebase contano per i 12 tester di Google.
Regola attuale Falso. Google richiede 12 tester attivati sul test chiuso del Play. Verificato
Affermazione Il test interno del Play conta, perché è pur sempre un test del Play.
Regola attuale Non per questa soglia. Il requisito per l’accesso in produzione nomina esplicitamente un test chiuso. Verificato dalla definizione
Affermazione Le app non verificate già installate verranno cancellate.
Regola attuale Non supportato. Google documenta restrizioni di installazione e aggiornamento e non annuncia alcuna rimozione automatica delle copie installate. Parziale, assenza di fonte
Affermazione Il flusso avanzato è sicuramente attivo ovunque, visto che siamo ad agosto.
Regola attuale Troppo forte. Google ha programmato un lancio mondiale ad agosto 2026 senza pubblicare un giorno esatto di attivazione. Parziale
Affermazione Circa il 98% delle app del Play è stato registrato automaticamente.
Regola attuale Dato superato. L’aggiornamento di Google del 18 giugno 2026 dice oltre il 99%. Verificato
Dove le due pagine di Google sembrano contraddirsi
Vale la pena parlarne perché un lettore attento prima o poi ci si imbatte. Il testo generico della Guida di Google dice che le app i cui sviluppatori non hanno completato il requisito diventano non disponibili per le nuove installazioni nei Paesi interessati, il che suona più ampio dell’eccezione limitata agli store. Le FAQ, più specifiche e aggiornate al 10 agosto 2026, dicono che la scadenza del 30 settembre riguarda solo gli store partecipanti e non arriva ancora all’installazione diretta.
Come questo post lo risolve, e perché è una scelta editoriale
Interpretazione editoriale. Per la prima fase del 30 settembre questo post segue la risposta delle FAQ, più recente e specifica per lo scenario, perché nomina esplicitamente il sideload diretto e gli store non partecipanti invece di lasciarli sottintesi, e perché la sua risposta sul sideload diretto porta la data del 15 luglio 2026. Il testo di aiuto generale descrive il programma nel suo insieme. Google non ha pubblicato alcuna regola formale secondo cui una fonte prevale sull’altra: è quindi una nostra scelta editoriale, dichiarata apertamente invece che nascosta. Le due pagine si leggono meglio come descrizioni di livelli diversi dello stesso rollout che come una contraddizione. Interpretazione editoriale
Dal sintomo alla soluzione: cosa non va davvero
Cerca la frase che hai detto tu o che ti ha detto il tuo tester. Una causa comune di installazione o aggiornamento fallito per un tester è un’incompatibilità del certificato di firma, che è un comportamento normale di Android, non ha niente a che vedere con la verifica dello sviluppatore e la precede di un decennio.
"Il mio amico non riesce a installare l’APK dopo la verifica"
Spiegazione probabile. Quasi certamente non la verifica degli sviluppatori. Prima del rollout più ampio del 2027, un’installazione APK diretta che fallisce non dipende dalla regola del 30 settembre, perché quella regola non tocca ancora il percorso diretto. La causa reale più comune è un certificato di firma non corrispondente: sul telefono c’è già una copia dell’app firmata con un altro certificato.
Il controllo più sicuro, in quest’ordine. Passa prima ai normali errori di installazione Android: una copia installata firmata con un altro certificato, un versionCode più basso di quello installato, una versione di Android o un’architettura CPU non supportate, un download troncato o corrotto, spazio insufficiente, il permesso di installazione non concesso all’app che consegna il file, o un avviso di Play Protect che il tester ha ignorato. Poi, e solo se l’installazione passa da uno store partecipante o se l’applicazione più ampia è iniziata, verifica la registrazione del pacchetto e della chiave di firma.
Concetto verificato
"Firebase dice che l’installazione è fallita sopra la mia versione del Play"
Spiegazione probabile. Un tester che ha già installata una build firmata dal Play non può aggiornarla sul posto con un APK di Firebase firmato da un certificato diverso. Gli sviluppatori hanno segnalato esattamente questo, e i tester quasi mai capiscono il messaggio di errore.
Controllo successivo più sicuro. Confronta i certificati di firma dei due artefatti. Oppure usa un percorso di firma compatibile, oppure fai disinstallare al tester la vecchia build: così però se ne vanno anche i dati, quindi avvisalo.
Esempio segnalato dalla comunità
"Devo aspettare 24 ore per installare con ADB?"
Risposta. No. Google afferma che il periodo di attesa di 24 ore del flusso avanzato non si applica alle installazioni via ADB.
Passo successivo. Usa il normale flusso ADB. I comandi sono nella sezione 05.
Verificato
"La mia app non registrata era già installata ma non si aggiorna"
Spiegazione probabile. Quando l’obbligo vale per quel percorso di installazione, Google dice che aggiornare un’app non registrata richiede il flusso avanzato o ADB, e che un aggiornamento ordinario fallisce.
Controllo successivo più sicuro. Registra il pacchetto come si deve. Nel frattempo il tester può attivare il flusso avanzato oppure puoi inviare l’aggiornamento via ADB.
Verificato
"Ho testato con 12 persone su Firebase ma il Play non mi fa richiedere la produzione"
Spiegazione probabile. I tester di Firebase non sono attivati su un canale di test chiuso del Play, quindi niente di quel test viene conteggiato per il requisito dell’accesso in produzione.
Controllo successivo più sicuro. Fai il test chiuso del Play: almeno 12 tester idonei, attivati e che restano attivati, per 14 giorni consecutivi. L’orologio parte quando sono effettivamente iscritti, non quando hai iniziato a testare.
Verificato
"Ho usato 12 persone nel test interno del Play ma la produzione resta bloccata"
Spiegazione probabile. Il test interno non è il canale che il requisito per l’accesso in produzione nomina. La regola chiede un test chiuso.
Controllo successivo più sicuro. Sposta il test che conta su un canale chiuso del Play. Il test interno resta utile per un QA rapido in parallelo.
Verificato dalla definizione della policy
"Il mio tester non ha mai ricevuto l’invito di Firebase, o dice che il link è morto"
Spiegazione probabile. Gli inviti ai tester di Firebase scadono dopo 30 giorni, con un avviso 5 giorni prima. Un tester che ha lasciato lì l’email per un mese ha un invito scaduto anche se la build resta disponibile per 150 giorni.
Controllo successivo più sicuro. Rimanda l’invito prima di ipotizzare qualsiasi cosa su firma, verifica o dispositivo. I problemi di onboarding su App Distribution vengono spesso segnalati come problemi di account, di invito o di origine dell’installazione, non come problemi della build.
Verificato Schema segnalato dalla comunità
"Un articolo dice che dal 30 settembre si ferma tutta l’installazione diretta"
Spiegazione probabile. Si appoggia a coperture del 2025 o dell’inizio 2026, scritte prima che Google restringesse l’ambito iniziale.
Controllo successivo più sicuro. Leggi direttamente le FAQ sulla verifica di Google. La risposta attuale è che la scadenza del 30 settembre riguarda gli store partecipanti e non copre ancora l’installazione diretta.
Correzione verificata
La regola che fa risparmiare più tempo di assistenza
Due APK con lo stesso nome di pacchetto ma firme del tutto diverse non sono intercambiabili, e non lo sono mai stati. Prima di diagnosticare qualcosa come problema di verifica dello sviluppatore, controlla se non stai semplicemente chiedendo ad Android di sostituire un’app con un suo sosia firmato in modo diverso. L’architettura della verifica ribadisce perché l’identità di firma conta, ma questo fallimento è facile da scambiare per un problema di verifica dello sviluppatore quando non è né nuovo né collegato.
Cosa dovresti fare davvero prima del 30 settembre
Se distribuisci gli APK solo in modo diretto, la prima fase del 30 settembre non applica la verifica degli sviluppatori su quel percorso. È temporaneo, non permanente: Google consiglia di completare la verifica prima che il rollout globale inizi nel 2027. Se pubblichi su Google Play, ti chiede una cosa: tutti i pacchetti registrati. E, separatamente da entrambe, se il tuo account affronta la soglia dell’accesso in produzione, l’orologio dei 14 giorni è la voce che decide la tua data di lancio, quindi dovrebbe essere già partito.
Tracker prima della scadenza
Dodici voci nell’ordine in cui capitano davvero. Spunta man mano; niente viene salvato, quindi finisci in una volta o lascia la scheda aperta.
0 / 12 completate
Ancora niente spuntato. Comincia capendo su quale corsia ti trovi.
Quando questo post diventa vecchio
Questo è un articolo insolitamente deperibile e sarebbe disonesto presentarlo come senza tempo. Qui sotto ci sono le cose che con più probabilità cambieranno per prime, e cosa renderebbe sbagliata ciascuna.
Il segnale di aggiornamento più importante della pagina. Se Google riscrive la risposta delle FAQ che oggi dice che l’installazione diretta non è ancora coperta, cambia tutta la prima metà di questo post.
Sette store, quattro Paesi. Google potrebbe aggiungere store o chiarire il comportamento il giorno stesso. Vale la pena controllare il 29 settembre, il giorno stesso e una settimana dopo.
Entrambi erano programmati per un lancio mondiale ad agosto 2026 senza un giorno pubblicato. Il loro stato può cambiare senza alcuna modifica di policy.
Nel momento in cui Google indicherà Paesi o date per il 2027, questo post avrà bisogno di una tabella per Paese che oggi, correttamente, non ha.
Le documentazioni APK e AAB di Firebase si muovono in modo indipendente l’una dall’altra, e il requisito del Play di 12 tester per 14 giorni vive su una pagina della Guida che Google rivede senza annunci.
Cadenza di aggiornamento adottata per questo post: settimanale fino al 30 settembre 2026, poi il giorno dell’entrata in vigore e circa una settimana dopo per i chiarimenti di implementazione, quindi mensile finché Google non pubblicherà un calendario concreto per il 2027. È una scelta editoriale basata su quanto spesso Google ha rivisto questo programma nel 2026, non un calendario ufficiale di Google.
Dove entra PrimeTestLab e dove non entra
Prima il limite, perché è la parte onesta. PrimeTestLab non verifica la tua identità, non registra i tuoi nomi di pacchetto e non trasforma un test Firebase in un test chiuso del Play. Quella parte è tua, e questo articolo è tutto il nostro contributo. Quello che copriamo noi è l’unico requisito di questa pagina fatto di tempo di calendario e non di documenti: 12 tester reali attivati continuamente per 14 giorni su un canale di test chiuso del Play. Google pubblica effettivamente API e una delega OAuth con cui una piattaforma autorizzata può assistere uno sviluppatore nella registrazione, ma quell’accesso dovresti concederlo tu e la responsabilità dell’account e dell’identità dell’app resta tua.
Questa distinzione ha esattamente la forma del problema che l’articolo esiste per risolvere. Uno sviluppatore distribuisce benissimo le build: gruppi su Firebase ordinati, note di rilascio pulite, tester attivi, segnalazioni di bug vere. Poi apre Play Console per richiedere l’accesso in produzione e scopre che niente di tutto questo è stato conteggiato. Distribuire è un problema risolto. La finestra di 14 giorni di attivazione è la parte che non accorci organizzandoti meglio.
Gestire il test chiuso da solo o delegarlo
Sulla registrazione dei pacchetti, sulla verifica dell’identità e sull’accesso in produzione decide Google. Nessuna delle tre è qualcosa che facciamo al posto tuo. Quello che un test gestito toglie di mezzo è il rischio di reclutamento e di continuità dei tester, che è la fase in cui si blocca davvero chi pubblica per la prima volta. Tasso di successo su 7.400+ app testate: 99,9%, in 120+ Paesi.
Tre piani, un pagamento
Starter
12 tester $19.99 più il 5% di commissione di servizioEsattamente il minimo di Google, per una singola app che deve superare il requisito.
Professional
20 tester $29.99 più il 5% di commissione di servizioUn margine sopra il minimo, così un abbandono non chiude il test.
Enterprise
25 tester $27.99 più il 5% di commissione di servizioPer più copertura di dispositivi e di aree geografiche lungo i 14 giorni.
Tutti i piani usano tester reali su dispositivi reali per l’intero periodo di 14 giorni, il test parte di solito in 4-6 ore, e se un test non va a buon fine hai nuovo test gratuito o rimborso completo. Non promettiamo l’approvazione di Google, perché nessuno può farlo.
Domande frequenti
I miei amici potranno ancora installare un APK che invio loro via email dopo il 30 settembre 2026?
Sì, secondo le regole attuali del rilascio iniziale di Google. La scadenza del 30 settembre in Brasile, Indonesia, Singapore e Thailandia riguarda sette app store partecipanti, e le FAQ di Google del 15 luglio 2026 dicono esplicitamente che l’installazione diretta non è ancora coperta. Il requisito più ampio resta previsto per l’espansione mondiale nel 2027, quindi consideralo un limite della prima fase e non un’esenzione permanente.
Google blocca tutte le installazioni dirette in Brasile, Indonesia, Singapore e Thailandia il 30 settembre?
No, ed è la correzione più importante alle notizie più vecchie. La prima fase di applicazione è limitata a Google Play, HONOR App Market, OPPO App Market, Samsung Galaxy Store, Transsion Palm Store, vivo V-Appstore e Xiaomi GetApps. L’installazione diretta e gli app store fuori da quell’elenco restano esplicitamente fuori dalla prima fase. Per la distribuzione fuori dal Play, Google afferma che l’entrata in vigore nelle aree selezionate riguarda inizialmente i formati smartphone e tablet.
Potrò ancora installare APK direttamente dopo il rilascio mondiale?
Per un’app registrata correttamente a nome di uno sviluppatore verificato, Google dice che l’esperienza di installazione abituale degli utenti dovrebbe restare invariata. Per un’app non verificata o non registrata, Google ha preservato due percorsi: ADB e un flusso avanzato con cui l’utente può scegliere deliberatamente di installarla. Google non ha annunciato una data mondiale esatta per quella fase più ampia, ma solo il 2027 e oltre.
Mi serve la verifica degli sviluppatori Android per usare ADB?
No. Google dice che sviluppatori e utenti esperti possono continuare a usare ADB per installare app non verificate, e che il periodo di attesa di 24 ore del flusso avanzato non si applica ad ADB. ADB via USB richiede però che sul dispositivo siano attive le opzioni sviluppatore e il debug USB, quindi si adatta molto meglio a sviluppatori e tester tecnici che agli utenti comuni.
Il flusso avanzato mi fa aspettare 24 ore per ogni APK?
No. Google descrive il ritardo di 24 ore come parte della configurazione una tantum del flusso avanzato. Una volta completata, l’utente può consentire l’installazione di app da sviluppatori non verificati per sette giorni o a tempo indeterminato. Google descrive la configurazione anche come una volta per account, e si trasferisce sul nuovo dispositivo.
Android cancellerà un’app non verificata già installata?
La documentazione di Google che abbiamo esaminato non dice che le copie esistenti verranno disinstallate automaticamente né bloccate all’avvio. Dice invece che, quando l’obbligo entrerà in vigore, un’app non registrata non può essere installata né aggiornata normalmente senza il flusso avanzato o ADB, e che un aggiornamento ordinario fallisce. Il modo corretto di descriverlo è come restrizione di installazione e di aggiornamento, non come cancellazione.
Firebase App Distribution aggira la verifica degli sviluppatori?
No. Firebase è un servizio di distribuzione di versioni di test, e registrare un’app su Firebase non è la stessa cosa della verifica degli sviluppatori Android, che collega uno sviluppatore verificato ai nomi dei pacchetti e alle chiavi di firma. La distribuzione di APK tramite Firebase dovrebbe restare fuori dalla prima fase degli store a settembre, perché le FAQ di Google dicono che l’installazione diretta non è ancora coperta, ma è una deduzione a partire dalla regola sull’installazione diretta e non un’esenzione specifica per Firebase, quindi prepara comunque la registrazione dei pacchetti per il rilascio del 2027.
I tester di Firebase App Distribution contano per il requisito dei 12 tester di Google?
No. Google richiede che gli account interessati abbiano almeno 12 tester attivati su un test chiuso di Google Play negli ultimi 14 giorni consecutivi prima di richiedere l’accesso in produzione. Firebase App Distribution è utile per trovare bug, ma quei tester non sono attivati su un canale di test chiuso del Play e non soddisfano quel requisito.
Il test interno del Play conta per i 12 tester?
No, il test interno non sostituisce il test chiuso richiesto. Google consente fino a 100 tester su un test interno, ma il requisito per l’accesso in produzione dice esplicitamente che i tester che contano devono essere stati attivati su un test chiuso per 14 giorni consecutivi. Il test interno resta utile per un controllo qualità rapido accanto al test chiuso.
Ho già verificato la mia identità. Qualsiasi APK creo va automaticamente bene?
Non darlo per scontato. La verifica degli sviluppatori Android comprende anche la registrazione del nome del pacchetto e della sua chiave o delle sue chiavi di firma, e Google consente di aggiungere e verificare più chiavi di firma per uno stesso pacchetto. Questo conta soprattutto quando le build di QA o di debug e quelle di rilascio usano certificati di firma diversi, una configurazione del tutto normale che la sola verifica dell’identità non copre.
La verifica significa che il mio APK installato direttamente deve seguire tutte le policy di Google Play?
La documentazione di verifica di Google descrive la conferma dell’identità e la registrazione dei pacchetti, non l’estensione di tutte le policy di pubblicazione del Play a ogni distribuzione diretta. Google distingue anche il verificare chi è uno sviluppatore dal controllo di sicurezza applicato ai contenuti dell’app. Stabilire l’identità non equivale ad approvare quello che hai pubblicato, quindi non trattare la distribuzione fuori dal Play come equivalente a una revisione del Play Store.
In sintesi
Sintesi
Al 13 agosto 2026 i tuoi tester possono ancora installare un APK grezzo che condividi direttamente. L’entrata in vigore del 30 settembre 2026 in Brasile, Indonesia, Singapore e Thailandia riguarda inizialmente solo sette app store partecipanti, e le FAQ di Google del 15 luglio dicono che l’installazione diretta non è ancora coperta. Google prevede di estendere i controlli ai dispositivi certificati con Android 7 o superiore nel 2027, senza aver annunciato una data mondiale esatta. Quando entrerà in vigore, le app registrate a nome di uno sviluppatore verificato mantengono il consueto percorso di installazione diretta, mentre le app non registrate restano installabili tramite ADB, che non ha attese di 24 ore, o tramite il flusso avanzato di Google, il cui ritardo di 24 ore è un passaggio di configurazione una tantum. Firebase App Distribution resta un ottimo canale di QA, ma non esegue la verifica degli sviluppatori Android, i flussi APK e AAB si comportano in modo diverso, e non è il test chiuso di Google Play che richiede 12 tester attivati per 14 giorni consecutivi. Se è proprio quella fase di test a bloccare il tuo lancio, PrimeTestLab fornisce 12 tester reali a partire da $19.99 più il 5% di commissione di servizio. Vedi i piani →
Fonti primarie usate in questo articolo
Ultima verifica delle policy: 13 agosto 2026. La pagina FAQ di Google sulla verifica degli sviluppatori è stata aggiornata l'ultima volta il 10 agosto 2026, la risposta sul sideload diretto che contiene è datata 15 luglio 2026 e la documentazione Android di Firebase App Distribution è stata aggiornata l'ultima volta l'11 agosto 2026. La verifica degli sviluppatori Android è in pieno rilascio, quindi l’ambito del 30 settembre, l’elenco degli store partecipanti, la disponibilità del flusso avanzato e il calendario del 2027 vanno ricontrollati sulle pagine di Google prima di agire. Questo articolo è programmato per una riverifica settimanale fino al 30 settembre 2026, di nuovo il giorno dell’entrata in vigore e circa una settimana dopo, e poi mensile finché Google non pubblicherà una geografia o una data concrete per il 2027.