Can you elaborate on why you think it's currently a second-class citizen?
Another reason why Android is losing on the developer front is that development environment setup and usage, even for Java, is worse than Apple's. It's usage of Eclipse is like duct tape and glue.
Yet, debugging with a galaxy nexus on usb is buggy for me (sometimes it works sometimes it won't). reboot might help ... I just love instruments in xcode.
As code editor I use MacVim (faster and a much cleaner look for me compared to IntelliJ as it's a coca citizen and not a Java GUI app ... ).
I can't imagine giving up all the code editing features of IntelliJ for any generic text editor though. All that java and XML without code completion and refactoring is just too horrible to contemplate. If you're determined to go that route then why not just ditch the IDE entirely and do everything from the command line?
I usually use Xcode/IntelliJ for refactoring and some more advanced functionality.
And although there are quirks (mainly performance related) in the ADT/Eclipse combo your description is far from my experience. The overall experience is better, IMO, than Xcode. The latter is the buggiest IDE I've ever used.
Frankly AppCode/IntelliJ beat both in many respects, but frustratingly don't quite cover the full range of functionality. It's difficult to make the leap when you need to go back to Xcode/Eclipse to accomplish some of your work each day.
Then when you get to single stepping its ridiculously slow. Anyone that has used or attempted to use the NDK debugger cannot say with a straight face that it is up to par with modern tools.
Oh...then there is the issue of ridiculously uninformative stack traces.
Its generally easier to build your code in an x-plat fashion in C++ and then work out as many bugs on iOS as you can and then - as the parent said - leave printf turds everywhere.
Stone knives and bear skins...
I used xcode for more than three years now, wrote a lot of object c/c/c++ and even assembler, and yet to find any major bug. This year I tried to port one of my app to Android, and the biggest challenge happens to be debugging native code. Basically you can't, there are some tutorials to set up gdb, but it shouldn't be that hard, and I don't bother. I ended up with printf, of course it is a nightmare.
If Google can deliver a xcode quality IDE, it'd already ruled the world.
It's a relatively new addition, and as warned above it still might not work in all setups in my experience. But it's worth a go.
I think this is mere perception vs reality. Android development environment is far superior to XCode. Using IntelliJ for Android Development is a true pleasure working with Android. I have no problems debugging over USB on my Mac ever.
The game industry is incredibly rigid to any change. Once they've found their horse they will not walk away from it, and show little interest in changing how they approach development ever. This isn't the first time we've seen some long article with game studios wringing their hands over any change.
Allow Android games to be fully written in C/C++/Go with a fat binary format to support ARM/x86 and now we're talking. You can kind-of-sort-of do native development in Android using the NDK but it is much more of a pain in the ass than it should be because Android's userland was designed so tightly around Dalvik and Google has always treated the NDK as a bit of a red-headed stepchild (eg. it was never officially supported on the x86 Google TV boxes).
The only possible reason having better support for C/C++ development is so that ports are easier (assuming the original is written in C++).
That's kind of the point; the tooling for native development is crap compared to working in Java, which, while a fine language for lots of purposes, brings a few performance penalties that can inhibit game development. Apart from the overhead of a VM, games often require precise timings that are difficult to achieve when a garbage collector can be running at unpredictable times. And I think you're dismissing the porting angle a bit quickly. When faced with the choice between converting your entire codebase to a different language, using difficult tools with poor debugging support, or starting a new project on a platform you're already successful on, which would you choose?
If you want more people to develop for your platform let them develop for your platform the way they are comfortable. Support C, Ruby, Pascal, Lua, Lisp, BASIC and even Logo.
Not perl though, That'd just be sadistic.