Android Debug Bridge (adb
) ist ein vielseitiges Befehlszeilentool, mit dem Sie mit einem Gerät kommunizieren können. Der Befehl adb
ermöglicht eine Vielzahl von Geräteaktionen, z. B. das Installieren und Debuggen von Apps. adb
bietet Zugriff auf eine Unix-Shell, mit der Sie verschiedene Befehle auf einem Gerät ausführen können. Es handelt sich um ein Client-Server-Programm mit drei Komponenten:
- Ein Client, der Befehle sendet. Der Client wird auf Ihrem Entwicklungssystem ausgeführt. Sie können einen Client über ein Befehlszeilenterminal mit dem Befehl
adb
aufrufen. - Ein Daemon (adbd), der Befehle auf einem Gerät ausführt. Der Daemon wird auf jedem Gerät als Hintergrundprozess ausgeführt.
- Ein Server, der die Kommunikation zwischen dem Client und dem Daemon verwaltet. Der Server wird als Hintergrundprozess auf Ihrem Entwicklungscomputer ausgeführt.
adb
ist im Android SDK Platform Tools-Paket enthalten. Laden Sie dieses Paket mit dem SDK Manager herunter. Es wird dann unter android_sdk/platform-tools/
installiert. Wenn Sie das eigenständige Android SDK Platform Tools-Paket benötigen, können Sie es hier herunterladen.
Informationen zum Verbinden eines Geräts für die Verwendung über adb
, einschließlich der Verwendung des Verbindungsassistenten zur Behebung häufiger Probleme, finden Sie unter Apps auf einem Hardwaregerät ausführen.
Funktionsweise von adb
Wenn Sie einen adb
-Client starten, prüft der Client zuerst, ob bereits ein adb
-Serverprozess ausgeführt wird. Falls nicht, wird der Serverprozess gestartet.
Wenn der Server gestartet wird, wird er an den lokalen TCP-Port 5037 gebunden und überwacht Befehle, die von adb
-Clients gesendet werden.
Hinweis:Alle adb
-Clients verwenden Port 5037 für die Kommunikation mit dem adb
-Server.
Der Server stellt dann Verbindungen zu allen laufenden Geräten her.
Emulatoren werden durch Scannen ungerader Ports im Bereich von 5555 bis 5585 gefunden. Dieser Bereich wird von den ersten 16 Emulatoren verwendet. Wenn der Server einen adb
-Daemon (adbd) findet, stellt er eine Verbindung zu diesem Port her.
Jeder Emulator verwendet ein Paar aufeinanderfolgender Ports – einen Port mit gerader Nummer für Konsolenverbindungen und einen Port mit ungerader Nummer für adb
-Verbindungen. Beispiel:
Emulator 1, Konsole: 5554
Emulator 1, adb
: 5555
Emulator 2, Konsole: 5556
Emulator 2, adb
: 5557
usw.
Wie zu sehen ist, ist der Emulator, der über Port 5555 mit adb
verbunden ist, derselbe wie der Emulator, dessen Konsole Port 5554 überwacht.
Sobald der Server Verbindungen zu allen Geräten hergestellt hat, können Sie mit adb
-Befehlen auf diese Geräte zugreifen. Da der Server Verbindungen zu Geräten verwaltet und Befehle von mehreren adb
-Clients verarbeitet, können Sie jedes Gerät von jedem Client oder von einem Skript aus steuern.
ADB-Fehlerbehebung auf dem Gerät aktivieren
Wenn Sie adb mit einem über USB verbundenen Gerät verwenden möchten, müssen Sie in den Systemeinstellungen des Geräts unter Entwickleroptionen das USB-Debugging aktivieren. Unter Android 4.2 (API-Level 17) und höher ist der Bildschirm Entwickleroptionen standardmäßig ausgeblendet. Damit sie sichtbar sind, müssen Sie die Entwickleroptionen aktivieren.
Sie können Ihr Gerät jetzt über USB verbinden. Sie können prüfen, ob Ihr Gerät verbunden ist, indem Sie adb devices
über das Verzeichnis android_sdk/platform-tools/
ausführen. Wenn das Gerät verbunden ist, wird der Gerätename als „Gerät“ aufgeführt.
Hinweis:Wenn Sie ein Gerät mit Android 4.2.2 (API-Level 17) oder höher verbinden, wird in einem Dialogfeld gefragt, ob Sie einen RSA-Schlüssel akzeptieren möchten, der das Debugging über diesen Computer ermöglicht. Dieser Sicherheitsmechanismus schützt Nutzergeräte, da sichergestellt wird, dass USB-Debugging und andere ADB-Befehle nur ausgeführt werden können, wenn Sie das Gerät entsperren und das Dialogfeld bestätigen.
Weitere Informationen zum Verbinden mit einem Gerät über USB finden Sie unter Apps auf einem Hardwaregerät ausführen.
Verbindung mit einem Gerät über WLAN herstellen
Hinweis:Die Anleitung unten gilt nicht für Wear-Geräte mit Android 11 (API-Level 30). Weitere Informationen finden Sie im Leitfaden zum Debuggen einer Wear OS-App.
Unter Android 11 (API‑Level 30) und höher wird das drahtlose Bereitstellen und Debuggen Ihrer App von Ihrer Workstation aus mit Android Debug Bridge (adb) unterstützt. So können Sie Ihre debugfähige App beispielsweise auf mehreren Remote-Geräten bereitstellen, ohne Ihr Gerät jemals physisch über USB verbinden zu müssen. So lassen sich Probleme mit USB-Verbindungen wie die Treiberinstallation vermeiden.
Bevor Sie mit der drahtlosen Fehlerbehebung beginnen, führen Sie die folgenden Schritte aus:
-
Achten Sie darauf, dass Ihre Workstation und Ihr Gerät mit demselben WLAN verbunden sind.
-
Achte darauf, dass auf deinem Gerät Android 11 (API‑Level 30) oder höher für Smartphones bzw. Android 13 (API‑Level 33) oder höher für Fernseher und Wear OS ausgeführt wird. Weitere Informationen finden Sie unter Android-Version prüfen und aktualisieren.
-
Wenn Sie die IDE verwenden, achten Sie darauf, dass Sie die aktuelle Version von Android Studio installiert haben. Hier herunterladen
-
Aktualisieren Sie auf Ihrer Workstation auf die neueste Version der SDK Platform Tools.
Wenn Sie das kabellose Debugging verwenden möchten, müssen Sie Ihr Gerät über einen QR‑Code oder einen Kopplungscode mit Ihrem Arbeitsplatzcomputer koppeln. Ihre Workstation und Ihr Gerät müssen mit demselben WLAN verbunden sein. So stellen Sie eine Verbindung zu Ihrem Gerät her:
-
Aktivieren Sie die Entwickleroptionen auf Ihrem Gerät.
-
Öffnen Sie Android Studio und wählen Sie im Menü für Ausführungskonfigurationen Geräte über WLAN koppeln aus.
Abbildung 1: Menü „Konfigurationen ausführen“Das Fenster Geräte über WLAN koppeln wird wie in Abbildung 2 angezeigt.
Abbildung 2: Pop-up-Fenster zum Koppeln von Geräten über einen QR-Code oder einen Kopplungscode. -
Tippen Sie auf Ihrem Gerät auf Drahtloses Debugging und koppeln Sie Ihr Gerät:
Abbildung 3: Screenshot der Einstellung Kabelloses Debugging auf einem Google Pixel Smartphone.-
Wenn Sie Ihr Gerät über einen QR‑Code koppeln möchten, wählen Sie Gerät über QR‑Code koppeln aus und scannen Sie den QR‑Code, den Sie im Pop‑up Geräte über WLAN koppeln (Abbildung 2) erhalten haben.
-
Wenn Sie Ihr Gerät über einen Kopplungscode koppeln möchten, wählen Sie im Pop-up-Fenster Geräte über WLAN koppeln die Option Gerät über einen Kopplungscode koppeln aus. Wähle auf deinem Gerät Über Kopplungscode koppeln aus und notiere dir den angezeigten sechsstelligen Code. Sobald Ihr Gerät im Fenster Geräte über WLAN koppeln angezeigt wird, können Sie Koppeln auswählen und den sechsstelligen Code eingeben, der auf Ihrem Gerät angezeigt wird.
Abbildung 4: Beispiel für die Eingabe eines sechsstelligen Codes.
-
-
Nachdem Ihr Gerät gekoppelt wurde, können Sie versuchen, Ihre App auf dem Gerät bereitzustellen.
Wenn Sie ein anderes Gerät koppeln oder das aktuelle Gerät auf Ihrer Workstation entfernen möchten, rufen Sie auf Ihrem Gerät Drahtloses Debugging auf. Tippen Sie unter Gekoppelte Geräte auf den Namen Ihres Arbeitsplatzes und wählen Sie Entfernen aus.
-
Wenn Sie das kabellose Debugging schnell aktivieren und deaktivieren möchten, können Sie die Kacheln für Schnelleinstellungen für Entwickler für Kabelloses Debugging verwenden. Sie finden sie unter Entwickleroptionen > Kacheln für Schnelleinstellungen für Entwickler.
Abbildung 5: Mit der Einstellung Kacheln für Schnelleinstellungen für Entwickler können Sie das kabellose Debugging schnell aktivieren und deaktivieren.
WLAN-Verbindung über die Befehlszeile
Alternativ können Sie auch ohne Android Studio über die Befehlszeile eine Verbindung zu Ihrem Gerät herstellen. Gehen Sie dazu so vor:
-
Aktiviere die Entwickleroptionen auf deinem Gerät, wie oben beschrieben.
-
Aktivieren Sie Kabelloses Debugging auf Ihrem Gerät, wie oben beschrieben.
-
Öffnen Sie auf Ihrer Workstation ein Terminalfenster und wechseln Sie zu
android_sdk/platform-tools
. -
Wähle Gerät über einen Kopplungscode koppeln aus, um deine IP-Adresse, Portnummer und deinen Kopplungscode aufzurufen. Notieren Sie sich die IP-Adresse, die Portnummer und den auf dem Gerät angezeigten Kopplungscode.
-
Führen Sie im Terminal Ihrer Workstation
adb pair ipaddr:port
aus. Verwenden Sie die IP-Adresse und Portnummer von oben. -
Gib bei Aufforderung den Kopplungscode ein, wie unten dargestellt.
Abbildung 6 Eine Meldung wird angezeigt, dass Ihr Gerät erfolgreich gekoppelt wurde.
Probleme mit der kabellosen Verbindung beheben
Wenn Sie Probleme beim Herstellen einer drahtlosen Verbindung zu Ihrem Gerät haben, versuchen Sie, das Problem mit den folgenden Schritten zur Fehlerbehebung zu beheben.
Prüfen, ob Ihre Workstation und Ihr Gerät die Voraussetzungen erfüllen
Prüfen Sie, ob die Workstation und das Gerät die Voraussetzungen am Anfang dieses Abschnitts erfüllen.
Nach anderen bekannten Problemen suchen
Im Folgenden finden Sie eine Liste der aktuellen bekannten Probleme beim drahtlosen Debugging (mit adb oder Android Studio) und Informationen zur Fehlerbehebung:
-
WLAN-Verbindung kann nicht hergestellt werden: Sichere WLANs wie Unternehmens-WLANs blockieren möglicherweise P2P-Verbindungen und lassen keine Verbindung über WLAN zu. Versuche, eine Verbindung über ein Kabel oder ein anderes (nicht geschäftliches) WLAN herzustellen. Eine weitere Option ist eine kabellose Verbindung über
adb connect ip:port
über TCP/IP (nach einer ersten USB-Verbindung), falls die Verwendung eines nicht unternehmenseigenen Netzwerks möglich ist. -
adb
über WLAN wird manchmal automatisch deaktiviert: Das kann passieren, wenn das Gerät entweder das WLAN wechselt oder die Verbindung zum Netzwerk getrennt wird. Stelle eine Verbindung zum Netzwerk her, um das Problem zu beheben. -
Gerät stellt nach erfolgreicher Kopplung keine Verbindung her:
adb
verwendet mDNS, um gekoppelte Geräte zu erkennen und automatisch eine Verbindung zu ihnen herzustellen. Wenn Ihr Netzwerk oder Ihre Gerätekonfiguration mDNS nicht unterstützt oder deaktiviert hat, müssen Sie manuell überadb connect ip:port
eine Verbindung zum Gerät herstellen.
Kabellose Verbindung mit einem Gerät nach einer ersten USB-Verbindung (einzige Option unter Android 10 und niedriger)
Hinweis:Dieser Workflow gilt auch für Android 11 und höher. Allerdings ist dafür auch eine *anfängliche* Verbindung über ein physisches USB-Kabel erforderlich.
Hinweis:Die folgende Anleitung gilt nicht für Wear-Geräte mit Android 10 (API-Level 29) oder niedriger. Weitere Informationen finden Sie im Leitfaden zum Debuggen einer Wear OS-App.
adb
kommuniziert in der Regel über USB mit dem Gerät, kann aber auch über WLAN verwendet werden.adb
So verbinden Sie ein Gerät mit Android 10 (API-Level 29) oder niedriger über USB:
-
Verbinden Sie Ihr Android-Gerät und den
adb
-Hostcomputer mit demselben WLAN. - Verbinden Sie das Gerät über ein USB-Kabel mit dem Hostcomputer.
-
Legen Sie fest, dass das Zielgerät auf Port 5555 auf eine TCP/IP-Verbindung wartet:
adb tcpip 5555
- Ziehen Sie das USB‑Kabel vom Zielgerät ab.
- Ermitteln Sie die IP-Adresse des Android-Geräts. Auf einem Nexus-Gerät finden Sie die IP-Adresse beispielsweise unter Einstellungen > Über das Tablet (oder Über das Smartphone) > Status > IP-Adresse.
-
Stellen Sie über die IP-Adresse eine Verbindung zum Gerät her:
adb connect device_ip_address:5555
-
Prüfen Sie, ob Ihr Hostcomputer mit dem Zielgerät verbunden ist:
$ adb devices List of devices attached device_ip_address:5555 device
Hinweis:Nicht alle Zugangspunkte sind geeignet. Möglicherweise müssen Sie einen Zugriffspunkt verwenden, dessen Firewall richtig für die Unterstützung von adb
konfiguriert ist.
Ihr Gerät ist jetzt mit adb
verbunden.
Wenn die adb
-Verbindung zu deinem Gerät unterbrochen wird:
- Das Hostgerät muss mit demselben WLAN verbunden sein wie dein Android-Gerät.
-
Stellen Sie die Verbindung wieder her, indem Sie den Schritt
adb connect
noch einmal ausführen. -
Wenn das nicht funktioniert, setzen Sie den
adb
-Host zurück:adb kill-server
Beginnen Sie dann noch einmal von vorn.
Geräte abfragen
Bevor Sie adb
-Befehle ausgeben, ist es hilfreich zu wissen, welche Geräteinstanzen mit dem adb
-Server verbunden sind. Erstellen Sie mit dem Befehl devices
eine Liste der angeschlossenen Geräte:
adb devices -l
Als Antwort gibt adb
diese Statusinformationen für jedes Gerät aus:
- Seriennummer:
adb
erstellt einen String, um das Gerät anhand seiner Portnummer eindeutig zu identifizieren. Beispiel für eine Seriennummer:emulator-5554
- Status:Der Verbindungsstatus des Geräts kann einer der folgenden sein:
offline
: Das Gerät ist nicht mitadb
verbunden oder reagiert nicht.device
: Das Gerät ist mit demadb
-Server verbunden. Dieser Status bedeutet nicht, dass das Android-System vollständig hochgefahren und betriebsbereit ist, da das Gerät eine Verbindung zuadb
herstellt, während das System noch hochfährt. Nach dem Hochfahren ist dies der normale Betriebszustand eines Geräts.no device
: Es ist kein Gerät verbunden.
- Beschreibung:Wenn Sie die Option
-l
einfügen, gibt der Befehldevices
an, um welches Gerät es sich handelt. Diese Information ist hilfreich, wenn mehrere Geräte verbunden sind, damit Sie sie unterscheiden können.
Das folgende Beispiel zeigt den Befehl devices
und seine Ausgabe. Es werden drei Geräte ausgeführt. Die ersten beiden Zeilen in der Liste sind Emulatoren und die dritte Zeile ist ein Hardwaregerät, das mit dem Computer verbunden ist.
$ 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
Emulator nicht aufgeführt
Der Befehl adb devices
hat eine Grenzfall-Befehlsfolge, die dazu führt, dass laufende Emulatoren nicht in der adb devices
-Ausgabe angezeigt werden, obwohl die Emulatoren auf Ihrem Desktop sichtbar sind. Dies ist möglich, wenn alle der folgenden Bedingungen erfüllt sind:
- Der Server „
adb
“ wird nicht ausgeführt. - Sie verwenden den Befehl
emulator
mit der Option-port
oder-ports
mit einem ungeraden Portwert zwischen 5554 und 5584. - Der von Ihnen ausgewählte Port mit ungerader Nummer ist nicht belegt. Die Portverbindung kann also über die angegebene Portnummer hergestellt werden. Wenn der Port belegt ist, wechselt der Emulator zu einem anderen Port, der die Anforderungen in Punkt 2 erfüllt.
- Sie starten den
adb
-Server, nachdem Sie den Emulator gestartet haben.
Eine Möglichkeit, dies zu vermeiden, besteht darin, dem Emulator die Auswahl der Ports zu überlassen und nicht mehr als 16 Emulatoren gleichzeitig auszuführen. Eine andere Möglichkeit besteht darin, den adb
-Server immer zu starten, bevor Sie den Befehl emulator
verwenden, wie in den folgenden Beispielen beschrieben.
Beispiel 1:In der folgenden Befehlsfolge wird der adb
-Server mit dem Befehl adb devices
gestartet, die Liste der Geräte wird jedoch nicht angezeigt.
Stoppen Sie den adb
-Server und geben Sie die folgenden Befehle in der angegebenen Reihenfolge ein. Geben Sie für den AVD-Namen einen gültigen AVD-Namen aus Ihrem System an. Geben Sie emulator -list-avds
ein, um eine Liste der AVD-Namen abzurufen. Der Befehl emulator
befindet sich im Verzeichnis 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 *
Beispiel 2:In der folgenden Befehlsfolge wird die Geräteliste von adb devices
angezeigt, da der adb
-Server zuerst gestartet wurde.
Wenn Sie den Emulator in der adb devices
-Ausgabe sehen möchten, stoppen Sie den adb
-Server und starten Sie ihn dann wieder, nachdem Sie den emulator
-Befehl und vor dem adb devices
-Befehl verwendet haben:
$ adb kill-server $ emulator -avd Nexus_6_API_25 -port 5557 $ adb start-server $ adb devices List of devices attached emulator-5557 device
Weitere Informationen zu den Befehlszeilenoptionen des Emulators finden Sie unter Befehlszeilen-Startoptionen.
Befehle an ein bestimmtes Gerät senden
Wenn mehrere Geräte ausgeführt werden, müssen Sie das Zielgerät angeben, wenn Sie den Befehl adb
ausführen.
So legen Sie das Ziel fest:
- Verwenden Sie den Befehl
devices
, um die Seriennummer des Ziels abzurufen. - Sobald Sie die Seriennummer haben, geben Sie sie mit der Option
-s
und denadb
-Befehlen an.- Wenn Sie viele
adb
-Befehle ausführen möchten, können Sie stattdessen die Umgebungsvariable$ANDROID_SERIAL
mit der Seriennummer festlegen. - Wenn Sie sowohl
-s
als auch$ANDROID_SERIAL
verwenden, wird$ANDROID_SERIAL
durch-s
überschrieben.
- Wenn Sie viele
Im folgenden Beispiel wird die Liste der angeschlossenen Geräte abgerufen. Anschließend wird die Seriennummer eines der Geräte verwendet, um die helloWorld.apk
auf diesem Gerät zu installieren:
$ 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
Hinweis: Wenn Sie einen Befehl ausgeben, ohne ein Zielgerät anzugeben, obwohl mehrere Geräte verfügbar sind, wird in adb
der Fehler „adb: more than one device/emulator“ (adb: mehr als ein Gerät/Emulator) angezeigt.
Wenn Sie mehrere Geräte zur Verfügung haben, aber nur eines davon ein Emulator ist, verwenden Sie die Option -e
, um Befehle an den Emulator zu senden. Wenn mehrere Geräte, aber nur ein Hardwaregerät angeschlossen sind, verwenden Sie die Option -d
, um Befehle an das Hardwaregerät zu senden.
App installieren
Mit adb
können Sie eine APK auf einem Emulator oder verbundenen Gerät mit dem Befehl install
installieren:
adb install path_to_apk
Sie müssen die Option -t
mit dem Befehl install
verwenden, wenn Sie eine Test-APK installieren. Weitere Informationen finden Sie unter -t
.
Verwenden Sie install-multiple
, um mehrere APKs zu installieren. Das ist nützlich, wenn Sie alle APKs für ein bestimmtes Gerät für Ihre App aus der Play Console herunterladen und auf einem Emulator oder physischen Gerät installieren möchten.
Weitere Informationen zum Erstellen einer APK-Datei, die Sie auf einer Emulator-/Geräteinstanz installieren können, finden Sie unter App erstellen und ausführen.
Hinweis:Wenn Sie Android Studio verwenden, müssen Sie adb
nicht direkt verwenden, um Ihre App auf dem Emulator oder Gerät zu installieren. Stattdessen übernimmt Android Studio das Verpacken und Installieren der App für Sie.
Portweiterleitung einrichten
Mit dem Befehl forward
können Sie eine beliebige Portweiterleitung einrichten, bei der Anfragen an einem bestimmten Hostport an einen anderen Port auf einem Gerät weitergeleitet werden.
Im folgenden Beispiel wird die Weiterleitung von Hostport 6100 an Geräteport 7100 eingerichtet:
adb forward tcp:6100 tcp:7100
Im folgenden Beispiel wird die Weiterleitung von Hostport 6100 an local:logd eingerichtet:
adb forward tcp:6100 local:logd
Das kann hilfreich sein, wenn Sie herausfinden möchten, was an einen bestimmten Port auf dem Gerät gesendet wird. Alle empfangenen Daten werden in den Systemprotokollierungs-Daemon geschrieben und in den Geräteprotokollen angezeigt.
Dateien auf ein Gerät kopieren und von einem Gerät kopieren
Mit den Befehlen pull
und push
können Sie Dateien auf ein Gerät kopieren und von einem Gerät kopieren. Im Gegensatz zum Befehl install
, mit dem nur eine APK-Datei an einen bestimmten Speicherort kopiert wird, können Sie mit den Befehlen pull
und push
beliebige Verzeichnisse und Dateien an einen beliebigen Speicherort auf einem Gerät kopieren.
So kopieren Sie eine Datei oder ein Verzeichnis und seine Unterverzeichnisse vom Gerät:
adb pull remote local
So kopieren Sie eine Datei oder ein Verzeichnis und seine Unterverzeichnisse auf das Gerät:
adb push local remote
Ersetzen Sie local
und remote
durch die Pfade zu den Zieldateien bzw. dem Zielverzeichnis auf Ihrem Entwicklungscomputer (lokal) und auf dem Gerät (remote). Beispiel:
adb push myfile.txt /sdcard/myfile.txt
adb-Server stoppen
In einigen Fällen müssen Sie den adb
-Serverprozess beenden und dann neu starten, um das Problem zu beheben. Das kann beispielsweise der Fall sein, wenn adb
nicht auf einen Befehl reagiert.
Verwenden Sie den Befehl adb kill-server
, um den adb
-Server zu beenden.
Sie können den Server dann neu starten, indem Sie einen beliebigen anderen adb
-Befehl ausführen.
ADB-Befehle ausführen
Geben Sie adb
-Befehle über die Befehlszeile auf Ihrem Entwicklungscomputer oder über ein Skript mit Folgendem aus:
adb [-d | -e | -s serial_number] command
Wenn nur ein Emulator ausgeführt wird oder nur ein Gerät verbunden ist, wird der Befehl adb
standardmäßig an dieses Gerät gesendet. Wenn mehrere Emulatoren ausgeführt werden und/oder mehrere Geräte angeschlossen sind, müssen Sie mit der Option -d
, -e
oder -s
das Zielgerät angeben, an das der Befehl gesendet werden soll.
Mit dem folgenden Befehl können Sie eine detaillierte Liste aller unterstützten adb
-Befehle aufrufen:
adb --help
Shell-Befehle ausführen
Mit dem Befehl shell
können Sie Gerätebefehle über adb
ausführen oder eine interaktive Shell starten. So geben Sie einen einzelnen Befehl aus:shell
adb [-d |-e | -s serial_number] shell shell_command
So starten Sie eine interaktive Shell auf einem Gerät:shell
adb [-d | -e | -s serial_number] shell
Wenn Sie eine interaktive Shell beenden möchten, drücken Sie Control+D
oder geben Sie exit
ein.
Android bietet die meisten der üblichen Unix-Befehlszeilentools. Eine Liste der verfügbaren Tools erhalten Sie mit dem folgenden Befehl:
adb shell ls /system/bin
Für die meisten Befehle ist über das Argument --help
Hilfe verfügbar.
Viele der Shell-Befehle werden von Toybox bereitgestellt.
Allgemeine Hilfe für alle Toybox-Befehle ist über toybox --help
verfügbar.
In Android Platform Tools 23 und höher verarbeitet adb
Argumente auf dieselbe Weise wie der Befehl ssh(1)
. Durch diese Änderung wurden viele Probleme mit Command Injection behoben. Außerdem können jetzt Befehle, die Shell-Metazeichen wie adb install Let\'sGo.apk
enthalten, sicher ausgeführt werden. Diese Änderung bedeutet, dass sich auch die Interpretation von Befehlen mit Shell-Metazeichen geändert hat.
Beispiel: adb shell setprop key 'two words'
ist jetzt ein Fehler, da die Anführungszeichen von der lokalen Shell verschluckt werden und das Gerät adb shell setprop key two words
sieht. Damit der Befehl funktioniert, müssen Sie ihn zweimal in Anführungszeichen setzen, einmal für die lokale Shell und einmal für die Remote-Shell, wie bei ssh(1)
. adb shell setprop key "'two words'"
funktioniert beispielsweise, weil die lokale Shell die äußere Ebene der Anführungszeichen übernimmt und das Gerät weiterhin die innere Ebene der Anführungszeichen sieht: setprop key 'two words'
. Sie können die Zeichen auch maskieren, aber das doppelte Setzen von Anführungszeichen ist in der Regel einfacher.
Das Logcat-Befehlszeilentool ist nützlich, um das Systemlog zu überwachen.
Anrufaktivitätsmanager
In einer adb
-Shell können Sie mit dem Aktivitätsmanager-Tool (am
) Befehle ausgeben, um verschiedene Systemaktionen auszuführen, z. B. eine Aktivität starten, einen Prozess erzwingen, einen Intent übertragen oder die Eigenschaften des Gerätebildschirms ändern.
In einer Shell lautet die am
-Syntax so:
am command
Sie können auch einen Befehl für den Aktivitätsmanager direkt über adb
ausgeben, ohne eine Remote-Shell zu öffnen. Beispiel:
adb shell am start -a android.intent.action.VIEW
Tabelle 1 Verfügbare Befehle für den Aktivitätsmanager
Befehl | Beschreibung |
---|---|
start [options] intent
|
Starte eine Activity , die von intent angegeben wird. Weitere Informationen finden Sie in der Spezifikation für Intent-Argumente. Es gibt folgende Optionen:
|
startservice [options] intent
|
Startet die Service , die durch intent angegeben wird. Weitere Informationen finden Sie in der Spezifikation für Intent-Argumente. Es gibt folgende Optionen:
|
force-stop package
|
Erzwingen Sie das Beenden aller Prozesse, die mit package verknüpft sind.
|
kill [options] package
|
Beenden Sie alle Prozesse, die mit package verknüpft sind. Mit diesem Befehl werden nur Prozesse beendet, die sicher beendet werden können und die sich nicht auf die Nutzerfreundlichkeit auswirken.
Es gibt folgende Optionen:
|
kill-all
|
Beenden Sie alle Hintergrundprozesse. |
broadcast [options] intent
|
Broadcast-Intent ausgeben Weitere Informationen finden Sie in der Spezifikation für Intent-Argumente. Es gibt folgende Optionen:
|
instrument [options] component
|
Beginnen Sie mit der Überwachung mit einer Instrumentation -Instanz.
Normalerweise hat das Ziel component die Form test_package/runner_class . Es gibt folgende Optionen:
|
profile start process file
|
Profiler für process starten und Ergebnisse in file schreiben.
|
profile stop process
|
Profiler bei process beenden.
|
dumpheap [options] process file
|
Heap von process sichern und in file schreiben. Es gibt folgende Optionen:
|
dumpbitmaps [options] [-p process]
|
Bitmap-Informationen aus process ausgeben (API-Level 36 und höher).
Es gibt folgende Optionen:
process angegeben ist, werden Bitmaps aus allen Prozessen ausgegeben.
|
set-debug-app [options] package
|
Legen Sie die App package für das Debugging fest. Es gibt folgende Optionen:
|
clear-debug-app
|
Löschen Sie das Paket, das zuvor für das Debugging mit set-debug-app festgelegt wurde.
|
monitor [options]
|
Mit dem Monitoring von Abstürzen oder ANR-Fehlern beginnen Es gibt folgende Optionen:
|
screen-compat {on | off} package
|
Steuern Sie den Bildschirmkompatibilitätsmodus von package .
|
display-size [reset | widthxheight]
|
Die Displaygröße des Geräts überschreiben.
Dieser Befehl ist hilfreich, um Ihre App auf verschiedenen Bildschirmgrößen zu testen, indem Sie auf einem Gerät mit großem Bildschirm eine niedrige Bildschirmauflösung simulieren und umgekehrt.
Beispiel: |
display-density dpi
|
Kompaktheitsgrad des Geräts überschreiben.
Dieser Befehl ist hilfreich, um Ihre App bei verschiedenen Bildschirmdichten zu testen, indem Sie eine Umgebung mit hoher Dichte auf einem Bildschirm mit niedriger Dichte simulieren und umgekehrt.
Beispiel: |
to-uri intent
|
Gibt die angegebene Intent-Spezifikation als URI aus. Weitere Informationen finden Sie in der Spezifikation für Intent-Argumente. |
to-intent-uri intent
|
Gibt die angegebene Intent-Spezifikation als intent: -URI aus. Weitere Informationen finden Sie in der Spezifikation für Intent-Argumente. |
Spezifikation für Intent-Argumente
Bei Befehlen des Aktivitätsmanagers, die ein intent
-Argument verwenden, können Sie die Intention mit den folgenden Optionen angeben:
Paketmanager aufrufen (pm
)
In einer adb
-Shell können Sie mit dem Paketmanager-Tool (pm
) Befehle ausführen, um Aktionen und Abfragen für auf dem Gerät installierte App-Pakete durchzuführen.
In einer Shell lautet die pm
-Syntax so:
pm command
Sie können auch einen Paketmanagerbefehl direkt über adb
ausführen, ohne eine Remote-Shell zu öffnen. Beispiel:
adb shell pm uninstall com.example.MyApp
Tabelle 2 Verfügbare Paketmanager-Befehle
Befehl | Beschreibung |
---|---|
list packages [options] filter
|
Alle Pakete ausgeben, optional nur diejenigen, deren Paketname den Text in filter enthält. Optionen:
|
list permission-groups
|
Alle bekannten Berechtigungsgruppen ausgeben. |
list permissions [options] group
|
Alle bekannten Berechtigungen ausgeben, optional nur die in group . Optionen:
|
list instrumentation [options]
|
Alle Testpakete auflisten. Optionen:
|
list features
|
Alle Funktionen des Systems ausgeben. |
list libraries
|
Gibt alle vom aktuellen Gerät unterstützten Bibliotheken aus. |
list users
|
Alle Nutzer im System ausgeben. |
path package
|
Gibt den Pfad zur APK-Datei des angegebenen package aus.
|
install [options] path
|
Installiert ein durch path angegebenes Paket auf dem System. Optionen:
|
uninstall [options] package
|
Entfernt ein Paket aus dem System. Optionen:
|
clear package
|
Alle mit einem Paket verknüpften Daten löschen |
enable package_or_component
|
Aktivieren Sie das angegebene Paket oder die angegebene Komponente (im Format „Paket/Klasse“). |
disable package_or_component
|
Deaktivieren Sie das angegebene Paket oder die angegebene Komponente (im Format „Paket/Klasse“). |
disable-user [options] package_or_component
|
Optionen:
|
grant package_name permission
|
Erteilen Sie einer App eine Berechtigung. Auf Geräten mit Android 6.0 (API-Level 23) und höher kann die Berechtigung eine beliebige Berechtigung sein, die im App-Manifest deklariert ist. Auf Geräten mit Android 5.1 (API-Ebene 22) und niedriger muss eine optionale Berechtigung definiert sein, die von der App angefordert wird. |
revoke package_name permission
|
Entziehen Sie einer App eine Berechtigung. Auf Geräten mit Android 6.0 (API-Level 23) und höher kann es sich dabei um eine beliebige Berechtigung handeln, die im App-Manifest deklariert ist. Auf Geräten mit Android 5.1 (API-Ebene 22) und niedriger muss eine optionale Berechtigung definiert sein, die von der App angefordert wird. |
set-install-location location
|
Ändern Sie den Standardinstallationsort. Standortwerte:
Hinweis:Dies ist nur für das Debugging vorgesehen. Die Verwendung dieser Funktion kann dazu führen, dass Apps nicht mehr funktionieren und andere unerwünschte Verhaltensweisen auftreten. |
get-install-location
|
Gibt den aktuellen Installationsort zurück. Rückgabewerte:
|
set-permission-enforced permission [true | false]
|
Geben Sie an, ob die angegebene Berechtigung erzwungen werden soll. |
trim-caches desired_free_space
|
Cache-Dateien kürzen, um den angegebenen freien Speicherplatz zu erreichen. |
create-user user_name
|
Erstelle einen neuen Nutzer mit der angegebenen user_name und gib die neue Nutzer-ID des Nutzers aus.
|
remove-user user_id
|
Entfernen Sie den Nutzer mit der angegebenen user_id und löschen Sie alle Daten, die mit diesem Nutzer verknüpft sind.
|
get-max-users
|
Gibt die maximale Anzahl von Nutzern aus, die vom Gerät unterstützt werden. |
get-app-links [options] [package]
|
Gibt den Status der Domainbestätigung für die angegebene package oder für alle Pakete aus, wenn keine angegeben ist. Die Bundesstaatscodes sind so definiert:
Es gibt folgende Optionen:
|
reset-app-links [options] [package]
|
Setzt den Status der Domainbestätigung für das angegebene Paket oder für alle Pakete zurück, wenn keines angegeben ist.
Es gibt folgende Optionen:
|
verify-app-links [--re-verify] [package]
|
Sendet eine Bestätigungsanfrage für die angegebene package oder für alle Pakete, wenn keine angegeben ist. Wird nur gesendet, wenn für das Paket zuvor keine Antwort aufgezeichnet wurde.
|
set-app-links [--package package] state domains
|
Status einer Domain für ein Paket manuell festlegen Die Domain muss vom Paket als „autoVerify“ deklariert werden, damit dies funktioniert. Bei Domains, die nicht angewendet werden konnten, wird mit diesem Befehl kein Fehler gemeldet.
|
set-app-links-user-selection --user user_id [--package package]
enabled domains
|
Den Status der Auswahl eines Hostnutzers für ein Paket manuell festlegen. Die Domain muss vom Paket deklariert werden, damit dies funktioniert. Bei Domains, auf die der Befehl nicht angewendet werden konnte, wird kein Fehler gemeldet.
|
set-app-links-allowed --user user_id [--package package] allowed
|
Die Einstellung für die automatische Überprüfung der Linkbearbeitung für ein Paket umschalten.
|
get-app-link-owners --user user_id [--package package] domains
|
Gibt die Inhaber einer bestimmten Domain für einen bestimmten Nutzer in der Reihenfolge von niedriger bis hoher Priorität aus.
|
Geräterichtlinienmanager aufrufen (dpm
)
Um Ihnen die Entwicklung und das Testen Ihrer Geräteverwaltungs-Apps zu erleichtern, können Sie Befehle an das Tool für den Geräterichtlinienmanager (dpm
) senden. Mit dem Tool können Sie die aktive Administrator-App steuern oder die Statusdaten einer Richtlinie auf dem Gerät ändern.
In einer Shell lautet die dpm
-Syntax so:
dpm command
Sie können auch einen Befehl des Gerätepolicy-Managers direkt über adb
ausgeben, ohne eine Remote-Shell zu öffnen:
adb shell dpm command
Tabelle 3 Verfügbare Device Policy Manager-Befehle
Befehl | Beschreibung |
---|---|
set-active-admin [options] component
|
Legt component als aktiven Administrator fest.
Es gibt folgende Optionen:
|
set-profile-owner [options] component
|
component als aktiven Administrator und sein Paket als Profilinhaber für einen vorhandenen Nutzer festlegen.
Es gibt folgende Optionen:
|
set-device-owner [options] component
|
Legen Sie component als aktiven Administrator und sein Paket als Geräteinhaber fest.
Es gibt folgende Optionen:
|
remove-active-admin [options] component
|
Aktiven Administrator deaktivieren In der App muss android:testOnly im Manifest deklariert werden. Mit diesem Befehl werden auch Geräte- und Profileigentümer entfernt.
Es gibt folgende Optionen:
|
clear-freeze-period-record
|
Löschen Sie den Datensatz des Geräts mit zuvor festgelegten Einfrierzeiträumen für OTA-Systemupdates. Das ist nützlich, um die Einschränkungen bei der Geräteplanung zu umgehen, wenn Sie Apps entwickeln, die Sperrzeiten verwalten. Weitere Informationen
Wird auf Geräten mit Android 9.0 (API-Level 28) und höher unterstützt. |
force-network-logs
|
Das System wird gezwungen, alle vorhandenen Netzwerkprotokolle für den Abruf durch einen Geräteinhaber bereitzustellen. Wenn Verbindungs- oder DNS-Logs verfügbar sind, erhält der Geräteinhaber-Controller den onNetworkLogsAvailable() -Callback. Weitere Informationen finden Sie unter Protokollierung der Netzwerkaktivität.
Für diesen Befehl gilt eine Ratenbegrenzung. Wird auf Geräten mit Android 9.0 (API-Level 28) und höher unterstützt. |
force-security-logs
|
Das System wird gezwungen, alle vorhandenen Sicherheitslogs dem Geräteinhaberprofil zur Verfügung zu stellen. Wenn Logs verfügbar sind, erhält der DPC den onSecurityLogsAvailable() -Callback. Weitere Informationen finden Sie unter Aktivitäten auf Unternehmensgeräten protokollieren.
Für diesen Befehl gilt eine Ratenbegrenzung. Wird auf Geräten mit Android 9.0 (API-Level 28) und höher unterstützt. |
Screenshot erstellen
Der Befehl screencap
ist ein Shell-Dienstprogramm zum Erstellen eines Screenshots des Displays eines Geräts.
In einer Shell lautet die screencap
-Syntax so:
screencap filename
Geben Sie Folgendes ein, um screencap
über die Befehlszeile zu verwenden:
adb shell screencap /sdcard/screen.png
Hier sehen Sie ein Beispiel für eine Screenshot-Sitzung, in der die adb
-Shell zum Erstellen des Screenshots und der Befehl pull
zum Herunterladen der Datei vom Gerät verwendet werden:
$ adb shell shell@ $ screencap /sdcard/screen.png shell@ $ exit $ adb pull /sdcard/screen.png
Wenn Sie den Dateinamen weglassen, schreibt screencap
das Bild in die Standardausgabe. In Kombination mit der Option -p
zum Angeben des PNG-Formats können Sie den Gerätescreenshot direkt in eine Datei auf Ihrem lokalen Computer streamen.
Hier ist ein Beispiel dafür, wie Sie mit einem einzigen Befehl einen Screenshot erstellen und lokal speichern:
# use 'exec-out' instead of 'shell' to get raw data $ adb exec-out screencap -p > screen.png
Nimm ein Video auf
Der Befehl screenrecord
ist ein Shell-Dienstprogramm zum Aufzeichnen der Anzeige von Geräten mit Android 4.4 (API-Level 19) und höher. Das Dienstprogramm zeichnet Bildschirmaktivitäten in einer MPEG‑4-Datei auf. Sie können diese Datei verwenden, um Werbe- oder Schulungsvideos zu erstellen oder um Fehler zu beheben und Tests durchzuführen.
Verwenden Sie in einer Shell die folgende Syntax:
screenrecord [options] filename
Geben Sie Folgendes ein, um screenrecord
über die Befehlszeile zu verwenden:
adb shell screenrecord /sdcard/demo.mp4
Beenden Sie die Bildschirmaufzeichnung, indem Sie Strg+C drücken. Andernfalls wird die Aufnahme nach drei Minuten oder nach dem von --time-limit
festgelegten Zeitlimit automatisch beendet.
Führen Sie den Befehl screenrecord
aus, um die Aufnahme des Gerätebildschirms zu starten. Führen Sie dann den Befehl pull
aus, um das Video vom Gerät auf den Hostcomputer herunterzuladen. Hier ein Beispiel für eine Aufnahmesitzung:
$ adb shell shell@ $ screenrecord --verbose /sdcard/demo.mp4 (press Control + C to stop) shell@ $ exit $ adb pull /sdcard/demo.mp4
Mit dem Tool screenrecord
können Sie in jeder unterstützten Auflösung und Bitrate aufnehmen, die Sie anfordern, wobei das Seitenverhältnis des Gerätedisplays beibehalten wird. Das Tool zeichnet standardmäßig in der nativen Bildschirmauflösung und -ausrichtung auf. Die maximale Länge beträgt drei Minuten.
Einschränkungen des Dienstprogramms screenrecord
:
- Die Videodatei enthält keinen Ton.
- Die Videoaufzeichnung ist für Geräte mit Wear OS nicht verfügbar.
- Einige Geräte können möglicherweise nicht in ihrer nativen Displayauflösung aufzeichnen. Wenn Probleme bei der Bildschirmaufzeichnung auftreten, versuchen Sie, eine niedrigere Bildschirmauflösung zu verwenden.
- Das Drehen des Bildschirms während der Aufnahme wird nicht unterstützt. Wenn sich das Display während der Aufnahme dreht, wird ein Teil des Bildschirms in der Aufnahme abgeschnitten.
Tabelle 4. screenrecord
Optionen
Optionen | Beschreibung |
---|---|
--help
|
Befehlssyntax und ‑optionen anzeigen |
--size widthxheight
|
Legen Sie die Videogröße fest: 1280x720 . Der Standardwert ist die native Bildschirmauflösung des Geräts (sofern unterstützt), andernfalls 1280 × 720. Die besten Ergebnisse erzielst du, wenn du eine Größe verwendest, die vom AVC-Encoder (Advanced Video Coding) deines Geräts unterstützt wird. |
--bit-rate rate |
Legen Sie die Video-Bitrate für das Video in Megabit pro Sekunde fest. Der Standardwert ist 20 Mbit/s.
Sie können die Bitrate erhöhen, um die Videoqualität zu verbessern. Dadurch werden jedoch größere Filmdateien erstellt. Im folgenden Beispiel wird die Bitrate für die Aufzeichnung auf 6 Mbit/s festgelegt:
screenrecord --bit-rate 6000000 /sdcard/demo.mp4 |
--time-limit time |
Legen Sie die maximale Aufnahmedauer in Sekunden fest. Der Standard- und der Höchstwert sind 180 (3 Minuten). |
--rotate |
Drehe die Ausgabe um 90 Grad. Diese Funktion wird noch getestet. |
--verbose |
Loginformationen auf dem Befehlszeilenbildschirm anzeigen. Wenn Sie diese Option nicht festlegen, werden während der Ausführung des Dienstprogramms keine Informationen angezeigt. |
ART-Profile für Apps lesen
Ab Android 7.0 (API-Ebene 24) erfasst die Android-Laufzeitumgebung (Android Runtime, ART) Ausführungsprofile für installierte Apps, die zur Optimierung der App-Leistung verwendet werden. Untersuchen Sie die erfassten Profile, um zu sehen, welche Methoden häufig ausgeführt werden und welche Klassen beim Starten der App verwendet werden.
Hinweis:Der Dateiname des Ausführungsprofils kann nur abgerufen werden, wenn Sie Root-Zugriff auf das Dateisystem haben, z. B. auf einem Emulator.
Verwenden Sie den folgenden Befehl, um eine Textform der Profilinformationen zu erstellen:
adb shell cmd package dump-profiles package
So rufen Sie die erstellte Datei ab:
adb pull /data/misc/profman/package.prof.txt
Testgeräte zurücksetzen
Wenn Sie Ihre App auf mehreren Testgeräten testen, kann es sinnvoll sein, Ihr Gerät zwischen den Tests zurückzusetzen, um beispielsweise Nutzerdaten zu entfernen und die Testumgebung zurückzusetzen. Sie können ein Testgerät mit Android 10 (API-Level 29) oder höher mit dem Shell-Befehl testharness
adb
auf die Werkseinstellungen zurücksetzen. Beispiel:
adb shell cmd testharness enable
Wenn das Gerät mit testharness
wiederhergestellt wird, wird der RSA-Schlüssel, der das Debugging über die aktuelle Workstation ermöglicht, automatisch an einem persistenten Speicherort gesichert. Das heißt, nachdem das Gerät zurückgesetzt wurde, kann die Workstation weiterhin debuggen und adb
-Befehle an das Gerät senden, ohne dass ein neuer Schlüssel manuell registriert werden muss.
Außerdem werden durch die Verwendung von testharness
zum Wiederherstellen eines Geräts auch die folgenden Geräteeinstellungen geändert, um das Testen Ihrer App zu vereinfachen und sicherer zu machen:
- Das Gerät richtet bestimmte Systemeinstellungen so ein, dass die Assistenten für die Ersteinrichtung des Geräts nicht angezeigt werden. Das Gerät wechselt also in einen Zustand, in dem Sie Ihre App schnell installieren, debuggen und testen können.
- Einstellungen:
- Deaktiviert den Sperrbildschirm.
- Deaktiviert Notfallbenachrichtigungen.
- Deaktiviert die automatische Synchronisierung für Konten.
- Deaktiviert automatische Systemupdates.
- Sonstiges:
- Deaktiviert vorinstallierte Sicherheits-Apps.
Wenn Ihre App die Standardeinstellungen des testharness
-Befehls erkennen und sich daran anpassen muss, verwenden Sie die
ActivityManager.isRunningInUserTestHarness()
.
sqlite
Mit sqlite3
wird das Befehlszeilenprogramm sqlite
zum Untersuchen von SQLite-Datenbanken gestartet.
Dazu gehören Befehle wie .dump
zum Ausgeben des Inhalts einer Tabelle und .schema
zum Ausgeben der SQL CREATE
-Anweisung für eine vorhandene Tabelle.
Sie können SQLite-Befehle auch über die Befehlszeile ausführen, wie hier gezeigt:
$ adb -s emulator-5554 shell $ sqlite3 /data/data/com.example.app/databases/rssitems.db SQLite version 3.3.12 Enter ".help" for instructions
Hinweis:Auf eine SQLite-Datenbank kann nur zugegriffen werden, wenn Sie Root-Zugriff auf das Dateisystem haben, z. B. auf einem Emulator.
Weitere Informationen finden Sie in der sqlite3
-Befehlszeilendokumentation.
adb-USB-Back-Ends
Der ADB-Server kann über zwei Back-Ends mit dem USB-Stack interagieren. Dabei kann entweder das native Backend des Betriebssystems (Windows, Linux oder macOS) oder das libusb
-Backend verwendet werden.
Einige Funktionen wie attach
, detach
und die Erkennung der USB-Geschwindigkeit sind nur verfügbar, wenn das libusb
-Backend verwendet wird.
Sie können ein Backend mit der Umgebungsvariable ADB_LIBUSB
auswählen.
Wenn sie nicht festgelegt ist, verwendet adb das Standard-Backend. Das Standardverhalten variiert je nach Betriebssystem. Ab ADB v34 wird das liubusb
-Back-End standardmäßig auf allen Betriebssystemen außer Windows verwendet. Dort wird standardmäßig das native Back-End verwendet. Wenn ADB_LIBUSB
festgelegt ist, wird bestimmt, ob das native Backend oder libusb
verwendet wird. Weitere Informationen zu adb-Umgebungsvariablen finden Sie auf der adb-Handbuchseite.
adb-mDNS-Back-Ends
ADB kann das Multicast-DNS-Protokoll verwenden, um automatisch eine Verbindung zwischen dem Server und den Geräten herzustellen. Der ADB-Server wird mit zwei Backends ausgeliefert: Bonjour (mdnsResponder von Apple) und Openscreen.
Für das Bonjour-Backend muss ein Daemon auf dem Hostcomputer ausgeführt werden.
Unter macOS wird der integrierte Daemon von Apple immer ausgeführt. Unter Windows und Linux muss der Nutzer jedoch dafür sorgen, dass der mdnsd
-Daemon ausgeführt wird.
Wenn der Befehl adb mdns check
einen Fehler zurückgibt, verwendet ADB wahrscheinlich das Bonjour-Backend, aber es wird kein Bonjour-Daemon ausgeführt.
Für das Openscreen-Backend ist kein Daemon erforderlich, der auf dem Computer ausgeführt wird. Die Unterstützung für das Openscreen-Backend unter macOS beginnt mit ADB v35. Windows und Linux werden ab ADB v34 unterstützt.
Standardmäßig verwendet ADB das Bonjour-Backend. Dieses Verhalten kann mit der Umgebungsvariable ADB_MDNS_OPENSCREEN
geändert werden (auf 1
oder 0
festgelegt). Weitere Informationen finden Sie auf der ADB-Handbuchseite.
adb-Burst-Modus (ab ADB 36.0.0)
Der Burst-Modus ist eine experimentelle Funktion, mit der ADB weiterhin Pakete an ein Gerät senden kann, auch bevor das Gerät auf das vorherige Paket geantwortet hat. Dadurch wird der ADB-Durchsatz beim Übertragen großer Dateien erheblich erhöht und die Latenzzeit beim Debuggen verringert.
Der Serienbildmodus ist standardmäßig deaktiviert. Führen Sie einen der folgenden Schritte aus, um das Feature zu aktivieren:
- Setzen Sie die Umgebungsvariable
ADB_DELAYED_ACK
auf1
. - Rufen Sie in Android Studio die Debugger-Einstellungen unter Datei (oder Android Studio unter macOS) > Einstellungen > Build, Ausführung, Bereitstellung > Debugger auf und setzen Sie ADB Server Burst Mode auf Aktiviert.