The Comprehensive Guide To Improving Android Emulator Performance

The Android Emulator is slow beyond belief. Over the 4-or-so years Android has been around it has only gotten worse, to the point of being something that will go down in the annals of Computer Science History. The fact that the vast majority of articles being published (today) about Android neglect to mention this all-too-painful fact is evidence that those articles are far from objective.

The goal of this post is to demonstrate how to get performance out of the emulator that won’t ‘kill’ you while developing and debugging. In fact, with the below recommendations, you might forget how slow the emulator once was. It might even be possible to develop an entire app on the emulator yet again (well, for the first time really, depending on your persepctive). Just imagine!

Now wake up. The Android Emulator is not a serious product for a professional Android developer, especially one who has an app to publish in Google Play. You need to purchase one or more Android devices for that type of development and testing. More can be said about this. In real-world usage your app will be on far more handsets than you can reasonably expect to source and purchase for testing. However, you also have constraints about what features are available for development and testing in the emulator. Ultimately you’ll have to find a balance for each Android project between how much time you spend using the emulator, versus how much on a device. More tools makes a happy engineer.

I’ve found these solid tricks to get the best performance out of the Android Emulator:

  1. Install a Solid State Drive (SSD). I witnessed this demo’ed for me two days ago and we tested the emulator. It made a massive difference in startup time! Improvement measured on order of 10.
  2. 16GB RAM. Again I just saw this demo’ed on a Mac. Huge difference in performance for the emulator. With 16GB it’s easier to roll with the emulator cached entirely in RAM without even trying.
  3. Reduce emulator screen size. When launching the emulator (manually) I’ll check the box “scale display” and use a scale-factor that gets the emulator to render about 50% of the original size. You may have to play around to get the right balance between speed and readability. This can be done by scaling DPI or entering a physical width/height when launching the emulator (or when configuring an AVD, or from the command line). It seems pretty clear that performance is directly impacted by the number of pixels the emulator is managing.
  4. Use virtual machine acceleration. This is a new feature as of SDK rev17. It also comes with at least a few caveats.
  5. Perhaps you could use VirtualBox. An excellent tutorial is posted at The caveat is: VirtualBox is an Android fork. It’s unreasonable to consider testing with VirtualBox to be a reliable reference, but that might be OK in some cases. Honestly, this seems to have potential, but after investigating the depth of forking and state of the VBox project I can’t recommend this as an option for professional developers. Even for beginners I’d think — you spend so much time getting that fork to run when you should be learning Android. So…use this at your own risk.
  6. Create AVDs with only the options you need for testing your app. Since creating AVDs is easy, create some with all options; and some with a very limited set that gets the job done for certain kinds of apps (or for a specific app). See
  7. Skip the boot animation. You can do this with the -no-boot-anim command line option. See for more.
  8. Enable startup snapshots. See
  9. Set the emulator’s Cache partition (emulator option) to 64MB or greater. See

The top two solutions are the most effective. They can be summarized as: a heaping order of RAM with some SSD-RAM on top. Upgrading to 8-16 GB RAM (or more) and a solid-state-drive will get your dev environment running nice and fast (for everything, actually). Multiple CPU cores are a must – but there’s a good chance you already have that.

We can tinker with the emulator settings as described above all we want. If we only make those tweaks then we still get an emulator that kills hopes of rapid development! Another thing is, we can’t be limited to only one or two other apps running alongside the emulator. That’s the last thing we want when we’re trying to troubleshoot code.

What probably doesn’t work:

  • Like I said – just tweaking the settings doesn’t work. It helps but you’ll still abandon the emulator whenever possible (i.e. use a real device).
  • Buying a new computer (see Nonono – that is not a solution. You will be happy with a new-fangled computer and it’ll run faster (at first), but the emulator will still kill your hopes of rapid development. Oh…you may get the sales person to let you install Android SDK and demo the emulator before you buy it. You might as well go and beg Murphy for help.
  • 1GB RAM – not enough. 4GB RAM – probably not enough (unless emulator is the only app running). 8GB RAM – now you’re talking. Point is…we need the entire emulator to be executed in RAM, none in the virtual-ram or ram-disk.

further reading:

5 thoughts on “The Comprehensive Guide To Improving Android Emulator Performance

    1. I haven’t tried that personally because I often see Eclipse eating up over 4GB in realtime and virtual RAM in Activity Monitor (OS X). I think SSD is the way to go, but OK if you have enough RAM and know what you’re doing with RAM disk management – go for it!

    1. I stated the Android image used in VirtualBox is a fork. I’m still a little vague on all the AOSP forks out there. Basically, from what I recall during my last bout of research, the Android images provided in VirtualBox are kinda like CyanogenMod images. This fact is generally a major problem for enterprise-level, production-ready, let’s all get paid and go home, Android development and testing. If I’m wrong, then please let us know!

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s