# Android Needs A Simulator, Not An Emulator

DevFeed: [Android Needs A Simulator, Not An Emulator](<https://devfeed.tech/articles/android-needs-a-simulator-not-an-emulator-20916.md>)

Original publisher: [Read original article](<https://jakewharton.com/android-needs-a-simulator/>)

Published: 2014-06-16T00:00:00Z

Content type: article

Language: en

Sources: [Jake Wharton](<https://devfeed.tech/sources/jake-wharton.md>)

Topics: [Android](<https://devfeed.tech/topics/android.md>), [Emulator](<https://devfeed.tech/topics/emulator.md>), [simulator](<https://devfeed.tech/topics/simulator.md>), [Android Studio](<https://devfeed.tech/topics/android-studio.md>), [Gradle](<https://devfeed.tech/topics/gradle.md>), [Tooling](<https://devfeed.tech/topics/tooling.md>), [IntelliJ IDEA](<https://devfeed.tech/topics/intellij-idea.md>), [SDK](<https://devfeed.tech/topics/sdk.md>), [Oracle-VM-VirtualBox](<https://devfeed.tech/topics/vm-box.md>), [virtualization](<https://devfeed.tech/topics/virtualization.md>)

Tags: [android](<https://devfeed.tech/tags/android.md>), [android-studio](<https://devfeed.tech/tags/android-studio.md>), [development-tools](<https://devfeed.tech/tags/development-tools.md>), [emulator](<https://devfeed.tech/tags/emulator.md>), [gradle](<https://devfeed.tech/tags/gradle.md>), [intellij-idea](<https://devfeed.tech/tags/intellij-idea.md>), [sdk](<https://devfeed.tech/tags/sdk.md>), [simulator](<https://devfeed.tech/tags/simulator.md>), [virtualization](<https://devfeed.tech/tags/virtualization.md>)

## AI overview

The article argues that Android needs a fast, responsive simulator rather than an increasingly slow emulator. It reviews improvements to Android development tooling, including the Gradle plugin and Android Studio, then describes emulator performance degradation and later improvements from x86 builds and CPU virtualization, including Genymotion's VirtualBox-based approach.

## Source excerpt

Two years ago I wrote a blog post complaining that the Android build system was broken. At the time, Eclipse ADT and Ant were the blessed solutions and they just hadn't scaled with the platform. Third-party solutions existed for both tooling and IDE but they always felt a bit illegitimate and at risk for problems. My post joined the cries of others who knew that something had to be done. Xavier Ducrohet swooped in and dropped a bomb on the resulting Google+ thread: "We are looking at revamping the whole thing". In the two years since he and the tools team have transformed the landscape of how Android development is done. A first-party Gradle plugin now provides the powerful and dynamic platform on which any app of quality is built. Ownership of the Android plugin inside IntelliJ IDEA (with a sprinkle of branding) yields a development environment that moves mountains for you. Neither the Gradle plugin nor the IntelliJ IDEA plugin (known bundled as Android Studio) are at a v1.0 yet. They're both still beta (albeit arguably in the sense that GMail was circa 2008). Why was all of this important and why is it important for Google moving forward? Developers are the top of the funnel for Android's continued success. Without quality development tools there are no quality apps, without quality apps there are no quality users, and without quality users the developers will flee. Half of the developer flow in this funnel comes from the tools and the other half from APIs. This post is about the former. My first exposure to Android was the M3 pre-release SDK's emulator (pictured). The emulator started up quickly and was responsive. Each successive release up to and beyond version 1.0 added much needed functionality to both the OS and the emulator. And in each successive release the emulator slowed. Android's pubescent period (otherwise known as Honeycomb) and its eventual emergence into adulthood had a devestating effect on emulator performance. Despite our development environmen