Android cambia le regole del sideloading: identità obbligatoria e nuovi ostacoli

Installare un'applicazione su Android senza passare dal Play Store — pratica nota come sideloading — è da sempre uno dei tratti distintivi del sistema operativo di Google rispetto all'ecosistema chiuso di Apple. Dal 2026, questa libertà non sparirà, ma cambierà profondamente il modo in cui viene esercitata. Google sta introducendo due misure che, combinate, ridisegnano i confini pratici del sideloading: un nuovo percorso di installazione più articolato e un requisito di identità per gli sviluppatori che distribuiscono app fuori dai canali ufficiali.

Per capire la portata del cambiamento, vale la pena partire da cosa significa oggi fare sideloading. Su Android, installare un file APK da fonti esterne al Play Store richiede di attivare un'opzione nelle impostazioni — storicamente chiamata "installazione da origini sconosciute" — e procedere con qualche avviso di rischio. Una procedura accessibile, relativamente rapida, usata da milioni di persone per installare store alternativi, app open source, versioni beta o applicazioni non disponibili nella propria area geografica.

Un nuovo percorso, più lento e deliberato

Il primo cambiamento è quello che Google chiama advanced flow, un percorso di abilitazione che sostituisce la vecchia opzione lineare. Stando alle descrizioni circolate nelle ultime settimane, il nuovo flusso introduce passaggi deliberatamente incompatibili con l'assistenza remota: una conferma esplicita che nessuno sta guidando l'utente da remoto, un riavvio del dispositivo per interrompere eventuali sessioni attive e, soprattutto, un'attesa di circa 24 ore prima di poter completare l'abilitazione. La verifica finale avviene tramite biometria o PIN.

La logica è anti-truffa più che anti-utente. Il bersaglio dichiarato è la dinamica tipica delle frodi telefoniche, in cui una vittima viene guidata passo dopo passo da un truffatore che le detta le istruzioni in tempo reale. Un'attesa forzata di 24 ore spezza quella dinamica: la truffa "in diretta" perde efficacia se non si può completare nell'arco di una telefonata. Il percorso viene spostato nelle impostazioni sviluppatore, e secondo chiarimenti emersi nella community, l'abilitazione sarebbe una tantum e non richiederebbe di tenere attive le opzioni sviluppatore in modo permanente.

Questo non significa che il nuovo percorso sia indolore per tutti. Chi testa build quotidiane di un'app, chi gestisce installazioni in ambienti aziendali o di laboratorio, chi usa strumenti di distribuzione alternativa con frequenza regolare, percepirà quell'attesa come un costo reale sul proprio flusso di lavoro. La frizione è progettata per essere selettiva: scoraggia chi agisce sotto pressione esterna, ma rallenta anche chi ha ragioni del tutto legittime.

Il nodo dell'identità verificata

Il secondo cambiamento è quello più strategico. Da settembre 2026, su dispositivi Android certificati, le app dovranno essere riconducibili a sviluppatori verificati. La verifica degli sviluppatori Android non è un semplice badge: è un'infrastruttura di identità che collega legalmente una persona o un'organizzazione a un'applicazione, formalizzando il rapporto tra il nome del pacchetto software e le chiavi crittografiche usate per firmarlo. Nelle guide ufficiali Google descrive esplicitamente un percorso che include la verifica di nome e indirizzo tramite documenti governativi, e una fase di registrazione del package name per rendere verificabile il legame tra quell'identità e l'app che l'utente sta installando.

In termini pratici, per chi distribuisce fuori dal Play Store, la domanda non è più solo «posso installare questo APK?», ma «questa app è installabile su un dispositivo certificato se il suo sviluppatore non è registrato in questo sistema?». Google lascia aperto un bypass tramite l'advanced flow, ma quel bypass ha un costo: cognitivo, temporale, e spesso anche di supporto verso gli utenti finali.

La libertà di installare app da fonti esterne resta, ma smette di essere un comportamento normale del sistema

Questa mossa colpisce in modo asimmetrico. Da un lato, rende più costoso per i truffatori rientrare nel sistema con nuove identità: perdere un account sviluppatore e crearne un altro diventa più difficile se ogni account richiede documenti verificati. Dall'altro, crea attriti anche per casi del tutto legittimi: progetti open source distribuiti senza strutture commerciali, piccoli team che usano canali diretti, app aziendali interne, beta distribuite con strumenti non allineati al modello Play Console.

I numeri che giustificano la stretta

Google ha costruito la narrativa attorno a questa transizione con dati precisi. Nel 2025 la protezione anti-frode contro installazioni provenienti da browser o app di messaggistica è stata estesa a 185 mercati, coprendo 2,8 miliardi di dispositivi e bloccando 266 milioni di tentativi considerati rischiosi. Non si tratta solo di malware classico, ma di un'area grigia più ampia: truffe, social engineering — cioè manipolazione psicologica per indurre comportamenti — e installazioni guidate a distanza da malintenzionati.

Play Protect, il sistema di sicurezza integrato in Android, opera già da tempo come una seconda linea di difesa: continua a scansionare le app anche quando non provengono dal Play Store, monitorando il comportamento delle applicazioni installate. I nuovi requisiti di identità si aggiungono a questo layer, spostandosi a monte: non più solo «blocco ciò che è già installato», ma «verifico chi distribuisce prima che l'installazione avvenga».

Android si avvicina al modello chiuso che ha sempre criticato

C'è un parallelismo che vale la pena osservare. In Europa, Apple è stata costretta ad aprire iPhone a marketplace alternativi sotto pressione regolatoria del DMA, e ha impostato gran parte del dibattito pubblico attorno ai rischi di sicurezza di quella apertura forzata. Android parte da una posizione opposta — apertura come valore fondante — ma sta convergendo verso un modello di «apertura condizionata», in cui installare fuori dallo store ufficiale resta possibile ma è sempre più mediato da controlli, attestazioni e identità verificate. Due strade diverse che portano a una forma simile di governance della piattaforma.

Google sceglie di non vietare il sideloading ma di renderlo più lento, più tracciabile e più costoso

Per la grande maggioranza degli utenti che usa esclusivamente il Play Store, questi cambiamenti non cambieranno nulla. Ed è esattamente questa la struttura del progetto: lasciare intatta l'esperienza comune, aumentare la complessità ai margini. I margini, però, sono abitati da una fetta non trascurabile dell'ecosistema Android: store alternativi come F-Droid, repository open source, tool per sviluppatori, app di nicchia che vivono di installazioni manuali. È plausibile che una parte di questi flussi si sposti verso canali tecnici — installazioni via ADB, dispositivi non certificati, ROM alternative — o che gli sviluppatori cerchino di adeguarsi ai requisiti di verifica per non perdere accessibilità.

Molto dipenderà dai dettagli del rollout: quali geografie saranno coinvolte per prime, se esisteranno eccezioni per contesti enterprise, come verranno trattati gli store alternativi e gli account con distribuzione limitata o amatoriale. Questi dettagli determineranno se l'advanced flow sarà percepito come una cintura di sicurezza o come un pedaggio. In ogni caso, il sideloading su Android non scompare: cambia di stato, da comportamento predefinito del sistema a scelta consapevole che lascia una traccia verificabile.