October 1, 2026 10 min read

Android Studio on Ubuntu: Fixing “ADB Version Too Low,” Wi-Fi Pairing, and SDK/PATH Problems

Math and Programming

One of the more confusing Android development problems on Ubuntu is Android Studio reporting that the installed Android Debug Bridge (ADB) is too old, or that the current ADB does not support Wi-Fi pairing.

At first, the solution seems obvious: install a newer ADB.

In practice, the problem can be much more subtle. A Linux development machine may contain:

multiple Android SDK installations,
multiple copies of adb,
an old Ubuntu/Debian ADB package,
a newer Android Studio installation,
an SDK whose Platform-Tools have not actually been upgraded, and
an outdated sdkmanager that does not fully understand newer SDK metadata.

In the troubleshooting case described here, what originally looked like one problem was actually several independent problems layered on top of one another.

The short version

There were two major issues:

The wrong ADB was initially being selected. Ubuntu's system ADB, version 34.0.4-debian, was earlier in PATH than the ADB installed in the Android SDK.
After fixing PATH, the Android SDK's own ADB was still too old for the desired Wi-Fi pairing workflow. The SDK contained Platform-Tools 36.0.0, even though 37.0.1 was available.

There was also a related command-line tools issue:

Warning: This version only understands SDK XML versions up to 3 but an SDK XML file of version 4 was encountered.

That warning concerned sdkmanager, not ADB itself. It indicated that the Android SDK command-line tools were older than the SDK metadata they were being asked to process.

Android Studio is not the Android SDK

The first important concept is that Android Studio and the Android SDK are separate installations.

For example, Android Studio itself may be installed at:

/usr/local/android-studio/

while the Android SDK may be located at:

$HOME/Android/Sdk/

They have completely different purposes.

Android Studio is the IDE. It provides the editor, debugger, project integration, plugins, build UI, and other development features.

The Android SDK contains the actual development tools and platform packages, including:

Platform-Tools
ADB
Build Tools
Android platforms
Emulator components
command-line tools

ADB is installed as part of the SDK's platform-tools package.

A typical arrangement therefore looks like:

Android Studio
    |
    +-- uses Android SDK
            |
            +-- platform-tools/
            |       |
            |       +-- adb
            |
            +-- cmdline-tools/
                    |
                    +-- latest/
                            |
                            +-- bin/
                                    |
                                    +-- sdkmanager

ANDROID_HOME should point to the SDK, not Android Studio

A common configuration mistake is setting ANDROID_HOME to the Android Studio installation directory.

This is generally wrong:

export ANDROID_HOME="/usr/local/android-studio"

If the SDK is installed under your home directory, use:

export ANDROID_HOME="$HOME/Android/Sdk"

The corresponding ADB executable is then normally:

$HOME/Android/Sdk/platform-tools/adb

And sdkmanager is typically:

$HOME/Android/Sdk/cmdline-tools/latest/bin/sdkmanager

ANDROID_HOME versus ANDROID_SDK_ROOT

Older tutorials and existing shell configurations may contain both ANDROID_HOME and ANDROID_SDK_ROOT.

The critical point during troubleshooting is not the historical naming convention. It is making sure that Android Studio, your shell, ADB, and the SDK command-line tools are all referring to the same intended SDK installation.

Do not point either variable at the Android Studio application directory simply because that directory contains the words android-studio.

Problem 1: Ubuntu was using the wrong ADB

The first diagnostic showed:

adb is /usr/bin/adb
adb is /bin/adb

Android Debug Bridge version 1.0.41
Version 34.0.4-debian
Installed as /usr/lib/android-sdk/platform-tools/adb

This revealed that the shell was not using the ADB installed inside the user's Android SDK.

Instead, it was using Ubuntu/Debian's system Android SDK:

/usr/lib/android-sdk/platform-tools/adb

That version was:

34.0.4-debian

Why multiple ADB installations are common on Linux

An Ubuntu machine can acquire ADB from several different sources:

Android Studio's SDK Manager
Android SDK command-line tools
Ubuntu or Debian packages
a manually downloaded Platform-Tools archive
another Android development environment
an SDK left behind from an older installation

It is therefore entirely possible to have all of these at once:

/usr/bin/adb
/usr/lib/android-sdk/platform-tools/adb
/home/user/Android/Sdk/platform-tools/adb

They may all be different versions.

This is why simply running:

adb version

is not enough.

You also need to know which ADB executable produced that version number.

The most useful diagnostic: type -a adb

Run:

type -a adb

This shows every adb visible through your current PATH, in search order.

A desirable result looks like:

adb is /home/user/Android/Sdk/platform-tools/adb
adb is /usr/bin/adb
adb is /bin/adb

The first entry is the executable Bash will normally use.

So in this example:

/home/user/Android/Sdk/platform-tools/adb

wins over the older system copies.

PATH order determines which ADB wins

When you type:

adb

the shell searches directories in PATH from left to right.

If the effective order is:

/home/user/Android/Sdk/platform-tools:/usr/bin:/bin

then the Android SDK copy wins.

But if it is:

/usr/bin:/home/user/Android/Sdk/platform-tools:/bin

then the system copy wins.

This explains the very common situation:

I installed a newer ADB, but adb version still shows the old version.

Fixing ANDROID_HOME and PATH

A typical Bash configuration is:

export ANDROID_HOME="$HOME/Android/Sdk"
export PATH="$ANDROID_HOME/platform-tools:$PATH"

Add those lines to:

~/.bashrc

Then reload it:

source ~/.bashrc
hash -r

hash -r clears Bash's remembered executable locations. This is useful after modifying PATH.

A subtle .bashrc mistake

If you want to append a line to ~/.bashrc, this is wrong:

'export PATH="$ANDROID_HOME/platform-tools:$PATH"' >> ~/.bashrc

Bash attempts to execute the quoted text as a command.

You may see:

bash: export PATH="$ANDROID_HOME/platform-tools:$PATH": No such file or directory

The correct command is:

echo 'export PATH="$ANDROID_HOME/platform-tools:$PATH"' >> ~/.bashrc

Or simply edit ~/.bashrc directly.

Do not use a quoted tilde for ANDROID_HOME

Avoid:

export ANDROID_HOME="~/Android/Sdk"

Use:

export ANDROID_HOME="$HOME/Android/Sdk"

$HOME expands reliably to the current user's home directory.

Resolve symlinks too

If both:

/usr/bin/adb
/bin/adb

appear, they are not necessarily independent installations.

Many Linux distributions use a merged /usr filesystem layout where these paths may resolve to the same underlying file.

Check the real executable with:

readlink -f "$(which adb)"

After fixing PATH: ADB 36.0.0

After correcting the SDK and PATH configuration, the active ADB became:

$HOME/Android/Sdk/platform-tools/adb

and reported:

Android Debug Bridge version 1.0.41
Version 36.0.0-13206524

This was a major improvement over the original Ubuntu ADB version:

34.0.4-debian

But Android Studio still reported that the installed ADB did not support the Wi-Fi pairing workflow being used.

This exposed the second problem.

Problem 2: The SDK's own Platform-Tools were still old

The shell was now using the correct SDK.

But the SDK itself still contained:

Platform-Tools 36.0.0

while the SDK package list showed that:

Platform-Tools 37.0.1

was available.

So the situation was effectively:

Android Studio
    newer

Android SDK
    $HOME/Android/Sdk

Platform-Tools installed
    36.0.0

Platform-Tools available
    37.0.1

ADB actually present in platform-tools
    36.0.0-13206524

Installing a new Android Studio version does not automatically guarantee that every Android SDK component has also been upgraded.

Android Studio, Platform-Tools, Build Tools, SDK platforms, emulator packages, and command-line tools all have their own versions and can be updated independently.

Check installed and available Platform-Tools

Run:

"$ANDROID_HOME/cmdline-tools/latest/bin/sdkmanager" --list | grep "platform-tools"

In this case, the important discovery was essentially:

platform-tools | 36.0.0 | Android SDK Platform-Tools
platform-tools | 37.0.1 | Android SDK Platform-Tools

The installed version was still 36.0.0 even though 37.0.1 was available.

The important sdkmanager mistake

An earlier attempt had used:

~/Android/Sdk/cmdline-tools/latest/bin/sdkmanager --install

without specifying a package.

That did not explicitly request an upgrade of platform-tools.

When troubleshooting a specific SDK package, name it explicitly:

~/Android/Sdk/cmdline-tools/latest/bin/sdkmanager --install "platform-tools"

You can also accept SDK licenses with:

~/Android/Sdk/cmdline-tools/latest/bin/sdkmanager --licenses

Then explicitly request Platform-Tools again if necessary:

~/Android/Sdk/cmdline-tools/latest/bin/sdkmanager "platform-tools"

Check ADB immediately after installation

Do not rely on the shell's generic adb command yet.

Check the SDK copy directly:

~/Android/Sdk/platform-tools/adb version

After the successful update, it reported:

Android Debug Bridge version 1.0.41
Version 37.0.1-15733141

This confirms that the SDK itself now contains the upgraded Platform-Tools version.

The SDK XML version warning is a separate problem

During this process, sdkmanager may print:

Warning: This version only understands SDK XML versions up to 3
but an SDK XML file of version 4 was encountered.

This can be confusing because it appears while troubleshooting ADB.

However, it is a different issue.

It means the sdkmanager executable being used is old enough that it understands SDK XML metadata only through version 3, while newer Android tooling has produced or expects metadata using XML version 4.

The situation can look like:

New Android Studio
        |
        +-- newer SDK metadata
                 |
                 +-- XML version 4

Old command-line tools
        |
        +-- old sdkmanager
                 |
                 +-- understands XML only through version 3

The warning is therefore evidence that the Android SDK command-line tools and the newer Android Studio/SDK installation were released at different times.

Check sdkmanager itself

Run:

~/Android/Sdk/cmdline-tools/latest/bin/sdkmanager --version

Also inspect the installed command-line tools directories:

ls -la ~/Android/Sdk/cmdline-tools/

This is important because a directory named latest does not magically guarantee that its contents are actually the latest release. It is simply a directory used by the SDK installation.

If sdkmanager consistently produces the XML version warning, update the Android SDK Command-line Tools through Android Studio's SDK Manager so that the command-line tools are reasonably synchronized with the rest of the SDK.

Why USB debugging can work while Wi-Fi pairing fails

Another source of confusion is assuming that successful USB debugging proves that every ADB feature is supported.

These are related but distinct workflows:

ADB over USB
traditional TCP/IP wireless debugging
ADB pairing over Wi-Fi
newer Android Studio wireless debugging workflows

For example:

adb devices

may work perfectly while Android Studio still rejects the installed ADB for Wi-Fi pairing.

That does not necessarily mean USB debugging is broken. It can simply mean the host-side Platform-Tools version is too old for the newer wireless workflow Android Studio wants to use.

Android Studio may not use the same environment as your terminal

Even after the terminal shows the correct ADB, Android Studio may still behave differently.

A GUI application launched from the desktop does not necessarily inherit exactly the same environment as a Bash shell.

After changing SDK variables or PATH:

fully exit Android Studio,
start it again,
verify its configured Android SDK location.

Check:

Settings → Languages & Frameworks → Android SDK

Make sure the SDK location corresponds to the SDK containing the desired ADB.

For example:

$HOME/Android/Sdk

and therefore:

$HOME/Android/Sdk/platform-tools/adb

Compare this with the terminal:

echo "$ANDROID_HOME"
which adb
type -a adb
adb version

If Android Studio still complains, inspect its logs

If:

~/Android/Sdk/platform-tools/adb version

shows 37.0.1 but Android Studio still reports that its ADB is too old, do not keep reinstalling Platform-Tools blindly.

Instead, inspect Android Studio's log:

Help → Show Log in Files

Search for terms such as:

adb
platform-tools
wifi

If Android Studio is invoking:

/usr/lib/android-sdk/platform-tools/adb

while your terminal is using:

/home/user/Android/Sdk/platform-tools/adb

then the problem is not that ADB 37.0.1 failed to install.

The problem is that Android Studio is using a different SDK or executable.

Restart the ADB server after changing Platform-Tools

ADB consists of several components:

the ADB client on the development machine,
the ADB server on the development machine, and
adbd running on the Android device.

After changing ADB versions, restart the host-side server:

adb kill-server
adb start-server
adb version
adb devices

This prevents an already-running ADB server started by an older executable from adding another source of confusion.

Do not immediately uninstall Ubuntu's old ADB

Once you discover an old copy such as:

/usr/bin/adb

or:

/usr/lib/android-sdk/platform-tools/adb

it can be tempting to uninstall it immediately.

That is often unnecessary.

If:

type -a adb

shows:

adb is /home/user/Android/Sdk/platform-tools/adb
adb is /usr/bin/adb
adb is /bin/adb

then the desired Android SDK ADB is already first in the shell's search order.

The older package can often remain installed without interfering with normal development.

A safer sequence is:

identify all ADB installations,
determine which one is active,
determine which SDK Android Studio uses,
put that SDK's platform-tools first in PATH,
restart Android Studio and ADB,
remove old packages only if there is an actual reason to do so.

If the device itself is still missing

An ADB version problem and a Linux USB-permission problem are different issues.

If ADB is correctly installed but:

adb devices

does not show the physical device, investigate:

USB debugging on the Android device,
the USB cable and USB mode,
plugdev group membership,
udev rules, and
the device's authorization dialog.

On Ubuntu, you may need:

sudo usermod -aG plugdev $LOGNAME

After changing group membership, log out and back in before testing again.

Ubuntu also provides Android device udev rules through packages such as:

android-sdk-platform-tools-common

Then test again:

adb devices

How to inspect every ADB installation

Start with:

type -a adb
which adb
readlink -f "$(which adb)"
adb version

Then check the SDK version directly:

"$ANDROID_HOME/platform-tools/adb" version

You can also search the SDK tree for ADB executables:

find "$HOME/Android/Sdk" \
  -path '*/platform-tools/adb' \
  -type f \
  -exec sh -c 'echo "=== $1"; "$1" version' _ {} \;

Common symptoms and what they actually mean

Symptom	Likely cause	What to check
ADB version is unexpectedly old	Another ADB appears earlier in `PATH`	`type -a adb`
`ANDROID_HOME` points to Android Studio	The IDE and SDK have been confused	Point it to the actual SDK directory
ADB reports `34.x-debian`	Ubuntu/Debian's packaged ADB is being used	`readlink -f "$(which adb)"`
ADB is 36.0.0 but Android Studio still rejects Wi-Fi pairing	The SDK's Platform-Tools are still too old for the required workflow	Check available Platform-Tools versions
37.0.1 appears in `sdkmanager --list` but ADB remains 36.0.0	The package is available but was not actually installed	`sdkmanager --install "platform-tools"`
`sdkmanager --install` changes nothing	No package was explicitly requested	Specify `"platform-tools"`
SDK XML version 4 warning appears	The command-line tools are older than the SDK metadata	`sdkmanager --version`
Changing `PATH` appears ineffective	Bash may have cached an old executable location	`hash -r`
Terminal uses new ADB but Android Studio does not	Android Studio is using another SDK or environment	Check Android Studio's SDK location and logs
`/bin/adb` and `/usr/bin/adb` both appear	They may resolve to the same executable	`readlink -f`
ADB is current but no physical device appears	USB permissions, udev, cable, authorization, or device configuration	`adb devices` and Ubuntu device setup

Complete diagnostic checklist

If Android Studio reports that ADB is too old or does not support Wi-Fi pairing, run these checks in order:

# 1. Which ADB will the shell use?
which adb

# 2. Show every ADB available through PATH
type -a adb

# 3. Resolve symlinks
readlink -f "$(which adb)"

# 4. Check the active ADB version
adb version

# 5. Check the configured SDK
echo "$ANDROID_HOME"

# 6. Check the SDK ADB directly
"$ANDROID_HOME/platform-tools/adb" version

# 7. Check sdkmanager itself
"$ANDROID_HOME/cmdline-tools/latest/bin/sdkmanager" --version

# 8. Check installed/available Platform-Tools
"$ANDROID_HOME/cmdline-tools/latest/bin/sdkmanager" --list | grep "platform-tools"

# 9. Accept licenses if necessary
"$ANDROID_HOME/cmdline-tools/latest/bin/sdkmanager" --licenses

# 10. Explicitly install/update Platform-Tools
"$ANDROID_HOME/cmdline-tools/latest/bin/sdkmanager" --install "platform-tools"

# 11. Verify the SDK ADB immediately
"$ANDROID_HOME/platform-tools/adb" version

# 12. Clear Bash's executable cache
hash -r

# 13. Restart the ADB server
adb kill-server
adb start-server

# 14. Check the final active version
adb version

# 15. Check connected devices
adb devices

Then completely restart Android Studio and verify its configured SDK directory.

The actual progression in this troubleshooting case

Stage 1: Ubuntu's ADB

/usr/lib/android-sdk/platform-tools/adb

Version 34.0.4-debian

The problem was that this copy appeared first in the effective executable search path.

Stage 2: Correct SDK, but still-old Platform-Tools

After correcting ANDROID_HOME and PATH:

$HOME/Android/Sdk/platform-tools/adb

Version 36.0.0-13206524

This fixed the wrong-ADB problem, but it did not resolve the newer Wi-Fi pairing requirement.

Stage 3: Platform-Tools update discovered

The SDK package list showed:

Installed:
    platform-tools 36.0.0

Available:
    platform-tools 37.0.1

The important detail was that simply running:

sdkmanager --install

had not explicitly requested Platform-Tools.

Stage 4: Explicit Platform-Tools installation

~/Android/Sdk/cmdline-tools/latest/bin/sdkmanager \
    --install "platform-tools"

Afterward:

~/Android/Sdk/platform-tools/adb version

Android Debug Bridge version 1.0.41
Version 37.0.1-15733141

Stage 5: sdkmanager warning identified separately

Warning: This version only understands SDK XML versions up to 3
but an SDK XML file of version 4 was encountered.

This did not mean that Platform-Tools 37.0.1 had somehow reverted.

It identified another outdated component: the Android SDK command-line tools containing sdkmanager.

The correct diagnostic was:

~/Android/Sdk/cmdline-tools/latest/bin/sdkmanager --version

The most important lesson

“ADB version too low” is not always one problem.

In this case, several independent conditions existed:

Multiple ADB installations existed on the same Ubuntu machine.
The older Ubuntu/Debian ADB initially won the PATH search.
Fixing PATH exposed the Android SDK's own ADB.
That ADB was still only version 36.0.0.
Platform-Tools 37.0.1 was available but had not actually been installed.
sdkmanager --install without specifying platform-tools did not perform the desired explicit upgrade.
The SDK command-line tools were old enough to warn that they understood SDK XML only through version 3 while encountering XML version 4.
Android Studio still needed to be checked to ensure it was using the same SDK as the terminal.

The best troubleshooting question is therefore not:

What version of ADB is installed?

Instead ask:

Which ADB is being used, which SDK does it belong to, what exact Platform-Tools version is installed there, and is Android Studio using that same SDK?

On Linux, keeping these components aligned prevents a large class of Android development problems:

Android Studio SDK location
ANDROID_HOME
PATH order
Platform-Tools version
ADB executable location
SDK Command-line Tools version

Once those agree, errors that initially look like mysterious Android Studio failures usually become much easier to diagnose.

References

Android Developers — Android Debug Bridge (adb)
Android Developers — SDK Platform-Tools release notes
Android Developers — Introducing fast and reliable wireless debugging with ADB Wi-Fi 2.0
Android Developers — Run apps on a hardware device

Comments

No comments yet. Leave the first one.

The short version

Android Studio is not the Android SDK

ANDROID_HOME should point to the SDK, not Android Studio

ANDROID_HOME versus ANDROID_SDK_ROOT

Problem 1: Ubuntu was using the wrong ADB

Why multiple ADB installations are common on Linux

The most useful diagnostic: type -a adb

PATH order determines which ADB wins

Fixing ANDROID_HOME and PATH

A subtle .bashrc mistake

Do not use a quoted tilde for ANDROID_HOME

Resolve symlinks too

After fixing PATH: ADB 36.0.0

Problem 2: The SDK's own Platform-Tools were still old

Check installed and available Platform-Tools

The important sdkmanager mistake

Check ADB immediately after installation

The SDK XML version warning is a separate problem

Check sdkmanager itself

Why USB debugging can work while Wi-Fi pairing fails

Android Studio may not use the same environment as your terminal

If Android Studio still complains, inspect its logs

Restart the ADB server after changing Platform-Tools

Do not immediately uninstall Ubuntu's old ADB

If the device itself is still missing

How to inspect every ADB installation

Common symptoms and what they actually mean

Complete diagnostic checklist

The actual progression in this troubleshooting case

Stage 1: Ubuntu's ADB

Stage 2: Correct SDK, but still-old Platform-Tools

Stage 3: Platform-Tools update discovered

Stage 4: Explicit Platform-Tools installation

Stage 5: sdkmanager warning identified separately

The most important lesson

References

Leave a comment