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!

Android Debugging Mobile

Debugging Against a Remote Android Emulator

The Android emulator is impossibly slow when running inside a virtual machine. It is possible to debug against a remote emulator via SSH. Here are the steps to connect from a Windows guest OS to an OS X host OS (they can be easily adapted for a Windows host). It does require installing the Android SDK on the host OS and creating and running an emulator there. It seems to work even if you have a device connected too. I’ve gotten them both to show up in the IDE and am able to pick between them and deploy and run on the emulator.  The Emulator is still slower than hardware, but this makes it usable.

Of note, this emulator performance isn’t an issue with Delphi, but is an issue with the Android emulator. So you may find this tip useful with other Android development tools as well.

This could be adapted to debug against a remote Android Emulator running on a remote machine located anywhere on the internet. Just requires port 22 to be open between the two machines.

Thanks to hheimbuerger for the the Stack Overflow answer that got me pointed in the right direction. This information has been adapted to the DocWiki too with additional links to more information.

  1. Install the Android SDK (not the ADT bundle) on your Mac OS X host & start an ARM based emulator (With use Host GPU enabled)
  2. Enable SSH on the host
    • On a Mac OS X Host go to System Preferences -> Sharing -> Remote Login
    • On a Windows host, you need to install a 3rd party SSH host. FreeSSHd has been found to work.
  3. Install the PuTTY SSH (putty.exe) client on the Windows Guest OS
  4. Ensure port 22 is open between the Windows guest OS and the Mac OS X host.
  5. Create a connection in PuTTY to the Host OS
    1. You will most likely use the 192.168.x.x IP address of the host
    2. Go to Connection -> SSH -> Tunnels and add a local/auto port forwarding for 5555 to locahost:5555 and 5554 to localhost:5554.
  6. Save and Open the connection in PuTTY
  7. Provide the login credentials for the Mac OS X host – anything typed in this window is executed on the remote machine
  8. You can check or change the tunnel settings via the icon in the upper left of the PuTTY window
  9. Minimize PuTTY (keep it open to maintain the SSH connection)
  10. Open a new command window in the Windows guest OS and type “adb kill-server & adb devices” and you should see the emulator-5554 as a listed device.
  11. Refresh target devices in Delphi and it should appear

PuTTY Tunnels

This should work for any emulators or devices connected to the remote machine. Unlike emulators that are local, you need to start the emulators before Delphi will see them. You may need to adjust the tunnel port numbers if you are connecting multiple devices.

Good luck, and happy debugging!