Here is a very simple official JNI method called in MainActivity’s onCreate.

extern "C" JNIEXPORT jstring JNICALL
Java_com_example_openclplayground_MainActivity_stringFromJNI(
        JNIEnv* env,
        jobject /* this */) {
    auto cl_handle = dlopen("/system/vendor/lib64/libOpenCL.so",RTLD_LAZY);
    __android_log_print(ANDROID_LOG_DEBUG,"sxf","dl result2 is:%s",dlerror());

}

It is found that every time the app process is killed and re entered, the dlerror will print “undefined symbol: jni_onload”

If the same dlopen method is compiled and run on the computer, there must be no error, and there is JNI tag in the error field. It can be seen that this error is related to Android.

And because of the official explanation of dlerror

The dlerror() function returns a human-readable, null-terminated
       string describing the most recent error that occurred from a call
       to one of the functions in the dlopen API since the last call to
       dlerror().  The returned string does not include a trailing
       newline.

It can be seen that the error reported by the dlerror is the information of the last error from the last dlerror to this one.

So change the program a little and change it like this

extern "C" JNIEXPORT jstring JNICALL
Java_com_example_openclplayground_MainActivity_stringFromJNI(
        JNIEnv* env,
        jobject /* this */) {
    __android_log_print(ANDROID_LOG_DEBUG,"sxf","dl result2 is:%s",dlerror());
    auto cl_handle = dlopen("/system/vendor/lib64/libOpenCL.so",RTLD_LAZY);

}

You can see that the error “undefined symbol: jni_onload” will still be reported

In fact, there was no error in our dlopen. The Android system reported an error in some strange things, and then it was not emptied with the dlerror. As a result, we got a dlerror of the Android system at the beginning of dlopen and then the dlerror.

Solution

1. Ignore the error.

2. Call dlerror once before calling dlopen