I would be extremely interested in how you approach that-- specifically with respect to the debugger. I'm using the canonical eclilpse/cdt/gdb stack and it is nothing short of torture compared to any modern IDE.
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 applications we build are cross-platform games, and the Android-specific code is reduced to the bare minimum and abstracted behind a framework.
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.
same thing here, we restricted our public APIs to native scalar types, and the JNI glue is just a wrapper around these functions. Off the top of my head, we only expose a couple functions to set the native surface handler, get a valid reference to the AssetManager, and receive input notifications.
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 do audio programming, among other things. This sadly requires a familiarity with low level mobile development that many find.... distasteful.
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.
I can recommend you the book "Advanced Android 4 Games" from Apress, the book basically consists in porting C/C++ games to Android, but it has everything you need to get started.
You should also check SDL 2.0 if you are starting a new project, they already did all the heavy-lifting for you.
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.