Android Debug Bridge (ADB)

Android Debug Bridge (adb) ist ein vielseitiges Befehlszeilentool, das die Kommunikation mit einem Gerät ermöglicht. Der Befehl adb erleichtert verschiedene Geräteaktionen wie die Installation von Apps und die Fehlerbehebung. 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 über ein Befehlszeilenterminal aufrufen, indem Sie den Befehl adb ausführen.
  • Ein Daemon (adbd), der Befehle auf einem Gerät ausführt. Der Daemon wird als Hintergrundprozess auf jedem Gerät 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, der es unter android_sdk/platform-tools/ installiert. Wenn du das eigenständige Android SDK Platform Tools-Paket nutzen möchtest, lade es hier herunter.

Informationen zum Verbinden eines Geräts zur Verwendung über adb, einschließlich der Verwendung des Verbindungsassistenten zur Behebung häufiger Probleme, findest du unter Apps auf einem Hardwaregerät ausführen.

Funktionsweise von ADB

Wenn Sie einen adb-Client starten, prüft dieser zuerst, ob bereits ein adb-Serverprozess ausgeführt wird. Ist dies nicht der Fall, wird der Serverprozess gestartet. Beim Start des Servers stellt er eine Verbindung zum lokalen TCP-Port 5037 her und wartet auf Befehle, die von adb-Clients gesendet werden.

Hinweis: Alle adb-Clients verwenden für die Kommunikation mit dem adb-Server Port 5037.

Der Server richtet dann Verbindungen zu allen ausgeführten Geräten ein. Er findet Emulatoren, indem er ungerade nummerierte Ports im Bereich von 5.555 bis 5.585 scannt. Dies ist der Bereich, der von den ersten 16 Emulatoren verwendet wird. Wenn der Server einen adb-Daemon (ADBD) findet, richtet er eine Verbindung zu diesem Port ein.

Jeder Emulator verwendet ein Paar sequenzieller Ports – ein Port mit gerader Nummer für Konsolenverbindungen und ein Port mit einer geraden Nummer für adb-Verbindungen. Beispiel:

Emulator 1, Console: 5554
Emulator 1, adb: 5555
Emulator 2, Console: 5556
Emulator 2, adb: 5557
usw.

Wie gezeigt, ist der Emulator, der mit adb an Port 5555 verbunden ist, derselbe wie der Emulator, 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 über jeden Client oder ein Script steuern.

ADB-Debugging auf Ihrem Gerät aktivieren

Wenn Sie ADB mit einem über USB angeschlossenen Gerät verwenden möchten, müssen Sie USB-Debugging in den Gerätesystemeinstellungen unter Entwickleroptionen aktivieren. Auf Geräten mit Android 4.2 (API-Level 17) und höher ist der Bildschirm Entwickleroptionen standardmäßig ausgeblendet. Aktiviere die Entwickleroptionen, um sie sichtbar zu machen.

Du kannst dein Gerät jetzt über 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 die Verbindung besteht, wird der Gerätename als „Gerät“ angezeigt.

Hinweis:Wenn du ein Gerät mit Android 4.2.2 (API-Ebene 17) oder höher verbindest, wird ein Dialogfeld angezeigt, in dem du gefragt wirst, ob ein RSA-Schlüssel akzeptiert werden soll, der die Fehlerbehebung über diesen Computer ermöglicht. Dieser Sicherheitsmechanismus schützt Nutzergeräte, da USB-Debugging und andere ADB-Befehle erst ausgeführt werden können, wenn Sie das Gerät entsperren und das Dialogfeld bestätigen.

Weitere Informationen zum Verbinden eines Geräts über USB findest du 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 in der Anleitung zum Debuggen einer Wear OS-App.

Android 11 (API-Level 30) und höher unterstützen die kabellose Bereitstellung und Fehlerbehebung Ihrer App über Ihre Workstation mithilfe von Android Debug Bridge (ADB). So können Sie beispielsweise Ihre Debug-fähige Anwendung auf mehreren Remote-Geräten bereitstellen, ohne Ihr Gerät physisch per USB verbinden zu müssen. So müssen Sie sich nicht um häufige USB-Verbindungsprobleme wie die Treiberinstallation kümmern.

Bevor Sie mit dem Debugging über WLAN beginnen, sollten Sie Folgendes tun:

  • Achten Sie darauf, dass die Workstation und das Gerät mit demselben WLAN verbunden sind.

  • Auf deinem Gerät muss Android 11 (API-Level 30) oder höher (Smartphone) oder Android 13 (API-Level 33) oder höher für TV und Wear OS ausgeführt werden. Weitere Informationen findest du 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.

  • Aktualisieren Sie auf Ihrer Workstation die SDK Platform Tools auf die neueste Version.

Wenn Sie „Debugging über WLAN“ verwenden möchten, müssen Sie Ihr Gerät über einen QR-Code oder einen Kopplungscode mit Ihrer Workstation koppeln. Die Workstation und das Gerät müssen mit demselben WLAN verbunden sein. So kannst du eine Verbindung zu deinem Gerät herstellen:

  1. Aktiviere die Entwickleroptionen auf deinem Gerät.

  2. Öffne Android Studio und wähle im Menü „Ausführungskonfigurationen“ die Option Geräte über WLAN koppeln aus.

    Drop-down-Menü für Ausführungskonfigurationen
    Abbildung 1: Menü „Run Configurations“ (Konfigurationen ausführen) aus.

    Das Fenster Geräte über WLAN koppeln öffnet sich, wie in Abbildung 2 dargestellt.

    Screenshot des Pop-up-Fensters zum Koppeln von Geräten über WLAN
    Abbildung 2: Pop-up-Fenster zum Koppeln von Geräten mithilfe eines QR-Codes oder eines Kopplungscodes.
  3. Tippen Sie auf Ihrem Gerät auf Debugging über WLAN und koppeln Sie das Gerät:

    Screenshot eines Pixel Smartphones mit der Einstellung „Wireless Debugging Systems“.
    Abbildung 3: Screenshot der Einstellung Debugging über WLAN auf einem Google Pixel
    1. Um dein Gerät mit einem QR-Code zu koppeln, wähle Gerät mit QR-Code koppeln aus und scanne den QR-Code, den du aus dem Pop-up Geräte über WLAN koppeln (siehe Abbildung 2) abrufen kannst.

    2. Um dein Gerät mit einem Kopplungscode zu koppeln, wähle im Pop-up-Fenster Geräte über WLAN koppeln die Option Gerät mit Kopplungscode koppeln aus. Wähle auf deinem Gerät Mit Kopplungscode koppeln aus und notiere den sechsstelligen Code. Wenn dein Gerät im Fenster Geräte über WLAN koppeln angezeigt wird, kannst du Koppeln auswählen und den auf dem Gerät angezeigten sechsstelligen Code eingeben.

      Screenshot des Beispiel-PIN-Code-Eintrags
      Abbildung 4: Beispiel für die Eingabe eines sechsstelligen Codes.
  4. Nachdem Ihr Gerät gekoppelt ist, können Sie versuchen, Ihre App auf dem Gerät bereitzustellen.

    Wenn du ein anderes Gerät koppeln oder das aktuelle Gerät von deiner Workstation entfernen möchtest, rufe auf deinem Gerät Debugging über WLAN auf. Tippen Sie unter Gekoppelte Geräte auf den Namen Ihrer Workstation und wählen Sie Entfernen aus.

  5. Wenn du das Debugging über WLAN schnell aktivieren und deaktivieren möchtest, kannst du die Kacheln für Entwickler von Schnelleinstellungen für das Debugging für WLAN verwenden. Diese findest du unter Entwickleroptionen > Kacheln für Entwickler mit Schnelleinstellungen.

    Screenshot der Kacheln für Entwickler von Schnelleinstellungen auf einem Google Pixel
    Abbildung 5: Über die Einstellung Kacheln für Entwickler mit Schnelleinstellungen kannst du „Debugging über WLAN“ schnell aktivieren oder deaktivieren.

WLAN-Verbindung über die Befehlszeile

Alternativ können Sie die folgenden Schritte ausführen, um eine Verbindung zu Ihrem Gerät über die Befehlszeile ohne Android Studio herzustellen:

  1. Aktivieren Sie die Entwickleroptionen wie zuvor beschrieben auf Ihrem Gerät.

  2. Aktivieren Sie wie zuvor beschrieben Debugging über WLAN auf Ihrem Gerät.

  3. Öffnen Sie auf Ihrer Workstation ein Terminalfenster und rufen Sie android_sdk/platform-tools auf.

  4. Wähle Gerät mit Kopplungscode koppeln aus, um deine IP-Adresse, Portnummer und den Kopplungscode zu ermitteln. Notieren Sie sich die auf dem Gerät angezeigte IP-Adresse, Portnummer und Kopplungscode.

  5. Führen Sie auf dem Terminal Ihrer Workstation adb pair ipaddr:port aus. Verwenden Sie die oben angegebene IP-Adresse und Portnummer.

  6. Wenn Sie dazu aufgefordert werden, geben Sie wie unten gezeigt den Kopplungscode ein.

    Screenshot der Kopplung über die Befehlszeile
    Abbildung 6: Eine Meldung zeigt an, dass dein Gerät erfolgreich gekoppelt wurde.

Probleme mit der drahtlosen Verbindung beheben

Wenn du Probleme beim Herstellen einer drahtlosen Verbindung zu deinem Gerät hast, probiere die folgenden Schritte zur Fehlerbehebung aus.

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 erfüllen, die zu Anfang dieses Abschnitts aufgeführt sind.

Nach weiteren bekannten Problemen suchen

Im Folgenden finden Sie eine Liste der aktuell bekannten Probleme beim Debugging über WLAN (mit ADB oder Android Studio) und wie Sie diese beheben können:

  • WLAN-Verbindung wird nicht hergestellt: Sichere WLANs, z. B. Unternehmens-WLANs, blockieren P2P-Verbindungen möglicherweise und ermöglichen keine Verbindung über WLAN. Versuchen Sie, eine Verbindung über ein Kabel oder ein anderes WLAN (kein Unternehmensnetzwerk) herzustellen. Drahtlose Verbindungen mit adb connect ip:port über tcp/ip (nach einer ersten USB-Verbindung) sind eine weitere Option, falls ein anderes Netzwerk als Unternehmensnetzwerk infrage kommt.

  • adb über WLAN wird manchmal automatisch deaktiviert: Dies kann passieren, wenn das Gerät entweder das WLAN wechselt oder die Verbindung zum Netzwerk trennt. Stellen Sie die Verbindung zum Netzwerk wieder her, um das Problem zu beheben.

  • Gerät wird nach erfolgreicher Kopplung nicht verbunden: adb benötigt mDNS, um gekoppelte Geräte zu erkennen und automatisch eine Verbindung herzustellen. Wenn mDNS von Ihrer Netzwerk- oder Gerätekonfiguration nicht unterstützt wird oder diese Funktion deaktiviert ist, müssen Sie mit adb connect ip:port manuell eine Verbindung zum Gerät herstellen.

Drahtlose Verbindung mit einem Gerät nach der ersten USB-Verbindung (nur unter Android 10 und niedriger verfügbar)

Hinweis:Dieser Workflow gilt auch für Android 11 (und höher). Es ist jedoch auch eine *Erstverbindung* über physischen USB-Speicher erforderlich.

Hinweis:Die folgende Anleitung gilt nicht für Wear-Geräte mit Android 10 (API-Level 29) oder niedriger. Weitere Informationen findest du in der Anleitung zum Debuggen einer Wear OS-App.

adb kommuniziert mit dem Gerät normalerweise über USB, du kannst adb aber auch über WLAN verwenden. Wenn du ein Gerät mit Android 10 (API-Level 29) oder niedriger verbinden möchtest, führe die folgenden ersten Schritte über USB aus:

  1. Verbinden Sie Ihr Android-Gerät und Ihren adb-Hostcomputer mit einem gemeinsamen WLAN.
  2. Hinweis:Nicht alle Zugangspunkte sind geeignet. Möglicherweise müssen Sie einen Zugangspunkt verwenden, dessen Firewall richtig konfiguriert ist, um adb zu unterstützen.

  3. Verbinden Sie das Gerät über ein USB-Kabel mit dem Hostcomputer.
  4. Legen Sie das Zielgerät so fest, dass es auf Port 5555 auf eine TCP/IP-Verbindung wartet:
    adb tcpip 5555
    
  5. Ziehen Sie das USB-Kabel vom Zielgerät ab.
  6. 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.
  7. Stellen Sie über die IP-Adresse eine Verbindung zum Gerät her:
    adb connect device_ip_address:5555
    
  8. Prüfen Sie, ob der Hostcomputer mit dem Zielgerät verbunden ist:
    $ adb devices
    List of devices attached
    device_ip_address:5555 device
    

Dein Gerät ist jetzt mit adb verbunden.

Wenn die adb-Verbindung zu deinem Gerät unterbrochen wird:

  • Achten Sie darauf, dass der Host immer noch mit demselben WLAN wie Ihr Android-Gerät verbunden ist.
  • Stellen Sie die Verbindung wieder her, indem Sie den Schritt adb connect noch einmal ausführen.
  • Sollte das nicht funktionieren, setzen Sie den adb-Host zurück:
    adb kill-server
    

    Fangen Sie dann noch einmal von vorn an.

Geräteabfrage

Bevor Sie adb-Befehle ausführen, sollten Sie 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 eine Seriennummer: emulator-5554
  • Status:Der Verbindungsstatus des Geräts kann einer der folgenden sein:
    • offline: Das Gerät ist nicht mit adb verbunden oder reagiert nicht.
    • device: Das Gerät ist mit dem adb-Server verbunden. Dieser Status bedeutet nicht, dass das Android-System vollständig gestartet und betriebsbereit ist, da das Gerät eine Verbindung zu adb herstellt, während das System noch gestartet wird. 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 hinzufügen, gibt der Befehl devices an, um welches Gerät es sich handelt. Diese Informationen sind hilfreich, wenn mehrere Geräte verbunden sind, um sie auseinanderzuhalten.

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 Groß- und Kleinschreibung, die dazu führt, dass ausgeführte Emulatoren nicht in der adb devices-Ausgabe angezeigt werden, obwohl die Emulatoren auf dem Desktop sichtbar sind. 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 ungeraden Portwert zwischen 5.554 und 5.584.
  • Der von Ihnen ausgewählte Port mit einer ungeraden Nummer ist nicht ausgelastet, sodass die Portverbindung über die angegebene Portnummer hergestellt werden kann. Wenn er belegt ist, wechselt der Emulator zu einem anderen Port, der die Anforderungen in Punkt 2 erfüllt.
  • Sie starten den adb-Server nach dem Start des Emulators.

Eine Möglichkeit, dies zu vermeiden, besteht darin, dem Emulator seine eigenen Ports auswählen zu lassen und nicht mehr als 16 Emulatoren gleichzeitig auszuführen. Eine andere Möglichkeit besteht darin, immer den adb-Server zu starten, bevor Sie den emulator-Befehl verwenden, wie in den folgenden Beispielen erläutert.

Beispiel 1: Bei der folgenden Befehlssequenz startet der Befehl adb devices den Server adb, aber die Liste der Geräte wird nicht angezeigt.

Beenden Sie den adb-Server 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 aufzurufen. 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 Server adb zuerst gestartet wurde.

Damit der Emulator in der adb devices-Ausgabe angezeigt wird, beenden Sie den adb-Server und starten ihn dann noch einmal, nachdem Sie den Befehl emulator und vor Verwendung des Befehls adb devices ausgeführt 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 Startoptionen der Befehlszeile.

Befehle an ein bestimmtes Gerät senden

Werden mehrere Geräte ausgeführt, müssen Sie das Zielgerät angeben, wenn Sie den Befehl adb ausführen. So geben Sie das Ziel an:

  1. Verwenden Sie den Befehl devices, um die Seriennummer des Ziels abzurufen.
  2. Sobald du die Seriennummer hast, verwende die Option -s mit den adb-Befehlen, um sie anzugeben.
    1. Wenn Sie viele adb-Befehle ausführen möchten, können Sie die Umgebungsvariable $ANDROID_SERIAL so festlegen, dass sie stattdessen die Seriennummer enthält.
    2. Wenn Sie sowohl -s als auch $ANDROID_SERIAL verwenden, überschreibt -s $ANDROID_SERIAL.

Im folgenden Beispiel wird die Liste der angehängten Geräte abgerufen. Dann 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 ohne Angabe eines Zielgeräts ausführen und mehrere Geräte verfügbar sind, zeigt adb den Fehler „adb: more than one device/Emulator“ an.

Wenn mehrere Geräte verfügbar sind, aber nur eines ein Emulator ist, verwenden Sie die Option -e, um Befehle an den Emulator zu senden. Wenn mehrere Geräte verbunden sind, aber nur ein Hardwaregerät angeschlossen ist, 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 einem 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.

Verwende install-multiple, um mehrere APKs zu installieren. Das ist nützlich, wenn du alle APKs für ein bestimmtes Gerät für deine App über die Play Console herunterlädst und sie auf einem Emulator oder einem physischen Gerät installieren möchtest.

Weitere Informationen zum Erstellen einer APK-Datei, die Sie auf einem Emulator/einer 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 auf dem Gerät zu installieren. Stattdessen übernimmt Android Studio das Packen und Installieren der App.

Portweiterleitung einrichten

Verwenden Sie den Befehl forward, um eine beliebige Portweiterleitung einzurichten, die Anfragen an einem bestimmten Hostport an einen anderen Port auf einem Gerät weiterleitet. Im folgenden Beispiel wird die Weiterleitung vom Hostport 6100 zum Geräteport 7100 eingerichtet:

adb forward tcp:6100 tcp:7100

Im folgenden Beispiel wird die Weiterleitung vom Hostport 6100 an „local:logd“ eingerichtet:

adb forward tcp:6100 local:logd

Dies kann nützlich sein, um festzustellen, was an einen bestimmten Port auf dem Gerät 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 zugehörige Unterverzeichnisse von dem Gerät:

adb pull remote local

So kopieren Sie eine Datei oder ein Verzeichnis und deren Unterverzeichnisse auf das Gerät:

adb push local remote

Ersetzen Sie local und remote durch die Pfade zu den Zieldateien/-verzeichnissen auf Ihrem Entwicklungscomputer (lokal) und auf dem Gerät (Remote). Beispiel:

adb push myfile.txt /sdcard/myfile.txt

ADB-Server anhalten

In einigen Fällen müssen Sie möglicherweise den adb-Serverprozess beenden und ihn dann neu starten, um das Problem zu beheben. Das könnte 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 mit einem beliebigen anderen adb-Befehl neu starten.

ADB-Befehle ausgeben

Führen Sie mit folgendem Befehl adb-Befehle über eine Befehlszeile auf Ihrem Entwicklungscomputer oder über ein Skript 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 verbunden sind, müssen Sie mit der Option -d, -e oder -s das Zielgerät angeben, 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 ausgeben

Mit dem Befehl shell können Sie Gerätebefehle über adb ausgeben oder eine interaktive Shell starten. Um einen einzelnen Befehl auszugeben, verwenden Sie den shell-Befehl so:

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

Wenn Sie eine interaktive Shell auf einem Gerät starten möchten, verwenden Sie den Befehl shell so:

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. Eine Liste der verfügbaren Tools erhalten Sie mit dem folgenden Befehl:

adb shell ls /system/bin

Hilfe ist für die meisten Befehle über das Argument --help verfügbar. Viele Shell-Befehle werden von toybox bereitgestellt. Allgemeine Hilfe zu allen Toybox-Befehlen ist über toybox --help verfügbar.

Ab Android Platform Tools 23 verarbeitet adb Argumente genauso wie der Befehl ssh(1). Durch diese Änderung wurden viele Probleme mit der Befehlseinschleusung behoben. Außerdem können 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, die Shell-Metazeichen enthalten, 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 zweimal Anführungszeichen, einmal für die lokale Shell und einmal für die Remote-Shell, wie Sie es bei ssh(1) tun. Beispiel: adb shell setprop key 'value' .

Weitere Informationen finden Sie unter Logcat-Befehlszeilentool, das zum Überwachen des Systemlogs nützlich ist.

Anrufaktivitäts-Manager

Innerhalb einer adb-Shell können Sie Befehle mit dem Aktivitätsmanager-Tool (am) 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 Bildschirmeigenschaften des Geräts zu ändern und vieles mehr.

In einer Shell lautet die am-Syntax so:

am command

Sie können einen Aktivitätsmanager-Befehl auch direkt über adb ausführen, ohne eine Remote-Shell eingeben zu müssen. Beispiel:

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

Tabelle 1 Verfügbare Aktivitätsmanager-Befehle

Befehl Beschreibung
start [options] intent Startet einen durch intent angegebenen Activity.

Weitere Informationen finden Sie unter Spezifikation für Intent-Argumente.

Es gibt folgende Optionen:

  • -D: Debugging aktivieren
  • -W: Warten, bis der Start abgeschlossen ist.
  • --start-profiler file: Profiler starten und Ergebnisse an file senden.
  • -P file: Wie --start-profiler, aber die Profilerstellung wird beendet, wenn die Anwendung inaktiv wird.
  • -R count: Wiederholen Sie den Aktivitätsstart count-mal. Vor jeder Wiederholung wird die wichtigste Aktivität beendet.
  • -S: Erzwinge das Beenden der Ziel-App, bevor die Aktivität gestartet wird.
  • --opengl-trace: Aktiviert das Tracing von OpenGL-Funktionen.
  • --user user_id | current: Geben Sie an, als welcher Nutzer ausgeführt werden soll. Wenn nicht angegeben, wird er als aktueller Nutzer ausgeführt.
startservice [options] intent Starten Sie den durch intent angegebenen Service.

Weitere Informationen finden Sie unter Spezifikation für Intent-Argumente.

Es gibt folgende Optionen:

  • --user user_id | current: Geben Sie an, als welcher Nutzer ausgeführt werden soll. Wenn nicht angegeben, wird er als aktueller Nutzer ausgeführt.
force-stop package Erzwingen Sie das Beenden aller mit package verknüpften Elemente.
kill [options] package Beenden Sie alle mit package verknüpften Prozesse. Mit diesem Befehl werden nur Prozesse beendet, die sicher beendet werden können und keinen Einfluss auf die Nutzerfreundlichkeit haben.

Es gibt folgende Optionen:

  • --user user_id | all | current: Geben Sie an, welche Prozesse des Nutzers beendet werden sollen. Wenn keine Angabe erfolgt, beenden Sie die Prozesse aller Nutzer.
kill-all Beenden Sie alle Hintergrundprozesse.
broadcast [options] intent Sende einen Broadcast-Intent.

Weitere Informationen finden Sie unter Spezifikation für Intent-Argumente.

Es gibt folgende Optionen:

  • [--user user_id | all | current]: Geben Sie an, an welchen Nutzer die Nachricht gesendet werden soll. Wenn nicht angegeben, an alle Nutzer senden.
instrument [options] component Starten Sie das Monitoring mit einer Instrumentation-Instanz. In der Regel hat die Ziel-component die Form test_package/runner_class.

Es gibt folgende Optionen:

  • -r: Rohergebnisse drucken (andernfalls report_key_streamresult decodieren). Wird zusammen mit [-e perf true] verwendet, um eine Rohausgabe für Leistungsmessungen zu generieren.
  • -e name value: Legen Sie das Argument name auf value fest. Für Test-Runner ist das gängige Format -e testrunner_flag value[,value...].
  • -p file: Schreibt Profildaten in file.
  • -w: Warten Sie, bis die Instrumentierung abgeschlossen ist, bevor Sie zurückkehren. Erforderlich für Test-Runner.
  • --no-window-animation: Deaktiviert Fensteranimationen während der Ausführung.
  • --user user_id | current: Geben Sie an, in welcher Nutzerinstrumentierung ausgeführt wird. Wird nicht angegeben, wird es im aktuellen Nutzer ausgeführt.
profile start process file Profiler auf process starten, Ergebnisse in file schreiben
profile stop process Profiler auf process beenden.
dumpheap [options] process file Dump des Heaps von process und schreibe in file.

Es gibt folgende Optionen:

  • --user [user_id | current]: Geben Sie bei der Angabe eines Prozessnamens den Nutzer des Prozesses an, der erstellt werden soll. Wenn nicht angegeben, wird der aktuelle Nutzer verwendet.
  • -n: Dump des nativen Heaps anstelle des verwalteten Heaps.
set-debug-app [options] package App „package“ auf Fehlerbehebung setzen.

Es gibt folgende Optionen:

  • -w: Beim Start der Anwendung auf den Debugger warten.
  • --persistent: Diesen Wert beibehalten.
clear-debug-app Löscht das vorherige Paket zur Fehlerbehebung mit set-debug-app.
monitor [options] Starte die Überwachung auf Abstürze oder ANRs.

Es gibt folgende Optionen:

  • --gdb: Startet gdbserv am angegebenen Anschluss bei Absturz/ANR.
screen-compat {on | off} package Steuert den Bildschirmkompatibilitätsmodus von package.
display-size [reset | widthxheight] Überschreibt die Anzeigegröße des Geräts. Dieser Befehl ist hilfreich, um Ihre App für verschiedene Bildschirmgrößen zu testen. Dabei wird eine kleine Bildschirmauflösung auf einem Gerät mit einem großen Bildschirm nachgeahmt und umgekehrt.

Beispiel:
am display-size 1280x800

display-density dpi Kompaktheitsgrad des Geräts überschreiben. Dieser Befehl ist hilfreich, um Ihre App bei verschiedenen Bildschirmdichten zu testen, indem eine Bildschirmumgebung mit hoher Dichte mit einem Bildschirm mit niedriger Dichte nachgeahmt wird und umgekehrt.

Beispiel:
am display-density 480

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

Für Aktivitätsmanager-Befehle, 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 mit dem Paketmanager-Tool (pm) Befehle ausführen, um Aktionen und Abfragen für auf dem Gerät installierte App-Pakete auszuführen.

In einer Shell lautet die pm-Syntax so:

pm command

Sie können einen Paketmanager-Befehl auch direkt über adb ausführen, ohne eine Remote-Shell einzugeben. Beispiel:

adb shell pm uninstall com.example.MyApp

Tabelle 2: Verfügbare Paketmanager-Befehle

Befehl Beschreibung
list packages [options] filter Gibt alle Pakete aus (optional nur die Pakete), deren Paketname den Text in filter enthält.

Optionen:

  • -f: Siehe zugehörige Datei.
  • -d: Filtert, um nur deaktivierte Pakete anzuzeigen.
  • -e: So filtern Sie nur die aktivierten Pakete.
  • -s: So filtern Sie nur Systempakete.
  • -3: So filtern Sie nur Drittanbieterpakete.
  • -i: Siehe das Installationsprogramm für die Pakete.
  • -u: Auch deinstallierte Pakete schließen.
  • --user user_id: Der abzufragende Userspace.
list permission-groups Alle bekannten Berechtigungsgruppen drucken.
list permissions [options] group Geben Sie alle bekannten Berechtigungen aus, optional nur die in group.

Optionen:

  • -g: Nach Gruppe organisieren.
  • -f: Alle Informationen drucken.
  • -s: Kurze Zusammenfassung.
  • -d: Nur gefährliche Berechtigungen auflisten.
  • -u: nur die Berechtigungen auflisten, die Nutzer sehen.
list instrumentation [options] Listen Sie alle Testpakete auf.

Optionen:

  • -f: APK-Datei für das Testpaket auflisten
  • target_package: Listet Testpakete nur für diese App auf.
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 Geben Sie den Pfad zum APK der angegebenen package aus.
install [options] path Installieren Sie ein durch path angegebenes Paket auf dem System.

Optionen:

  • -r: Vorhandene App unter Beibehaltung der Daten neu installieren
  • -t: Die Installation von Test-APKs zulassen. Gradle generiert ein Test-APK, wenn du deine App nur ausgeführt oder debuggen oder den Android Studio-Befehl Build > Build APK verwendet hast. Wenn das APK mit einem SDK für die Entwicklervorschau erstellt wurde, musst du beim Installieren eines Test-APKs die Option -t in den Befehl install einfügen.
  • -i installer_package_name: Geben Sie den Namen des Installationspakets an.
  • --install-location location: Legen Sie den Installationspfad mit einem der folgenden Werte fest:
    • 0: Der Standardinstallationspfad wird verwendet.
    • 1: Im internen Gerätespeicher installieren.
    • 2: Auf externen Medien installieren.
  • -f: Paket auf dem internen Systemspeicher installieren
  • -d: Ermöglicht das Downgrade des Versionscodes.
  • -g: Alle im App-Manifest aufgeführten Berechtigungen werden gewährt.
  • --fastdeploy: Aktualisiere ein installiertes Paket schnell, indem du nur die Teile des APK aktualisierst, die sich geändert haben.
  • --incremental: Installiert so viele des APK, dass die App gestartet werden kann, während die verbleibenden Daten im Hintergrund gestreamt werden. Wenn du diese Funktion verwenden möchtest, musst du das APK signieren, eine APK Signature Scheme v4-Datei erstellen und diese Datei im selben Verzeichnis wie das APK speichern. Diese Funktion wird nur auf bestimmten Geräten unterstützt. Diese Option zwingt adb dazu, das Feature zu verwenden oder schlägt fehl, wenn es nicht unterstützt wird, zusammen mit ausführlichen Informationen zur Fehlerursache. Hänge die Option --wait an und erlaube dem Zugriff erst, wenn das APK vollständig installiert ist.

    --no-incremental verhindert, dass adb diese Funktion verwenden kann.

uninstall [options] package Entfernt ein Paket aus dem System.

Optionen:

  • -k: Die Daten- und Cache-Verzeichnisse werden nach dem Entfernen des Pakets beibehalten.
  • --user user_id: Gibt den Nutzer an, für den das Paket entfernt wird.
  • --versionCode version_code: Die App wird nur deinstalliert, wenn sie den angegebenen Versionscode hat.
clear package Löscht alle mit einem Paket verknüpften Daten.
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 Komponente (geschrieben als „package/class“).
disable-user [options] package_or_component

Optionen:

  • --user user_id: Der zu deaktivierende Nutzer.
grant package_name permission Einer App eine Berechtigung erteilen. 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 sich um eine optionale Berechtigung handeln, die von der App definiert wird.
revoke package_name permission Widerrufen Sie eine Berechtigung in einer App. 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 sich um eine optionale Berechtigung handeln, die von der App definiert wird.
set-install-location location Ändern Sie den Standardspeicherort für die Installation. Standortwerte:
  • 0: Automatisch: Das System wählt den besten Standort aus.
  • 1: Intern: Installation im internen Gerätespeicher.
  • 2: Extern: Auf externen Medien installieren.

Hinweis:Diese Anleitung dient nur der Fehlerbehebung. Ihre Verwendung kann dazu führen, dass Apps nicht mehr funktionieren und andere unerwünschte Verhaltensweisen auftreten.

get-install-location Gibt den aktuellen Installationspfad zurück. Rückgabewerte:
  • 0 [auto]: Vom System den besten Standort auswählen lassen
  • 1 [internal]: Im internen Gerätespeicher installieren
  • 2 [external]: Auf externen Medien installieren
set-permission-enforced permission [true | false] Geben Sie an, ob die gegebene Berechtigung erzwungen werden soll.
trim-caches desired_free_space Schneiden Sie Cache-Dateien, um den angegebenen freien Speicherplatz zu erreichen.
create-user user_name Erstellt einen neuen Nutzer mit dem angegebenen user_name und gibt die neue Nutzer-ID des Nutzers aus.
remove-user user_id Nutzer mit der angegebenen user_id entfernen und alle mit ihm verknüpften Daten löschen
get-max-users Die maximale Anzahl der vom Gerät unterstützten Nutzer ausgeben.
get-app-links [options] [package]

Gibt den Domainbestätigungsstatus für das angegebene package-Objekt oder für alle Pakete aus, wenn kein Status angegeben ist. Bundesstaatcodes sind wie folgt definiert:

  • none: Für diese Domain wurden keine Daten aufgezeichnet
  • verified: Die Domain wurde bestätigt.
  • approved: Erzwungene Genehmigung, in der Regel über die Shell
  • denied: erzwungene Ablehnung, in der Regel über die Shell
  • migrated: Bestätigung aus einer alten Antwort beibehalten
  • restored: Bestätigung aus einer Wiederherstellung von Nutzerdaten beibehalten
  • legacy_failure: von einem alten Prüfer abgelehnt, unbekannter Grund
  • system_configured: automatisch von der Gerätekonfiguration genehmigt
  • >= 1024: benutzerdefinierter Fehlercode, der für die Geräteprüfung spezifisch ist

Es gibt folgende Optionen:

  • --user user_id: Nutzerauswahl einschließen. Schließen Sie alle Domains ein, nicht nur diejenigen mit automatischer Bestätigung.
reset-app-links [options] [package]

Setzt den Domainbestätigungsstatus für das angegebene Paket oder für alle Pakete zurück, wenn keiner angegeben ist.

  • package: das Paket, das zurückgesetzt werden soll, oder „all“, um alle Pakete zurückzusetzen

Es gibt folgende Optionen:

  • --user user_id: Nutzerauswahl einschließen. Schließen Sie alle Domains ein, nicht nur diejenigen mit automatischer Bestätigung.
verify-app-links [--re-verify] [package]

Sende eine Bestätigungsanfrage für die angegebene package oder für alle Pakete, wenn keine angegeben ist. Wird nur gesendet, wenn das Paket zuvor keine Antwort erfasst hat.

  • --re-verify: wird gesendet, auch wenn das Paket eine Antwort erfasst 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.

  • --package package: das festzulegende Paket oder „all“, um alle Pakete festzulegen
  • state: Der Code, der für die Domains festgelegt werden soll. Gültige Werte:
    • STATE_NO_RESPONSE (0): wird zurückgesetzt, als wäre keine Antwort aufgezeichnet worden.
    • STATE_SUCCESS (1): behandelt die Domain als erfolgreich vom Domainbestätigungs-Agent. Beachten Sie, dass der Agent für die Domainbestätigung dies überschreiben kann.
    • STATE_APPROVED (2): Die Domain wird wie immer genehmigt behandelt und kann dadurch vom Agent für die Domainbestätigung nicht geändert werden.
    • STATE_DENIED (3): Die Domain wird als immer abgelehnt behandelt, sodass der Agent für die Domainbestätigung die Domain nicht ändern kann.
  • domains: durch Leerzeichen getrennte Liste der Domains, die geändert werden sollen, oder „alle“, um alle Domains zu ändern.
set-app-links-user-selection --user user_id [--package package] enabled domains

Legen Sie den Status einer 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.

  • --user user_id: der Nutzer, für den die Auswahl geändert werden soll
  • --package package: das festzulegende Paket
  • enabled: ob die Domain genehmigt werden soll
  • domains: durch Leerzeichen getrennte Liste der Domains, die geändert werden sollen, oder „alle“, um alle Domains zu ändern
set-app-links-user-selection --user user_id [--package package] enabled domains

Legen Sie den Status einer 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.

  • --user user_id: der Nutzer, für den die Auswahl geändert werden soll
  • --package package: das festzulegende Paket
  • enabled: ob die Domain genehmigt werden soll
  • domains: durch Leerzeichen getrennte Liste der Domains, die geändert werden sollen, oder „alle“, um alle Domains zu ändern
set-app-links-allowed --user user_id [--package package] allowed

Einstellung für die automatisch bestätigte Linkverarbeitung für ein Paket umschalten.

  • --user user_id: der Nutzer, für den die Auswahl geändert werden soll
  • --package package: das festzulegende Paket oder „all“, um alle Pakete festzulegen; Pakete werden zurückgesetzt, wenn kein Paket angegeben ist
  • allowed: „true“, damit das Paket automatisch bestätigte Links öffnen kann, „false“, um sie zu deaktivieren
get-app-link-owners --user user_id [--package package] domains

Drucken Sie die Inhaber für eine bestimmte Domain für einen bestimmten Nutzer in der Reihenfolge von niedriger bis hoher Priorität.

  • --user user_id: der Nutzer, der abgefragt werden soll
  • --package package: wird optional auch für alle Webdomains ausgegeben, die von einem Paket deklariert wurden, oder „all“, um alle Pakete auszugeben.
  • domains: durch Leerzeichen getrennte Liste der Domains, die abgefragt werden sollen

Geräterichtlinien-Manager anrufen (dpm)

Geben Sie Befehle an das Geräterichtlinienmanager-Tool (dpm) aus, um Sie beim Entwickeln und Testen Ihrer Apps zur Geräteverwaltung zu unterstützen. 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 wie folgt:

dpm command

Sie können einen Befehl des Geräterichtlinienmanagers auch direkt über adb ausführen, ohne eine Remote-Shell eingeben zu müssen:

adb shell dpm command

Tabelle 3 Verfügbare Befehle von Device Policy Manager

Befehl Beschreibung
set-active-admin [options] component Legt component als aktiven Administrator fest.

Es gibt folgende Optionen:

  • --user user_id: Geben Sie den Zielnutzer an. Sie können auch --user current übergeben, um den aktuellen Nutzer auszuwählen.
set-profile-owner [options] component Legen Sie component als aktiven Administrator und das zugehörige Paket als Profilinhaber für einen vorhandenen Nutzer fest.

Es gibt folgende Optionen:

  • --user user_id: Geben Sie den Zielnutzer an. Sie können auch --user current übergeben, um den aktuellen Nutzer auszuwählen.
  • --name name: Geben Sie den visuell lesbaren Organisationsnamen an.
set-device-owner [options] component Legen Sie component als aktiven Administrator und das zugehörige Paket als Geräteeigentümer fest.

Es gibt folgende Optionen:

  • --user user_id: Geben Sie den Zielnutzer an. Sie können auch --user current übergeben, um den aktuellen Nutzer auszuwählen.
  • --name name: Geben Sie den visuell lesbaren Organisationsnamen an.
remove-active-admin [options] component Deaktivieren Sie einen aktiven Administrator. Für die App muss im Manifest android:testOnly deklariert werden. Mit diesem Befehl werden auch Geräte- und Profilinhaber entfernt.

Es gibt folgende Optionen:

  • --user user_id: Geben Sie den Zielnutzer an. Sie können auch --user current übergeben, um den aktuellen Nutzer auszuwählen.
clear-freeze-period-record Löscht den Eintrag des Geräts über zuvor festgelegte Aufbewahrungszeiträume für OTA-Updates des Systems. Auf diese Weise lassen sich Einschränkungen bei der Geräteplanung bei der Entwicklung von Apps vermeiden, die Sperrzeiten verwalten. Weitere Informationen finden Sie 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, dass das System alle vorhandenen Netzwerkprotokolle zum Abrufen durch einen DPC bereit macht. Wenn Verbindungs- oder DNS-Logs verfügbar sind, empfängt der DPC den onNetworkLogsAvailable()-Callback. Siehe Logging der Netzwerkaktivität.

Dieser Befehl ist ratenbegrenzt. Diese Option wird auf Geräten mit Android 9.0 (API-Level 28) und höher unterstützt.

force-security-logs Erzwingen, dass das System alle vorhandenen Sicherheitsprotokolle für den DPC verfügbar macht. Wenn Logs verfügbar sind, empfängt der DPC den onSecurityLogsAvailable()-Callback. Siehe Aktivität von Unternehmensgeräten protokollieren.

Dieser Befehl ist ratenbegrenzt. Diese Option wird auf Geräten mit Android 9.0 (API-Level 28) und höher unterstützt.

Screenshot aufnehmen

Der Befehl screencap ist ein Shell-Dienstprogramm, mit dem Sie einen Screenshot vom Bildschirm eines Geräts erstellen können.

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 ist ein Beispiel für eine Screenshot-Sitzung, in der mit der adb-Shell der Screenshot und mit dem pull-Befehl die Datei vom Gerät heruntergeladen 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 die Bildschirmaktivität in einer MPEG-4-Datei auf. Sie können diese Datei verwenden, um Werbe- oder Schulungsvideos zu erstellen oder um Fehler zu beheben und zu testen.

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 endet die Aufzeichnung nach drei Minuten oder nach Ablauf des von --time-limit festgelegten Zeitlimits automatisch.

Führen Sie den Befehl screenrecord aus, um mit der Aufzeichnung des Gerätebildschirms zu beginnen. Führen Sie dann den Befehl pull aus, um das Video vom Gerät auf den Hostcomputer herunterzuladen. Hier ein Beispiel für eine Aufzeichnung:

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

Das Dienstprogramm screenrecord kann mit jeder von dir angeforderten Auflösung und Bitrate aufzeichnen, wobei das Seitenverhältnis des Gerätebildschirms beibehalten wird. Das Dienstprogramm zeichnet standardmäßig mit der nativen Displayauflösung und Ausrichtung auf. Die maximale Dauer beträgt drei Minuten.

Einschränkungen des screenrecord-Dienstprogramms:

  • In der Videodatei wird kein Ton aufgezeichnet.
  • Die Videoaufzeichnung ist für Geräte mit Wear OS nicht verfügbar.
  • Einige Geräte können möglicherweise nicht in der nativen Bildschirmauflösung aufnehmen. Wenn Sie Probleme mit der Bildschirmaufzeichnung haben, 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 Aufnahme dreht, wird ein Teil des Bildschirms bei der Aufzeichnung 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 (falls unterstützt), andernfalls 1.280 × 720. Die besten Ergebnisse erzielst du mit einer Größe, die vom Advanced Video Coding (AVC)-Encoder deines Geräts unterstützt wird.
--bit-rate rate Legen Sie die Video-Bitrate in Megabit pro Sekunde fest. Der Standardwert ist 20 Mbit/s. Sie können die Bitrate erhöhen, um die Videoqualität zu 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 Lege die maximale Aufnahmezeit in Sekunden fest. Der Standard- und Höchstwert beträgt 180 (3 Minuten).
--rotate Drehen Sie die Ausgabe um 90 Grad. Hierbei handelt es sich um eine experimentelle Funktion.
--verbose Zeigen Sie Loginformationen auf dem Befehlszeilenbildschirm an. 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-Level 24) erfasst Android Runtime (ART) Ausführungsprofile für installierte Apps, die zur Optimierung der App-Leistung verwendet werden. Untersuchen Sie die erfassten Profile, um herauszufinden, welche Methoden häufig ausgeführt werden und welche Klassen beim Start der Anwendung verwendet werden.

Hinweis:Sie können den Dateinamen des Ausführungsprofils nur dann abrufen, wenn Sie Root-Zugriff auf das Dateisystem haben, z. B. in einem Emulator.

Verwenden Sie den folgenden Befehl, um ein Textformat der Profilinformationen zu erstellen:

adb shell cmd package dump-profiles package

Verwenden Sie zum Abrufen der erstellten Datei:

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. Du kannst ein Testgerät mit Android 10 (API-Level 29) oder höher mit dem Shell-Befehl testharness adb auf die Werkseinstellungen zurücksetzen:

adb shell cmd testharness enable

Beim Wiederherstellen des Geräts mit testharness sichert das Gerät automatisch den RSA-Schlüssel, der die Fehlerbehebung über die aktuelle Workstation an einem nichtflüchtigen Speicherort ermöglicht. Das heißt, nach dem Zurücksetzen des Geräts kann die Workstation weiterhin Fehler beheben und adb-Befehle an das Gerät ausgeben, ohne manuell einen neuen Schlüssel zu registrieren.

Damit du deine App einfacher und sicherer weiter testen kannst, werden mit der testharness zum Wiederherstellen eines Geräts auch die folgenden Geräteeinstellungen geändert:

  • Das Gerät legt bestimmte Systemeinstellungen fest, sodass keine Assistenten für die Ersteinrichtung des Geräts angezeigt werden. Das Gerät wechselt in einen Status, über den Sie Ihre App schnell installieren, debuggen und testen können.
  • Einstellungen:
    • Deaktiviert den Sperrbildschirm.
    • Deaktiviert Notfallbenachrichtigungen.
    • Dadurch wird die automatische Synchronisierung für Konten deaktiviert.
    • Deaktiviert automatische Systemupdates.
  • Sonstiges:
    • Deaktiviert vorinstallierte Sicherheits-Apps

Wenn die Anwendung die Standardeinstellungen des Befehls testharness erkennen und anpassen muss, verwenden Sie ActivityManager.isRunningInUserTestHarness().

Squarelite

sqlite3 startet das sqlite-Befehlszeilentool zum Untersuchen von SQLite-Datenbanken. Sie enthält Befehle wie .dump, um den Inhalt einer Tabelle auszugeben, und .schema, um die SQL CREATE-Anweisung 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: Sie können nur auf eine SQLite-Datenbank zugreifen, wenn Sie Root-Zugriff auf das Dateisystem haben, z. B. in einem Emulator.

Weitere Informationen finden Sie in der Dokumentation zur sqlite3-Befehlszeile.

ADB-USB-Back-Ends

Der ADB-Server kann über zwei Back-Ends mit dem USB-Stack interagieren. Es kann entweder das native Back-End des Betriebssystems (Windows, Linux oder macOS) oder das libusb-Back-End verwenden. Einige Features wie attach, detach und die USB-Geschwindigkeitserkennung sind nur bei Verwendung des libusb-Back-Ends verfügbar.

Sie können ein Back-End mithilfe der Umgebungsvariable ADB_LIBUSB auswählen. Wenn es nicht festgelegt ist, verwendet ADB sein Standard-Back-End. Das Standardverhalten variiert je nach Betriebssystem. Ab ADB v34 wird das liubusb-Back-End standardmäßig auf allen Betriebssystemen mit Ausnahme von Windows verwendet, wo standardmäßig das native Back-End verwendet wird. Wenn ADB_LIBUSB festgelegt ist, wird dadurch bestimmt, ob das native Back-End oder libusb verwendet wird. Weitere Informationen zu ADB-Umgebungsvariablen finden Sie auf der Seite mit der ADB-Anleitung.

ADB mDNS-Backends

ADB kann das Multicast-DNS-Protokoll verwenden, um den Server und die Geräte automatisch zu verbinden. Der ADB-Server wird mit zwei Back-Ends ausgeliefert: Bonjour (mdnsResponseer von Apple) und Openscreen.

Für das Bonjour-Back-End muss auf dem Hostcomputer ein Daemon 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 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, um auf der Maschine ausgeführt zu werden. Die Unterstützung des Openscreen-Back-Ends unter macOS beginnt bei 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 mit der ADB-Anleitung.