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 eine Vielzahl von Befehlen auf einem Gerät ausführen können. Es ist ein Client-Server-Programm, das drei Komponenten umfasst:
- Einen Client, der Befehle sendet. Der Client wird auf Ihrem Entwicklungscomputer ausgeführt. Sie können einen Client von einem Befehlszeilenterminal aufrufen, indem Sie einen
adb
-Befehl ausführen. - 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. Dieser wird dort unter android_sdk/platform-tools/
installiert. Wenn Sie das eigenständige Android SDK Platform Tools-Paket benötigen, laden Sie es hier herunter.
Informationen zum Verbinden eines Geräts zur Nutzung ü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 er zuerst, ob bereits ein adb
-Serverprozess ausgeführt wird. Andernfalls wird der Serverprozess gestartet.
Beim Start stellt der Server eine Bindung an den lokalen TCP-Port 5037 her und wartet auf Befehle, die von adb
-Clients gesendet werden.
Hinweis: Alle adb
-Clients kommunizieren über Port 5037 mit dem adb
-Server.
Der Server richtet dann Verbindungen zu allen laufenden Geräten ein.
Die Emulatoren werden durch Scannen von Ports mit ungerader Nummer im Bereich 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 sequenzieller Ports – einen Port mit gerader Nummer für Konsolenverbindungen und einen Port mit ungerader Nummer für adb
-Verbindungen. Beispiele:
Emulator 1, Konsole: 5554
Emulator 1, adb
: 5555
Emulator 2, Konsole: 5556
Emulator 2, adb
: 5557
und so weiter.
Wie gezeigt, ist der Emulator, der über Port 5555 mit adb
verbunden ist, mit dem Emulator identisch, dessen Konsole Port 5554 überwacht.
Sobald der Server Verbindungen zu allen Geräten eingerichtet 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 über ein Skript aus steuern.
ADB-Debugging auf Ihrem Gerät aktivieren
Um ADB mit einem über USB verbundenen Gerät zu verwenden, müssen Sie USB-Debugging in den Systemeinstellungen des Geräts unter Entwickleroptionen aktivieren. Unter Android 4.2 (API-Level 17) und höher ist der Bildschirm Entwickleroptionen standardmäßig ausgeblendet. Aktivieren Sie die Entwickleroptionen, um sie sichtbar zu machen.
Du kannst dein Gerät jetzt per USB verbinden. Sie können prüfen, ob Ihr Gerät verbunden ist, indem Sie adb devices
aus dem Verzeichnis android_sdk/platform-tools/
ausführen. Wenn eine Verbindung besteht, wird der Gerätename als „Gerät“ angezeigt.
Hinweis:Wenn du ein Gerät mit Android 4.2.2 (API-Level 17) oder höher verbindest, wird ein Dialogfeld angezeigt, in dem du gefragt wirst, ob ein RSA-Schlüssel akzeptiert werden soll, der das Debugging über diesen Computer ermöglicht. Dieser Sicherheitsmechanismus schützt Nutzergeräte, da er dafür sorgt, dass USB-Debugging und andere ADB-Befehle nur dann ausgeführt werden können, wenn Sie das Gerät entsperren und das Dialogfeld bestätigen können.
Weitere Informationen zum Anschließen eines Geräts über USB finden Sie unter Apps auf einem Hardwaregerät ausführen.
Gerät über WLAN verbinden
Hinweis: Die folgende Anleitung gilt nicht für Wear-Geräte mit Android 11 (API-Level 30). Weitere Informationen findest du im Leitfaden zur Fehlerbehebung bei Wear OS-Apps.
Android 11 (API-Level 30) und höher unterstützen die drahtlose Bereitstellung und Fehlerbehebung von Apps über Ihre Workstation mithilfe von Android Debug Bridge (ADB). So können Sie beispielsweise Ihre debugfähige App auf mehreren Remote-Geräten bereitstellen, ohne das Gerät physisch über USB verbinden zu müssen. Dadurch entfällt die Notwendigkeit, sich mit häufigen USB-Verbindungsproblemen wie der Treiberinstallation auseinanderzusetzen.
Bevor Sie das Debugging über WLAN nutzen, gehen Sie so vor:
-
Achten Sie darauf, dass Workstation und Gerät mit demselben WLAN verbunden sind.
-
Auf deinem Gerät muss 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 installiert sein. Weitere Informationen finden Sie unter Android-Version prüfen und aktualisieren.
-
Wenn Sie die IDE verwenden, achten Sie darauf, dass Sie die neueste Version von Android Studio installiert haben. Sie können sie hier herunterladen.
-
Führen Sie auf Ihrer Workstation ein Update auf die neueste Version der SDK Platform Tools durch.
Für das Debugging über WLAN musst du dein Gerät über einen QR-Code oder einen Kopplungscode mit deiner Workstation koppeln. Workstation und Gerät müssen mit demselben WLAN verbunden sein. So stellen Sie eine Verbindung zu Ihrem Gerät her:
-
Aktivieren Sie Entwickleroptionen auf Ihrem Gerät.
-
Öffnen Sie Android Studio und wählen Sie im Menü „Ausführungskonfigurationen“ die Option Geräte über WLAN koppeln aus.
Das Fenster Geräte über WLAN koppeln wird angezeigt (Abbildung 2).
-
Tippen Sie auf Ihrem Gerät auf Debugging bei kabellosem Laden und koppeln Sie Ihr Gerät:
-
Wenn du dein Gerät mit einem QR-Code koppeln möchtest, wähle Gerät über QR-Code koppeln aus und scanne den QR-Code, den du aus dem Pop-up-Fenster Geräte über WLAN koppeln in Abbildung 2 erhalten hast.
-
Wenn du dein Gerät mit einem Kopplungscode koppeln möchtest, wähle im Pop-up-Fenster Geräte über WLAN koppeln die Option Gerät über Kopplungscode koppeln aus. Wähle auf deinem Gerät Über Kopplungscode koppeln aus und notiere dir den sechsstelligen Code. Sobald dein Gerät im Fenster Geräte über WLAN koppeln angezeigt wird, kannst du Koppeln auswählen und den sechsstelligen Code eingeben, der auf deinem Gerät angezeigt wird.
-
-
Nachdem dein Gerät gekoppelt ist, kannst du versuchen, die App auf deinem Gerät bereitzustellen.
Wenn du ein anderes Gerät koppeln oder das aktuelle Gerät auf deiner Workstation entfernen möchtest, navigiere auf deinem Gerät zu Debugging über WLAN. Tippen Sie unter Gekoppelte Geräte auf den Namen Ihrer Workstation und wählen Sie Entfernen aus.
-
Wenn du das kabellose Debugging schnell aktivieren und deaktivieren möchtest, kannst du die Entwicklerkacheln für Schnelleinstellungen für das WLAN-Debugging verwenden. Du findest sie unter Entwickleroptionen > Entwicklerkacheln für Schnelleinstellungen.
WLAN-Verbindung über die Befehlszeile
Alternativ können Sie auch die folgenden Schritte ausführen, um ohne Android Studio über die Befehlszeile eine Verbindung zu Ihrem Gerät herzustellen:
-
Aktivieren Sie die Entwickleroptionen auf Ihrem Gerät, wie zuvor beschrieben.
-
Aktivieren Sie Debugging über WLAN auf Ihrem Gerät, wie zuvor beschrieben.
-
Öffnen Sie auf Ihrer Workstation ein Terminalfenster und rufen Sie
android_sdk/platform-tools
auf. -
Wählen Sie Gerät mit Kopplungscode koppeln aus, um Ihre IP-Adresse, Portnummer und den Kopplungscode zu ermitteln. Notieren Sie sich die auf dem Gerät angezeigte IP-Adresse, die Portnummer und den Kopplungscode.
-
Führen Sie auf dem Terminal Ihrer Workstation
adb pair ipaddr:port
aus. Verwenden Sie die oben genannte IP-Adresse und Portnummer. -
Gib auf Aufforderung den Kopplungscode wie unten dargestellt ein.
Probleme mit der WLAN-Verbindung beheben
Wenn Sie Probleme bei der drahtlosen Verbindung mit Ihrem Gerät haben, führen Sie die folgenden Schritte zur Fehlerbehebung aus.
Prüfen, ob Workstation und Gerät die Voraussetzungen erfüllen
Prüfen Sie, ob die Workstation und das Gerät die zu Anfang dieses Abschnitts aufgeführten Voraussetzungen erfüllen.
Auf andere bekannte Probleme prüfen
Im Folgenden findest du eine Liste mit aktuell bekannten Problemen beim Debugging über WLAN (mit ADB oder Android Studio) und wie du diese beheben kannst:
-
WLAN kann keine Verbindung herstellen: Sichere WLANs, z. B. in Unternehmens-WLANs, können P2p-Verbindungen blockieren und nicht zulassen, dass Sie eine Verbindung über WLAN herstellen. Versuchen Sie, eine Verbindung über ein Kabel oder ein anderes (nicht Unternehmens-)WLAN herzustellen. Eine drahtlose Verbindung mit
adb connect ip:port
über TCP/ip (nach einer ersten USB-Verbindung) ist eine weitere Option, falls die Verwendung eines externen Netzwerks möglich ist. -
adb
über WLAN wird manchmal automatisch deaktiviert: Das kann passieren, wenn das Gerät das WLAN wechselt oder die Verbindung zum Netzwerk trennt. Stellen Sie die Verbindung zum Netzwerk wieder her, um das Problem zu beheben. -
Gerät kann nach erfolgreichem Koppeln keine Verbindung herstellen:
adb
benötigt mDNS, um gekoppelte Geräte zu erkennen und automatisch eine Verbindung zu ihnen herzustellen. Wenn Ihre Netzwerk- oder Gerätekonfiguration mDNS nicht unterstützt oder deaktiviert ist, müssen Sie mitadb connect ip:port
manuell eine Verbindung zum Gerät herstellen.
Kabellose Verbindung mit einem Gerät nach der ersten USB-Verbindung herstellen (nur unter Android 10 und niedriger verfügbar)
Hinweis:Dieser Workflow gilt auch für Android 11 (und höher), allerdings erfordert er auch eine *anfängliche* Verbindung über einen physischen USB-Speicher.
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 zur Fehlerbehebung in einer Wear OS-App.
adb
kommuniziert in der Regel über USB mit dem Gerät, aber Sie können adb
auch über WLAN verwenden. Wenn du ein Gerät mit Android 10 (API-Level 29) oder niedriger verbinden möchtest, folge diesen ersten Schritten über USB:
-
Verbinden Sie Ihr Android-Gerät und Ihren
adb
-Hostcomputer mit einem gängigen WLAN. - Verbinden Sie das Gerät über ein USB-Kabel mit dem Hostcomputer.
-
Legen Sie das Zielgerät so fest, dass es auf eine TCP/IP-Verbindung an Port 5555 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 Telefon) > 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 der Hostcomputer mit dem Zielgerät verbunden ist:
$ adb devices List of devices attached device_ip_address:5555 device
Hinweis:Beachten Sie, dass nicht alle Zugangspunkte geeignet sind. Möglicherweise müssen Sie einen Zugangspunkt verwenden, dessen Firewall so konfiguriert ist, dass sie adb
unterstützt.
Dein Gerät ist jetzt mit adb
verbunden.
Wenn die adb
-Verbindung zu deinem Gerät unterbrochen wird:
- Der Host muss immer noch mit demselben WLAN wie Ihr Android-Gerät verbunden sein.
-
Stellen Sie die Verbindung wieder her, indem Sie den Schritt
adb connect
noch einmal ausführen. -
Wenn das nicht funktioniert, setzen Sie Ihren
adb
-Host zurück:adb kill-server
Fang dann noch einmal von vorn an.
Geräteabfrage
Bevor Sie adb
-Befehle verwenden, ist es hilfreich zu wissen, welche Geräteinstanzen mit dem adb
-Server verbunden sind. Generieren Sie mit dem Befehl devices
eine Liste der angehängten 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. Hier ein Beispiel für die Seriennummeremulator-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 dem Serveradb
verbunden. Dieser Status bedeutet nicht, dass das Android-System vollständig gestartet und betriebsbereit ist, da sich das Gerät mitadb
verbindet, während das System noch gestartet wird. Nach dem Hochfahren ist dies der normale Betriebsstatus eines Geräts.no device
: Es ist kein Gerät verbunden.
- Beschreibung: Wenn Sie die Option
-l
einbinden, gibt der Befehldevices
an, um welches Gerät es sich handelt. Diese Informationen sind hilfreich, wenn Sie mehrere Geräte verbunden haben, um sie voneinander zu unterscheiden.
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 an den Computer angeschlossen 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
enthält eine Befehlssequenz in extremer Groß- und Kleinschreibung, die dazu führt, dass ausgeführte Emulatoren nicht in der adb devices
-Ausgabe angezeigt werden, obwohl sie auf dem Desktop angezeigt werden. Dies geschieht, wenn alle der folgenden Bedingungen erfüllt sind:
- Der
adb
-Server wird nicht ausgeführt. - Sie verwenden den Befehl
emulator
mit der Option-port
oder-ports
mit einem Portwert mit ungerader Nummer zwischen 5554 und 5584. - Der ausgewählte Port mit ungerader Nummer ist nicht ausgelastet, sodass die Verbindung über die angegebene Portnummer hergestellt werden kann. Falls dieser belegt ist, wechselt der Emulator zu einem anderen Port, der die Anforderungen unter Schritt 2 erfüllt.
- Sie starten den
adb
-Server, nachdem Sie den Emulator gestartet haben.
Eine Möglichkeit, dies zu vermeiden, besteht darin, den Emulator seine eigenen Ports auswählen zu lassen und nicht mehr als 16 Emulatoren gleichzeitig auszuführen. Alternativ können Sie, wie in den folgenden Beispielen erläutert, den adb
-Server immer starten, bevor Sie den emulator
-Befehl verwenden.
Beispiel 1: In der folgenden Befehlssequenz startet der Befehl adb devices
den Server adb
, aber die Liste der Geräte wird nicht angezeigt.
Halten Sie den adb
-Server an und geben Sie die folgenden Befehle in der angegebenen Reihenfolge ein. Geben Sie als 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 Befehlssequenz zeigt adb devices
die Liste der Geräte an, da der adb
-Server zuerst gestartet wurde.
Wenn Sie den Emulator in der adb devices
-Ausgabe sehen möchten, beenden Sie den adb
-Server und starten Sie ihn dann neu, nachdem Sie den Befehl emulator
und bevor Sie den Befehl adb devices
verwendet haben. Gehen Sie dazu so vor:
$ 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 Startoptionen über die Befehlszeile.
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, verwenden Sie die Option
-s
mit denadb
-Befehlen, um die Seriennummer anzugeben.- Wenn Sie viele
adb
-Befehle ausgeben möchten, können Sie stattdessen die Umgebungsvariable$ANDROID_SERIAL
so festlegen, dass sie die Seriennummer enthält. - Wenn Sie sowohl
-s
als auch$ANDROID_SERIAL
verwenden, überschreibt-s
$ANDROID_SERIAL
.
- Wenn Sie viele
Im folgenden Beispiel wird die Liste der verbundenen Geräte abgerufen. Anschließend wird die Seriennummer eines der Geräte verwendet, um 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 ausführen, ohne ein Zielgerät anzugeben, obwohl mehrere Geräte verfügbar sind, zeigt adb
den Fehler „adb: mehr als ein Gerät/Emulator“ an.
Wenn Sie mehrere Geräte haben, von denen aber nur eines ein Emulator ist, verwenden Sie die Option -e
, um Befehle an den Emulator zu senden. Wenn mehrere Geräte, aber nur ein Hardwaregerät angehängt sind, verwenden Sie die Option -d
, um Befehle an das Hardwaregerät zu senden.
App installieren
Du kannst adb
verwenden, um ein APK mit dem Befehl install
auf einem Emulator oder verbundenen Gerät zu installieren:
adb install path_to_apk
Du musst die Option -t
mit dem Befehl install
verwenden, wenn du ein Test-APK installierst. Weitere Informationen findest du unter -t
.
Wenn du mehrere APKs installieren möchtest, verwende install-multiple
. Das ist nützlich, wenn du alle APKs für ein bestimmtes Gerät für deine App aus der Play Console herunterlädst und sie in einem Emulator oder auf einem physischen Gerät installieren möchtest.
Weitere Informationen zum Erstellen einer APK-Datei, die Sie auf einem Emulator/Geräteinstanz installieren können, finden Sie unter App erstellen und ausführen.
Hinweis: Wenn du Android Studio verwendest, musst du adb
nicht direkt verwenden, um deine App auf dem Emulator oder Gerät zu installieren. Das Packen und Installieren der App übernimmt Android Studio für dich.
Portweiterleitung einrichten
Verwenden Sie den Befehl forward
, um eine beliebige Portweiterleitung einzurichten, die Anfragen auf einem bestimmten Hostport an einen anderen Port auf einem Gerät weiterleitet.
Im folgenden Beispiel wird die Weiterleitung von Host-Port 6100 an Geräte-Port 7100 eingerichtet:
adb forward tcp:6100 tcp:7100
Im folgenden Beispiel wird die Weiterleitung von Hostport 6100 zu „local:logd“ eingerichtet:
adb forward tcp:6100 local:logd
Das kann nützlich sein, wenn Sie herausfinden möchten, was an einen bestimmten Port des Geräts gesendet wird. Alle empfangenen Daten werden in den System-Logging-Daemon geschrieben und in den Gerätelogs angezeigt.
Dateien von und auf ein Gerät kopieren
Verwenden Sie die Befehle pull
und push
, um Dateien auf ein und von einem Gerät zu kopieren. Im Gegensatz zum Befehl install
, mit dem eine APK-Datei nur 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 aus dem 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). Beispiele:
adb push myfile.txt /sdcard/myfile.txt
ADB-Server anhalten
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.
Anschließend können Sie den Server neu starten, indem Sie einen anderen adb
-Befehl ausführen.
ADB-Befehle ausführen
Führen Sie adb
-Befehle über eine Befehlszeile auf Ihrem Entwicklungscomputer oder aus einem Skript aus. Verwenden Sie dabei folgenden Code:
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 und/oder mehrere Geräte angehängt sind, müssen Sie die Option -d
, -e
oder -s
verwenden, um das Zielgerät anzugeben, an das der Befehl weitergeleitet 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
ausgeben oder eine interaktive Shell starten. Verwenden Sie den Befehl shell
so, um einen einzelnen Befehl auszugeben:
adb [-d |-e | -s serial_number] shell shell_command
Verwenden Sie den Befehl shell
so, um eine interaktive Shell auf einem Gerät zu starten:
adb [-d | -e | -s serial_number] shell
Drücken Sie Control+D
oder geben Sie exit
ein, um eine interaktive Shell zu beenden.
Android bietet die meisten der üblichen Unix-Befehlszeilentools. Verwenden Sie den folgenden Befehl, um eine Liste der verfügbaren Tools abzurufen:
adb shell ls /system/bin
Hilfe zu den meisten Befehlen erhalten Sie über das Argument --help
.
Viele Shell-Befehle werden von toybox bereitgestellt.
Allgemeine Hilfeinformationen zu allen Toybox-Befehlen finden Sie unter toybox --help
.
Ab Android Platform Tools 23 verarbeitet adb
Argumente auf dieselbe Weise wie der Befehl ssh(1)
. Durch diese Änderung wurden viele Probleme mit der Befehlseinschleusung behoben und es wird ermöglicht, Befehle sicher auszuführen, die Shell-Metazeichen wie adb install Let\'sGo.apk
enthalten. Das bedeutet, dass sich auch die Interpretation jedes Befehls, der Shell-Metazeichen enthält, geändert hat.
Beispielsweise ist adb shell setprop key 'value'
jetzt ein Fehler, da die einfachen Anführungszeichen ('
) von der lokalen Shell verschluckt werden und das Gerät adb shell setprop key value
erkennt. Damit der Befehl funktioniert, setzen Sie Anführungszeichen zweimal, wie bei ssh(1)
einmal für die lokale und einmal für die Remote-Shell. z. B. adb shell setprop key 'value'
.
Siehe auch das Logcat-Befehlszeilentool, das zum Überwachen des Systemlogs hilfreich ist.
Aktivitätsmanager für Anruf
Innerhalb einer adb
-Shell können Sie mit dem Aktivitätsmanager-Tool (am
) Befehle ausführen, um verschiedene Systemaktionen auszuführen, z. B. eine Aktivität zu starten, das Beenden eines Prozesses zu erzwingen, einen Intent zu senden, die Eigenschaften des Gerätebildschirms zu ändern usw.
In einer Shell lautet die Syntax am
:
am command
Sie können einen Aktivitätsmanager-Befehl auch direkt in adb
ausführen, ohne eine Remote-Shell eingeben zu müssen. Beispiele:
adb shell am start -a android.intent.action.VIEW
Befehl | Beschreibung |
---|---|
start [options] intent
|
Startet ein durch intent angegebenes Activity . Weitere Informationen finden Sie unter Spezifikation für Intent-Argumente. Es gibt folgende Optionen:
|
startservice [options] intent
|
Starten Sie den durch intent angegebenen Service . Weitere Informationen finden Sie unter Spezifikation für Intent-Argumente. Es gibt folgende Optionen:
|
force-stop package
|
Erzwingen Sie das Beenden aller mit „package “ verbundenen Elemente.
|
kill [options] package
|
Beenden Sie alle Prozesse, die mit package verknüpft sind. Dieser Befehl beendet nur Prozesse, die sicher beendet werden können und keine Auswirkungen auf die Nutzerfreundlichkeit haben.
Es gibt folgende Optionen:
|
kill-all
|
Beenden Sie alle Hintergrundprozesse. |
broadcast [options] intent
|
Veranlassen Sie einen Broadcast-Intent. Weitere Informationen finden Sie unter Spezifikation für Intent-Argumente. Es gibt folgende Optionen:
|
instrument [options] component
|
Starten Sie das Monitoring mit einer Instrumentation -Instanz.
In der Regel hat der Ziel-component das Format test_package/runner_class . Es gibt folgende Optionen:
|
profile start process file
|
Profiler auf process starten und die Ergebnisse in file schreiben.
|
profile stop process
|
Profiler auf process beenden.
|
dumpheap [options] process file
|
Verwerfen Sie den Heap von process und schreiben Sie in file . Es gibt folgende Optionen:
|
set-debug-app [options] package
|
App package auf „Debug“ festlegen. Es gibt folgende Optionen:
|
clear-debug-app
|
Löscht den vorherigen Paketsatz zur Fehlerbehebung mit set-debug-app .
|
monitor [options]
|
Monitoring auf Abstürze oder ANRs starten Es gibt folgende Optionen:
|
screen-compat {on | off} package
|
Damit wird der Bildschirmkompatibilitätsmodus von package gesteuert.
|
display-size [reset | widthxheight]
|
Anzeigegröße des Geräts überschreiben.
Dieser Befehl ist hilfreich, um Ihre App für verschiedene Bildschirmgrößen zu testen, indem eine kleine Bildschirmauflösung auf einem Gerät mit einem großen Bildschirm nachgeahmt wird und umgekehrt.
Beispiel: |
display-density dpi
|
Kompaktheitsgrad des Gerätebildschirms überschreiben.
Dieser Befehl ist hilfreich, um Ihre App für verschiedene Bildschirmdichten zu testen, indem Sie eine Bildschirmumgebung mit hoher Dichte mithilfe eines Bildschirms mit niedriger Dichte nachahmen und umgekehrt.
Beispiel: |
to-uri intent
|
Gibt die angegebene Intent-Spezifikation als URI aus. Weitere Informationen finden Sie unter Spezifikation für Intent-Argumente. |
to-intent-uri intent
|
Gibt die angegebene Intent-Spezifikation als intent: -URI aus. Weitere Informationen finden Sie unter Spezifikation für Intent-Argumente. |
Spezifikation für Intent-Argumente
Bei Aktivitätsmanager-Befehlen, die ein intent
-Argument verwenden, können Sie den Intent mit den folgenden Optionen angeben:
Paketmanager aufrufen (pm
)
Innerhalb einer adb
-Shell können Sie Befehle mit dem Paketmanager-Tool (pm
) ausgeben, um Aktionen und Abfragen für App-Pakete auszuführen, die auf dem Gerät installiert sind.
In einer Shell lautet die Syntax pm
:
pm command
Sie können einen Paketmanagerbefehl auch direkt über adb
ausführen, ohne eine Remote-Shell eingeben zu müssen. Beispiele:
adb shell pm uninstall com.example.MyApp
Befehl | Beschreibung |
---|---|
list packages [options] filter
|
Gibt alle Pakete aus, optional nur die Pakete, deren Paketname den Text in filter enthält. Optionen:
|
list permission-groups
|
Alle bekannten Berechtigungsgruppen ausgeben. |
list permissions [options] group
|
Geben Sie alle bekannten Berechtigungen aus, optional nur die in group . Optionen:
|
list instrumentation [options]
|
Listet alle Testpakete auf. Optionen:
|
list features
|
Alle Funktionen des Systems drucken. |
list libraries
|
Alle vom aktuellen Gerät unterstützten Bibliotheken drucken. |
list users
|
Alle Nutzer im System drucken. |
path package
|
Gib den Pfad zum APK der angegebenen package aus.
|
install [options] path
|
Installieren Sie 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
|
Aktiviert das angegebene Paket oder die angegebene Komponente (geschrieben als "package/class"). |
disable package_or_component
|
Deaktiviert das angegebene Paket oder die angegebene Komponente (geschrieben als "package/class"). |
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 im App-Manifest deklarierte Berechtigung sein. Auf Geräten mit Android 5.1 (API-Level 22) und niedriger muss es eine optionale Berechtigung sein, die von der App definiert wird. |
revoke package_name permission
|
Berechtigungen für eine App widerrufen. Auf Geräten mit Android 6.0 (API-Level 23) und höher kann die Berechtigung eine beliebige im App-Manifest deklarierte Berechtigung sein. Auf Geräten mit Android 5.1 (API-Level 22) und niedriger muss es eine optionale Berechtigung sein, die von der App definiert wird. |
set-install-location location
|
Ändern Sie den Standardspeicherort. Standortwerte:
Hinweis:Diese Option ist nur für die Fehlerbehebung gedacht. Dies kann dazu führen, dass Apps nicht mehr funktionieren und andere unerwünschtes Verhalten auftreten. |
get-install-location
|
Gibt den aktuellen Installationsort zurück Rückgabewerte:
|
set-permission-enforced permission [true | false]
|
Geben Sie an, ob die jeweilige Berechtigung erzwungen werden soll. |
trim-caches desired_free_space
|
Cache-Dateien kürzen, um den angegebenen freien Speicherplatz zu erreichen. |
create-user user_name
|
Erstellen Sie einen neuen Nutzer mit dem angegebenen user_name und geben Sie die neue Nutzer-ID des Nutzers aus.
|
remove-user user_id
|
Sie können den Nutzer mit dem angegebenen user_id entfernen. Dadurch werden alle mit diesem Nutzer verknüpften Daten gelöscht.
|
get-max-users
|
Drucken Sie die maximale Anzahl von Nutzern, die vom Gerät unterstützt werden. |
get-app-links [options] [package]
|
Gibt den Domainbestätigungsstatus für die angegebene package oder für alle Pakete aus, wenn keiner angegeben ist. Die Codes für Bundesstaaten sind wie folgt definiert:
Es gibt folgende Optionen:
|
reset-app-links [options] [package]
|
Domainbestätigungsstatus für das angegebene Paket oder für alle Pakete zurücksetzen, wenn keiner angegeben ist.
Es gibt folgende Optionen:
|
verify-app-links [--re-verify] [package]
|
Sendet eine Bestätigungsanfrage für den angegebenen package oder für alle Pakete, wenn keiner angegeben ist. Wird nur gesendet, wenn das Paket zuvor keine Antwort aufgezeichnet hat.
|
set-app-links [--package package] state domains
|
Legen Sie den Status einer Domain für ein Paket manuell fest. Die Domain muss vom Paket als AutoVerify deklariert werden, damit dies funktioniert. Dieser Befehl meldet keinen Fehler für Domains, die nicht angewendet werden konnten.
|
set-app-links-user-selection --user user_id [--package package]
enabled domains
|
Legen Sie den Status der Hostnutzerauswahl für ein Paket manuell fest. Die Domain muss vom Paket deklariert werden, damit dies funktioniert. Dieser Befehl meldet keinen Fehler für Domains, die nicht angewendet werden konnten.
|
set-app-links-user-selection --user user_id [--package package]
enabled domains
|
Legen Sie den Status der Hostnutzerauswahl für ein Paket manuell fest. Die Domain muss vom Paket deklariert werden, damit dies funktioniert. Dieser Befehl meldet keinen Fehler für Domains, die nicht angewendet werden konnten.
|
set-app-links-allowed --user user_id [--package package] allowed
|
Sie können die Einstellung für die Verarbeitung von automatisch bestätigten Links für ein Paket aktivieren oder deaktivieren.
|
get-app-link-owners --user user_id [--package package] domains
|
Drucken Sie die Eigentümer einer bestimmten Domain für einen bestimmten Nutzer in niedriger bis hoher Priorität aus.
|
Geräterichtlinienmanager anrufen (dpm
)
Damit Sie Ihre Apps zur Geräteverwaltung entwickeln und testen können, geben Sie Befehle an das Geräterichtlinien-Manager-Tool (dpm
) aus. Mit dem Tool können Sie die aktive Admin-App steuern oder die Statusdaten einer Richtlinie auf dem Gerät ändern.
In einer Shell lautet die dpm
-Syntax:
dpm command
Sie können einen Geräterichtlinienmanager-Befehl auch direkt über adb
ausführen, ohne eine Remote-Shell eingeben zu müssen:
adb shell dpm command
Befehl | Beschreibung |
---|---|
set-active-admin [options] component
|
Legt component als aktiven Administrator fest.
Es gibt folgende Optionen:
|
set-profile-owner [options] component
|
Lege component als aktiven Administrator und das zugehörige Paket als Profilinhaber für einen vorhandenen Nutzer fest.
Es gibt folgende Optionen:
|
set-device-owner [options] component
|
Lege component als aktiven Administrator und das zugehörige Paket als Geräteinhaber fest.
Es gibt folgende Optionen:
|
remove-active-admin [options] component
|
Deaktivieren Sie einen aktiven Administrator. Die App muss im Manifest android:testOnly deklarieren. Mit diesem Befehl werden auch Geräte- und Profilinhaber entfernt.
Es gibt folgende Optionen:
|
clear-freeze-period-record
|
Löscht den Datensatz mit zuvor festgelegten Fixierungszeiträumen für System-OTA-Updates auf dem Gerät. So lassen sich bei der Entwicklung von Apps, für die Sperrzeiträume festgelegt werden, Planungseinschränkungen für das Gerät vermeiden. Weitere Informationen findest du unter Systemupdates verwalten.
Diese Option wird auf Geräten mit Android 9.0 (API-Level 28) und höher unterstützt. |
force-network-logs
|
Erzwingen Sie, dass das System vorhandene Netzwerkprotokolle für den Abruf durch einen DPC bereit macht. Wenn Verbindungs- oder DNS-Logs verfügbar sind, empfängt der DPC den onNetworkLogsAvailable() -Callback. Siehe Logging für Netzwerkaktivitäten.
Für diesen Befehl gilt eine Ratenbegrenzung. Diese Option wird auf Geräten mit Android 9.0 (API-Level 28) und höher unterstützt. |
force-security-logs
|
Erzwingen Sie, dass das System vorhandene Sicherheitsprotokolle dem DPC zur Verfügung stellt. Sind Logs verfügbar, empfängt der DPC den onSecurityLogsAvailable() -Callback. Siehe Unternehmensaktivitäten in Logs protokollieren.
Für diesen Befehl gilt eine Ratenbegrenzung. Diese Option 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 der Geräteanzeige.
In einer Shell lautet die Syntax screencap
:
screencap filename
Geben Sie Folgendes ein, um screencap
über die Befehlszeile zu verwenden:
adb shell screencap /sdcard/screen.png
Hier ist ein Beispiel für eine Screenshot-Sitzung, in der die adb
-Shell zum Erfassen des Screenshots und der pull
-Befehl zum Herunterladen der Datei vom Gerät verwendet wird:
$ adb shell shell@ $ screencap /sdcard/screen.png shell@ $ exit $ adb pull /sdcard/screen.png
Video aufnehmen
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. Du kannst 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
Stoppen Sie die Bildschirmaufzeichnung durch Drücken von Strg+C. Andernfalls endet die Aufzeichnung automatisch nach drei Minuten oder dem in --time-limit
festgelegten Zeitlimit.
Um mit der Aufzeichnung des Gerätebildschirms zu beginnen, führen Sie den Befehl screenrecord
aus, um das Video aufzunehmen. Führen Sie dann den Befehl pull
aus, um das Video vom Gerät auf den Hostcomputer herunterzuladen. Hier ist ein Beispiel für eine Aufzeichnungssitzung:
$ adb shell shell@ $ screenrecord --verbose /sdcard/demo.mp4 (press Control + C to stop) shell@ $ exit $ adb pull /sdcard/demo.mp4
Das Dienstprogramm screenrecord
kann jede unterstützte Auflösung und Bitrate, die Sie anfordern, unter Beibehaltung des Seitenverhältnisses des Gerätebildschirms aufnehmen. Das Dienstprogramm zeichnet standardmäßig die native Bildschirmauflösung und -ausrichtung auf. Die maximale Dauer beträgt drei Minuten.
Einschränkungen des Dienstprogramms screenrecord
:
- Mit der Videodatei wird kein Audio aufgezeichnet.
- Die Videoaufnahme ist für Geräte mit Wear OS nicht verfügbar.
- Einige Geräte können möglicherweise nicht mit der nativen Bildschirmauflösung aufnehmen. Wenn Probleme bei der Bildschirmaufzeichnung auftreten, versuchen Sie es mit einer niedrigeren Bildschirmauflösung.
- Das Drehen des Bildschirms während der Aufnahme wird nicht unterstützt. Wenn sich der Bildschirm während der Aufzeichnung dreht, ist ein Teil des Bildschirms in der Aufnahme abgeschnitten.
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 (falls unterstützt), andernfalls 1280 × 720. Die besten Ergebnisse erzielst du mit einer Größe, die vom Advanced Video Coding-Encoder (AVC) deines Geräts unterstützt wird. |
--bit-rate rate |
Hier wird die Video-Bitrate für das Video in Megabit pro Sekunde festgelegt. Der Standardwert ist 20 Mbit/s.
Durch Erhöhung der Bitrate können Sie die Videoqualität verbessern. Dies führt jedoch zu größeren Filmdateien. Im folgenden Beispiel wird die Bitrate für die Aufnahme auf 6 Mbit/s festgelegt:
screenrecord --bit-rate 6000000 /sdcard/demo.mp4 |
--time-limit time |
Legen Sie die maximale Aufnahmezeit in Sekunden fest. Der Standard- und Höchstwert beträgt 180 (3 Minuten). |
--rotate |
Drehe die Ausgabe um 90 Grad. Hierbei handelt es sich um eine experimentelle Funktion. |
--verbose |
Protokollinformationen auf dem Befehlszeilenbildschirm anzeigen Wenn Sie diese Option nicht festlegen, zeigt das Dienstprogramm während der Ausführung keine Informationen an. |
ART-Profile für Apps lesen
Ab Android 7.0 (API-Ebene 24) erfasst Android Runtime (ART) Ausführungsprofile für installierte Anwendungen, die zur Optimierung der Anwendungsleistung verwendet werden. Sehen Sie sich die erfassten Profile an, um herauszufinden, welche Methoden häufig ausgeführt werden und welche Klassen beim Start der Anwendung verwendet werden.
Hinweis:Der Dateiname des Ausführungsprofils kann nur abgerufen werden, wenn Sie Root-Zugriff auf das Dateisystem haben, beispielsweise in einem Emulator.
Verwenden Sie den folgenden Befehl, um ein Textformat der Profilinformationen zu erstellen:
adb shell cmd package dump-profiles package
Verwenden Sie folgenden Befehl, um die erstellte Datei abzurufen:
adb pull /data/misc/profman/package.prof.txt
Testgeräte zurücksetzen
Wenn du deine App auf mehreren Testgeräten testest, kann es sinnvoll sein, das Gerät zwischen den Tests zurückzusetzen, z. B. um Nutzerdaten zu entfernen und die Testumgebung zurückzusetzen. Sie können ein Testgerät mit Android 10 (API-Level 29) oder höher auf die Werkseinstellungen zurücksetzen. Dazu verwenden Sie den Shell-Befehl testharness
adb
:
adb shell cmd testharness enable
Beim Wiederherstellen des Geräts mit testharness
sichert das Gerät automatisch den RSA-Schlüssel, der das Debugging über die aktuelle Workstation an einem nichtflüchtigen Speicherort ermöglicht. Das heißt, die Workstation kann nach dem Zurücksetzen des Geräts weiterhin Fehler beheben und adb
-Befehle an das Gerät ausgeben, ohne manuell einen neuen Schlüssel zu registrieren.
Um das Testen deiner App einfacher und sicherer zu machen, werden durch die Verwendung des testharness
zum Wiederherstellen eines Geräts auch die folgenden Geräteeinstellungen geändert:
- Auf dem Gerät werden bestimmte Systemeinstellungen eingerichtet, sodass keine Assistenten für die Ersteinrichtung des Geräts angezeigt werden. Das heißt, das Gerät wechselt in einen Status, ab 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:
- Dadurch werden vorinstallierte Sicherheits-Apps deaktiviert.
Wenn Ihre Anwendung die Standardeinstellungen des Befehls testharness
erkennen und sich daran anpassen muss, verwenden Sie
ActivityManager.isRunningInUserTestHarness()
.
Squarelite
sqlite3
startet das sqlite
-Befehlszeilentool zur Prüfung von SQLite-Datenbanken.
Sie enthält Befehle wie .dump
, um den Inhalt einer Tabelle auszugeben, und .schema
, um die Anweisung SQL CREATE
für eine vorhandene Tabelle auszugeben.
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: Der Zugriff auf eine SQLite-Datenbank ist nur möglich, wenn Sie Root-Zugriff auf das Dateisystem haben, z. B. bei einem Emulator.
Weitere Informationen finden Sie in der Dokumentation zur sqlite3
-Befehlszeile.
ADB-USB-Backends
Der ADB-Server kann über zwei Back-Ends mit dem USB-Stack interagieren. Sie kann entweder das native Back-End des Betriebssystems (Windows, Linux oder macOS) oder das libusb
-Back-End verwenden.
Einige Funktionen wie attach
, detach
und USB-Geschwindigkeitserkennung sind nur bei Verwendung des libusb
-Back-Ends verfügbar.
Mithilfe der Umgebungsvariable ADB_LIBUSB
können Sie ein Back-End auswählen.
Ist dies nicht festgelegt, verwendet ADB das Standard-Back-End. Das Standardverhalten variiert je nach Betriebssystem. Ab API-Level 34 wird standardmäßig das native Back-End verwendet. Wenn ADB_LIBUSB
festgelegt ist, wird bestimmt, ob das native Back-End oder libusb
verwendet wird. Weitere Informationen zu ADB-Umgebungsvariablen finden Sie auf der Seite der ADB-Anleitung.
ADB-mDNS-Back-Ends
ADB kann das Multicast-DNS-Protokoll verwenden, um den Server und die Geräte automatisch zu verbinden. Der ADB-Server wird mit zwei Backends ausgeliefert, Bonjour (mdnsAntworter von Apple) und Openscreen.
Das Bonjour-Back-End benötigt einen Daemon, der auf dem Hostcomputer ausgeführt wird.
Unter macOS wird der integrierte Daemon von Apple immer ausgeführt. Unter Windows und Linux muss der Nutzer jedoch prüfen, ob der mdnsd
-Daemon aktiv ist.
Wenn der Befehl adb mdns check
einen Fehler zurückgibt, verwendet ADB wahrscheinlich das Bonjour-Back-End, aber es wird kein Bonjour-Daemon ausgeführt.
Das Openscreen-Back-End benötigt keinen Daemon, der auf der Maschine ausgeführt wird. Die Unterstützung für das Openscreen-Back-End unter macOS beginnt ab ADB v35. Windows und Linux werden ab ADB v34 unterstützt.
Standardmäßig verwendet ADB das Bonjour-Back-End. Dieses Verhalten kann mit der Umgebungsvariable ADB_MDNS_OPENSCREEN
geändert werden, die auf 1
oder 0
festgelegt ist. Weitere Informationen finden Sie auf der Seite des ADB-Handbuchs.