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.
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:
True enough, but aspects like memory consumption can still be tested on an emulator. Due to differences in x86 and ARM code gen, it can be beneficial to get actual numbers.
There are also aspects like ease of automating. An emulator running on a desktop is easier to fiddle with than an actual device.
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.
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.
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.
