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.
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.