Android Debugging

8 Tips to Speed Up Your Android ARM Emulator (AVD)

The Android Emulator is very slow. The main reason is because it is emulating the ARM CPU & GPU, unlike the iOS Simulator, which runs x86 code instead of the ARM code that runs on the actual hardware. This means the iOS Simulator is typically faster than actual hardware, and the Android Emulator is slower than actual hardware. Most Android developers I talk to develop on actual hardware, but sometimes you need the emulator, and when you are using it you need it to run faster.

You may see some articles or tips about using the Intel HAXM, BlueStacks, Genymotion, Android-x86 or some other high performance Android emulator. These almost always are using an x86/Atom Android image, which runs faster because it doesn’t need to emulate the CPU, running x86 code on your host CPU (much like the iOS Simulator). Yes, they are faster, but the majority of Android devices (in the USA at least) are ARMv7. So you are technically testing on a niche hardware configuration that is not likely to be what your app runs on in the real world. In some parts of the world, Intel Atom based Android devices are becoming more common, so those emulators do serve a purpose.

The Android Emulator runs an Android Virtual Device or AVD. You can configure and create different Android Virtual Devices with the Android Virtual Device Manager or from the adb command-line tool.

Here are some tips to make the ARM Android emulator faster for any Android development tool, but my examples are specific to Delphi XE5. Many of these tips can be combined for better performance. Using these tips I’ve seen the emulator go from sluggishly terrible to actually usable on a few different systems.

  1. Use Actual Hardware – OK, so this doesn’t speed up the emulator, but it is worth mentioning again. There are a number of other advantages besides speed, and Android hardware is pretty cheap compared to iOS hardware. Get a few different devices, and you are set.
  2. Don’t Run the Emulator in a Virtual Machine – The emulator is a virtual machine, and running a virtual machine in a virtual machine just compounds the problem. If you are developing in a virtual machine, all is not lost, you can still debug against a remote emulator to run the emulator on the host machine.
  3. Use Parallels Desktop 9 – If you must run the emulator in a virtual machine (which I don’t recommend) I hear reports that Parallels Desktop 9 for Mac OS X is faster than VMWare Fusion. You can test this for yourself with the latest version of VMWare Fusion. The comparison I heard about was between Parallels 9 and Fusion 5, which is now a version behind.
  4. Use Host GPU – There is an option when creating an Android Emulator Instance (called an AVD or Android Virtual Machine) to use the physical GPU on the host machine instead of emulating it in software. This gives a huge performance boost. So create a new Android Emulator, and make sure to enable Use Host GPU. (Not, this is incompatible with the other performance option of Snapshot, but I’ve found Use Host GPU results in better emulator performance, while Snapshot only speeds up emulator startup.)
  5. Copy the OpenGLES libraries – After launching an emulator with Use Host GPU enabled, sometimes you get an error “Could not load OPENGLES emulation library”. If you do, then use this tip (if you don’t get the error, then skip this tip).OpenGLES errorThis has two common causes, the first is fixed with a reboot. If that doesn’t work then you need to copy the necessary DLLs to a different directory so the emulator can find them. Simply copy lib*.* from C:\Users\Public\Documents\RAD Studio\12.0\PlatformSDKs\adt-bundle-windows-x86-20130522\sdk\tools\lib up one folder to C:\Users\Public\Documents\RAD Studio\12.0\PlatformSDKs\adt-bundle-windows-x86-20130522\sdk\tools (this is assuming you are using the Android tools installed by RAD Studio. Adjust your paths as necessary). Relaunch the emulator and the error should go away, and your emulator should be much faster. There is another method that involves updating path information, but just copying the necessary files is easier.
  6. Run your Emulator on a Mac – I’ve heard reports that the OpenGLES libraries are faster on Mac OS X than on Windows, because Windows prefers DirectX, while OS X prefers OpenGL. You can use the remote emulator setup to make that work (assuming you have a Mac handy). Likewise, if you have a computer with a newer and more powerful GPU and CPU, then use that one. Be sure you combine this tip with the previous two (to Use Host GPU).
  7. Run an Older Version of Android – Sure, Kit Kat is new and Shiney, but not everyone has it yet. The newer versions of Android are typically more demanding on the hardware, so newer  may be slower. Check out the Android Platform Version Dashboard and go back to an older, popular version, or just stick with Gingerbread and know you will support close to 98% of all Android devices.
  8. Tweak the AVD Hardware Configuration – One advantage of the using the Android Emulator is you can test specific hardware configurations, so this one is less useful. But if you increase the memory (within reason) and make the screen smaller (again within reason) that can give you a minor performance increase too.

Generally speaking, I would suggest everyone use tips 2, 4, 5 and maybe 7, but everyone’s situation and needs are different, so pick and test the tips that give you the best Android Emulator AVD performance possible. Good luck, and happy Android development and debugging!

34 replies on “8 Tips to Speed Up Your Android ARM Emulator (AVD)”

Pedro, i’ve been using it, but unfortunately, it can’t run simple delpi xe5 android application, always crash, i still don’t know why, and i’m trying to write a blog on how to run and debug delphi xe5 apps in genymotion when i’m success with it

Yes, I mentioned Genymotion in my post. It is an x86 Android, not an ARM Android. So the ARM native code that Delphi produces won’t run on it. In that case you might as well just add Win32 as a target to your project and run it on your desktop. The purpose of the emulator is test closer to what it will be like on the device, which typically has an ARM CPU.

Oo i see, so because delphi xe5 produce native arm binary, it can’t run on genymotion, while other compiler generate java dalvik or js and that can run on genymotion, is that correct? So there is no way delphi xe5 binary can run on genymotion?Ok then, i will look into your tips to speed up the emulator

Correct, the Genymotion (and some others) are x86, so they are emulating non-standard hardware since most Android devices are ARM based. Delphi produces native ARM binaries, so they will only run on ARM devices and emulators.

The Android Emulator runs an Android Virtual Device or AVD. You can configure and create different Android Virtual Devices with the Android Virtual Device Manager or from the adb command-line tool.

HAXM only works with ATOM (x86) based emulator images, which by definition are not ARM emulator images, which is the purpose of this post.

did you try to debug with break points using XE5 and emulator yourself?

Because, for me, XE5 app never stops on break points if I use emulator.

Thanks to be honest. Yes, it’s slow but it’s not the point I am after… I’m trying to figure it out if my installation is corrupted or it was never worked this way and Embarcadero conveniently keeping silence on the matter.

There are plenty wiki pages documenting how to run emulator this and that, through ssh tunnel etc. And there is NOT a single word telling that Emulator will not stop on break points from XE5.

PS: I can debug android apps using eclipse and same installation of Emulator no problem. I do understand difference in code generations of regular android app and “native” XE5/FMX thingy.

Vlad: Sorry I didn’t see your connect earlier. It doesn’t appear XE5 can debug a breakpoint with the emulator. One more reason to recommend working with actual hardware.

Hello. Xe7 generate arm code and can t run on a x86 emulator ok. But I worked with android studio too and dalvik and apk installed worked on both emulator arm and x86. I don t understand. ..

Android Studio doesn’t generate native apps. It generates Dalvik apps – because they don’t run natively on the CPU they are able to run on both x86 and ARM CPUs (as well as MIPS, if you can find one).

XE7 generates CPU native apps, and targets the ARM CPU since it is the most common.

Not a Tech guy, only know a little about the Windows 7 system I have.
Need to know if you have to be a tech guy to configure Android emulators.
Looked online and there are more emulators out there that have Pros and Cons.
Need to know if a novice can configure android emulators and which emulator to use on the Windows 7 system.
Like I said, looked online and the fixes might look simple for the Tech guys but looks complicated for a novice like myself.
Or do I just get a System already configured for the android system (my old phone!!!!).

Thanks to tell the truth. We are able to configure as well as create various Android Digital Devices using the Android Digital Device Supervisor.

I don’t understand why cant they just create a separate emulator using actual computer machine just for debugging purposes. Like if I’m just wanna see “Hello World” on the screen…. Are they blind to see how IOS Xcode being implemented?

Comments are closed.