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 for more ways on how to speed up your emulator.
"Emulator without GPU emulation detected."
Is it accelerated anyway?
emulator -avd 403_r2 -gpu on
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.
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?
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.
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.
Just a fact I thought you might find interesting.
There are also aspects like ease of automating. An emulator running on a desktop is easier to fiddle with than an actual device.
How about running dalvik in x86 and just emulating NDK calls? Should give a nice speed boost while still supporting native ARM code.
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.
I'm not sure what you mean by this. Example?
>Also it is not like the problem isn't relevant with using QEMU, it remains relevant.
Which problem? Being consistent across multiple platforms? QEMU is fairly good at this.
When I say there are problems with the simulator, I mean like the whole audio api wasn't working on the simulator for awhile. This isn't a small difference, this made it so that I couldn't even test the app. (Not to mention the other hardware support I needed, accelerometer/gyroscope data, wasn't supported either).
"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.
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.
I think that's overstating it a bit. The NDK is very heavily used by the overwhelming majority of premium games, not least because it allows for significant code reuse between Android and iOS. The release of the NDK was the beginning of a massive quality app explosion on the platform.
e.g. (in the Application.mk)
APP_ABI := x86 armeabi armeabi-v7a
This app will run with gust on any of those platforms.
There's no way I'm going to deal with cold booting the emulator instead of using snapshots.
That said, this will make app development much nicer.