Fix an ADB `unauthorized` Device Without Reinstalling Platform Tools

What unauthorized actually tells you

When adb devices -l lists a serial followed by unauthorized, the host can see a transport but the device has not authorized this computer's debugging key. Reinstalling platform-tools rarely addresses that state. The device must be unlocked and its RSA trust prompt accepted.

Start with the small diagnostic sequence:

adb kill-server
adb start-server
adb devices -l

Disconnect and reconnect the cable, unlock the phone, and look for the “Allow USB debugging?” prompt. Confirm the computer fingerprint only on a device you control. If the prompt was previously dismissed, revoke USB debugging authorizations in Developer options, turn USB debugging off and on, reconnect, then accept the new prompt.

Separate trust from transport problems

If the device disappears entirely, investigate the cable, USB mode, port, or host permissions instead. If the status is offline, wait briefly after reconnecting and restart the ADB server once. Avoid repeatedly killing servers while Android Studio, an emulator, and another terminal are all trying to manage the same transport.

Use adb devices -l after each change. A serial ending in device is the state needed for normal shell, install, and logcat commands. For wireless debugging, pair with the code displayed on the device using the current wireless-debugging flow; do not reuse an old address or assume the USB authorization automatically covers a different host.

Treat the authorization key as a credential. Do not copy private ADB keys into shared repositories or CI artifacts. Once the serial is in the device state, test with a harmless command such as adb shell getprop ro.build.version.release before resuming an app install.

Walk through the trust exchange deliberately

The authorization prompt is a security decision, not just a nuisance dialog. Compare the displayed computer fingerprint with the identity of the host you intended to connect. A developer phone used with a known workstation is different from a device plugged into an unknown shared machine. If the device is managed by an organization, follow its debugging policy before enabling or revoking authorizations. USB debugging gives the authorized host substantial access to the device, so convenience should not override ownership and policy.

When a prompt does not appear, first make sure the phone is unlocked and the USB mode permits data transfer. Some cables provide power only. Try a known data cable and a direct port before changing Android settings. Then inspect the device's Developer options and verify USB debugging is enabled. A stale authorization can be removed on the phone with the revoke-authorizations control; after reconnecting, Android should offer a fresh trust prompt. Avoid deleting host key files as the first step: doing so changes the host identity for every device and may disrupt other development workflows.

If the prompt appears and is accepted but the status remains unauthorized, capture the exact serial and repeat the server restart once. Ensure that the terminal's ADB binary is the one you intend to use. Multiple platform-tools installations can cause a server/client version mismatch, and an IDE may start a different ADB server. Close duplicate device-management processes only after recording what is running; then reconnect and observe whether the state changes. Repeatedly restarting the server without checking the status wastes time and can interrupt active emulator sessions.

Verify the recovery and prevent recurrence

Treat the transition from unauthorized to device as a checkpoint. Run a read-only shell command and confirm it returns expected device information. Then test the specific workflow that was blocked, such as adb logcat or installing a debug APK. If shell access works but installation fails, the remaining problem is probably package version, signing, storage, or install policy rather than authorization. Keep those failure classes separate in the incident note.

For teams, document the supported pairing method for both USB and Android's wireless debugging. Wireless pairing uses a displayed pairing code and a reachable network endpoint; it is a separate trust flow and can be invalidated when network addresses change. Remove stale pairings from developer machines you no longer control. Do not place ADB keys in shared CI artifacts, because possession of the private key can grant access to devices that trust it. A short checklist that records device ownership, selected host, ADB version, and final device state is a better repair than reinstalling the SDK whenever a prompt is missed.