Platform-Tools und Verbindung am Computer vorbereiten
ADB, die Android Debug Bridge, verbindet ein Befehlsprogramm auf dem Computer mit einem Dienst auf dem Android-Gerät. Für alltägliche Aufgaben genügt das offizielle Paket Android SDK Platform-Tools; die vollständige Entwicklungsumgebung Android Studio ist dafür nicht erforderlich. Nach dem Entpacken wird ein Terminal im entsprechenden Ordner geöffnet. Fremde Sammelpakete aus Foren sind für diese Grundfunktionen nicht nötig.
Die folgenden Befehle setzen voraus, dass das Programm als „adb“ aufrufbar ist, etwa über den Suchpfad des Betriebssystems. Liegt es nur im aktuellen Ordner, ist unter macOS und Linux häufig „./adb“ erforderlich, in Windows PowerShell „.\adb.exe“. Diese Schreibweisen bestimmen lediglich, welches lokale Programm startet. Ein Fehler wie „Befehl nicht gefunden“ liegt zunächst am Computer und sagt noch nichts über das angeschlossene Handy aus.
Windows kann für die ADB-Schnittstelle einen passenden USB-Treiber des Geräteherstellers benötigen. Der Google-USB-Treiber ist nicht automatisch der richtige Treiber für jedes Fabrikat. macOS benötigt normalerweise keinen zusätzlichen ADB-USB-Treiber. Unter Linux können passende udev-Regeln und Benutzerrechte erforderlich sein; die Einrichtung hängt von der Distribution ab. ADB pauschal als Administrator auszuführen ersetzt keine saubere Treiber- oder Rechtekonfiguration.
Ein funktionierendes Datenkabel bleibt Voraussetzung. Dass ein Handy lädt oder über MTP Dateien anzeigt, beweist nicht, dass auch die getrennte ADB-Schnittstelle korrekt eingerichtet ist. Für die Fehlersuche sollten zunächst nur ein Handy und keine unnötigen Emulatoren verbunden sein. So bleibt eindeutig, auf welches Ziel die Befehle wirken.
Entwickleroptionen und USB-Debugging freigeben
Die Entwickleroptionen werden auf vielen Geräten durch wiederholtes Antippen der Build-Nummer in den Geräteinformationen sichtbar. Ort und Bezeichnung variieren nach Hersteller; gegebenenfalls ist die Displaysperre zu bestätigen. Innerhalb dieses Bereichs lässt sich USB-Debugging einschalten. Andere Optionen sind für die grundlegende ADB-Verbindung nicht erforderlich. Insbesondere die OEM-Entsperrung hat einen anderen Zweck und muss dafür nicht aktiviert werden.
Nach dem Anschließen erscheint auf dem entsperrten Handy normalerweise eine Anfrage, ob der Debugging-Schlüssel dieses Computers akzeptiert werden soll. Diese Bestätigung erlaubt dem Rechner die ADB-Kommunikation. Der angebotene dauerhafte Vertrauensstatus sollte nur für einen kontrollierten eigenen Computer verwendet werden. Eine unerwartete Anfrage an einem fremden Anschluss ist kein notwendiger Bestandteil des gewöhnlichen Ladens.
Fehlt der Dialog, sind zunächst die USB-Verbindung und der eingeschaltete Debugging-Modus zu prüfen. Bereits bestätigte Computer können ohne erneute Anfrage erkannt werden. Die Entwickleroptionen bieten auf vielen Geräten auch das Widerrufen früherer USB-Debugging-Autorisierungen; die Bezeichnung unterscheidet sich. Danach muss eine gewünschte Verbindung erneut bestätigt werden. Ein gesperrtes oder nicht mehr bedienbares Display lässt sich durch erstmaliges Anschließen von ADB nicht einfach umgehen.
Fünf Befehle für überschaubare Aufgaben
adb devices listet erreichbare Geräte mit ihrer Kennung und ihrem Verbindungszustand auf. „device“ kennzeichnet eine grundsätzlich verfügbare ADB-Verbindung, während „unauthorized“ meist auf die noch fehlende Bestätigung am Handy verweist. Eine leere Liste lenkt die Fehlersuche auf Kabel, Treiber, Rechte oder Debugging. Der Befehl zeigt allerdings nicht, ob Android bereits vollständig gestartet und jede App einsatzbereit ist.
adb pull /sdcard/Download/beispiel.pdf . kopiert eine vorhandene Datei vom Handy in den aktuellen Ordner des Computers. Der Dateiname ist ein Beispiel und muss zur tatsächlichen Quelldatei passen. Der Punkt bezeichnet hier das lokale Zielverzeichnis. Der Pfad „/sdcard“ meint auf üblichen Geräten den gemeinsam nutzbaren Speicher des betreffenden Nutzers und nicht zwingend eine eingelegte Speicherkarte.
adb push beispiel.pdf /sdcard/Download/ arbeitet in Gegenrichtung. Die lokale Datei wird in den genannten, bereits vorhandenen Zielordner kopiert. Pfade mit Leerzeichen benötigen geeignete Anführungszeichen. Eine gleichnamige Zieldatei kann überschrieben werden, weshalb eindeutige Namen sinnvoll sind. Beide Kopierbefehle unterliegen den Zugriffsrechten des ADB-Dienstes und öffnen nicht automatisch den privaten Speicher anderer Apps.
adb install beispiel.apk installiert ein vorhandenes APK-Paket vom Computer. Die Herkunft der Datei muss vorher geklärt sein, denn ADB bewertet die Vertrauenswürdigkeit ihres Inhalts nicht. Architektur, Systemanforderungen und gegebenenfalls vorhandene Signaturen müssen passen. Eine einzelne APK reicht außerdem nicht für jede App-Verteilung aus: Manche Anwendungen bestehen aus mehreren zusammengehörigen Paketen und lassen sich mit diesem einfachen Beispiel nicht vollständig installieren.
adb logcat -d gibt die erreichbaren Diagnosemeldungen aus den ausgewählten Standardpuffern aus und beendet die Ausgabe anschließend. Darin können Hinweise auf Abstürze stehen, aber auch harmlose Warnungen. Nicht jede Fehlermeldung erklärt das beobachtete Problem. Vor der Weitergabe muss das Protokoll auf persönliche Inhalte geprüft werden; Umfang und Sichtbarkeit hängen von Android-Version, Gerät und Berechtigungen ab.
Warum ADB keine Root-Rechte und kein Vollbackup liefert
ADB arbeitet auf einem gewöhnlichen Seriengerät mit begrenzten Systemrechten. Diese gehen für manche Aufgaben über die Möglichkeiten einer normalen App hinaus, sind aber keine uneingeschränkten Root-Rechte. Root bezeichnet einen besonders privilegierten Systemzugriff. Private App-Verzeichnisse, geschützte Systembereiche und bestimmte Geräteeinstellungen bleiben deshalb auch bei einer erfolgreich bestätigten ADB-Verbindung unzugänglich oder nur eingeschränkt nutzbar.
Eine Fehlermeldung wie „Permission denied“ kann genau diese Grenze ausdrücken. Dann helfen weder wiederholtes Kopieren noch eine zusätzliche Freigabe des Computers. Bei eigenen Entwicklungs-Apps oder besonderen Testsystemen können andere Regeln gelten; daraus lässt sich keine allgemeine Anleitung für jedes Serienhandy ableiten. Ebenso ist das Entsperren des Bootloaders ein separater Vorgang mit eigenem Risiko und keine Voraussetzung für die beschriebenen Befehle.
Auch eine Dateikopie per ADB ist kein vollständiges Android-Backup. Sie enthält nur die erreichbaren und tatsächlich ausgewählten Inhalte. Kontozugänge, App-Datenbanken und gerätegebundene Schlüssel werden damit nicht allgemein gesichert. Alte Anleitungen zu pauschalen ADB-Backups sind ebenfalls keine verlässliche Zusage vollständiger Wiederherstellung auf heutigen Geräten. Für wichtige App-Inhalte bleiben die vorgesehenen Export-, Synchronisations- oder Sicherungsfunktionen maßgeblich.
Debugging nach der Arbeit wieder begrenzen
Ein autorisierter Computer erhält über ADB Zugriff auf mehr Funktionen als beim bloßen Laden. Er kann beispielsweise die beschriebenen Installationen und Dateizugriffe ausführen, soweit das Gerät sie erlaubt. Dauerhaft aktiviertes USB-Debugging ist deshalb besonders dann riskant, wenn ein bereits vertrauter Rechner später von anderen Personen kontrolliert wird. Die einmalige Freigabe sollte als Zugangsentscheidung behandelt werden und nicht als belangloser Anschlussdialog.
Nach Abschluss der Arbeit lässt sich USB-Debugging wieder ausschalten. Wird ein Rechner nicht mehr benötigt oder ist seine Vertrauenswürdigkeit unklar, können zusätzlich die gespeicherten Autorisierungen widerrufen werden. Das bloße Abziehen des Kabels beendet zwar die aktuelle Kabelverbindung, entfernt aber nicht automatisch deren Vertrauensstatus. Auch das Sperren des Displays sollte nicht als sicherer Ersatz für den Widerruf vorausgesetzt werden.
Drahtloses Debugging ist eine weitere, getrennt zu prüfende Verbindungsmöglichkeit. Verfügbarkeit und Kopplungsverfahren hängen vom System ab. Für gelegentliche USB-Aufgaben ist es nicht notwendig. Nach einer Nutzung sollten auch dessen aktivierte Verbindung und gespeicherte Kopplungen kontrolliert werden. Wenn ein Befehl aus einer fremden Anleitung über die beschriebenen Kopier- und Diagnoseaufgaben hinausgeht, müssen Ziel, Wirkung und mögliche Rücknahme vor der Ausführung verständlich sein.