AndroidRuntime Caused by: java.lang.unsatisfiedLinkError: Couldn't load tfp_jni: findLibrary returned null

Question

So, it looks like there are a lot of issues like mine out there but not sure any of them are related to my issue. OK. I have an Android project that uses an SDK as a refer

Answer 1

A number of things must occur for the linkage to work

1. The native library must be compiled to an .so file for the appropriate ABI(s) - this is typically accomplished via the ndk-build script/batch file, though it can also be done using a generated stand alone toolchain. IDE projects may want to configure running this as a custom build step.

2. The native library must get packaged in the application .apk. If it was built from a jni/ folder under an application project directory, then ndk-build probably copied it into an ABI-appropriate subdirectory of the libs/ folder of the project. However, if the native library belongs to a distinct Android library, extra steps may be required. In particular, a .so cannot be obtained by the build system from a library .jar and so one associated with library code must either by explicitly copied under the libs/ folder of the client project, or else found by referencing a library project directory tree (not a lonely .jar) which includes it.

3. The installer on the device must decide that one of the .so files contained in the .apk is appropriate for the device's ABI (architecture) and copy it out of the .apk into the install directory for use.

4. The runtime linkage names of the jni functions (downstream of any compiler name-mangling) must match those which the VM is looking for. Typically, problems here come up from not correctly encoding the java fully qualified class name in the native function name. The javah tool is intended to help avoid such mistakes, though with care it can be done manually.

Each of these steps presents a potential breakdown, so debugging an unsatisfied link can be approached by trying to find the first stage at which the .so file goes missing.