Repository navigation
SoLoader 0.8.0 couldn't find DSO to load - issue on .apk build #55
Description
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)
Reacted by Rafał Wójcik, ziem, Iwo Polański, ProstoF, Maciej Witowski, Dima Portenko, Lasitha Ishan Petthawadu, Dan Lowe, Ngankt2, Slava and 17 more
Activity
[-]SoLoader 8.0 couldn't find DSO to load - apk build[/-][-]SoLoader 0.8.0 couldn't find DSO to load - apk build[/-]mars-lan commentedon Dec 26, 2019
Seeing a similar issue on 0.8.0 with a different stack trace.
Was able to reproduce this reliably by applying the following patch to the standard RN starter project on a stock "Google Play Intel x86 Atom System Image API 28 rev 9" emulator.
Also attached a a copy of the project to help debug.
BurntBrunch commentedon Jan 17, 2020
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.
mars-lan commentedon Jan 18, 2020
@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
xserxses commentedon Jan 20, 2020
Update: Downgrading to 0.6.1 didn't fix the problem. After releasing it to production we faced some crashes from Sony devices.
Xperia XZ 33%
Xperia X Compact 29%
Xperia X 17%
Xperia X Performance 14%
Xperia XA 5%
Xperia Z5 Compact 1%
Xperia Z5 1%
BurntBrunch commentedon Jan 21, 2020
Google are reporting that the image is actually correct because there's runtime dynamic code translation in that image.
I have some thoughts on how to fix all this but it's not trivial, especially because I don't know what SELinux will let me do. Stay tuned.
Filter out incompatible ABIs but do not reorder the list
mars-lan commentedon Jan 22, 2020
Thanks for the investigation, @BurntBrunch. Look forward to a new release that includes 20198bf
BurntBrunch commentedon Jan 22, 2020
@mars-lan this commit addressed the issue described, as it pertains to emulators. I don't think the other samples you saw are the same issue. I've added extended logging in the exception message for the WrongAbiError exceptions, hope that gives more clues.
mars-lan commentedon Jan 23, 2020
@BurntBrunch is dynamic code translation limited to only emulators?
BurntBrunch commentedon Jan 23, 2020
As far as I know, yes. x86 devices are very rare in the wild (they have libhoudini which does similar things on them) and all the devices you mentioned are definitely ARM.
mars-lan commentedon Jan 24, 2020
Got it. Let's see if the extra logging can reveal some other bugs then. Look forward to the new release soon.
oprisnik commentedon Jan 28, 2020
Version 0.8.1 has been released which includes this fix.
sintylapse commentedon Jan 30, 2020
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 of
couldn't find DSO to load: libhermes.so77 remaining items
DevVibhor commentedon Nov 23, 2022
I've solved this issue by doing this,
https://stackoverflow.com/a/74486848/20503822
98rahul commentedon Jan 3, 2023
couldn't find DSO to load: libhermes.so caused by: dlopen failed: library "libjsi.so" not found:
not solved by changing the above different soloader version mention .
Have anyone able to resolve this error.
unicornRainbows commentedon Jan 30, 2023
I also have the same issue..
98rahul commentedon Jan 30, 2023
better to move with latest version RN-0.71.1
and chill 🎉🎉
unicornRainbows commentedon Jan 30, 2023
I wish I could, but react-native-vision-camera doesn't support it yet..
miteshdb commentedon Mar 28, 2023
Having same problem.
React Native : 0.64.4
implementation 'com.facebook.soloader:soloader:0.9.0+'
malikzype commentedon May 24, 2023
Facing the same issue... none of the solutions worked.
Fatal Exception: java.lang.UnsatisfiedLinkError: couldn't find DSO to load: libhermes.so
SoSource 0: com.facebook.soloader.a[root = /data/data/...../lib-main flags = 1]
SoSource 1: com.facebook.soloader.d[root = /data/app/~~MPKzZHrXvYC8_UVhanEkkg==/......-3O2d9zcsgjcplUI6W_P4_A==/lib/arm64 flags = 0]
SoSource 2: com.facebook.soloader.d[root = /system/lib64 flags = 2]
SoSource 3: com.facebook.soloader.d[root = /vendor/lib64 flags = 2]
Native lib dir: /data/app/~~MPKzZHrXvYC8_UVhanEkkg==/....-3O2d9zcsgjcplUI6W_P4_A==/lib/arm64
RubenPM-dev commentedon Jul 25, 2023
I'm having the same issue on 71.7 on Android 9 to 12
shailesh-galgal commentedon Aug 31, 2023
Anyone’s got any solution?
RodolfoGS commentedon Sep 4, 2023
Issue continues with the latest soloader version (com.facebook.soloader:soloader: 0.10.5)
Devices impacted are 100% Google Nexus 5X
And all devices dispatch 2 crashes, one with libhermes.so and the other one with libreactnativejni.so
react-native: 0.72.4
I uncompressed the APK and both files exists in
lib/x86/:lib/x86/libhermes.so<-- existslib/x86/libreactnativejni.so<-- existscouldn't find DSO to load: libhermes.so
couldn't find DSO to load: libreactnativejni.so
rathorevaibhav commentedon May 14, 2024
hi. Is there any update on a possible solution for this? I'm building an app and seeing the same issue for Android 10 users.
Screenshot from Crashlytics
AnandKuhar1100 commentedon Jun 27, 2025
Any solution on this? Getting same issue -
In our case these crashes occur majorly on OnePlus devices having android version as 11.
Iram-sufiyan-313 commentedon Nov 5, 2025
I'm experiencing the same SoLoader crash on certain device architectures. Here's what worked for me:
Temporary Fix:
Downgrading to SoLoader 0.6.1 resolves the immediate crash:
implementation 'com.facebook.soloader:soloader:0.6.1'Proper Long-term Solution:
Updating to SoLoader 0.10.4+ addresses the underlying platform compatibility issue:
implementation 'com.facebook.soloader:soloader:0.10.4'This appears to be a known defect in SoLoader versions before 0.9.0 that causes UnsatisfiedLinkError and "APK was built for a different platform" errors when loading native libraries on incompatible architectures. The issue is specifically related to how SoLoader 0.8.0 handles DSO loading across different CPU architectures.
Summary: Downgrade to 0.6.1 for immediate relief, but upgrade to 0.10.4+ for the proper fix.
hardik-bm-ai commentedon Nov 24, 2025
I’m also experiencing the similar crash on SoLoader with React Native 0.80.1.
Sharing my app configuration + affected devices + the full Crashlytics stacktrace.
com.facebook.soloader.b0: couldn't find DSO to load: libreactnative.soFull Crashlytics stacktrace (file)
React Native & Build Environment
React Native: 0.80.1
newArchEnabled: true
hermesEnabled: true
Packaging: universal APK
ABI Filters:
abiFilters "armeabi-v7a", "arm64-v8a"Build system: Android Studio (assemble release)
SoLoader: default version from RN (not overridden)
libreactnative.so: confirmed present inside the APK
Custom SoLoader logic: none
Reproducible locally: no (not reproducible on QA devices, BrowserStack, or LambdaTest)
Gradle & AGP
Android Gradle Plugin: 8.13.0
Gradle: 8.14.1
Devices observed (via Crashlytics)
Pixel 6 Pro → Android 12
OnePlus 8 Pro → Android 11
Samsung Galaxy A55 5G → Android 10
This seems to match the pattern other developers in this thread reported — only happening on specific ARM64 devices, even though the correct ABI is shipped.
Notes
su0329 commentedon Jan 16, 2026
I am not sure this would help. We also seeing the same crash report from Nexus 5X Android 13, but could not reproduce it with same simulator Model and Android API version. https://support.google.com/faqs/answer/12576726?hl=en
Fatal Exception: com.facebook.soloader.SoLoaderULError
java.lang.UnsatisfiedLinkError: dlopen failed: "/data/data/com.apodapp/lib-main/libc++_shared.so" is for EM_AARCH64 (183) instead of EM_X86_64 (62)
Caused by java.lang.UnsatisfiedLinkError
dlopen failed: "/data/data/com.apodapp/lib-main/libc++_shared.so" is for EM_AARCH64 (183) instead of EM_X86_64 (62)