droid.rooter
AnleitungenFortgeschritten10 Min. Lesezeit

ADB per WLAN unter Android 17: Koppeln, automatische Wiederverbindung und weiter gültige Lösungen

Koppeln und Verbinden sind zwei verschiedene Schritte. Dieser Guide erklärt ADB Wi-Fi 2.0, die zwei Ports, die aktuellen Platform Tools und eine sicherere Reihenfolge bei der Fehlersuche.

Wireless ADB on Android 17: Pairing, Auto-Reconnect and the Fixes That Still Apply
Inhaltsverzeichnis
  1. Wisse, welche Methode für kabelloses ADB du nutzt
  2. Prüfe das ADB, das wirklich läuft
  3. Warum manche beliebten mDNS-Lösungen überholt sind
  4. Handy und Computer koppeln
  5. Kopplungsport und Verbindungsport sind verschieden
  6. Was ein „vertrauenswürdiges Netzwerk“ bedeutet
  7. Gekoppelt, aber nicht verbunden: diese Prüfungen helfen
  8. 1. Aktuelle Adresse und Verbindungsport prüfen
  9. 2. Den laufenden Server prüfen
  10. 3. Die Diensterkennung untersuchen
  11. 4. Das Netzwerk prüfen, ohne es zu schwächen
  12. „More than one device“ ist ein Auswahlproblem
  13. Funktionierendes kabelloses ADB heißt nicht, dass Shizuku immer läuft
  14. Trennen ist nicht dasselbe wie Zugriff entziehen
  15. Ein brauchbarer Fehlerbericht zu kabellosem ADB
  16. Häufige Fragen
  17. Brauche ich unter Android 17 ein USB-Kabel zum Koppeln?
  18. Warum meldet ADB „gekoppelt“, obwohl die Geräteliste leer ist?
  19. Funktioniert ADB Wi-Fi 2.0 auf jedem älteren Android-Handy?
  20. Soll ich ADB_MDNS_OPENSCREEN=0 setzen?
  21. Soll ich Port 5555 öffnen, um das zu beheben?
  22. Teile die Diagnose in drei Teile
  23. Quellen und Umfang

„Successfully paired“ sollte sich wie das Ende der Einrichtung anfühlen. Stattdessen führst du adb devices aus und siehst nichts.

Meist schickt das zurück zum Kopplungsbildschirm: neuen Code erzeugen, denselben Befehl wiederholen, dasselbe Ergebnis. Es fehlt die Unterscheidung: Beim Koppeln entsteht Vertrauen, beim Verbinden eine nutzbare Debugging-Verbindung.

Android 17 und ADB 37.0.0 führen ADB Wi-Fi 2.0 ein, darunter automatische Verbindungen, wenn ein gekoppeltes Gerät einem vertrauenswürdigen Netzwerk für kabelloses Debugging beitritt. Ältere Android-Versionen können kabelloses Debugging weiter unterstützen, übernehmen aber nicht jedes Verhalten von Android 17, nur weil das ADB am Computer aktualisiert wurde.Quelle 1

Die folgende Einrichtung nutzt dein eigenes Handy, einen vertrauenswürdigen Computer und ein privates Netzwerk. Sie ist kein Weg, ein Gerät ohne Erlaubnis seines Besitzers zu verwalten.

Wisse, welche Methode für kabelloses ADB du nutzt

Drei verschiedene Situationen werden oft „kabelloses ADB“ genannt:

MethodeSo erkennst du sieDas gilt es zu merken
Modernes Wireless debuggingAndroid-Ablauf mit Kopplungscode oder QR-CodeComputer koppeln und die Verbindungsdaten dieser Sitzung nutzen
Android 17 mit ADB Wi-Fi 2.0Unterstütztes Android-17-Gerät plus ADB 37 oder neuerDas Verhalten bei vertrauenswürdigen Netzwerken kann eine gekoppelte Verbindung automatisch wiederherstellen
Legacy-TCP-ModusAnleitungen mit adb tcpip 5555Das ist nicht der moderne Ablauf mit Kopplung und TLS

Googles Anleitung für Hardware-Geräte warnt ausdrücklich, dass die Legacy-Verbindung über adb tcpip, wie sie fürs Spiegeln genutzt wird, nicht verschlüsselt ist.Quelle 1 Öffne Port 5555 nicht am Router und setze ADB nicht dem öffentlichen Internet aus.

Eine Firewall-Regel, die alles freigibt, ist keine akzeptable Lösung für ein Erkennungsproblem.

Prüfe das ADB, das wirklich läuft

Lade die aktuellen SDK Platform Tools von Google herunter, kein verwaistes „Minimal ADB“-Paket. Führe dann aus:

adb version

Lies die Version-Angabe, nicht nur die vertraute Zeile zur Protokollversion der Android Debug Bridge. Dass du einen Ordner aktualisiert hast, beweist nicht, dass deine Shell oder IDE ihn nutzt.

Unter Windows:

where.exe adb

Unter macOS oder Linux:

command -v adb

Gibt es mehrere Kopien, entscheide, welche Installation deine Tools nutzen sollen. Lösche nicht wahllos fremde SDK-Ordner. Ein direkter Aufruf aus dem vorgesehenen Verzeichnis platform-tools ist ein nützlicher Vergleich.

Laut Googles Release Notes hat Platform Tools 37.0.1 vom Juli 2026 das alte OpenScreen-Backend entfernt. Das Setzen von ADB_MDNS_OPENSCREEN bleibt in dieser Version ohne Wirkung. Aktiv ist die Implementierung libadbmdns.Quelle 3

Eine Anleitung, die jedem Leser rät, diese Variable umzuschalten, wurde womöglich für ein anderes Release geschrieben. Prüfe zuerst die Version. Stapel keine alten Umgebungsvariablen-Workarounds auf eine neue Installation, ohne zu verstehen, ob es sie noch gibt.

Handy und Computer koppeln

Nutze ein vertrauenswürdiges Netzwerk und lass das Handy bei der Einrichtung entsperrt.

Öffne Developer options > Wireless debugging. Erlaube Debugging im Netzwerk nur, wenn du es kontrollierst und ihm vertraust. Wähle die Option mit Kopplungscode und lass diesen Dialog geöffnet.

Nutze am Computer die Adresse und den Kopplungsport aus diesem Dialog:

adb pair PHONE_IP:PAIRING_PORT

Ersetze beide Platzhalter durch die echten Werte und gib auf Nachfrage den angezeigten Code ein. Prüfe danach:

adb devices -l

Das sind die modernen ADB-Prüfungen für Kopplung und Verbindung, wie Google sie dokumentiert.Quelle 2

Poste keinen gültigen Kopplungscode in einem Support-Forum. Koppeln ist eine Autorisierung, nicht nur ein Verbindungstest.

Kopplungsport und Verbindungsport sind verschieden

Erscheint das Handy nach dem Koppeln nicht, geh zurück zur Hauptseite von Wireless debugging. Nutze deren Adresse und Verbindungsport:

adb connect PHONE_IP:CONNECTION_PORT
adb devices -l

Nimm nicht den Port aus dem Kopplungsdialog, nur weil es die zuletzt kopierte Zahl ist. Der Entwickler von Bugjaeger beschreibt diesen Unterschied ebenfalls in seiner Anleitung zur kabellosen Verbindung.Quelle 4

Ein Kopplungsdialog und die Hauptseite können zum Beispiel bei derselben Handy-IP verschiedene Ports zeigen. Das sind Sitzungsdaten, keine festen Zahlen, die du in jeden künftigen Befehl einbauen solltest.

Was ein „vertrauenswürdiges Netzwerk“ bedeutet

Es gibt zwei Entscheidungen: ob du dem Computer vertraust und ob kabelloses Debugging in diesem Netzwerk automatisch erlaubt sein soll.

Googles Anleitung für Android 17 erklärt: Wählst du die Option always-allow für das Netzwerk, wird es ein vertrauenswürdiges Netzwerk für kabelloses Debugging. Ein gekoppelter Computer kann sich dann wieder verbinden, wenn das Gerät in dieses Netzwerk zurückkehrt.Quelle 1

Das ist an deinem Schreibtisch praktisch. Es ist kein Grund, das WLAN im Hotel, am Flughafen oder ein geteiltes öffentliches WLAN dauerhaft zu genehmigen.

Trenne außerdem die Einstellung zum vertrauenswürdigen Netzwerk von der Berechtigung für das lokale Netzwerk auf App-Ebene, die für betroffene Android-17-Apps eingeführt wurde. Die ADB-Einrichtung lässt sich nicht beheben, indem du irgendeiner Medien-App mehr Rechte gibst. Unsere Anleitung zum lokalen Netzwerk unter Android 17 behandelt die Erkennung von TV, Drucker und NAS getrennt.

Gekoppelt, aber nicht verbunden: diese Prüfungen helfen

1. Aktuelle Adresse und Verbindungsport prüfen

Lies sie noch einmal von der Hauptseite von Wireless debugging ab. Verlass dich nicht auf den Screenshot von gestern oder einen gespeicherten Befehl. Versuche dann eine direkte Verbindung zu diesem aktuellen Endpunkt.

Klappt die direkte Verbindung, die automatische Erkennung aber nicht, hast du das Problem deutlich eingegrenzt. Das Koppeln musst du wahrscheinlich nicht als Erstes wiederholen.

2. Den laufenden Server prüfen

Prüfe mit aktuellem ADB:

adb server-status

Googles Dokumentation zur Fehlerbehebung nutzt das, um Serverversion und mDNS-Status zu prüfen. Achte bei der aktuellen Implementierung darauf, dass mDNS aktiviert und das Backend LIBADBMDNS ist.Quelle 2

Ein Client-Binary und ein bereits laufender Server verdienen getrennte Aufmerksamkeit. Starte den Server bei Bedarf aus der vorgesehenen Platform-Tools-Installation neu:

adb kill-server
adb start-server
adb server-status

Das unterbricht andere ADB-Verbindungen an diesem Computer. Sichere vorher laufende Debugging-Arbeit.

Hat deine Umgebung mDNS ausdrücklich deaktiviert, entferne diese Konfiguration oder folge Googles dokumentierter Einstellung ADB_MDNS für deine Shell. Ersetze sie nicht durch die überholte OpenScreen-Variable.Quelle 2Quelle 3

3. Die Diensterkennung untersuchen

Eine nützliche Erkennungsprüfung, die nur liest, ist:

adb mdns services

Vergleiche diese Ausgabe mit einem direkten Verbindungsversuch. Ein leeres Erkennungsergebnis beweist für sich allein nicht, dass die Kopplungsdaten des Handys defekt sind.Quelle 2

Halte die Kombination der Ergebnisse fest:

BeobachtungEin engerer nächster Schritt
Koppeln klappt und direkte Verbindung funktioniert, die automatische Erkennung aber nichtmDNS, den aktiven ADB-Server und die Filter im lokalen Netzwerk prüfen
Koppeln klappt, aber die direkte Verbindung scheitertAktuellen Verbindungsport, Netzwerkpfad und Status von Wireless debugging erneut prüfen
Klappt im privaten Hotspot oder Heimnetz, aber nicht im FirmennetzDen Administrator nach Client-Isolation und erlaubter Erkennung fragen
Ein Computer funktioniert, ein anderer nichtPlatform-tools-Installationen, Serverstatus und Firewall-Regeln des Hosts vergleichen
Klappt, bis du das Netzwerk wechselstNetzwerkvertrauen und Konnektivität des neuen Netzwerks prüfen, statt dauerhaften Zugriff anzunehmen
Das Ziel erscheint doppeltDen gewünschten Transport ausdrücklich wählen

Die Tabelle ist eine Methode zur Fehlersuche. Jede Beobachtung grenzt die Untersuchung ein, keine ist für sich eine allgemeingültige Diagnose.

4. Das Netzwerk prüfen, ohne es zu schwächen

Gast-WLAN, Client-Isolation, eine Host-Firewall oder ein VPN können ändern, ob Geräte sich gegenseitig finden oder erreichen. Googles ADB-Dokumentation nennt restriktive Netzwerkumgebungen als Ursache für Probleme mit kabellosem Debugging.Quelle 2

Probiere ein Netzwerk, das dir gehört und dem du vertraust. Halte den Test kontrolliert: dasselbe Handy, derselbe Computer, dieselbe ADB-Installation. Ein Erfolg dort ist ein nützlicher Beleg für den Administrator.

Schalte den Firewall-Schutz nicht dauerhaft komplett ab. Lege nur die eng gefasste Ausnahme an, die dein Betriebssystem und deine Netzwerkrichtlinie unterstützen.

„More than one device“ ist ein Auswahlproblem

USB-, WLAN- und Emulator-Verbindungen können nebeneinander bestehen. Geh nicht davon aus, dass eine ADB-Zielkennung immer wie die aufgedruckte Hardware-Seriennummer des Handys aussieht.

Eine XDA-Diskussion von 2022 dokumentiert genau diese Verwirrung: Der Nutzer sah wechselnde Kennungen für kabellose Verbindungen und wollte sich mit einer einzigen festen Seriennummer verbinden. Antworten und Tests drehten sich darum, den von ADB tatsächlich aufgelisteten Transport zu wählen.Quelle 6

Lies die aktuelle Liste und kopiere die Kennung der Verbindung, die du nutzen willst:

adb devices -l
adb -s "EXACT_IDENTIFIER_FROM_THE_LIST" shell getprop ro.product.model

Der zweite Befehl ist eine reine Leseprüfung der Identität. Nennt er das falsche Ziel, hör auf, bevor du Befehle zum Installieren, Löschen oder Flashen nutzt.

Kürze eine mDNS-basierte Kennung nicht, nur weil der verbleibende Text vertrauter aussieht.

Funktionierendes kabelloses ADB heißt nicht, dass Shizuku immer läuft

ADB-Kopplung und der Lebenszyklus einer per ADB gestarteten App hängen zusammen, sind aber verschiedene Themen.

Shizuku dokumentiert eigene Startmethoden, das Verhalten nach Neustarts und gerätespezifische Einschränkungen.Quelle 5 Dass ein Computer sich über ADB Wi-Fi 2.0 automatisch neu verbindet, beweist nicht, dass Shizuku automatisch neu gestartet ist oder dass Android den Dienst einer App nie beendet.

Prüfe den Statusbildschirm der App selbst. Funktioniert ADB, das abhängige Tool aber nicht, untersuche dessen Start und Autorisierung, statt eine funktionierende ADB-Kopplung neu aufzubauen.

Dasselbe gilt für eine Helfer-App, die lokales kabelloses Debugging auf dem Handy selbst nutzt. Folge dem unterstützten Ablauf dieser App und geh nicht davon aus, dass Anleitungen für den Computer mit einer Loopback-Verbindung identisch sind.

Trennen ist nicht dasselbe wie Zugriff entziehen

Schalte Wireless debugging aus, wenn du es nicht brauchst. Um einem Computer das Vertrauen zu entziehen, nutze Paired devices > den Computer > Forget. Googles Anleitung beschreibt auch, wie du Debugging-Autorisierungen widerrufst, um zuvor gekoppelte Computer zu entfernen.Quelle 1

adb disconnect schließt eine Transportverbindung. Es ersetzt nicht, einen nicht vertrauenswürdigen Computer zu entfernen oder das automatische Netzwerkvertrauen aufzuheben.

Prüfe vor dem Verleihen oder Verkaufen eines Geräts die autorisierten Computer und Entwickleroptionen als Teil der Übergabe. Lass keinen vorübergehenden Support-Computer gekoppelt, nur weil die Sitzung vorbei ist.

Ein brauchbarer Fehlerbericht zu kabellosem ADB

Nenne das Handymodell und den genauen Android-Build, die Ausgabe von adb version und adb server-status, ob das Koppeln klappt, ob die direkte Verbindung klappt und ob dieselbe Einrichtung in einem anderen vertrauenswürdigen Netzwerk funktioniert.

Gib an, ob USB und WLAN gleichzeitig verbunden sind. Füge ein geschwärztes Ergebnis von adb devices -l bei, wenn die Zielauswahl das Problem ist.

Veröffentliche keine Kopplungscodes, keine privaten ADB-Schlüssel und keine vollständigen Logs mit persönlichen App-Daten. Ein Bericht, der Erkennung, Vertrauen und Verbindung trennt, spart allen Zeit.

Häufige Fragen

Brauche ich unter Android 17 ein USB-Kabel zum Koppeln?

Nicht für den unterstützten modernen Kopplungsablauf mit Wireless debugging. Verwechsle ihn nicht mit älteren Anleitungen, die zuerst über USB den TCP-Modus aktivieren.Quelle 1Quelle 4

Warum meldet ADB „gekoppelt“, obwohl die Geräteliste leer ist?

Koppeln und eine aktive Verbindung sind getrennt. Prüfe den aktuellen Verbindungsport auf der Hauptseite und untersuche dann Erkennung und Serverstatus.

Funktioniert ADB Wi-Fi 2.0 auf jedem älteren Android-Handy?

Die dokumentierte neue Kombination ist Android 17 mit ADB 37.0.0 oder neuer. Frühere Versionen können den älteren kabellosen Ablauf unterstützen, das ist aber kein Versprechen für identisches automatisches Verhalten.Quelle 1

Soll ich ADB_MDNS_OPENSCREEN=0 setzen?

Nicht als Lösung für Platform Tools 37.0.1. Laut Google hat diese Variable in diesem Release keine Wirkung mehr.Quelle 3

Soll ich Port 5555 öffnen, um das zu beheben?

Nein. Öffentliche Portweiterleitung gehört nicht zum modernen lokalen Kopplungsablauf. Beschränke Debugging auf autorisierte Geräte und Netzwerke.

Teile die Diagnose in drei Teile

Kann der Computer das Handy finden? Vertraut das Handy dem Computer? Kann er die aktuelle Verbindung aufbauen?

Beantworte das getrennt. Dann weißt du, ob du ein Netzwerk reparieren, den richtigen Endpunkt wählen, die laufende ADB-Installation aktualisieren oder ein echtes Kopplungsproblem beheben musst, statt immer wieder Codes zu erzeugen und zu hoffen, dass einer klappt.

Quellen und Umfang

Recherche geprüft am 28. September 2026. Die Befehle nutzen Googles dokumentierte ADB-Schnittstelle und Beispielplatzhalter. Es wird nicht behauptet, dass das automatische Neuverbinden für diesen Artikel auf Geräten verschiedener Hersteller oder in verschiedenen Netzwerken praktisch getestet wurde.

  • Quelle 1: Android Developers, Apps auf einem Hardware-Gerät ausführen, Android 17 Wi-Fi 2.0, vertrauenswürdige Netzwerke, Kopplung und Widerruf. Quelle öffnen
  • Quelle 2: Android Developers, Android Debug Bridge und Fehlerbehebung bei kabellosem Debugging. Quelle öffnen
  • Quelle 3: Android Developers, Release Notes der SDK Platform Tools, besonders 37.0.0 und 37.0.1. Quelle öffnen
  • Quelle 4: Entwickler von Bugjaeger, Verbindung über WLAN, einschließlich Kopplungs- und Verbindungsports. Quelle öffnen
  • Quelle 5: Offizielle Shizuku-Einrichtungsanleitung, Startmethoden und Geräteeinschränkungen. Quelle öffnen
  • Quelle 6: XDA, Diskussion vom August 2022 über Kennungen bei kabellosem ADB und wechselnde Portzuweisungen. Fehlersuche von Nutzern aus der Vergangenheit, kein Test unter Android 17. Quelle öffnen