The only time I fire up the emulators is to make sure my assets are scaling properly for the various screen sizes of devices I don't own yet.
If you start with video (or even audio) displaying/capturing then the emulator is pretty fast useless indeed.
One pain point I have, though, is the need to always hit the VirtualBox host key when switching between Eclipse and VirtualBox, since there's no true integration. Sometimes I also get some weird effects with the mouse pointer not being able to move around the entire framebuffer. (Hmm, maybe a VirtualBox integration module for android-x86 would be a good weekend project...)
The Android 2.2 and 2.3 Emulators are atleast on my machine fast enough for development, but i still prefer to develop against hardware just because it feels faster and more real. Multi-Touch is easier...
Even on iOS it's better to develop against actual hardware than the simulator, therefor it's not really that much of an issue.
I dont think its fair to call the emulator an obstacle, it just comes with limitations. After all, emulators are only designed to emulate, they can't replace areal device. A hammer is still a tool, its just not the appropriate tool when you're trying to assemble a clock.
Maybe its just time to upgrade your tools.
XCode isn't perfect, but I don't need google for blog posts or spend hours writing scripts or messing with configuration files in order to get it into a usable state.
Being open source has nothing to do with how easy a platform is to develop on. All that means is that the platform's source code is available.
Debugging on a phone is not so bad, but it's not quite as nice as the iOS simulator experience.
I figured it was important to test on a low end phone, right? ( see how I nicely justified my cheapness there?) The downside to that plan was the jQuery Mobile bug that only showed up on top end devices (now the Huawei has a Galaxy S2 siting next to it...)
They are the Google Reference devices. Admittedly, it's perhaps not as lean as what you're referring to, but as a testing sandbox, I've tried a lot of different phones, but nothing has worked as well, in a general sense, as the reference models.
But just working from (non reference) phones is dangerous too, it's so annoying to implement the volume controls with a BroadcastReceiver for the ACTION_MEDIA_BUTTON Intent (works great on Motorola's), but fails on HTC, and you should just override onKeyUp()... all (Android) phones behave differently, and not only in (screen) specs. Samsung Galaxy S (<2.2) is notorious in not following the Android specs, for example it shows the versionCode instead of versionName to the user [http://developer.android.com/guide/publishing/versioning.htm...] and if you do some (proxy) audio stream playback there is the [http://google.com/search?q=PVMFMemoryBufferReadDataStreamImp...] error with no real solutions...
The problem is, in the end, it should work on the popular devices, not the 'perfect' Android reference phones..
* No Google APIs. So no MapView.
* The various builds are quirky. I couldn't get networking to function in the "Stable" Froyo build. Meanwhile, the Gingerbread build used in the linked post reports the wrong SDK version (it claims Honeycomb but is actually Gingerbread). The deprecated Froyo build I tried didn't support Google Accounts. And so on.
Meanwhile, new builds are currently impossible due to the ongoing kernel.org outage (android-x86 has some hard submodule deps on git.android.kernel.org), so my attempts to go in and tweak the build were thwarted.
Still, very cool stuff. I think the iOS simulator is fantastic and I've been pining for something similar for Android. This doesn't quite meet my needs at the moment, but it would save me multiple hours per week if I could get it set up properly.
The question is whether you can make the emulator run as fast as modern dual core android phones.
Why not? A lot of programmers develop native apps on high-performance workstations because it makes development faster.
Once in a while, you might hit a bug in which the execution time on a phone or in a slow emulator will cause problems. These are the exception to the rule. Use good programming practices especially with respect to multithreading and time-sensitive code and use sensible algorithms (don't under- or over-optimize), and these will be few and far between.
In general, you want fast builds, fast tests, and fast iteration. Anything that allows you to iterate faster is a good thing.
* Presuming you want your NDK app to run any Intel-based tablets/phones.
I get to the home screen with everything loaded in about 18 seconds. I'm on a fairly new system with decent processor and memory to spare, but even on my old single processor 4GB laptop I get the emulator launched in about 35 seconds.
Actually, it is closer to 70 seconds.
Then the lag while attempting to use it is unbearable, it stutters, input is completely ignored, or it crashes randomly when we try to replicate that bug on an actual device we can't.
Core2 Duo, T7500 @ 2.20GHz 4GB RAM Patriot Inferno SSD
2.3 load time from start to lock screen: 65 seconds.
