The Android Honeycomb Emulator

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.

 

If you have any tips you’d like to share please feel free to post them in the comments below or send me a message on twitter.

8 thoughts on “The Android Honeycomb Emulator

Add yours

    1. fanfan

      because ios apps are all written it objective-c code. once that code is compiled to arm it does not need to be compiled again. android apps are compiled to machine agnostic byte-code and must be compiled again on the fly to run on the physical device cpu.

      in the scenario of development emulators on the PC, you are also running an emulator to translate the virtual device into x86 code. this means that while that apps running inside the ios emulator are only going through one level of translation, while the android is going through two (doing it twice).

      this does not mean however that there is anything inherently superior about ios than android. in fact, there are “certain” cases where it makes android better in “ways”. one example is stated in the article. operations in dalvik’s just-in-time that are cached can sometimes be optimized and actually execute faster than native code such as that used in ios apps. also, this provides for application compatibility. because of the dalvik vm, the same app can be run on different versions of android. this is why apps for say an iphone complied for arm arch can not run on a x86 mac or a ppc mac despite all three running the same operating system kernel. in contrast to this, in theory, a app packaged for android can run on a MIPS port of android, which hopes to compete with ARM in the mobile market soon, or it could run on a x86 netbook port of android if such a thing existed and there were drivers.

  1. Two quick notes on what I’m seeing with the final 3.0 release.

    On the plus side, you can edit an AVD configuration through the SDK and AVD Manager, so you don’t need to hand-modify the INI file.

    On the minus side, I can’t run it with less than 1GB of device RAM. Leastways, 512MB was getting me nowhere. And a 2.66GHz quad-core is sluggish, courtesy of the single-core limit.

    1. The performance is something that really needs some work. On my machine the start-up can take between one and a half and two minutes, after which I the app I’m working on may not get installed via the ADT on Eclipse so I have to go through it again, and to see that on an 8 core with dual 2.4Ghz Xeon CPUs with 20GB of RAM indicates to me that it may be time to move away from the single-threaded qemu.

  2. I was just about to make a post like this myself on my own blog but you have beaten me to it. Essentially I agree with your breakdown of the Android Honeycomb Emulator. However I would like to add that there is a patch to QEMU mentioned on the Wikipedia page called COREMU that apparently adds physical multicore support to QEMU. Therefore, I am hoping that the Android development team might be able to push a multicore change into the emulator or QEMU by using that code. It certainly sounds like it would be an easier win. Anyway, thanks for the good post.

  3. For the time being, since the emulator lacks multi-core support, I find it best to set the affinity to run on a single core. I have a Core i7 860 and notice a nice little performance boost. It is still not as efficient as my Droid 2 Global but at least some of the sluggishness has decreased.

  4. So you’re saying there isn’t much we can do to speed up the Android emulator? That’s a shame, because Apple is light years ahead with their emulator…

Leave a Reply

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

Proudly powered by WordPress | Theme: Baskerville 2 by Anders Noren.

Up ↑