Cambiano gli equilibri del sideloading su Android e il nuovo messaggio che inizia a spuntare dentro il Play Store ha il sapore di un compromesso faticosamente negoziato tra Google, sviluppatori indipendenti e quell’esigua ma rumorosa minoranza di utenti che non si accontenta di installare solo ciò che passa dal negozio ufficiale. Nel codice dell’ultima versione del Play Store (49.7.20-29) compaiono stringhe come “Install without verifying” accompagnate da avvisi sul fatto che le app di sviluppatori non verificati “possono mettere a rischio dispositivo e dati”, insieme a messaggi di errore quando non è possibile verificare l’identità del developer per mancanza di connessione o problemi lato server.Per capire cosa sta succedendo bisogna tornare all’estate scorsa, quando Google ha messo in allarme l’ecosistema Android annunciando che dal 2026 anche gli sviluppatori che distribuiscono APK fuori dal Play Store – via sideloading diretto o store alternativi – dovranno registrarsi e verificare la propria identità per poter installare sui dispositivi Android certificati. L’idea, comunicata con la solita narrativa sulla sicurezza, è chiara: niente più app da sviluppatori anonimi, ma account legati a documenti, recapiti verificati e, in molti casi, anche a un account developer con processo KYC in stile Play Console, seppure con un canale più “leggero” per studenti e hobbisti. Di fronte alle critiche sul rischio di soffocare scene come F-Droid, store indipendenti e tool distribuiti direttamente su GitHub, Google ha fatto marcia indietro parziale promettendo un “advanced flow” pensato per power user ed “experienced users” che accettano consapevolmente il rischio di installare software non verificato.Il nuovo set di stringhe dentro il Play Store sembra il primo tassello concreto di questo flusso avanzato, anche se la sua implementazione attuale, almeno a giudicare dai testi, appare sorprendentemente blanda. La sequenza è più o meno questa: il Play Store prova a verificare lo sviluppatore, se la verifica fallisce compaiono messaggi del tipo “Can’t verify app developer” e “The app can’t be verified at the moment”, e subito dopo viene comunque offerta la possibilità di proseguire e “install without verifying”, accompagnata da un avviso generico sui rischi per dispositivo e dati. Non è la rivoluzione di UX punitiva che molti si aspettavano dopo i toni duri usati da Google per motivare l’obbligo di verifica, ma assomiglia più a una versione evoluta del vecchio toggle “Installa da origini sconosciute”, con una mano di vernice lessicale in più sulla parola “verifica”.Dietro questa apparente morbidezza, però, c’è un cambio di paradigma molto più radicale di quanto lasci intuire una singola schermata di warning. Con il rollout del nuovo requisito di developer verification, Android sposta il baricentro della sicurezza dal contenuto del pacchetto (static analysis, Play Protect, controlli post-pubblicazione) all’identità di chi lo firma, estendendo al mondo del sideloading lo stesso modello già consolidato sul Play Store. Google lo dice esplicitamente: senza obbligare i developer a usare un’identità reale, i criminali possono generare infinite varianti di app malevole e giocare al solito whack‑a‑mole con i sistemi di rilevamento automatici; con la verifica, ogni nuova campagna malware diventa più costosa perché lega il codice a una persona o ad un’entità aziendale verificata, rendendo più semplice bloccare recidivi e reti di account collegati.Se guardato da questa prospettiva, l’avviso “Install without verifying” diventa un discrimine quasi politico dentro Android: da una parte c’è il flusso standard in cui l’installazione è subordinata alla benedizione di Google sul developer, dall’altra c’è un corridoio laterale, pensato per chi sa cosa sta facendo, in cui l’utente si prende su di sé una quota di rischio che prima era più implicita, quasi nascosta dietro il semplice toggle delle origini sconosciute. Google promette che questo advanced flow sarà progettato per “resistere alla coercizione”, cioè per evitare che scammer e truffatori possano guidare le vittime a bypassare tutti i warning semplicemente dicendo “clicca sempre su Avanti”, introducendo più attrito, passaggi espliciti e spiegazioni sui pericoli di accettare software non verificato. Nell’implementazione attuale, però, il testo visto nel teardown del Play Store non trasmette ancora questa robustezza: si limita a ribadire che l’app può essere rischiosa, senza meccanismi visibili per spezzare i pattern tipici del social engineering o per confermare che l’utente sta davvero agendo in autonomia.Per gli utenti Android più smaliziati la domanda vera non è tanto se sarà ancora possibile sideloadare APK, quanto a che prezzo in termini di frizione e di dipendenza dall’infrastruttura Google. Il rollout del programma partirà a settembre 2026 in Brasile, Indonesia, Singapore e Thailandia, per poi estendersi globalmente nel 2027, e interesserà tutti i dispositivi Android certificati, cioè quelli con servizi Google, Play Protect e le API di integrità attive. Chi vive già su custom ROM senza Play Services o su progetti de‑Googled continuerà a muoversi in un’altra dimensione, ma per il resto del mondo Android la traiettoria è evidente: o si accettano app da sviluppatori verificati, o si entra in un flusso avanzato che rende esplicita ogni deviazione dalla linea di sicurezza tracciata da Google, con il rischio che, versione dopo versione, questo corridoio diventi sempre più stretto.Nel frattempo, il nuovo messaggio “Install without verifying” è una sorta di trailer di ciò che aspetta la community Android nei prossimi anni. Per chi gestisce portali e community dedicate al modding, agli store alternativi e al software libero su Android, è il momento di osservare da vicino come evolveranno queste schermate, perché saranno loro il front‑end di una battaglia molto più ampia: quella tra un’idea di piattaforma aperta, dove l’utente decide cosa installare, e un ecosistema sempre più chiuso in cui l’ultima parola spetta a chi controlla la verifica dell’identità dei developer.Questa discussione è aperta anche su Feddit in @AndroidianiVuoi discutere di questa funzione o condividere altre anticipazioni? Unisciti alla conversazione nella nostra community. La discussione sul forum è in categoria: @google-play-developers.
