Android Debug Bridge (ADB)

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:

  1. Aktivieren Sie Entwickleroptionen auf Ihrem Gerät.

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

    Drop-down-Menü zur Ausführung von Konfigurationen
    Abbildung 1: Menü „Konfigurationen ausführen“.

    Das Fenster Geräte über WLAN koppeln wird angezeigt (Abbildung 2).

    Screenshot des Pop-up-Fensters für die Gerätekopplung über WLAN
    Abbildung 2: Pop-up-Fenster zum Koppeln von Geräten per QR-Code oder Kopplungscode.

  3. Tippen Sie auf Ihrem Gerät auf Debugging bei kabellosem Laden und koppeln Sie Ihr Gerät:

    Screenshot eines Pixel Smartphones, auf dem die Einstellung „Wireless Debugging Systems“ zu sehen ist
    Abbildung 3: Screenshot der Einstellung Debugging bei WLAN auf einem Google Pixel

    1. 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.

    2. 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.

      Screenshot der Beispieleingabe für die PIN
      Abbildung 4: Beispiel für die Eingabe eines sechsstelligen Codes.

  4. 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.

  5. 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.

    Screenshot der Entwicklerkacheln für die Schnelleinstellungen auf einem Google Pixel
    Abbildung 5: Mit der Einstellung Schnelleinstellungen für Entwicklerkacheln können Sie das Debugging über WLAN schnell aktivieren oder deaktivieren.

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:

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

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

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

  4. 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.

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

  6. Gib auf Aufforderung den Kopplungscode wie unten dargestellt ein.

    Screenshot der Kopplung in der Befehlszeile.
    Abbildung 6: Eine Meldung zeigt an, dass die Kopplung deines Geräts erfolgreich abgeschlossen wurde.

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 mit adb 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:

  1. Verbinden Sie Ihr Android-Gerät und Ihren adb-Hostcomputer mit einem gängigen WLAN.

    2. 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.

  2. Verbinden Sie das Gerät über ein USB-Kabel mit dem Hostcomputer.
  3. Legen Sie das Zielgerät so fest, dass es auf eine TCP/IP-Verbindung an Port 5555 wartet: 
    adb tcpip 5555
  4. Ziehen Sie das USB-Kabel vom Zielgerät ab.
  5. 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.
  6. Stellen Sie über die IP-Adresse eine Verbindung zum Gerät her: 
    adb connect device_ip_address:5555
  7. 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:

  • 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 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 Server adb verbunden. Dieser Status bedeutet nicht, dass das Android-System vollständig gestartet und betriebsbereit ist, da sich das Gerät mit adb 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 Befehl devices 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:

  1. Verwenden Sie den Befehl devices, um die Seriennummer des Ziels abzurufen.
  2. Sobald Sie die Seriennummer haben, verwenden Sie die Option -s mit den adb-Befehlen, um die Seriennummer anzugeben.
    1. Wenn Sie viele adb-Befehle ausgeben möchten, können Sie stattdessen die Umgebungsvariable $ANDROID_SERIAL so festlegen, dass sie 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 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

Tabelle 1 Verfügbare Aktivitätsmanager-Befehle

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:

  • -D: Debugging aktivieren.
  • -W: Warten Sie, 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 Start der Aktivität count-mal. Vor jeder Wiederholung wird die wichtigste Aktivität beendet.
  • -S: Erzwingen Sie das Beenden der Ziel-App, bevor die Aktivität beginnt.
  • --opengl-trace: Aktiviert die Nachverfolgung von OpenGL-Funktionen.
  • --user user_id | current: Geben Sie an, als welcher Nutzer ausgeführt werden soll. Ist kein Nutzer 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 keine Angabe erfolgt, wird der Dienst als aktueller Nutzer ausgeführt.
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:

  • --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 Veranlassen Sie 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 keine Angabe erfolgt, an alle Nutzer senden.
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:

  • -r: Ausgabe der Rohergebnisse (andernfalls report_key_streamresult decodieren). Verwenden Sie sie mit [-e perf true], um eine Rohausgabe für Leistungsmessungen zu generieren.
  • -e name value: Legen Sie das Argument name auf value fest. Eine gängige Form für Test-Runner ist -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: Fensteranimationen während der Ausführung ausschalten.
  • --user user_id | current: Geben Sie an, in welcher Nutzerinstrumentierung ausgeführt wird. Wenn nicht angegeben, wird die Ausführung im aktuellen Nutzer ausgeführt.
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:

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

Es gibt folgende Optionen:

  • -w: Beim Starten der Anwendung wird auf den Debugger gewartet.
  • --persistent: Dieser Wert wird beibehalten.
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:

  • --gdb: Starten Sie gdbserv auf dem angegebenen Port bei Absturz/ANR.
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:
am display-size 1280x800

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:
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

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

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 verknüpfte Datei.
  • -d: Filtert so, dass nur deaktivierte Pakete angezeigt werden.
  • -e: Filtert so, dass nur aktivierte Pakete angezeigt werden.
  • -s: Filtert so, dass nur Systempakete angezeigt werden.
  • -3: Filtert so, dass nur Pakete von Drittanbietern angezeigt werden.
  • -i: Die Pakete finden Sie im Installationsprogramm.
  • -u: Umfasst nicht installierte Pakete.
  • --user user_id: Der abzufragende Nutzerbereich.
list permission-groups Alle bekannten Berechtigungsgruppen ausgeben.
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: Geben Sie nur die Berechtigungen an, die Nutzer sehen.
list instrumentation [options] Listet alle Testpakete auf.

Optionen:

  • -f: Listet die APK-Datei für das Testpaket auf.
  • target_package: Testpakete nur für diese App auflisten.
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:

  • -r: Installiert eine vorhandene App neu und behält ihre Daten bei.
  • -t: Installation von Test-APKs zulassen. Gradle generiert ein Test-APK, wenn Sie Ihre App nur ausgeführt oder Fehler behoben oder den Android Studio-Befehl Build > Build APK (Build > APK) verwendet haben. Wenn das APK mit einem Entwicklervorschau-SDK erstellt wurde, musst du beim Installieren eines Test-APKs die Option -t mit dem Befehl install angeben.
  • -i installer_package_name: Geben Sie den Namen des Installationspakets an.
  • --install-location location: Legen Sie den Installationsort mit einem der folgenden Werte fest:
    • 0: Standardspeicherort verwenden
    • 1: Auf internem Gerätespeicher installieren.
    • 2: Auf externen Medien installieren.
  • -f: Installation des Pakets im internen Systemspeicher.
  • -d: Downgrade des Versionscodes zulassen.
  • -g: Erteilt alle im App-Manifest aufgeführten Berechtigungen.
  • --fastdeploy: Du kannst ein installiertes Paket schnell aktualisieren, indem du nur die Teile des APKs aktualisierst, die geändert wurden.
  • --incremental: Installiert so viel des APK, dass die App gestartet wird und die verbleibenden Daten im Hintergrund gestreamt werden. Damit Sie diese Funktion verwenden können, müssen Sie das APK signieren, eine Datei für das APK-Signaturschema v4 erstellen und diese Datei im selben Verzeichnis wie das APK ablegen. Diese Funktion wird nur auf bestimmten Geräten unterstützt. Mit dieser Option wird erzwungen, dass adb das Feature verwendet oder fehlschlägt, wenn es nicht unterstützt wird. Außerdem enthält sie ausführliche Informationen dazu, warum der Fehler aufgetreten ist. Hängen Sie die Option --wait an, um zu warten, bis das APK vollständig installiert ist, bevor Sie Zugriff auf das APK gewähren.

    --no-incremental hindert adb daran, diese Funktion zu verwenden.

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

Optionen:

  • -k: Behält die Verzeichnisse für Daten und Cache nach der Paketentfernung bei.
  • --user user_id: Gibt den Nutzer an, für den das Paket entfernt wird.
  • --versionCode version_code: wird nur deinstalliert, wenn die App den angegebenen Versionscode hat.
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:

  • --user user_id: Der zu deaktivierende Nutzer.
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:
  • 0: Automatisch: Das System bestimmt den besten Standort.
  • 1: Intern: Im internen Gerätespeicher installieren.
  • 2: Extern: Auf externen Medien installieren.

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:
  • 0 [auto]: Das System ermittelt den besten Standort.
  • 1 [internal]: Auf internem Gerätespeicher installieren
  • 2 [external]: Auf externen Medien installieren
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:

  • none: Für diese Domain wurde nichts aufgezeichnet
  • verified: Die Domain wurde bestätigt.
  • approved: mit erzwungener Genehmigung, normalerweise über Shell
  • denied: erzwungener Ablehnung, normalerweise über Shell
  • migrated: Bestätigung aus einer Legacy-Antwort beibehalten
  • restored: Bestätigung nach einer Wiederherstellung der Nutzerdaten beibehalten
  • legacy_failure: von einer Legacy-Prüffunktion 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: Auswahl der Nutzer einschließen. Schließen Sie alle Domains ein, nicht nur Domains, die automatisch bestätigt werden.
reset-app-links [options] [package]

Domainbestätigungsstatus für das angegebene Paket oder für alle Pakete zurücksetzen, 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: Auswahl der Nutzer einschließen. Schließen Sie alle Domains ein, nicht nur Domains, die automatisch bestätigt werden.
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.

  • --re-verify: auch dann senden, wenn das Paket eine 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.

  • --package package: das festzulegende Paket oder „all“, um alle Pakete festzulegen
  • state: der Code, für den die Domains festgelegt werden sollen. Gültige Werte:
    • STATE_NO_RESPONSE (0): wird zurückgesetzt, als ob keine Antwort aufgezeichnet wurde.
    • STATE_SUCCESS (1): Die Domain wird als vom Domainbestätigungs-Agent bestätigt behandelt. Der Domainbestätigungs-Agent kann dies überschreiben.
    • STATE_APPROVED (2): Die Domain wird als immer genehmigt behandelt, sodass der Domainbestätigungs-Agent sie nicht ändern kann.
    • STATE_DENIED (3): Die Domain wird als immer abgelehnt behandelt, sodass der Domainbestätigungs-Agent sie nicht ändern kann.
  • domains: durch Leerzeichen getrennte Liste der Domains, die geändert werden sollen, oder „all“, um jede Domain zu ändern.
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.

  • --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 „all“, um jede Domain zu ändern
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.

  • --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 „all“, um jede Domain zu ändern
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.

  • --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 verifizierte Links öffnen kann, „false“ zum 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.

  • --user user_id: der abzufragende Nutzer
  • --package package: optional auch für alle Webdomains, die in einem Paket deklariert wurden, oder mit „all“, um alle Pakete zu drucken
  • domains: durch Leerzeichen getrennte Liste von Domains, die abgefragt werden sollen

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

Tabelle 3 Verfügbare Befehle für die Geräterichtlinienverwaltung

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 Lege 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 Lege component als aktiven Administrator und das zugehörige Paket als Geräteinhaber 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. Die App muss im Manifest android:testOnly deklarieren. 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 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.

Tabelle 4 Optionen für screenrecord

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 4 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.