ADB per principianti: cosa puoi fare davvero (e cosa rischi)

Collegare il telefono al computer con un cavo è la prima cosa che molti evitano. ADB, la sigla che spunta fuori ogni volta che si parla di app di sistema, screenshot da riga di comando o ripristini, sembra roba da smanettoni incalliti. In realtà è uno strumento di Google, gratuito, che non richiede root e non fa decadere la garanzia.

Serve solo un po’ di ordine: installare i platform tools, attivare il debug USB, imparare cinque o sei comandi. Qui sotto trovi la procedura su Windows, Mac e Linux, i comandi che valgono la pena e i punti in cui si può fare danno sul serio.

Cos’è ADB e perché non serve il root

ADB sta per Android Debug Bridge. È un programma che gira sul computer e parla con un demone presente su ogni telefono Android, chiamato adbd. Il demone è già lì, spento in attesa: quando attivi il debug USB, il telefono apre una porta e il computer può inviare comandi.

La confusione nasce dal fatto che ADB viene spesso citato insieme al root, ma sono due cose diverse. Il root dà permessi di amministratore sul sistema operativo. ADB dà una shell con i permessi dell’utente shell, che sono più alti di quelli di un’app normale ma non onnipotenti. Con ADB puoi leggere la memoria condivisa, installare e disinstallare applicazioni, fare screenshot, consultare i log. Non puoi modificare la partizione di sistema, se non sbloccando il bootloader e facendo il root.

Sul fronte garanzia la questione è semplice: attivare il debug USB e usare ADB non invalida la garanzia. È una funzione prevista da Android per gli sviluppatori, non una manomissione. Cosa diversa è lo sblocco del bootloader, che su molti produttori fa decadere la garanzia e cancella tutti i dati. Quello sì è un passaggio da valutare con calma.

Installare ADB su Windows, Mac e Linux

ADB vive dentro i platform-tools, un pacchetto ufficiale di Google per tutti e tre i sistemi. Non serve installare Android Studio, che pesa diversi gigabyte e non aggiunge nulla.

Su Windows si scarica lo zip dal sito di Android Developers, si estrae in una cartella semplice come C:platform-tools e si apre il prompt dei comandi da lì. In alternativa c’è il pacchetto gestito da winget, comodo per gli aggiornamenti. Alcuni produttori, Samsung e Xiaomi in testa, richiedono anche il driver USB proprietario: senza, il telefono compare come periferica sconosciuta e ADB non lo vede.

Su Mac il metodo più rapido passa da Homebrew, con il pacchetto android-platform-tools. Su Linux dipende dalla distribuzione: adb su Debian e Ubuntu, android-tools su Fedora, android-tools anche su Arch. Chi preferisce evitare il gestore di pacchetti può estrarre lo zip ufficiale ovunque e lanciare ./adb dalla cartella.

Il primo controllo è adb version. Se risponde con un numero di versione e il percorso del binario, sei a posto. Se il terminale dice comando non trovato, il problema è quasi sempre il PATH: la cartella dei platform tools non è nella variabile d’ambiente, oppure va aperto il terminale da lì.

Attivare le opzioni sviluppatore e il debug USB

Le opzioni sviluppatore sono nascoste di default. Si sbloccano toccando sette volte la voce Numero build, che sta in Impostazioni, Informazioni sul telefono. Su Samsung la voce si chiama Informazioni software, su Xiaomi è la versione di HyperOS o MIUI. Al settimo tocco Android avvisa che sei diventato sviluppatore.

Da lì torna nel menu principale, cerca Opzioni sviluppatore e attiva Debug USB. Quando colleghi il cavo, sul telefono compare una finestra con l’impronta RSA del computer: va confermata con Consenti. Se la si nega per sbaglio, il computer resta in stato non autorizzato e nessun comando passa.

Su Android 11 e successivi esiste anche il debug wireless, che evita il cavo. Si attiva dalla stessa schermata, si sceglie Associa dispositivo con codice e si digita il codice a sei cifre sul computer con adb pair. Funziona bene, ma richiede che telefono e computer stiano sulla stessa rete e che il router non isoli i client tra loro.

Un dettaglio che frega molti: il debug USB resta attivo anche dopo aver scollegato il cavo. È comodo, ma significa che chiunque abbia accesso fisico al telefono e un computer con ADB può leggere i dati già autorizzati. Se non lo usi tutti i giorni, spegnilo.

I primi comandi che servono davvero

Il primo è sempre adb devices. Restituisce la lista dei dispositivi collegati: se compare il seriale con la scritta device, la connessione è attiva. Se compare unauthorized, manca la conferma sul telefono. Se la lista è vuota, il problema è nel cavo, nella porta o nei driver.

Il secondo è adb pull, che copia file dal telefono al computer. adb pull /sdcard/DCIM/Camera ./foto scarica l’intera cartella della fotocamera. Il comando inverso è adb push, utile per caricare un file senza passare dal cloud. Funziona sulla memoria condivisa, non sulle cartelle private delle app: quelle restano chiuse senza root.

Per gli screenshot da riga di comando il comando giusto è adb exec-out screencap -p > schermata.png. La variante con adb shell e la redirezione interna corrompe il file su Windows, perché il terminale converte i ritorni a capo. Se ti interessa il tema, nella guida agli screenshot su Android e ai metodi nascosti ci sono anche le scorciatoie da tastiera e dal pannello notifiche.

Con adb logcat si legge il registro di sistema in tempo reale. È rumorosissimo, quindi conviene filtrare: adb logcat -s NomeTag mostra solo le righe di un’app, adb logcat -c svuota il buffer prima di una prova. Serve quando un’app si chiude da sola e vuoi capire perché senza indovinare.

Poi ci sono i comandi di gestione pacchetti. adb shell pm list packages -3 elenca solo le app installate dall’utente, -s solo quelle di sistema. adb install nome.apk installa un pacchetto scaricato sul computer, con -r per sovrascrivere una versione esistente. Se il tema ti interessa, vale la pena leggere anche la guida per installare APK fuori dal Play Store in sicurezza.

Chiudono la lista i comandi di servizio: adb reboot riavvia, adb reboot recovery entra nella recovery, adb shell dumpsys battery mostra livello e temperatura della batteria. Quest’ultimo è più preciso di qualsiasi app di terze parti, perché legge i dati grezzi del sistema.

Disinstallare un’app di sistema senza root

Questa è la funzione che spinge più persone verso ADB. Su molti telefoni le app preinstallate del produttore non si possono disinstallare dal menu, solo disattivare. Con ADB si aggira il limite usando adb shell pm uninstall --user 0 nome.pacchetto: l’app sparisce per l’utente corrente, resta nella partizione di sistema e può essere ripristinata in qualsiasi momento con adb shell cmd package install-existing nome.pacchetto.

Il trucco funziona perché non si tocca il sistema, si toglie solo l’installazione per quell’utente. Ed è reversibile. Non è però un’operazione innocua: disinstallare il pacchetto sbagliato può rompere la fotocamera, il risparmio energetico o le notifiche push di sistema e in alcuni casi impedire l’avvio normale del launcher.

La regola pratica è semplice: mai toccare pacchetti che iniziano con com.android, com.google.android.gms, com.qualcomm, com.mediatek o quelli con system nella descrizione. Se un’app non sai cosa fa, cercane il nome prima di procedere. Il ripristino esiste, ma richiede che il telefono si avvii abbastanza da accettare comandi ADB.

Quando qualcosa va storto

L’errore più comune è device unauthorized. Significa che il telefono non ha accettato l’impronta del computer: sbloccalo, controlla che la finestra di conferma non sia finita dietro altre app e riconnetti il cavo. Se non compare nulla, revoca le autorizzazioni dalle opzioni sviluppatore e riprova.

Il secondo è device offline, spesso legato a un server ADB impallato. adb kill-server seguito da adb start-server risolve nella maggior parte dei casi. Se nemmeno così funziona, cambia cavo: molti cavi da ricarica non hanno i fili dati: è la causa numero uno dei pomeriggi persi.

C’è poi lo scenario che spaventa tutti, il telefono che non si avvia dopo un comando sbagliato. Se il sistema parte ma il launcher va in crash, ADB resta disponibile e puoi ripristinare il pacchetto. Se non parte affatto, l’unica strada è la recovery o il flash del firmware ufficiale, che cancella i dati. Per questo conviene avere un backup completo del telefono senza root aggiornato prima di mettere le mani sulle app di sistema.

Un’ultima nota sui comandi con rm, mv e dd dentro la shell ADB: sono veri comandi Linux e non chiedono conferma. Una barra di troppo nella sintassi può cancellare una cartella intera. Con ADB non c’è il cestino.

Domande frequenti

ADB funziona anche senza root?

Sì, ed è il suo uso normale. ADB gira con i permessi dell’utente shell, sufficienti per file condivisi, installazioni, screenshot, log e disinstallazione per utente. Il root serve solo per modificare la partizione di sistema o accedere ai dati privati delle app.

Serve il cavo per forza?

No, da Android 11 il debug wireless è integrato e si associa con un codice a sei cifre. Il cavo resta più stabile e non dipende dalla rete, quindi è la scelta migliore per operazioni lunghe come un backup da decine di gigabyte.

ADB consuma batteria o dati?

Solo quando è in uso. Il demone è fermo finché non arriva una connessione. Il traffico passa dal cavo o dalla rete locale, non dai dati mobili. L’impatto sulla batteria durante un’operazione è paragonabile a quello di un trasferimento file.

Posso danneggiare il telefono con ADB?

Con i comandi di lettura no. I rischi arrivano da tre direzioni: disinstallazione di pacchetti critici, comandi distruttivi nella shell e flash di firmware sbagliati. Restando su pull, push, screenshot, logcat e install, il margine di errore è minimo.

Le app di sistema disinstallate tornano con gli aggiornamenti?

Dipende. Un aggiornamento OTA importante può ripristinare alcuni pacchetti, soprattutto quelli legati ai servizi Google. In genere le app del produttore restano rimosse per l’utente, ma non è una garanzia: dopo un aggiornamento di sistema conviene ricontrollare la lista.