Android 17 blocca la rimozione delle app di sistema tramite ADB?

Google ha scelto di rendere più complesso il sideloading delle app Android, permettendone – come una delle alternative in futuro supportate – l’installazione mediante ADB (Android Debug Bridge), strumento che permette a un computer di comunicare con uno smartphone Android tramite USB o rete WiFi. Consente di installare applicazioni, eseguire comandi, leggere i log, trasferire file e gestire alcuni pacchetti di sistema.

La novità è che ADB non scompare da Android 17, ma una delle operazioni più usate per alleggerire gli smartphone senza root ha smesso di funzionare. Il comando che per anni ha permesso di rimuovere un’app di sistema dal profilo dell’utente restituisce ora un messaggio piuttosto netto: “Failure [only root can delete system app for a particular user]“. Le prime segnalazioni hanno coinvolto Pixel aggiornati ad Android 17, YouTube, YouTube Music e il nuovo Android Developer Verifier, servizio di sistema Google che controlla se un’app proviene da uno sviluppatore verificato e se il pacchetto risulta associato correttamente alla sua identità e chiave di firma. Non certifica che l’app sia sicura: verifica soprattutto chi la distribuisce. Sebbene la distribuzione di Android Developer Verifier sia già cominciata sugli smartphone degli utenti, dovrebbe entrare in funzione – in Italia – nel corso del 2027.

Che cosa è successo con Android 17

Una delle prime segnalazioni verificabili riguarda un dispositivo Pixel sul quale il comando pm uninstall --user 0 com.google.android.youtube termina con l’errore che richiede l’uso di un account root.

Per molti anni il comando pm uninstall --user 0 ha rappresentato il metodo più efficace per nascondere e neutralizzare il software preinstallato senza sbloccare il bootloader. Interfacce come Universal Android Debloater hanno reso l’operazione accessibile anche a chi non voleva lavorare direttamente dalla riga di comando. Con Android 17, però, il comando incoccia su un controllo molto più severo e stringente.

Numerose conferme e prove sul campo mostrano che il problema non è limitato a componenti critici come Android Developer Verifier (com.google.android.verifier), che il sistema si rifiuta di rimuovere via ADB con il comando pm uninstall --user 0. Lo stesso comportamento interessa molti altri pacchetti di sistema normalmente gestibili con ADB, che producono tutti lo stesso messaggio d’errore dopo l’aggiornamento ad Android 17.

La discussione citata in apertura e riferita ad Universal Android Debloater Next Generation, tratta proprio il caso della mancata possibilità di intervento sulle applicazioni di sistema dopo il passaggio ad Android 17. Al momento della verifica, la difformità rispetto alla precedenti release di Android è confermata e non è disponibile alcuna soluzione capace di ripristinare il vecchio comportamento sui dispositivi privi di root.

Cosa faceva il comando pm uninstall –user 0

Il comando comunemente impiegato per il debloating su Android è il seguente: adb shell pm uninstall --user 0 nome.del.pacchetto

User 0 identifica l’utente principale del dispositivo: Android adotta infatti un modello multiutente anche quando sul telefono appare configurato un solo profilo. Applicazioni, dati e stato di installazione possono cambiare da un utente all’altro.

La documentazione AOSP continua a descrivere adb uninstall --user <userId> come comando per disinstallare un pacchetto da uno specifico utente, come mostra la pagina ufficiale dedicata ai test delle configurazioni multiutente.

Quando il pacchetto si trova nelle partizioni protette del sistema, però, il comando non cancella materialmente il relativo APK. Non potrebbe farlo: sui dispositivi commerciali le partizioni come system, product e vendor fanno parte di immagini verificate e normalmente montate in sola lettura. Android Verified Boot controlla inoltre l’integrità della catena di avvio.

La cosiddetta disinstallazione per utente cambiava invece lo stato del pacchetto nel database del Package Manager: per il profilo utente specificato, l’app risultava non installata, i dati potevano essere eliminati e i componenti non venivano più avviati; la copia originale restava nell’immagine di sistema. Un ripristino di fabbrica, o il comando cmd package install-existing, poteva renderla nuovamente disponibile.

Disabilitare un pacchetto resta possibile

L’alternativa più immediata consiste nel cambiare lo stato del pacchetto senza marcarlo come non installato:

adb shell pm disable-user --user 0 nome.del.pacchetto

Per riattivarlo, si può ricorrere al seguente comando:

adb shell pm enable --user 0 nome.del.pacchetto

L’opzione disable-user continua a comparire tra le operazioni previste in PackageManagerShellCommand e, sulle build attuali di Android 17 riesce ancora a neutralizzare molte applicazioni preinstallate. Il processo dell’app non dovrebbe avviarsi, le sue attività non dovrebbero apparire nel launcher e i servizi associati restano inattivi finché il pacchetto mantiene lo stato disabled-user.

Dal punto di vista dell’utente, il risultato può sembrare quasi identico alla vecchia disinstallazione per profilo. Sotto il cofano, però, l’approccio è differente: l’app continua a risultare installata per l’utente indicato e può comparire nelle impostazioni. Altri profili, come l’area privata o un profilo di lavoro, mantengono inoltre il proprio stato indipendente. Chi volesse disabilitare lo stesso pacchetto ovunque deve ripetere l’operazione per ciascuno user ID.

La disabilitazione, inoltre, non è sempre ammessa: il produttore o il sistema possono proteggere determinati componenti; in alcuni casi il comando riesce ma lascia il dispositivo in condizioni instabili.

Perché Google potrebbe avere introdotto il nuovo controllo

Google non ha pubblicato, nelle note di rilascio di Android 17, una spiegazione specifica della scelta. Il comportamento osservato in queste settimane appare comunque coerente con una regola di separazione dei privilegi: la shell ADB non è root e non dovrebbe poter applicare tutte le modifiche riservate al proprietario del sistema.

Google può presentare il cambiamento come un rafforzamento della sicurezza, ma il risultato concreto riduce la granularità degli strumenti disponibili senza root.

Un utente esperto poteva infatti scegliere di escludere applicazioni commerciali, client multimediali, servizi di telemetria o componenti del produttore senza sbloccare il bootloader. Android 17 sposta tale possibilità dalla disinstallazione alla semplice disabilitazione, quando quest’ultima è consentita.

Evitare che una shell compromessa rimuova pacchetti di sistema è una misura difendibile; applicare il divieto indistintamente anche a software non essenziale limita però la capacità dell’utente di amministrare un dispositivo regolarmente acquistato e di suo esclusivo utilizzo.

Quali verifiche fare sul proprio smartphone

Prima di concludere che un pacchetto rientri nella nuova restrizione, conviene controllare la versione del sistema con adb shell getprop ro.build.version.release e l’API level con adb shell getprop ro.build.version.sdk. Android 17 corrisponde all’API 37, come confermano le pagine ufficiali dedicate alla versione.

Il comando adb shell pm path nome.del.pacchetto aiuta a capire dove risiede l’app. Percorsi sotto /system, /product, /vendor o /system_ext indicano un componente inserito nell’immagine software. adb shell dumpsys package nome.del.pacchetto permette invece di cercare flag, stato per utente, versione e informazioni sull’installatore.

Chi riceve l’errore può provare pm disable-user --user 0, annotando sempre il comando inverso. Prima di modificare componenti poco conosciuti è prudente creare una copia dei dati importanti e verificare che ADB rimanga autorizzato.

L’acquisizione dei diritti root resta l’unico modo utile per superare direttamente il nuovo controllo, ma introduce conseguenze ben più ampie: sblocco del bootloader, cancellazione iniziale dei dati su molti dispositivi, possibile perdita di alcune funzioni protette e problemi con applicazioni bancarie o sistemi di attestazione. Attrezzarsi con i permessi root soltanto per rimuovere YouTube o poche app preinstallate difficilmente rappresenta una scelta proporzionata.