Android Debug Bridge (ADB)

Android Debug Bridge (adb) ist ein vielseitiges Befehlszeilentool, mit dem Sie mit einem Gerät kommunizieren können. Mit dem Befehl adb können Sie verschiedene Geräteaktionen ausführen, z. B. Apps installieren und debuggen. 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 mit drei Komponenten:

  • Ein Client, der Befehle sendet. Der Client wird auf Ihrem Entwicklungscomputer ausgeführt. Sie können einen Client über ein Befehlszeilen-Terminal aufrufen, indem Sie einen adb-Befehl ausgeben.
  • 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 Paket „Android SDK Platform Tools“ enthalten. Laden Sie dieses Paket mit dem SDK-Manager herunter. Es wird dann unter android_sdk/platform-tools/ installiert. Wenn Sie das eigenständige Paket „Platform Tools“ des Android SDK benötigen, laden Sie es hier herunter.

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

Funktionsweise von adb

Wenn Sie einen adb-Client starten, prüft der Client zuerst, ob bereits ein adb-Serverprozess ausgeführt wird. Andernfalls wird der Serverprozess gestartet. Beim Starten bindet der Server an den lokalen TCP-Port 5037 und überwacht Befehle, die von adb-Clients gesendet werden.

Hinweis:Alle adb-Clients verwenden Port 5037, um mit dem adb-Server zu kommunizieren.

Der Server richtet dann Verbindungen zu allen laufenden Geräten ein. Er sucht Emulatoren, indem er Ports mit ungerader Nummer im Bereich von 5555 bis 5585 scannt. Dieser Bereich wird von den ersten 16 Emulatoren verwendet. Wenn der Server einen adb-Daemon (adbd) findet, stellt er eine Verbindung zu diesem Port her.

Jeder Emulator verwendet ein Paar aufeinanderfolgender Ports – einen Port mit gerader Nummer für Konsolenverbindungen und einen Port mit ungerader Nummer für adb-Verbindungen. Beispiel:

Emulator 1, Konsole: 5554
Emulator 1, adb: 5555
Emulator 2, Konsole: 5556
Emulator 2, adb: 5557
und so weiter.

Wie gezeigt, ist der Emulator, der über Port 5555 mit adb verbunden ist, derselbe wie der Emulator, dessen Konsole Port 5554 überwacht.

Sobald der Server Verbindungen zu allen Geräten hergestellt hat, können Sie mit adb-Befehlen auf diese Geräte zugreifen. Da der Server Verbindungen zu Geräten verwaltet und Befehle von mehreren adb-Clients verarbeitet, können Sie jedes Gerät von jedem Client oder über ein Script steuern.

ADB-Fehlerbehebung auf dem Gerät aktivieren

Wenn Sie adb mit einem über USB verbundenen Gerät verwenden möchten, müssen Sie in den Systemeinstellungen des Geräts unter Entwickleroptionen das USB-Debugging aktivieren. Unter Android 4.2 (API-Ebene 17) und höher ist der Bildschirm Entwickleroptionen standardmäßig ausgeblendet. Wenn Sie sie sehen möchten, aktivieren Sie die Entwickleroptionen.

Sie können Ihr Gerät jetzt über USB verbinden. Sie können prüfen, ob Ihr Gerät verbunden ist, indem Sie adb devices aus dem Verzeichnis android_sdk/platform-tools/ ausführen. Wenn eine Verbindung besteht, wird der Gerätename als „Gerät“ angezeigt.

Hinweis:Wenn Sie ein Gerät mit Android 4.2.2 (API-Ebene 17) oder höher verbinden, wird in einem Dialogfeld gefragt, ob Sie einen RSA-Schlüssel akzeptieren möchten, der das Debuggen über diesen Computer ermöglicht. Dieser Sicherheitsmechanismus schützt die Geräte der Nutzer, da USB-Debugging und andere ADB-Befehle nur ausgeführt werden können, wenn Sie das Gerät entsperren und das Dialogfeld bestätigen können.

Weitere Informationen zum Verbinden mit einem Gerät über USB finden Sie unter Apps auf einem Hardwaregerät ausführen.

Über WLAN eine Verbindung zu einem Gerät herstellen

Hinweis:Die folgende Anleitung gilt nicht für Wear-Geräte mit Android 11 (API-Level 30). Weitere Informationen finden Sie im Leitfaden zum Debuggen einer Wear OS-App.

Android 11 (API-Level 30) und höher unterstützen das drahtlose Bereitstellen und Debuggen Ihrer App von Ihrem Arbeitsplatz aus mithilfe von Android Debug Bridge (adb). So können Sie Ihre debuggbare App beispielsweise auf mehreren Remote-Geräten bereitstellen, ohne Ihr Gerät physisch über USB verbinden zu müssen. So müssen Sie keine häufigen Probleme mit USB-Verbindungen wie die Treiberinstallation beheben.

Bevor Sie mit dem drahtlosen Debuggen beginnen, müssen Sie Folgendes tun:

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

  • Achten Sie darauf, dass auf Ihrem Gerät Android 11 (API-Level 30) oder höher für Smartphones oder Android 13 (API-Level 33) oder höher für Android TV und Wear OS installiert ist. Weitere Informationen finden Sie unter Android-Version prüfen und aktualisieren.

  • Wenn Sie die IDE verwenden, muss die neueste Version von Android Studio installiert sein. Sie können es hier herunterladen.

  • Aktualisieren Sie auf Ihrer Workstation die SDK-Plattformtools auf die neueste Version.

Wenn Sie das drahtlose Debuggen verwenden möchten, müssen Sie Ihr Gerät über einen QR-Code oder einen Kopplungscode mit Ihrer 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 die 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ü „Ausführungskonfigurationen“
    Abbildung 1: Menü „Konfigurationen ausführen“

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

    Screenshot des Pop-up-Fensters „Geräte über WLAN koppeln“
    Abbildung 2: Pop-up-Fenster zum Koppeln von Geräten über einen QR-Code oder Kopplungscode.

  3. Tippen Sie auf Ihrem Gerät auf Drahtloses Debuggen und koppeln Sie Ihr Gerät:

    Screenshot eines Pixel Smartphones mit der Einstellung für die kabellose Fehlerbehebung
    Abbildung 3: Screenshot der Einstellung Ohne Kabel debuggen auf einem Google Pixel Smartphone

    1. Wenn Sie Ihr Gerät über einen QR-Code koppeln möchten, wählen Sie Gerät über QR-Code koppeln aus und scannen Sie den QR-Code aus dem Pop-up Geräte über WLAN koppeln in Abbildung 2.

    2. Wenn Sie Ihr Gerät über einen Kopplungscode koppeln möchten, wählen Sie im Pop-up Geräte über WLAN koppeln die Option Gerät über einen Kopplungscode koppeln aus. Wählen Sie auf Ihrem Gerät Über Kopplungscode koppeln aus und notieren Sie sich den sechsstelligen Code. Sobald Ihr Gerät im Fenster Geräte über WLAN koppeln angezeigt wird, können Sie Koppeln auswählen und den sechsstelligen Code eingeben, der auf Ihrem Gerät angezeigt wird.

      Screenshot eines Beispiels für die Eingabe einer PIN
      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 Sie ein anderes Gerät koppeln oder das aktuelle Gerät auf Ihrer Workstation entfernen möchten, rufen Sie auf Ihrem Gerät Drahtloses Debuggen auf. Tippen Sie unter Gekoppelte Geräte auf den Namen Ihrer Workstation und wählen Sie Vergessen aus.

  5. Wenn Sie das kabellose Debuggen schnell aktivieren und deaktivieren möchten, können Sie die Kacheln für Schnelleinstellungen für Entwickler für das kabellose Debuggen verwenden. Sie finden sie unter Entwickleroptionen > Kacheln für Schnelleinstellungen für Entwickler.

    Screenshot der Kacheln für Schnelleinstellungen für Entwickler auf einem Google Pixel Smartphone
    Abbildung 5: Mit der Einstellung Kacheln für Schnelleinstellungen für Entwickler können Sie das kabellose Debuggen schnell aktivieren und deaktivieren.

WLAN-Verbindung über die Befehlszeile

Alternativ können Sie auch ohne Android Studio über die Befehlszeile eine Verbindung zu Ihrem Gerät herstellen. Gehen Sie dazu so vor:

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

  2. Aktivieren Sie wie oben beschrieben die kabellose Fehlerbehebung auf Ihrem Gerät.

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

  4. Wählen Sie Gerät über einen Kopplungscode koppeln aus, um Ihre IP-Adresse, Portnummer und den Kopplungscode zu sehen. Notieren Sie sich die IP-Adresse, die Portnummer und den Kopplungscode, die auf dem Gerät angezeigt werden.

  5. Führen Sie im Terminal Ihrer Workstation adb pair ipaddr:port aus. Verwende die IP-Adresse und Portnummer von oben.

  6. Geben Sie auf Aufforderung den Kopplungscode ein (siehe unten).

    Screenshot des Koppelns über die Befehlszeile
    Abbildung 6 In einer Meldung wird angezeigt, dass die Kopplung Ihres Geräts erfolgreich war.

Probleme mit der WLAN-Verbindung beheben

Wenn Sie Probleme beim Herstellen einer drahtlosen Verbindung mit Ihrem Gerät haben, versuchen Sie, das Problem mithilfe der folgenden Schritte zur Fehlerbehebung zu beheben.

Prüfen, ob Workstation und Gerät die Voraussetzungen erfüllen

Prüfen Sie, ob die Workstation und das Gerät die am Anfang dieses Abschnitts aufgeführten Voraussetzungen erfüllen.

Nach anderen bekannten Problemen suchen

Im Folgenden finden Sie eine Liste der derzeit bekannten Probleme mit dem drahtlosen Debuggen (mit adb oder Android Studio) und deren Behebung:

  • Es kann keine WLAN-Verbindung hergestellt werden: Sichere WLANs, z. B. WLANs von Unternehmen, können P2P-Verbindungen blockieren und verhindern, dass Sie eine WLAN-Verbindung herstellen. Versuchen Sie, eine Verbindung über ein Kabel oder ein anderes (nicht geschäftliches) WLAN herzustellen. Eine weitere Option ist eine drahtlose Verbindung über adb connect ip:port über TCP/IP (nach einer ersten USB-Verbindung), falls ein nicht unternehmenseigenes Netzwerk infrage kommt.

  • adb wird über WLAN 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 stellt nach erfolgreicher Kopplung keine Verbindung her: adb nutzt mDNS, um gekoppelte Geräte zu finden und automatisch eine Verbindung herzustellen. Wenn Ihre Netzwerk- oder Gerätekonfiguration mDNS nicht unterstützt oder deaktiviert hat, müssen Sie eine manuelle Verbindung über adb connect ip:port herstellen.

Nach einer ersten USB-Verbindung kabellos mit einem Gerät verbinden (nur Option unter Android 10 und niedriger verfügbar)

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

Hinweis:Die folgende Anleitung gilt nicht für Wear-Geräte mit Android 10 (API-Level 29) oder niedriger. Weitere Informationen finden Sie im Leitfaden zum Entwickeln einer Wear OS-App.

adb kommuniziert normalerweise über USB mit dem Gerät, Sie können adb aber auch über WLAN verwenden. Wenn Sie ein Gerät mit Android 10 (API-Level 29) oder niedriger über USB verbinden möchten, gehen Sie so vor:

  1. Verbinden Sie Ihr Android-Gerät und den adb-Hostcomputer mit demselben WLAN.

    2. Hinweis:Nicht alle Zugangspunkte sind geeignet. Möglicherweise müssen Sie einen Zugangspunkt verwenden, dessen Firewall richtig für die Unterstützung von adb konfiguriert ist.

  2. Verbinden Sie das Gerät über ein USB-Kabel mit dem Hostcomputer.
  3. Legen Sie fest, dass das Zielgerät eine TCP/IP-Verbindung an Port 5555 überwacht: 
    adb tcpip 5555
  4. Trennen Sie das USB-Kabel vom Zielgerät.
  5. Suchen Sie die IP-Adresse des Android-Geräts. Auf einem Nexus-Gerät finden Sie die IP-Adresse beispielsweise unter Einstellungen > Über das Tablet (oder Über das Smartphone) > Status > IP-Adresse.
  6. Stellen Sie eine Verbindung zum Gerät über die IP-Adresse her: 
    adb connect device_ip_address:5555
  7. Prüfen Sie, ob Ihr Hostcomputer mit dem Zielgerät verbunden ist: 
    $ adb devices
List of devices attached
device_ip_address:5555 device

Ihr Gerät ist jetzt mit adb verbunden.

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

  • Achten Sie darauf, dass Ihr Host weiterhin 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.
  • Wenn das nicht funktioniert, setzen Sie Ihren adb-Host zurück: 
    adb kill-server

    Starten Sie dann von vorn.

Geräte abfragen

Bevor Sie adb-Befehle ausführen, ist es hilfreich zu wissen, welche Geräteinstanzen mit dem adb-Server verbunden sind. Mit dem Befehl devices eine Liste der angeschlossenen Geräte generieren: 

  adb devices -l

Als Antwort gibt adb für jedes Gerät die folgenden Statusinformationen aus:

  • Seriennummer:adb erstellt einen String, um das Gerät anhand seiner Portnummer eindeutig zu identifizieren. Hier ist 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 sich mit adb verbindet, während das System noch gestartet wird. Nach dem Starten ist dies der normale Betriebszustand eines Geräts.
    • no device: Es ist kein Gerät verbunden.
  • Beschreibung:Wenn Sie die Option -l angeben, erfahren Sie über den Befehl devices, um welches Gerät es sich handelt. Diese Informationen sind hilfreich, wenn Sie mehrere Geräte verbunden haben, damit Sie sie unterscheiden können.

Das folgende Beispiel zeigt den Befehl devices und seine Ausgabe. Es sind drei Geräte in Betrieb. Die ersten beiden Zeilen in der Liste sind Emulatoren und die dritte Zeile ist ein Hardwaregerät, das mit dem Computer verbunden ist.

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

Emulator nicht aufgeführt

Der Befehl adb devices enthält eine Befehlssequenz für Grenzfälle, die dazu führt, dass laufende Emulatoren nicht in der adb devices-Ausgabe angezeigt werden, obwohl sie auf dem Desktop sichtbar sind. Das ist der Fall, 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 und einem Portwert mit einer ungeraden Zahl zwischen 5554 und 5584.
  • Der von Ihnen ausgewählte Port mit der ungeraden Zahl ist nicht belegt. Die Portverbindung kann also über die angegebene Portnummer hergestellt werden. Ist der Port belegt, wechselt der Emulator zu einem anderen Port, der die Anforderungen in 2 erfüllt.
  • Starten Sie den adb-Server, nachdem Sie den Emulator gestartet haben.

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

Beispiel 1:In der folgenden Befehlssequenz wird mit dem Befehl adb devices der adb-Server gestartet, die Geräteliste wird jedoch 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 Geräteliste 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 vor dem 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 für 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. Geben Sie die Seriennummer mit der Option -s und den Befehlen adb an.
    1. Wenn Sie viele adb-Befehle ausführen möchten, können Sie die Umgebungsvariable $ANDROID_SERIAL stattdessen auf die Seriennummer festlegen.
    2. Wenn Sie sowohl -s als auch $ANDROID_SERIAL verwenden, wird $ANDROID_SERIAL durch -s überschrieben.

Im folgenden Beispiel wird die Liste der angeschlossenen Geräte abgerufen und dann die Seriennummer eines der Geräte verwendet, um die helloWorld.apk auf diesem Gerät zu installieren: 

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

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

Hinweis: Wenn Sie einen Befehl ausführen, ohne ein Zielgerät anzugeben, und mehrere Geräte verfügbar sind, wird in adb die Fehlermeldung „adb: more than one device/emulator“ (adb: mehr als ein Gerät/Emulator) angezeigt.

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 vorhanden sind, aber nur ein Hardwaregerät angeschlossen ist, verwenden Sie die Option -d, um Befehle an das Hardwaregerät zu senden.

App installieren

Sie können adb verwenden, um mit dem Befehl install ein APK auf einem Emulator oder einem verbundenen Gerät zu installieren:

adb install path_to_apk

Wenn Sie ein Test-APK installieren, müssen Sie die Option -t mit dem Befehl install verwenden. Weitere Informationen finden Sie unter -t.

Verwenden Sie install-multiple, um mehrere APKs zu installieren. Das ist nützlich, wenn Sie alle APKs für ein bestimmtes Gerät für Ihre App aus der Play Console herunterladen und auf einem Emulator oder einem physischen Gerät installieren möchten.

Weitere Informationen zum Erstellen einer APK-Datei, die Sie auf einer Emulator-/Gerätinstanz installieren können, finden Sie unter App erstellen und ausführen.

Hinweis:Wenn Sie Android Studio verwenden, müssen Sie adb nicht direkt verwenden, um Ihre App auf dem Emulator oder Gerät zu installieren. Stattdessen übernimmt Android Studio die Verpackung und Installation der App für Sie.

Portweiterleitung einrichten

Mit dem Befehl forward können Sie eine beliebige Portweiterleitung einrichten, bei der Anfragen an einem bestimmten Hostport an einen anderen Port auf einem Gerät weitergeleitet werden. Im folgenden Beispiel wird die Weiterleitung des Hostports 6100 an den Geräteport 7100 eingerichtet: 

adb forward tcp:6100 tcp:7100

Im folgenden Beispiel wird die Weiterleitung des Hostports 6100 an local:logd eingerichtet: 

adb forward tcp:6100 local:logd

Das kann hilfreich sein, wenn Sie herausfinden möchten, was an einen bestimmten Port auf dem Gerät gesendet wird. Alle empfangenen Daten werden in den Systemprotokoll-Daemon geschrieben und in den Geräteprotokollen angezeigt.

Dateien auf ein Gerät kopieren und von einem Gerät kopieren

Verwenden Sie die Befehle pull und push, um Dateien auf ein Gerät zu kopieren oder von einem Gerät zu kopieren. Im Gegensatz zum Befehl install, mit dem nur eine APK-Datei an einen bestimmten Speicherort kopiert wird, können Sie mit den Befehlen pull und push beliebige Verzeichnisse und Dateien an einen beliebigen Speicherort auf einem Gerät kopieren.

So kopieren Sie eine Datei oder ein Verzeichnis und seine Unterverzeichnisse vom Gerät: 

adb pull remote local

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

adb push local remote

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

adb push myfile.txt /sdcard/myfile.txt

adb-Server beenden

In einigen Fällen müssen Sie den adb-Serverprozess beenden und dann neu starten, um das Problem zu beheben. Das kann beispielsweise der Fall sein, wenn adb nicht auf einen Befehl reagiert.

Verwenden Sie den Befehl adb kill-server, um den adb-Server zu beenden. Sie können den Server dann mit einem beliebigen anderen adb-Befehl neu starten.

ADB-Befehle ausführen

Sie können adb-Befehle über eine Befehlszeile auf Ihrem Entwicklungscomputer oder über ein Script ausführen. Gehen Sie dazu so vor: 

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

Wenn nur ein Emulator ausgeführt wird oder nur ein Gerät verbunden ist, wird der Befehl adb standardmäßig an dieses Gerät gesendet. Wenn mehrere Emulatoren ausgeführt werden und/oder mehrere Geräte angeschlossen sind, müssen Sie mit der Option -d, -e oder -s das Zielgerät angeben, an das der Befehl gerichtet 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 kannst du Gerätebefehle über adb ausführen oder eine interaktive Shell starten. Wenn Sie einen einzelnen Befehl ausführen möchten, verwenden Sie den Befehl shell so: 

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

So starten Sie eine interaktive Shell auf einem Gerät:shell

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

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 rufen Sie mit dem folgenden Befehl auf:

adb shell ls /system/bin

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

Mit Android Platform Tools 23 und höher werden Argumente mit adb genauso behandelt wie mit dem Befehl ssh(1). Durch diese Änderung wurden viele Probleme mit Befehlseinschleusung behoben und es ist jetzt möglich, Befehle mit Shell-Metazeichen wie adb install Let\'sGo.apk sicher auszuführen. Durch diese Änderung hat sich auch die Interpretation aller Befehle geändert, die Shell-Metazeichen enthalten.

Beispiel: adb shell setprop key 'two words' ist jetzt ein Fehler, da die Anführungszeichen von der lokalen Shell verschluckt werden und das Gerät adb shell setprop key two words sieht. Damit der Befehl funktioniert, müssen Sie ihn zweimal in Anführungszeichen setzen, einmal für die lokale Shell und einmal für die Remote-Shell, genau wie bei ssh(1). adb shell setprop key "'two words'" funktioniert beispielsweise, weil die lokale Shell die äußere Anführungszeichenebene übernimmt und das Gerät weiterhin die innere Anführungszeichenebene sieht: setprop key 'two words'. Auch das Entkommen ist eine Option, aber das doppelte Anführungszeichen ist in der Regel einfacher.

Weitere Informationen finden Sie im Hilfeartikel zum Logcat-Befehlszeilentool, das sich zum Überwachen des Systemlogs eignet.

Anrufaktivitätsmanager

In einer adb-Shell können Sie mit dem Aktivitätsmanager (am) Befehle ausführen, um verschiedene Systemaktionen auszuführen, z. B. eine Aktivität starten, einen Prozess erzwingen, einen Intent übertragen oder die Eigenschaften des Gerätebildschirms ändern.

In einer Shell lautet die am-Syntax:

am command

Sie können einen Befehl für den Aktivitätsmanager auch direkt über adb ausführen, ohne eine Remote-Shell aufzurufen. Beispiel:

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

Tabelle 1 Verfügbare Befehle für den Aktivitätsmanager

Befehl Beschreibung
start [options] intent Starten Sie eine Activity, die durch intent angegeben ist.

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

Es gibt folgende Optionen:

  • -D: Aktivieren Sie die Fehlerbehebung.
  • -W: Warten, bis die Einführung abgeschlossen ist.
  • --start-profiler file: Profiler starten und Ergebnisse an file senden
  • -P file: Wie --start-profiler, aber das Profiling wird beendet, wenn die App inaktiv wird.
  • -R count: Wiederholen Sie die Aktivitätsauslösung count mal. Vor jeder Wiederholung wird die oberste Aktivität abgeschlossen.
  • -S: Beenden Sie die Ziel-App erzwungen, bevor Sie die Aktivität starten.
  • --opengl-trace: Aktivieren Sie das Tracing von OpenGL-Funktionen.
  • --user user_id | current: Gibt an, als welcher Nutzer das Programm ausgeführt werden soll. Wenn nichts angegeben ist, wird es als aktueller Nutzer ausgeführt.
startservice [options] intent Startet die von intent angegebene Service.

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

Es gibt folgende Optionen:

  • --user user_id | current: Geben Sie an, als welcher Nutzer der Befehl ausgeführt werden soll. Wenn nicht angegeben, wird der Befehl als aktueller Nutzer ausgeführt.
force-stop package Beenden Sie alle Prozesse, die mit package verknüpft sind.
kill [options] package Beenden Sie alle Prozesse, die mit package verknüpft sind. Mit diesem Befehl werden nur Prozesse beendet, die sicher beendet werden können und die sich nicht auf die Nutzerfreundlichkeit auswirken.

Es gibt folgende Optionen:

  • --user user_id | all | current: Geben Sie an, die Prozesse welcher Nutzer beendet werden sollen. Wenn nicht angegeben, werden die Prozesse aller Nutzer beendet.
kill-all Beenden Sie alle Hintergrundprozesse.
broadcast [options] intent Senden Sie einen Broadcast-Intent.

Weitere Informationen finden Sie in der 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, wird die E-Mail an alle Nutzer gesendet.
instrument [options] component Beginnen Sie mit dem Monitoring einer Instrumentation-Instanz. Normalerweise hat das Ziel component das Format test_package/runner_class.

Es gibt folgende Optionen:

  • -r: Rohergebnisse drucken (andernfalls report_key_streamresult decodieren). Mit [-e perf true] verwenden, um Rohausgaben für Leistungsmessungen zu generieren.
  • -e name value: Legen Sie das Argument name auf value fest. Für Testläufer ist -e testrunner_flag value[,value...] eine gängige Form.
  • -p file: Profildaten in file schreiben
  • -w: Warten, bis die Instrumentierung abgeschlossen ist, bevor zurückgegeben wird. Erforderlich für Testläufer.
  • --no-window-animation: Fensteranimationen während der Ausführung deaktivieren.
  • --user user_id | current: Gibt an, in welchem Nutzerkontext die Nutzerinstrumentierung ausgeführt wird. Wenn nicht angegeben, wird der aktuelle Nutzer verwendet.
profile start process file Profiler bei process starten, Ergebnisse in file schreiben
profile stop process Beenden Sie den Profiler auf process.
dumpheap [options] process file process-Heap dumpen, in file schreiben

Es gibt folgende Optionen:

  • --user [user_id | current]: Wenn Sie einen Prozessnamen angeben, geben Sie auch den Nutzer des zu dumpenden Prozesses an. Wenn nicht angegeben, wird der aktuelle Nutzer verwendet.
  • -b [| png | jpg | webp]: Bitmaps aus dem Grafikspeicher dumpen (API-Level 35 und höher) Optional können Sie das Dump-Format angeben (standardmäßig PNG).
  • -n: Dump des nativen Heaps anstelle des verwalteten Heaps.
set-debug-app [options] package Legen Sie die App package zum Debuggen fest.

Es gibt folgende Optionen:

  • -w: Beim Starten der App auf den Debugger warten.
  • --persistent: Diesen Wert beibehalten.
clear-debug-app Löschen Sie das Paket, das zuvor mit set-debug-app für das Debuggen festgelegt wurde.
monitor [options] Starten Sie die Überwachung von Abstürzen oder ANRs.

Es gibt folgende Optionen:

  • --gdb: Startet gdbserv am angegebenen Port bei einem Absturz/ANR.
screen-compat {on | off} package Bildschirmkompatibilitätsmodus von package steuern
display-size [reset | widthxheight] Displaygröße des Geräts überschreiben. Dieser Befehl ist hilfreich, um Ihre App auf verschiedenen Bildschirmgrößen zu testen. Dazu wird die Auflösung eines kleinen Bildschirms mit einem Gerät mit großem Bildschirm simuliert und umgekehrt.

Beispiel:
am display-size 1280x800

display-density dpi Kompaktheitsgrad des Gerätedisplays überschreiben. Dieser Befehl ist hilfreich, um Ihre App auf verschiedenen Bildschirmdichten zu testen. Dazu wird eine Umgebung mit hoher Bildschirmdichte mit einem Bildschirm mit niedriger Dichte simuliert und umgekehrt.

Beispiel:
am display-density 480

to-uri intent Die angegebene Intent-Spezifikation als URI drucken.

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

to-intent-uri intent Die angegebene Intent-Spezifikation als intent:-URI ausdrucken.

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

Spezifikation für Intent-Argumente

Bei Befehlen für den Aktivitätsmanager, die ein intent-Argument annehmen, können Sie die Absicht mit den folgenden Optionen angeben:

Paketmanager anrufen (pm)

In einer adb-Shell können Sie mit dem Paketmanager (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:

pm command

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

adb shell pm uninstall com.example.MyApp

Tabelle 2 Verfügbare Paketmanager-Befehle

Befehl Beschreibung
list packages [options] filter Alle Pakete drucken, optional nur diejenigen, deren Paketname den Text in filter enthält

Optionen:

  • -f: Siehe zugehörige Datei.
  • -d: Filtern Sie, um nur deaktivierte Pakete anzuzeigen.
  • -e: Filtern, um nur aktivierte Pakete anzuzeigen.
  • -s: Filtern Sie, um nur Systempakete anzuzeigen.
  • -3: Filtern Sie so, dass nur Drittanbieterpakete angezeigt werden.
  • -i: Sie finden sie im Installationsprogramm der Pakete.
  • -u: Entfernte Pakete einschließen.
  • --user user_id: Der abzufragende Nutzerbereich.
list permission-groups Alle bekannten Berechtigungsgruppen ausdrucken
list permissions [options] group Alle bekannten Berechtigungen drucken, optional nur die in group.

Optionen:

  • -g: Nach Gruppe organisieren
  • -f: Alle Informationen drucken.
  • -s: Kurze Zusammenfassung.
  • -d: Nur gefährliche Berechtigungen auflisten.
  • -u: Fügen Sie nur die Berechtigungen hinzu, die für Nutzer sichtbar sind.
list instrumentation [options] Listet alle Testpakete auf.

Optionen:

  • -f: Geben Sie die APK-Datei für das Testpaket an.
  • target_package: Testpakete nur für diese App auflisten.
list features Alle Funktionen des Systems ausdrucken
list libraries Alle vom aktuellen Gerät unterstützten Bibliotheken ausgeben
list users Alle Nutzer im System drucken.
path package Druckt den Pfad zum APK der angegebenen package aus.
install [options] path Installiert ein Paket, das durch path angegeben ist, auf dem System.

Optionen:

  • -r: Eine vorhandene App neu installieren und dabei die Daten beibehalten.
  • -t: Test-APKs dürfen installiert werden. Gradle generiert ein Test-APK, wenn Sie Ihre App nur ausgeführt oder debuggt oder den Befehl Build > Build APK in Android Studio verwendet haben. Wenn das APK mit einem SDK für die Entwicklervorschau erstellt wurde, müssen Sie die Option -t in den Befehl install aufnehmen, wenn Sie ein Test-APK installieren.
  • -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: Standardinstallationsort verwenden
    • 1: Installation im internen Gerätespeicher
    • 2: Auf externen Medien installieren
  • -f: Paket im internen Systemspeicher installieren.
  • -d: Downgrade des Versionscodes zulassen.
  • -g: Gewähren Sie alle im App-Manifest aufgeführten Berechtigungen.
  • --fastdeploy: Sie können ein installiertes Paket schnell aktualisieren, indem Sie nur die geänderten Teile des APK aktualisieren.
  • --incremental: Es wird genügend APK installiert, um die App zu starten, während die verbleibenden Daten im Hintergrund gestreamt werden. Wenn Sie diese Funktion verwenden möchten, müssen Sie das APK signieren, eine APK Signature Scheme v4-Datei erstellen und diese Datei im selben Verzeichnis wie das APK ablegen. Diese Funktion wird nur auf bestimmten Geräten unterstützt. Bei dieser Option wird adb gezwungen, die Funktion zu verwenden, oder es wird ein Fehler ausgegeben, wenn sie nicht unterstützt wird. Außerdem werden ausführliche Informationen dazu angezeigt, warum der Fehler aufgetreten ist. Fügen Sie die Option --wait an, um zu warten, bis das APK vollständig installiert ist, bevor Sie Zugriff darauf gewähren.

    --no-incremental verhindert, dass adb diese Funktion verwendet.

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

Optionen:

  • -k: Daten- und Cache-Verzeichnisse 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 Alle mit einem Paket verknüpften Daten löschen.
enable package_or_component Aktivieren Sie das angegebene Paket oder die angegebene Komponente (in Form von „Paket/Klasse“).
disable package_or_component Deaktivieren Sie das angegebene Paket oder die angegebene Komponente (als „Paket/Klasse“ geschrieben).
disable-user [options] package_or_component

Optionen:

  • --user user_id: Der Nutzer, der deaktiviert werden soll.
grant package_name permission Gewähren Sie einer App eine Berechtigung. Auf Geräten mit Android 6.0 (API-Level 23) und höher kann die Berechtigung jede im App-Manifest deklarierte Berechtigung sein. Auf Geräten mit Android 5.1 (API-Ebene 22) und niedriger muss es sich um eine optionale Berechtigung handeln, die von der App definiert wird.
revoke package_name permission Eine Berechtigung für eine App widerrufen. Auf Geräten mit Android 6.0 (API-Level 23) und höher kann es sich dabei um eine beliebige Berechtigung handeln, die im App-Manifest deklariert wurde. Auf Geräten mit Android 5.1 (API-Ebene 22) und niedriger muss es sich um eine optionale Berechtigung handeln, die von der App definiert wird.
set-install-location location Ändern Sie den Standardinstallationsort. Standortwerte:
  • 0: Automatisch: Das System entscheidet über den besten Speicherort.
  • 1: Intern: Installation im internen Gerätespeicher.
  • 2: Extern: Installation auf externen Medien.

Hinweis:Diese Option ist nur für die Fehlerbehebung gedacht. Dies kann zu Fehlfunktionen von Apps und anderen unerwünschten Verhaltensweisen führen.
get-install-location Gibt den aktuellen Installationsort zurück. Rückgabewerte:
  • 0 [auto]: Dem System erlauben, den besten Standort zu ermitteln
  • 1 [internal]: Im internen Gerätespeicher installieren
  • 2 [external]: Auf externen Medien installieren
set-permission-enforced permission [true | false] Geben Sie an, ob die angegebene Berechtigung erzwungen werden soll.
trim-caches desired_free_space Cachedateien kürzen, um den angegebenen freien Speicherplatz zu erreichen.
create-user user_name Erstellen Sie einen neuen Nutzer mit der angegebenen user_name und drucken Sie die neue Nutzer-ID des Nutzers aus.
remove-user user_id Entfernen Sie den Nutzer mit der angegebenen user_id und löschen Sie alle mit diesem Nutzer verknüpften Daten.
get-max-users Die maximale Anzahl der Nutzer drucken, die vom Gerät unterstützt wird.
get-app-links [options] [package]

Gibt den Domainbestätigungsstatus für die angegebene package oder für alle Pakete aus, falls keine angegeben ist. Die Bundesländercodes sind so definiert:

  • none: Für diese Domain wurde nichts aufgezeichnet.
  • verified: Die Domain wurde bestätigt.
  • approved: erzwungene Genehmigung, in der Regel über die Shell
  • denied: Zwangsverweigert, in der Regel über die Shell
  • migrated: Beibehaltene Bestätigung aus einer älteren Antwort
  • restored: Beibehaltene Bestätigung aus einer Wiederherstellung von Nutzerdaten
  • legacy_failure: Von einem Legacy-Bestätigungsdienst aus unbekanntem Grund abgelehnt
  • system_configured: automatisch von der Gerätekonfiguration genehmigt
  • >= 1024: benutzerdefinierter Fehlercode, der für den Geräteprüfer spezifisch ist

Es gibt folgende Optionen:

  • --user user_id: Nutzerauswahlen enthalten. Fügen Sie alle Domains hinzu, nicht nur die mit automatischer Bestätigung.
reset-app-links [options] [package]

Setzt den Status der Domainbestätigung für das angegebene Paket zurück oder für alle Pakete, wenn keines angegeben ist.

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

Es gibt folgende Optionen:

  • --user user_id: Nutzerauswahlen enthalten. Fügen Sie alle Domains hinzu, nicht nur die mit automatischer Bestätigung.
verify-app-links [--re-verify] [package]

Es wird eine Bestätigungsanfrage für die angegebene package gesendet oder für alle Pakete, wenn keine angegeben ist. Wird nur gesendet, wenn für das Paket zuvor keine Antwort aufgezeichnet wurde.

  • --re-verify: wird gesendet, auch wenn für das Paket eine Antwort erfasst wurde
set-app-links [--package package] state domains

Status einer Domain für ein Paket manuell festlegen Die Domain muss vom Paket als „autoVerify“ deklariert werden, damit dies funktioniert. Bei diesem Befehl wird kein Fehler für Domains gemeldet, die nicht angewendet werden konnten.

  • --package package: das Paket, das festgelegt werden soll, oder „alle“, um alle Pakete festzulegen
  • state: Der Code, auf den die Domains festgelegt werden sollen. Gültige Werte sind:
    • STATE_NO_RESPONSE (0): zurückgesetzt, als wäre nie eine Antwort erfasst worden.
    • STATE_SUCCESS (1): Die Domain wird als erfolgreich vom Domainbestätigungsagenten bestätigt behandelt. Der Domainbestätigungsagent kann dies jedoch überschreiben.
    • STATE_APPROVED (2): Die Domain wird immer als genehmigt behandelt, sodass der Domainbestätigungsagent sie nicht ändern kann.
    • STATE_DENIED (3): Die Domain wird als immer abgelehnt behandelt, sodass der Domain Verification Agent sie nicht ändern kann.
  • domains: Eine durch Leerzeichen getrennte Liste der zu ändernden Domains 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. Bei diesem Befehl wird kein Fehler für Domains gemeldet, die nicht angewendet werden konnten.

  • --user user_id: Nutzer, für den die Auswahl geändert werden soll
  • --package package: das Paket, das festgelegt werden soll
  • enabled: ob die Domain genehmigt werden soll
  • domains: Eine durch Leerzeichen getrennte Liste der zu ändernden Domains 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. Bei diesem Befehl wird kein Fehler für Domains gemeldet, die nicht angewendet werden konnten.

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

Aktivieren oder deaktivieren Sie die Einstellung für die automatische Bestätigung der Linkverwaltung für ein Paket.

  • --user user_id: Nutzer, für den die Auswahl geändert werden soll
  • --package package: das Paket, das festgelegt werden soll, oder „alle“, um alle Pakete festzulegen. Pakete werden zurückgesetzt, wenn kein Paket angegeben wird.
  • allowed: „wahr“, damit das Paket automatisch verifizierte Links öffnen kann, „falsch“, um diese Funktion zu deaktivieren
get-app-link-owners --user user_id [--package package] domains

Die Inhaber einer bestimmten Domain für einen bestimmten Nutzer in absteigender Prioritätsreihenfolge ausdrucken.

  • --user user_id: der Nutzer, nach dem gesucht werden soll
  • --package package: Optional auch für alle Webdomains drucken, die von einem Paket deklariert wurden, oder „alle“, um alle Pakete zu drucken
  • domains: Eine durch Leerzeichen getrennte Liste von Domains, nach denen gesucht werden soll.

Geräterichtlinienmanager anrufen (dpm)

Sie können Befehle an das Tool „Device Policy Manager“ (dpm) senden, um Ihre Apps zur Geräteverwaltung zu entwickeln und zu testen. Mit dem Tool können Sie die aktive Administrator-App steuern oder die Statusdaten einer Richtlinie auf dem Gerät ändern.

In einer Shell lautet die dpm-Syntax:

dpm command

Sie können einen Befehl für den Geräterichtlinienmanager auch direkt über adb ausführen, ohne eine Remote-Shell aufzurufen:

adb shell dpm command

Tabelle 3 Verfügbare Befehle für Device Policy Manager

Befehl Beschreibung
set-active-admin [options] component component wird als aktiver Administrator festgelegt.

Es gibt folgende Optionen:

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

Es gibt folgende Optionen:

  • --user user_id: Geben Sie den Zielnutzer an. Du kannst auch --user current übergeben, um den aktuellen Nutzer auszuwählen.
  • --name name: Geben Sie den für Menschen lesbaren Namen der Organisation an.
set-device-owner [options] component Legen Sie component als aktiven Administrator und sein Paket als Geräteinhaber fest.

Es gibt folgende Optionen:

  • --user user_id: Geben Sie den Zielnutzer an. Du kannst auch --user current übergeben, um den aktuellen Nutzer auszuwählen.
  • --name name: Geben Sie den für Menschen lesbaren Namen der Organisation an.
remove-active-admin [options] component Deaktivieren Sie einen aktiven Administrator. Die App muss android:testOnly im Manifest deklarieren. Mit diesem Befehl werden auch Geräte- und Profilinhaber entfernt.

Es gibt folgende Optionen:

  • --user user_id: Geben Sie den Zielnutzer an. Du kannst auch --user current übergeben, um den aktuellen Nutzer auszuwählen.
clear-freeze-period-record Löschen Sie den Eintrag für zuvor festgelegte Ruhezeiträume für OTA-Systemupdates auf dem Gerät. Das ist nützlich, um die Einschränkungen bei der Geräteplanung zu vermeiden, wenn Sie Apps entwickeln, die Ruhezeiträume verwalten. Weitere Informationen finden Sie unter Systemupdates verwalten.

Unterstützt auf Geräten mit Android 9.0 (API-Ebene 28) und höher.
force-network-logs Das System zwingt dazu, alle vorhandenen Netzwerkprotokolle für den Abruf durch einen Dienstanbieter für die digitale Post bereitzustellen. Wenn Verbindungs- oder DNS-Logs verfügbar sind, erhält der DPC den onNetworkLogsAvailable()-Callback. Weitere Informationen finden Sie unter Protokollierung der Netzwerkaktivität.

Für diesen Befehl gilt eine Ratenbegrenzung. Unterstützt auf Geräten mit Android 9.0 (API-Ebene 28) und höher.
force-security-logs Das System zwingen, alle vorhandenen Sicherheitsprotokolle für den Datenschutzbeauftragten verfügbar zu machen. Wenn Protokolle verfügbar sind, erhält der DPC den onSecurityLogsAvailable()-Callback. Weitere Informationen finden Sie unter Aktivitäten von Enterprise-Geräten erfassen.

Für diesen Befehl gilt eine Ratenbegrenzung. Unterstützt auf Geräten mit Android 9.0 (API-Ebene 28) und höher.

Screenshot erstellen

Der Befehl screencap ist ein Shell-Dienstprogramm zum Erstellen eines Screenshots des Displays eines Geräts.

In einer Shell lautet die screencap-Syntax: 

screencap filename

Wenn Sie screencap über die Befehlszeile verwenden möchten, geben Sie Folgendes ein: 

adb shell screencap /sdcard/screen.png

Hier ein Beispiel für eine Screenshot-Sitzung, bei der der Screenshot mit der adb-Shell aufgenommen und die Datei mit dem Befehl pull 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 des Displays von Geräten mit Android 4.4 (API-Ebene 19) und höher. Das Dienstprogramm zeichnet die Bildschirmaktivitäten in einer MPEG-4-Datei auf. Sie können diese Datei verwenden, um Werbe- oder Trainingsvideos zu erstellen oder zum Debuggen und Testen.

Verwenden Sie in einer Shell die folgende Syntax:

screenrecord [options] filename

Wenn Sie screenrecord über die Befehlszeile verwenden möchten, geben Sie Folgendes ein: 

adb shell screenrecord /sdcard/demo.mp4

Drücken Sie Strg + C, um die Bildschirmaufzeichnung zu beenden. Andernfalls wird die Aufzeichnung nach drei Minuten oder dem von --time-limit festgelegten Zeitlimit automatisch beendet.

Führen Sie den Befehl screenrecord aus, um den Bildschirm Ihres Geräts aufzuzeichnen. Führen Sie dann den Befehl pull aus, um das Video vom Gerät auf den Hostcomputer herunterzuladen. Hier ein Beispiel für eine Aufnahmesitzung:

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

Das Dienstprogramm screenrecord kann mit jeder unterstützten Auflösung und Bitrate aufzeichnen und dabei das Seitenverhältnis des Displays des Geräts beibehalten. Das Dienstprogramm zeichnet standardmäßig mit der nativen Displayauflösung und -ausrichtung auf und hat eine maximale Länge von drei Minuten.

Einschränkungen des screenrecord-Dienstprogramms:

  • Der Ton wird nicht mit der Videodatei aufgezeichnet.
  • Die Videoaufzeichnung ist auf Geräten mit Wear OS nicht verfügbar.
  • Auf einigen Geräten ist möglicherweise keine Aufnahme in der nativen Displayauflösung möglich. Wenn bei der Bildschirmaufzeichnung Probleme auftreten, versuchen Sie, eine niedrigere Bildschirmauflösung zu verwenden.
  • Die Bildschirmdrehung während der Aufnahme wird nicht unterstützt. Wenn sich das Display während der Aufnahme dreht, wird ein Teil des Displays in der Aufnahme abgeschnitten.

Tabelle 4 screenrecord Optionen

Optionen Beschreibung
--help Befehlssyntax und -optionen anzeigen
--size widthxheight Legen Sie die Videogröße fest: 1280x720. Der Standardwert ist die native Bildschirmauflösung des Geräts (falls unterstützt) oder 1280 x 720. Die besten Ergebnisse erzielst du mit einer Größe, die vom AVC-Encoder (Advanced Video Coding) deines Geräts unterstützt wird.
--bit-rate rate Legen Sie die Video-Bitrate für das Video in Megabit pro Sekunde fest. Der Standardwert ist 20 Mbit/s. Sie können die Bitrate erhöhen, um die Videoqualität zu verbessern. Dies führt jedoch zu größeren Filmdateien. Im folgenden Beispiel wird die Aufnahmebitrate auf 6 Mbit/s festgelegt: 
screenrecord --bit-rate 6000000 /sdcard/demo.mp4
--time-limit time Legen Sie die maximale Aufnahmedauer in Sekunden fest. Der Standard- und der Höchstwert ist 180 (3 Minuten).
--rotate Drehen Sie die Ausgabe um 90 Grad. Diese Funktion wird noch getestet.
--verbose Loginformationen auf dem Befehlszeilenbildschirm anzeigen Wenn Sie diese Option nicht festlegen, werden während der Ausführung keine Informationen angezeigt.

ART-Profile für Apps lesen

Ab Android 7.0 (API-Ebene 24) erfasst die Android Runtime (ART) Ausführungsprofile für installierte Apps, die zur Optimierung der App-Leistung verwendet werden. Prüfen Sie die erfassten Profile, um zu sehen, welche Methoden häufig ausgeführt werden und welche Klassen beim Starten der App verwendet werden.

Hinweis:Der Dateiname des Ausführungsprofils kann nur abgerufen werden, wenn Sie Root-Zugriff auf das Dateisystem haben, z. B. auf einem Emulator.

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

adb shell cmd package dump-profiles package

So rufen Sie die erstellte Datei ab:

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

Testgeräte zurücksetzen

Wenn Sie Ihre App auf mehreren Testgeräten testen, kann es sinnvoll sein, das Gerät zwischen den Tests zurückzusetzen, um beispielsweise Nutzerdaten zu entfernen und die Testumgebung zurückzusetzen. Sie können ein Testgerät mit Android 10 (API-Level 29) oder höher mit dem Shell-Befehl testharness adb auf die Werkseinstellungen zurücksetzen. 

adb shell cmd testharness enable

Wenn Sie das Gerät mit testharness wiederherstellen, wird der RSA-Schlüssel, der das Debuggen über die aktuelle Workstation an einem dauerhaften Speicherort ermöglicht, automatisch gesichert. Das bedeutet, dass nach dem Zurücksetzen des Geräts die Workstation weiterhin Fehler beheben und adb-Befehle an das Gerät senden kann, ohne einen neuen Schlüssel manuell zu registrieren.

Außerdem werden durch die Wiederherstellung eines Geräts mit testharness die folgenden Geräteeinstellungen geändert, um das Testen Ihrer App einfacher und sicherer zu machen:

  • Auf dem Gerät werden bestimmte Systemeinstellungen eingerichtet, sodass die Assistenten für die Ersteinrichtung des Geräts nicht angezeigt werden. Das Gerät wechselt also in einen Zustand, in dem Sie Ihre App schnell installieren, debuggen und testen können.
  • Einstellungen:
    • Der Sperrbildschirm wird deaktiviert.
    • Deaktiviert Notfallbenachrichtigungen.
    • Deaktiviert die automatische Synchronisierung für Konten.
    • Deaktiviert automatische Systemupdates.
  • Sonstiges:
    • Deaktiviert vorinstallierte Sicherheits-Apps.

Wenn Ihre App die Standardeinstellungen des Befehls testharness erkennen und anpassen muss, verwenden Sie den Befehl ActivityManager.isRunningInUserTestHarness().

sqlite

sqlite3 startet das Befehlszeilenprogramm sqlite zum Prüfen von SQLite-Datenbanken. Dazu gehören Befehle wie .dump zum Drucken des Inhalts einer Tabelle und .schema zum Drucken der SQL CREATE-Anweisung für eine vorhandene Tabelle. Sie können SQLite-Befehle auch über die Befehlszeile ausführen, wie hier gezeigt:

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

Hinweis:Der Zugriff auf eine SQLite-Datenbank ist nur möglich, wenn Sie Root-Zugriff auf das Dateisystem haben, z. B. auf einem Emulator.

Weitere Informationen finden Sie in der sqlite3-Befehlszeilendokumentation.

adb-USB-Backends

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 verwendet werden. Einige Funktionen wie attach, detach und die USB-Geschwindigkeitserkennung sind nur bei Verwendung des libusb-Backends verfügbar.

Sie können ein Backend mithilfe der Umgebungsvariablen ADB_LIBUSB auswählen. Wenn diese Option nicht festgelegt ist, verwendet adb das Standard-Backend. Das Standardverhalten variiert je nach Betriebssystem. Ab ADB v34 wird das liubusb-Back-End standardmäßig auf allen Betriebssystemen außer Windows verwendet, wo das native Back-End standardmäßig verwendet wird. Wenn ADB_LIBUSB festgelegt ist, wird damit bestimmt, ob das native Backend oder libusb verwendet wird. Weitere Informationen zu adb-Umgebungsvariablen finden Sie auf der adb-Manpage.

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 (mdnsResponder von Apple) und Openscreen.

Für das Bonjour-Backend muss ein Daemon auf dem Hostcomputer ausgeführt werden. Unter macOS ist der integrierte Daemon von Apple immer aktiv. 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-Backend, aber es ist kein Bonjour-Daemon aktiv.

Für das Openscreen-Backend muss kein Daemon auf dem Computer ausgeführt werden. Das Openscreen-Backend wird unter macOS ab ADB v35 unterstützt. Windows und Linux werden ab ADB v34 unterstützt.

Standardmäßig verwendet ADB das Bonjour-Backend. Dieses Verhalten kann mit der Umgebungsvariablen ADB_MDNS_OPENSCREEN geändert werden (1 oder 0 festlegen). Weitere Informationen finden Sie auf der ADB-Anleitungsseite.

adb-Burst-Modus (ab ADB 36.0.0)

Der Burst-Modus ist eine experimentelle Funktion, mit der ADB weiterhin Pakete an ein Gerät senden kann, auch bevor das Gerät auf das vorherige Paket geantwortet hat. Dadurch wird der Durchsatz von ADB bei der Übertragung großer Dateien erheblich erhöht und die Latenz beim Debuggen verringert.

Der Serienbildmodus ist standardmäßig deaktiviert. So aktivieren Sie die Funktion:

  • Legen Sie die Umgebungsvariable ADB_DELAYED_ACK auf 1 fest.
  • Rufen Sie in Android Studio die Debugger-Einstellungen unter Datei (oder Android Studio unter macOS) > Einstellungen > Build, Ausführung, Bereitstellung > Debugger auf und legen Sie ADB-Server-Burst-Modus auf Aktiviert fest.