Fatal Exception: java.lang.UnsatisfiedLinkError: couldn't find DSO to load: libimagepipeline.so

[facebook]

Fatal Exception: java.lang.UnsatisfiedLinkError: couldn't find DSO to load: libimagepipeline.so

[panpanini]

@zetbrush could you tell me which version of the Android Gradle Plugin you were using?
Recently we ran into a similar issue when updating from AGP 3.2.0 to 3.4.0. I found that using either AGP 3.3.0 or 3.4.0 would cause this crash, however 3.2.0 would successfully find the .so file

[passy]

Have you checked which architecture the bundled .so actually is?

[zetbrush]

@passy its under lib/armeabi-v7a/libimagepipeline.so
ELF 32-bit LSB shared object ARM, EABI5 version 1 (SYSV)

[passy]

So the device is 32bit and the library is 32bit, too, but you get an error that it should be 64bit? Am I getting this right?

[zetbrush]

@passy not sure about the OS, but devices have Cortex-A53 cpus, with support for both AArch32 and AArch64

[karthickmurugesa]

Same issue I am also facing
com.facebook.soloader.SoLoader.doLoadLibraryBySoName
SoLoader.java, line 703
java.lang.UnsatisfiedLinkError: couldn't find DSO to load: libimagepipeline.so caused by: dlopen failed: "/data/data/org.deelchat/lib-main/libimagepipeline.so" is 64-bit instead of 32-bit
Open

For android gradle plugin 3.3.1 not working if i am downgraded to 3.2.0 its working .Please Facebook fix this issue ASAP. Don't lose the stability of the lib.

[artemisia]

I think I found why this bug happened, because the cpu_abi of /data/data/yourpackage/lib and /data/data/yourpackage/lib-main is different.
And why is it different? because ExtractFromZipSoSource.ensureDsos() had a defect.
What defect? There was an assumption that Android OS think you were a 64-bit app when you had both 32-bit and 64-bit so libraries. But, the rule was broken on the OPPO R7sm (Android 5.1.1 ColorOS: V3.0_170510_beta).

I have fixed the bug on my OPPO by modifying code, I will make a pull request later, expecting to help your guys.

[zetbrush]

@panpanini sorry for late response it was 3.3.1 back then

[waseefakhtar]

@artemisia this sounds good! Have you opened a PR for it yet? If not, I'd love to have a look at your modified code.

[waseefakhtar]

Regarding the Android Gradle Plugin, we've been using 3.3.2 but noticed the UnsatisfiedLinkError only when we started supporting 64-bit. Also, our error is:

"/data/data/com.degoo.android/lib-main/libnative-imagetranscoder.so" is 64-bit instead of 32-bit

and not:

"/mnt/expand/7c0f06c2-1644-460f-8533-efe2fb639ade/user/0/com.studio/lib-main/libimagepipeline.so" is 32-bit instead of 64-bit

[sp00ne]

Any update on this? We have crashes in our production app currently

[zetbrush]

@oprisnik can you update here pls? any news for fix? we are using latest soloader 0.8.0 version and still getting a lot of crashes
Fatal Exception: java.lang.UnsatisfiedLinkError: couldn't find DSO to load: libimagepipeline.so at com.facebook.soloader.SoLoader.doLoadLibraryBySoName(SoLoader.java:789) at com.facebook.soloader.SoLoader.loadLibraryBySoName(SoLoader.java:639) at com.facebook.soloader.SoLoader.loadLibrary(SoLoader.java:577) at com.facebook.soloader.SoLoader.loadLibrary(SoLoader.java:525) at com.facebook.imagepipeline.nativecode.ImagePipelineNativeLoader.load(ImagePipelineNativeLoader.java:40) at com.facebook.imagepipeline.memory.NativeMemoryChunk.<clinit>(NativeMemoryChunk.java:31) at com.facebook.imagepipeline.memory.NativeMemoryChunkPool.alloc(NativeMemoryChunkPool.java:25) at com.facebook.imagepipeline.memory.NativeMemoryChunkPool.alloc(NativeMemoryChunkPool.java:13) at com.facebook.imagepipeline.memory.BasePool.get(BasePool.java:266) at com.facebook.imagepipeline.memory.MemoryPooledByteBufferOutputStream.<init>(MemoryPooledByteBufferOutputStream.java:51) at com.facebook.imagepipeline.memory.MemoryPooledByteBufferFactory.newOutputStream(MemoryPooledByteBufferFactory.java:106) at com.facebook.imagepipeline.memory.MemoryPooledByteBufferFactory.newOutputStream(MemoryPooledByteBufferFactory.java:24) at com.facebook.imagepipeline.producers.NetworkFetchProducer.onResponse(NetworkFetchProducer.java:96) at com.facebook.imagepipeline.producers.NetworkFetchProducer$1.onResponse(NetworkFetchProducer.java:73) at com.picsart.studio.fresco.backends.OkHttpNetworkFetcher$2.onResponse(OkHttpNetworkFetcher.java:147) at com.google.firebase.perf.network.zzf.onResponse(zzf.java:22) at okhttp3.RealCall$AsyncCall.execute(RealCall.java:174) at okhttp3.internal.NamedRunnable.run(NamedRunnable.java:32) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1113) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:588) at java.lang.Thread.run(Thread.java:818)

https://i.ibb.co/56yWJky/Screen-Shot-2019-10-30-at-9-17-57-PM.png

[nanchen2251]

I think I found why this bug happened, because the cpu_abi of /data/data/yourpackage/lib and /data/data/yourpackage/lib-main is different.
And why is it different? because ExtractFromZipSoSource.ensureDsos() had a defect.
What defect? There was an assumption that Android OS think you were a 64-bit app when you had both 32-bit and 64-bit so libraries. But, the rule was broken on the OPPO R7sm (Android 5.1.1 ColorOS: V3.0_170510_beta).

I have fixed the bug on my OPPO by modifying code, I will make a pull request later, expecting to help your guys.

We encountered the same problem on OPPO phones, how did you solve it

[haliquim]

I ran into the same issue and resolved it by disabling the backup library sources. The generated APK has the proper libraries in the $appPath/lib folder, and libraries with the incorrect source in $appPath/lib-main. The lib-main sources are configured as a backup source, but are tried before the sources in the lib folder.

You can change this behavior with the initialization flags, and disabling the backup sources resolved the issue:

SoLoader.init(application,
    SoLoader.SOLOADER_DISABLE_BACKUP_SOSOURCE & // DISABLE BACKUP SOURCES
   (~SoLoader.SOLOADER_ENABLE_EXOPACKAGE)); // DISABLE EXOPACKAGE

[qasimgit]

@here
We are using 0.9.0+ version still getting alot of crashes, any update on this?
SoLoader Version: 0.9.0+
React Native Version: 0.66
would appreciate any help on this
Thanks
below is the screen shot of crash logs

[shawnsmsu]

It sounds like this issue was resolved with the v0.10.3 release based on the release notes. However, I'm still getting crash reports in production for it since upgrading. I did notice though that I only had
configurations.all { resolutionStrategy { force "com.facebook.soloader:soloader:0.10.3" } }
in build.gradle and did not have
dependencies { implementation "com.facebook.soloader:soloader:0.10.3+"
in app/build.gradle. Not sure if that's an issue so I've since shipped that. Anyone confirm or deny 10.3 resolving the issue for them?