I'm working on a large game engine that must be ported to Android. All the code is C/C++, so we are porting via the NDK. I've got everything building, but after lots of scouring, I'm still uncertain what the best method is for building Debug vs. Release versions of our .so file. Changing things by hand every time is getting old.
Do you have different Application.mk files for each target? Or is there some way to include multiple targets in a single Android.mk file under the jni/ directory? Or perhaps a third option might be to write a standard makefile that sets environment variables that the Android.mk file uses to inform the build process?
Finally, one last question regarding the android:debuggable flag that must be set in the AndroidManifest.xml file. What this actually have any effect on the generated native code that's copied to the device?
Best and thanks,
Kevin
Do you have different Application.mk files for each target?
No. Separate subdirectories, all with their own Android.mk (shared and static libs) but only one Application.mk for me.
My Application.mk is just:
APP_STL := gnustl_static
APP_OPTIM := debug
I'm still uncertain what the best method is for building Debug vs. Release versions of our .so file. Changing things by hand every time is getting old.
It's a bit spread out, for me at least, using the jni/Android.mk + Application.mk layout.
Application.mk has APP_OPTIM := debug
Then in the application element of AndroidManifest.xml I have android:debuggable="true"
When you build with ndk-build, it uses this manifest flag to determine optimization (which is useful to turn off or on, off for profiling, etc.)
(A Little Off topic) I recently ran across
https://code.google.com/p/android-ndk-profiler/
Which, when combined with http://code.google.com/p/jrfonseca/wiki/Gprof2Dot
Generates some pretty images to help my little mind grasp how things are running over on the phone itself.
You're not required to use the Android.mk system to build your .so's. Personally, I use my own Makefile's with the targets I need and this allows for very standardized debug vs. release build specification.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With