Android cambia le regole del sideloading: dal 30 settembre 2026 Google inizierà a richiedere la verifica sviluppatore Android per installare app su dispositivi certificati in alcuni Paesi del mondo. Al momento non c’è l’Italia perché da noi la stessa misura, come anticipato in precedenza, sarà introdotta nel 2027. La novità non elimina la possibilità di installare app Android da fonti esterne, ma introduce un controllo sull’identità di chi distribuisce ciascuna applicazione.
Per capire il peso della decisione bisogna tornare al 2008, quando Android arrivò sul mercato come alternativa più aperta rispetto al modello chiuso di iPhone/iOS. Per quasi 20 anni, un file APK ha potuto circolare fuori dagli store ufficiali con pochi vincoli tecnici: bastava consentire l’installazione dalle origini sconosciute facendo leva sulle impostazioni di Android.
Ora Google sostiene che quel margine di libertà abbia favorito truffe finanziarie, cloni di app legittime e campagne malware. La ricetta scelta da Google per il sideloading Android, tuttavia, non riguarda solo il Play Store: tocca l’intera filiera di distribuzione del software sui dispositivi Android certificati.
Che cosa cambia dal 30 settembre 2026 sui dispositivi Android
In Italia, per adesso, non cambierà nulla ma assisteremo al cambiamento introdotto per la prima volta sugli smartphone degli utenti di altri Paesi: Brasile, Indonesia, Singapore e Thailandia. Si parte proprio da questi perché Google li indica come aree ad alto rischio per truffe basate su app.
La nuova regola prevede che ogni app installata su un dispositivo Android certificato risulti associata a uno sviluppatore verificato. Google parla di dispositivi che rispettano i requisiti di compatibilità Android e integrano i servizi Google; in pratica, la maggior parte degli smartphone venduti da produttori come Samsung, Xiaomi, OPPO, vivo, Honor e Google stessa.
La verifica richiede due passaggi principali. Lo sviluppatore deve confermare la propria identità, fornendo nome legale, indirizzo, email, numero di telefono e, in alcuni casi, un documento ufficiale. Le imprese devono inoltre fornire un identificativo univoco e verificare la proprietà del proprio sito web utilizzando Google Search Console.
Il secondo elemento è più tecnico: bisogna registrare il package name dell’app e dimostrarne la proprietà attraverso un APK firmato con la chiave privata dello sviluppatore.
Il legame tra nome del pacchetto e app signing key diventa quindi cruciale: se un attore malevolo provasse a distribuire una copia modificata di un’app nota con un’identità diversa, Google potrà rendere qualunque blocco molto più efficace.

Store coinvolti e ruolo dei produttori
Google ha chiarito che la prima fase coinvolgerà vari store: Google Play, HONOR App Market, OPPO App Market, Galaxy Store, Palm Store di Transsion, V-Appstore di vivo e GetApps di Xiaomi.
Per gli sviluppatori già presenti su Google Play, gran parte della procedura risulterà automatica: Google dichiara che oltre il 99% delle app Play è già registrato o pronto alla nuova policy.
La parte più delicata riguarda chi distribuisce fuori da Google Play: per questi sviluppatori nasce l’Android Developer Console, distinta dalla Play Console, con la possibilità di registrare app e identità anche senza pubblicare nello store di Google.
Google sta anche introducendo un componente chiamato Android Developer Verifier (com.google.android.verifier): il servizio arriverà sui dispositivi con Android 8 e versioni successive e resterà inattivo fino all’introduzione delle procedure di verifica nell’area geografica in cui si trova l’utente.
In pratica, durante l’installazione il sistema potra’ controllare se l’app appartiene a uno sviluppatore registrato. La veridica tecnica non passa quindi solo dallo store, ma dal dispositivo finale: è uno schema che sposta il controllo fino al momento dell’installazione, rendendo più difficile aggirare le regole semplicemente cambiando sito o marketplace.
Account limitati e sviluppatori non professionali
Google ha previsto un canale per studenti, hobbisti e sviluppatori che vogliono condividere app con un gruppo ristretto. Gli account a distribuzione limitata non richiedono la condivisione di un documento d’identità né il versamento di qualsivoglia quota di registrazione, ma impongono un limite: le app possono arrivare al massimo su 20 dispositivi esplicitamente autorizzati.
È una soluzione utile per prototipi, corsi, test domestici e piccoli progetti personali. Non risolve però il problema di chi sviluppa software indipendente con una comunità più ampia ma non vuole stabilire un rapporto formale con Google. Qui la critica è comprensibile: Android resta più aperto di iOS, ma l’anonimato tecnico che per anni ha caratterizzato il sideloading ne esce abbondantemente azzoppato.
Resta invariato anche l’uso di ADB, cioè Android Debug Bridge, strumento del quale si avvalgono sviluppatori e power user per installare build locali, app modificate e versioni di test. Questa eccezione è importante: senza ADB, il nuovo modello avrebbe inciso pesantemente su debugging, reverse engineering legittimo, ricerche sul piano della sicurezza e sviluppo indipendente.
Le nuove API per automatizzare la registrazione
Nei prossimi mesi Google introdurrà due interfacce utili agli sviluppatori con molte app o processi automatizzati.
Android Developer ID Status API consentirà di verificare se un package name risultasse già registrato; Android Developer Console API permetterà invece di registrare e gestire package name direttamente dagli ambienti di sviluppo.
Entrambe supporteranno la delega OAuth, così store di terze parti e piattaforme di distribuzione potranno eseguire alcune operazioni per conto dello sviluppatore. È un aspetto tecnico meno visibile agli utenti, ma decisivo per evitare che la verifica diventi un collo di bottiglia per software house con molti pacchetti, varianti regionali o build firmate con chiavi diverse.
Sicurezza reale o controllo della distribuzione?
La motivazione di sicurezza legata all’introduzione della verifica degli sviluppatori su Android ha basi solide.
Le truffe tramite APK esterni spesso sfruttano messaggi, social network o falsi operatori bancari per convincere l’utente a installare app che rubano credenziali, intercettano notifiche o abusano dei servizi di accessibilità. Legare un’app a un’identità reale può rendere più costose le operazioni svolte da gruppi di criminali informatici.
D’altro canto, però, la verifica dell’identità non garantisce che il codice sia sicuro. Google stessa la paragona a un controllo documenti, non a un’ispezione del contenuto: uno sviluppatore verificato può comunque commettere errori, subire compromissioni o pubblicare app invasive. La misura riduce l’anonimato degli abusi, ma non sostituisce analisi statica, sandboxing, Play Protect, controllo dei permessi e buone pratiche lato utente.