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?
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.
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.
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").
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.
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.
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.
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.
> it is not like they support it correctly in one single platform.
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.
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.
which is not usually done except where you need to wring every last bit of performance out of the device
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.
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.
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.