Revision history [back]

Apparently this stems from wrong information in the documentation as to how to setup the jni part of an application that also wants to access OpenCV from it's native library. The problem is this line in Application.mk:

APP_STL := gnustl_static

This needs to be gnustl_shared instead, and you need to do a System.loadLibrary("gnustl_shared"); once in your app before invoking OpenCV Manager to load OpenCV. This loads the shared library version of the GNU STL (instead of compiling it into your own lib).

Today I've come across this post on stackoverflow explaining the cause. After reading that the pieces finally fell into place. Both my own library and OpenCV use the gnustl, and opencv was apparently (and correctly!) compiled against the dynamic version.

This is even necessary, and clearly explained in the NDK documentation IN CAPS TEXT to make sure it's not ignored:

Please keep in mind that the static library variant of a given C++ runtime
SHALL ONLY BE LINKED INTO A SINGLE BINARY for optimal conditions.

It goes into more detail why, but the point is we have multiple binaries: we have libopencv_java, which is loaded by the manager, and libyourstuff (libCamAnalysis in my case) containing whatever you have in your own library (containing your own native code). Linking statically with the gnustl is therefore a very very bad idea as the global state might exist twice in one application and can cause memory corruption and all sorts of other nasty stuff.

Unfortunately, the official tutorial on how to create an OpenCV Android app with an own native part (Section "Native/C++") instructs the user to set APP_STL to gnustl_static. I hope this is fixed soon!