Version-aligned checklist for Android Studio, AGP 9.2, Gradle 9.4.1, JDK 17 and ARM64 emulator on Apple Silicon…
Join developers getting comprehensive guides, code examples, optimization tips, and time-saving prompts to accelerate their development workflow.
No spam. Unsubscribe anytime.
I spent the better part of a morning recently helping a developer get an Android project building on a new MacBook Pro with an M4 chip. The hardware was not the issue — M-series Macs are more than fast enough for Android work. The issue was version drift. Android Studio, AGP, Gradle, Kotlin, Compose, SDK packages, emulator images, and JDK requirements all move on slightly different schedules, and when you set up a machine from memory or from a guide that is even six months old, you end up fighting mismatched versions for half a day instead of writing code.
This post is the baseline I would use today for a new native Android app on a MacBook with Apple Silicon. The date matters here: this reflects the current stable stack as of June 3, 2026.
If you want the shortest possible recommendation, use this:
system-images;android-36;google_apis;arm64-v8aIf you follow that matrix, you are aligned with the current Android toolchain instead of fighting mismatched versions. The rest of this post explains where each of those numbers comes from and how to get everything running.
Before touching any SDK packages or build configuration, you need to make sure you are running the right build of Android Studio itself. On Apple Silicon, that distinction matters more than it sounds.
As of June 3, 2026, the stable Mac ARM download on the official Android Studio page is:
android-studio-quail1-mac_arm.dmgThe reason to be explicit about the ARM version is that there are two downloads on the Android Studio page — one for Intel, one for Apple Silicon. On an M-series Mac, you want the native ARM build. Running the Intel version under Rosetta works, but it is slower, and the emulator story gets more complicated when the host process and the emulator images are not aligned on architecture.
If you prefer working in Cursor, VS Code, or another editor, you can still install only the command-line tools and skip Android Studio as your daily driver. But knowing which version of Studio corresponds to the current stable toolchain is useful context even if you never open it.
For developers who prefer a terminal-first workflow, the Android SDK does not require Android Studio at all. The current macOS command-line tools package listed by Google is:
commandlinetools-mac-14742923_latest.zipThat package gives you sdkmanager, avdmanager, and the rest of the Android SDK command-line toolchain. Once installed, everything else flows through those tools rather than through the Studio UI.
This is the setup I prefer when the main workflow looks like this:
Editor
Terminal
Gradle wrapper
Android SDK command-line tools
Real device and/or emulator
Android Studio still earns its place for certain tasks. SDK bootstrapping, emulator setup, Compose previews, Logcat, the profiler, and deeper device debugging are all easier in Studio than in a terminal. But none of those are daily-driver requirements for most projects. The command-line tools give you the full SDK surface without making Studio a dependency.
The most important compatibility anchor in the Android toolchain is the Android Gradle Plugin release. Everything else — Gradle version, JDK, Build Tools, SDK level — is documented relative to the AGP version. Getting that number right first is what keeps the rest of the stack from fighting itself.
As of the current AGP 9.2.0 release, Google documents this compatibility baseline:
That gives you the practical starting point for a new project on macOS Apple Silicon:
compileSdk = 36
targetSdk = 36
minSdk = 26
AGP = 9.2.0
Gradle = 9.4.1
JDK = 17
Build Tools = 36.0.0
For Kotlin, the currently released stable version is 2.3.21, published on April 23, 2026. For Compose, the current stable BOM shown in the official docs is 2026.05.00. Those two are worth pinning separately because they follow their own release cadence rather than tracking AGP directly.
That is the complete stack I would start with for any new Android app today. The next section covers how to actually get those pieces onto a clean machine.
Setting up a clean Apple Silicon machine for Android work involves four distinct pieces. Getting them in the right order saves a round of troubleshooting later.
Optional for daily coding, but worth having installed. Use it for initial SDK bootstrapping, emulator and device management, Compose preview, profiling, and deeper Android-specific debugging. Even if your daily driver is a different editor, Studio is the most reliable way to get the SDK laid down correctly on a new machine.
Install the current command-line tools package, then use sdkmanager to install:
cmdline-tools;latest
platform-tools
platforms;android-36
build-tools;36.0.0
emulator
system-images;android-36;google_apis;arm64-v8a
That last package is the Apple Silicon-specific detail worth calling out. On a MacBook with Apple Silicon, you want the ARM64 emulator image:
system-images;android-36;google_apis;arm64-v8a
Not the x86_64 image. The x86_64 image runs under emulation on ARM and loses a significant amount of the performance advantage that makes the emulator tolerable on M-series hardware.
Do not improvise here. The current AGP compatibility table is explicit: use JDK 17. JDK 21 is not yet the supported default, and older versions will cause build failures. Install a named JDK 17 distribution and point JAVA_HOME at it explicitly rather than relying on whatever the system resolves.
Even though AGP 9.2.0 aligns with Gradle 9.4.1, the project wrapper is still the right way to manage the Gradle version rather than a global install. Pin it in the project:
./gradlew assembleDebug
That keeps the version in the repo rather than in your machine state, which matters as soon as more than one person is working on the project.
Once the tools are installed, the environment configuration is straightforward. The goal is predictability: every relevant tool should resolve from the same paths, and the paths should survive shell restarts.
A typical macOS setup looks like this:
export ANDROID_HOME="$HOME/Library/Android/sdk"
export ANDROID_SDK_ROOT="$ANDROID_HOME"
export PATH="$ANDROID_HOME/cmdline-tools/latest/bin:$ANDROID_HOME/platform-tools:$ANDROID_HOME/emulator:$PATH"
If your JDK is installed separately from the system default:
export JAVA_HOME="/path/to/jdk-17"
export PATH="$JAVA_HOME/bin:$PATH"
The simplest way to verify the setup is working is to check four things:
java -version resolves to JDK 17sdkmanager runs without errorsadb is on the path./gradlew assembleDebug completes from the project rootIf those four things are true, the machine is ready. If any of them fail, the environment paths are usually the culprit before anything else.
With the machine set up, the question of what to actually build with is worth addressing directly. For a new native Android app on Apple Silicon in 2026, I would not get creative with the architecture:
The last point about DataStore versus Room is worth elaborating on. Room is a solid library, but it adds complexity that most new projects do not need on day one. DataStore handles the majority of local persistence requirements until the app has a real use case for relational data. Starting with DataStore and adding Room later is much cleaner than starting with Room and realizing half of its machinery is unused.
The same logic applies to module structure. One app module is still the right default for a small or medium product. The instinct to split into feature modules early is usually premature. Let the codebase earn that structure through growth, not through upfront architecture decisions that add friction before they add value.
On Apple Silicon, the emulator story is finally good enough that avoiding it is no longer necessary. The ARM64 emulator images run natively on M-series hardware, and the performance gap between emulator and device is much smaller than it was on Intel Macs.
That said, I still would not default to the emulator for everything. My order of preference is:
The emulator is fast enough to be the primary development target for most UI work. But nothing replaces a real device for confirming that the app actually feels right in a human's hand.
If you are starting fresh on a MacBook Silicon today, the complete checklist is short:
./gradlew assembleDebug
./gradlew installDebug
If both of those complete without errors, you have a working Android development setup on Apple Silicon. Anything older than this matrix is now legacy setup. Anything newer should be adopted deliberately — when you have a specific reason to upgrade — not by accident when a dependency pulls in a newer transitive version.
Android development on Apple Silicon is no longer the awkward edge case it was a few years ago. The hardware is strong, the native ARM64 emulator images are fast, and the official toolchain has a clear path for M-series Macs. The investment Google has made in the ARM build of Android Studio and the SDK tools shows in the current experience.
The difficulty that remains is not hardware or tooling quality — it is version alignment. The Android build system has more moving parts than most ecosystems, and those parts have slightly different release cadences. If you pin the versions described here and keep the workflow terminal-first, a MacBook Silicon machine is now a genuinely good default for Android development. Most setup problems are not exotic — they are a wrong JDK, a stale Build Tools version, or an Intel emulator image running on an ARM machine.
Getting the baseline right takes about an hour. Getting it wrong costs a day.
Let me know in the comments if you run into anything specific to your setup, and subscribe for more practical development guides.
Thanks, Matija
sdkmanager: https://developer.android.com/toolssdkmanager usage: https://developer.android.com/tools/sdkmanager