Emulators cover a lot of ground, but they don't cover the things that actually break in production: real GPU behaviour, real thermal throttling, real camera and sensor stacks, real network flakiness, and the OEM software layers that make one vendor's Android behave unlike another's. At some point the test matrix needs physical hardware.
And the first physical device you plug into a Windows machine almost always produces the same result: adb devices returns an empty list. This is not a broken phone or a broken toolchain. It is a four-part setup where each part fails silently, and knowing the order turns an afternoon of guessing into a five-minute job.
The order that works
1. Enable developer options and USB debugging. On the device: Settings → About phone → tap the build number seven times. Then Settings → Developer options → enable USB debugging. Nothing on the host side matters until this is on, and it is off by default on every retail device.
2. Set the USB mode. Plug the phone in, unlock it, and check the USB notification. Charging-only is the default on modern Android and it will not expose the debug interface reliably; switch to File transfer / MTP. Some devices expose a separate developer setting for the default USB configuration, which is worth setting if the hardware lives on your desk permanently.
3. Install the OEM USB driver on Windows. This is the step that catches people coming from macOS or Linux, where no driver is needed at all. Windows needs a driver that binds the device's ADB interface, and the generic one it picks does not always do it. The symptom is unambiguous once you know it: Device Manager shows the phone with a warning triangle, or as an "Unknown device", or under "Other devices" — and adb devices stays empty no matter how many times you restart the server.
Each vendor publishes its own package. Samsung's is the one most commonly needed on a mixed test bench, and a page like the Samsung USB driver for Windows collects the Windows installer and its setup steps in one place rather than sending you through several support redirects. Install it, unplug, plug back in, and re-check Device Manager: the device should now appear cleanly, typically under "Android Device" or the vendor's own node.
Standard supply-chain caution applies here as with any binary that installs a kernel-mode driver: take it from the vendor or one source you have deliberately chosen to trust, and avoid generic "driver updater" utilities entirely — they bundle far more than a driver.
4. Accept the authorisation prompt. With the driver in place, adb devices will often show the device as unauthorized. Look at the phone's screen: there is an RSA fingerprint dialog waiting. Accept it, and tick "always allow from this computer" for a machine you own. If the prompt never appears, adb kill-server && adb start-server with the phone unlocked usually forces it.
Reading the failure by its symptom
| What you see | What it means |
|---|---|
adb devices empty, nothing new in Device Manager |
Cable has no data lines, or the port is dead — try a known-good cable first |
| Device Manager shows a warning triangle / unknown device | Missing OEM USB driver — step 3 |
adb devices lists the device as unauthorized |
The RSA prompt is waiting on the phone's screen — step 4 |
adb devices lists it as offline |
Stale adb session; kill the server and reconnect, and check the phone isn't asleep |
| Works, then drops mid-test-run | Power management on the USB hub, or a cable that only makes contact at one angle |
The first row deserves emphasis because it costs the most time: charge-only cables are extremely common, they look identical to data cables, and every other diagnosis assumes the data lines exist. Keep one cable that you have proven transfers files taped to the test bench, and never troubleshoot with a cable pulled out of a drawer.
Notes for a device bench that stays working
- Pin the driver version you validated. A Windows update that swaps a driver underneath a working setup is a genuinely confusing failure mode.
- Disable USB selective suspend on the host for a bench machine — Windows will power down a port mid-run otherwise.
- Prefer rear ports and powered hubs. Front-panel headers deliver enough current to charge and not always enough stability to hold a session.
- Consider wireless debugging once the device is paired over USB. It removes cable flakiness from long-running suites, at the cost of network dependency.
- Keep the device unlocked and awake during automated runs; a lock screen mid-suite invalidates results in ways that look like real failures.
That last category — environmental noise that produces failures indistinguishable from genuine bugs — is the same class of problem covered in our piece on automated testing past CAPTCHAs: a test suite that fails for infrastructure reasons trains the team to ignore red builds, which is more expensive than having no suite at all.
FAQ
Why does adb work on macOS without a driver but not on Windows?
macOS and Linux talk to the device through generic USB support that already covers the ADB interface. Windows binds a specific driver to that interface, and the generic one it selects often doesn't match a given OEM's implementation — hence the vendor packages.
My device shows as unauthorized. What now?
The authorisation dialog is on the phone. Unlock the screen and accept the RSA fingerprint. If it doesn't appear, restart the adb server with the phone unlocked, and revoke previous authorisations in developer options if the device was previously paired with another machine.
Is installing an OEM USB driver from a download site safe?
A driver installs with system-level privileges, so the source matters more than for ordinary software. Use the vendor package, get it from one place you have deliberately vetted, and never use bundled driver-updater tools. A page that hosts the vendor installer and documents the steps is a reasonable convenience; an installer that wants to scan your entire system is not.
Do I still need physical devices if I have a good emulator?
For most logic, no. For anything touching the camera, sensors, GPU behaviour, battery, or OEM-specific system UI, yes — those are precisely the layers an emulator abstracts away, and precisely where user-reported bugs concentrate.
Next step
Run the four steps in order on the next device you add to the bench: USB debugging on, file-transfer mode, OEM driver installed, authorisation accepted. If Device Manager is where it fails, install the vendor package first — for Samsung hardware, the Samsung USB driver for Windows — and then let adb devices confirm the setup before you write a single test against it.
