Android debug on Ubuntu – emulator and alternatives

This is the second article in my 21 day blogging marathon. It is not quite as polished, as it could be.

Join the marathon by adding meaningful comments all the way!

I use a quite old, and battered Acer laptop with an I5 2nd generation processor and a “feeble” 8GB memory, for my personal projects.

It works fine, as long as I work on my smaller hobby projects, Freeplane GTD+ or the MindWeb which only require a  smallish development environment, but it quickly becomes a bottleneck as soon as I start up my heavier Android development environment, as that requires full processor  emulation using the Android emulator.

It’s quite useful to keep the computer running hot, to keep my fingers warm, and my tea next to the air went hot, in these cold autumn afternoons. On the long run however it will certainly damage the fan or even burn the processor. I had to find a way to keep the emulator overhead down.

I’ve spent a better part of a week, looking for an alternative solution to the SDK emulator, to arrive to the most rudimentary solution available in Unixes.

Use the emulator with KVM

First of all, let’s look at what causes a heavy load on the emulator. It actually does an active processor emulation, so once you realize that, and do some digging, you’ll realize there is a really simple built-in option, that makes use of the KVM in the emulator itself.

All you have to do, is to use an x86-based AVD and include the KVM options (source):

emulator -avd <avd_name> -qemu -m 512 -enable-kvm

This performs way better, than the original emulator, not to mention it works better with dual monitor setup, as the original emulator tends to resize itself to fill all available monitors horizontally.

The performance is much better, but still, the CPU heats up like crazy, as the emulator uses a full processor core. I couldn’t find any way to control the resource usage of the emulator, so I looked at other  alternatives.

Use Android x86 in VirtualBox

To control the resource usage, the simplest alternative is to use an environment, where that is not a problem. VirtualBox virtualization has been praised as being faster, than the emulator, while you can use the resource controls of the virtualbox itself.

Installation is quite straightforward, and well documented. I had to play around quite a bit with the “hardware” settings to get the JellyBean version installed, and wasn’t able to install the Lollypop to the virtual disk, and could only run from the CD image.

Once it’s installed, you should not forget, you’ll need ADB for deploying and debuging. The easiest method I found was to set up DNAT and port forward from localhost to the virtual host.

adb connect localhost:5555

As soon as I started my application up, I had to realize the wrong in my ways. Android-x86 doesn’t yet(?) support OpenGL rendering. Since my project is a map client, it relies heavily on OpenGL rendering.

No matter, how fast it actually started, I had to let this pass.

Genymotion – The ultimate emulator

After digging through tons of outdated articles on the subject, I cam across a promising candidate.

Genymotion is a cloud based emulator provider, that uses hardware virtualization (VirtualBox) to run the emulation.

It’s as fast as the android-x86 under VirtualBox, but provides much more than that. OpenGL and multi-touch support helps tremendously in development.

There is a little glitch, though. It’s not free, only for personal use. I went on and tested development with the personal edition, and I was quite impressed.

Also, I had to feed the emulator GPS track data, which turned out is not possible anywhere, but the factory emulator.

I went back to the dumb, original emulator instead.

Controlling the emulator

I had to find a way to control this greedy beast, so I turned to using the old-school methods, that were around for years, and we tend to forget, they even exist.

What I really needed, was to turn the emulator off, when not in use, and on when I actually want to interact with it. Starting and stopping the emulator is quite slow, so I couldn’t use that. Or could I?

On Unix systems a process can be started and killed, but there is also a process signal-pair STOP and CONT, that will not destroy the process, just stop/resume it’s execution.

All I needed was than, two simple shortcuts on my desktop, one with

pkill emulator64-x86 --signal STOP

and one with

pkill emulator64-x86 --signal CONT

to get it working.

Now I can let my CPU cool down, when I don’t readily need the emulator, and get the emulator back online in fractions of a second.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.