Supercharge Your Slow Android Emulator

With thousands of different mobile devices on the market today, mobile application developers rely heavily on emulators and simulators to sanity-test their apps. As we've said many times before (it's really something of a mantra): there's simply no substitute for hardware testing. We'll be some of the first to tell Android developers (and any mobile developer for that matter) that you must test your mobile application on [at least a good variety of] target devices to ensure that the app works as expected under different conditions, on different hardware and screen types.

We also advocated that developers should use devices, too, so as not to be surprised by differences between the Android emulator and physical devices. ("What you mean devices use slow cellular networks, battery power and have different screen refresh rates?")

Android emulators hold a valuable place in the Android app developer's daily work. It's simply unreasonable to require developers to test on every conceivable Android device configuration these days. Android developers have been able to use the Android emulator, which comes with the Android SDK, to test their applications from the comfort of their development environment. Over time, and many revisions, the emulator has both improved in the features the tool offers, and become bogged down with significant performance problems. By the Honeycomb release timeframe, many Android developers felt that the stock Android emulator had become virtually unusable.

A while back, we were taking part in an Android conference and we ran an informal poll. We asked fellow Android developers what the worst thing about Android development was and what area of Android needed the most improvement. The answers were not about the need for a specific API or some new device feature. Instead, they were overwhelmingly in favor of Android emulator improvements. We basically realized we had a room full of Android app developers begging for a better emulator.

So what exactly was wrong with the emulator? It turned out that few people had complaints about the emulator's features. It wasn't complicated to use. It was reasonably customizable. No, the problem was quite easy to identify: The emulator was slow. And we don't mean go-get-a-cup-of-coffee slow or take-a-bathroom-break slow. We mean "Is this thing still alive? I went to lunch, came back, went to a meeting, came back and it still hasn't loaded." slow. Slow enough to walk, bike or drive down to the nearest big box store, buy a device, activate it, charge it and load up your app, test it and then return it (not that we recommend this practice… usually).

The Android emulator's performance problems only seemed to get worse with the newer and higher resolution emulator configurations, such as those you'd use for current devices with 720p and higher screens. The first few times we tried to load the Honeycomb emulator were downright grueling. By this point, the emulator had become virtually unusable. We talked to some Googlers and asked how they managed to work with the emulators, and everyone was in agreement that there was a lot of room for improvement.

Sure, there were tricks that sometimes worked on certain development environment configurations. For example, developers running Linux seemed to have an easier time of it. However, for many developers, the emulator simply stopped working altogether. We often resorted to using physical hardware for most, if not all, Android app testing and development. This meant returning to the days of constantly searching for devices in the office, charging always-dead batteries, and living with a desktop covered in a nest of cables and chargers. While some of us like having a desk full of devices, it's not necessarily the most productive way to work.

Eventually the Android tools team did indeed turn their attention to improving the emulator's performance. In the last few Android tool revisions, the tools have had significant improvements. The emulator now runs better than it did, but there's still a lot of room for improvement. Meanwhile, others, like Intel®, decided to take matters into their own hands, with some impressive results.

Why Is the Android Emulator So Slow?

If you've used virtual machines in the past, such as the old days of running Windows inside a VM, you'll probably recognize the pain. Most host machines today are based on the x86 instruction set. The system images used by the Android emulator aren't using the same processor type as the host machine. The Android emulator, based on QEMU (the Quick EMUlator), must emulate ARM instructions on top of a different host machine architecture, which is highly processor intensive. QEMU's goal was to deliver speed by supporting new host architectures and not requiring host CPU support for virtualization. Together, all of these things add up to an emulator that works, but can be too slow to be usable.

This real-time translation and simulation at the processor instruction level means that the emulated CPU is, effectively, entirely written in software. In addition to this, other hardware, such as storage, memory, input and output devices must be emulated through software as well. This entire process is what causes the slowdown. In fact, it's a wonder that it works at all. There's an assumption that the software processor works exactly like the real thing, quirks and all. The same goes for the graphics processing, network connection, screen, input and so on.

Early on, when we app developers got our hands on the first Android devices, the emulator had a fairly reasonable task. It had to simulate only a small number of devices, which had very similar stats and hardware. The hardware was also much simpler, the screens of much lower resolution and the performance demands on the host system much less overall. But as the Android device market matured, and different types of devices with very diverse hardware and software specs came on the market, the emulator simply couldn't keep up with being both highly configurable and keep up in terms of performance. The introduction of Android Virtual device profiles, or AVDs, enabled developers to create emulator profiles for a wide variety of devices. The more complex the devices got, the more the emulator ran into trouble.

Intel Improves Android Emulator Performance

There is a solution to all of these performance problems. It does come with a caveat that we'll explain. Recall that the Android platform runs applications inside a VM of its own: the Dalvik VM. As such, the underlying hardware that Android runs on is much easier to change, including the CPU architecture. In fact, there have been devices to ship with an Intel x86 chip instead of the more typical ARM-based chips. Intel has full ported Android over to the x86 architecture.

This matters to Android app developers because it has allowed Intel to distribute emulator system images that are based on the x86 architecture. This alone does not solve the problem of emulator performance, however. In fact, in our testing, by just switching to an x86 system image, a variety of things actually ran slower than when we were using ARM. Until the release of the Intel® Hardware Accelerated Execution Manager (HAXM) driver, that is.

With the Intel® HAXM driver in place, the Android emulator can run the Android system and your apps as fast -- or faster -- than on physical hardware. The speedup is truly dramatic and returns usefulness to the emulator, even running at high resolutions. When combined with GPU emulation -- which helps graphical performance only -- the emulator can now be used again for day-to-day testing (with all of the normal caveats of not using a real device).

There is one catch, for now: Intel's driver requires that your development environment runs on Intel hardware. The solution does, however, run on Windows and Mac OS computers. It's freely available for download. On Linux, KVM is utilized for similar results. (Note: As tested on Intel x86 platforms. AMD platforms are not supported. )

Page 1 of 2