Bridge di debug Android (adb)

Android Debug Bridge (adb) è uno strumento a riga di comando versatile che ti consente di comunicare con un dispositivo. Il comando adb facilita una serie di azioni del dispositivo, come l'installazione e il debug delle app. adb fornisce l'accesso a una shell Unix che puoi utilizzare per eseguire una serie di comandi su un dispositivo. Si tratta di un programma client-server che include tre componenti:

  • Un client, che invia comandi. Il client viene eseguito sulla macchina di sviluppo. Puoi richiamare un client da un terminale della riga di comando eseguendo un comando adb.
  • Un daemon (adbd), che esegue comandi su un dispositivo. Il daemon viene eseguito come processo in background su ogni dispositivo.
  • Un server, che gestisce la comunicazione tra il client e il daemon. Il server viene eseguito come processo in background sulla macchina di sviluppo.

adb è incluso nel pacchetto Strumenti della piattaforma SDK Android. Scarica questo pacchetto con SDK Manager, che lo installa in android_sdk/platform-tools/. Se vuoi il pacchetto autonomo SDK Android Platform Tools, scaricalo qui.

Per informazioni su come connettere un dispositivo per l'utilizzo tramite adb, incluso come utilizzare l'assistente per la connessione per risolvere i problemi comuni, vedi Eseguire app su un dispositivo hardware.

Come funziona adb

Quando avvii un client adb, questo verifica innanzitutto se è già in esecuzione un processo del server adb. In caso contrario, avvia il processo del server. All'avvio, il server si associa alla porta TCP locale 5037 e rimane in ascolto dei comandi inviati dai client adb.

Nota:tutti i client adb utilizzano la porta 5037 per comunicare con il server adb.

Il server configura quindi le connessioni a tutti i dispositivi in esecuzione. Individua gli emulatori eseguendo la scansione delle porte con numeri dispari nell'intervallo da 5555 a 5585, ovvero l'intervallo utilizzato dai primi 16 emulatori. Quando il server trova un daemon adb (adbd), configura una connessione a quella porta.

Ogni emulatore utilizza una coppia di porte sequenziali: una porta con numero pari per le connessioni alla console e una porta con numero dispari per le connessioni adb. Ad esempio:

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

Come mostrato, l'emulatore connesso a adb sulla porta 5555 è lo stesso dell'emulatore la cui console è in ascolto sulla porta 5554.

Una volta che il server ha configurato le connessioni a tutti i dispositivi, puoi utilizzare i comandi adb per accedere a questi dispositivi. Poiché il server gestisce le connessioni ai dispositivi e gestisce i comandi di più client adb, puoi controllare qualsiasi dispositivo da qualsiasi client o da uno script.

Attivare il debug ADB sul dispositivo

Per utilizzare adb con un dispositivo connesso tramite USB, devi attivare il debug USB nelle impostazioni di sistema del dispositivo, in Opzioni sviluppatore. Su Android 4.2 (livello API 17) e versioni successive, la schermata Opzioni sviluppatore è nascosta per impostazione predefinita. Per renderlo visibile, attiva le Opzioni sviluppatore.

Ora puoi connettere il dispositivo tramite USB. Puoi verificare che il dispositivo sia connesso eseguendo adb devices dalla directory android_sdk/platform-tools/. Se è connesso, vedrai il nome del dispositivo elencato come "dispositivo".

Nota:quando connetti un dispositivo con Android 4.2.2 (livello API 17) o versioni successive, il sistema mostra una finestra di dialogo che chiede se accettare una chiave RSA che consenta il debug tramite questo computer. Questo meccanismo di sicurezza protegge i dispositivi degli utenti perché garantisce che il debug USB e altri comandi adb non possano essere eseguiti a meno che tu non riesca a sbloccare il dispositivo e confermare la finestra di dialogo.

Per maggiori informazioni su come connettersi a un dispositivo tramite USB, leggi Eseguire app su un dispositivo hardware.

Connettersi a un dispositivo tramite Wi-Fi

Nota:le istruzioni riportate di seguito non si applicano ai dispositivi Wear con Android 11 (livello API 30). Per ulteriori informazioni, consulta la guida al debug di un'app per Wear OS.

Android 11 (livello API 30) e versioni successive supportano la distribuzione e il debug wireless dell'app dalla workstation utilizzando Android Debug Bridge (adb). Ad esempio, puoi distribuire l'app di cui è possibile eseguire il debug su più dispositivi remoti senza dover collegare fisicamente il dispositivo tramite USB. In questo modo, non è più necessario risolvere i problemi comuni di connessione USB, come l'installazione dei driver.

Android 17, insieme ad adb 37.0.0, introduce adb Wi-Fi 2.0, che risolve molti problemi di usabilità della versione precedente. In particolare, il dispositivo si connetterà automaticamente alla workstation quando si connette a una rete attendibile per il debug wireless.

Prima di iniziare a utilizzare il debug wireless:

  • Assicurati che la workstation e il dispositivo siano connessi alla stessa rete wireless.

  • Assicurati che sul tuo dispositivo sia installato Android 11 (livello API 30) o versioni successive per smartphone o Android 13 (livello API 33) o versioni successive per TV e WearOS. Per ulteriori informazioni, consulta Controlla e aggiorna la versione di Android.

  • Sulla workstation, esegui l'aggiornamento all'ultima versione degli strumenti della piattaforma SDK.

Per utilizzare il debug wireless, devi accoppiare il dispositivo alla workstation utilizzando un codice QR o un codice di accoppiamento. La workstation e il dispositivo devono essere connessi alla stessa rete wireless. Per accoppiarlo al dispositivo, segui questi passaggi:

Nota:devi accoppiare il dispositivo alla workstation una sola volta. Il dispositivo rimarrà accoppiato alla workstation finché non lo dimentichi esplicitamente o non revochi le autorizzazioni di debug adb sul dispositivo. Il dispositivo e la workstation si connetteranno automaticamente quando si trovano sulla stessa rete.

  1. Attiva le opzioni sviluppatore sul tuo dispositivo.

  2. Sul dispositivo, tocca Debug wireless:

    Screenshot di uno smartphone Pixel che mostra il prompt di debug wireless.
    Figura 1. Il prompt di debug wireless su uno smartphone Google Pixel.

  3. Consentire il debug wireless sulla rete. Tieni presente che se selezioni la casella di controllo Consenti sempre su questa rete, la rete diventa una rete di debug wireless attendibile. Il dispositivo consentirà sempre il debug wireless su questa rete non appena si connette alla rete.

    4. Screenshot di uno smartphone Google Pixel che mostra l'impostazione Sistemi di debug wireless.
    Figura 2. L'impostazione Debug wireless su uno smartphone Google Pixel.

    Nota:gli utenti di Android Studio possono accoppiare il proprio dispositivo con un codice QR, selezionare Accoppia dispositivo con codice QR e scansionare il codice QR ottenuto dalla finestra di dialogo Accoppia dispositivi tramite Wi-Fi in Android Studio.

  4. Sul dispositivo, seleziona Accoppia tramite codice di accoppiamento e prendi nota dell'indirizzo IP, del numero di porta e del codice di accoppiamento visualizzati sul dispositivo.

  5. Sulla workstation, apri una finestra del terminale e vai a android_sdk/platform-tools.

  6. Nel terminale della workstation, esegui adb pair ipaddr:port. Utilizza l'indirizzo IP e il numero di porta indicati sopra.

  7. Quando richiesto, inserisci il codice di accoppiamento, come mostrato di seguito.

    Screenshot dell'accoppiamento sulla riga di comando.
    Figura 3. Un messaggio indica che l'accoppiamento del dispositivo è andato a buon fine.

  8. Dopo l'accoppiamento del dispositivo, verifica che sia connesso.Ora puoi utilizzare il dispositivo in modalità wireless, in modo simile a come faresti con una connessione USB.

    Per disaccoppiare la workstation, vai a Debug wireless sul dispositivo. Tocca il nome della tua postazione di lavoro nella sezione Dispositivi accoppiati e seleziona Dissocia. In alternativa, puoi fare clic su Revoca autorizzazioni debug adb nella pagina Impostazioni del dispositivo per annullare l'accoppiamento della workstation e di tutte le altre workstation accoppiate in precedenza.

  9. Se vuoi attivare e disattivare rapidamente il debug wireless, puoi utilizzare i riquadri sviluppatore per impostazioni rapide per il debug wireless, che si trova in Opzioni sviluppatore > Riquadri sviluppatore per impostazioni rapide.

    Screenshot dei riquadri sviluppatore per impostazioni rapide di uno smartphone Google Pixel.
    Figura 4. L'impostazione Riquadri sviluppatore per impostazioni rapide consente di attivare e disattivare rapidamente il debug wireless.

Risolvere i problemi di connessione wireless

Se hai problemi a connetterti al dispositivo in modalità wireless, prova i seguenti passaggi per la risoluzione dei problemi.

Controlla se la workstation e il dispositivo soddisfano i prerequisiti

Verifica che la workstation e il dispositivo soddisfino i prerequisiti elencati all'inizio di questa sezione.

Controlla se la configurazione di adb sulla tua workstation è corretta

Per verificare che la configurazione di ADB sulla workstation sia corretta, apri un terminale sulla workstation e inserisci adb server-status. Verifica che l'output mostri quanto segue:

  • version: "37.0.0" o versioni successive:in caso contrario, scarica l'ultima versione di SDK Platform Tools.
  • mdns_enabled: true: se questa opzione è impostata su false, adb non sarà in grado di rilevare automaticamente i dispositivi sulla tua rete. Per risolvere il problema, devi impostare la variabile di ambiente ADB_MDNS su 1 e poi riavviare il server adb eseguendo adb kill-server e poi adb start-server.
  • mdns_backend: LIBADBMDNS: in caso contrario, adb utilizza una libreria obsoleta per rilevare automaticamente i dispositivi sulla tua rete. Per risolvere il problema, devi impostare la variabile di ambiente ADB_MDNS_OPENSCREEN su 0 e poi riavviare il server adb eseguendo adb kill-server e poi adb start-server.

Controllare se la rete supporta mDNS

adb si basa su mDNS per rilevare e connettersi automaticamente ai dispositivi accoppiati. Per verificare se la tua rete supporta mDNS:

  1. Sul dispositivo, attiva il debug wireless come descritto nella sezione Connettersi a un dispositivo tramite Wi-Fi.

  2. Sulla workstation, apri un terminale e inserisci adb mdns track-services --proto-text.

  3. Verifica che l'output non sia vuoto e contenga un servizio TLS con l'indirizzo IP e il numero di porta del tuo dispositivo. Se l'output è vuoto, la tua rete non supporta mDNS. Output di esempio:

    tls {
  service {
    instance: "adb-35121FDJH000R8-xyMD0H"
    service: "_adb-tls-connect._tcp"
    ipv4: "192.168.84.23"
    ipv6: "fe80:0:0:0:fc7a:299d:8d38:6c1c"
    port: 37895
    product_model: "Pixel 8"
    build_version_sdk_full: "37.0"
    given_name: "sherifeid Pixel"
    serial: "35121FDJH000R8"
    mdns_service_version: "2.0"
    hostname: "Android_CXUKYJY1.local"
  }
}

Controllare se il dispositivo supporta ADB Wi-Fi 2.0

Nota: ADB Wi-Fi 2.0 è supportato su Android 17 e versioni successive.

Per controllare se il tuo dispositivo supporta ADB Wi-Fi 2.0:

  1. Sul dispositivo, attiva il debug wireless come descritto nella sezione Connettersi a un dispositivo tramite Wi-Fi.

  2. Sulla workstation, apri un terminale e inserisci adb mdns track-services --proto-text.

  3. Verifica che l'output contenga mdns_service_version: "2.0" o versioni successive. In caso contrario, il tuo dispositivo non esegue Android 17 o versioni successive e non supporta ADB Wi-Fi 2.0. Per eseguire l'aggiornamento ad Android 17 o versioni successive, controlla se sono presenti aggiornamenti di sistema in sospeso sul dispositivo. Controllare e aggiornare la versione di Android.

Segnala un nuovo problema

Se riscontri ancora problemi di connessione wireless al dispositivo, puoi segnalare un nuovo problema. Assicurati di fornire le seguenti informazioni nella segnalazione:

  • I log del dispositivo:riproduci il problema e allega i log del dispositivo.
  • I log di adb sulla workstation:
    1. Imposta la variabile di ambiente ADB_TRACE=all.
    2. Riavvia il server adb eseguendo adb kill-server e poi adb start-server.
    3. Riproduci il problema.
    4. Individua i file di log:esegui adb server-status e allega il file di log a cui viene fatto riferimento nell'output log_absolute_path.

Connettersi in modalità wireless a un dispositivo dopo una connessione USB iniziale (unica opzione disponibile su Android 10 e versioni precedenti)

Nota:questo flusso di lavoro è applicabile anche ad Android 11 (e versioni successive), con l'avvertenza che prevede anche una connessione *iniziale* tramite USB fisica.

Nota:le seguenti istruzioni non si applicano ai dispositivi Wear con Android 10 (livello API 29) o versioni precedenti. Per maggiori informazioni, consulta la guida al debug di un'app per Wear OS.

adb di solito comunica con il dispositivo tramite USB, ma puoi anche utilizzare adb tramite Wi-Fi. Per connettere un dispositivo con Android 10 (livello API 29) o versioni precedenti, segui questi passaggi iniziali tramite USB:

  1. Collega il dispositivo Android e il adbcomputer host a una rete Wi-Fi comune.

    2. Nota: tieni presente che non tutti i punti di accesso sono adatti. Potresti dover utilizzare un punto di accesso il cui firewall sia configurato correttamente per supportare adb.

  2. Collega il dispositivo al computer host con un cavo USB.
  3. Imposta il dispositivo di destinazione in modo che ascolti una connessione TCP/IP sulla porta 5555: 
    adb tcpip 5555
  4. Scollega il cavo USB dal dispositivo di destinazione.
  5. Trova l'indirizzo IP del dispositivo Android. Ad esempio, su un dispositivo Nexus puoi trovare l'indirizzo IP in Impostazioni > Informazioni sul tablet (o Informazioni sullo smartphone) > Stato > Indirizzo IP.
  6. Connettiti al dispositivo tramite il suo indirizzo IP: 
    adb connect device_ip_address:5555
  7. Verifica che il computer host sia connesso al dispositivo di destinazione: 
    $ adb devices
List of devices attached
device_ip_address:5555 device

Il dispositivo ora è connesso a adb.

Se la connessione di adb al tuo dispositivo viene persa:

  • Assicurati che l'host sia ancora connesso alla stessa rete Wi-Fi del tuo dispositivo Android.
  • Riconnettiti eseguendo di nuovo il passaggio adb connect.
  • Se il problema persiste, ripristina l'host adb: 
    adb kill-server

    Poi ricomincia dall'inizio.

Query per i dispositivi

Prima di inviare comandi adb, è utile sapere quali istanze di dispositivi sono connesse al server adb. Genera un elenco dei dispositivi collegati utilizzando il comando devices: 

  adb devices -l

In risposta, adb stampa queste informazioni sullo stato per ogni dispositivo:

  • Numero di serie:adb crea una stringa per identificare in modo univoco il dispositivo in base al numero di porta. Ecco un esempio di numero di serie: emulator-5554
  • Stato:lo stato della connessione del dispositivo può essere uno dei seguenti:
    • offline: Il dispositivo non è connesso a adb o non risponde.
    • device: il dispositivo è connesso al server adb. Tieni presente che questo stato non implica che il sistema Android sia completamente avviato e operativo, perché il dispositivo si connette a adb mentre il sistema è ancora in fase di avvio. Dopo l'avvio, questo è lo stato operativo normale di un dispositivo.
    • no device: nessun dispositivo è connesso.
  • Descrizione:se includi l'opzione -l, il comando devices ti dice cos'è il dispositivo. Queste informazioni sono utili quando hai più dispositivi collegati, in modo da poterli distinguere.

L'esempio seguente mostra il comando devices e il relativo output. Ci sono tre dispositivi in esecuzione. Le prime due righe dell'elenco sono emulatori, mentre la terza riga è un dispositivo hardware collegato al computer.

$ adb devices
List of devices attached
emulator-5556 device product:sdk_google_phone_x86_64 model:Android_SDK_built_for_x86_64 device:generic_x86_64
emulator-5554 device product:sdk_google_phone_x86 model:Android_SDK_built_for_x86 device:generic_x86
0a388e93      device usb:1-1 product:razor model:Nexus_7 device:flo

Emulatore non elencato

Il comando adb devices ha una sequenza di comandi in casi limite che impedisce agli emulatori in esecuzione di essere visualizzati nell'output adb devices anche se gli emulatori sono visibili sul desktop. Ciò si verifica quando tutte le seguenti condizioni sono vere:

  • Il server adb non è in esecuzione.
  • Utilizza il comando emulator con l'opzione -port o -ports con un valore di porta dispari compreso tra 5554 e 5584.
  • La porta con numero dispari che hai scelto non è occupata, quindi la connessione alla porta può essere stabilita al numero di porta specificato oppure, se è occupata, l'emulatore passa a un'altra porta che soddisfa i requisiti del punto 2.
  • Avvia il server adb dopo aver avviato l'emulatore.

Un modo per evitare questa situazione è lasciare che l'emulatore scelga le proprie porte ed eseguire non più di 16 emulatori contemporaneamente. Un altro modo è avviare sempre il server adb prima di utilizzare il comando emulator, come spiegato negli esempi seguenti.

Esempio 1: nella seguente sequenza di comandi, il comando adb devices avvia il server adb, ma l'elenco dei dispositivi non viene visualizzato.

Arresta il server adb e inserisci i seguenti comandi nell'ordine mostrato. Per il nome dell'AVD, fornisci un nome AVD valido dal tuo sistema. Per visualizzare un elenco dei nomi degli AVD, digita emulator -list-avds. Il comando emulator si trova nella directory android_sdk/tools. 

$ adb kill-server
$ emulator -avd Nexus_6_API_25 -port 5555
$ adb devices

List of devices attached
* daemon not running. starting it now on port 5037 *
* daemon started successfully *

Esempio 2: nella seguente sequenza di comandi, adb devices mostra l'elenco dei dispositivi perché il server adb è stato avviato per primo.

Per visualizzare l'emulatore nell'output adb devices, arresta il server adb e riavvialo dopo aver utilizzato il comando emulator e prima di utilizzare il comando adb devices, come segue: 

$ adb kill-server
$ emulator -avd Nexus_6_API_25 -port 5557
$ adb start-server
$ adb devices

List of devices attached
emulator-5557 device

Per ulteriori informazioni sulle opzioni della riga di comando dell'emulatore, consulta Opzioni di avvio della riga di comando.

Inviare comandi a un dispositivo specifico

Se sono in esecuzione più dispositivi, devi specificare il dispositivo di destinazione quando esegui il comando adb. Per specificare il target:

  1. Utilizza il comando devices per ottenere il numero di serie della destinazione.
  2. Una volta ottenuto il numero di serie, utilizza l'opzione -s con i comandi adb per specificare il numero di serie.
    1. Se intendi emettere molti comandi adb, puoi impostare la variabile di ambiente $ANDROID_SERIAL in modo che contenga il numero di serie.
    2. Se utilizzi sia -s che $ANDROID_SERIAL, -s ha la precedenza su $ANDROID_SERIAL.

Nell'esempio seguente, viene ottenuto l'elenco dei dispositivi collegati, quindi il numero di serie di uno dei dispositivi viene utilizzato per installare helloWorld.apk su quel dispositivo: 

$ adb devices
List of devices attached
emulator-5554 device
emulator-5555 device
0.0.0.0:6520  device

# To install on emulator-5555
$ adb -s emulator-5555 install helloWorld.apk
# To install on 0.0.0.0:6520
$ adb -s 0.0.0.0:6520 install helloWorld.apk

Nota:se emetti un comando senza specificare un dispositivo di destinazione quando sono disponibili più dispositivi, adb visualizza l'errore "adb: more than one device/emulator".

Se sono disponibili più dispositivi, ma solo uno è un emulatore, utilizza l'opzione -e per inviare comandi all'emulatore. Se sono presenti più dispositivi, ma solo uno è un dispositivo hardware collegato, utilizza l'opzione -d per inviare comandi al dispositivo hardware.

Installare un'app

Puoi utilizzare adb per installare un APK su un emulatore o un dispositivo connesso con il comando install:

adb install path_to_apk

Quando installi un APK di test, devi utilizzare l'opzione -t con il comando install. Per saperne di più, vedi -t.

Per installare più APK, utilizza install-multiple. Questa operazione è utile se scarichi tutti gli APK per un dispositivo specifico per la tua app da Play Console e vuoi installarli su un emulatore o un dispositivo fisico.

Per ulteriori informazioni su come creare un file APK che puoi installare su un'istanza di emulatore/dispositivo, vedi Compilare ed eseguire l'app.

Nota:se utilizzi Android Studio, non è necessario utilizzare adb direttamente per installare l'app sull'emulatore o sul dispositivo. Android Studio gestisce il packaging e l'installazione dell'app per te.

Configura port forwarding

Utilizza il comando forward per configurare l'inoltro di porte arbitrario, che inoltra le richieste su una porta host specifica a una porta diversa su un dispositivo. Il seguente esempio configura l'inoltro della porta host 6100 alla porta del dispositivo 7100: 

adb forward tcp:6100 tcp:7100

Il seguente esempio configura l'inoltro della porta host 6100 a local:logd: 

adb forward tcp:6100 local:logd

Questa opzione può essere utile se stai cercando di determinare cosa viene inviato a una determinata porta del dispositivo. Tutti i dati ricevuti verranno scritti nel daemon di logging del sistema e visualizzati nei log del dispositivo.

Copiare file da e verso un dispositivo

Utilizza i comandi pull e push per copiare i file su e da un dispositivo. A differenza del comando install, che copia solo un file APK in una posizione specifica, i comandi pull e push consentono di copiare directory e file arbitrari in qualsiasi posizione di un dispositivo.

Per copiare un file o una directory e le relative sottodirectory dal dispositivo, segui questi passaggi: 

adb pull remote local

Per copiare un file o una directory e le relative sottodirectory sul dispositivo, segui questi passaggi: 

adb push local remote

Sostituisci local e remote con i percorsi dei file/della directory di destinazione sulla macchina di sviluppo (locale) e sul dispositivo (remoto). Ad esempio:

adb push myfile.txt /sdcard/myfile.txt

Arrestare il server adb

In alcuni casi, potrebbe essere necessario terminare il processo del server adb e riavviarlo per risolvere il problema. Ad esempio, questo potrebbe essere il caso se adb non risponde a un comando.

Per arrestare il server adb, utilizza il comando adb kill-server. Puoi quindi riavviare il server eseguendo qualsiasi altro comando adb.

Esegui comandi ADB

Esegui i comandi adb da una riga di comando sulla tua macchina di sviluppo o da uno script utilizzando quanto segue: 

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

Se è in esecuzione un solo emulatore o è connesso un solo dispositivo, il comando adb viene inviato a quel dispositivo per impostazione predefinita. Se sono in esecuzione più emulatori e/o sono collegati più dispositivi, devi utilizzare l'opzione -d, -e o -s per specificare il dispositivo di destinazione a cui deve essere indirizzato il comando.

Puoi visualizzare un elenco dettagliato di tutti i comandi adb supportati utilizzando il seguente comando:

adb --help

Eseguire comandi shell

Puoi utilizzare il comando shell per inviare comandi al dispositivo tramite adb o per avviare una shell interattiva. Per eseguire un singolo comando, utilizza il comando shell nel seguente modo: 

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

Per avviare una shell interattiva su un dispositivo, utilizza il comando shell nel seguente modo:

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

Per uscire da una shell interattiva, premi Control+D o digita exit.

Android fornisce la maggior parte dei normali strumenti a riga di comando Unix. Per un elenco degli strumenti disponibili, utilizza il seguente comando:

adb shell ls /system/bin

Puoi chiedere aiuto per la maggior parte dei comandi tramite l'argomento --help. Molti comandi della shell sono forniti da toybox. La guida generale applicabile a tutti i comandi di Toybox è disponibile tramite toybox --help.

Con Android Platform Tools 23 e versioni successive, adb gestisce gli argomenti nello stesso modo in cui lo fa il comando ssh(1). Questa modifica ha risolto molti problemi relativi all'inserimento di comandi e consente di eseguire in modo sicuro i comandi che contengono metacaratteri della shell, come adb install Let\'sGo.apk. Questa modifica comporta anche un cambiamento nell'interpretazione di qualsiasi comando che contenga metacaratteri della shell.

Ad esempio, adb shell setprop key 'two words' ora è un errore, perché le virgolette vengono eliminate dalla shell locale e il dispositivo vede adb shell setprop key two words. Per far funzionare il comando, inserisci le virgolette due volte, una volta per la shell locale e una volta per la shell remota, come fai con ssh(1). Ad esempio, adb shell setprop key "'two words'" funziona perché la shell locale prende il livello esterno delle virgolette e il dispositivo vede ancora il livello interno delle virgolette: setprop key 'two words'. L'escape è un'altra opzione, ma in genere è più semplice usare le virgolette due volte.

Vedi anche lo strumento a riga di comando Logcat, utile per monitorare il log di sistema.

Gestore attività di chiamata

All'interno di una shell adb, puoi eseguire comandi con lo strumento Gestione attività (am) per eseguire varie azioni di sistema, ad esempio avviare un'attività, arrestare forzatamente un processo, trasmettere un intent, modificare le proprietà dello schermo del dispositivo e altro ancora.

In una shell, la sintassi di am è:

am command

Puoi anche inviare un comando di Activity Manager direttamente da adb senza accedere a una shell remota. Ad esempio:

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

Tabella 1. Comandi disponibili del gestore attività

Comando Descrizione
start [options] intent Avvia un Activity specificato da intent.

Consulta la specifica per gli argomenti intent.

Le opzioni sono:

  • -D: attiva il debug.
  • -W: attendi il completamento del lancio.
  • --start-profiler file: Avvia il profiler e invia i risultati a file.
  • -P file: come --start-profiler, ma la profilazione si interrompe quando l'app diventa inattiva.
  • -R count: Ripeti l'avvio dell'attività count volte. Prima di ogni ripetizione, l'attività principale verrà completata.
  • -S: forza l'interruzione dell'app di destinazione prima di iniziare l'attività.
  • --opengl-trace: attiva la tracciabilità delle funzioni OpenGL.
  • --user user_id | current: specifica l'utente da utilizzare per l'esecuzione. Se non specificato, viene utilizzato l'utente corrente.
startservice [options] intent Avvia Service specificato da intent.

Consulta la specifica per gli argomenti intent.

Le opzioni sono:

  • --user user_id | current: specifica l'utente con cui eseguire l'operazione. Se non specificato, viene eseguito come utente corrente.
force-stop package Forza l'interruzione di tutto ciò che è associato a package.
kill [options] package Termina tutti i processi associati a package. Questo comando termina solo i processi che possono essere terminati in sicurezza e che non influiranno sull'esperienza utente.

Le opzioni sono:

  • --user user_id | all | current: specifica i processi dell'utente da terminare. Se non specificato, vengono terminati tutti i processi degli utenti.
kill-all Termina tutti i processi in background.
broadcast [options] intent Emetti un intent di trasmissione.

Consulta la specifica per gli argomenti intent.

Le opzioni sono:

  • [--user user_id | all | current]: specifica a quale utente inviare. Se non specificato, invia a tutti gli utenti.
instrument [options] component Inizia il monitoraggio con un'istanza Instrumentation. In genere, il target component è la postura test_package/runner_class.

Le opzioni sono:

  • -r: stampa i risultati non elaborati (altrimenti decodifica report_key_streamresult). Utilizza con [-e perf true] per generare output non elaborati per le misurazioni del rendimento.
  • -e name value: imposta l'argomento name su value. Per i test runner, una forma comune è -e testrunner_flag value[,value...].
  • -p file: Scrivi i dati di profilazione in file.
  • -w: attendi il completamento della strumentazione prima di tornare. Obbligatorio per i test runner.
  • --no-window-animation: disattiva le animazioni delle finestre durante l'esecuzione.
  • --user user_id | current: specifica in quale strumentazione utente viene eseguita. Se non specificato, viene eseguito nell'utente corrente.
profile start process file Avvia il profiler su process, scrivi i risultati in file.
profile stop process Interrompi il profiler il giorno process.
dumpheap [options] process file Scarica il dump dell'heap di process, scrivi in file.

Le opzioni sono:

  • --user [user_id | current]: quando fornisci un nome di processo, specifica l'utente del processo di cui eseguire il dump. Se non specificato, viene utilizzato l'utente corrente.
  • -b [| png | jpg | webp]: scarica le bitmap dalla memoria grafica (livello API 35 e versioni successive). (Facoltativo) Specifica il formato in cui eseguire il dump (PNG per impostazione predefinita).
  • -n: Esegui il dump dell'heap nativo anziché dell'heap gestito.
dumpbitmaps [options] [-p process] Estrai le informazioni bitmap da process (livello API 36 e versioni successive).

Le opzioni sono:

  • -d|--dump [format]: scarica i contenuti bitmap nel format specificato, che può essere uno tra png, jpg o webp. Se non viene specificato alcun valore, il valore predefinito è png. Verrà creato un file zip dumpbitmaps-<time>.zip con le bitmap.
  • -p process: scarica le bitmap da process, è possibile specificare più -p process.
Se non viene specificato alcun process, verranno dumpate le bitmap di tutti i processi.
set-debug-app [options] package Imposta l'app package per il debug.

Le opzioni sono:

  • -w: attende il debugger all'avvio dell'app.
  • --persistent: mantieni questo valore.
clear-debug-app Cancella il pacchetto impostato in precedenza per il debug con set-debug-app.
monitor [options] Inizia a monitorare gli arresti anomali o gli errori ANR.

Le opzioni sono:

  • --gdb: avvia gdbserv sulla porta specificata in caso di arresto anomalo/ANR.
screen-compat {on | off} package Controlla la modalità di compatibilità dello schermo di package.
display-size [reset | widthxheight] Esegui l'override delle dimensioni di visualizzazione del dispositivo. Questo comando è utile per testare l'app su schermi di dimensioni diverse simulando una risoluzione dello schermo piccola utilizzando un dispositivo con uno schermo grande e viceversa.

Esempio:
am display-size 1280x800

display-density dpi Esegui l'override della densità di visualizzazione del dispositivo. Questo comando è utile per testare l'app su diverse densità dello schermo simulando un ambiente dello schermo ad alta densità utilizzando uno schermo a bassa densità e viceversa.

Esempio:
am display-density 480

to-uri intent Stampa la specifica dell'intent specificato come URI.

Consulta la specifica per gli argomenti intent.

to-intent-uri intent Stampa la specifica dell'intent specificata come URI intent:.

Consulta la specifica per gli argomenti intent.

Specifica per gli argomenti dell'intent

Per i comandi di Activity Manager che accettano un argomento intent, puoi specificare l'intent con le seguenti opzioni:

Chiama il gestore dei pacchetti (pm)

All'interno di una shell adb, puoi eseguire comandi con lo strumento di gestione dei pacchetti (pm) per eseguire azioni e query sui pacchetti app installati sul dispositivo.

In una shell, la sintassi di pm è:

pm command

Puoi anche eseguire un comando del gestore di pacchetti direttamente da adb senza accedere a una shell remota. Ad esempio:

adb shell pm uninstall com.example.MyApp

Tabella 2. Comandi del gestore dei pacchetti disponibili

Comando Descrizione
list packages [options] filter Stampa tutti i pacchetti, facoltativamente solo quelli il cui nome contiene il testo in filter.

Opzioni:

  • -f: vedi il file associato.
  • -d: filtra per mostrare solo i pacchetti disattivati.
  • -e: filtra per mostrare solo i pacchetti abilitati.
  • -s: filtra per mostrare solo i pacchetti di sistema.
  • -3: filtra per mostrare solo i pacchetti di terze parti.
  • -i: consulta il programma di installazione dei pacchetti.
  • -u: Includi pacchetti disinstallati.
  • --user user_id: lo spazio utente da interrogare.
list permission-groups Stampa tutti i gruppi di autorizzazioni noti.
list permissions [options] group Stampa tutte le autorizzazioni note, facoltativamente solo quelle in group.

Opzioni:

  • -g: Organizza per gruppo.
  • -f: stampa tutte le informazioni.
  • -s: breve riepilogo.
  • -d: Elenca solo le autorizzazioni pericolose.
  • -u: elenca solo le autorizzazioni che gli utenti vedranno.
list instrumentation [options] Elenca tutti i pacchetti di test.

Opzioni:

  • -f: elenca il file APK per il pacchetto di test.
  • target_package: elenca 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 attuale.
list users Stampa tutti gli utenti del sistema.
path package Stampa il percorso dell'APK del package specificato.
install [options] path Installa nel sistema un pacchetto specificato da path.

Opzioni:

  • -r: reinstalla un'app esistente conservandone i dati.
  • -t: consente l'installazione di APK di test. Gradle genera un APK di test quando hai solo eseguito o eseguito il debug della tua app oppure hai utilizzato il comando Build > Build APK di Android Studio. Se l'APK è creato utilizzando un SDK di anteprima per gli sviluppatori, devi includere l'opzione -t con il comando install se stai installando un APK di test.
  • -i installer_package_name: specifica il nome del pacchetto di installazione.
  • --user user_id: specifica l'utente per cui installare il pacchetto. Per impostazione predefinita, il pacchetto viene installato per tutti gli utenti esistenti sul dispositivo.
  • --install-location location: imposta la posizione di installazione utilizzando uno dei seguenti valori:
    • 0: utilizza la posizione di installazione predefinita.
    • 1: Installazione nella memoria interna del dispositivo.
    • 2: Installare su un supporto esterno.
  • -f: Installa il pacchetto nella memoria interna del sistema.
  • -d: Consenti il downgrade del codice versione.
  • -g: concedi tutte le autorizzazioni elencate nel file manifest dell'app.
  • --fastdeploy: aggiorna rapidamente un pacchetto installato aggiornando solo le parti dell'APK che sono cambiate.
  • --incremental: installa una parte sufficiente dell'APK per avviare l'app mentre trasmette in streaming i dati rimanenti in background. Per utilizzare questa funzionalità, devi firmare l'APK, creare un file dello schema di firma dell'APK v4 e inserirlo nella stessa directory dell'APK. Questa funzionalità è supportata solo su alcuni dispositivi. Questa opzione impone a adb di utilizzare la funzionalità o di non riuscirci se non è supportata, con informazioni dettagliate sul motivo del mancato funzionamento. Aggiungi l'opzione --wait per attendere che l'APK sia completamente installato prima di concedere l'accesso.

    --no-incremental impedisce a adb di utilizzare questa funzionalità.

uninstall [options] package Rimuove un pacchetto dal sistema.

Opzioni:

  • -k: mantieni le directory di dati e cache dopo la rimozione del pacchetto.
  • --user user_id: specifica l'utente per il quale viene rimosso il pacchetto. Per impostazione predefinita, il pacchetto viene rimosso per tutti gli utenti del dispositivo.
  • --versionCode version_code: disinstalla solo se l'app ha il codice di versione specificato.
clear package Elimina tutti i dati associati a un pacchetto.
enable package_or_component Attiva il pacchetto o il componente specificato (scritto come "package/class").
disable package_or_component Disattiva il pacchetto o il componente specificato (scritto come "package/class").
disable-user [options] package_or_component

Opzioni:

  • --user user_id: l'utente da disattivare.
grant package_name permission Concedi un'autorizzazione a un'app. Sui dispositivi con Android 6.0 (livello API 23) e versioni successive, l'autorizzazione può essere qualsiasi autorizzazione dichiarata nel manifest dell'app. Sui dispositivi con Android 5.1 (livello API 22) e versioni precedenti, deve essere un'autorizzazione facoltativa definita dall' app.
revoke package_name permission Revoca di un'autorizzazione da un'app. Sui dispositivi con Android 6.0 (livello API 23) e versioni successive, l'autorizzazione può essere qualsiasi autorizzazione dichiarata nel manifest dell'app. Sui dispositivi con Android 5.1 (livello API 22) e versioni precedenti, deve essere un'autorizzazione facoltativa definita dall'app.
set-install-location location Modifica la posizione di installazione predefinita. Valori di località:
  • 0: Automatico: lascia che il sistema decida la posizione migliore.
  • 1: Interno: installa nello spazio sul dispositivo interno.
  • 2: Esterno: installa su supporti esterni.

Nota:questa operazione è destinata solo al debug. L'utilizzo può causare l'interruzione delle app e altri comportamenti indesiderati.
get-install-location Restituisce la posizione di installazione corrente. Valori restituiti:
  • 0 [auto]: Lascia che il sistema decida la posizione migliore
  • 1 [internal]: Installazione nella memoria interna del dispositivo
  • 2 [external]: Installare su un supporto esterno
set-permission-enforced permission [true | false] Specifica se l'autorizzazione specificata deve essere applicata.
trim-caches desired_free_space Taglia i file della cache per raggiungere lo spazio libero specificato.
create-user user_name Crea un nuovo utente con il user_name specificato, stampando il nuovo identificatore utente.
remove-user user_id Rimuovi l'utente con il user_id specificato, eliminando tutti i dati associati a quell'utente
get-max-users Stampa il numero massimo di utenti supportati dal dispositivo.
get-app-links [options] [package]

Stampa lo stato di verifica del dominio per il package specificato o per tutti i pacchetti se non ne viene specificato nessuno. I codici stato sono definiti come segue:

  • none: non è stato registrato nulla per questo dominio
  • verified: il dominio è stato verificato correttamente
  • approved: approvato forzatamente, in genere tramite shell
  • denied: negato forzatamente, in genere tramite shell
  • migrated: verifica conservata da una risposta precedente
  • restored: verifica conservata da un ripristino dei dati utente
  • legacy_failure: rifiutato da un verificatore legacy, motivo sconosciuto
  • system_configured: approvato automaticamente dalla configurazione del dispositivo
  • >= 1024: codice di errore personalizzato, specifico per il programma di verifica del dispositivo

Le opzioni sono:

  • --user user_id: includi le selezioni degli utenti. Includi tutti i domini, non solo quelli con verifica automatica.
reset-app-links [options] [package]

Reimposta lo stato di verifica del dominio per il pacchetto specificato o per tutti i pacchetti se non ne viene specificato nessuno.

  • package: il pacchetto da reimpostare o "all" per reimpostare tutti i pacchetti

Le opzioni sono:

  • --user user_id: includi le selezioni degli utenti. Includi tutti i domini, non solo quelli con verifica automatica.
verify-app-links [--re-verify] [package]

Trasmetti una richiesta di verifica per il package specificato o per tutti i pacchetti se non ne viene specificato nessuno. Viene inviato solo se il pacchetto non ha registrato una risposta in precedenza.

  • --re-verify: invia anche se il pacchetto ha registrato una risposta
set-app-links [--package package] state domains

Imposta manualmente lo stato di un dominio per un pacchetto. Affinché questa operazione funzioni, il dominio deve essere dichiarato dal pacchetto come verifica automatica. Questo comando non segnalerà un errore per i domini a cui non è stato possibile applicare l'impostazione.

  • --package package: il pacchetto da impostare o "all" per impostare tutti i pacchetti
  • state: il codice per impostare i domini. I valori validi sono:
    • STATE_NO_RESPONSE (0): reimposta come se non fosse mai stata registrata alcuna risposta.
    • STATE_SUCCESS (1): considera il dominio verificato correttamente dall'agente di verifica del dominio. Tieni presente che l'agente di verifica del dominio può ignorare questa impostazione.
    • STATE_APPROVED (2): tratta il dominio come sempre approvato, impedendo all'agente di verifica del dominio di modificarlo.
    • STATE_DENIED (3): tratta il dominio come sempre negato, impedendo all'agente di verifica del dominio di modificarlo.
  • domains: elenco separato da spazi dei domini da modificare o "all" per modificare tutti i domini.
set-app-links-user-selection --user user_id [--package package] enabled domains

Imposta manualmente lo stato di una selezione di utenti host per un pacchetto. Per funzionare, il dominio deve essere dichiarato dal pacchetto. Questo comando non segnalerà un errore per i domini che non è stato possibile applicare.

  • --user user_id: l'utente per cui modificare le selezioni
  • --package package: il pacchetto da impostare
  • enabled: indica se approvare il dominio
  • domains: elenco separato da spazi dei domini da modificare o "all" per modificare tutti i domini
set-app-links-allowed --user user_id [--package package] allowed

Attiva/disattiva l'impostazione di gestione dei link verificata automaticamente per un pacchetto.

  • --user user_id: l'utente per cui modificare le selezioni
  • --package package: il pacchetto da impostare o "all" per impostare tutti i pacchetti; i pacchetti verranno reimpostati se non ne viene specificato nessuno
  • allowed: true per consentire al pacchetto di aprire i link verificati automaticamente, false per disattivare
get-app-link-owners --user user_id [--package package] domains

Stampa i proprietari di un dominio specifico per un determinato utente in ordine di priorità crescente.

  • --user user_id: l'utente per cui eseguire la query
  • --package package: facoltativamente, stampa anche per tutti i domini web dichiarati da un pacchetto o "all" per stampare tutti i pacchetti
  • domains: elenco separato da spazi dei domini per cui eseguire query

Chiama il gestore dei criteri del dispositivo (dpm)

Per aiutarti a sviluppare e testare le tue app di gestione dei dispositivi, invia comandi allo strumento di gestione dei criteri del dispositivo (dpm). Utilizza lo strumento per controllare l'app per amministratori attiva o modificare i dati di stato di un criterio sul dispositivo.

In una shell, la sintassi di dpm è:

dpm command

Puoi anche inviare un comando di Device Policy Manager direttamente da adb senza inserire una shell remota:

adb shell dpm command

Tabella 3. Comandi di Device Policy Manager disponibili

Comando Descrizione
set-active-admin [options] component Imposta component come amministratore attivo.

Le opzioni sono:

  • --user user_id: specifica l'utente di destinazione. Puoi anche passare --user current per selezionare l'utente corrente.
set-profile-owner [options] component Imposta component come amministratore attivo e il relativo pacchetto come proprietario del profilo per un utente esistente.

Le opzioni sono:

  • --user user_id: specifica l'utente di destinazione. Puoi anche trasmettere --user current per selezionare l'utente corrente.
  • --name name: specifica il nome dell'organizzazione leggibile.
set-device-owner [options] component Imposta component come amministratore attivo e il relativo pacchetto come proprietario del dispositivo.

Le opzioni sono:

  • --user user_id: specifica l'utente di destinazione. Puoi anche passare --user current per selezionare l'utente corrente.
  • --name name: specifica il nome dell'organizzazione leggibile.
remove-active-admin [options] component Disattivare un amministratore attivo. L'app deve dichiarare android:testOnly nel manifest. Questo comando rimuove anche i proprietari del dispositivo e del profilo.

Le opzioni sono:

  • --user user_id: specifica l'utente di destinazione. Puoi anche passare --user current per selezionare l'utente corrente.
clear-freeze-period-record Cancella il record del dispositivo dei periodi di blocco impostati in precedenza per gli aggiornamenti OTA di sistema. Questa opzione è utile per evitare le limitazioni di pianificazione del dispositivo durante lo sviluppo di app che gestiscono i periodi di blocco. Vedi Gestire gli aggiornamenti di sistema.

Supportato sui dispositivi con Android 9.0 (livello API 28) e versioni successive.
force-network-logs Forza il sistema a preparare tutti i log di rete esistenti per il recupero da parte di un DPC. Se sono disponibili log di connessione o DNS, il DPC riceve il callback onNetworkLogsAvailable(). Vedi Logging dell'attività di rete.

Questo comando è soggetto a limiti di frequenza. Supportato sui dispositivi con Android 9.0 (livello API 28) e versioni successive.
force-security-logs Forza il sistema a rendere disponibili al DPC tutti i log di sicurezza esistenti. Se sono disponibili log, il DPC riceve il callback onSecurityLogsAvailable(). Vedi Registrare l'attività dei dispositivi aziendali.

Questo comando è soggetto a limiti di frequenza. Supportato sui dispositivi con Android 9.0 (livello API 28) e versioni successive.

Fai uno screenshot

Il comando screencap è un'utilità shell per acquisire uno screenshot del display di un dispositivo.

In una shell, la sintassi di screencap è: 

screencap filename

Per utilizzare screencap dalla riga di comando, inserisci quanto segue: 

adb shell screencap /sdcard/screen.png

Ecco una sessione di screenshot di esempio, in cui viene utilizzata la shell adb per acquisire lo screenshot e il comando pull per scaricare il file dal dispositivo:

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

In alternativa, se ometti il nome file, screencap scrive l'immagine nell'output standard. Se combinata con l'opzione -p per specificare il formato PNG, puoi trasmettere lo screenshot del dispositivo direttamente a un file sul computer locale.

Ecco un esempio di acquisizione di uno screenshot e salvataggio locale in un unico comando:

# use 'exec-out' instead of 'shell' to get raw data
$ adb exec-out screencap -p > screen.png

Registra un video

Il comando screenrecord è un'utilità della shell per registrare la visualizzazione dei dispositivi con Android 4.4 (livello API 19) e versioni successive. L'utilità registra l'attività dello schermo in un file MPEG-4. Puoi utilizzare questo file per creare video promozionali o di formazione oppure per il debug e il test.

In una shell, utilizza la seguente sintassi:

screenrecord [options] filename

Per utilizzare screenrecord dalla riga di comando, inserisci quanto segue: 

adb shell screenrecord /sdcard/demo.mp4

Interrompi la registrazione dello schermo premendo Ctrl+C. In caso contrario, la registrazione si interrompe automaticamente dopo tre minuti o al raggiungimento del limite di tempo impostato da --time-limit.

Per iniziare a registrare lo schermo del dispositivo, esegui il comando screenrecord per registrare il video. Quindi, esegui il comando pull per scaricare il video dal dispositivo al computer host. Ecco un esempio di sessione di registrazione:

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

L'utilità screenrecord può registrare a qualsiasi risoluzione e velocità in bit supportate che richiedi, mantenendo le proporzioni del display del dispositivo. L'utilità registra alla risoluzione e all'orientamento nativi del display per impostazione predefinita, con una durata massima di tre minuti.

Limitazioni dell'utilità screenrecord:

  • L'audio non viene registrato con il file video.
  • La registrazione video non è disponibile per i dispositivi con Wear OS.
  • Alcuni dispositivi potrebbero non essere in grado di registrare alla risoluzione nativa del display. Se riscontri problemi con la registrazione dello schermo, prova a utilizzare una risoluzione dello schermo inferiore.
  • La rotazione dello schermo durante la registrazione non è supportata. Se lo schermo ruota durante la registrazione, parte dello schermo viene tagliata nella registrazione.

Tabella 4. screenrecord opzioni

Opzioni Descrizione
--help Visualizzare la sintassi e le opzioni del comando
--size widthxheight Imposta le dimensioni del video: 1280x720. Il valore predefinito è la risoluzione nativa del display del dispositivo (se supportata), 1280x720 in caso contrario. Per risultati ottimali, utilizza una dimensione supportata dal codificatore Advanced Video Coding (AVC) del tuo dispositivo.
--bit-rate rate Imposta la velocità in bit del video, in megabit al secondo. Il valore predefinito è 20 Mbps. Puoi aumentare il bit rate per migliorare la qualità video, ma in questo modo i file dei film diventano più grandi. L'esempio seguente imposta il bit rate di registrazione su 6 Mbps: 
screenrecord --bit-rate 6000000 /sdcard/demo.mp4
--time-limit time Imposta la durata massima della registrazione, in secondi. Il valore predefinito e massimo è 180 (3 minuti).
--rotate Ruota l'output di 90 gradi. Si tratta di una funzionalità sperimentale.
--verbose Visualizza le informazioni del log nella schermata della riga di comando. Se non imposti questa opzione, l'utilità non mostra alcuna informazione durante l'esecuzione.

Legge i profili ART per le app

A partire da Android 7.0 (livello API 24), Android Runtime (ART) raccoglie i profili di esecuzione per le app installate, che vengono utilizzati per ottimizzare le prestazioni delle app. Esamina i profili raccolti per capire quali metodi vengono eseguiti di frequente e quali classi vengono utilizzate durante l'avvio dell'app.

Nota:è possibile recuperare il nome del file del profilo di esecuzione solo se disponi dell'accesso root al file system, ad esempio su un emulatore.

Per generare una versione di testo delle informazioni del profilo, utilizza il seguente comando:

adb shell cmd package dump-profiles package

Per recuperare il file prodotto, utilizza:

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

Reimposta i dispositivi di test

Se testi la tua app su più dispositivi di test, potrebbe essere utile ripristinare il dispositivo tra un test e l'altro, ad esempio per rimuovere i dati utente e ripristinare l'ambiente di test. Puoi eseguire un ripristino dei dati di fabbrica di un dispositivo di test con Android 10 (livello API 29) o versioni successive utilizzando il comando della shell testharness adb, come mostrato di seguito: 

adb shell cmd testharness enable

Quando ripristini il dispositivo utilizzando testharness, il dispositivo esegue automaticamente il backup della chiave RSA che consente il debug tramite la workstation corrente in una posizione persistente. ovvero, dopo il ripristino del dispositivo, la workstation può continuare a eseguire il debug ed emettere comandi adb al dispositivo senza registrare manualmente una nuova chiave.

Inoltre, per semplificare e rendere più sicuro il test continuo della tua app, l'utilizzo di testharness per ripristinare un dispositivo modifica anche le seguenti impostazioni del dispositivo:

  • Il dispositivo configura determinate impostazioni di sistema in modo che le procedure guidate di configurazione iniziale del dispositivo non vengano visualizzate. ovvero il dispositivo entra in uno stato da cui puoi installare, eseguire il debug e testare rapidamente la tua app.
  • Impostazioni:
    • Disattiva la schermata di blocco.
    • Disattiva gli avvisi di emergenza.
    • Disattiva la sincronizzazione automatica per gli account.
    • Disattiva gli aggiornamenti automatici del sistema.
  • Altro:
    • Disabilita le app di sicurezza preinstallate.

Se la tua app deve rilevare e adattarsi alle impostazioni predefinite del comando testharness, utilizza ActivityManager.isRunningInUserTestHarness().

sqlite

sqlite3 avvia il programma a riga di comando sqlite per esaminare i database SQLite. Include comandi come .dump per stampare i contenuti di una tabella e .schema per stampare l'istruzione SQL CREATE per una tabella esistente. Puoi anche eseguire i comandi SQLite dalla riga di comando, come mostrato di seguito:

$ adb -s emulator-5554 shell
$ sqlite3 /data/data/com.example.app/databases/rssitems.db
SQLite version 3.3.12
Enter ".help" for instructions

Nota:è possibile accedere a un database SQLite solo se disponi dell'accesso root al file system, ad esempio su un emulatore.

Per saperne di più, consulta la documentazione della riga di comando sqlite3.

Backend USB adb

Il server adb può interagire con lo stack USB tramite due backend. Può utilizzare il backend nativo del sistema operativo (Windows, Linux o macOS) oppure il backend libusb. Alcune funzionalità, come attach, detach e il rilevamento della velocità USB, sono disponibili solo quando utilizzi il backend libusb.

Puoi scegliere un backend utilizzando la variabile di ambiente ADB_LIBUSB. Se non è impostato, adb utilizza il backend predefinito. Il comportamento predefinito varia in base al sistema operativo. A partire da ADB v34, il backend liubusb viene utilizzato per impostazione predefinita su tutti i sistemi operativi, ad eccezione di Windows, dove viene utilizzato il backend nativo per impostazione predefinita. Se ADB_LIBUSB è impostato, determina se viene utilizzato il backend nativo o libusb. Per ulteriori informazioni sulle variabili di ambiente adb, consulta la pagina del manuale di adb.

Backend mDNS adb

ADB utilizza il protocollo mDNS (multicast DNS) per connettere automaticamente il server e i dispositivi per il debug wireless. A partire da ADB v37, il server ADB viene fornito con due backend mDNS, libadbmdns e openscreen.

Il backend predefinito e consigliato è libadbmdns. Questo comportamento può essere modificato utilizzando la variabile di ambiente ADB_MDNS_OPENSCREEN (impostata su 1 o 0). Il supporto del backend Openscreen su macOS inizia con ADB v35. Windows e Linux sono supportati a partire da ADB v34.

adb Burst Mode (a partire da ADB 36.0.0)

La modalità Burst è una funzionalità sperimentale che consente ad ADB di continuare a inviare pacchetti a un dispositivo anche prima che il dispositivo abbia risposto al pacchetto precedente. In questo modo aumenta notevolmente la velocità effettiva di ADB durante il trasferimento di file di grandi dimensioni e riduce anche la latenza durante il debug.

La modalità Burst è disattivata per impostazione predefinita. Per attivare la funzionalità, esegui una delle seguenti operazioni:

  • Imposta la variabile di ambiente ADB_BURST_MODE su 1.
  • In Android Studio, vai alle impostazioni del debugger in File (o Android Studio su macOS) > Impostazioni > Build, esecuzione, deployment > Debugger e imposta Modalità burst del server ADB su Attivata.