Android Debug Bridge (ADB)

Die Android Debug Bridge (adb) ist ein vielseitiges Befehlszeilentool, mit dem Sie mit einem Gerät kommunizieren können. Der adb-Befehl 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:

  • Ein Client, der Befehle sendet. Der Client wird auf Ihrer Entwicklungsmaschine ausgeführt. Sie können einen Client über ein Befehlszeilenterminal mit dem Befehl adb aufrufen.
  • Ein Daemon (adbd), der Befehle auf einem Gerät ausführt. Der Daemon wird auf jedem Gerät als Hintergrundprozess ausgeführt.
  • Ein Server, der die Kommunikation zwischen dem Client und dem Daemon verwaltet. Der Server wird als Hintergrundprozess auf Ihrer Entwicklungsmaschine 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 Android SDK Platform Tools-Paket benötigen, können Sie es hier herunterladen.

Informationen zum Verbinden eines Geräts für die Verwendung über adb, einschließlich der Verwendung des Verbindungsassistenten zur Fehlerbehebung bei häufigen Problemen, 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. Wenn nicht, wird der Serverprozess gestartet. Wenn der Server gestartet wird, wird er an den lokalen TCP-Port 5037 gebunden und überwacht Befehle, die von adb-Clients gesendet werden.

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

Der Server stellt dann Verbindungen zu allen laufenden Geräten her. Emulatoren werden durch Scannen ungerader Ports im Bereich von 5555 bis 5585 gefunden. Dieser Bereich wird von den ersten 16 Emulatoren verwendet. Wenn der Server einen adb-Daemon (adbd) findet, stellt er eine Verbindung zu diesem Port her.

Für jeden Emulator wird ein Paar aufeinanderfolgender Ports verwendet: ein Port mit gerader Nummer für Konsolenverbindungen und ein Port mit ungerader Nummer für adb-Verbindungen. Beispiel:

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

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

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

ADB-Debugging auf Ihrem Gerät aktivieren

Wenn Sie „adb“ mit einem über USB verbundenen Gerät verwenden möchten, müssen Sie in den Gerätesystemeinstellungen 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 ihn sichtbar machen 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 über das Verzeichnis android_sdk/platform-tools/ ausführen. Wenn das Gerät verbunden ist, wird der Gerätename als „Gerät“ aufgeführt.

Hinweis:Wenn Sie ein Gerät mit Android 4.2.2 (API-Level 17) oder höher verbinden, wird in einem Dialogfeld gefragt, ob Sie einen RSA-Schlüssel akzeptieren möchten, der das Debugging über diesen Computer ermöglicht. Dieser Sicherheitsmechanismus schützt Nutzergeräte, da er dafür sorgt, dass 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 mit einem Gerät verbinden

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

Unter Android 11 (API‑Level 30) und höher können Sie Ihre App drahtlos von Ihrem Arbeitsplatz aus mit Android Debug Bridge (adb) bereitstellen und debuggen. So können Sie Ihre debugfähige App beispielsweise auf mehreren Remote-Geräten bereitstellen, ohne Ihr Gerät jemals physisch über USB verbinden zu müssen. So lassen sich Probleme mit USB-Verbindungen wie die Treiberinstallation vermeiden.

Mit Android 17 und adb 37.0.0 wird adb Wi‑Fi 2.0 eingeführt, das viele der Probleme der vorherigen Version behebt. Das Gerät stellt automatisch eine Verbindung zur Workstation her, wenn es mit einem vertrauenswürdigen Netzwerk für das kabellose Debugging verbunden ist.

Bevor Sie mit dem Debugging über WLAN beginnen, führen Sie die folgenden Schritte aus:

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

  • Achte darauf, dass auf deinem Smartphone Android 11 (API‑Level 30) oder höher und auf deinem Fernseher und WearOS-Gerät Android 13 (API‑Level 33) oder höher ausgeführt wird. Weitere Informationen findest du unter Android-Version prüfen und aktualisieren.

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

Wenn Sie das Debugging über WLAN verwenden möchten, müssen Sie Ihr Gerät über einen QR-Code oder einen Kopplungscode mit Ihrer Workstation koppeln. Ihre Workstation und Ihr Gerät müssen mit demselben WLAN verbunden sein. So koppeln Sie Ihr Gerät:

Hinweis:Sie müssen Ihr Gerät nur einmal mit Ihrer Workstation koppeln. Das Gerät bleibt mit Ihrer Workstation gekoppelt, bis Sie es ausdrücklich vergessen oder die ADB-Fehlerbehebungsautorisierungen auf Ihrem Gerät widerrufen. Das Gerät und die Workstation stellen automatisch eine Verbindung her, wenn sie sich im selben Netzwerk befinden.

  1. Aktivieren Sie die Entwickleroptionen auf Ihrem Gerät.

  2. Tippen Sie auf Ihrem Gerät auf Debugging über WLAN:

    Screenshot eines Pixel Smartphones, auf dem die Aufforderung zum Debugging über WLAN angezeigt wird.
    Abbildung 1. Die Aufforderung zum Debugging über WLAN auf einem Google Pixel Smartphone.

  3. Debugging über WLAN in Ihrem Netzwerk zulassen Wenn Sie das Kästchen In diesem Netzwerk immer zulassen anklicken, wird das Netzwerk zu einem vertrauenswürdigen WLAN-Debugging-Netzwerk. Ihr Gerät lässt in diesem Netzwerk immer das Debugging über WLAN zu, sobald es mit dem Netzwerk verbunden ist.

    4. Screenshot eines Google Pixel Smartphones mit der Systemeinstellung „Debugging über WLAN“.
    Abbildung 2: Die Einstellung Debugging über WLAN auf einem Google Pixel.

    Hinweis:Android Studio-Nutzer können ihr Gerät über einen QR‑Code koppeln. Wählen Sie dazu Gerät über QR‑Code koppeln aus und scannen Sie den QR‑Code, den Sie im Dialogfeld Geräte über WLAN koppeln in Android Studio erhalten haben.

  4. Wählen Sie auf Ihrem Gerät Über Kopplungscode koppeln aus und notieren Sie sich die IP-Adresse, die Portnummer und den Kopplungscode, die auf dem Gerät angezeigt werden.

  5. Öffnen Sie auf Ihrer Workstation ein Terminalfenster und wechseln Sie zu android_sdk/platform-tools.

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

  7. Gib bei Aufforderung den Kopplungscode ein, wie unten dargestellt.

    Screenshot der Kopplung über die Befehlszeile
    Abbildung 3: Eine Meldung wird angezeigt, dass Ihr Gerät erfolgreich gekoppelt wurde.

  8. Nachdem Ihr Gerät gekoppelt wurde, prüfen Sie, ob es verbunden ist.Sie können es jetzt wie bei einer USB-Verbindung kabellos verwenden.

    Wenn Sie die Kopplung Ihrer Workstation aufheben möchten, rufen Sie auf Ihrem Gerät Drahtloses Debugging auf. Tippen Sie unter Gekoppelte Geräte auf den Namen Ihrer Arbeitsstation und wählen Sie Entfernen aus. Alternativ können Sie auf Ihrem Gerät auf der Seite „Einstellungen“ auf adb-Debugging-Autorisierungen widerrufen klicken, um die Verknüpfung Ihrer Arbeitsstation und aller anderen zuvor gekoppelten Arbeitsstationen aufzuheben.

  9. Wenn Sie das Debugging über WLAN schnell aktivieren und deaktivieren möchten, können Sie die Kacheln für Schnelleinstellungen für Entwickler für Debugging über WLAN verwenden. Sie finden sie unter Entwickleroptionen > Kacheln für Schnelleinstellungen für Entwickler.

    Screenshot von Kacheln für Schnelleinstellungen für Entwickler auf einem Google Pixel Smartphone.
    Abbildung 4: Mit der Einstellung Kacheln für Schnelleinstellungen für Entwickler können Sie das Debugging über WLAN schnell aktivieren und deaktivieren.

Probleme mit der kabellosen Verbindung beheben

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

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

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

Prüfen, ob die ADB-Einrichtung auf Ihrer Workstation korrekt ist

Um zu prüfen, ob die ADB-Einrichtung auf Ihrer Workstation korrekt ist, öffnen Sie ein Terminal auf Ihrer Workstation und geben Sie adb server-status ein. Prüfen Sie, ob die Ausgabe Folgendes enthält:

  • version: "37.0.0" oder höher:Falls nicht, laden Sie die aktuelle Version der SDK-Plattformtools herunter.
  • mdns_enabled: true: Wenn diese Option auf false festgelegt ist, kann adb Geräte in Ihrem Netzwerk nicht automatisch erkennen. Um dieses Problem zu beheben, müssen Sie die Umgebungsvariable ADB_MDNS auf 1 festlegen und dann den ADB-Server neu starten, indem Sie adb kill-server und dann adb start-server ausführen.
  • mdns_backend: LIBADBMDNS: Wenn dies nicht der Fall ist, verwendet adb eine veraltete Bibliothek, um Geräte in Ihrem Netzwerk automatisch zu erkennen. Um dieses Problem zu beheben, müssen Sie die Umgebungsvariable ADB_MDNS_OPENSCREEN auf 0 festlegen und dann den ADB-Server neu starten, indem Sie adb kill-server und dann adb start-server ausführen.

Prüfen, ob Ihr Netzwerk mDNS unterstützt

 adb verwendet mDNS, um automatisch gekoppelte Geräte zu erkennen und eine Verbindung zu ihnen herzustellen. So prüfen Sie, ob Ihr Netzwerk mDNS unterstützt:

  1. Aktivieren Sie auf Ihrem Gerät das Debugging über WLAN, wie im Abschnitt Über WLAN mit einem Gerät verbinden beschrieben.

  2. Öffnen Sie auf Ihrer Workstation ein Terminal und geben Sie adb mdns track-services --proto-text ein.

  3. Prüfen Sie, ob die Ausgabe leer ist und einen TLS-Dienst mit der IP-Adresse und Portnummer Ihres Geräts enthält. Wenn die Ausgabe leer ist, unterstützt Ihr Netzwerk mDNS nicht. Beispielausgabe:

    tls {
  service {
    instance: "adb-35121FDJH000R8-xyMD0H"
    service: "_adb-tls-connect._tcp"
    ipv4: "192.168.84.23"
    ipv6: "fe80:0:0:0:fc7a:299d:8d38:6c1c"
    port: 37895
    product_model: "Pixel 8"
    build_version_sdk_full: "37.0"
    given_name: "sherifeid Pixel"
    serial: "35121FDJH000R8"
    mdns_service_version: "2.0"
    hostname: "Android_CXUKYJY1.local"
  }
}

Prüfen, ob Ihr Gerät ADB Wi‑Fi 2.0 unterstützt

Hinweis:ADB Wi‑Fi 2.0 wird unter Android 17 und höher unterstützt.

So prüfen Sie, ob Ihr Gerät ADB Wi‑Fi 2.0 unterstützt:

  1. Aktivieren Sie auf Ihrem Gerät das Debugging über WLAN, wie im Abschnitt Über WLAN mit einem Gerät verbinden beschrieben.

  2. Öffnen Sie auf Ihrer Workstation ein Terminal und geben Sie adb mdns track-services --proto-text ein.

  3. Prüfen Sie, ob die Ausgabe mdns_service_version: "2.0" oder höher enthält. Wenn das nicht der Fall ist, wird auf Ihrem Gerät nicht Android 17 oder höher ausgeführt und es unterstützt ADB over Wi-Fi 2.0 nicht. Wenn Sie auf Android 17 oder höher aktualisieren möchten, prüfen Sie, ob für Ihr Gerät ausstehende Systemupdates verfügbar sind. Android-Version prüfen und aktualisieren

Neues Problem melden

Wenn weiterhin Probleme beim Herstellen einer drahtlosen Verbindung zu Ihrem Gerät auftreten, können Sie ein neues Problem melden. Bitte geben Sie in Ihrem Bericht die folgenden Informationen an:

  • Protokolle von Ihrem Gerät:Reproduzieren Sie das Problem und hängen Sie die Geräteprotokolle an.
  • Die Logs von ADB auf Ihrer Workstation:
    1. Umgebungsvariable ADB_TRACE=all festlegen
    2. Starten Sie den ADB-Server neu, indem Sie adb kill-server und dann adb start-server ausführen.
    3. Reproduzieren Sie den Fehler.
    4. Logdateien suchen:Führen Sie adb server-status aus und hängen Sie die in der Ausgabe log_absolute_path referenzierte Logdatei an.

Kabellose Verbindung mit einem Gerät nach einer ersten USB-Verbindung herstellen (einzige Option unter Android 10 und niedriger)

Hinweis:Dieser Workflow gilt auch für Android 11 und höher. Allerdings ist dafür auch eine *anfängliche* Verbindung über USB erforderlich.

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

adb kommuniziert 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-Ebene 29) oder niedriger verbinden möchten, führen Sie die folgenden Schritte über USB aus:

  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 Zugriffspunkt 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 auf Port 5555 auf eine TCP/IP-Verbindung wartet: 
    adb tcpip 5555
  4. Ziehen Sie das USB‑Kabel vom Zielgerät ab.
  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 über die IP-Adresse eine Verbindung zum Gerät 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

Dein Gerät ist jetzt mit adb verbunden.

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

  • Das Hostgerät muss mit demselben WLAN verbunden sein wie dein Android-Gerät.
  • Stellen Sie die Verbindung wieder her, indem Sie den Schritt adb connect noch einmal ausführen.
  • Wenn das nicht funktioniert, setzen Sie den adb-Host zurück: 
    adb kill-server

    Fangen Sie dann noch einmal von vorne an.

Geräte abfragen

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

  adb devices -l

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

  • Seriennummer:adb erstellt einen String, um das Gerät anhand seiner Portnummer eindeutig zu identifizieren. Beispiel für eine Seriennummer: emulator-5554
  • Status:Der Verbindungsstatus des Geräts kann einer der folgenden sein:
    • offline: Das Gerät ist nicht 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 hochgefahren und betriebsbereit ist, da das Gerät eine Verbindung zu adb herstellt, während das System noch hochfährt. Nach dem Hochfahren ist dies der normale Betriebszustand eines Geräts.
    • no device: Es ist kein Gerät verbunden.
  • Beschreibung:Wenn Sie die Option -l angeben, gibt der Befehl devices an, um welches Gerät es sich handelt. Diese Information ist hilfreich, wenn mehrere Geräte verbunden sind, damit Sie sie unterscheiden können.

Das folgende Beispiel zeigt den Befehl devices und seine Ausgabe. Es 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 hat eine Grenzfall-Befehlsfolge, die dazu führt, dass laufende Emulatoren nicht in der adb devices-Ausgabe angezeigt werden, obwohl die Emulatoren auf Ihrem Desktop sichtbar sind. Dies geschieht, wenn alle der folgenden Bedingungen erfüllt sind:

  • Der Server „adb“ wird nicht ausgeführt.
  • Sie verwenden den Befehl emulator mit der Option -port oder -ports mit einem ungeraden Portwert zwischen 5554 und 5584.
  • Der von Ihnen ausgewählte Port mit ungerader Nummer ist nicht belegt. Die Portverbindung kann also über die angegebene Portnummer hergestellt werden. Wenn der Port belegt ist, wechselt der Emulator zu einem anderen Port, der die Anforderungen in Punkt 2 erfüllt.
  • Sie starten den adb-Server, nachdem Sie den Emulator gestartet haben.

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

Beispiel 1:In der folgenden Befehlsfolge wird der adb-Server mit dem Befehl adb devices gestartet, die Liste der Geräte wird jedoch nicht angezeigt.

Stoppen Sie den adb-Server und geben Sie die folgenden Befehle in der angegebenen Reihenfolge ein. Geben Sie für den AVD-Namen einen gültigen AVD-Namen aus Ihrem System an. Geben Sie emulator -list-avds ein, um eine Liste der AVD-Namen 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 Befehlsfolge wird die Liste der Geräte von adb devices angezeigt, da der adb-Server zuerst gestartet wurde.

Wenn Sie den Emulator in der adb devices-Ausgabe sehen möchten, stoppen Sie den adb-Server und starten Sie ihn dann wieder, nachdem Sie den emulator-Befehl und vor dem adb devices-Befehl verwendet haben: 

$ adb kill-server
$ emulator -avd Nexus_6_API_25 -port 5557
$ adb start-server
$ adb devices

List of devices attached
emulator-5557 device

Weitere Informationen zu den Befehlszeilenoptionen des Emulators finden Sie unter Befehlszeilen-Startoptionen.

Befehle an ein bestimmtes Gerät senden

Wenn mehrere Geräte ausgeführt werden, müssen Sie das Zielgerät angeben, wenn Sie den Befehl adb ausführen. So legen Sie das Ziel fest:

  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 ausführen möchten, können Sie stattdessen die Umgebungsvariable $ANDROID_SERIAL mit der 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. 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, gibt adb den Fehler „adb: more than one device/emulator“ (adb: mehr als ein Gerät/Emulator) aus.

Wenn mehrere Geräte verfügbar sind, aber nur eines ein Emulator ist, verwenden Sie die Option -e, um Befehle an den Emulator zu senden. Wenn mehrere Geräte, aber nur ein Hardwaregerät angeschlossen sind, verwenden Sie die Option -d, um Befehle an das Hardwaregerät zu senden.

App installieren

Mit adb können Sie eine APK auf einem Emulator oder verbundenen Gerät mit dem Befehl install installieren:

adb install path_to_apk

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

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

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

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

Portweiterleitung einrichten

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

adb forward tcp:6100 tcp:7100

Im folgenden Beispiel wird die Weiterleitung 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 Systemprotokollierungs-Daemon geschrieben und in den Geräteprotokollen angezeigt.

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

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

So kopieren Sie eine Datei oder ein Verzeichnis und die zugehörigen Unterverzeichnisse vom Gerät: 

adb pull remote local

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

adb push local remote

Ersetzen Sie local und remote durch die Pfade zu den Zieldateien bzw. dem Zielverzeichnis auf Ihrer Entwicklungsmaschine (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 neu starten, indem Sie einen beliebigen anderen adb-Befehl ausführen.

ADB-Befehle ausführen

Geben Sie adb-Befehle über die Befehlszeile auf Ihrer Entwicklungsmaschine oder über ein Skript mit den folgenden Optionen aus: 

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

Wenn nur ein Emulator ausgeführt wird oder nur ein Gerät verbunden ist, wird der Befehl adb standardmäßig an dieses Gerät gesendet. Wenn mehrere Emulatoren ausgeführt werden und/oder mehrere Geräte angeschlossen sind, müssen Sie mit der Option -d, -e oder -s das Zielgerät angeben, an das der Befehl gesendet werden soll.

Eine detaillierte Liste aller unterstützten adb-Befehle können Sie mit dem folgenden Befehl aufrufen:

adb --help

Shell-Befehle ausführen

Mit dem Befehl shell können Sie Gerätebefehle über adb ausführen oder eine interaktive Shell starten. 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 mit dem Befehl shell:

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

Wenn Sie eine interaktive Shell beenden möchten, drücken Sie Control+D oder geben Sie exit ein.

Android bietet die meisten der üblichen Unix-Befehlszeilentools. Eine Liste der verfügbaren Tools erhalten Sie mit dem folgenden Befehl:

adb shell ls /system/bin

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

In Android Platform Tools 23 und höher werden Argumente von adb genauso verarbeitet wie vom Befehl ssh(1). Durch diese Änderung wurden viele Probleme mit Command Injection behoben und es ist möglich, Befehle, die Shell-Metazeichen wie adb install Let\'sGo.apk enthalten, sicher auszuführen. Diese Änderung hat auch die Interpretation von Befehlen mit Shell-Metazeichen geändert.

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

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

Anrufaktivitätsmanager

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

In einer Shell lautet die am-Syntax so:

am command

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

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

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

Befehl Beschreibung
start [options] intent Starte eine Activity, die von intent angegeben wird.

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

Es gibt folgende Optionen:

  • -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 das Profiling wird beendet, wenn die App in den Leerlauf geht.
  • -R count: Wiederhole den Start der Aktivität count-mal. Vor jeder Wiederholung wird die oberste Aktivität beendet.
  • -S: Erzwingen Sie das Beenden der Ziel-App, bevor Sie die Aktivität starten.
  • --opengl-trace: Aktiviert das Tracing von OpenGL-Funktionen.
  • --user user_id | current: Gibt an, als welcher Nutzer die Ausführung erfolgen soll. Wenn nicht angegeben, wird der aktuelle Nutzer verwendet.
startservice [options] intent Startet die Service, die durch intent angegeben wird.

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

Es gibt folgende Optionen:

  • --user user_id | current: Gibt an, als welcher Nutzer die Ausführung erfolgen soll. Wenn nicht angegeben, wird die Ausführung als aktueller Nutzer durchgeführt.
force-stop package Erzwingen Sie das Beenden aller Prozesse, die mit package zusammenhängen.
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: Gibt an, welche Nutzerprozesse 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]: Gibt an, an welchen Nutzer die Nachricht gesendet werden soll. Falls nicht angegeben, wird die Nachricht an alle Nutzer gesendet.
instrument [options] component Beginnen Sie mit der Überwachung mit einer Instrumentation-Instanz. Normalerweise hat das Ziel component die Form test_package/runner_class.

Es gibt folgende Optionen:

  • -r: Rohdaten ausgeben (andernfalls report_key_streamresult). Mit [-e perf true] verwenden, um Rohdaten für Leistungsmessungen zu generieren.
  • -e name value: Setzen Sie das Argument name auf value. Für Test-Runner ist eine gängige Form -e testrunner_flag value[,value...].
  • -p file: Profildaten in file schreiben.
  • -w: Warten, bis die Instrumentierung abgeschlossen ist, bevor zurückgegeben wird. Für Test-Runner erforderlich.
  • --no-window-animation: Deaktiviert Fensteranimationen während der Ausführung.
  • --user user_id | current: Gibt an, für welchen Nutzer die Nutzerinstrumentierung ausgeführt wird. Wenn nicht angegeben, wird die Ausführung für den aktuellen Nutzer durchgeführt.
profile start process file Profiler auf process starten, Ergebnisse in file schreiben.
profile stop process Profiler auf process beenden.
dumpheap [options] process file Heap von process sichern und in file schreiben.

Es gibt folgende Optionen:

  • --user [user_id | current]: Wenn Sie einen Prozessnamen angeben, geben Sie den Nutzer des zu sichernden Prozesses an. Wenn nicht angegeben, wird der aktuelle Nutzer verwendet.
  • -b [| png | jpg | webp]: Bitmaps aus dem Grafikspeicher ausgeben (API-Level 35 und höher). Optional können Sie das Format angeben, in das der Dump erfolgen soll (standardmäßig PNG).
  • -n: Nativen Heap anstelle des verwalteten Heaps ausgeben.
dumpbitmaps [options] [-p process] Bitmap-Informationen aus process auslesen (API-Level 36 und höher).

Es gibt folgende Optionen:

  • -d|--dump [format]: Gibt an, dass der Inhalt der Bitmap in der angegebenen format ausgegeben wird. format kann png, jpg oder webp sein. Wenn nichts angegeben ist, wird standardmäßig png verwendet. Eine ZIP-Datei dumpbitmaps-<time>.zip wird mit den Bitmaps erstellt.
  • -p process: Bitmaps aus process ausgeben. Es können mehrere -p process angegeben werden.
Wenn kein process angegeben ist, werden Bitmaps aus allen Prozessen ausgegeben.
set-debug-app [options] package Legen Sie die App package für das Debugging fest.

Es gibt folgende Optionen:

  • -w: Beim Start der App auf den Debugger warten.
  • --persistent: Behalten Sie diesen Wert bei.
clear-debug-app Löschen Sie das Paket, das zuvor mit set-debug-app für das Debugging festgelegt wurde.
monitor [options] Mit dem Monitoring von Abstürzen oder ANRs beginnen

Es gibt folgende Optionen:

  • --gdb: Startet gdbserv auf dem angegebenen Port bei einem Absturz/ANR-Fehler.
screen-compat {on | off} package Steuern Sie den Bildschirmkompatibilitätsmodus von package.
display-size [reset | widthxheight] Anzeigegröße des Geräts überschreiben Dieser Befehl ist hilfreich, um Ihre App auf Geräten mit unterschiedlichen Bildschirmgrößen zu testen. Sie können damit auf einem Gerät mit großem Bildschirm eine niedrige Bildschirmauflösung simulieren und umgekehrt.

Beispiel:
am display-size 1280x800

display-density dpi Gerätekompaktheitsgrad überschreiben Dieser Befehl ist hilfreich, um Ihre App bei verschiedenen Bildschirmdichten zu testen, indem Sie eine Umgebung mit hoher Dichte auf einem Bildschirm mit niedriger Dichte simulieren und umgekehrt.

Beispiel:
am display-density 480

to-uri intent Gibt die angegebene Intention als URI aus.

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

to-intent-uri intent Gibt die angegebene Intent-Spezifikation als intent:-URI aus.

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

Spezifikation für Intent-Argumente

Für Befehle des Activity Managers, die ein intent-Argument verwenden, können Sie die Intention mit den folgenden Optionen angeben:

Paketmanager aufrufen (pm)

In einer adb-Shell können Sie mit dem Paketverwaltungstool (pm) Befehle ausführen, um Aktionen und Abfragen für auf dem Gerät installierte App-Pakete durchzuführen.

In einer Shell lautet die pm-Syntax so:

pm command

Sie können auch einen Paketmanagerbefehl direkt über adb ausführen, ohne eine Remote-Shell zu öffnen. Beispiel:

adb shell pm uninstall com.example.MyApp

Tabelle 2: Verfügbare Paketmanager-Befehle

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

Optionen:

  • -f: Siehe zugehörige Datei.
  • -d: Filtert, um nur deaktivierte Pakete anzuzeigen.
  • -e: Filter, um nur aktivierte Pakete zu zeigen.
  • -s: Filtert, um nur Systempakete anzuzeigen.
  • -3: Filtert, um nur Drittanbieterpakete zu zeigen.
  • -i: Weitere Informationen finden Sie im Installationsprogramm für die Pakete.
  • -u: Nicht installierte Pakete einbeziehen.
  • --user user_id: Der Nutzerbereich, der abgefragt werden soll.
list permission-groups Alle bekannten Berechtigungsgruppen ausgeben.
list permissions [options] group Alle bekannten Berechtigungen ausgeben, optional nur die in group.

Optionen:

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

Optionen:

  • -f: Listet die APK-Datei für das Testpaket auf.
  • target_package: Nur Testpakete für diese App auflisten.
list features Geben Sie alle Funktionen des Systems aus.
list libraries Gibt alle vom aktuellen Gerät unterstützten Bibliotheken aus.
list users Alle Nutzer im System ausgeben.
path package Gibt den Pfad zur APK-Datei des angegebenen package aus.
install [options] path Installiert ein durch path angegebenes Paket auf dem System.

Optionen:

  • -r: Eine vorhandene App neu installieren und die Daten beibehalten.
  • -t: Ermöglicht die Installation von Test-APKs. Gradle generiert ein Test-APK, wenn Sie Ihre App nur ausgeführt oder debuggt haben oder den Befehl Build > Build APK (Build > APK erstellen) in Android Studio verwendet haben. Wenn das APK mit einem Developer Preview-SDK erstellt wurde, müssen Sie die Option -t mit dem Befehl install angeben, wenn Sie ein Test-APK installieren.
  • -i installer_package_name: Geben Sie den Namen des Installationspakets an.
  • --user user_id: Geben Sie den Nutzer an, für den das Paket installiert werden soll. Standardmäßig wird das Paket für alle Nutzer installiert, die auf dem Gerät vorhanden sind.
  • --install-location location: Legen Sie den Installationsort mit einem der folgenden Werte fest:
    • 0: Standardinstallationsort verwenden.
    • 1: Auf dem internen Gerätespeicher installieren.
    • 2: Auf externen Medien installieren.
  • -f: Installiert das Paket im internen Systemspeicher.
  • -d: Downgrade des Versionscodes zulassen.
  • -g: Gewährt alle im App-Manifest aufgeführten Berechtigungen.
  • --fastdeploy: Ein installiertes Paket kann schnell aktualisiert werden, indem nur die Teile des APK aktualisiert werden, die sich geändert haben.
  • --incremental: Es wird so viel vom APK installiert, dass die App gestartet werden kann, während die verbleibenden Daten im Hintergrund gestreamt werden. Wenn Sie diese Funktion verwenden möchten, müssen Sie das APK signieren, eine APK-Signaturschema v4-Datei erstellen und diese Datei in dasselbe Verzeichnis wie das APK einfügen. Diese Funktion wird nur auf bestimmten Geräten unterstützt. Mit dieser Option wird adb gezwungen, die Funktion zu verwenden. Wenn sie nicht unterstützt wird, wird ein Fehler mit ausführlichen Informationen dazu ausgegeben, warum der Vorgang fehlgeschlagen ist. Hängen Sie die Option --wait an, um zu warten, bis das APK vollständig installiert ist, bevor Sie den Zugriff auf das APK gewähren.

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

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

Optionen:

  • -k: Behält die Daten- und Cacheverzeichnisse nach dem Entfernen des Pakets bei.
  • --user user_id: Gibt den Nutzer an, für den das Paket entfernt wird. Standardmäßig wird das Paket für alle Nutzer auf dem Gerät entfernt.
  • --versionCode version_code: Die App wird nur deinstalliert, wenn sie den angegebenen Versionscode hat.
clear package Löschen Sie alle Daten, die mit einem Paket verknüpft sind.
enable package_or_component Aktivieren Sie das angegebene Paket oder die angegebene Komponente (als „Paket/Klasse“ geschrieben).
disable package_or_component Deaktivieren Sie das angegebene Paket oder die angegebene Komponente (im Format „Paket/Klasse“).
disable-user [options] package_or_component

Optionen:

  • --user user_id: Der Nutzer, der deaktiviert werden soll.
grant package_name permission Erteilt einer App eine Berechtigung. Auf Geräten mit Android 6.0 (API-Level 23) und höher kann die Berechtigung eine beliebige Berechtigung sein, die im App-Manifest deklariert ist. Auf Geräten mit Android 5.1 (API-Level 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 um eine beliebige Berechtigung handeln, die im App-Manifest deklariert ist. 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: Auf dem internen Gerätespeicher installieren.
  • 2: Extern: Auf externen Medien installieren.

Hinweis:Diese Funktion ist nur für die Fehlerbehebung vorgesehen. Die Verwendung kann dazu führen, dass Apps nicht mehr funktionieren und andere unerwünschte Verhaltensweisen auftreten.
get-install-location Gibt den aktuellen Installationsort zurück. Rückgabewerte:
  • 0 [auto]: System den besten Standort auswählen lassen
  • 1 [internal]: Auf dem 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 Löschen Sie Cache-Dateien, um den angegebenen freien Speicherplatz zu erreichen.
create-user user_name Erstelle einen neuen Nutzer mit dem angegebenen user_name und gib die neue Nutzer-ID des Nutzers aus.
remove-user user_id Entfernen Sie den Nutzer mit der angegebenen user_id und löschen Sie alle mit diesem Nutzer verknüpften Daten.
get-max-users Gibt die maximale Anzahl von Nutzern aus, die vom Gerät unterstützt werden.
get-app-links [options] [package]

Gibt den Status der Domainbestätigung für die angegebene package oder für alle Pakete aus, wenn keine angegeben ist. Die Bundesstaatscodes sind so definiert:

  • none: Für diese Domain wurden keine Daten aufgezeichnet.
  • verified: Die Domain wurde bestätigt.
  • approved: Erzwingen der Genehmigung, in der Regel über die Shell
  • denied: Erzwingen des Ablehnens, in der Regel über die Shell
  • migrated: beibehaltene Bestätigung aus einer alten Antwort
  • restored: Bei der Wiederherstellung von Nutzerdaten wird die Bestätigung beibehalten.
  • legacy_failure: Von einem Legacy-Prüftool abgelehnt, unbekannter Grund
  • system_configured: automatisch durch die Gerätekonfiguration genehmigt
  • >= 1024: benutzerdefinierter Fehlercode, der für die Geräteüberprüfung spezifisch ist

Es gibt folgende Optionen:

  • --user user_id: Schließen Sie Nutzerauswahlen ein. Schließen Sie alle Domains ein, nicht nur die, die automatisch überprüft werden.
reset-app-links [options] [package]

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

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

Es gibt folgende Optionen:

  • --user user_id: Schließen Sie Nutzerauswahlen ein. Schließen Sie alle Domains ein, nicht nur die, die automatisch überprüft werden.
verify-app-links [--re-verify] [package]

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

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

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

  • --package package: Das Paket, das festgelegt werden soll, oder „all“, um alle Pakete festzulegen
  • state: Der Code, mit dem die Domains festgelegt werden sollen. Gültige Werte sind:
    • STATE_NO_RESPONSE (0): Zurücksetzen, als ob nie eine Antwort aufgezeichnet wurde.
    • STATE_SUCCESS (1): Die Domain wird so behandelt, als ob sie vom Domainbestätigungs-Agent bestätigt wurde. Der Domainbestätigungs-Agent kann dies jedoch überschreiben.
    • STATE_APPROVED (2): Die Domain wird immer als genehmigt behandelt. Der Domainbestätigungs-Agent kann sie nicht ändern.
    • STATE_DENIED (3): Die Domain wird immer als abgelehnt behandelt. So wird verhindert, dass der Agent zur Domainbestätigung sie ändert.
  • domains: Eine durch Leerzeichen getrennte Liste der zu ändernden Domains oder „all“, um alle Domains zu ändern.
set-app-links-user-selection --user user_id [--package package] enabled domains

Hiermit wird der Status einer Auswahl des Hostnutzers für ein Paket manuell festgelegt. Die Domain muss vom Paket deklariert werden, damit dies funktioniert. Bei Domains, die nicht angewendet werden konnten, wird mit diesem Befehl kein Fehler gemeldet.

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

Sie können die Einstellung für die automatische Überprüfung der Linkbearbeitung für ein Paket aktivieren oder deaktivieren.

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

Gibt die Inhaber einer bestimmten Domain für einen bestimmten Nutzer in der Reihenfolge von niedriger bis hoher Priorität aus.

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

Geräterichtlinienmanager aufrufen (dpm)

Um Ihnen die Entwicklung und das Testen Ihrer Geräteverwaltungs-Apps zu erleichtern, können Sie Befehle an das Tool für den Geräte-Policy-Manager (dpm) senden. 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 so:

dpm command

Sie können auch einen Befehl des Gerätepolicy-Managers direkt über adb ausgeben, ohne eine Remote-Shell zu öffnen:

adb shell dpm command

Tabelle 3 Verfügbare Device Policy Manager-Befehle

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

Es gibt folgende Optionen:

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

Es gibt folgende Optionen:

  • --user user_id: Gibt den Zielnutzer an. Sie können auch --user current übergeben, um den aktuellen Nutzer auszuwählen.
  • --name name: Geben Sie den für Menschen lesbaren Organisationsnamen 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: Gibt den Zielnutzer an. Sie können auch --user current übergeben, um den aktuellen Nutzer auszuwählen.
  • --name name: Geben Sie den für Menschen lesbaren Organisationsnamen an.
remove-active-admin [options] component Aktiven Administrator deaktivieren 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: Gibt den Zielnutzer an. Sie können auch --user current übergeben, um den aktuellen Nutzer auszuwählen.
clear-freeze-period-record Löschen Sie den Datensatz des Geräts mit zuvor festgelegten Einfrierzeiträumen für OTA-Systemupdates. Das ist nützlich, um die Einschränkungen bei der Geräteplanung zu umgehen, wenn Sie Apps entwickeln, die Sperrzeiten verwalten. Weitere Informationen

Wird auf Geräten mit Android 9.0 (API-Level 28) und höher unterstützt.
force-network-logs Erzwingt, dass das System alle vorhandenen Netzwerkprotokolle für den Abruf durch einen Geräteinhaber bereitstellt. Wenn Verbindungs- oder DNS-Protokolle verfügbar sind, erhält der Geräteinhaber den onNetworkLogsAvailable()-Callback. Weitere Informationen finden Sie unter Netzwerkaktivitätsprotokollierung.

Für diesen Befehl gilt eine Ratenbegrenzung. Wird auf Geräten mit Android 9.0 (API-Level 28) und höher unterstützt.
force-security-logs Erzwingt, dass das System alle vorhandenen Sicherheitslogs für den DPC verfügbar macht. Wenn Logs verfügbar sind, empfängt der DPC den onSecurityLogsAvailable()-Callback. Weitere Informationen finden Sie unter Aktivitäten auf Unternehmensgeräten protokollieren.

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

Screenshot erstellen

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

In einer Shell lautet die screencap-Syntax: 

screencap filename

Geben Sie Folgendes ein, um screencap über die Befehlszeile zu verwenden: 

adb shell screencap /sdcard/screen.png

Hier sehen Sie ein Beispiel für eine Screenshot-Sitzung, in der die adb-Shell zum Erstellen des Screenshots und der Befehl pull zum Herunterladen der Datei vom Gerät verwendet werden:

$ adb shell
shell@ $ screencap /sdcard/screen.png
shell@ $ exit
$ adb pull /sdcard/screen.png

Wenn Sie den Dateinamen weglassen, schreibt screencap das Bild in die Standardausgabe. In Kombination mit der Option -p zum Angeben des PNG-Formats können Sie den Gerätescreenshot direkt in eine Datei auf Ihrem lokalen Computer streamen.

Hier ist ein Beispiel dafür, wie Sie mit einem einzigen Befehl einen Screenshot aufnehmen und lokal speichern:

# use 'exec-out' instead of 'shell' to get raw data
$ adb exec-out screencap -p > screen.png

Nimm ein Video auf

Der Befehl screenrecord ist ein Shell-Dienstprogramm zum Aufzeichnen des Displays von Geräten mit Android 4.4 (API-Level 19) und höher. Das Dienstprogramm zeichnet Bildschirmaktivitäten in einer MPEG‑4-Datei auf. Sie können diese Datei verwenden, um Werbe- oder Schulungsvideos zu erstellen oder um Fehler zu beheben und Tests durchzuführen.

Verwenden Sie in einer Shell die folgende Syntax:

screenrecord [options] filename

Geben Sie Folgendes ein, um screenrecord über die Befehlszeile zu verwenden: 

adb shell screenrecord /sdcard/demo.mp4

Beenden Sie die Bildschirmaufzeichnung, indem Sie Strg+C drücken. Andernfalls wird die Aufzeichnung nach drei Minuten oder nach dem von --time-limit festgelegten Zeitlimit automatisch beendet.

Führen Sie zuerst den Befehl screenrecord aus, um die Aufzeichnung des Gerätebildschirms zu starten. 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

Mit dem Tool screenrecord können Sie in jeder unterstützten Auflösung und Bitrate aufnehmen, die Sie anfordern, wobei das Seitenverhältnis des Gerätedisplays beibehalten wird. Das Tool zeichnet standardmäßig in der nativen Bildschirmauflösung und -ausrichtung auf. Die maximale Länge beträgt drei Minuten.

Einschränkungen des screenrecord-Tools:

  • Die Videodatei enthält keinen Ton.
  • Die Videoaufzeichnung ist für Geräte mit Wear OS nicht verfügbar.
  • Einige Geräte können möglicherweise nicht in ihrer nativen Displayauflösung aufzeichnen. Wenn Probleme bei der Bildschirmaufzeichnung auftreten, versuchen Sie, eine niedrigere Bildschirmauflösung zu verwenden.
  • Das Drehen des Bildschirms während der Aufnahme wird nicht unterstützt. Wenn sich das Display während der Aufnahme dreht, wird ein Teil des Bildschirms in der Aufnahme abgeschnitten.

Tabelle 4: screenrecord-Optionen

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

ART-Profile für Apps lesen

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

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

Verwenden Sie den folgenden Befehl, um eine Textform der Profilinformationen zu erstellen:

adb shell cmd package dump-profiles package

So rufen Sie die erstellte Datei ab:

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

Testgeräte zurücksetzen

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

adb shell cmd testharness enable

Wenn das Gerät mit testharness wiederhergestellt wird, wird der RSA-Schlüssel, der das Debugging über die aktuelle Arbeitsstation ermöglicht, automatisch an einem persistenten Speicherort gesichert. Das heißt, nachdem das Gerät zurückgesetzt wurde, kann die Workstation weiterhin debuggen und adb-Befehle an das Gerät senden, ohne dass ein neuer Schlüssel manuell registriert werden muss.

Außerdem werden durch die Verwendung von testharness zum Wiederherstellen eines Geräts auch die folgenden Geräteeinstellungen geändert, um das Testen Ihrer App zu vereinfachen und sicherer zu machen:

  • Das Gerät richtet bestimmte Systemeinstellungen so ein, dass keine Assistenten für die Ersteinrichtung des Geräts angezeigt werden. Das Gerät wechselt also in einen Zustand, in dem Sie Ihre App schnell installieren, debuggen und testen können.
  • Einstellungen:
    • Deaktiviert den Sperrbildschirm.
    • Deaktiviert Warnmeldungen.
    • Deaktiviert die automatische Synchronisierung für Konten.
    • Deaktiviert automatische Systemupdates.
  • Sonstiges:
    • Deaktiviert vorinstallierte Sicherheits-Apps.

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

sqlite

Mit sqlite3 wird das sqlite-Befehlszeilenprogramm zum Untersuchen von SQLite-Datenbanken gestartet. Es enthält Befehle wie .dump zum Ausgeben des Inhalts einer Tabelle und .schema zum Ausgeben der SQL CREATE-Anweisung für eine vorhandene Tabelle. Sie können auch SQLite-Befehle über die Befehlszeile ausführen, wie unten gezeigt:

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

Hinweis:Auf eine SQLite-Datenbank kann nur zugegriffen werden, wenn Sie Root-Zugriff auf das Dateisystem haben, z. B. auf einem Emulator.

Weitere Informationen finden Sie in der sqlite3-Befehlszeilendokumentation.

adb-USB-Back-Ends

Der ADB-Server kann über zwei Backends mit dem USB-Stack interagieren. Es kann entweder das native Backend des Betriebssystems (Windows, Linux oder macOS) oder das libusb-Backend verwendet werden. Einige Funktionen wie attach, detach und die Erkennung der USB-Geschwindigkeit sind nur verfügbar, wenn das libusb-Backend verwendet wird.

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

adb-mDNS-Back-Ends

ADB verwendet das mDNS-Protokoll (Multicast DNS), um den Server und die Geräte für das drahtlose Debugging automatisch zu verbinden. Ab ADB v37 wird der ADB-Server mit zwei mDNS-Backends ausgeliefert: libadbmdns und openscreen.

Das Standard- und empfohlene Backend ist libadbmdns. Dieses Verhalten kann mit der Umgebungsvariable ADB_MDNS_OPENSCREEN (auf 1 oder 0 festgelegt) geändert werden. Die Unterstützung für das Openscreen-Back-End auf macOS beginnt mit ADB v35. Windows und Linux werden ab ADB v34 unterstützt.

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 reagiert hat. Dadurch wird der Durchsatz von ADB beim Übertragen großer Dateien erheblich erhöht und die Latenz beim Debuggen verringert.

Der Serienbildmodus ist standardmäßig deaktiviert. Führen Sie einen der folgenden Schritte aus, um das Feature zu aktivieren:

  • Setzen Sie die Umgebungsvariable ADB_BURST_MODE auf 1.
  • 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 Mode auf Aktiviert fest.