[mono-android] Help with .so and java source

[Jonathan Pryor]

On Feb 17, 2012, at 11:41 AM, Goncalo Oliveira wrote:
> So, here's what I did
> 
> 1. Added the .so library to the project under /NativeLibraries/armeabi/libsdk.so
> 2. Set the library's build action to AndroidNativeLibrary
> 3. Added the java source file under /JavaSources/libmsg.java
> 4. Set the file's build action to AndroidJavaSource

Sanity check: unzip the apk and make sure that lib/armeabi/libsdk.so is inside the .apk.

> I compile the whole thing, deploy to device and start debugging. When I click the button that calls the LibAPI.HasStarted() I get an Java.Lang.UnsatisfiedLinkError.

Can you provide the full stack trace for the UnsatisfiedLinkError?

I can think of three different reasons for the UnsatisfiedLinkError:

1. The native library is compiled for an architecture that your device doesn't support. For example, if the .so is an armeabi-v7a library and you try to load it on an armeabi device, this can fail. I don't think this is the case here, but it's otherwise possible.

2. The com.alk.sdk.AlkMsg type doesn't have a static constructor which calls System.loadLibrary("sdk"), and instead requires that "external" code call System.loadLibrary(). If this is the case, then you should add a call to Java.Lang.JavaSystem.LoadLibrary("sdk") during your startup code, sometime before you call AlkMsg.Msg_HasStarted().

3. The native library has been improperly linked, and dlopen() refuses to load the library. This requires NDK tools to validate.

I would hope that (2) is the problem, and that the JavaSystem.LoadLibrary() call would fix it.

If (2) doesn't fix it, you could try using the C API that they provide via P/Invoke and [DllImport]. This would still fail if the problem is due to (3).

Using a P/Invoke interface would also allow skipping the Java class and JNIEnv use, so it may be preferable, but without knowing _why_ the UnsatisfiedLinkError is being thrown, it's difficult to know what the actual reason is.

Thanks,
- Jon