[ericd]

The shoddy state of the simulator really irks me on Android - it's really necessary that it works well, because there are so many different models of phone.

The Android version of my app apparently has a crash-on-startup bug on a single type of Android phone (Droid X), shows up as windowed in others, and works just great on the Nexus/Droid I've tried it on. I can't test on all that physical hardware, though, and the emulator is slow enough that it's nearly useless - various background services on the virtual machine complain about timing out when starting it up.

The fragmentation of that market doesn't seem worth dealing with for the amount of activity on the marketplace.

[Locke1689]

I actually have a pretty massive patch for QEMU sitting in a computer somewhere (with a pretty massive bug) so I know QEMU pretty well. QEMU is actually very fast if used correctly. Android is not using QEMU correctly. I'm not really sure what they're doing wrong but if I can virtualize a VMM which then virtualizes another OS and the interaction is essentially real-time, basic ARM and Java should not be out of the performance target.

P.S. If you think QEMU is slow, don't even think about Bochs.

[jamesg]

QEMU is a truly awesome piece of code. Everything Fabrice Bellard does is incredible.

You could well be right that they're not using it correctly -- that sounds entirely plausible. I guess my point was more that, whatever the cause, the net effect of it is that the Apple Simulator is unrealistically fast, and the Android Emulator is unrealistically slow. Neither really encourage great development if you rely on them.

[Locke1689]

Agreed -- I just wanted to defend QEMU (and my own work, by extension) for a moment.

Also, code can always be made to go slower so I'm not sure if "unrealistically fast" is as bad a "unrealistically slow."

[kbutler]

It's actually much easier to "virtualize another OS" than to virtualize a hardware platform (and associated OS).

If you are running guest code that matches your host architecture, QEMU can run the code natively. If you are running foreign code (e.g., ARM on an Intel host), it has to dynamically recompile the code, which will hurt performance.

kb

[Locke1689]

Actually, my research was simulating a different hardware architecture and the patch I have is for hardware-assisted virtualization under arbitrary hardware architectures. It does have to recompile the code, but the TCG does a pretty good job of that. The virtualization target can do a lot better by keeping TCG in mind while structuring its binary execution, which may be one thing that they don't try to do in Android.

[rbritton]

The lack of a decent simulator also affects web apps. I downloaded the SDK and installed it in hopes of using it to test mobile versions of sites. It's rather difficult to test when it can take ten minutes to fully load and render a page!

[kellysutton]

I can second this one thousand times. I developed the blip.tv Android app. It runs well on the Samsung Galaxy S phones, but crashes on startup on _all_ other Android devices. No clue why.

[jimrandomh]

Do you have a debugger attached? I've found that Android's emulator is a bit slow, but not unreasonable; but then attaching Eclipse's debugger slows it down by two extra orders of magnitude, which makes it unusable,