The Android Honeycomb Emulator

Thu, Jan 27, 2011 4-minute read

Some people have noticed some niggles with the Android Honeycomb Preview emulator, so I’ve put together a few tips which may help improve your experience.

I’ll do my best to keep this updated with tips and post hints on my twitter account as I get them.

Things you can do something about

Emulated memory size

By default the Honeycomb AVD is created to emulate 256MB of RAM, my advice is to increase this significantly. I’m using 1GB, you may want to try 512MB if you haven’t got a free gigabyte of RAM (and I mean physical RAM, not swap), but to run the emulator and your apps I’m pretty sure you’re going to need more than 256MB of RAM.

If you’re creating the AVD for Honeycomb in Eclipse you’ll find the RAM setting in the Hardware section under “Device ram size”. If you already have an AVD you can increase the setting by finding the directory you’re AVD is in (e.g. .android/avd/honeycomb.avd), editing the emulator-user.ini file, and changing hw.ramSize to whatever you want the ram size to be in megabytes (e.g. 1024 for 1GB).

Enable Snapshots

[This comes from the Android SDK documentation]

Enabling snapshots on an AVD allows the emulator to start-up an AVD in the state it was in when you closed it. This means that it doesn’t have to go throught the boot-up procedure each time, which will save you a reasonable chunk of time.

You can find more on enabling snapshots on the Android Tools Site.

Screen orientation (Seems to be fixed in the release SDK)

You’re not going mad, when you start the emulator it’ll be in the wrong orientation. It’s easy to fix; Press CTRL & F12 (to rotate the screen), Run Settings from the Apps panel, go to the Screen option, and turn Auto Rotation off (if it’s already off turn it on and off again). Then press CTRL & F12 again to put the device back into landscape mode and the orientation should now be correct.

Things you can’t do anything about

Multi-core performance

The Android emulator is based on QEMU, and QEMU is single threaded. It doesn’t matter how many cores you emulate in QEMU it will run them in a single thread which means it doesn’t matter how many cores you have in your machine you’re going to be limited to the performance of a single core.

This is why you might see a single core machine running the emulator faster than a multi-core machine with a slower clock speed.

Some things improve over time

Honeycomb and QEMU both use a Just In Time compilation techniques which means executing sections of code will initially be slow but later runs of the same code should be faster.

When you first start the emulator QEMU needs to take all of the code used in starting Android and translate it into code for your machine. Once it’s done this a lot of the translated code will be cached to allow QEMU to avoid re-translating those sections when they’re needed in the future.

Using a cached version of the code is significantly faster than having to translate the code, and as the code cache grows QEMU needs to do less translation, which is why the emulator may appear to gradually speed up when you’re using it.

This also applies when you run a freshly installed app for the first time. Dalvik converts your app from byte code into ARM native code, then QEMU takes that ARM code and translates it into code for your machine (most likely x86), so it’s best to run through your app a couple of times to let Dalvik and QEMU do as much of their slower translating work as possible before making any statements about how fast an app is compared to running a different version of Android in the emulator.

There also appear to be some bugs which appear to resolve themselves over time. An example of this I’ve seen is opening a new tab in the Browser; If I start the emulator, start the browser, then click on ‘+’ for a new tab I’ve seen the whole browser crash. If I try again a few minutes later it seems to work, so if you see something odd you might want to try something else and then come back to the problematical action.