Skip to main content

Fixing common ADB connection errors before they ruin your mirror session

· 3 min read
admin
NearMirror

If mirroring fails at the connection step, the root cause is often one of a handful of ADB-adjacent issues. This post collects the fastest checks we see in the wild.

“Device unauthorized” or no RSA prompt​

Unplug and replug, revoke old keys if you have been swapping machines: Developer options → Revoke USB debugging authorizations, then reconnect and accept the prompt on the phone while it is unlocked.

Device never appears in the desktop app​

  1. Confirm USB debugging is on—see Developer Options.
  2. Try another cable (data-capable, ideally OEM).
  3. Try another USB port; some front-panel ports are underpowered or flaky.

Wireless: “offline” or endless pairing​

Double-check same Wi‑Fi as the PC, correct pairing port/code for wireless debugging, and that the phone is not switching networks due to weak signal. Firewalls on corporate VLANs sometimes block ADB ports between Wi‑Fi clients; USB is the quickest isolation test.

adb devices shows nothing (if you use CLI)​

Install or repair USB drivers on Windows; on macOS/Linux, rule out bad cables first. On Linux, udev rules for your vendor ID may be required for non-root access.

NearMirror’s Getting Started path is designed so you do not need the CLI, but the same physical and authorization issues apply to every mirroring stack built on ADB.

device offline or flaky state changes​

offline usually means the host can see the gadget layer but adbd is not conversing cleanly—bad cable/port, USB hub in the path, or the device dropped authorization mid-session. Remove hubs temporarily, try another port, unlock the phone, and watch for the authorize prompt. If you toggled File transfer / MTP recently, reconnect once; some stacks are picky until the USB mode settles.

USB mode (MTP, PTP, “charge only”)​

Android’s USB notification can silently land on charge only after an update. Pick File transfer / Android Auto or the mode your OEM labels for data—exact names vary—then replug. This is not “magic,” but it eliminates a boring class of “worked yesterday” reports.

Windows: OEM and Google drivers​

Generic Windows drivers cover many phones, but not all. If the device never enumerates, install the OEM USB driver package for Samsung, Google, Xiaomi, etc., or the Google USB Driver for Pixel-class devices. Device Manager “unknown device” entries are your hint before you blame mirroring software.

Linux: udev rule pattern​

Non-root adb needs permission on the USB node. Rules are vendor-specific; you will see an 18d1 (Google) style id or your phone vendor’s USB id in lsusb. A typical pattern (replace 0xXXXX with your vendor id from lsusb -v) looks like:

SUBSYSTEM=="usb", ATTR{idVendor}=="XXXX", MODE="0666", GROUP="plugdev"

Reload rules and replug. Distro docs differ slightly (udevadm control --reload-rules && udevadm trigger).

Corporate Wi‑Fi and VLANs​

Even when the phone and laptop are “on Wi‑Fi,” client isolation or inter-VLAN firewall rules can block the TCP ports wireless debugging uses. If USB works instantly but wireless never completes pairing, grab IT with “peer-to-peer blocked on SSID X” language—or use USB on that network.

For device-specific flows, keep Connecting Devices open next to this checklist.