

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

======
mdwrigh2
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...](http://developer.android.com/guide/developing/devices/emulator.html#accel-
vm)

~~~
robot
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?

~~~
mdwrigh2
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.

------
jsherer
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.

~~~
shadowmatter
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
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.

------
hub_
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.

~~~
com2kid
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.

~~~
drewcrawford
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.

~~~
nekitamo
The binaries built by the Android NDK are emulated on the emulator properly.
I've deployed NDK binaries on the emulator and traced it with IDA Pro, one
line of ARM assembler at a time... So yes, it's a proper emulator.

Just a fact I thought you might find interesting.

~~~
drewcrawford
But does an ADD instruction on ARM take the correct multiplier of time as the
MUL instruction? No, because time-accurate emulation is shockingly hard.
Further reading:

[http://arstechnica.com/gaming/news/2011/08/accuracy-takes-
po...](http://arstechnica.com/gaming/news/2011/08/accuracy-takes-power-one-
mans-3ghz-quest-to-build-a-perfect-snes-emulator.ars)

------
w-ll
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.

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

------
learc83
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.

------
verminoth
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!

~~~
mdwrigh2
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.

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

