ADB

ADB Server Port 5037 Conflicts: Fixing "Cannot Bind to 127.0.0.1:5037"

Published: July 6, 2026 • Applies to: Windows, macOS, Linux, any adb client version

Every adb command talks to a background process called the adb server, which listens on TCP port 5037 on localhost and brokers the actual USB or network connection to your device. When that port is already held by something else, adb fails before it even gets to looking for a phone — usually with cannot bind to 127.0.0.1:5037: Address already in use or a command that just hangs with no output at all.

Why Port 5037 Specifically

5037 is hardcoded as adb's default server port; it's not configurable per-install the way an app's port usually is, though it can be overridden with the ANDROID_ADB_SERVER_PORT environment variable if you deliberately want a different one. Because it's a fixed, well-known number, any second process that also happens to bind it — intentionally or by coincidence — blocks the real adb server from starting.

What Usually Grabs the Port

A second copy of adb. Android Studio, Genymotion, Google's platform-tools, and various flashing tools each ship their own bundled adb.exe. If two are running from different install paths, the second one to launch can't bind the port the first is already using, and depending on the tool's error handling it may fail silently or spawn a stale server that never sees your device.
Antivirus or endpoint protection that monitors localhost ports and briefly holds them during a scan cycle.
VPN or proxy software that reserves a range of local ports including 5037, though this is less common than the two above.
A zombie adb server process from a previous session that crashed without releasing the port cleanly, which is the most frequent cause on all three operating systems.

Finding What's Holding the Port

On Windows, open a Command Prompt and run netstat -ano | findstr 5037, note the PID in the last column, then check tasklist | findstr <PID> to see which process owns it. On macOS or Linux, lsof -i :5037 shows the process name and PID directly in one command.

Resolving the Conflict

Run adb kill-server first — this cleanly stops any adb server your own client can see, which resolves the zombie-process case without touching anything else.
If the port is still held after that, it belongs to a different adb.exe or a non-adb process. Close the other application (Android Studio, Genymotion, or whichever tool showed up in the lookup) rather than force-killing it via Task Manager if you can, since a clean shutdown releases the socket more reliably than a forced kill.
Run adb start-server to bring up a fresh server instance, then adb devices to confirm it now sees your phone.
If a non-adb process (antivirus, VPN) is the one holding 5037 and you can't close it, set ANDROID_ADB_SERVER_PORT to an alternate port such as 5038 in your environment before launching adb; every client in that session needs the same variable set or they'll each spin up an independent server that can't see the other's devices.

Running Multiple ADB-Based Tools at Once

Tools like Genymotion, Android Studio, and standalone platform-tools are all meant to share a single adb server rather than run separate ones — the adb protocol was designed so that whichever server started first just keeps serving every client that connects afterward, including the emulator and device connections from other apps. Conflicts happen specifically when one tool's bundled adb binary is a different, incompatible version from another's; mismatched versions sometimes refuse to talk to a server started by an older or newer build. Keeping all your tools pointed at the same platform-tools installation, rather than letting each one carry its own bundled copy, avoids this category of problem entirely. See the Homebrew-based platform-tools setup on macOS for one way to keep a single canonical adb install that other tools can be pointed at.

If the Device Still Doesn't Show Up

Once the server starts cleanly on 5037 (or your chosen alternate port), a phone that still doesn't appear in adb devices is a separate, unrelated problem — likely USB debugging not enabled, a missing driver, or an unauthorized connection waiting on an on-device confirmation dialog. The adb devices troubleshooting guide covers those cases once you've confirmed the server itself is running.