How to Set Up Android Command-Line Tools on macOS With `sdkmanager` and `adb` That Actually Work

The trap: Android setup guides often assume Android Studio already fixed everything for you. But when you need repeatable command-line tooling on a Mac for CI, Flutter, React Native, or native Android work, you want a setup you actually understand.

What you are really installing

A useful Android command-line environment on macOS usually means:

1. Android command-line tools
2. sdkmanager
3. platform-tools including adb
4. one or more Android platforms and build tools
5. optionally the emulator and a system image

If any one of those layers is missing, the errors get misleading quickly.

Step 1: create a stable SDK location

Pick a predictable directory:

mkdir -p "$HOME/Library/Android/sdk"

This is a common location on macOS and keeps the setup easy to reason about.

Step 2: install Android command-line tools

Download the official command-line tools package from Android Developers, then unzip it into a cmdline-tools/latest layout.

Example:

mkdir -p "$HOME/Library/Android/sdk/cmdline-tools"
cd "$HOME/Library/Android/sdk/cmdline-tools"
unzip ~/Downloads/commandlinetools-mac-*.zip
mv cmdline-tools latest

That final directory shape matters. A lot of broken setups happen because the extracted folder names do not match what sdkmanager expects.

Step 3: set environment variables and PATH

Add this to ~/.zshrc:

export ANDROID_SDK_ROOT="$HOME/Library/Android/sdk"
export PATH="$ANDROID_SDK_ROOT/cmdline-tools/latest/bin:$PATH"
export PATH="$ANDROID_SDK_ROOT/platform-tools:$PATH"
export PATH="$ANDROID_SDK_ROOT/emulator:$PATH"

Reload the shell:

source ~/.zshrc

Check that sdkmanager is visible:

sdkmanager --list

Step 4: accept licenses

Before installing packages, accept the Android SDK licenses:

yes | sdkmanager --licenses

This is one of those small commands that saves a lot of later confusion in local builds and CI.

Step 5: install the packages you actually need

At minimum, install platform tools:

sdkmanager "platform-tools"

Then install one Android platform and matching build tools. Example:

sdkmanager "platforms;android-35" "build-tools;35.0.0"

If you need the emulator:

sdkmanager "emulator" "system-images;android-35;google_apis;arm64-v8a"

Step 6: create and boot a virtual device

List available device profiles:

avdmanager list device

Create an emulator:

avdmanager create avd -n Pixel_8_API_35 -k "system-images;android-35;google_apis;arm64-v8a"

Start it:

emulator -avd Pixel_8_API_35

Then confirm adb sees it:

adb devices

The most common breakpoints

sdkmanager: command not found

Usually means:

• PATH does not include cmdline-tools/latest/bin
• the extracted folder structure is wrong
• shell config was not reloaded

adb: command not found

Usually means:

• platform-tools was not installed
• PATH does not include the platform-tools directory

Licenses not accepted

This breaks Gradle and Flutter builds more often than people expect. Run:

yes | sdkmanager --licenses

again and verify.

Emulator is painfully slow or unstable

On Apple Silicon, make sure you are using the correct ARM64 system image. Wrong image selection is a classic “the emulator exists, but the experience is terrible” mistake.

Why this matters outside native Android

Flutter, React Native, and other mobile toolchains often depend on the same Android SDK foundation. If your base command-line environment is shaky, every higher-level tool looks buggy even when it is not.

Final advice

Do not judge the setup as “done” when sdkmanager --list works. Judge it as done when all three of these succeed:

sdkmanager --list
adb devices
emulator -list-avds

That is the moment the environment becomes real, not theoretical.

Sources

• Android command-line tools docs
• Android environment variables and SDK tools
• avdmanager and sdkmanager docs