Android Developer Verifier arriva sui telefoni: Google cambia il sideloading

Un’app comparsa senza preavviso tra i componenti installati sullo smartphone può facilmente destare sospetti, soprattutto quando il suo nome richiama attività di verifica e controllo. È quanto sta accadendo con Android Developer Verifier (Verifica dello sviluppatore Android, in italiano), un servizio Google identificato dal nome pacchetto com.google.android.verifier e distribuito gradualmente tramite gli aggiornamenti di sistema di Google Play. Molti utenti lo hanno notato soltanto consultando l’elenco completo delle applicazioni, per poi tentare di disabilitarlo o rimuoverlo.

La sua presenza anticipa una modifica molto più ampia che riguarda la gestione dei file APK esterni al Play Store. Android consente il sideloading (appunto, l’installazione di app da sorgenti non ufficiali) fin dalle prime versioni. A partire da settembre 2026, tuttavia, Google inizierà ad aggiungere un livello di controllo sui dispositivi Android certificati, partendo da Brasile, Indonesia, Singapore e Thailandia; l’estensione agli altri Paesi – Italia compresa – è prevista dal 2027.

Il servizio appena apparso prepara il terreno proprio in vista di tale passaggio. Non analizza soltanto il contenuto di un APK e non sostituisce Google Play Protect: il suo compito consiste nel verificare se l’app che l’utente intende installare risulta associata a uno sviluppatore registrato e identificato da Google. Si tratta di una distinzione importante, perché identità verificata e sicurezza del software non coincidono.

Cos’è Android Developer Verifier e perché compare sul telefono

Android Developer Verifier è un componente di sistema distribuito da Google sui dispositivi che includono i Google Mobile Services. Il pacchetto può arrivare senza un aggiornamento completo del firmware, perché Google utilizza i Google Play System Updates per aggiornare moduli e servizi critici senza attendere i tempi dei produttori degli smartphone.

Il meccanismo deriva da Project Mainline, introdotto con Android 10 e ampliato nelle versioni successive. Alcuni elementi del sistema operativo sono forniti come moduli aggiornabili, spesso in formato APEX o APK, attraverso l’infrastruttura Google Play. In pratica, un nuovo servizio può apparire tra le applicazioni installate anche se il telefono non ha ricevuto una nuova versione di Android o una patch specifica del produttore.

Il codice di Android Developer Verifier è quindi predisposto sui dispositivi degli utenti, per espressa volontà di Google, molto prima dell’effettiva entrata in vigore delle nuove regole in materia di verifica dell’identità degli sviluppatori.

Accedendo alla sezione App delle impostazioni di Android, si può cercare la presenza di Android Developer Verifier.

La verifica riguarda lo sviluppatore, non la bontà dell’app

Il nuovo sistema collega un’applicazione a un “profilo sviluppatore” del quale Google ha verificato l’identità.

Per chi pubblica su Google Play, la procedura passa attraverso la Play Console; chi distribuisce software tramite siti web, store indipendenti o canali diretti può utilizzare l’Android Developer Console dedicata.

Google richiede dati che permettano di associare l’account a una persona o a un’organizzazione reale. A seconda della categoria e del profilo possono entrare in gioco nome legale, recapiti, informazioni societarie, documenti d’identità e prove relative al possesso delle chiavi con cui risultano firmati gli APK.

Ogni app Android possiede infatti un application ID, normalmente corrispondente al package name, e deve essere firmata digitalmente prima dell’installazione.

La firma ha già un ruolo decisivo: Android consente a un aggiornamento di sostituire una versione esistente soltanto quando la nuova build risulta firmata con una chiave compatibile. La registrazione aggiunge un legame tra pacchetto, chiave e soggetto identificato: Google vuole così rendere più difficile per un autore di malware tornare immediatamente a distribuire applicazioni dopo la sospensione di un account, cambiando nome e ripresentandosi con un’identità anonima.

Un profilo verificato, comunque, non garantisce che l’app sia priva di codice dannoso, vulnerabilità o comportamenti invasivi. Uno sviluppatore identificato può subire il furto della chiave di firma, inserire librerie pubblicitarie aggressive oppure pubblicare software tecnicamente scadente. La verifica aumenta la tracciabilità e rende più onerosa la creazione ripetuta di identità “usa e getta”; non equivale a una revisione completa del codice sorgente.

Perché Google sta rendendo più difficile il sideloading

Il problema che Google dichiara di voler affrontare si coniuga male, purtroppo, con l’utilizzo di meccanismi alternativi come F-Droid, Obtainium, GitHub o altri store non ufficiali.

L’obiettivo principale di Google ha a che fare con il contrasto delle frodi basate sull’ingegneria sociale, nelle quali il criminale telefona alla vittima e la spinge a installare un APK.

La sceneggiatura cambia poco: un falso operatore bancario segnala un pagamento sospetto, un sedicente agente parla di conseguenze legali oppure qualcuno sostiene che un familiare abbia bisogno di aiuto. La vittima riceve un collegamento, autorizza Android a installare applicazioni sconosciute e supera gli avvisi seguendo le istruzioni impartite al telefono o tramite condivisione dello schermo.

Un’app malevola può poi chiedere l’accesso ai servizi di accessibilità, leggere notifiche, intercettare codici temporanei, mostrare schermate sovrapposte o controllare il dispositivo da remoto. Le protezioni già presenti risultano efficaci quando l’utente legge gli avvisi con calma; perdono valore sotto pressione, se il truffatore interpreta ogni messaggio di sicurezza come un ostacolo da superare.

Per dare un taglio a questi attacchi, Google ha progettato un percorso avanzato che introduce tempo, riavvio e autenticazione. Sono barriere pensate non tanto per fermare un utente esperto, quanto per bloccare le strategie poste in essere dal truffatore.

Come funzionerà il percorso avanzato per gli APK non verificati

Quando le nuove regole entreranno in funzione (in Italia, verosimilmente, nel corso del 2027), le applicazioni registrate da sviluppatori verificati continueranno a installarsi attraverso i canali autorizzati. Per eseguire un APK attribuito a uno sviluppatore non verificato, l’utente dovrà invece ricorrere a una “procedura avanzata” (advanced flow).

Il flusso in questione prevede l’attivazione delle Opzioni sviluppatore, la conferma di non agire sotto coercizione, l’autenticazione mediante PIN o dati biometrici e il riavvio del telefono. Seguirà un periodo di attesa di 24 ore; trascorso tale intervallo, l’utente dovrà tornare nelle impostazioni, autenticarsi nuovamente e scegliere se consentire temporaneamente o senza una scadenza prestabilita l’installazione di app non verificate.

Il riavvio serve a interrompere eventuali sessioni di controllo remoto, chiamate o strumenti di assistenza utilizzati per guidare la vittima. Le 24 ore eliminano invece l’urgenza artificiale sulla quale si fondano molte truffe. Una richiesta che sembrava inderogabile perde credibilità se il sistema impedisce comunque di completarla prima del giorno successivo.

Google presenta il percorso come un’attivazione avanzata una tantum, non come un meccanismo da ripetere a ogni installazione. Restano però possibili modifiche prima della distribuzione definitiva; interfaccia, durata delle autorizzazioni e comportamento sui diversi produttori potrebbero cambiare attraverso i successivi aggiornamenti.

ADB resta una via diretta per sviluppatori e utenti esperti

Le installazioni effettuate tramite Android Debug Bridge risultano escluse dal periodo obbligatorio di 24 ore. ADB rappresenta lo strumento ufficiale con cui sviluppatori, tecnici e amministratori comunicano con un dispositivo Android da un computer tramite USB o rete locale.

Dopo aver attivato il debug USB e autorizzato il computer, un APK può essere installato con il comando adb install nomefile.apk.

L’opzione -r consente di sostituire un’app già presente mantenendone i dati, purché la firma sia compatibile; -d permette in determinati casi un downgrade di versione, mentre -g concede automaticamente le autorizzazioni runtime richieste dall’app durante l’installazione.

L’esenzione totale per chi fa uso di uno strumento come ADB si è resa indispensabile per non compromettere i normali cicli di sviluppo e collaudo. Imporre una pausa di un giorno a ogni build renderebbe quasi impossibile provare rapidamente correzioni e versioni di debug su hardware reale.

Allo stesso tempo, ADB richiede un computer, l’attivazione delle Opzioni sviluppatore, l’autorizzazione esplicita della chiave RSA e una certa familiarità con la riga di comando. È quindi poco compatibile con una truffa telefonica rivolta a un utente inesperto.

Disinstallare il servizio oggi serve davvero?

Per la maggior parte degli utenti, Android Developer Verifier rimane al momento inattivo e privo di effetti visibili.

La fase di applicazione obbligatoria inizierà il 30 settembre 2026 soltanto nei quattro Paesi indicati da Google (descritti come i più bersagliati in assoluto dalle truffe telefoniche); altrove, l’impatto è per il momento rimandato.

Rimuovere il pacchetto con gli strumenti disponibili nell’interfaccia, eliminare gli aggiornamenti oppure tentare la disinstallazione per l’utente principale tramite ADB non garantisce alcun risultato duraturo.

Un comando come adb shell pm uninstall --user 0 com.google.android.verifier non cancella il componente dalla partizione di sistema: ne rimuove l’installazione soltanto per l’utente principale di Android, identificato dal numero 0. Un aggiornamento di sistema Google Play, un ripristino del telefono o una nuova configurazione del componente potrebbe renderlo nuovamente disponibile.

Non è neppure certo che la verifica dipenda esclusivamente dall’APK visibile nell’elenco delle applicazioni. Parti della logica potrebbero coinvolgere Package Installer, Google Play Services, Play Protect, API remote e altri moduli aggiornabili. Google sa bene che i criminali cercherebbero di neutralizzare il primo componente riconoscibile; appare quindi improbabile che l’intera protezione possa essere eliminata cancellando un solo pacchetto.

Il nodo tra sicurezza, controllo e software indipendente

La decisione di Google ha una motivazione tecnica comprensibile, ma solleva una questione che va oltre la singola app di sistema. Android è un progetto open source, mentre la maggior parte degli smartphone commerciali utilizza una versione certificata con servizi proprietari Google. Il controllo si applicherà proprio a tali dispositivi, indipendentemente dal fatto che l’APK provenga dal Play Store, da uno store alternativo o dal sito dello sviluppatore.

Organizzazioni legate al software libero e alla tutela dei diritti digitali contestano l’obbligo di identificazione centrale. Un programmatore indipendente, un ricercatore o un autore che necessitano di anonimato potrebbero non voler consegnare documenti a Google. Anche le applicazioni abbandonate, i progetti storici e i programmi distribuiti da sviluppatori non più reperibili rischiano di richiedere il percorso avanzato.

Google ha introdotto formule più leggere per studenti e hobbisti che distribuiscono software a gruppi limitati, oltre alla possibilità di installare app non verificate attraverso la procedura dedicata. Rimane però una forte asimmetria: la società che gestisce i servizi presenti sulla quasi totalità dei telefoni Android certificati assume anche il ruolo di intermediario dell’identità per software distribuito fuori dal proprio negozio.

Le ROM personalizzate non certificate, come alcune configurazioni di LineageOS prive dei servizi Google, non devono necessariamente adottare Android Developer Verifier. In tali casi il comportamento dipende dal progetto, dai componenti inclusi e dall’eventuale installazione successiva dei Google Mobile Services.

Le critiche di F-Droid, GrapheneOS e Keep Android Open

Le rassicurazioni di Google non hanno spento le critiche, ampiamente documentate anche su IlSoftware.it.

F-Droid considera la verifica obbligatoria una minaccia diretta agli store alternativi e alla distribuzione del software libero: il problema, secondo il progetto, non riguarda soltanto l’identificazione degli sviluppatori, ma il principio per cui un’app pubblicata fuori dal Play Store dovrebbe comunque ottenere una registrazione preventiva presso Google.

La campagna Keep Android Open insiste sullo stesso punto e contesta l’idea che il proprietario di uno smartphone debba accettare termini imposti da una società privata, fornire documenti e superare una procedura di nove passaggi con 24 ore di attesa per eseguire software non approvato in precedenza.

GrapheneOS ha chiarito che il sistema operativo non certificato non adotterà Android Developer Verifier e continuerà a consentire l’uso del dispositivo senza account, identificazione personale o autorizzazione di Google

La critica più rilevante non nega il problema delle truffe basate sull’ingegneria sociale: mette in discussione la soluzione scelta. Una protezione nata per ostacolare il malware rischia infatti di trasformarsi in un punto di controllo centralizzato sulla distribuzione delle applicazioni, con conseguenze soprattutto per piccoli sviluppatori, progetti anonimi, software abbandonato e archivi come F-Droid, nei quali molti pacchetti derivano direttamente da codice sorgente pubblico e possono essere ricompilati con firme diverse da quelle usate dagli autori originali.