13

I have integrated two native libraries (.so ) in my application. The libraries compile fine and I can load them in my application too. The first time I invoke a native method of a library it works fine, but if I call the same method again in the Activity the application shuts down.

The problem I am facing is exactly the same as mentioned in here :
http://grokbase.com/t/gg/android-ndk/1226m68ydm/app-exit-on-second-native-call

The solution that works is to invoke the native method in another Activity and shut it down forcefully via System.exit(0). Following the article I tried setting the pointers to NULL of the called method after a successful operation, but this too didn't help me. Also its not possible to unload a library once its loaded by System.loadLibrary().

I want to call the native methods more than once without creating a new Activity. Any ideas how to solve this issue ?

(I FINALLY FOUND A SOLUTION ... HERE IT IS)

Okay, I have finally found a way to resolve this issue. The solution is actually pretty simple. Build another independent native library (utility library) to load and unload the other libraries. What we need to do is use dlopen() and dlclose() in the native method of the utility. We can load the utility library like before via System.loadLibrary().

So in the native method of the utility library what we need to do is:

Use#include <dlfcn.h> // this is required to call dlopen() and dlclose() functions.

Provide handler and function prototype:

void *handle;
typedef int (*func)(int); // define function prototype
func myFunctionName; // some name for the function

Open the library via dlopen() : 

handle = dlopen("/data/data/my.package.com/lib/somelibrary.so", RTLD_LAZY);

Get and Call the function of the library:

myFunctionName = (func)dlsym(handle, "actualFunctionNameInLibrary");
myFunctionName(1); // passing parameters if needed in the call

Now that the call is done. Close it via dlclose():

dlclose(handle);

Hope this will help others facing the same issue.

ZakiMak
  • 2,072
  • 2
  • 17
  • 26
  • where do you do dlclose(handle)? I mean in the Activity or JNI code? – Arif Nadeem Aug 24 '12 at 11:15
  • Its in JNI code. It's a function available via dlfcn.h header file. – ZakiMak Aug 26 '12 at 10:14
  • ok got it, I see that you load and unload other libraries in this c class. But how should I link it to my Java code? – Arif Nadeem Aug 27 '12 at 08:00
  • You will need to know about NDK. [link](http://mindtherobot.com/blog/452/android-beginners-ndk-setup-step-by-step/) - this tutorial will show you how to do it all step by step. In short once your NDK environment is ready: 1. You need to write the C file. 2. Write your Android.mk file to generate the .so - shared library. 3. Build the .so file using ndk. 4. Write the Java class where you will expose the native methods and also load the library via System.loadLibrary in a static block. – ZakiMak Aug 28 '12 at 09:26
  • I already did that, I was wondering if I have to call this helper libraries methods in Java code, anyways can you please provide a link where I can learn more about the above answer to your question. – Arif Nadeem Aug 29 '12 at 08:17
  • 1
    I wonder how you got dlclose to work, in ndk-documentation it clearly states that "Static destructors are never called at the moment, either at program exit, or when dlclose() is called." PLEASE REFER TO NDK folder (where ndk is unzipped on your system and refer to SYSTEM-ISSUES.html) – Arif Nadeem Sep 06 '12 at 07:38
  • This is in reply to the question posted on 29th August. Yes, I had to call the helper library methods in Java. Once I had the helper library .so file generated, I wrote a separate Java class which loads the helper library and has a native method declared to access the library method. The tree is like this: Java Class to load and declare native method for helper library->access library method->library method loads and unloads the other libraries as needed. Sorry, but I could not find any link that documents the steps to make it easier...but feel free to get in touch. – ZakiMak Sep 07 '12 at 17:43

2 Answers2

6

So ... my solution was starting a service that runs the shared library code, this service has a different process name ( you can set it in the Android Manifest ), as it is a different process you can kill it ( Using Process.killProcess(Process.myPid()) when it finishes running, without affecting your application in any way.

Worked very well for me, hope it helps someone else.

MindTrip
  • 283
  • 6
  • 12
3

As this is the top hit for this issue and as the issue itself still exists, it seems that the approach that ZakiMak shared with us is still the most popular solution.

For others who may want to implement it and would like a little more detail for the latest Android releases, here are some notes I made as I stumbled through this:

  • Firstly, there is a solution which implements this approach on GitHub now. I have not tried it personally, but I have used it as a reference. It is very useful to see how the Android.mk file is structured and how the library is opened and methods called. Link is here: https://github.com/jhotovy/android-ffmpeg
  • The path to the native library folder changes over Android releases and it also appears to change every time you run the app (although this may be just in debug mode). Either way, it is best to pass the path in from the calling Java method if possible. For example:

In the Java wrapping class:

import android.content.Context;
import android.util.Log;

public class FfmpegJNIWrapper {

    //This class provides a Java wrapper around the exposed JNI ffmpeg functions.

    static {
        //Load the 'first' or 'outer' JNI library so this activity can use it
        System.loadLibrary("ffmpeg_wraper_multi_invoke_jni");
    }

    public static int call_ffmpegWrapper(Context appContext, String[] ffmpegArgs) {
        //Get the native libary path
        String nativeLibPath = appContext.getApplicationInfo().nativeLibraryDir;

        //Call the method in the first or 'outer' library, passing it the
        //native library past as well as the original args
        return ffmpegWrapper(nativeLibPath, ffmpegArgs);
    }


    // Native methods for ffmpeg functions
    public static native int ffmpegWrapper(String nativeLibPath, String[] argv);

}

In the 'first' or 'outer' native library:

JNIEXPORT jint JNICALL Java_com_yourpackage_androidffmpegwrapper_FfmpegJNIWrapper_ffmpegWrapper(JNIEnv *pEnv, jobject pObj, jstring nativeLibPath, jobjectArray javaArgv) {

    //Get the second or 'inner' native library path
    char* nativePathPassedIn = (char *)(*pEnv)->GetStringUTFChars(pEnv, nativeLibPath, NULL);
    char ourNativeLibraryPath[256];
    snprintf(ourNativeLibraryPath, sizeof (ourNativeLibraryPath), "%s%s", nativePathPassedIn, "/libffmpeg_wraper_jni.so"); //the name of your ffmpeg library

    //Open the so library
    void *handle;
    typedef int (*func)(JNIEnv*, jobject, jobjectArray);
    handle = dlopen(ourNativeLibraryPath, RTLD_LAZY);
    if (handle == NULL) {
        __android_log_print(ANDROID_LOG_VERBOSE, APPNAME, "could not open library: %s", dlerror());
        printf("Could not dlopen(\"libbar.so\"): %s\n", dlerror());
        return(-1);
    }

    //Call the ffmpeg wrapper functon in the second or 'inner' library
    func reenterable_ffmpegWrapperFunction;
    reenterable_ffmpegWrapperFunction = (func)dlsym(handle, "Java_com_yourpackage_androidffmpegwrapper_FfmpegJNIWrapper_ffmpegWrapper");
    reenterable_ffmpegWrapperFunction(pEnv, pObj, javaArgv); //the original arguments

    //Close the library
    dlclose(handle);

    // return
    return(1);
}
  • The Android.mk file is a little 'flaky' to put it politely. Because you are building two separate libraries in one Android.mk file, this may be a little more complex that other NDK make files so if you get some strange errors do some searching before you start taking your project apart. For example: https://stackoverflow.com/a/6243727/334402
Community
  • 1
  • 1
Mick
  • 24,231
  • 1
  • 54
  • 120