Android: Faster emulator with better hardware support

http://android-developers.blogspot.com/2012/04/faster-emulator-with-better-hardware.html

by joshbaptiste • 14 years ago

165 38 14 years ago

android-developers.blogspot.com

hub_3• 14 years ago

They should use the iOS Simulator approach: have the whole "emulator" build native on the host PC instead of running the ARM version in qemu.

varunsaini• 14 years ago

Maybe they tried that. but Apple had patent on that.

nextparadigms• 14 years ago

Isn't that what the article says, too?

"Last week’s r17 developer tools release included x86 system images and host drivers (available through the SDK Manager), allowing the emulator to access the host CPU natively and offer significantly faster execution."

I just wonder, does this mean that the apps built on this version will only work on x86 devices and you need to modify the app later to work on ARM devices, too? Because if that's the case I probably won't bother with this, since 99.9% of Android units have an ARM chip.

njs12345• 14 years ago

Almost certainly not --- Android apps are compiled to a platform independent bytecode anyway, so there's no reason the compilation process would be any different here.

See http://en.wikipedia.org/wiki/Dalvik_(software)

psquid• 14 years ago

Nope. Android apps are, with one caveat, independent of any particular architecture, due to their Java/Dalvik base.

The only situation where anything developed on x86 would not also work on ARM is if you include native code via the NDK (which is not usually done except where you need to wring every last bit of performance out of the device), and that's just a matter of building the native code for all the platforms you intend the app to run on.

The platform used by the emulator image makes no difference to any of that, it just makes it a lot more practical to get usable speed out of it.

ryanpetrich• 14 years ago

It's still running the Android flavour of the Linux kernel along with all its various processes inside of a VM. iOS Simulator runs SpringBoard, the various iOS daemons, and any user apps as native processes on the host OS X system. The difference may be negligible though.

huggyface3• 14 years ago

Aside from the managed bytecode, when you build with the NDK you can target multiple platforms in the same APK.

e.g. (in the Application.mk)

APP_ABI := x86 armeabi armeabi-v7a

This app will run with gust on any of those platforms.

com2kid2• 14 years ago

There are different trade offs for each technique. Aside from ensure that native code functions properly (e.g. Android NDK), you can get platform specific perf metrics from an emulator that you just do not get from running x86 code.

With Android apps running in a VM this is not as much of an issue, but it is still nice to have.

The downside is that writing performance emulators for 1ghz+ multicore ARM chips is hard. :) GPU virtualization helps out a fair amount with this.

As an aside, they do have a virtualized mode that appears to be sort of a hybrid between an emulator an Apple's technique. I believe they are still running the entire Android OS, but it is a native x86 version of it so you get much better performance.

The other cool part about having an emulator is that once your emulator is complete enough, you can add in emulation support for all sorts of sensors, GPS, etc, and they are truly emulated and the programmer can interact with them the same way they would on the device (with the need for some sort of "feed arbitrary input" code paths of course).

When you just have a glorified UI toolkit that has been ported to the Desktop, everything else (GPS, sensors, etc) can end up special cased.

m_eiman• 14 years ago

There are different trade offs for each technique. Aside from ensure that native code functions properly (e.g. Android NDK)

How about running dalvik in x86 and just emulating NDK calls? Should give a nice speed boost while still supporting native ARM code.

drewcrawford2• 14 years ago

As an iOS dev, I can tell you, I would much rather be doing my perf optimization on real hardware than on an emulator, even one that emulates clock-for-clock (and I highly doubt that the Android NDK does, although perhaps they ship a tool that lets you extract this information).

Just for starters, if I am profiling code, it's probably because the code is slow. (Infamously, for awhile we had a 13-hour unit test). If a quad-core 1ghz ARM device is slow, the last thing I want to do is throw an emulator into the mix.

hub_3• 14 years ago

Performance testing in any case has to be done on the target device. Neither iOS Simulator nor the Android Emulator are appropriate.

mdwrigh27• 14 years ago

The problem with the simulator approach is then you have to make sure all of the APIs behave exactly the same both on the desktop and the phone (which are running two different processors). This certainly causes some issues (the Simulator has had no end of trouble with the sound APIs in the last 6-12 months, and only recently has it even allowed me to play sounds, albeit while still throwing exceptions, for example).

On top of that, Apple only has to worry about being consistent on two platforms: OS X and the device (iPad, iPhone, etc.), whereas Google supports all three major platforms (Win, OSX, Linux) and doesn't control the underlying hardware.

hub_3• 14 years ago

it is not like they support it correctly in one single platform. Also it is not like the problem isn't relevant with using QEMU, it remains relevant.

TazeTSchnitzel• 14 years ago

Thank God for this. Android 4.0's UI in the emulator was not a pleasant experience.

w-ll• 14 years ago

This is very good news to hear. It seams with each major release of android, the emulator got that much slower. Tablet work is damn near impossible (even on my i7 w/16gb all sitting on ssd). Very good news indeed.

jsherer• 14 years ago

After updating my dev tools through the SDK, I wondered why I couldn't run an x86 system image. The update doesn't select it for installation by default. Selected "Intel Atom x86 System Image" for the Android 2.3.3 system and everything works. Seems a little bit faster. Though, I really wanted to test it out with Android 4.0.

mwsherman• 14 years ago

> Last week’s r17 developer tools release included x86 system images and host drivers

I am confused by this announcement. Does that ^ refer to the 2.3.3 version?

I don't see any x86 for 4.0+. What am I missing?

mdwrigh27• 14 years ago

No, this blog post referring to GPU emulation and some improvements they've made to floating point emulation.

mdwrigh27• 14 years ago

You can still get GPU emulation on Android 4.0 - this isn't tied at all to the x86 images for 2.3.3. When creating an image, just make sure to set the hardware property "GPU Emulation" to "yes" (you can do this by creating a new emulator, or editing a current one, going to "Hardware" at the bottom, clicking "New" on the far right, selecting "GPU Emulation", hitting okay, double clicking on GPU Emulation in the property list and setting it to "yes").

shadowmatter• 14 years ago

I was testing this last night. It reduced the time for the emulator to cold boot from 120-130 seconds down to 45-55 seconds. Not as snappy as the iPhone simulator, but over cutting the time by over half is really substantial. Props to them.

mike-cardwell• 14 years ago

I just tested it on my Lenovo Thinkpad T420. Takes about 65 seconds using a VM with the 2.3.3 ARM image, and 6 seconds using the 2.3.3 x86 image taking advantage of my CPUs VT instructions...

Literally 6 seconds after typing "emulator-x86 -avd TestImage -qemu -m 512 -enable-kvm" and hitting return, until I'm at the Android login screen.

This laptop has an i5-2520M CPU @ 2.50GHz, 8GB of RAM and an SSD.

verminoth• 14 years ago

I remember waiting at least a minute or more for the Android emulator to boot up and I just gave up on it. This is going to be so make development so much easier!

mdwrigh27• 14 years ago

The simple fix to this is to use the snapshot system that's built-in. Start it up once, and then just continually deploy your app to it.

That said, this will make app development much nicer.

mdwrigh27• 14 years ago

Note that you have to enable GPU Emulation for any given AVD first! A lot of people seem (understandably) confused that their emulator wasn't suddenly much faster with this update.

Quick Start Guide to Getting GPU Emulation Working:

* Open up the settings for your AVD (either by creating a new one or editing a current one)

* Go to Hardware (near the bottom), and hit new on the far right

* Select GPU emulation from the drop down list and hit okay

* Find GPU emulation in the list of properties under hardware, click on the value column and set it to "yes"

See here[1] for more ways on how to speed up your emulator.

[1] http://developer.android.com/guide/developing/devices/emulat...

robot• 14 years ago

I am wondering about the opposite case: how do they emulate graphics when there is no GPU support? Do they emulate the GPU device, or use a software library? Which library if it is done in software?

mdwrigh27• 14 years ago

Essentially all of the commands on the device are translated into native OpenGL calls, so I suspect if you don't have a GPU you just get the default OpenGL software renderer.

huggyface3• 14 years ago

To add an anecdote about this new functionality, I have been unsuccessful using the GPU acceleration (x64 Windows 7 with an nvidia GTX 560 w/latest drivers). With the emulation on the AVD GPFs with emulator-arm.exe has stopped working (invalid access). Anyone have success?

blinkingled• 14 years ago

Me neither - Win 7 x64 Sandy Bridge GPU.

biafra2• 14 years ago

I did as you suggested but in the logcat output I see the following message:

"Emulator without GPU emulation detected."

Is it accelerated anyway?

biafra2• 14 years ago

It seems to be working if I start the emulator on the command line via:

emulator -avd 403_r2 -gpu on

nixa• 14 years ago

I don't know why they haven't added Google API support.

learc83• 14 years ago

Tried the new GPU emulation, and got a warning that snapshots and GPU emulation are mutually exclusive.

There's no way I'm going to deal with cold booting the emulator instead of using snapshots.

Android: Faster emulator with better hardware support

Related Stories