CODEWITHSUNDEEP
androidckotlinjava-native-interface
bukka.wh
bukka.wh

Reputation: 913

Android native library (.so) - unsatisfied link error

I have recently created and published an Android App bundle with compiled native libraries for all processors architectures. On most of devices everything is running ok. But on some of devices I can see this error in Crashlytics console Fatal Exception: java.lang.UnsatisfiedLinkError dalvik.system.PathClassLoader[DexPathList[[zip file "/system/framework/org.apache.http.legacy.boot.jar", zip file "/data/app/com.someapp-wAu5DoLmLvM_RVnbU1qsCg==/base.apk"],nativeLibraryDirectories=[/data/app/com.someapp-wAu5DoLmLvM_RVnbU1qsCg==/lib/arm64, /system/lib64]]] couldn't find "somemylib.so"

I am wondering - why this may happen. I have libs for x64 processors. This is happening only on some devices - but this crash is the most often in Crashlytics. All my libs are stored inside jniLibs directory THese are some pieces from my build.gradle

bundle {
    density {
        // Different APKs are generated for devices with different screen densities; true by default.
        enableSplit false
    }
    abi {
        // Different APKs are generated for devices with different CPU architectures; true by default.
        enableSplit true
    }
    language {
        // This is disabled so that the App Bundle does NOT split the APK for each language.
        // We're gonna use the same APK for all languages.
        enableSplit false
    }
}
splits {
    abi {
        enable true
        reset()
        include 'armeabi', 'mips', 'x86', 'armeabi-v7a', 'arm64-v8a', 
 'mips64', 'x86_64'
    }
}
sourceSets {

    main {
        jniLibs.srcDirs = ['jniLibs']
    }
}

I have a service class inside my app which is trying to load native library when someone is starting it. My be sometimes this "start" call to service is executing before the OS can detect the native libs in my app? But I don't think that this is so. Can you help me please

Upvotes: 1

Views: 4253

Answers (2)

shubhamgarg1
shubhamgarg1

Reputation: 2005

This issue might be related to https://issuetracker.google.com/issues/127691101

It happens on some devices of LG or old Samsung devices where the user has moved the app to the SD Card.

One way of fixing the issue is to use Relinker library to load your native libraries instead of directly calling System.load method.

https://github.com/KeepSafe/ReLinker

Another way is to block the movement of the app to the SD card.

You can also keep android.bundle.enableUncompressedNativeLibs=false in your gradle.properties file. But it will increase the app download size on Play Store as well as its disk size.

Upvotes: 0

Daniel Zolnai
Daniel Zolnai

Reputation: 16910

Your problem is not with the library code, but with the .so files themselves. Android devices have a primary ABI, the instruction set supported by the processor. For example, some devices with 64-bit processors use the ABI arm64-v8a.

However, a lot of libraries and apps don't support 64-bit processors yet. So usually, the newer processors also support a secondary ABI, which is a more common one. arm64-v8a processors usually support armeabi-v7a too, for example.

When the app starts, it starts looking for the native libraries in the directories. First it checks in the primary ABI directory, arm64-v8a in this example. If the .so files are not there, it checks in the secondary ABI directory (armeabi-v7a). If still not found, you will get the error you described.

In your case, you have the files, as you said, so that's not the problem.

One big problem with this selection is, that it always sticks to the primary ABI, if the directory exists. This can lead to crashes if not all libraries supply all .so files for all ABIs. This is described here.

Here's an example: you include 2 libraries in your app: 1. VideoPlayerLibrary, which has .so files for all ABIs 2. GifLibrary, which has .so files only for armeabi and armeabi-v7a.

Now if you start the app on an arm64-v8a device, it will stick to it's primary ABI, because it has found files there (the .so files of VideoPlayerLibrary). But at the moment you want to play gifs, it will try to load the .so files from the arm64-v8a directory, but it will not find them there and it will crash as in your post with a link error.

So what can you do?

You have 2 options:

  1. If it is your own library which has the missing .so files, compile it for all ABIs. If it is not your own, check if there's a newer version which has fixed this issue.
  2. Exclude the incomplete ABIs from the app. This way the newer processors will use the secondary ABI for running the app. This will result in worse performance of course, but it will not crash. From my experience, the most important ABI is armeabi-v7a, this should be supported by probably all Android devices.

Upvotes: 9

Related Questions