D DOKUBASIS
Dev Blog

Android Localhost Debugging: Port Forwarding, ADB Drivers, and the Missing RSA Prompt

An overlapping button in a mobile browser, a Spring Boot app behind a strict OAuth wall, and a Windows PC that does not recognize the smartphone. What looks like a small CSS fix can quickly escalate into a debugging odyssey. This deep dive is for web developers struggling with Chrome port forwarding, faulty ADB drivers, and uncooperative USB debugging prompts.

As a web developer, you know the phenomenon: The web application looks excellent in the browser on your desktop monitor. Even the mobile view in Chrome DevTools shows no errors. But when you open the page on a real Android smartphone, for example in Edge or Chrome, important UI elements suddenly disappear or buttons overlap.

The Problem: CSS Bugs, Mobile Edge, and the OAuth Trap

The culprit is often quickly identified: the CSS property height: 100vh. Mobile browsers, especially those with an address bar at the bottom such as mobile Edge, often calculate this value based on the maximum screen height. In doing so, they ignore the dynamic toolbar that appears and disappears as you scroll. As a result, the layout extends beyond the bottom of the visible area.

These days, the solution is usually trivial: use height: 100dvh (Dynamic Viewport Height), which correctly accounts for these bars.

But how do you test this fix locally when the application is more complex?

Why Cloudflare Tunnel Often Fails with OAuth

Many developers use services such as Cloudflare Quick Tunnels (trycloudflare.com) for temporary mobile testing. The problem is that they generate a new, random subdomain every time they start.

If your application, such as a Spring Boot backend, is behind an OAuth2 login (Google, GitHub, Auth0), the provider requires a strictly registered redirect URI. A random Cloudflare URL results in a “Redirect URI mismatch” error. Temporarily disabling security in the code is often impossible as well when important application data, such as user roles, is loaded directly from the authenticated OAuth profile.

The most elegant solution is Chrome port forwarding via USB debugging. The smartphone tunnels its requests through the USB cable to localhost on the development PC. The OAuth provider continues to see the clean, permitted localhost:8080 redirect.

But getting there on Windows is often a rocky road.

Hurdle 1: Windows Device Manager and the Driver Vacuum

The first logical step takes you to the Android device’s developer options: Enable USB debugging and connect the phone to the PC with a cable. But Chrome DevTools at chrome://inspect/#devices remains completely empty.

A look at Windows Device Manager usually reveals the problem: The smartphone is recognized as an MTP storage device, but the debugging interface is missing or marked with a yellow exclamation point (“ADB Interface”). Windows simply lacks the correct drivers for Android debugging.

Installing ADB Drivers as an Administrator

To install the driver correctly system-wide, you must launch Device Manager with administrator privileges; otherwise, Windows refuses the manual driver assignment.

  1. Open Command Prompt as an administrator: Press the Windows key, type cmd, right-click “Command Prompt,” and select “Run as administrator.”
  2. Launch Device Manager directly: Type the command devmgmt.msc and press Enter.
  3. Download and install the driver: Download the official Google USB Driver and extract the ZIP file.
  4. In Device Manager, right-click the “Unknown device” with the exclamation point, select Update driver, then Browse my computer for drivers, and choose the extracted folder.

After a successful installation, the device should be listed correctly as “Android Composite ADB Interface.”

Hurdle 2: “Offline” — Why the USB Debugging Prompt Does Not Appear

The drivers are installed and the phone is connected, but Chrome still reports the device as Offline at chrome://inspect. The critical additional message reads: “Pending authentication: please accept debugging session on the device.”

At this point, the RSA prompt should normally appear on the smartphone: “Allow USB debugging? The computer’s RSA key fingerprint is …” Without this cryptographic confirmation, Android firmly blocks access from the PC. But the display remains blank. Even revoking USB debugging authorizations or switching to another smartphone does not help.

The Conflict Between Chrome and the ADB Daemon

The answer lies in Chrome’s architecture. The browser includes its own built-in USB discovery routine. It relies on communicating in the background with the ADB daemon (adb.exe, Android Debug Bridge). But if this background service is not running on the PC, has become stuck, or Chrome lacks the permissions to trigger it correctly, the required RSA handshake is never sent through the USB port.

The smartphone waits for an authorization request that the PC never sends.

The Fix: Force the ADB Handshake Manually

When Chrome fails, you need to initialize the hardware connection manually from the command line. For this, you need Google’s raw, official tools.

Step-by-Step Troubleshooting Guide

  1. Download Platform-Tools: Download the Android Platform-Tools. They do not require installation. Simply extract the ZIP file to a folder, for example on the desktop.
  2. Check MTP mode on the smartphone (important!): For security reasons, such as protection against “juice jacking” at public charging stations, modern Android versions block the data lines when the device is set to “Charging only.” In the phone’s USB settings, make sure you select “File transfer” (MTP).
  3. Start ADB manually: Open Windows File Explorer in the folder where you extracted Platform-Tools. Click the address bar at the top, type cmd, and press Enter. The terminal opens directly in this directory.
  4. The crucial command: Type the following command and press Enter:
adb devices

What happens in the background: The system now reports: * daemon not running; starting now at tcp:5037. The ADB daemon is forcibly started and actively scans the USB ports. It uses the Windows driver you repaired earlier and initiates the RSA handshake with the smartphone.

The result: The long-awaited “Allow USB debugging?” prompt appears on the smartphone display at the exact moment you run the command.

The Final Step: Enable and Test Port Forwarding

Once you confirm the prompt on the phone by selecting “Always allow from this computer,” the setup is complete:

  1. Return to chrome://inspect/#devices in Chrome. The “Offline” message is gone, and the device is now listed as active.
  2. Click “Port forwarding …” next to the device.
  3. Enter 8080, or your Spring Boot port, as the port.
  4. Enter localhost:8080 as the target address.
  5. Select “Enable port forwarding” and confirm.

Now open mobile Edge or Chrome on the smartphone and type http://localhost:8080 into the address bar. The traffic is securely routed through the USB cable to your PC. The application loads, the OAuth redirect to localhost works perfectly, the roles are loaded correctly from the database, and you can finally turn your attention to fixing the original CSS bug.

Conclusion: When web technologies such as OAuth and CSS meet hardware interfaces such as ADB and USB protocols, the resulting errors are often difficult to understand. A silent RSA prompt rarely means that the smartphone is defective; it usually points to a silent ADB daemon. Keeping the adb devices command and the Windows Device Manager’s administrator mode in your toolkit can save you hours of fruitless troubleshooting.