How to Fix ADB “cannot connect to daemon”

adb: cannot connect to daemon at tcp:5037

What Is the ADB Daemon?

ADB, or Android Debug Bridge, consists of several components:

• An ADB client that accepts commands
• An ADB server running in the background on the development computer
• The adbd daemon running on the Android device

When you run:

adb devices

the ADB client communicates with the ADB server on the computer.

If the server is not running, ADB normally starts it automatically:

* daemon not running; starting now at tcp:5037 * daemon started successfully *

ADB can then list connected physical devices and Emulators.

If the client cannot start or communicate with the server, you may instead see:

adb: cannot connect to daemon at tcp:5037

Common Error Messages

You may see:

* daemon not running; starting now at tcp:5037 adb: cannot connect to daemon at tcp:5037

Another common combination is:

ADB server didn't ACK adb: cannot connect to daemon at tcp:5037

Some environments may report:

cannot connect to daemon at tcp:5037: cannot connect to 127.0.0.1:5037

In each case, start with the host-side ADB server.

Common Causes

1. The ADB Server Failed to Start

ADB normally starts its server automatically when needed, but that startup can fail.

2. A Stale adb Process Is Still Running

An old ADB process can remain after Android Studio or another Android tool shuts down abnormally.

A new ADB client may then be unable to communicate correctly with the existing process.

3. Local Port 5037 Is Already in Use

The host-side ADB server normally uses local TCP port 5037.

If another process is already listening on that port, the expected ADB server may not be able to start.

4. Multiple ADB Versions Conflict

Android Studio, an old Android SDK, Android gaming Emulators, or phone-management software can each provide their own copy of ADB.

Different ADB client and server versions can create unexpected communication problems.

5. Android SDK Platform Tools Are Corrupted

ADB is included in Android SDK Platform Tools.

A damaged or incomplete Platform Tools installation can prevent ADB from starting correctly.

6. PATH Points to an Old adb Binary

Android Studio may use a current SDK while your terminal launches an older ADB from another PATH entry.

7. Firewall or Security Software Interferes with ADB

Security software can block the ADB executable or local TCP communication.

8. ADB Processes Run with Different Privileges

On Windows, mixing elevated and non-elevated ADB processes can sometimes create confusing process or port behavior.

9. Another Android Emulator Starts Its Own ADB Server

Some third-party Android Emulators include an independent ADB installation that can conflict with Android Studio’s Platform Tools.

Step 1: Check the ADB Version

Run:

adb version

If this command itself cannot be found, investigate PATH or your Platform Tools installation first.

Step 2: Start the ADB Server Manually

Run:

adb start-server

A normal result is:

* daemon not running; starting now at tcp:5037 * daemon started successfully *

If it instead reports:

cannot connect to daemon at tcp:5037

focus on the ADB environment on your computer.

Solution 1: Restart the ADB Server

Stop the current server:

adb kill-server

Start it again:

adb start-server

Then verify:

adb devices

Even with no Android devices connected, a working ADB server should normally return:

List of devices attached

Solution 2: Check for Remaining ADB Processes

If adb kill-server does not solve the problem, inspect running processes.

Windows:

tasklist | findstr adb

macOS and Linux:

ps aux | grep adb

On Windows, a stuck ADB process can be terminated when necessary with:

taskkill /F /IM adb.exe

Solution 3: Check Port 5037

Determine which process is listening on local TCP port 5037.

Windows:

netstat -ano | findstr 5037

Example:

TCP 127.0.0.1:5037 0.0.0.0:0 LISTENING 1234

Identify that PID:

tasklist /FI "PID eq 1234"

On macOS:

lsof -iTCP:5037

On Linux:

ss -ltnp | grep 5037

If an unrelated application owns port 5037, close that application before restarting ADB.

Solution 4: Check Which adb Binary Is Running

On Windows:

where adb

On macOS and Linux:

which adb

If several ADB locations exist, an old binary may be taking precedence.

For example:

C:\Android\old-sdk\platform-tools\adb.exe C:\Users\User\AppData\Local\Android\Sdk\platform-tools\adb.exe

Prefer the Platform Tools installation configured in Android Studio.

Solution 5: Run ADB by Full Path

To test whether PATH is the problem, run the ADB binary from the Android Studio SDK directly.

Example on Windows:

"C:\Users\User\AppData\Local\Android\Sdk\platform-tools\adb.exe" kill-server "C:\Users\User\AppData\Local\Android\Sdk\platform-tools\adb.exe" start-server

Example on macOS:

~/Library/Android/sdk/platform-tools/adb kill-server ~/Library/Android/sdk/platform-tools/adb start-server

If the full-path command works while plain adb fails, another ADB installation in PATH is likely causing the conflict.

Solution 6: Update Android SDK Platform Tools

Open Android Studio’s SDK Manager and update Android SDK Platform-Tools.

After updating, restart the server:

adb kill-server adb start-server adb devices

Solution 7: Reinstall Android SDK Platform Tools

If updating does not help, remove and reinstall Android SDK Platform-Tools from SDK Manager.

Then test:

adb version adb start-server adb devices

Solution 8: Close Android Studio Before Restarting ADB

Because Android Studio also uses ADB, closing the IDE can make it easier to reset the environment completely.

Try this sequence:

1. Close Android Studio.
2. Run adb kill-server.
3. Check for remaining ADB processes.
4. Run adb start-server.
5. Run adb devices.
6. Open Android Studio again.

Solution 9: Close Other Android Emulators

Temporarily close third-party Android Emulators, device managers, and older Android development utilities.

Then restart ADB:

adb kill-server adb start-server

If the error disappears, another application’s ADB server may have been conflicting with Android Studio.

Solution 10: Remove Old Platform Tools from PATH

If several ADB installations exist, remove obsolete Platform Tools directories from PATH or make the Android Studio SDK version take precedence.

A common Windows SDK path is:

%LOCALAPPDATA%\Android\Sdk\platform-tools

A common macOS location is:

~/Library/Android/sdk/platform-tools

Your actual Android SDK may be installed elsewhere, so verify the SDK Location inside Android Studio.

Solution 11: Restart Windows

If a stale process or port cannot be released cleanly, restart the computer.

After rebooting, test ADB before opening third-party Android software:

adb start-server adb devices

Solution 12: Restart ADB on macOS or Linux

The basic commands are the same:

adb kill-server adb start-server

Check remaining processes:

ps aux | grep adb

Check port 5037 on macOS:

lsof -iTCP:5037

On Linux:

ss -ltnp | grep 5037

Solution 13: Check Firewall and Security Software

Security software may block the ADB executable or local communication.

Do not permanently disable security software as your first troubleshooting step.

Instead, confirm:

• That the ADB executable comes from trusted Android SDK Platform Tools.
• That ADB has not been quarantined.
• That local communication is not being blocked.
• That an unrelated ADB executable has not been allowed instead.

Solution 14: Avoid Mixed Privilege Levels on Windows

If Android Studio is running normally, avoid unnecessarily launching another ADB process as Administrator.

Stop all ADB processes and restart ADB from the same normal development environment.

Difference Between “cannot connect to daemon” and “ADB server didn’t ACK”

They can appear together:

ADB server didn't ACK adb: cannot connect to daemon at tcp:5037

“ADB server didn’t ACK” indicates that the initial client/server response failed.

“cannot connect to daemon” indicates that the client ultimately has no usable ADB server connection.

For both errors, start with:

adb kill-server adb start-server

and then investigate port 5037 and duplicate ADB installations if necessary.

Difference Between “cannot connect to daemon” and “device offline”

If you see:

ABC123456789 offline

the host-side ADB server is already running and recognizes that the Android device exists.

With:

adb: cannot connect to daemon at tcp:5037

the problem is earlier in the communication chain, between the ADB client and server on the computer.

Difference Between “cannot connect to daemon” and “device unauthorized”

An unauthorized device appears as:

ABC123456789 unauthorized

In this situation the host-side ADB server is already working.

The physical device simply needs USB debugging authorization.

With “cannot connect to daemon,” repair the ADB server first.

Will Replacing the USB Cable Fix It?

If the specific error is:

adb: cannot connect to daemon at tcp:5037

the USB cable is usually not the first thing to investigate.

The host-side ADB server can start even when no Android device is connected.

Test:

adb start-server adb devices

If the daemon error occurs here, fix the computer-side ADB environment first.

Once ADB starts normally, troubleshoot the USB cable, driver, or USB debugging only if the physical device still does not appear.

Use Android Studio’s Connection Assistant After ADB Is Working

If the ADB server starts correctly but a physical device is still unavailable, open:

Tools → Troubleshoot Device Connections

The Connection Assistant can then help troubleshoot USB detection and USB debugging.

Recommended Windows Commands

where adb adb version tasklist | findstr adb netstat -ano | findstr 5037

Then, when needed:

adb kill-server taskkill /F /IM adb.exe adb start-server adb devices

Recommended macOS Commands

which adb adb version ps aux | grep adb lsof -iTCP:5037 adb kill-server adb start-server adb devices

Recommended Linux Commands

which adb adb version ps aux | grep adb ss -ltnp | grep 5037 adb kill-server adb start-server adb devices

How to Confirm That the Problem Is Fixed

Run:

adb kill-server adb start-server adb devices

A healthy result looks similar to:

* daemon not running; starting now at tcp:5037 * daemon started successfully * List of devices attached

If a physical device is connected and authorized, you should also see:

ABC123456789 device

If the Error Keeps Returning

If adb kill-server fixes the problem temporarily but the error soon returns, investigate the environment rather than repeatedly restarting ADB.

Check whether:

• where adb or which adb shows multiple ADB binaries.
• An obsolete Android SDK remains in PATH.
• A third-party Android Emulator runs its own ADB.
• Another process takes port 5037.
• Platform Tools are outdated.
• Elevated and non-elevated ADB processes are mixed.

If the Problem Still Occurs

If ADB “cannot connect to daemon” continues, check the following:

• Run adb kill-server and adb start-server.
• Check for stale ADB processes.
• Check whether another process owns TCP port 5037.
• Use where adb or which adb to detect multiple ADB installations.
• Make sure Android Studio and the terminal use the same ADB.
• Update Android SDK Platform Tools.
• Reinstall Platform Tools if necessary.
• Close third-party Android Emulators and device-management tools.
• Restart Android Studio.
• Restart the computer.
• Check whether security software is blocking ADB.

Summary

The ADB “cannot connect to daemon” error usually means that the ADB client cannot connect to the ADB server on the development computer.

Start with:

adb kill-server adb start-server adb devices

If that does not work, inspect port 5037 and check for multiple ADB installations.

On Windows:

where adb netstat -ano | findstr 5037

On macOS or Linux:

which adb lsof -iTCP:5037

A practical troubleshooting order is:

1. Restart the ADB server.
2. Terminate stale ADB processes.
3. Check which process owns port 5037.
4. Remove conflicts between multiple ADB versions.
5. Update Android SDK Platform Tools.
6. Reinstall Platform Tools if necessary.
7. Close third-party Android Emulators and device tools.
8. Restart Android Studio or the computer.

If where adb or which adb reveals multiple ADB installations, or another application repeatedly takes port 5037, simply restarting ADB may only provide a temporary fix.

Restore the ADB server to a state where adb devices runs without a daemon connection error first. After that, troubleshoot USB, drivers, or the Android Emulator only if the intended device is still missing.