SoLoader: SoLoader 0.8.0 couldn't find DSO to load - issue on .apk build
MyApp is crashing while performing tests on Firebase Test lab emulators (x86). Downgrading to 0.6.1 is fixing the problem.
java.lang.UnsatisfiedLinkError: couldn't find DSO to load: libyoga.so caused by: APK was built for a different platform
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.yoga.YogaNative.<clinit>(YogaNative.java:15)
at com.facebook.yoga.YogaConfig.<init>(YogaConfig.java:20)
at com.facebook.yoga.YogaConfigFactory.create(YogaConfigFactory.java:5)
at com.facebook.litho.yoga.LithoYogaFactory.createYogaConfig(LithoYogaFactory.java:26)
at com.facebook.litho.NodeConfig.<clinit>(NodeConfig.java:45)
About this issue
- Original URL
- State: open
- Created 4 years ago
- Reactions: 27
- Comments: 93 (12 by maintainers)
Commits related to this issue
- Filter out incompatible ABIs but do not reorder the list Summary: This logic is supposed to filter out absolutely incompatible ABIs from the list given by `Build.SUPPORTED_ABIS`. This is particularly... — committed to facebook/SoLoader by BurntBrunch 4 years ago
- fix: bump soloader version to fix java.lang.UnsatisfiedLinkError See: https://github.com/facebook/SoLoader/issues/55 — committed to bacarybruno/kebetoo-mobile by bacarybruno 3 years ago
- fix: bump soloader version to fix java.lang.UnsatisfiedLinkError See: https://github.com/facebook/SoLoader/issues/55 — committed to bacarybruno/kebetoo-mobile by bacarybruno 3 years ago
What fixed it for us what upgrading the SOLoader.
In android/app/build.gradle:
go to the android directory and run dis command “./gradle clean” its work for me
cd android && ./gradlew clean
This is worked for me
Version 0.8.1 has been released which includes this fix.
Still an issue for me with version 0.8.1, only error message a little bit changed in crashlitics
couldn't find DSO to load: libhermes.so result: 0instead ofcouldn't find DSO to load: libhermes.soHave the same issue with React Native 0.61.5 and SoLoader 0.8.0 Device: Galaxy J2 Prime ,Redmi Note 4, HUAWEI Y3II
same here on upgrade react-native to 62.2
i am still facing the same problem, issue is not resolved. i am using
soloader:0.10.3Another one from me, but this time I have updated SoLoader to the latest version (0.10.1).
Version:
Device: Pixel 3 XL (Android 9)
Log:
@soroushm Thanks. Is it
./gradlew clean? —> This command fixed the issue on my side…Hi @BurntBrunch, this is another one to help you with the debugging.
Version:
implementation 'com.facebook.soloader:soloader:0.9.0+'Distribution: Android App Bundle (AAB)
Device: Galaxy S5 (Android 5.1.1)
Log:
Still seeing similar issue with SoLoader 0.8.2 with the following (not very helpful) error message. @BurntBrunch any update?
@BurntBrunch thanks for looking into this. Actually it seems that the “brokenness” affects real devices as well. Seeing similar crashes in production on these devices running Android 6-9
Nexus 6 Xiaomi Mi 9X, Redmi Pro, Mi 5 Trend TaintArt for x86 X9 (Maybe Vivo X9?) Vivo s1 Huawei Enjoy 9s Others (Samsung, Asus, LGE, Google, Lenovo)
Unfortunately the stack trace from Firebase is limited
Definitely seeing fewer crashes with 0.9.0 but still not zero. Good news is that it’s giving more logs now. Below is an example for Nexus 6. Looks like it’s still trying to load from an incorrect location.
Hi, sorry about the delay! I’ve investigated this a bit and I am reasonably convinced that particular emulator image (Pie SDK 28 Google APIs x86) is just broken.
The Google APIs version is reporting both x86 and armv7 compatibility when the non-Google version correctly only reports x86. As a workaround, can you try using an SDK 29 (Q) Google APIs image? In my testing, that image should behave better.
I’ve also posted this on the Android bug tracker here.
@saczuac does this fix it for you? It did for me:
Changed the version to
0.10.1solve the issue at my end. implementation ‘com.facebook.soloader:soloader:0.10.1+’@simpleton as @thanakij I am having this issue only on android 11 I was facing the issue yesterday and Crashlytics was reporting this crash with the following logs:
I am using
implementation "com.facebook.soloader:soloader:0.10.3+"However when i opened the run logs in android studio i saw the following error after the app crashes
this error is actually caused by
implementation 'com.squareup.okhttp3:okhttp:4.9.2'so what i added i have addedin
android/app/build.gradlethen i cleaned the build folder and reinstall the app again and it is working without any crash even no more reported crashes in firebase
CrashlyticsHonestly I have no idea how the
Crashlyticsis reporting fatal error related tosoloaderwhile the issue was caused byokhttpDid not help for me.
Me too.
I’m using soloader 0.9.0+ and it happened since the update to 0.63.2.
It happened on devices with Android 10 and 11. Don’t know why tho.
Any luck for the issue? Have tried multiple solutions but still facing it. The same issue is causing number of crashes in production app. “react-native”: “0.63.0” implementation ‘com.facebook.soloader:soloader:0.9.0+’
Some more data from me
Setup:
“react-native”: “0.63.0” implementation ‘com.facebook.soloader:soloader:0.9.0+’ enableHermes: false Distribution: Android App Bundle (AAB)
Happening to me as well on production on version 0.8.1 of SoLoader. Xperia X Performance - Android 8.0.0
Same
0.66, make sure remove the plus on suffix implementation ‘com.facebook.soloader:soloader:0.10.1+’ -> implementation ‘com.facebook.soloader:soloader:0.10.1’This works for me
We are also seeing similar crashes in Android 10 and 11 devices with RN version = 0.64 and Soloader = 0.8.2.
Is there any update on this bug? or anyone knows of a workaround?
We have upgraded soloader to 0.10.3 but somehow Crashlytics is still reporting this issue…
This time the report says the device is running Android 8.1.0 (Nexus 5X) at SoLoader.java line 1098.
I believe it is not a problem in the RN, but in how the android studio behaves in generating an apk
you can fix it, but I wouldn’t put much effort into it, since it’s a way the tool works
one of the alternatives and force the type of the build setting to ABI for the same architecture as RN
ABI - Application Binary Interface See https://developer.android.com/studio/build/configure-apk-splits
I’m a native android programmer, and this problem happens when compiling the app through Play from the android studio itself
Behind it, it generates an apk with ABI with simpler architecture for the OS
If you generate the APK via Build or via ADB, the APK architecture will be generated using the architecture defined by build.gradle or the standard architecture
In this case I want to make it clear, that there is a difference between creating apk via Play and via Build / ADB
if you using proguard try this rule’s worked for me -keep class com.facebook.soloader.{*;} -keep class com.facebook.yoga.{;} -keep class com.facebook.jni.**{;} -keep class com.facebook.fbjni.**{*;}
Hi @sn123, Please let me know if you found any solution to fix this app crash issue.
@tusharsarkar @nagasai65 what RN version are you guys on? facing same issue, soloader is
0.10.3+, and RN is0.66.00.10.3 should fix this issue
On Tue, Jan 11, 2022 at 9:34 PM Mayuresh Gharpure @.***> wrote:
(1) I cannot reproduce this myself.
(2) Because Crashlytics is saying the crash is for line 1098, this should just help confirm that I am using the latest v0.10.3.
I have pinned the version of SoLoader to be 0.10.3 in my
android/app/build.xml:(3) Anyway, my estimate is that around 0.08% of my Android users have experienced this crash.
From the pattern in my Crashlytics, trying to make sense out of it, it is likely that only some certain devices are affected.
It means that if this issue affects a user, she will just have a consistent early crash every time when she tries to open the app. But for most users, they wouldn’t run into this same issue.
Hi @simpleton, please see the log below:
me too having same issue with version 0.10.3 and Android 11
I had the issue on RN version 64.2 and what solved it for me was upgrading my
hermes-engineversion to0.7.0. Apparently there is strict version compatibility. Hope this saves someone the 4 hours I just wasted.@agrass I’m not sure if fix libv8executor.so too ¯\_(ツ)_/¯
Hello! this error still with the configuration SoLoader 0.9+ when using RN 59. Anyone already managed to fix this issue? Thanks
Same here:
Version:
Same issue here, with:
Setup:
“react-native”: “0.63.2” implementation ‘com.facebook.soloader:soloader:0.9.0+’ enableHermes: false Distribution: Android App Bundle (AAB)
Device: Nexus 5X (Android 6.0.1)
Log:
Fatal Exception: java.lang.UnsatisfiedLinkError: couldn’t find DSO to load: libhermes.so SoSource 0: com.facebook.soloader.ApkSoSource[root = /data/data/com.metropolis/lib-main flags = 1] SoSource 1: com.facebook.soloader.DirectorySoSource[root = /data/app/com.metropolis-1/lib/arm flags = 0] SoSource 2: com.facebook.soloader.DirectorySoSource[root = /system/vendor/lib flags = 2] SoSource 3: com.facebook.soloader.DirectorySoSource[root = /system/lib flags = 2] Native lib dir: /data/app/com.metropolis-1/lib/arm result: 0 at com.facebook.soloader.SoLoader.doLoadLibraryBySoName(SoLoader.java:896) at com.facebook.soloader.SoLoader.loadLibraryBySoNameImpl(SoLoader.java:725) at com.facebook.soloader.SoLoader.loadLibraryBySoName(SoLoader.java:649) at com.facebook.soloader.SoLoader.loadLibrary(SoLoader.java:629) at com.facebook.soloader.SoLoader.loadLibrary(SoLoader.java:577) at com.facebook.hermes.reactexecutor.HermesExecutor.<clinit>(HermesExecutor.java:20) at com.facebook.hermes.reactexecutor.HermesExecutorFactory.create(HermesExecutorFactory.java:29) at com.facebook.react.ReactInstanceManager$5.run(ReactInstanceManager.java:1017) at java.lang.Thread.run(Thread.java:818)
i managed to resolve this crash by releasing apk instead of aab for playstore.
version for the production app “react-native”: “0.61.5” force ‘com.facebook.soloader:soloader:0.9.0’
it should be an issue on how bundletool manage the native library with the aab package while install into devices through playstore.
去掉defaultConfig里面的 ndk 在外面加上以下代码: splits { abi { reset() enable enableSeparateBuildPerCPUArchitecture universalApk false // If true, also generate a universal APK include “armeabi-v7a”, “x86”, “arm64-v8a”, “x86_64” } }
亲测有效, 不知道为啥