adb devices looks like a trivial command, but its output has four distinct states beyond the obvious "not connected," and each one points to a different root cause. Treating every blank or odd result as "driver problem" wastes time when the actual issue is a stale server, a permissions file, or a cable that only carries power.
adb devices
List of devices attached
R58N123ABCD deviceThe tab-separated second column is the state. device means the connection is fully authorized and ready for commands. Anything else needs attention before adb shell or adb install will work reliably.
R58N123ABCD unauthorizedThe phone has not confirmed the RSA key fingerprint of the connecting computer. Look at the phone's screen — a dialog is waiting there, or was dismissed and needs to be re-triggered. Reset with:
adb kill-server
adb devicesThis forces the authorization prompt to reappear if it was previously dismissed rather than declined outright. If it still does not appear, the phone's adb_keys file may be corrupted; revoke all authorizations under Developer Options > Revoke USB Debugging Authorizations, then reconnect.
R58N123ABCD offlineThe device was recognized once but the ADB daemon on the phone is not responding now — common after a phone wakes from deep sleep with USB debugging toggled but the connection stale. A server restart usually clears it:
adb kill-server
adb start-server
adb devicesIf offline persists across a server restart, unplug and replug the cable; the USB enumeration itself likely dropped even though Windows or macOS still shows the port as connected.
no permissions (user in plugdev group; are your udev rules wrong?); see [http://developer.android.com/tools/device.html]Linux-specific: the device node was created but the current user lacks read/write access to it, almost always because a udev rule for the phone's vendor ID is missing or the user is not in the plugdev group. This is not a Windows-style driver problem at all — it is a file permissions problem, and installing a "driver" fixes nothing here.
No lines at all under "List of devices attached" means the phone was never enumerated as a USB device with an ADB interface in the first place. Work through these in order:
A less obvious cause of inconsistent output: having more than one adb.exe or adb binary on the PATH, for example one bundled with Android Studio and another from a manually downloaded platform-tools ZIP. Each maintains its own server on port 5037, and whichever one a given terminal invokes may see a completely different device list. Check which binary is actually running with:
where adbOn macOS or Linux, use which adb instead. If more than one path is found, remove all but one from the system PATH environment variable to avoid this entirely.
ADB actually runs two separate pieces: a client (the adb command itself), a server (a background process on the PC that manages connections), and a daemon (running on the Android device). adb kill-server only restarts the middle piece on your PC; it does nothing to the daemon on the phone. When a phone's own daemon has wedged, only a reboot of the phone itself clears it, which is why some offline states survive a server restart and only go away after physically rebooting the device.
Running adb devices with an Android Studio emulator active shows an entry with a name like emulator-5554 rather than a hardware serial number. This is expected and not a sign anything is misconfigured; the port number simply increments for each additional running emulator instance. A script that assumes every entry in the list is a physical phone will misbehave the moment an emulator is left running in the background, so filtering on the state column alone (rather than assuming a fixed number of expected entries) is the more robust approach for any automation built on top of this command.
Rather than polling adb devices in a loop and parsing text output, ADB provides a built-in blocking wait command that returns as soon as a device reaches the fully-online state:
adb wait-for-deviceThis is the more reliable building block for any script that needs to pause until a device is ready, since it handles the unauthorized-to-authorized and offline-to-online transitions internally rather than requiring a script to re-check and re-parse the plain text table on every iteration.