How to Fix “ADB server didn’t ACK” in Android Studio

* daemon not running; starting now at tcp:5037 ADB server didn't ACK Full server startup log: ... adb: cannot connect to daemon at tcp:5037

What Does “ADB server didn’t ACK” Mean?

ADB consists of several components:

• The ADB client
• The ADB server on the development computer
• The ADB daemon on the Android device

When you run a command such as:

adb devices

the ADB client communicates with the host-side ADB server.

If the server is not already running, the client starts it. The server then listens for ADB client connections on local TCP port 5037. :contentReference[oaicite:10]{index=10}

A normal startup looks similar to:

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

If that startup or initial communication fails, you may instead see:

ADB server didn't ACK

Common Causes

1. An Old ADB Server Process Is Still Running

A previously started ADB process may remain in the background after an abnormal shutdown.

A new ADB client may then fail to communicate correctly with that existing process.

2. Multiple Android SDK Installations Exist

Android Studio may use a recent Platform Tools installation while the terminal launches an older ADB binary from another SDK directory.

Mixing different ADB versions can create server conflicts.

3. TCP Port 5037 Is Already in Use

The ADB server normally uses local TCP port 5037. :contentReference[oaicite:11]{index=11}

If another process already owns that port, ADB may not be able to start its server normally.

4. The ADB Server Is Temporarily Stuck

Long Android Studio sessions or repeated connection and disconnection of devices and Emulators can occasionally leave ADB in an unhealthy state.

5. Android SDK Platform Tools Are Old or Corrupted

ADB is part of Android SDK Platform Tools.

An outdated or partially damaged installation can cause startup or compatibility problems.

6. Another Android Development Tool Is Running Its Own ADB

Other software may bundle or launch ADB, including:

• Android gaming Emulators
• Phone-management tools
• Manufacturer debugging utilities
• Older Android development environments

If another tool launches a different ADB server, the two environments can conflict.

7. ADB Processes Are Running with Different Privileges

On Windows, mixing an administrator-launched ADB process with a normally launched ADB process can complicate process and port handling.

8. Security Software Blocks ADB

A firewall or security application can interfere with the ADB process or local TCP communication.

Solution 1: Restart the ADB Server

This is the first fix to try.

adb kill-server adb start-server

A successful startup looks like:

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

Then check connected targets:

adb devices

Google’s Android Studio device troubleshooting documentation also recommends restarting the ADB server when device connections are not working correctly. :contentReference[oaicite:12]{index=12}

Solution 2: Terminate Remaining ADB Processes

If adb kill-server does not stop the problematic process, inspect the operating system’s process list.

On macOS or Linux:

ps aux | grep adb

On Windows:

tasklist | findstr adb

If an unwanted ADB process remains, terminate it.

On Windows, when necessary:

taskkill /F /IM adb.exe

Then start ADB again:

adb start-server

Solution 3: Check Which Process Uses Port 5037

ADB normally listens on local TCP port 5037. :contentReference[oaicite:13]{index=13}

On macOS or Linux:

lsof -i :5037

or:

netstat -an | grep 5037

On Windows:

netstat -ano | findstr 5037

Use the PID from the output to identify the process:

tasklist /FI "PID eq 1234"

If an unrelated application is using port 5037, close that application and retry ADB.

Solution 4: Check Which adb Binary Is Being Used

Multiple Android SDK installations can cause the terminal to launch the wrong ADB.

On macOS or Linux:

which adb

On Windows:

where adb

If several paths are displayed, more than one ADB installation exists in your PATH.

For example:

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

Make sure an obsolete SDK is not being selected first.

Solution 5: Check the ADB Version

Run:

adb version

If several ADB binaries exist, use their full paths to compare versions.

Example on macOS:

~/Library/Android/sdk/platform-tools/adb version

Example on Windows:

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

Using the Platform Tools installation configured in Android Studio helps avoid version conflicts.

Solution 6: Update Android SDK Platform Tools

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

Google’s current Android Studio troubleshooting documentation recommends using the latest SDK Platform Tools when Android Studio cannot connect correctly to an Emulator. :contentReference[oaicite:14]{index=14}

After updating, restart ADB:

adb kill-server adb start-server adb devices

Solution 7: Reinstall Android SDK Platform Tools

If updating does not fix the problem, the Platform Tools installation may be damaged.

Remove and reinstall Android SDK Platform-Tools through SDK Manager.

Then test:

adb version adb start-server adb devices

Solution 8: Restart Android Studio

If ADB works inconsistently with Android Studio, close and reopen the IDE.

A useful sequence is:

1. Close Android Studio.
2. Run adb kill-server.
3. Confirm that no unwanted ADB process remains.
4. Run adb start-server.
5. Open Android Studio again.

Solution 9: Use Android Studio’s Connection Assistant

If physical-device connectivity is also affected, open:

Tools → Troubleshoot Device Connections

Android Studio’s Connection Assistant includes steps for rescanning USB devices, checking USB debugging, and restarting the ADB server. :contentReference[oaicite:15]{index=15}

Solution 10: Restart the Computer

If you cannot cleanly identify or terminate the process holding the ADB port, rebooting the computer can reset stale ADB processes and local port state.

After restarting, test ADB before opening multiple development tools:

adb start-server adb devices

Solution 11: Close Other Android Emulators and Device Tools

Other programs may start their own ADB instance.

Temporarily close software such as:

• Android gaming Emulators
• Phone-management applications
• Manufacturer debugging utilities
• Older Android SDK tools

Then restart ADB:

adb kill-server adb start-server

Solution 12: Remove Old ADB Installations from PATH

If which adb or where adb reports multiple copies, clean up your PATH.

Prefer the Platform Tools directory used by Android Studio.

A common location on macOS is:

~/Library/Android/sdk/platform-tools

A common Windows location is:

%LOCALAPPDATA%\Android\Sdk\platform-tools

Your SDK may be installed somewhere else, so verify the actual SDK location in Android Studio.

Solution 13: Run the Correct ADB by Full Path

If you do not want to change PATH immediately, invoke the Android Studio SDK’s ADB directly.

Example on macOS:

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

If this works while the plain adb command fails, another ADB installation in PATH is likely responsible.

Solution 14: Inspect Port 5037 Before Restarting ADB

If a normal restart repeatedly fails, inspect the port before trying again.

Windows:

netstat -ano | findstr 5037

macOS:

lsof -iTCP:5037

If a non-ADB process owns the port, close that program.

If an old ADB process owns it, normally stop it with:

adb kill-server

Solution 15: Check Firewall and Security Software

Security software may interfere with the ADB executable or local TCP communication.

Do not permanently disable security software as a first-line solution.

Instead, verify whether the trusted ADB binary from Android SDK Platform Tools is being blocked and configure an appropriate exception only when necessary.

Windows Troubleshooting Commands

On Windows, these commands are useful for diagnosing the environment:

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

If necessary, terminate a stuck ADB process:

taskkill /F /IM adb.exe

Then start the ADB binary from the Android Studio SDK again.

macOS Troubleshooting Commands

On macOS:

which adb adb version ps aux | grep adb lsof -iTCP:5037

If you installed ADB through multiple methods, such as Android Studio and another package manager, confirm which binary is actually running.

Linux Troubleshooting Commands

On Linux:

which adb adb version ps aux | grep adb ss -ltnp | grep 5037

Check for multiple Platform Tools installations and stale processes.

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

Several messages may appear together when the ADB server fails to start:

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

“ADB server didn’t ACK” indicates that the initial client-server communication did not complete correctly.

“cannot connect to daemon” can then appear because the ADB client has no working server to connect to.

For both errors, start by checking the host-side ADB server, port 5037, and duplicate ADB installations.

Difference Between “ADB server didn’t ACK” and “device offline”

If a device appears as:

ABC123456789 offline

the ADB server itself is already running and knows that the device exists.

“ADB server didn’t ACK” usually occurs earlier in the communication chain, on the development computer between the ADB client and server.

Therefore, restart the host-side ADB server and inspect port 5037 before focusing on USB debugging settings.

Difference Between “ADB server didn’t ACK” and “device unauthorized”

An unauthorized device appears as:

ABC123456789 unauthorized

In that situation, the ADB server is already functioning and the physical device simply needs USB debugging authorization.

With “ADB server didn’t ACK,” fix the host-side ADB server first.

How to Confirm That the ADB Server Is Working

Run:

adb start-server adb devices

A normal result may look like:

* daemon started successfully * List of devices attached ABC123456789 device

Even with no physical devices or Emulators connected, a working ADB server should normally return an empty device list rather than a server startup error:

List of devices attached

Recommended Steps When the Error Appears Suddenly

If ADB worked previously and suddenly fails, try this sequence:

1. Close Android Studio.
2. Run adb kill-server.
3. Check whether any ADB processes remain.
4. Check which process owns port 5037.
5. Run adb start-server.
6. Run adb devices.
7. Update Platform Tools if the problem remains.

If the Error Keeps Returning

If “ADB server didn’t ACK” repeatedly returns after temporary fixes, look for an environmental conflict rather than repeatedly restarting ADB.

Check whether:

• where adb or which adb shows multiple ADB installations.
• An Android gaming Emulator launches its own ADB.
• Another program owns TCP port 5037.
• An old Platform Tools directory remains in PATH.
• ADB is being launched with inconsistent administrator privileges.

If the Problem Still Occurs

If “ADB server didn’t ACK” continues, verify the following:

• Run adb kill-server and adb start-server.
• Check for remaining ADB processes.
• Check whether another process uses port 5037.
• Use which adb or where adb to locate every ADB binary.
• Check the current version with adb version.
• Update Android SDK Platform Tools.
• Reinstall Platform Tools if necessary.
• Restart Android Studio.
• Close other Android Emulators and phone-management software.
• Restart the computer.
• Check whether security software is blocking ADB.

Summary

The Android Studio “ADB server didn’t ACK” error usually means that the ADB client cannot correctly start or communicate with the ADB server on the development computer.

The ADB server normally listens on local TCP port 5037. :contentReference[oaicite:16]{index=16}

Start with:

adb kill-server adb start-server adb devices

If that does not fix the problem, use this troubleshooting order:

1. Check for stale ADB processes.
2. Check which process owns TCP port 5037.
3. Locate ADB with which adb or where adb.
4. Remove conflicts between multiple ADB installations.
5. Update Android SDK Platform Tools.
6. Reinstall Platform Tools if necessary.
7. Restart Android Studio or the computer.

Android Studio’s Connection Assistant also includes an option to restart the ADB server when device connections fail. :contentReference[oaicite:17]{index=17}

If multiple ADB binaries appear in your PATH or another process repeatedly takes port 5037, fixing that environment conflict is more effective than repeatedly restarting ADB.