ADB Unauthorized: Fix Device Access Fast

You plug in your Android phone, run adb devices, and instead of the word device you see unauthorized. Your app won't deploy, logcat stays empty, and the shell refuses to open. Nothing looks broken — the cable works for charging, USB debugging is on, and ADB worked last week on this same machine. It's the kind of error that makes you doubt your setup instead of pointing at the real cause.

The cause is almost always trust, not tooling. Since Android 4.2, every computer has its own RSA key, and the phone shows a fingerprint dialog asking you to approve it. If that dialog was dismissed, timed out, or never appeared, the daemon lists the phone as unauthorized and blocks every command. Re-running adb devices won't help because the phone is still waiting on your tap — or it never got asked at all.

This guide walks the full fix in order. You'll retrigger the RSA prompt by revoking old authorizations, rule out charging-only cables and wrong USB modes, restart the ADB server to clear stale keys, and fix Linux udev rules that can mask the prompt entirely. By the end, adb devices will show device, and you'll know which step to repeat the next time a new machine or a factory reset breaks trust again.

The RSA Fingerprint Dialog You Never Accepted

Since Android 4.2, ADB authentication is a two-party handshake: your computer offers an RSA public key, and your phone asks its human to approve it. The dialog shows the key's fingerprint plus a checkbox for Always allow from this computer. Until you tap Allow, the daemon marks the transport unauthorized and rejects shell, install, logcat, and file push — even though the USB link itself is fine. That's why everything looks connected yet nothing works.

Dialogs get missed more often than you'd think. The prompt can appear while the screen is locked, time out in under a minute, or hide behind the current app while you're staring at the terminal. Some phones suppress it when the screen is off or when USB mode sits on charging only. If you tapped Cancel once, the phone remembers the refusal for that key and won't ask again until you revoke authorizations. Each miss leaves the same symptom: adb devices prints unauthorized with no hint about the untapped dialog.

Build the habit of phone-first debugging. After plugging in, look at the phone before the terminal — if no dialog is showing, assume it timed out or was suppressed, not that ADB is broken. Revoke first, replug, keep the screen awake, and accept with the Always allow checkbox on machines you own. On shared lab machines skip the checkbox so the next engineer's key can't ride on your approval. One careful tap is the whole fix in most cases, and it's the step every other section depends on.

# Check current device state (device = trusted, unauthorized = tap missing)
adb devices -l

# Restart the daemon if the state looks stale after tapping Allow
adb kill-server
adb start-server
adb devices

# Confirm which host key the phone was asked to approve
ls -l ~/.android/adbkey ~/.android/adbkey.pub
adb --version

Revoke USB Authorizations to Retrigger the Prompt

Revoking USB debugging authorizations is the cleanest way to force a fresh handshake. The option lives under Developer options and wipes every computer the phone has ever trusted. That sounds drastic, but it's exactly what you want when fingerprints changed: a new laptop, a regenerated ~/.android/adbkey, a CI runner that was reimaged, or a phone update that half-cleared stored keys. After revoking, the next plug-in behaves like a first meeting — the phone must ask again, which clears refusals, timeouts, and stale approvals in one move.

The sequence matters. Revoke on the phone first, then toggle USB debugging off and back on so the software stack re-registers. Unplug the cable, restart the host daemon with adb kill-server and adb start-server so it offers the current key instead of a cached session, and only then replug. Watch the phone immediately: the dialog appears within seconds when everything lines up. Accept it with Always allow on your own machine, then verify with adb devices before opening a second terminal or launching the IDE.

Treat revocation as routine maintenance, not a last resort. Shared test phones accumulate approvals and refusals from dozens of hosts, and old entries cause exactly the silent stuck states teams chase for hours. After release weeks or lab reshuffles, revoke the pool phones once and re-approve them serially. You'll spend ten minutes tapping and save an evening of ghost debugging where every command fails with no new information.

# On the phone: Settings > Developer options > Revoke USB debugging
# authorizations, then toggle USB debugging off and on.

# On the host: restart the daemon so it offers the current key
adb kill-server
adb start-server

# Replug the phone, accept the RSA dialog, then verify
adb devices
# want: emulator-5554 device  (not 'unauthorized')
# still stuck? confirm the daemon sees the USB transport:
adb devices -l

Cable, Port, and Charging-Only Modes That Block Auth

Not every USB cable carries data. Charging-only cables — common with cheap bundles and some hotel cords — connect power pins while leaving the data pins un wired, so the phone charges happily while the host never sees a device at all. Even with a good cable, a failing hub, a front-panel port with loose wiring, or a port stuck in charging-only negotiation can produce the same silence. If the key can't travel over data lines, no dialog can appear, and every ADB command is doomed before it starts.

USB mode on the phone is the second gate. Many phones default new connections to charging only, which suppresses the RSA dialog on some builds until you switch to File transfer (MTP) or PTP. The mode picker lives in the USB notification the moment you plug in — pull it down and change it, since the default rarely announces itself. Developer options like Default USB configuration let you pin file transfer as the default so future plug-ins don't silently land in charging mode again.

Diagnose the physical layer before wiping keys. Check lsusb for the vendor ID and dmesg for fresh USB enumeration lines right after plugging in — both prove data lines work. If lsusb shows nothing new, swap the cable first, then the port, skipping hubs entirely for the test. Keep one known-good short cable labeled for debugging; it ends more unauthorized mysteries than any daemon flag. Only when the host provably sees the phone should you go back to revoking and re-approving trust.

# Did the host see USB data lines at all? (want a phone vendor row)
lsusb | grep -i -E 'google|samsung|oneplus|xiaomi|motorola|sony'

# Check kernel enumeration right after plugging in
dmesg | tail -20

# Confirm ADB's view of transports (empty = physical layer fault)
adb devices -l
system_profiler SPUSBDataType 2>/dev/null | grep -i -A 3 android || true

Restart ADB Server to Clear Stale Keys

The ADB server caches keys and device sessions for speed, and that cache can lie. If you regenerated ~/.android/adbkey, switched users, or revoked trust on the phone while the daemon kept running, the server may keep offering the old identity or hold the transport in its previous unauthorized state. Tapping Allow on the phone then changes nothing visible, because the host side never re-offers the current key. The symptom looks like a broken phone approval, but it's really a stale server.

The standard reset is two commands: adb kill-server followed by adb start-server, then adb devices to re-enumerate. Killing the server drops all transports and forces a fresh key load; starting it re-reads ~/.android/adbkey and re-presents it to each attached phone. Run these as your normal user — sudo creates root-owned keys and a second daemon that your user session can't approve, which produces endless unauthorized loops. If multiple platform-tools copies exist (system package plus Android Studio's SDK), make sure the adb on your PATH is the one you restarted.

When even a restart fails, regenerate deliberately instead of randomly deleting files. Stop the server, back up the keypair aside, start the server so it mints a fresh pair, revoke authorizations on the phone, and approve the single new fingerprint. That ordered reset beats deleting keys mid-session, which strands the running daemon with keys it already loaded. Log which host key each lab machine uses and you'll stop chasing ghosts the next time a reimage mints a stranger.

# Clean daemon restart as YOUR user (never sudo for this)
adb kill-server
adb start-server
adb devices

# If the key itself changed: back up, regenerate, re-approve
adb kill-server
mv ~/.android/adbkey ~/.android/adbkey.bak
mv ~/.android/adbkey.pub ~/.android/adbkey.pub.bak
adb start-server   # mints a fresh keypair
adb devices        # approve the NEW fingerprint on the phone

# Which adb are you actually restarting?
which -a adb
adb --version

Linux udev Rules: Permission Faults Wearing an Auth Mask

On Linux, unauthorized is sometimes the wrong diagnosis entirely. Without a udev rule granting your user access to the phone's USB device node, ADB can't open the interface — and the failure can surface as a missing prompt or a no permissions row that reads like a trust problem. You'll revoke keys and swap cables while the real gate is file ownership under /dev/bus/usb. Any Linux bench that hasn't set Android rules will hit this with every new vendor ID it meets.

The fix is a one-file rule plus group membership. Find the phone's vendor ID with lsusb (18d1 for Google, 04e8 for Samsung, and so on), then write /etc/udev/rules.d/51-android.rules with a MODE of 0666 and GROUP plugdev for that ID. Reload rules with udevadm control --reload-rules and udevadm trigger, add your user to plugdev, and log out and back in so the group applies. Replug the phone and run adb devices — trusted phones now prompt, and approved ones show device instead of permission errors.

Bake this into images and onboarding docs rather than fixing it per engineer. Device labs accumulate vendor IDs fast, so keep one rules file covering every brand in the pool and commit it beside the runner setup scripts. Document the logout step explicitly, since group changes don't apply to live sessions and that gap sends people back to key-wiping. Once permissions are stable, every remaining unauthorized is genuine trust you can fix with a tap — which is exactly how the layers should separate.

# Find your phone's vendor ID (first hex group before the colon)
lsusb

# Grant access (replace 18d1 with your ID; repeat per vendor)
echo 'SUBSYSTEM=="usb", ATTR{idVendor}=="18d1", MODE="0666", GROUP="plugdev"' \
  | sudo tee /etc/udev/rules.d/51-android.rules
sudo udevadm control --reload-rules
sudo udevadm trigger

# Join plugdev, then LOG OUT and back in (required)
sudo usermod -aG plugdev "$USER"
groups "$USER"

# Replug the phone and verify (want 'device', not 'no permissions')
adb kill-server && adb start-server && adb devices

Verifying the Fix Sticks Across Reconnects

A fix that lasts one plug-in isn't a fix. Trust entries can look good until a screen lock, a hub power cycle, or a switch from MTP back to charging mode drops the transport again. Verify deliberately: unplug, wait five seconds, replug, and confirm adb devices still prints device without a new dialog. Then lock the phone, unlock it, and run a real command such as adb shell getprop ro.build.version.release to prove the channel carries traffic — listing alone doesn't prove usability.

Watch for the two impostors. A device row that appears only while USB debugging is toggled fresh but vanishes on replug points at a hub or cable that drops data lines under load — swap hardware before blaming keys. A prompt that reappears on every single plug-in despite Always allow points at a phone that can't persist approvals (often after a wipe or a managed-device policy) or a host that regenerates keys each boot from a read-only home. Both need their root cause fixed; repeated tapping just papers over them.

Lock in the working state once it holds. Note which cable, port, USB mode, and host key produced device, and keep that combo for demos and release lanes. On shared machines, decide the Always allow policy up front and revoke pool phones between borrowers so approvals stay intentional. The goal isn't just one green adb devices line — it's a setup where the next engineer plugs in and stays authorized without reading this guide again.