HAXM Speeds Up the Slow Android Emulator, Page 2
How Does HAXM Speed Up the Android Emulator?
The Android emulator is based on QEMU, which is a virtual machine environment emulating an entire computing system. The HAXM driver support runs both inside the emulator and on the host machine. As with many modern virtual machines, this enables the code inside the emulator to run at nearly full speed on the host machine. A variety of different Intel® Virtualization Technology (VT)-specific features are utilized to perform this feat. (Watch this Intel video for a demo of HAXM and its benefits.)
The interface between QEMU and the HAXM driver on the host system is designed to be vendor-agnostic, but currently it supports only Intel® VT. This means that upcoming Windows machines running on ARM potentially could be supported. In addition, AMD-based x86 machines could also be supported. Naturally, Intel did not do this work for them.
The overall performance is also increased through efficient use of the host GPU device. This is separate from HAXM, but helps increase performance. A flag can be enabled on each AVD that effectively pushes the 3D commands out to the host machine GPU. You'll see how to enable this in the next section.
Configuring Your Android Development Environment for HAXM
Are you sufficiently enticed? We were! OK, to be honest, it seemed like Android emulator performance could only get better, so let's talk about how you can configure your development environment and start using the HAXM driver to enable the emulator to start pulling its weight again.
Before you begin, make sure your development machine has an Intel CPU in it (such as a Core i7). The HAXM driver and Intel x86 Atom system images are provided by Intel without additional cost, so this isn't a surprise to us. (In fact, we have desktops with competing processors where we can't use this. Even though they are faster for other things, the emulator performance makes our laptops with Intel processors work very well.)
- Update Eclipse:Make sure your Eclipse installation and the ADT plug-in are fully up to date. At the time of this writing, each was on release version 20.
- Update your Android Tools:After each Eclipse plug-in update, it is important to update your Android SDK Tools. To do this, launch the Android SDK Manager and update all the Android SDK components. To take advantage of HAXM, you must be on at least release version 17.
- Download the x86 Atom System Images: Using the Android SDK Manager, download the Intel x86 Atom System Image packages for the API Levels you require. As of this writing, system image packages are available only for API Level 10 (Gingerbread MR1 -- Android 2.3.7) and API Level 15 (Ice Cream Sandwich MR1 -- Android 4.0.3/4.0.4).
- Download the Intel Hardware Accelerated Execution Manager Driver: Again, use the Android SDK Manager to download the HAXM driver. Unlike many other items you can download through the Android SDK Manager, the HAXM driver will not be automatically installed on your computer. Instead, it just downloads an install package that you must install manually.
- Install the HAXM Driver: Find the IntelHaxm.exe file within the
/extras/intelfolder of your Android SDK installation. Launch the executable to start the installation process. The installer will check your platform configuration for compatibility and then either install the driver or display a failure message if your computer is not compatible with the HAXM driver.
- Create a New x86 AVD: Using the Android Virtual Device Manager, create a new AVD that will leverage the driver. Most of the AVD settings will remain the same. Set the AVD Target property to one of the two API Levels that have an x86 system image available (API Level 10 or 15). Then, under the Hardware property settings, add a new value. Click New, select the GPU emulation option, and turn it on with a value of yes. When done, click Create AVD to actually save this AVD profile for use with the emulator. (Note: When you enable GPU emulation you cannot use the AVD snapshot feature. Soon you'll see that it's not nearly as important as it was.)
Now your development environment is ready to rumble with hardware accelerated emulation. Go ahead and launch the emulator using your newly created AVD. You should see a small window titled "Starting Android Emulator." Within it, some status text will show. If you see "HAX is working and emulator runs in fast virt mode" then you'll know everything is installed and working correctly. If, instead, you see "emulator:Failed to open the HAX device!" or "HAX is not working and emulator runs in emulation mode," then the installation did not work properly. At this point, recheck that you followed all the steps for installing everything properly, and that you are targeting compatible API levels in your AVD.
You can also consult the "Configuring Virtual Machine Acceleration" section of the official Android emulator documentation for instructions on setting up HAXM.
So, How Much Faster Is My Android Emulator?
Well, like we said, Android emulator performance couldn't get much worse. But how much better does the emulator perform once you've gotten HAXM on the case? Believe us, you'll notice.
The performance improvements once HAXM is in use can be felt immediately. From the first, you'll enjoy a much faster bootup time when you launch an emulator instance and once running, the emulator is transformed from a clunky, janky mess (watch this video at 2:25) to a pleasant experience with silky smooth animations. But these are just subjective observations we had. We decided to run a few performance tests in order to demonstrate and quantify the sorts of improvement that we were experiencing.
Finding easy-to-use benchmarking tools that run through completion on the emulator sounds easier than it is. We ultimately chose to measure boot up time and determine SunSpider 0.9.1, Linpack, and Scimark scores. We also ran some 2D and 3D measurements, but their results aren't standard so we'll just talk about them in general rough terms. Developer.com commissioned us to ran all these benchmarks, but note that you can now run the Octane Benchmark for Chrome within HAXM as well.
The first measurement, and probably the one we've all felt the most pain with (and complained the most about), is emulator bootup time. This is the time from when you first tell your development environment to launch the emulator to the time the UI is functionally available to use and you can install apps. We've noted that the first time an Android AVD boots up in the emulator it takes longer to start. We included these numbers, too.
As you can see in the chart, the bootup time was dramatically reduced in both the first bootup time and subsequent bootup times when HAXM is leveraged. Overall, the emulator becomes useful in about a quarter of the time that it used to and about a third of the time an ARM emulator boots up. This is remarkable and can increase developer productivity substantively.
Next we used 0xbench, which utilizes a number of other benchmarks. Specifically, the Sunspider, Linpack and Scimark numbers are interesting and revealing.
The SunSpider results may be the most striking difference. The non-accelerated results are quite slow, and it shows when trying to use the built-in browser within the emulator. When in accelerated mode, the results are substantially faster than our devices and only about half the speed of our host machine. This is tremendously useful for web developer testing with the emulator. About the only issue we noted is that the performance will not be indicative of that on real devices; it's too good! But then, that's why you still have to test on real hardware, right?
As you can easily visualize here, the computational benchmarks show a substantial improvement when HAXM is used. While the exact numbers and even the exact differences are not particularly important, what is important is that the improvement is very real. The feel of the emulator and the speed with which your apps will run is all much more on par with current generation high-end device hardware. In fact, some of these stats are better than our dual core Galaxy Nexus or quad core Nexus 7 devices.
Overall, we are quite impressed with the performance results with HAXM. We can only hope other host targets will be added in a timely fashion and, eventually, all API Levels will have an x86 system image available immediately upon release, and that this level of performance ultimately becomes the default on supported development environment configurations.
Is There a Catch?
Like all development configuration decisions, you've got to weigh the pros and cons of using a tool. The HAXM solution isn't too good to be true; there are some downsides. First of all, this solution works only in Intel CPUs at this time. They are the most popular, but there are competing processors that many people use, including these authors. Second, HAXM works only when using an x86 system image. This isn't a huge problem for most developers, because standard Android applications run within the Dalvik VM. Finally, not all Android API levels have x86 system images available. For example, at the time of writing there are no system images for Android 2.1 and 3.x, but Intel is planning to release the x86 system image for Android 4.1 (Jelly Bean) during the first week of September. With some of the popular Android SDK versions not supported, you may not be able to take advantage of the performance improvements while using the emulator to simulate these device configurations.
If you've been losing sleep over how dismal the performance of the Android emulator has gotten as we have, you should be pleasantly surprised by how much Intel's Hardware Accelerated Execution Manager (HAXM) driver improves your work day. If you have a development machine with an Intel processor, we see no reason at all to not use this solution for Android app development. In fact, it's so compelling that we feel it should be the default setup for compatible development environments.
Have you suffered Android emulator performance frustrations too? How have you dealt with them? Share your experiences in the comments below. After you get HAXM up and running, let us know how well it works for you as well. Did you run across any problems with any of your applications? Is it so fast that you have to run your app on the real device to truly simulate the true (slower) performance that users will experience?
Page 2 of 2