Wireless debugging pairing pitfalls that break Android mirroring

Wireless debugging is convenient until the pairing port rotates, the phone sleeps, or your laptop quietly joins the guest SSID. Most “it worked yesterday” wireless ADB stories trace back to a small set of network and power state mistakes—not a broken mirroring app.

Same Wi-Fi really means same L2 domain

Phone and PC must see each other at LAN scope. Guest Wi-Fi, captive portals, and client isolation (APs that forbid Wi-Fi-to-Wi-Fi traffic) all look “online” from a browser test yet block ADB pairing traffic.

If pairing fails instantly at the office, try USB once to prove the device is healthy, then ask IT whether peer-to-peer Wi-Fi is blocked on your VLAN.

IP churn and sleep

DHCP leases can change addresses. Some OEMs aggressively sleep wireless debugging when the screen is off. For long sessions, keep the device plugged in, disable overly strict battery savers for your mirroring session if your OEM allows it, and reconnect after router reboots.

VPNs and split tunnels

A full-tunnel VPN on the desktop can hairpin what “local network” means. If wireless debugging targets a RFC1918 address on your LAN, but the VPN sends all traffic elsewhere, pairing packets never arrive. Split-tunnel or pause VPN only if your security policy allows it for lab networks.

Pairing codes and fat fingers

Android shows a pairing port and six-digit code for a limited time. Typos, stale dialogs, and trying to reuse yesterday’s port are common. When in doubt: forget pairing, regenerate in Developer options, and enter the fresh values once—rarely does hammering the old port help.

Step-by-step device setup lives in Getting Started; connection patterns are covered in Connecting Devices. For the bigger picture on USB versus Wi-Fi tradeoffs, read USB vs wireless ADB.

Wireless debugging is a sharp tool—respect your network topology and it stays boringly reliable.