One core difference between Android and iOS devices is the variety of devices on which the respective operating systems run. iOS developers need only cater to a very small number of devices, with specific screen sizes and resolutions. On the other hand, Android developers have to cater to hundreds of different devices with various screen sizes and different hardware specifications.
For independent developers and hobbyists, it is not feasible to purchase every possible device out there which runs Android. For this reason, the Android emulator was created to simulate these devices. However, many developers have complained that developing on an emulator is extremely frustrating, slow, and in some cases, simply unusable.
Enter Intel’s x86 Emulator Accelerator Manager (HAXM)! This technology allows developers to run an emulator which performs much faster than a typical emulator running on an ARM-based CPU architecture. It should be noted that this technology only works on Intel VT (Virtualization Technology) enabled systems. As a general improvement, you can also enable your emulator to use your machine’s GPU, which should make rendering of animations or graphics much faster than it would otherwise be.
Windows and Mac users can download Intel’s HAXM straight through the Android SDK Manager under the “extras” section. The installation can then be found at:
Linux users can install HAXM by following the instructions here. For those of you running Linux, you need to be running a 64-bit version of the OS in order to make this work.
After you have installed the HAXM, create a new AVD which runs on an Intel Atom CPU architecture.
After having done this, simply launch the AVD you have just created. On a PC running Linux with an i7 CPU and an Intel Integrated Graphics Card, the emulator above finished loading in less than three seconds. A significant improvement over the previous time of two minutes!
It should be noted that there is a bug present when you use API Level 17 in combination with the Intel HAXM which involves flooding your logs with garbage text. Google has yet to release a fix for this. At the moment, there are currently two known workarounds:
- Use an API level of 16 or less
- Set the following RegEx as a filter in the logcat view: