Those of us doing C++ on Android still cannot.
Plus Eclipse has quite good static analyzer, which is something non optional when I code in languages like C and C++.
I mean, eclipse is a broken hellscape of failed promises on its own, but gdb is.... words fail me. Truly. AND I KNOW HOW TO USE GDB PRETTY WELL.
The development and debugging is done with the desktop version of the game. We avoid using Eclipse & friends unless we manage to break something at the Android side, which fortunately almost never happens.
We found this approach to be the most productive and less frustrating for our team.
the Java code base only consists in a single Activity object and a ScaleListener.
We also ended up integrating our android build process in visual studio using a mix of python/batch scripts.
The make utility provided by the NDK is notorious for not being able to process absolute windows paths, so we cannot use the all-subdir-makefiles command. A workaround was to use a simple python script to generate a viable Android.mk file, setting the LOCAL_SRC_FILES var with a list of relative paths to our source files.
In the post-build event of a dedicated VS project, we batch the calls to ndk-build, the ant command, and the final little adb dance.
with the proper file hierarchy (src, res, jni and asset directories), the build process is very smooth.
I would advise anybody listening to stay well away from NDK programming. Here there be dragons. Google has done their absolute best to pretend nobody ever needs to get their hands dirty in android. Which would be nice, if it were true.
Native development is a pleasure in iOS and Windows Phone.
On Android it feels like something Android team was forced to provide by upper management and do as little as they can.
Which given their reaction to alternative languages on the Android Team Fireside, might actually be true.
You should also check SDL 2.0 if you are starting a new project, they already did all the heavy-lifting for you.