Android Command-line Tools
Android SDK manager and package tools
Install with Homebrew
brew install --cask android-commandlinetoolsQuick Take: Android Command-line Tools
If you need Google's SDK on a Mac without paying the Android Studio disk tax, build 15859902 Command-Line Tools are the right default in August 2026. Homebrew's android-commandlinetools cask, arm64 zips, and JDK 17 compatibility with Quail 3 / AGP 9.x make headless and hybrid setups straightforward. Skip them only when you exclusively need IDE UI surfaces; even then, keep one shared SDK root.
Best For
- •CI engineers provisioning macOS Android builders
- •Flutter and React Native developers who edit outside Studio
- •Kotlin Multiplatform authors sharing one SDK pin list
- •Students and indie devs on small SSD MacBooks
- •Teams automating emulators with avdmanager
What are Android SDK Command-Line Tools?
Android SDK Command-Line Tools are Google's official headless SDK utilities for Mac developers who build Android software without living inside Android Studio. The package centers on sdkmanager (install and update SDK components), avdmanager (create and manage Android Virtual Devices), and apkanalyzer (inspect APK and AAB composition). In August 2026 the current macOS zips are commandlinetools-mac_x86_64-15859902_latest.zip and commandlinetools-mac_arm64-15859902_latest.zip. Homebrew ships the same line as the android-commandlinetools cask. The older android-sdk cask is discontinued, so new installs should use this package instead of chasing archived formulas. You still need a JDK. Teams targeting Android Studio Quail 3 (2026.1.3), Android Gradle Plugin 9.x, and Gradle 9.x typically standardize on JDK 17. The tools themselves are free under the Android SDK license. They run natively on Apple Silicon and on macOS Tahoe 26.x. Intel Macs still get an x86_64 zip; Apple Silicon Macs should prefer the arm64 zip so emulator and host tooling stay aligned. Pick Command-Line Tools when CI runners, Flutter or React Native scaffolding, Kotlin Multiplatform shared builds, or a disk-tight MacBook Air need an SDK root without a multi-gigabyte IDE. Keep Android Studio when you want the visual layout editor, profiler UI, and Gemini agent workflows in one window. Many Mac setups install both: Studio for interactive work, cmdline-tools on PATH for scripts and agents. Operationally, treat the SDK root like a versioned artifact. Record the cmdline-tools build number (15859902 today), the JDK version, and the sdkmanager package list beside your Gradle wrapper. That trio explains most 'cannot find android.jar' failures on fresh Macs. If Studio and Terminal disagree, it is usually two roots, not a broken install.
Closer look: Headless Android SDKs on Apple Silicon Macs
Why build 15859902 matters for Mac paths, how Homebrew's cask maps to Google's zip layout, and when cmdline-tools should replace a full Studio install.
History & Background
Google split the old monolithic SDK tools into versioned cmdline-tools so multiple releases could sit side by side. Mac developers previously fought PATH collisions between Studio-bundled tools and manual installs. Homebrew's android-commandlinetools cask made the headless path ordinary for Flutter and CI users. The discontinued android-sdk cask marked the end of the older layout. Build 15859902 continues that versioned model with explicit x86_64 and arm64 Mac zips. Before this split, Mac instructions often mixed SDK Tools, SDK Platform-Tools, and Studio paths until PATH order decided which binary won. Teaching repos for Flutter on Mac now default to cmdline-tools language in README files. Enterprise images that still mention android-sdk from Homebrew should be treated as stale runbooks.
How It Works
A correct Mac SDK root contains cmdline-tools/<version>/bin with a latest symlink or folder, plus platforms, build-tools, platform-tools, and optional system-images. sdkmanager mutates that tree. avdmanager writes AVD configs under the AVD home (often ~/.android/avd). Gradle reads ANDROID_SDK_ROOT and local.properties. On Apple Silicon, arm64 host tools plus ARM system images avoid translating both the emulator and the SDK binaries. Keep disk pressure visible: du -sh $ANDROID_SDK_ROOT after each major platform add. Students on 256GB machines should delete unused system-images with sdkmanager --uninstall when a course ends. CI caches should key on the pin file hash so a platform bump invalidates correctly.
Ecosystem & Integrations
Flutter, React Native, Kotlin Multiplatform, and plain Gradle Android apps all consume the same SDK root. Quail 3 users often keep Studio installed for UI work while CI uses only cmdline-tools. apkanalyzer bridges release engineering scripts and the IDE's APK Analyzer. Platform-Tools remain a separate package ID even though people colloquially say 'install the SDK'. React Native's Android environment documentation assumes platform-tools are present; install them explicitly even if you never open an emulator. KMP samples often require a minimum compileSdk that forces a newer platforms;android-* package than tutorials from 2024 mention. Re-read the project's Gradle files before copying package lists from blog posts.
Future Development
Expect continued AGP 9.x and Gradle 9.x alignment notes in Studio release channels, with cmdline-tools builds publishing on Google's download hub. Teams should keep pinning package IDs rather than trusting floating latest aliases on Mac runners. Watch Homebrew cask bumps when Google publishes newer than 15859902. When Quail 4 canary notes mention toolchain changes, re-check JDK recommendations before upgrading shared Mac images. AGP ranges spanning 7.1 through 9.3 still appear in older maintenance branches, so cmdline-tools must serve both modern and legacy package needs inside one SDK root.
Key Features
sdkmanager
sdkmanager lists, installs, updates, and uninstalls SDK packages from a terminal. Typical installs include platforms;android-35 or android-36, build-tools, system images, and platform-tools. In CI you pin exact package IDs so every runner resolves the same bits. --licenses walks the license set; yes | sdkmanager --licenses is the usual non-interactive pattern on Mac build agents.
avdmanager
avdmanager creates and deletes Android Virtual Devices without opening Studio's Device Manager. You pick a device profile, a system image, and hardware options from flags or config files. CI jobs often create a disposable AVD, boot it with the emulator binary, run instrumented tests, then wipe the AVD so disk use stays predictable on shared Mac runners.
apkanalyzer
apkanalyzer reports how an APK or AAB spends bytes: dex, resources, assets, and native libraries. Mac release engineers use it before store uploads to catch size regressions after dependency bumps. It complements Android Studio's APK Analyzer when you want the same numbers in a shell pipeline or pull-request check.
Native Apple Silicon packages
Build 15859902 publishes separate x86_64 and arm64 macOS zips. On M-series Macs, the arm64 package avoids Rosetta overhead for host tools. Pair it with ARM system images when you run the emulator so the whole stack stays native on Apple Silicon under macOS Tahoe 26.x.
Homebrew cask path
brew install --cask android-commandlinetools is the common Mac install. On Apple Silicon the cask lands under /opt/homebrew/share/android-commandlinetools. Point ANDROID_HOME (or ANDROID_SDK_ROOT) at that root and put cmdline-tools/latest/bin on PATH. Do not reinstall the discontinued android-sdk cask; it is not the supported distribution in 2026.
CI-friendly licenses and offline mirrors
Headless Macs can accept licenses non-interactively and cache packages for offline or air-gapped jobs. sdkmanager supports channel selection and package filters so a Flutter job pulls NDK pieces while a pure Kotlin library job stays on platforms and build-tools only. That keeps runner images smaller than a full Studio DMG.
Works with AGP and Gradle 9.x
Command-Line Tools stay compatible with Android Gradle Plugin ranges teams still see in the wild (historically 7.1 through current 9.3 docs) and with Gradle 9.x when the JDK matches. Quail 3 (2026.1.3) users who keep Studio for editing can still drive the same SDK root from Gradle on the command line.
License and offline workflow
The tools are free subject to the Android SDK license. You can pre-seed licenses and packages into a shared volume or Docker layer used by Mac CI. Students on a 256GB Air benefit because they install only the platforms they need instead of the full IDE footprint.
Who Should Use Android Command-line Tools?
1Flutter or React Native Mac developer
A cross-platform developer on an M3 MacBook needs Android builds without living in Studio. They install android-commandlinetools via Homebrew, accept licenses, then sdkmanager platform-tools plus one platform and build-tools revision. Flutter doctor or React Native's environment checks resolve ANDROID_HOME. Day to day they edit in VS Code or Cursor and only open Studio when a layout or profiler task demands it.
2CI engineer on macOS runners
A platform team maintains GitHub Actions or Buildkite agents on Mac minis. The image installs JDK 17 and android-commandlinetools, exports ANDROID_SDK_ROOT, and runs yes | sdkmanager --licenses during provision. Each workflow pins package IDs for the app's compileSdk. avdmanager creates an AVD for instrumentation when required; otherwise jobs stay on unit tests and lint to save minutes.
3Emulator automation specialist
A QA engineer scripts cold boots and snapshot restores. avdmanager defines devices from a checked-in config. The emulator binary from the SDK starts headless with -no-window on CI, or with a window on a desk Mac. apkanalyzer runs after assembleRelease to fail the job if the APK grows beyond a budget.
4Kotlin Multiplatform shared-module owner
A KMP library publishes Android targets from a Mac laptop. The owner keeps a slim SDK root with platforms and build-tools only, no Studio UI plugins. Gradle sync uses the same ANDROID_HOME locally and in CI, which cuts 'works on my machine' drift between Apple Silicon laptops and Linux agents that share package IDs.
5Student on a 256GB MacBook Air
A student cannot spare Android Studio's full install size. They install Command-Line Tools, one platform image, and platform-tools. Assignments build with Gradle from Terminal. When a course module needs the Layout Inspector they borrow a lab machine with Studio, then return to the slim SDK on the Air for daily compiles.
How to Install Android SDK Command-Line Tools on Mac
Four steps cover a typical Apple Silicon Mac: install JDK 17, install the tools (Homebrew or zip), set environment variables, then install packages and accept licenses. macOS Tahoe 26.x is supported for native arm64 hosts.
Install JDK 17
Install a JDK 17 distribution such as Temurin or Homebrew openjdk@17. Confirm with java -version. AGP 9.x and Gradle 9.x workflows used with Quail 3 expect 17 as the default toolchain unless your project documents otherwise.
Install Command-Line Tools
Preferred: brew install --cask android-commandlinetools. Manual: download commandlinetools-mac_arm64-15859902_latest.zip (Apple Silicon) or the x86_64 zip (Intel) from Google's Android Studio download page, then unpack into a versioned cmdline-tools directory as documented by Google so sdkmanager resolves cmdline-tools/latest.
Set environment variables
Export ANDROID_HOME or ANDROID_SDK_ROOT to your SDK root (Homebrew Apple Silicon default: /opt/homebrew/share/android-commandlinetools). Add $ANDROID_HOME/cmdline-tools/latest/bin and $ANDROID_HOME/platform-tools to PATH in ~/.zshrc. Open a new terminal and verify sdkmanager --version.
Install packages and accept licenses
Run yes | sdkmanager --licenses. Then install what your project needs, for example: sdkmanager "platform-tools" "platforms;android-35" "build-tools;35.0.0". Add system images only if you will use the emulator. Keep a text pin list in your repo for CI parity.
Pro Tips
- • Prefer a single SDK root shared by Studio and CLI to avoid duplicate platform downloads.
- • Pin package revisions in CI; floating latest tags cause surprise breakages across agents.
- • On Apple Silicon, install ARM system images when you use the emulator.
Configuration Tips
Single SDK Root
Point both Android Studio and your shell at one ANDROID_SDK_ROOT. Duplicate roots waste tens of gigabytes and produce mismatched build-tools. After Homebrew install, open Studio once and set the SDK location to the same path if Studio created a second default under ~/Library/Android/sdk.
Pin Versions
Check a packages.txt into the repo listing exact sdkmanager IDs. CI runs sdkmanager --package_file=packages.txt (or equivalent install loop). Developers run the same file after cloning. This matches the discipline of Gradle version catalogs.
Prefer ARM Emulator Images
On Apple Silicon Macs, install google_apis or google_apis_playstore ARM system images. x86 images under emulation are slower and more fragile on Tahoe. Verify with avdmanager list target and sdkmanager --list | rg system-images before creating AVDs.
Alternatives to Android Command-line Tools
Command-Line Tools sit between a full IDE and single-purpose device bridges. Choose based on whether you need UI tooling or only SDK/device access.
Android Studio
Full IDE with editors, profilers, Device Manager UI, and Gemini agent features. Heavier disk and RAM cost. Use when you need visual Android tooling; keep cmdline-tools for scripts.
Platform-Tools only
adb and fastboot without sdkmanager. Fine for device debugging when the SDK is already provisioned elsewhere. Not enough to bootstrap platforms and build-tools alone.
Docker Android images
Container images bundle SDK pieces for Linux CI. On Mac, Docker usually runs Linux VMs, so native Mac Gradle UX still prefers host cmdline-tools. Useful for reproducible Linux agents, weaker for macOS-native GUI emulation.
Pricing
Android SDK Command-Line Tools are free to download and use under Google's Android SDK license. There is no paid tier for sdkmanager, avdmanager, or apkanalyzer. You pay only for your own hardware, CI minutes, and optional commercial IDEs. Homebrew distribution does not add a fee.
Pros
- ✓Official Google SDK utilities without requiring the full Android Studio IDE
- ✓Native arm64 and x86_64 macOS packages at build 15859902
- ✓Homebrew cask android-commandlinetools for straightforward Mac installs
- ✓Works with Quail 3, AGP 9.x, Gradle 9.x, and JDK 17 toolchains
- ✓CI-friendly license acceptance and package pinning
- ✓Smaller disk footprint than a full Studio install on 256GB machines
- ✓apkanalyzer supports scriptable size budgets in release pipelines
- ✓Same SDK root can be shared with Android Studio when you need a GUI later
Cons
- ✗No visual layout editor, profiler UI, or Gemini agent features
- ✗Initial SDK package downloads still consume substantial disk once platforms and images are added
- ✗License prompts must be automated correctly or CI fails on first run
- ✗Directory layout mistakes (missing cmdline-tools/latest) confuse newcomers
- ✗Emulator performance still depends on choosing appropriate system images on Apple Silicon
Community and Support
Primary documentation lives on developer.android.com under Studio command-line tools, sdkmanager, and related tool pages. Homebrew maintains the android-commandlinetools cask formula for Mac packaging issues. Issue discussion for SDK tooling appears across Android issue trackers, Stack Overflow tags like android-sdk and sdkmanager, and team Slack/Discord channels for Flutter and React Native. Google still treats Studio release notes as the north star when AGP and cmdline-tools expectations change.
Frequently Asked Questions about Android Command-line Tools
About the Author
Expert Tips for Android Command-line Tools
Treat cmdline-tools/latest as sacred: if you unpack zips manually and skip Google's versioned folder layout, sdkmanager looks broken when the binaries are actually fine.
On a 256GB Air, install platforms and one build-tools revision first; add emulator system images only when a course or project requires them.
Share one ANDROID_SDK_ROOT between Studio and Terminal. Dual roots are the usual reason Mac disks fill with duplicate system images.
Related Technologies & Concepts
Related Topics
Android development on Mac
Tooling for building Android apps on macOS including IDE and SDK utilities.
Cross-platform mobile
Flutter and React Native Android target setup on developer Macs.
Sources & References
Fact-CheckedLast verified: Aug 9, 2026
Key Verified Facts
- Mac packages include commandlinetools-mac_x86_64-15859902_latest.zip and commandlinetools-mac_arm64-15859902_latest.zip.[cite-7, cite-1]
- Homebrew distributes the tools via the android-commandlinetools cask; the older android-sdk cask is discontinued.[cite-3]
- sdkmanager, avdmanager, and related CLIs are documented as Android's official command-line SDK tools.[cite-1, cite-2]
- The tools are free to use under the Android SDK licensing model.[cite-1, cite-7]
- Platform-tools (adb/fastboot) are commonly installed into the same SDK root via sdkmanager.[cite-5, cite-6]
- 1Android Studio command-line tools
Accessed Aug 9, 2026
"Official overview of cmdline-tools components including sdkmanager and related utilities."
- 2sdkmanager documentation
Accessed Aug 9, 2026
"Package install, license, and listing flags for sdkmanager."
- 3Homebrew android-commandlinetools cask
Accessed Aug 9, 2026
"Cask metadata for Mac distribution via Homebrew."
- 4Android Studio download / intro
Accessed Aug 9, 2026
"Studio and SDK tooling entry points for developers."
- 5Platform-Tools releases
Accessed Aug 9, 2026
"Companion platform-tools often installed beside cmdline-tools."
- 6adb tool documentation
Accessed Aug 9, 2026
"Device bridge typically installed via sdkmanager platform-tools package."
- 7Android Studio landing
Accessed Aug 9, 2026
"Download hub referencing command-line tools packages for Mac."
- 8IntelliJ Community (Studio lineage)
Accessed Aug 9, 2026
"Upstream IntelliJ platform lineage relevant to Android Studio pairing."
Research queries: Android SDK command-line tools 15859902 mac; Homebrew android-commandlinetools cask; sdkmanager JDK 17 AGP 9 macOS Tahoe