Come usare i comandi ADB e Fastboot su Android [GUIDA]

Punti chiave

ADB e fastboot sono i due strumenti principali per intervenire su Android da riga di comando: si avviano dal Prompt dei comandi di Windows e si trovano nella cartella platform-tools se hai installato l’SDK Android.
Se non vuoi installare tutto l’SDK, puoi usare anche minimal adb, che contiene solo i file necessari per ADB e fastboot ed è scaricabile da XDA.
Per collegare il telefono via USB non basta il cavo: su Android devi attivare Debug USB nelle Opzioni sviluppatore, altrimenti il comando adb devices non mostrerà il dispositivo come connesso.
Un errore comune è saltare l’autorizzazione RSA quando compare la finestra sul telefono: senza conferma, il debug USB e gli altri comandi ADB non possono partire.
Una limitazione reale è che alcuni comandi funzionano solo in contesti specifici, ad esempio su build userdebug, su app debuggable oppure con vincoli pratici come i tre minuti massimi di screenrecord e l’assenza dell’audio nella registrazione.

Come usare i comandi ADB e fastboot su Android

Come funziona ADB e fastboot

ADB, cioè Android Debug Bridge, è un tool a riga di comando versatile che permette di comunicare con un dispositivo Android e di eseguire azioni come l’installazione e il debug delle app, oltre all’accesso a una shell Unix per lanciare comandi sul dispositivo.

ADB è un programma client-server composto da tre elementi:

Client: invia i comandi dal computer dello sviluppatore e può essere richiamato dal terminale lanciando un comando adb.
Demone (adbd): esegue i comandi sul dispositivo come processo in background su ciascun device.
Server: gestisce la comunicazione tra client e demone ed è eseguito in background sul computer dello sviluppatore.

Quando avvii il client ADB, il client controlla per prima cosa se il server ADB è già attivo; se non lo trova, lo avvia. A quel punto il server si collega alla porta TCP locale 5037 e resta in ascolto dei comandi del client.

Il server imposta poi le connessioni verso i dispositivi attivi in quel momento, individuando anche gli emulatori. Per farlo esegue la scansione delle porte dispari nell’intervallo da 5555 a 5585, cioè l’intervallo usato dai primi 16 emulatori. Quando trova un demone adbd, si connette a quella porta.

La scansione avviene solo sulle porte dispari perché ogni emulatore usa una coppia di porte sequenziali: una porta pari per la console e una porta dispari per le connessioni ADB.

Ecco l’esempio riportato nella guida:

Emulatore 1, console: 5554
Emulatore 1, adb: 5555
Emulatore 2, console: 5556
Emulatore 2, adb: 5557
e così via…

Come si vede, l’emulatore 1 è collegato ad ADB sulla porta 5555 e alla console sulla porta 5554.

Una volta configurate tutte le connessioni, puoi usare i comandi ADB per accedere ai device. Il server, gestendo sia le connessioni ai dispositivi sia i comandi provenienti da più client ADB, permette di controllare qualsiasi device da qualsiasi client o anche da uno script.

Come abilitare il debug USB su un dispositivo Android

Per usare ADB con un dispositivo collegato via USB è necessario attivare il debug USB dalle impostazioni di Android, dentro la voce Opzioni sviluppatore.

Dalla versione Android 4.2 in poi, le Opzioni sviluppatore sono nascoste per impostazione predefinita, ma puoi renderle visibili con una procedura semplice:

Apri Info telefono da Impostazioni > Info telefono e premi 7 volte su Numero di Build finché non compare il pop-up che indica che sei diventato sviluppatore e che le opzioni correlate sono attive.

Ora torna indietro nelle Impostazioni, entra in Sistema e aggiornamenti e cerca la nuova voce Opzioni sviluppatore, su cui dovrai toccare per accedervi.

Tieni presente che questo è un percorso generale: su alcuni dispositivi le Opzioni sviluppatore possono trovarsi in una pagina diversa da Sistema e aggiornamenti. Se non le vedi subito, usa la barra di ricerca in alto nelle Impostazioni.

Attiva Debug USB dentro Opzioni sviluppatore agendo sull’interruttore dedicato e confermando con OK.
Collega il dispositivo via USB con la modalità debug attiva, perché è il requisito necessario per usare i comandi ADB e Fastboot su Android.
Verifica la connessione dalla cartella android_sdk/platform-tools eseguendo adb devices: se tutto è corretto, il dispositivo comparirà come device.

Quando colleghi un dispositivo Android via USB al computer, dalle versioni Android 4.2.2.0 e successive il sistema mostra una finestra in cui ti chiede se accettare una chiave RSA. È una misura di sicurezza che consente il debug solo dopo aver sbloccato il dispositivo e dato conferma esplicita.

Come connettere un dispositivo Android via Wi-Fi invece che USB

ADB viene usato di solito con la USB, ma non è l’unico modo per comunicare con il dispositivo: puoi usarlo anche via Wi-Fi, dopo una configurazione iniziale fatta via USB.

Collega il dispositivo alla stessa rete Wi‑Fi del computer host adb. In questa fase è importante che il punto d’accesso abbia un firewall configurato in modo da supportare ADB.
Disattiva il Bluetooth sul telefono accoppiato se devi connetterti a un dispositivo Wear OS.
Collega il dispositivo via USB al computer host.
Imposta l’ascolto TCP/IP sul dispositivo di destinazione con il comando adb tcpip 5555.
Scollega il cavo USB dal computer.
Recupera l’indirizzo IP del dispositivo Android: per smartphone e tablet segui Impostazioni > Informazioni sul dispositivo > Stato > Indirizzo IP; per Wear OS, invece, vai in Impostazioni > Impostazioni Wi‑Fi > Avanzate > Indirizzo IP.
Connettiti via IP usando il comando adb connect device_ip_adress (il tuo IP).
Controlla lo stato con il comando seguente:

$ adb devices
List of devices attached
device_ip_adress:5555 device

Se la connessione ADB è corretta, il dispositivo risulta connesso. Se invece la connessione si perde, procedi così:

verifica che il computer host sia sulla stessa identica rete Wi‑Fi del dispositivo Android;
riconnettiti con il comando adb connect;
se ancora non funziona, reimposta l’host ADB con adb kill-server e ripeti da capo la procedura di collegamento wireless.

Quando la connessione tra computer e dispositivo Android è attiva, sia via USB sia via Wi‑Fi, puoi eseguire i comandi ADB.

Comandi ADB e opzioni disponibili

Prima di tutto, nella guida originale compaiono anche queste tre opzioni legate ai pacchetti:

-s: installa l’app sulla scheda SD.
-d: consente il downgrade del codice versione, solo per il debug dei pacchetti.
-g: concede tutte le autorizzazioni di runtime.

Opzioni globali

-a Ascolta su tutte le interfacce di rete invece che su localhost.
-d Dirige un comando adb sull’unico dispositivo USB collegato. Restituisce un errore se sono collegati più dispositivi USB.
-e Dirige un comando adb sull’unico emulatore in esecuzione. Restituisce un errore se è in esecuzione più di un emulatore.
-s serial_number Dirige un comando adb verso un dispositivo specifico, identificato dal numero seriale assegnato da adb, ad esempio emulator-5556. Sostituisce il valore memorizzato nella variabile di ambiente $ANDROID_SERIAL.
-H server Indica il nome host del server adb. Il valore predefinito è localhost.
-P port Indica il numero di porta del server adb. Il valore predefinito è 5037.
-L socket Ascolta sul socket del server adb specificato. Il valore predefinito è tcp:localhost:5037.

Comandi generali

devices [-l] Stampa l’elenco di tutti i dispositivi. Con -l includi anche le descrizioni del dispositivo.
help Mostra l’elenco dei comandi adb supportati e la relativa descrizione.
version Mostra il numero di versione di adb.
run-as package_name Esegue comandi sul dispositivo come app, specificata tramite nome_pacchetto. In questo modo lavori con gli stessi permessi che avrebbe l’app, senza richiedere l’accesso root. Può servire su dispositivi non rooted o su emulatori con immagine Play Store. L’app deve essere debuggable.

Comandi di rete

connect host[:port] Connette un dispositivo via TCP/IP. Se non specifichi la porta, viene usata la porta predefinita 5555.
disconnect [host | host:port] Disconnette il dispositivo TCP/IP specificato sulla porta indicata. Se non specifichi host o porta, tutti i dispositivi vengono disconnessi da tutte le porte TCP/IP. Se specifichi solo l’host senza la porta 5555, viene usata la porta predefinita.
forward –list Elenca tutte le connessioni socket inoltrate.
forward [–no-rebind] local remote Inoltra le connessioni socket dalla porta locale indicata alla porta remota corrispondente sul dispositivo. Le porte locali e remote possono essere specificate come segue: tcp:port (per scegliere una porta aperta usa tcp:0), localabstract:unix_domain_socket_name, localreserved:unix_domain_socket_name, localfilesystem:unix_domain_socket_name, dev:character_device_name, jdwp:pid.
forward –remove local Rimuove la connessione socket inoltrata specificata.
reverse –list Elenca tutte le connessioni di presa inversa dal dispositivo.
reverse [–no-rebind] remote local Inverte una connessione socket. L’opzione –no-rebind fa fallire l’operazione se il socket specificato è già associato a un comando reverse precedente. Le porte local e remote possono essere specificate come tcp:port (per scegliere una porta aperta usa tcp:0), localabstract:unix_domain_socket_name, localreserved:unix_domain_socket_name, localfilesystem:unix_domain_socket_name.
reverse –remove remote Rimuove la connessione inversa specificata dal dispositivo.
reverse –remove-all Rimuove tutte le connessioni della presa inversa dal dispositivo.

Comandi di trasferimento file

push local remote Copia file e cartelle dal computer locale a una posizione remota sul dispositivo.
pull [-a] remote local Copia file e cartelle dal dispositivo remoto al computer. Con -a conserva timestamp e modalità del file.
sync [system|vendor|oem|data|all] Sincronizza una build locale dalla posizione specificata in $ANDROID_PRODUCT_OUT verso il dispositivo. I file modificati vengono copiati dalla partizione indicata; il default è sincronizzare tutte le partizioni. Questo comando si usa solo quando si crea l’origine della piattaforma Android. Gli sviluppatori di app non devono usarlo. La variabile $ANDROID_PRODUCT_OUT viene impostata automaticamente dal sistema di build Android per contenere la posizione delle immagini di sistema. In genere non è necessario impostarla quando si esegue adb sync, ma può essere utile se non sei in un albero di build, oppure se stai sincronizzando tra alberi di build senza cambiare contesto.

$ ANDROID_PRODUCT_OUT = / out / target / product / generic
adb sync

Comandi di installazione dell’app

install [options] package Installa i pacchetti sul dispositivo. Le opzioni possibili sono: -l app di blocco in avanti, -r sostituisci l’app esistente, -t consenti pacchetti di test. Se l’APK è creato con un SDK di anteprima per sviluppatori, cioè se targetSdkVersion è una lettera anziché un numero, devi includere l’opzione -t quando installi un APK di test.
install-multiple [options] packages Usa le stesse opzioni di install con in più -p per l’installazione parziale dell’app.
uninstall [-k] package Rimuove il pacchetto di app dal dispositivo. Con -k mantieni i dati e le directory della cache.

Backup e ripristino dei comandi

backup[ ] -f file [ -apk| -noapk] [ -obb| -noobb] [ -shared| -noshared] [ -all] [ -system| [ -nosystem] package_names Scrive un archivio dei dati del dispositivo su file. Se non specifichi un nome file, viene usato il file predefinito. L’elenco dei pacchetti è facoltativo quando specifichi le opzioni. Le altre opzioni servono così: -apk | -noapk esegue o non esegue il backup dei file .apk; predefinito -noapk. -obb | -noobb esegue o non esegue il backup dei file .obb; predefinito -noobb. -shared | -noshared esegue o non esegue il backup dello spazio di archiviazione condiviso; predefinito -noshared. -all esegue il backup di tutte le app installate. -system | -nosystem include o esclude le app di sistema quando esegui il backup di tutte le app installate con -all; il valore predefinito è -system.
restore file Ripristina il contenuto del dispositivo dal file indicato.

Comandi di debug

bugreport path Stampa un bugreport nel percorso specificato. Se il percorso è una directory, il bug report viene salvato lì usando il nome file predefinito bugreport.zip. Viene stampato su stdout sui dispositivi che non supportano i bug report compressi.
jdwp Stampa l’elenco dei processi JDWP disponibili su un determinato dispositivo. Serve per connettersi a uno specifico processo JDWP. Esempio: adb forward tcp:8000 jdwp:472 e poi jdb -attach localhost:8000.
logcat [-help] [option] [filter-spec] Stampa i dati del registro sullo schermo. Per i dettagli sul comando logcat e sulla variabile di ambiente $ANDROID_LOG_TAGS, la guida rimanda al filtro dell’output del registro. La variabile $ADB_TRACE contiene un elenco separato da virgole delle informazioni di debug da registrare. I valori possibili sono all, adb, sockets, packets, rwx, usb, sync, sysdeps, transport e jdwp.

Comandi di sicurezza

disable-verity Disabilita il controllo dm-verity sulle build userdebug. dm-verity è una opzione che garantisce che, all’avvio del dispositivo, questo si trovi nello stesso stato in cui si trovava al momento dell’ultimo utilizzo.
enable-verity Riattiva il controllo dm-verity sulle build userdebug. dm-verity garantisce che, all’avvio del dispositivo, questo si trovi nello stesso stato in cui si trovava al momento dell’ultimo utilizzo.
keygen file Genera chiavi crittografate RSA pubbliche e private per adb. La chiave privata viene memorizzata nel file, mentre la chiave pubblica viene memorizzata in file.pub. Una coppia di chiavi RSA è necessaria quando usi adb per connetterti via USB per la prima volta. Devi accettare la chiave RSA del computer host per concedere esplicitamente l’accesso adb al dispositivo. Usa la variabile d’ambiente $ANDROID_VENDOR_KEYS per puntare a un file o a una directory contenente coppie di chiavi di autenticazione RSA a 2048 bit generate con keygen. Queste coppie si aggiungono a quelle generate dal server adb.

Quando il server adb ha bisogno di una chiave, prima cerca nella directory dell’archivio chiavi del server adb. Se non trova nulla, controlla la variabile $ANDROID_VENDOR_KEYS. Se non trova ancora chiavi, il server adb locale genera e salva una nuova coppia nella directory dell’archivio chiavi del server adb. Per questo motivo, solo un OEM che crea un nuovo dispositivo Android deve eseguire adb keygen autonomamente.

Per impostazione predefinita, le coppie di chiavi generate dal server adb vengono memorizzate nelle seguenti directory come adbkey per la chiave privata e adbkey.pub per la chiave pubblica:

Linux e Mac: $HOME/.android.
Windows: %USERPOFILE%.android.

Comandi di scripting

wait-for [-transport] -state Attende che il dispositivo si trovi nello stato specificato. I valori di state possono essere device, recovery, sideload o bootloader. I valori di transport possono essere usb, local o any.
get-state Stampa lo stato adb di un dispositivo. Lo stato adb può essere print offline, bootloader o device.
get-serialno Stampa la stringa del numero seriale del dispositivo adb.
get-devpath Stampa il percorso del dispositivo adb.
remount Rimonta le partizioni /system, /vendor e /oem in modalità lettura-scrittura.
reboot [bootloader | recovery | sideload | sideload-auto-reboot ] Riavvia il dispositivo. Il comando parte automaticamente nell’immagine di sistema, ma supporta anche bootloader e recovery. Con bootloader riavvii in modalità bootloader. Con recovery riavvii in modalità ripristino. Con sideload riavvii in modalità recovery e sideload. Con sideload-auto-reboot il comportamento è uguale a sideload, ma il dispositivo si riavvia dopo il sideload.
sideload otapackage Esegue il sideload, cioè installa, il pacchetto OTA completo specificato sul dispositivo.
root Riavvia adbd con i permessi di root.
unroot Riavvia adbd senza autorizzazioni di root.
usb Riavvia il server adb in ascolto su USB.
tcpip port-number Riavvia il server adb in ascolto su TCP nella porta specificata.

Comandi di debug interni

start-server Controlla se il processo del server adb è in esecuzione.
kill-server Termina il processo del server adb.
reconnect Forza una riconnessione dall’host.
reconnect device Forza una riconnessione dal dispositivo.

Comandi di shell

shell Avvia una shell interattiva remota nel dispositivo di destinazione.
shell -e escape_char [-n] [-T] [-t] [-x] [command] Esegue un comando shell sul dispositivo di destinazione e poi esce dalla shell remota. Le opzioni disponibili sono: -e per specificare un carattere di escape o none se non vuoi usarne uno; se non specifichi un valore viene usato il carattere predefinito, cioè un trattino (–). -n non legge stdin. -T disattiva l’allocazione di pseudo-terminal utility (PTY). -t impone l’allocazione PTY. -x disabilita i codici di uscita remota e la separazione stdout/stderr.
emu command Esegue un comando della console di emulazione.

Puoi usare il comando shell per inviare comandi al dispositivo tramite adb, sia entrando nella shell remota sia senza entrarci.

Per eseguire un singolo comando senza aprire la shell remota, usa questo formato:

adb [-d |-e | -s serial_number] shell shell_command

Oppure entra nella shell remota così:

adb [-d | -e | -s serial_number] shell

Quando vuoi uscire dalla shell remota, premi Ctrl + D oppure digita exit.

I binari del comando shell si trovano nel file system del dispositivo in /system/bin/.

All’interno di una shell adb puoi usare anche lo strumento activity manager (am) per avviare attività, forzare l’interruzione di processi, trasmettere intent, modificare le proprietà dello schermo del dispositivo e altro ancora. In una shell, la sintassi è:

am command

Puoi anche inviare un comando di gestione attività direttamente da ADB senza entrare in una shell:

adb shell am start -a android.intent.action.VIEW

Comandi di Gestione attività disponibili

start [options] intent Avvia un Activity specificato da intent. Le opzioni sono: -D abilita il debug; -W attende il completamento del lancio; –start-profiler file avvia il profiler e invia i risultati a file; -P file è simile a –start-profiler, ma la profilazione si interrompe quando l’app diventa inattiva; -R count ripete count volte l’avvio dell’attività e, prima di ogni ripetizione, l’attività principale viene terminata; -S forza l’arresto dell’app di destinazione prima di avviare l’attività; –opengl-trace abilita la traccia delle funzioni OpenGL; –user user_id | current specifica quale utente usare, oppure quello corrente se non indicato.
startservice [options] intent Avvia il Service specificato da intent. L’opzione è –user user_id | current, per specificare quale utente usare oppure quello corrente se non indicato.
force-stop package Forza l’interruzione di tutto ciò che è associato al package indicato, cioè il nome del pacchetto dell’app.
kill [options] package Elimina tutti i processi associati al package indicato. Questo comando chiude solo i processi che possono essere terminati in sicurezza e che non incidono sull’esperienza utente. Le opzioni includono –user user_id | all | current per specificare l’utente da cui uccidere i processi; se non specifichi nulla, vale per tutti gli utenti.
kill-all Uccide tutti i processi in background.
broadcast [options] intent Emette un intent di trasmissione. L’opzione [–user user_id | all | current] specifica a quale utente inviare il comando; se non indicato, viene inviato a tutti gli utenti.
instrument [options] component Avvia il monitoraggio con un’istanza di Instrumentation. Di solito il component ha la forma test_package/runner_class. Le opzioni sono: -r per stampare i risultati grezzi invece del report decodificato; da usare con [-e perf true] per ottenere output non elaborati per misurazioni delle prestazioni; -e name value imposta l’argomento name al valore specificato, ed è comune nei test runner usare la forma -e testrunner_flag value[,value…]; -p file scrive i dati di profilo su file; -w attende la fine della strumentazione prima di restituire il controllo, ed è richiesto per i test runner; –no-window-animation disattiva le animazioni delle finestre durante l’esecuzione; –user user_id | current specifica quale utente esegue la strumentazione.
profile start process file Avvia il profiler del processo e scrive i risultati su file.
profile stop process Interrompe il profiler del processo.
dumpheap [options] process file Scarica l’heap del processo e scrive su file. Le opzioni sono: –user [user_id | current] per specificare l’utente del processo quando si fornisce un nome di processo; in assenza di indicazione usa l’utente corrente. -n scarica l’heap nativo invece di quello gestito.
set-debug-app [options] package Imposta l’app indicata per il debug. Le opzioni sono: -w attende il debugger all’avvio dell’app; –persistent mantiene questo valore.
clear-debug-app Cancella il pacchetto precedente impostato per il debug con set-debug-app.
monitor [options] Avvia il monitoraggio per crash o ANR. L’opzione –gdb avvia gdbserv sulla porta specificata in caso di crash/ANR.
screen-compat {on | off} package Controlla la modalità di compatibilità dello schermo del package.
display-size [reset | widthxheight] Ignora le dimensioni di visualizzazione del dispositivo. È utile per testare l’app su diverse dimensioni dello schermo, simulando un display piccolo su un dispositivo grande e viceversa. Esempio: am display-size 1280×800.
display-density dpi Ignora la densità del display del dispositivo. Serve per testare l’app su densità diverse, ad esempio simulando un ambiente ad alta densità con uno schermo a bassa densità e viceversa. Esempio: am display-density 480.
to-uri intent Stampa la specifica di intent indicata come URI.
to-intent-uri intent Stampa la specifica di intent indicata come intent:URI.

Specifica per argomenti di intent

Per i comandi del gestore attività che accettano un argomento intent, puoi specificarlo con queste opzioni:

-a action Specifica l’azione intent, come android.intent.action.VIEW. Puoi indicarla una sola volta.
-d data_uri Specifica l’URI dei dati dell’intent, ad esempio content://contacts/people/1. Puoi indicarla una sola volta.
-t mime_type Specifica il tipo MIME dell’intent, ad esempio image/png. Puoi indicarla una sola volta.
-c category Specifica una categoria di intent, come android.intent.category.APP_CONTACTS.
-n component Specifica il nome del componente con prefisso del nome del pacchetto per creare un intent esplicito, ad esempio com.example.app/.ExampleActivity.
-f flags Aggiunge flag all’intent, come supportato da setFlags().
–esn extra_key Aggiunge un extra nullo. Questa opzione non è supportata per intent URI.
-e | –es extra_key extra_string_value Aggiunge dati stringa come coppia chiave-valore.
–ez extra_key extra_boolean_value Aggiunge dati booleani come coppia chiave-valore.
–ei extra_key extra_int_value Aggiunge dati interi come coppia chiave-valore.
–el extra_key extra_long_value Aggiunge dati long come coppia chiave-valore.
–ef extra_key extra_float_value Aggiunge dati float come coppia chiave-valore.
–eu extra_key extra_uri_value Aggiunge dati URI come coppia chiave-valore.
–ecn extra_key extra_component_name_value Aggiunge un nome componente che viene convertito e passato come oggetto ComponentName.
–eia extra_key extra_int_value[,extra_int_value…] Aggiunge un array di interi.
–ela extra_key extra_long_value[,extra_long_value…] Aggiunge una serie di long.
–efa extra_key extra_float_value[,extra_float_value…] Aggiunge una serie di float.
–grant-read-uri-permission Include il flag FLAG_GRANT_READ_URI_PERMISSION.
–grant-write-uri-permission Include il flag FLAG_GRANT_WRITE_URI_PERMISSION.
–debug-log-resolution Include il flag FLAG_DEBUG_LOG_RESOLUTION.
–exclude-stopped-packages Include il flag FLAG_EXCLUDE_STOPPED_PACKAGES.
–include-stopped-packages Include il flag FLAG_INCLUDE_STOPPED_PACKAGES.
–activity-brought-to-front Include il flag FLAG_ACTIVITY_BROUGHT_TO_FRONT.
–activity-clear-top Include il flag FLAG_ACTIVITY_CLEAR_TOP.
–activity-clear-when-task-reset Include il flag FLAG_ACTIVITY_CLEAR_WHEN_TASK_RESET.
–activity-exclude-from-recents Include il flag FLAG_ACTIVITY_EXCLUDE_FROM_RECENTS.
–activity-launched-from-history Include il flag FLAG_ACTIVITY_LAUNCHED_FROM_HISTORY.
–activity-multiple-task Include il flag FLAG_ACTIVITY_MULTIPLE_TASK.
–activity-no-animation Include il flag FLAG_ACTIVITY_NO_ANIMATION.
–activity-no-history Include il flag FLAG_ACTIVITY_NO_HISTORY.
–activity-no-user-action Include il flag FLAG_ACTIVITY_NO_USER_ACTION.
–activity-previous-is-top Include il flag FLAG_ACTIVITY_PREVIOUS_IS_TOP.
–activity-reorder-to-front Include il flag FLAG_ACTIVITY_REORDER_TO_FRONT.
–activity-reset-task-if-needed Include il flag FLAG_ACTIVITY_RESET_TASK_IF_NEEDED.
–activity-single-top Include il flag FLAG_ACTIVITY_SINGLE_TOP.
–activity-clear-task Include il flag FLAG_ACTIVITY_CLEAR_TASK.
–activity-task-on-home Include il flag FLAG_ACTIVITY_TASK_ON_HOME.
–receiver-registered-only Include il flag FLAG_RECEIVER_REGISTERED_ONLY.
–receiver-replace-pending Include il flag FLAG_RECEIVER_REPLACE_PENDING.
–selector Richiede l’uso delle opzioni -d e -t per impostare i dati e il tipo dell’intent.
URI component package Puoi specificare direttamente un URI, il nome del pacchetto e il nome del componente quando non sono qualificati da una delle opzioni precedenti. Se l’argomento contiene : viene considerato un URI; se contiene / viene considerato un nome di componente; altrimenti viene considerato un nome di pacchetto.

Per completare la parte ADB, la guida passa anche allo strumento pm, cioè il package manager. Dentro una shell adb puoi impartire comandi con pm per eseguire azioni e query sui pacchetti installati sul dispositivo. In una shell la sintassi è:

pm command

PuoI anche inviare un comando package manager direttamente da adb senza entrare in una shell remota, per esempio:

adb shell pm uninstall com.example.MyApp

Comandi di gestione pacchetti disponibili

filter Stampa tutti i pacchetti, oppure solo quelli il cui nome contiene il testo filter. Le opzioni sono: -f per mostrare il file associato; -d per mostrare solo i pacchetti disabilitati; -e per mostrare solo i pacchetti abilitati; -s per i pacchetti di sistema; -3 per i pacchetti di terze parti; -i per vedere l’installer; -u per includere anche i pacchetti disinstallati; –user user_id per scegliere lo spazio utente da interrogare.
list permission-groups Stampa tutti i gruppi di autorizzazioni noti.
list permissions [options] group Stampa tutte le autorizzazioni conosciute, oppure solo quelle del gruppo indicato. Le opzioni sono: -g per organizzare per gruppo; -f per stampare tutte le informazioni; -s per un breve riepilogo; -d per elencare solo le autorizzazioni pericolose; -u per elencare solo le autorizzazioni visibili agli utenti.
list instrumentation [options] Elenca tutti i pacchetti di test. Le opzioni sono: -f per mostrare il file APK del pacchetto di test; target_package per elencare i pacchetti di test solo per questa app.
list features Stampa tutte le funzionalità del sistema.
list libraries Stampa tutte le librerie supportate dal dispositivo corrente.
list users Stampa tutti gli utenti presenti sul sistema.
path package Stampa il percorso dell’APK del package indicato.
install [options] path Installa un pacchetto specificato da path nel sistema. Le opzioni sono: -l per installare con forward lock; -r per reinstallare un’app esistente mantenendo i dati; -t per consentire l’installazione di APK di test. Gradle genera un APK di test quando esegui o esegui il debug della tua app o usi il comando Android Studio Build > Build APK. Se l’APK è creato con un SDK di anteprima per sviluppatori, devi includere l’opzione -t quando installi un APK di test. Le altre opzioni sono: -i installer_package_name per specificare il nome del pacchetto di installazione; -s per installare il pacchetto nella memoria di massa condivisa, ad esempio la sdcard; -f per installare il pacchetto nella memoria interna di sistema; -d per consentire il downgrade del codice versione; -g per concedere tutte le autorizzazioni elencate nel manifest dell’app.
uninstall [options] package Rimuove un pacchetto dal sistema. Con -k conservi le directory dei dati e della cache dopo la rimozione.
clear package Elimina tutti i dati associati a un pacchetto.
enable package_or_component Abilita il pacchetto o componente indicato, scritto come pacchetto/classe.
disable package_or_component Disabilita il pacchetto o componente indicato, scritto come pacchetto/classe.
disable-user [options] package_or_component Le opzioni includono –user user_id, cioè l’utente da disabilitare.
grant package_name permission Concede un’autorizzazione a un’app. Su Android 6.0 e versioni successive l’autorizzazione può essere qualsiasi permesso dichiarato nel manifest; su Android 5.1 e precedenti deve essere un’autorizzazione opzionale definita dall’app.
revoke package_name permission Revoca un’autorizzazione da un’app. Anche qui, su Android 6.0 e versioni successive può essere qualsiasi permesso del manifest, mentre su Android 5.1 e precedenti deve essere un’autorizzazione opzionale definita dall’app.
set-install-location location Cambia il percorso di installazione predefinito. I valori sono: 0 auto, cioè il sistema decide la posizione migliore; 1 interno, installazione sulla memoria interna; 2 esterno, installazione su supporto esterno. Nota: è pensato solo per il debug e può causare malfunzionamenti o comportamenti indesiderati.
get-install-location Restituisce il percorso di installazione corrente. I valori di ritorno sono: 0 [auto] il sistema decide la posizione migliore; 1 [internal] installazione sulla memoria interna del dispositivo; 2 [external] installazione su supporti esterni.
set-permission-enforced permission [true | false] Specifica se l’autorizzazione data deve essere applicata.
trim-caches desired_free_space Elimina file di cache per raggiungere lo spazio libero richiesto.
create-user user_name Crea un nuovo utente con il nome indicato e stampa il relativo identificativo utente.
remove-user user_id Rimuove l’utente indicato cancellando tutti i dati associati a quell’utente.
get-max-users Stampa il numero massimo di utenti supportati dal dispositivo.

La guida prosegue poi con dpm, cioè il Device Policy Manager, utile per sviluppare e testare app di gestione dei dispositivi o di altre aziende. Lo strumento serve per controllare l’app di amministrazione attiva o modificare i dati di stato di una politica sul dispositivo. In una shell, la sintassi è:

dpm command

Puoi anche inviare un comando di gestione dei criteri del dispositivo direttamente da adb senza entrare in una shell remota:

adb shell dpm command

Comandi di gestione dei criteri dispositivo disponibili

set-active-admin [options] component Imposta il componente come amministratore attivo. L’opzione –user user_id specifica l’utente di destinazione; puoi usare anche –user current per selezionare l’utente corrente.
set-profile-owner [options] component Imposta il componente come amministratore attivo e il suo pacchetto come proprietario del profilo per un utente esistente. Le opzioni sono –user user_id per scegliere l’utente di destinazione oppure –user current per l’utente corrente, e –name name per specificare il nome dell’organizzazione leggibile dall’uomo.
set-device-owner [options] component Imposta il componente come amministratore attivo e il suo pacchetto come proprietario del dispositivo. Le opzioni sono –user user_id per l’utente di destinazione oppure –user current per l’utente corrente, e –name name per il nome dell’organizzazione leggibile dall’uomo.
remove-active-admin [options] component Disattiva un amministratore attivo. L’app deve dichiarare android:testOnly nel manifest. Questo comando rimuove anche i proprietari di dispositivi e profili. L’opzione –user user_id specifica l’utente di destinazione; puoi usare anche –user current per l’utente corrente.

Fare uno screenshot e registrare lo schermo

Il comando screencap è un’utilità di shell per acquisire uno screenshot del display di un dispositivo. In una shell, la sintassi è:

screencap filename

Per usare screencap dalla riga di comando, la guida mostra questo esempio:

adb shell screencap /sdcard/screen.png

Ecco una sessione di esempio che usa la shell adb per acquisire lo screenshot e poi il comando pull per scaricare il file dal dispositivo:

$ adb shell
shell@ $ screencap /sdcard/screen.png
shell@ $ exit
$ adb pull /sdcard/screen.png

Per registrare un video, il comando screenrecord è un’utilità shell che registra la visualizzazione dei dispositivi con Android 4.4 (livello API 19) e versioni successive. L’utility salva l’attività dello schermo in un file MPEG-4, utile per video promozionali, formazione, debug e test.

In una shell, la sintassi è:

screenrecord [options] filename

Per usare screenrecord dalla riga di comando, digita:

adb shell screenrecord /sdcard/demo.mp4

Per interrompere la registrazione premi Control + C su Mac usi Command + C. In alternativa, la registrazione si ferma automaticamente dopo tre minuti o al limite impostato da –time-limit. Per avviare la registrazione, esegui il comando screenrecord e poi usa pull per scaricare il video dal dispositivo al computer host.

Esempio di sessione:

$ adb shell
shell@ $ screenrecord –verbose /sdcard/demo.mp4
(press Control + C to stop)
shell@ $ exit
$ adb pull /sdcard/demo.mp4

L’utility screenrecord può registrare in qualsiasi risoluzione e bit rate supportati, mantenendo le proporzioni del display del dispositivo. Di default registra la risoluzione e l’orientamento nativi dello schermo, con una durata massima di tre minuti.

Le limitazioni di screenrecord sono queste:

l’audio non viene registrato insieme al video;
la registrazione video non è disponibile sui dispositivi con sistema operativo Wear;
alcuni dispositivi potrebbero non riuscire a registrare con la risoluzione nativa del display; in caso di problemi prova una risoluzione più bassa;
la rotazione dello schermo durante la registrazione non è supportata; se lo schermo ruota, parte dell’immagine può essere tagliata.

Opzioni screenrecord

–help Mostra sintassi e opzioni del comando.
–size widthxheight Imposta le dimensioni del video, ad esempio 1280×720. Il valore predefinito è la risoluzione nativa del dispositivo, se supportata, oppure 1280×720 in caso contrario. Per risultati migliori usa una dimensione supportata dal codificatore AVC del dispositivo.
–bit-rate rate Imposta il bit rate del video, in megabit al secondo. Il valore predefinito è 4Mbps. Puoi aumentarlo per migliorare la qualità, ma otterrai file più grandi. Esempio: screenrecord –bit-rate 6000000 /sdcard/demo.mp4.
–time-limit time Imposta il tempo massimo di registrazione, in secondi. Il valore predefinito e massimo è 180 secondi, cioè 3 minuti.
–rotate Ruota l’output di 90 gradi. La funzione è sperimentale.
–verbose Mostra le informazioni di log nella riga di comando. Se non la imposti, l’utility non visualizza informazioni durante l’esecuzione.

Profili ART per le app

A partire da Android 7.0 (livello API 24), Android Runtime (ART) raccoglie i profili di esecuzione delle app installate per ottimizzarne le prestazioni. Puoi esaminare i profili raccolti per capire quali metodi vengono eseguiti più spesso e quali classi vengono usate durante l’avvio dell’app.

Per produrre un file di testo con le informazioni del profilo, usa:

adb shell cmd package dump-profiles package

Per recuperare il file prodotto, usa:

adb pull /data/misc/profman/package.txt

Altri comandi shell

Per vedere tutti i programmi di shell disponibili, usa:

adb shell ls /system/bin

La guida è disponibile per la maggior parte dei comandi. La tabella seguente elenca alcuni dei comandi shell adb più comuni.

Altri comandi della shell adb

dumpsys Scarica i dati di sistema sullo schermo.
dumpstate Esegue il dump dello stato su un file.
logcat [option]… [filter-spec]… Abilita la registrazione di sistema e app e stampa l’output sullo schermo.
dmesg Stampa i messaggi di debug del kernel sullo schermo.
start Avvia o riavvia un dispositivo.
stop Interrompe l’esecuzione di un dispositivo.
sqlite3 Avvia il programma da riga di comando sqlite3. Lo strumento include comandi come .dump, che stampa il contenuto di una tabella, e .schema, che mostra l’istruzione SQL CREATE di una tabella esistente. Puoi anche eseguire comandi SQLite al volo. I database SQLite3 sono memorizzati in ./data/data/package_name/databases/. Esempio: $ adb -s emulator-5554 shell, poi $ sqlite3 /data/data/com.example.app/databases/rssitems.db, quindi Versione SQLite 3.3.12 e Immettere “.help” per istruzioni.

Domande Frequenti

ADB funziona solo con il cavo USB?

No. La USB è il metodo più comune, ma ADB può funzionare anche via Wi‑Fi dopo una configurazione iniziale fatta via USB con adb tcpip 5555 e adb connect.

Perché il telefono non compare con adb devices?

Di solito perché non hai attivato il debug USB, non hai autorizzato la chiave RSA oppure il dispositivo non è collegato correttamente al computer. Se la connessione è wireless, controlla anche che sia sulla stessa rete Wi‑Fi.

Dove trovo le Opzioni sviluppatore se non compaiono?

Su Android 4.2 e versioni successive devi prima toccare 7 volte Numero di Build dentro Info telefono. Poi, in genere, le trovi in Sistema e aggiornamenti, ma su alcuni dispositivi il percorso cambia e conviene usare la ricerca nelle Impostazioni.

Posso usare screenrecord per registrare l’audio del telefono?

No, l’audio non viene registrato insieme al video. Inoltre la durata massima predefinita è di tre minuti e la rotazione dello schermo durante la registrazione non è supportata.

Quali comandi richiedono più attenzione su build specifiche?

Comandi come disable-verity, enable-verity o alcune operazioni di debug e installazione hanno limiti legati al tipo di build, alle autorizzazioni dell’app o alla presenza di requisiti come debuggable e userdebug.

Abbiamo quindi visto come usare i comandi ADB e Fastboot su Android. Tutti i comandi riportati sono stati recuperati dalla fonte ufficiale developer.android.com e, per eventuali dubbi di traduzione o per leggere tutte le descrizioni nella lingua originale, puoi consultare la FONTE.