Morning!

I've created a small NDK project which allows dynamic serialisation of objects between Java and C++ through JNI. The logic works like this:

Bean -> JavaCInterface.Java -> JavaCInterface.cpp -> JavaCInterface.java -> Bean

The problem is I want to use this functionality in other projects. I separated out the test code from the project and created a "Tester" project. The tester project sends a Java object through to C++ which then echo's it back to the Java layer.

I thought linking would be pretty simple - ("Simple" in terms of NDK/JNI is usually a day of frustration) I added the JNIBridge project as a source project and including the following lines to Android.mk:

NDK_MODULE_PATH=.../JNIBridge/jni/"

JNIBridge/jni/JavaCInterface/Android.mk:

...
include $(BUILD_STATIC_LIBRARY)

JNITester/jni/Android.mk:

...
include $(BUILD_SHARED_LIBRARY)
$(call import-module, JavaCInterface)

This all works fine. The C++ files which rely on headers from JavaCInterface module work fine. Also the Java classes can happily use interfaces from JNIBridge project. All the linking is happy.

Unfortunately JavaCInterface.java which contains the native method calls cannot see the JNI method located in the static library. (Logically they are in the same project but both are imported into the project where you wish to use them through the above mechanism).

My current solutions are are follows. I'm hoping someone can suggest something that will preserve the modular nature of what I'm trying to achieve:

My current solution would be to include the JavaCInterface cpp files in the calling project like so:

LOCAL_SRC_FILES := FunctionTable.cpp $(PATH_TO_SHARED_PROJECT)/JavaCInterface.cpp

But I'd rather not do this as it would lead to me needing to update each depending project if I changed the JavaCInterface architecture.

I could create a new set of JNI method signatures in each local project which then link to the imported modules. Again, this binds the implementations too tightly.