> ## Content Index
> Fetch the complete content index at: https://madewithlove.com/blog/llms.txt
> Use this file to discover other available public pages before exploring further.

# The Claude desktop app just killed fifteen years of waiting for an Android emulator to boot
- URL: https://madewithlove.com/blog/the-claude-desktop-app-just-killed-fifteen-years-of-waiting-for-an-android-emulator-to-boot/
- Published: 2026-09-11T08:17:57.000Z
- Updated: 2026-09-11T08:17:57.000Z
- Description: The Android emulator was never the real cost. The setup was: SDK paths, JDK versions, licence acceptance, a hand-edited config file, repeated on every machine and every new joiner. Claude Desktop takes that off your hands, and the wait that's left is spent reading a plan, not a stack trace.
- Author: Emma Williams
- Tags: Claude, Mobile, Developer experience, Tooling, AI development

## The history, briefly

Five years in tech can feel like a lifetime, especially given how quickly AI has reshaped everything recently. Anyone who has built an app on Android knows the pain of wrestling with the emulator. You have developed something in the app, and you want to test it locally. You begin loading the emulator, then go and work on something else. When you come back, it can be hard to tell whether it is hanging or just slow. The process was, and still is, very time-consuming. Apple Silicon and other hardware improvements have helped, but **the part of the developer experience nobody had managed to solve until now was what happens before the emulator boots.**

## The setup was always the real cost

Before the emulator even boots, there's a lot to set up: the Android SDK (developer tools), the JDK (Java runtime), licence acceptance, and a config file (config.ini) for the virtual device that often needs hand-editing. For example, if you want to increase or decrease the memory of the emulator or amend the device resolution. **That's the part the Claude desktop app has quietly taken off my hands**, and the cost it removes multiplies quickly across a team.

## What the Claude desktop app actually changes

Say you're building an app and you've reached the stage where you want to test it. You select the project folder and tell Claude you want to test locally, meaning your own machine, not a cloud build service. From there, **Claude runs the installs, lays out the command-line tools as Android expects, accepts the licences and creates the virtual device (the simulated phone that the emulator actually runs).** It determines the correct screen density so the emulator boots properly, writes it to the config file, then boots and runs the app.

Depending on your prompt, or what you have in your CLAUDE.md file, it also explains itself. Ask why it's editing a particular file and it'll tell you what that file controls and why. Some of this process is mechanical, licences for instance, and is fine to hand off completely. But a few steps involve root-level system changes (settings that affect your whole machine, not just this one project), and those are worth understanding rather than [blindly accepting](https://madewithlove.com/blog/beyond-prompting-read-verify-implement-learn/).

To be clear, none of this needs Android Studio, which is just a wrapper around the same command-line tools listed below. The desktop app still gives you visibility. There's a shared terminal to verify Claude's work, a file pane for hand-editing config.ini, screenshots you can drop straight into chat, and a plan you can review before any root-level changes run, with [each session isolated](https://madewithlove.com/blog/conductor-running-multiple-ai-coding-agents-in-parallel/) so a long install doesn't block your other work.

## Where Claude stops

Be clear about the parts Claude does not do. There is no dedicated Android simulator pane. The desktop app currently has one for iOS, but Android runs through the shell and ADB in the chat, just like any other command. **It also does not run the emulator itself. That still runs on your machine exactly as before, on the same runtime.**

## What you still do yourself

You'll need to install two things by hand: Claude can't install itself, and it can't click through a graphical installer. So you need both the Claude desktop app and JDK 17 (check the current recommended version at the time of reading, as this can change).

Everything else you can hand off:

- cmdline-tools/latest: the command-line tools, in exactly the directory layout Android expects
- platforms;android-36 for Flutter, or platforms;android-35 for React Native (the version of Android your app builds against)
- build-tools;36.0.0: turns your code into an installable app
- platform-tools: includes ADB, which lets your machine talk to the emulator
- emulator: the actual emulator program
- the SDK licences: Google requires you to agree to these before the tools will run
- ANDROID\_HOME, set: tells other tools where to find everything above
- an arm64 system image, such as system-images;android-31;google\_apis;arm64-v8a (the "phone" the emulator boots)

On newer Macs (M1 and later, which use Apple's arm64 chip architecture), you need the matching arm64 system image. The older x86\_64 images were built for a different chip architecture.

The setup still takes time. **The difference is you now spend that wait reading a plan instead of a stack trace, and that adds up over a working week.** Handling the tooling around [a mobile app](https://madewithlove.com/blog/building-a-react-native-flutter-app-is-more-than-coding/) has always been part of the job, but it has always carried overhead that has nothing to do with actually building the app. As that overhead shrinks, what's left to improve shifts back to the emulator itself: faster hardware, better acceleration.