D DOKUBASIS
Dev Blog

Android Localhost Debugging: Port Forwarding, ADB-Treiber und das fehlende RSA-Popup

Ein überlappender Button im mobilen Browser, eine Spring-Boot-App hinter einer strengen OAuth-Wall und ein Windows-Rechner, der das Smartphone nicht erkennt. Was wie ein kleiner CSS-Fix aussieht, eskaliert schnell zur Debugging-Odyssee. Ein Deep-Dive für Webentwickler, die mit Chrome Port Forwarding, fehlerhaften ADB-Treibern und streikenden USB-Debugging-Popups kämpfen.

Als Webentwickler kennt man das Phänomen: Die Webapplikation sieht auf dem Desktop-Monitor im Browser hervorragend aus. Auch die Mobile-Ansicht in den Chrome DevTools zeigt keine Fehler. Doch öffnet man die Seite auf einem echten Android-Smartphone, etwa im Edge- oder Chrome-Browser, verschwinden plötzlich wichtige UI-Elemente oder Buttons überlappen sich.

Das Problem: CSS-Bugs, Mobile Edge und die OAuth-Falle

Oft ist der Übeltäter schnell identifiziert: die CSS-Eigenschaft height: 100vh. Mobile Browser, besonders solche mit einer Adressleiste am unteren Rand wie der mobile Edge, berechnen diesen Wert oft auf Basis der maximalen Bildschirmhöhe. Sie ignorieren dabei die dynamische Menüleiste, die sich beim Scrollen ein- und ausblendet. Die Folge: Das Layout ragt unten aus dem sichtbaren Bereich heraus.

Die Lösung ist heute meist trivial: die Nutzung von height: 100dvh (Dynamic Viewport Height), die diese Leisten korrekt einkalkuliert.

Doch wie testet man diesen Fix lokal, wenn die Applikation komplexer ist?

Warum Cloudflare Tunnel bei OAuth oft scheitern

Viele Entwickler greifen für temporäre Mobile-Tests zu Diensten wie Cloudflare Quick Tunnels (trycloudflare.com). Das Problem: Diese generieren bei jedem Start eine neue, zufällige Subdomain.

Wenn deine Anwendung, wie zum Beispiel ein Spring-Boot-Backend, hinter einem OAuth2-Login (Google, GitHub, Auth0) liegt, verlangt der Provider eine strikt registrierte Redirect-URI. Eine zufällige Cloudflare-URL führt zu einem „Redirect URI mismatch“-Fehler. Auch das temporäre Deaktivieren der Security im Code ist oft unmöglich, wenn wichtige Anwendungsdaten wie Benutzerrollen direkt aus dem authentifizierten OAuth-Profil geladen werden.

Die eleganteste Lösung lautet Chrome Port Forwarding via USB-Debugging. Das Smartphone tunnelt seine Anfragen über das USB-Kabel an den localhost des Entwickler-PCs. Der OAuth-Provider sieht weiterhin den sauberen, erlaubten localhost:8080-Redirect.

Doch der Weg dorthin ist unter Windows oft steinig.

Hürde 1: Der Windows Geräte-Manager und das Treiber-Vakuum

Der erste logische Schritt führt in die Entwickleroptionen des Android-Geräts: USB-Debugging aktivieren und das Handy per Kabel an den PC anschließen. Doch in den Chrome DevTools unter chrome://inspect/#devices herrscht gähnende Leere.

Der Blick in den Windows Geräte-Manager offenbart meist das Problem: Das Smartphone wird zwar als MTP-Speichermedium erkannt, aber die Debugging-Schnittstelle fehlt oder ist mit einem gelben Ausrufezeichen markiert („ADB Interface“). Windows fehlen schlichtweg die passenden Treiber für das Android-Debugging.

ADB-Treiber als Administrator installieren

Um den Treiber systemweit sauber zu installieren, muss der Geräte-Manager zwingend mit Administratorrechten gestartet werden, da Windows sonst die manuelle Treiberzuweisung verweigert.

  1. Kommandozeile als Admin öffnen: Drücke die Windows-Taste, tippe cmd, mache einen Rechtsklick auf „Eingabeaufforderung“ und wähle „Als Administrator ausführen“.
  2. Geräte-Manager erzwingen: Tippe den Befehl devmgmt.msc ein und drücke Enter.
  3. Treiber laden und installieren: Lade den offiziellen Google USB Driver herunter und entpacke die ZIP-Datei.
  4. Rechtsklicke im Geräte-Manager auf das „Unbekannte Gerät“ mit dem Ausrufezeichen, wähle Treiber aktualisieren, dann Auf dem Computer nach Treibern suchen und wähle den entpackten Ordner aus.

Nach erfolgreicher Installation sollte das Gerät als sauberes „Android Composite ADB Interface“ gelistet sein.

Hürde 2: „Offline“ – Warum das USB-Debugging-Popup nicht erscheint

Die Treiber sitzen, das Handy ist verbunden, doch Chrome meldet das Gerät unter chrome://inspect weiterhin nur als Offline. Der fatale Zusatz: „Pending authentication: please accept debugging session on the device.“

Eigentlich sollte in diesem Moment auf dem Smartphone das sogenannte RSA-Popup erscheinen: „USB-Debugging zulassen? Der RSA-Schlüssel-Fingerabdruck des Computers ist …“ Ohne diese kryptografische Bestätigung blockiert Android den Zugriff des PCs vehement. Doch das Display bleibt leer. Selbst das Zurücksetzen der Debugging-Berechtigungen oder der Wechsel auf ein anderes Smartphone bringt keine Besserung.

Der Konflikt zwischen Chrome und dem ADB-Daemon

Die Antwort liegt in der Architektur von Chrome. Der Browser bringt eine eigene, integrierte Routine zur USB-Erkennung mit. Diese verlässt sich darauf, im Hintergrund mit dem ADB-Daemon (adb.exe, Android Debug Bridge) zu kommunizieren. Wenn dieser Hintergrunddienst auf dem PC aber nicht läuft, sich verschluckt hat oder Chrome nicht die Rechte hat, ihn korrekt zu triggern, wird der notwendige RSA-Handshake nie über den USB-Port gesendet.

Das Smartphone wartet auf eine Autorisierungsanfrage, die der PC nie absendet.

Der Fix: Den ADB-Handshake manuell erzwingen

Wenn Chrome versagt, muss man die Hardware-Verbindung über die Kommandozeile manuell initialisieren. Dafür benötigen wir die rohen, offiziellen Werkzeuge von Google.

Schritt-für-Schritt-Anleitung zur Problemlösung

  1. Platform-Tools laden: Lade die Android Platform-Tools herunter. Diese benötigen keine Installation. Entpacke die ZIP-Datei einfach in einen Ordner, zum Beispiel auf den Desktop.
  2. MTP-Modus am Smartphone prüfen (wichtig!): Moderne Android-Versionen blockieren aus Sicherheitsgründen, etwa zum Schutz vor „Juice Jacking“ an öffentlichen Ladesäulen, die Datenleitungen, wenn das Gerät auf „Nur Laden“ steht. Wähle in den USB-Einstellungen des Handys zwingend „Datenübertragung“ (MTP) aus.
  3. ADB manuell starten: Öffne den Windows-Explorer in dem Ordner, in den du die Platform-Tools entpackt hast. Klicke oben in die Adresszeile, tippe cmd ein und drücke Enter. Das Terminal öffnet sich exakt in diesem Verzeichnis.
  4. Der entscheidende Befehl: Tippe folgenden Befehl ein und drücke Enter:
adb devices

Was im Hintergrund passiert: Das System bemerkt nun: * daemon not running; starting now at tcp:5037. Der ADB-Daemon wird hart gestartet und scannt die USB-Ports aktiv ab. Er nutzt den zuvor reparierten Windows-Treiber und feuert den RSA-Handshake an das Smartphone.

Das Ergebnis: Exakt in der Sekunde der Befehlsausführung erscheint das ersehnte Popup „USB-Debugging zulassen?“ auf dem Smartphone-Display.

Das Finale: Port Forwarding aktivieren und testen

Nachdem das Popup auf dem Handy mit „Von diesem Computer immer zulassen“ bestätigt wurde, ist das Setup komplett:

  1. Wechsle zurück in Chrome auf chrome://inspect/#devices. Die „Offline“-Meldung ist verschwunden, das Gerät wird aktiv gelistet.
  2. Klicke neben dem Gerät auf „Port forwarding …“.
  3. Trage als Port 8080 oder deinen Spring-Boot-Port ein.
  4. Trage als Zieladresse localhost:8080 ein.
  5. Setze den Haken bei „Enable port forwarding“ und bestätige.

Jetzt öffnest du auf dem Smartphone den mobilen Edge oder Chrome und tippst http://localhost:8080 in die Adresszeile ein. Der Traffic wird sicher durch das USB-Kabel an deinen PC geleitet. Die Applikation lädt, der OAuth-Redirect auf localhost funktioniert perfekt, die Rollen werden sauber aus der Datenbank geladen und du kannst dich endlich der Behebung des anfänglichen CSS-Fehlers widmen.

Fazit: Wenn Webtechnologien wie OAuth und CSS und Hardware-Schnittstellen wie ADB und USB-Protokolle aufeinandertreffen, sind die Fehlerbilder oft schwer zu durchschauen. Ein schweigendes RSA-Popup ist selten ein defektes Smartphone, sondern meist ein stummgeschalteter ADB-Daemon. Wer das Kommando adb devices und den Admin-Modus des Windows Geräte-Managers in seinem Werkzeugkasten hat, spart sich Stunden fruchtloser Fehlersuche.