To root cause (and maybe solve your issue in the same time), here is what you can do:
-
Remove the jni folder and all the .mk files. You don’t need these nor the NDK if you aren’t compiling anything.
-
Copy your
libcalculate.so
file inside<project>/libs/(armeabi|armeabi-v7a|x86|...)
. When using Android Studio, it’s<project>/app/src/main/jniLibs/(armeabi|armeabi-v7a|x86|...)
, but I see you’re using eclipse. -
Build your APK and open it as a zip file, to check that your
libcalculate.so
file is inside lib/(armeabi|armeabi-v7a|x86|…). -
Remove and install your application
-
Run dumpsys package packages | grep yourpackagename to get the nativeLibraryPath or legacyNativeLibraryDir of your application.
-
Run ls on the nativeLibraryPath you had or on legacyNativeLibraryDir/armeabi, to check if your libcalculate.so is indeed there.
-
If it’s there, check if it hasn’t been altered from your original libcalculate.so file: is it compiled against the right architecture, does it contain the expected symbols, are there any missing dependencies. You can analyze libcalculate.so using readelf.
In order to check step 5-7, you can use my application instead of command lines and readelf: Native Libs Monitor
PS: It’s easy to get confused on where .so files should be put or generated by default, here is a summary:
-
libs/CPU_ABI inside an eclipse project
-
jniLibs/CPU_ABI inside an Android Studio project
-
jni/CPU_ABI inside an AAR
-
lib/CPU_ABI inside the final APK
-
inside the app’s nativeLibraryPath on a <5.0 device, and inside the app’s legacyNativeLibraryDir/CPU_ARCH on a >=5.0 device.
Where CPU_ABI is any of: armeabi, armeabi-v7a, arm64-v8a, x86, x86_64, mips, mips64. Depending on which architectures you’re targeting and your libs have been compiled for.
Note also that libs aren’t mixed between CPU_ABI directories: you need the full set of what you’re using, a lib that is inside the armeabi folder will not be installed on a armeabi-v7a device if there are any libs inside the armeabi-v7a folder from the APK.