Android NDK UnsatisfiedLinkError when calling a native function that resides in an Android Library Project

Question

I built an android app that used the android NDK to make a shared native library (.so) to compute sha1's and it worked just fine when it was in one self contained project. Recently though I made that project into an Android Shared Project and kept the jni code there.. I then made a new project which references the shared project and the project seems to work correctly except that I get an UnsatisfiedLinkError when calling the native function. The native function gets called from within a Java Class named Hash. Inside this class there are some native functions that make calls to compute a sha1 hash for a file.

The ndk/jni code is getting compiled and it does get into application's APK, however I continue to get that error. I've uninstalled the app on my phone, done an ndk-build clean to make sure its not getting old references.. Etc and no luck. I've also made sure that the names of my jni functions match the

So here is the gist of my code:

Hash.java

package com.mydomain.sdk.util.Hash

public class Hash {
    static {
      System.loadLibrary("native_sha1")
    }

    public static native String getFileHashNative(String fileName);

}

Then I have (in the same project

jni/Android.mk

LOCAL_PATH := $(call my-dir)
include $(CLEAR_VARS)
LOCAL_LDLIBS := -llog
LOCAL_MODULE    := native_sha1
LOCAL_SRC_FILES := sha1.c sha1_native.c
include $(BUILD_SHARED_LIBRARY)

jni/sha1_native.c

jstring Java_com_mydomain_sdk_util_Hash_getFileHashNative(JNIEnv * env, jclass this, jstring fileName)
{
  //call function from sha1.c to get sha1, return to user
}

Anyways, this all worked great until I changed the structure of my project so that I could reuse common code (putting this into the android library project). If I compile my app and open up the .apk file I can see a lib directory and within that there is armeabi/libnative_sha1.so file.. Thus, it definitely is in there its just not working.

Update - Some Debug Information

Ok so I added some debugging.. I took the loadLibrary out of a static block and put it in a function which I call before attempting to call Hash.getFileHashNative

12-15 12:34:13.143: D/Hash(31567): Attempting to load native_sha1 lib
12-15 12:34:13.153: D/dalvikvm(31567): Trying to load lib /data/data/com.mydomain/lib/libnative_sha1.so 0x4051e4f8
12-15 12:34:13.163: D/dalvikvm(31567): Added shared lib /data/data/com.mydomain/lib/libnative_sha1.so 0x4051e4f8

12-15 12:34:13.163: D/dalvikvm(31567): No JNI_OnLoad found in /data/data/com.mydomain/lib/libnative_sha1.so 0x4051e4f8, skipping init
12-15 12:34:13.163: W/dalvikvm(31567): No implementation found for native Lcom/mydomain/sdk/util/Hash;.getFileHashNative (Ljava/lang/String;)Ljava/lang/String;

I'm not sure what is causing this but it appears it can't find the function obviously.. The only thing I'm modifying is the name of mydomain, everything else is exact.. Also note that my library project has the package name of com.mydomain.sdk and my application project is just com.mydomain The source code for the sha1 resides in the library project under com.mydomain.sdk.util.Hash I don't get what is going on here. Any ideas?

Answer 1

Alright I hate to answer another of my own questions but after many hours struggling with this one I think I've finally figured it out. In the manifest of my application I needed to set the

AndroidManifest.xml

 <uses-library android:name="com.mydomain.sdk" android:required="true" />

It's weird because in most the documentation I read online they don't mention using this and I thought it just had to do with something the marketplace used to resolve dependencies between applications (as opposed to dependencies for a library). Also I find it odd that the project compiled and ran at all without at least giving a warning when I did not have that in there.

-- Update - January 2014 --

This no longer is needed for the app to compile and run. If you are using relatively new (within about 1.5 years) Android build tools you shouldn't need this at all. I haven't had this issue in well over a year.