What is adb? The client, server and adbd daemon explained

adb, short for Android Debug Bridge, is the command line tool that lets a computer talk to an Android device or emulator. You type adb devices or adb shell and, a moment later, you’re inside the phone: pulling logs, installing an APK, tapping a UI element, or dropping into a shell. It ships as part of the Android SDK Platform Tools and it’s the thing under the hood of almost every Android automation, testing, or debugging workflow you’ll run into.

Where people get confused is that “adb” isn’t one program. It’s three: a client on your machine, a server also on your machine, and a daemon on the device. Knowing the difference matters the first time something breaks, like when adb suddenly can’t see your phone, or when a platform-tools update makes your terminal print something about a server version mismatch and everything restarts on its own. This piece walks through what each piece does, how they talk to each other, and where most people’s mental model goes wrong.

what it is

adb is Google’s command line utility for developer communication with an Android device, distributed inside the SDK Platform Tools package alongside fastboot and sqlite3. It’s documented directly by Google at developer.android.com/tools/adb, and it ships and versions together with the rest of platform-tools, which Google updates on its own cadence, tracked in the official platform-tools release notes.

Architecturally, adb is a client-server model split across three pieces:

adb client: the adb binary you actually run in a terminal. Every command you type, adb install app.apk, adb logcat, adb shell pm list packages, starts here.
adb server: a background process that runs on your development machine, not the phone, and manages every connection to every attached device or emulator.
adbd: the adb daemon, a background process running on the Android device or emulator itself, the thing that actually executes what the client asked for.

None of these three do anything in isolation. The client is a thin dispatcher, the server is the traffic cop, and adbd is where the work physically happens on the device.

how it works

Type any adb command and here’s the order of operations. The client first checks whether an adb server is already running on your machine. If it isn’t, the client starts one and hands the request off. That server binds to TCP port 5037 on localhost by default, and every subsequent adb command you run, even from a different terminal window, talks to that same server over that same port rather than spinning up a new one. You can watch this happen with adb start-server, and kill it manually with adb kill-server if you ever need a clean restart.

Once the server is up, it keeps a list of every device it can see and a persistent connection open to each one’s adbd. This is where transport matters, because adb supports two.

USB: the default. Plug a phone in with USB debugging enabled in developer options, and the server talks to adbd over that USB connection. Google’s own developer options guide covers exactly what turning on USB debugging exposes and why it prompts for authorization the first time.
TCP/IP: adb can also reach adbd over the network. The older method is adb tcpip 5555 run over an existing USB connection, which flips adbd into listening on port 5555, followed by adb connect <device-ip>:5555. Since Android 11, you can skip the cable entirely and use wireless debugging directly, pairing a dev machine and device with a pairing code, as documented in Google’s wireless debugging section. If that’s the workflow you’re setting up, read our wireless debugging walkthrough first, since the pairing port and the connect port are different and that’s what trips most people up.

The version mismatch restart is the other mechanic worth understanding. The client and server speak a small internal protocol, and that protocol has a version number tied to the platform-tools release. If you update platform-tools, say through Android Studio’s SDK Manager or a package manager, while an old adb server is still running, the next command you issue will detect the mismatch, kill the stale server, and start a fresh one automatically. It’s not a bug, it’s the client refusing to trust a server it can’t fully talk to. This behavior is why running two different adb binaries on the same machine, one bundled with Android Studio and one installed separately, tends to make the server thrash between versions every time you switch terminals.

why it matters

debugging real behavior, not simulated behavior: adb logcat streams the device’s actual log buffer in real time, which is how you catch a crash, an ANR, or a silent exception that never surfaces in the UI. I’ve written a full breakdown of filtering that stream by app, tag, and priority in our logcat guide, because the unfiltered stream is close to unreadable on a busy device.
app management without touching the phone’s screen: adb shell pm list packages, adb install, and adb uninstall let you manage what’s on a device from a terminal, which is the backbone of most CI pipelines and QA workflows. Our pm and am commands piece covers the package manager and activity manager verbs in more depth.
automation and input simulation: tools like Appium, UiAutomator2, and Espresso all sit on top of adb, or the same underlying protocol, to install test builds and pull results back off the device. Which transport you’re on, USB or TCP, directly affects how stable that automation stays under load.
authorization is the gate everything sits behind: adbd won’t accept a connection from an unrecognized computer. The first time you connect a device, it shows an RSA key fingerprint dialog, and if you decline, or the key isn’t in the device’s allowlist, every subsequent command gets refused. That handshake is worth understanding rather than just clicking through, and I go through the mechanics in our RSA key authorization piece.

One place this shows up outside your own workstation: if you’re driving a phone you don’t own physically, like a rented Android device, adb still needs a deliberate path to adbd, not just “being on the internet.” cloudf.one rents real Android phones in Singapore on dedicated hardware, each with a persistent Singapore mobile IP, normally controlled from the browser. There’s no self-service adb there: adb and Appium reach a rented phone only through a WireGuard tunnel set up on request (email [email protected]). Same authorization principle as the RSA prompt, just enforced at the network layer instead of the device layer.

common misconceptions

“adb only works over USB.” It doesn’t. TCP/IP has been part of adb for years, and wireless debugging without ever plugging in a cable has worked since Android 11. USB is just the default because it needs no setup.
“the adb server runs on the phone.” It doesn’t, adbd does. The server is a process on your computer. Mixing these two up is a common reason people misdiagnose connection problems, restarting the phone when they should be running adb kill-server on the laptop, or the other way around.
“adb devices showing my phone means it’s authorized.” Not necessarily. A device can show up in that list marked unauthorized if you haven’t accepted the RSA key prompt on the device screen yet. Being visible isn’t the same as being reachable.
“one adb server can only track one device at a time.” One server tracks every device and emulator it can see at once. That’s the entire point of the -s <serial> flag on commands like adb -s emulator-5554 shell, which tells the client which of several connected targets to send a command to.

where to go from here

if you’re setting up wireless debugging so you can drop the cable entirely, read adb over wifi: wireless debugging.
if you want to actually drive the UI, not just install and inspect, our guide to adb shell input covers tap, swipe, text entry, and keyevent syntax.
if you’re deciding between running tests on an emulator versus a physical device, that choice changes what adb can and can’t see, and emulator vs real device testing lays out the tradeoffs.
if you’re picking an automation framework that sits on top of adb, UiAutomator2 vs Appium compares the two most common choices for Android UI automation.

You can browse the rest of the explainers on the blog if you want to work through the fundamentals in order.

Written by Xavier Fok

disclosure: this article may contain affiliate links. if you buy through them we may earn a commission at no extra cost to you. verdicts are independent of payouts. last reviewed by Xavier Fok on 2026-09-18.