Come disinstallare le app di sistema senza root: guida ADB passo per passo

Le app di sistema stanno lì dal primo avvio, occupano spazio, a volte partono da sole e non hanno il pulsante Disinstalla. Su un Samsung Galaxy o su uno Xiaomi possono essere trenta o quaranta, tra servizi del produttore, doppioni delle app Google e software preinstallato in base al mercato.
Toglierle dal Play Store non si può, perché non sono state installate da lì. Esiste una via di mezzo che non richiede root, non invalida la garanzia e si annulla in trenta secondi: i comandi ADB da un PC.
Ecco cosa fa pm uninstall --user 0, cosa comporta un aggiornamento OTA e come tornare indietro se qualcosa smette di funzionare.
Cosa sono le app di sistema e perché il Play Store non le tocca
Un’app di sistema è un pacchetto installato nella partizione di sola lettura del firmware, quella che Android monta come /system (oggi /system, /product, /vendor a seconda del costruttore). Non sta in /data, la parte scrivibile dall’utente, quindi l’interfaccia normale non offre il pulsante di rimozione.
Il risultato è che convivono sullo stesso telefono tre categorie diverse di software: i pezzi indispensabili del sistema (telefono, gestione permessi, Bluetooth), i servizi del produttore che qualcuno usa davvero (Samsung Pass, Mi Cloud) e il bloatware puro, cioè app commerciali preinstallate per accordi di distribuzione. Le prime due categorie vanno lasciate in pace quasi sempre, la terza è quella che vale la pena rimuovere.
La domanda da farsi prima di ogni comando è semplice: se domani questa app sparisse, cosa si rompe? Se la risposta è “non lo so”, meglio disattivarla e conviverci una settimana.
Il bloatware non è solo spazio sprecato: le app preinstallate hanno spesso permessi già concessi e notifiche attive. Ne abbiamo parlato anche in disinstallare il bloatware a fine mese, qui il discorso è più radicale.
Disattivare o rimuovere: la differenza che conta
Disattivare è l’opzione che Android offre a tutti, dalle Impostazioni, senza PC. L’app resta installata, smette di girare, sparisce dal launcher e non può essere aggiornata. È reversibile con due tocchi ed è la scelta giusta per tutto ciò di cui non si è sicuri.
Rimuovere per l’utente è un passo oltre. Il pacchetto resta fisicamente nella partizione di sistema (quindi lo spazio occupato dall’APK non torna e in genere sono pochi megabyte), ma viene cancellato per l’utente 0, cioè quello principale. Spariscono dati, cache, aggiornamenti scaricati e notifiche. Il telefono si comporta come se l’app non esistesse.
In cambio si guadagna RAM perché non parte più nessun servizio in background, si guadagna spazio in /data e si toglie di mezzo un canale di telemetria. La terza strada, il root, permette di cancellare davvero l’APK, ma i rischi per Play Integrity e per gli aggiornamenti OTA superano il beneficio di recuperare 40 megabyte.
Preparare PC e telefono per ADB
Serve un computer Windows, macOS o Linux, un cavo USB che trasmetta dati e dieci minuti di pazienza. Il pacchetto si chiama Platform Tools e si scarica dal sito ufficiale Android Developers: è uno zip, si scompatta dove si vuole, non ha installazione.
Su Windows bisogna aprire il terminale dentro quella cartella o aggiungerla al PATH, su macOS e Linux basta il terminale. Il primo comando è adb devices: se risponde con il seriale e la scritta device, è tutto a posto.
Sul telefono vanno attivate le Opzioni sviluppatore, toccando sette volte Numero build nella sezione Info sul dispositivo. Dentro Opzioni sviluppatore si attiva il Debug USB. Al primo collegamento il telefono mostra una finestra con l’impronta RSA del PC: va accettata, altrimenti ogni comando restituisce unauthorized.
TIP: se il telefono non compare, non è quasi mai ADB. Nel 90% dei casi è il cavo, che è solo di ricarica. Nel restante 10% è il driver del produttore: su Windows conviene installare quello ufficiale Samsung, Xiaomi o Google. Su Android 11 e successivi esiste anche il debug wireless con adb pair, comodo ma più lento da impostare e inutile per questa procedura.
I comandi, uno per uno
Prima si guarda cosa c’è. Il comando adb shell pm list packages -s elenca solo i pacchetti di sistema, quelli cioè che non si possono toccare dalle Impostazioni. L’output è una lista di nomi tipo com.samsung.android.bixby.agent: sono gli identificativi reali, quelli che servono nei comandi successivi.
Per capire a cosa corrisponde un nome si filtra con adb shell pm list packages -s | grep samsung, oppure si usa un’app che mostri nome e icona. Senza filtro il rischio di sbagliare pacchetto è concreto.
Il comando di rimozione è questo, con il pacchetto al posto del segnaposto:
adb shell pm uninstall -k --user 0 com.esempio.pacchetto
Il flag -k mantiene i dati e la cache dell’app, cosa utile quando si vuole poter tornare indietro senza perdere configurazioni. Se non interessa, si può omettere. La risposta corretta è Success. Se compare Failure [DELETE_FAILED_INTERNAL_ERROR] o not allowed, il produttore ha bloccato quel pacchetto: non c’è modo di aggirare il blocco senza root e non vale la pena provarci.
Per verificare che sia sparito davvero basta rilanciare la lista con adb shell pm list packages -s e controllare che il nome non ci sia più. Attenzione a un dettaglio: con pm list packages -u i pacchetti rimossi ricompaiono, perché il flag -u include anche quelli disinstallati per l’utente. È normale e anzi è proprio quello che serve per il ripristino.
Chi preferisce non toccare la shell usa un’interfaccia grafica, ma sotto il cofano girano sempre questi comandi. Abbiamo raccontato perché ADB resta l’ultima linea di difesa per un Android libero e aperto e questa procedura è l’esempio più concreto.
Se qualcosa si rompe: il ripristino
La rimozione per utente è reversibile finché non si fa un factory reset. Il comando di ripristino è:
adb shell pm install-existing --user 0 com.esempio.pacchetto
Su alcune versioni di Android la sintassi equivalente è adb shell cmd package install-existing com.esempio.pacchetto. Entrambe funzionano senza root e senza scaricare nulla: il pacchetto è ancora nella partizione di sistema, si tratta solo di riattivarlo per l’utente.
Se il comando risponde Package ... installed for user: 0, l’app torna disponibile. Nel caso di app che dipendono da servizi collegati (per esempio un framework di pagamento) conviene riavviare il telefono dopo il ripristino, altrimenti alcuni processi restano nello stato sbagliato fino al boot successivo.
Caso tipico: si toglie il provider di stampa o il servizio di condivisione e le app non esportano più file. Il ripristino risolve, ma serve il nome del pacchetto: conviene annotare ogni comando eseguito, con nome e data.
Il caso più fastidioso è togliere l’app che gestisce gli aggiornamenti del produttore: il telefono funziona, poi smette di ricevere patch e nessuno collega le due cose.
Dopo un aggiornamento OTA e dopo un factory reset
Qui sta la parte che quasi nessuna guida dice. Lo stato “disinstallato per l’utente 0” è salvato nella partizione dati, quindi nella maggior parte dei casi sopravvive agli aggiornamenti di sicurezza mensili. Il pacchetto resta nel firmware, lo stato di rimozione resta in /data e l’app non torna.
Gli aggiornamenti di versione maggiore sono meno prevedibili. Samsung, Xiaomi e Google gestiscono l’OTA in modi diversi e alcuni pacchetti vengono reinstallati forzatamente perché il nuovo firmware li considera necessari per la migrazione dei dati. Non è un bug: è una scelta del produttore. Aspettarsi che una rimozione duri per sempre è irrealistico.
Il factory reset invece azzera tutto. Dopo il ripristino di fabbrica le app di sistema sono tutte al loro posto, comprese quelle rimosse e la procedura va rifatta da capo. Chi cambia telefono ogni due anni e fa un reset all’anno si trovi un file di comandi pronti da incollare.
Consiglio pratico: dopo ogni aggiornamento importante contare i pacchetti di sistema con adb shell pm list packages -s | grep -c . e confrontare il numero con quello annotato. Se è cresciuto, qualcosa è tornato.
Le app da non toccare
Alcune rimozioni sembrano innocue e poi rompono funzioni che si usano ogni giorno. Questa lista non è completa, ma copre gli errori più frequenti.
- Servizi Google Play e Play Store: senza questi, notifiche push, account e acquisti smettono di funzionare.
- Google Play Services Framework: è il livello su cui girano le API di sistema, non è un doppione.
- Provider dei contatti, del calendario e della rubrica: le app di terze parti li usano per leggere i dati, non hanno un sostituto proprio.
- Package installer e Permission controller: senza questi non si installa più nulla, nemmeno dagli APK.
- Servizi di telefonia, SIM toolkit, IMS: chiamate e VoLTE dipendono da lì.
- Framework di aggiornamento del produttore: la rimozione blocca le patch di sicurezza, spesso in silenzio.
- Qualsiasi cosa con “carrier” o “mno” nel nome: gestisce configurazioni di rete legate all’operatore.
Fuori da questa lista restano le app commerciali preinstallate, i doppioni dei servizi del produttore, i giochi di prova e le app di partner commerciali. Sono le candidate ideali e sono anche quelle che nessuno rimpiange.
Se l’obiettivo è solo liberare spazio, c’è un percorso meno rischioso che passa dalle Impostazioni e dagli strumenti del produttore: installare e disinstallare le app Android in modo corretto copre anche quello.
Checklist prima e dopo
Prima: attivare debug USB, autorizzare il PC, annotare il numero totale di pacchetti di sistema, scegliere un massimo di cinque app per sessione. Cinque, non trenta: se qualcosa si rompe, con cinque si isola il colpevole in un minuto.
Durante: un comando per volta, risposta Success verificata, nome del pacchetto copiato dalla lista e non digitato a memoria.
Dopo: riavviare, controllare notifiche, chiamate, fotocamera, pagamenti e aggiornamenti. Se qualcosa non va, ripristinare il pacchetto sospetto e riprovare. Solo dopo ventiquattro ore senza problemi si passa al gruppo successivo.
Domande frequenti
Serve davvero il root per disinstallare le app di sistema?
No. pm uninstall --user 0 funziona su qualsiasi telefono con debug USB attivo e non modifica il firmware. Il root serve solo a cancellare fisicamente l’APK dalla partizione di sistema, operazione che non porta benefici pratici e complica aggiornamenti e verifiche di integrità.
L’app rimossa libera spazio?
In parte. L’APK resta nella partizione di sistema e quello spazio non torna. Si liberano i dati in /data, la cache e gli aggiornamenti scaricati dal Play Store. Il guadagno maggiore è in RAM e batteria, perché i servizi in background smettono di partire.
Cosa succede se rimuovo un’app sbagliata?
Nella maggior parte dei casi nulla di irreparabile, perché il ripristino con pm install-existing è immediato e non richiede connessione. Fa eccezione la rimozione di componenti che gestiscono l’installazione dei pacchetti o la rete: se il telefono non si avvia o non prende campo, serve un factory reset, che riporta tutto allo stato di fabbrica ma cancella i dati personali.
Le app rimosse tornano dopo un aggiornamento?
Gli aggiornamenti di sicurezza mensili in genere rispettano lo stato di rimozione. I passaggi di versione maggiore possono reinstallare alcuni pacchetti considerati necessari dal nuovo firmware. Dopo un factory reset tornano tutte, senza eccezioni.
