Introduction

When adb devices shows a phone or emulator as offline, ADB can see the transport but cannot complete a usable debug session. In most cases the fix is to reset the ADB connection, re-establish authorization, and rule out cable, driver, or platform-tools mismatches before touching the app itself.

Reset the ADB server first

The fastest first step is to restart the ADB server:

adb kill-server
adb start-server
adb devices

If the device comes back as device, the problem was just a stuck transport. If it remains offline, move on to authorization and connection checks.

Re-establish USB debugging authorization

ADB relies on a trust handshake between the host machine and the Android device. If that handshake becomes stale or corrupted, the device may sit in offline instead of becoming fully authorized.

On the device:

1. enable Developer Options
2. open the USB debugging settings
3. revoke USB debugging authorizations

Then reconnect the cable and approve the RSA fingerprint prompt again.

On the host, you can also remove old ADB keys if needed:

rm ~/.android/adbkey ~/.android/adbkey.pub
adb kill-server
adb start-server

After reconnecting, accept the new prompt on the device.

Check the physical connection

A surprising number of offline states come from USB issues rather than ADB logic.

Check:

• data-capable USB cable, not charge-only
• different USB port
• direct connection instead of a flaky hub
• switching between USB modes on the device if needed

If the device repeatedly disconnects or changes state, solve the transport stability problem first. ADB cannot stay healthy on an unreliable USB link.

Update platform tools and drivers

Host-side tooling mismatches can also cause offline behavior. Make sure the machine is using a current platform-tools install and not an older ADB binary left behind by some IDE or third-party tool.

Check the version:

adb version

On Windows, also confirm the device driver is correct. A bad or generic USB driver can allow partial detection while still breaking full debugging.

Emulators can go offline too

If the target is an emulator rather than a physical phone, offline often means the emulator booted into a bad state or the ADB server lost synchronization with it. Restarting the emulator after adb kill-server is often faster than trying to salvage the session.

You can also inspect which emulator instance ADB sees:

adb devices -l

If multiple emulators or devices are attached, target the right one explicitly with -s.

Common Pitfalls

The biggest mistake is repeatedly running app-level commands while the transport is still offline. Until adb devices shows a healthy state, deployment commands are not the right layer to debug.

Another mistake is forgetting the RSA authorization prompt on the device. If the prompt was dismissed, hidden behind the lock screen, or never refreshed, the host cannot become fully trusted.

Developers also overlook host environment conflicts. An old adb binary on the PATH can keep causing issues even after Android Studio updates newer tools elsewhere.

Finally, do not ignore simple cable problems. Many ADB failures that look "software-like" are actually unstable USB connections.

If the device keeps bouncing between offline, unauthorized, and disconnected states, treat that as a transport or trust problem first. Stable authorization usually produces a consistent state quickly once the cable and handshake are healthy.

Summary

• 'offline means ADB can see the device transport but cannot use it properly yet.'
• Restart the ADB server first with adb kill-server and adb start-server.
• Revoke and re-approve USB debugging authorization if the trust handshake is stale.
• Check cables, ports, drivers, and platform-tools versions.
• Do not debug the app until adb devices reports a healthy device state.