9

i'm trying to add some lib (.jar & .so)to my multidex project in android studio.

when i add only a few jars to the project everything works fine. in case i add more and more jars (other libs) i'm getting this error:

java.lang.UnsatisfiedLinkError:
  dalvik.system.PathClassLoader[DexPathList[[zip file
  "/data/app/com.test.digital.ocrtest-2/base.apk"],nativeLibraryDirectories=[/data/app/com.test.digital.ocrtest-2/lib/arm,
  /data/app/com.test.digital.ocrtest-2/base.apk!/lib/armeabi-v7a,
  /vendor/lib, /system/lib]]] couldn't find
  "libScanovatePassportAndIDLSDK_CPP.so"

any idea how can I tell to the compiler to generate jar and so in same dex?

fredmaggiowski
  • 2,232
  • 3
  • 25
  • 44
Nimrod Borochov
  • 356
  • 3
  • 17
  • No, .so doesn't go into dex. But do check if the .so was packed into your APK. You can use `unzip -l` to list the contents of an APK file. – Alex Cohn Nov 30 '15 at 17:17
  • yes, it was packed in my APK. – Nimrod Borochov Dec 01 '15 at 12:33
  • What's the total size of your APK when it stops working? Which device is this? – Alex Cohn Dec 01 '15 at 14:27
  • update: it's work if i add the .so file to other 3 folders in jniLibs . now i have .so file in 4 folders in my project (armeabi, mips, armeabi-v7 and x86). the size of the .so is 14MB and 4 times is a lot . – Nimrod Borochov Dec 06 '15 at 07:36
  • 1
    so probably the root cause was not multidex and not the size, but maybe one of the extra JARs brought a native library for **armeabi-v7a**, while your **libScanovatePassportAndIDLSDK_CPP.so** was only built for **armeabi**. The fix then is not to add more copies of **.so**, but rather strip away the other ABIs. In gradle, you can [use **splits**](http://stackoverflow.com/a/33928159/192373) – Alex Cohn Dec 06 '15 at 08:08
  • i will try it. ty sir – Nimrod Borochov Dec 08 '15 at 13:49
  • Possible duplicate of [System.loadLibrary(...) couldn't find native library in my case](https://stackoverflow.com/questions/27421134/system-loadlibrary-couldnt-find-native-library-in-my-case) – tir38 Jun 11 '19 at 20:20

2 Answers2

7

If some of the extra JARs bring native libraries for armeabi-v7a, while your libScanovatePassportAndIDLSDK_CPP.so was only built for armeabi, the installer will extract a wrong set of libraries. The fix is not to add more copies of .so, but rather strip away the other ABIs. In gradle, you can use splits.

matdev
  • 4,115
  • 6
  • 35
  • 56
Alex Cohn
  • 56,089
  • 9
  • 113
  • 307
2

There is an elegant solution for this. When your APK file doesn't contain all native libs in 64bit version for a certain ABI you just need to make sure that your APK file does not contain any 64bit libs. Here is the tutorial on how to configure your project to fix this: https://corbt.com/posts/2015/09/18/mixing-32-and-64bit-dependencies-in-android.html

Background When your app is installed on 64bit ABI devices, package manager scans the APK file on install and looks for 64bit native libraries. If it finds the appropriate 64bit native library folder (you can check /libs folder in your APK file if you open it with any zip client) it assumes that all native libraries are available in 64bit versions. If one or more native libraries are not available in 64bit version, the package manager will fail to load their 32bit version. Hence, when the app attempts to run code that relies on these native librairies you will get this UnsatisfiedLinkError message. This means that the 32bit version of your library

Simon-Droid
  • 409
  • 2
  • 7
  • While this turned out to be my problem, don't think it applies to OP. For me the dead giveaway was that the error shows system was only looking in 64 directories `java.lang.UnsatisfiedLinkError: ...nativeLibraryDirectories=[/data/app/com.example.debug-1/lib/arm64, /system/lib64, /vendor/lib64]]] couldn't find "mylib_jni.so"` – tir38 Jun 11 '19 at 20:17