Repository navigation
SoLoaderDSONotFoundError: couldn't find DSO to load: libreactnative.so #55562
Description
Description
continuation of #49111 which was closed without resolution, even though many others have the same issue.
it looks like it's only Play Store test emulators that are crashing (pixel 6/6pro/7/7a, nexus,...)
but perhaps it's also real users with real devices, not sure on that last one.
Steps to reproduce
- run app
React Native Version
0.81.1
Affected Platforms
Runtime - Android
Output of npx @react-native-community/cli info
System:
OS: macOS 26.2
CPU: (10) arm64 Apple M1 Pro
Memory: 262.11 MB / 16.00 GB
Shell:
version: "5.9"
path: /bin/zsh
Binaries:
Node:
version: 22.17.0
path: /usr/local/bin/node
Yarn:
version: 4.10.3
path: /usr/local/bin/yarn
npm:
version: 10.9.2
path: /usr/local/bin/npm
Watchman:
version: 2026.01.05.00
path: /opt/homebrew/bin/watchman
Managers:
CocoaPods:
version: 1.16.2
path: /opt/homebrew/bin/pod
SDKs:
iOS SDK:
Platforms:
- DriverKit 25.2
- iOS 26.2
- macOS 26.2
- tvOS 26.2
- visionOS 26.2
- watchOS 26.2
Android SDK: Not Found
IDEs:
Android Studio: 2025.2 AI-252.27397.103.2522.14617522
Xcode:
version: 26.2/17C52
path: /usr/bin/xcodebuild
Languages:
Java:
version: 17.0.17
path: /usr/bin/javac
Ruby:
version: 2.6.10
path: /usr/bin/ruby
npmPackages:
"@react-native-community/cli":
installed: 20.0.1
wanted: ^20.0.0
react:
installed: 19.1.0
wanted: 19.1.0
react-native:
installed: 0.81.1
wanted: ^0.81.1
react-native-macos: Not Found
npmGlobalPackages:
"*react-native*": Not Found
Android:
hermesEnabled: true
newArchEnabled: true
iOS:
hermesEnabled: true
newArchEnabled: true
Stacktrace or Logs
Fatal Exception: com.facebook.soloader.SoLoaderDSONotFoundError: couldn't find DSO to load: libreactnative.so
existing SO sources:
SoSource 0: ApplicationSoSource[DirectorySoSource[root = /data/app/~~XqhJ1EpBs99Ahf1FxVSQNw==/my.app-s-j3U1pjJ9NznSe6OnKJYQ==/lib/arm64 flags = 0]]
SoSource 1: DirectApkSoSource[root = [/data/app/~~XqhJ1EpBs99Ahf1FxVSQNw==/my.app-s-j3U1pjJ9NznSe6OnKJYQ==/base.apk!/lib/arm64-v8a]]
SoSource 2: DirectorySoSource[root = /system/lib64 flags = 2]
SoSource 3: DirectorySoSource[root = /vendor/lib64 flags = 2]
Native lib dir: /data/app/~~XqhJ1EpBs99Ahf1FxVSQNw==/my.app-s-j3U1pjJ9NznSe6OnKJYQ==/lib/arm64
at com.facebook.soloader.SoLoader.doLoadLibraryBySoName(SoLoader.java:1216)
at com.facebook.soloader.SoLoader.loadLibraryBySoNameImpl(SoLoader.java:1078)
at com.facebook.soloader.SoLoader.loadLibraryBySoName(SoLoader.java:943)
at com.facebook.soloader.SoLoader.loadLibraryOnAndroid(SoLoader.java:859)
at com.facebook.soloader.SoLoader.loadLibrary(SoLoader.java:842)
at com.facebook.soloader.SoLoader.loadLibrary(SoLoader.java:812)
at com.facebook.react.internal.featureflags.ReactNativeFeatureFlagsCxxInterop.<clinit>(ReactNativeFeatureFlagsCxxInterop.kt:28)
at com.facebook.react.internal.featureflags.ReactNativeFeatureFlagsCxxInterop.override(ReactNativeFeatureFlagsCxxInterop.kt)
at com.facebook.react.internal.featureflags.ReactNativeFeatureFlagsCxxAccessor.override(ReactNativeFeatureFlagsCxxAccessor.kt:615)
at com.facebook.react.internal.featureflags.ReactNativeFeatureFlags.override(ReactNativeFeatureFlags.kt:402)
at com.facebook.react.defaults.DefaultNewArchitectureEntryPoint.load(DefaultNewArchitectureEntryPoint.kt:97)
at com.facebook.react.defaults.DefaultNewArchitectureEntryPoint.load(DefaultNewArchitectureEntryPoint.kt:43)
at com.facebook.react.ReactNativeApplicationEntryPoint.loadReactNative(ReactNativeApplicationEntryPoint.java:31)
at my.app.MainApplication.onCreate(MainApplication.kt:36)
at android.app.Instrumentation.callApplicationOnCreate(Instrumentation.java:1211)
at android.app.ActivityThread.handleBindApplication(ActivityThread.java:6728)
at android.app.ActivityThread.access$1500(ActivityThread.java:247)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:2057)
at android.os.Handler.dispatchMessage(Handler.java:106)
at android.os.Looper.loopOnce(Looper.java:201)
at android.os.Looper.loop(Looper.java:288)
at android.app.ActivityThread.main(ActivityThread.java:7842)
at java.lang.reflect.Method.invoke(Method.java)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:548)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1003)
at de.robv.android.xp0sed.Xp0sedBridge.main(Xp0sedBridge.java:112)
MANDATORY Reproducer
I don't have a reproducer that I can share
Screenshots and Videos
No response
Activity
react-native-bot commentedon Feb 16, 2026
Warning
Unsupported version: It looks like your issue or the example you provided uses an unsupported version of React Native.
Due to the number of issues we receive, we're currently only accepting new issues against one of the supported versions. Please upgrade to latest and verify if the issue persists (alternatively, create a new project and repro the issue in it). If you cannot upgrade, please open your issue on StackOverflow to get further community support.
react-native-bot commentedon Feb 16, 2026
Warning
Missing reproducer: We could not detect a reproducible example in your issue report. Reproducers are mandatory and we can accept only one of those as a valid reproducer:
You can read more about about it on our website: How to report a bug.
react-native-bot commentedon Feb 16, 2026
Warning
Unsupported version: It looks like your issue or the example you provided uses an unsupported version of React Native.
Due to the number of issues we receive, we're currently only accepting new issues against one of the supported versions. Please upgrade to latest and verify if the issue persists (alternatively, create a new project and repro the issue in it). If you cannot upgrade, please open your issue on StackOverflow to get further community support.
FreTimmerman commentedon Feb 16, 2026
what does the bot mean, 0.81.1 is unsupported version??? the table it links even shows that it's still active.
[-]SoLoaderDSONotFoundError[/-][+]SoLoaderDSONotFoundError: couldn't find DSO to load: libreactnative.so[/+]muhammad-kumail commentedon Feb 18, 2026
Facing same issue in
Android OS : 12
Pixel 6 Pro
Firebase Crashlytics:
Fatal Exception: QJ0
couldn't find DSO to load: libreactnative.so existing SO sources: SoSource 0: ApplicationSoSource[DirectorySoSource[root = /data/app/~~NpA7rPxCsohhsCYwH5y8-w==/com.myapp-AgILHbfs8IIq5aLn_dm_qw==/lib/arm64 flags = 0]] SoSource 1: DirectApkSoSource[root = [/data/app/~~NpA7rPxCsohhsCYwH5y8-w==/com.myapp-AgILHbfs8IIq5aLn_dm_qw==/base.apk!/lib/arm64-v8a]] SoSource 2: DirectorySoSource[root = /system/lib64 flags = 2] SoSource 3: DirectorySoSource[root = /vendor/lib64 flags = 2] Native lib dir: /data/app/~~NpA7rPxCsohhsCYwH5y8-w==/com.myapp-AgILHbfs8IIq5aLn_dm_qw==/lib/arm64
vexenuch commentedon Feb 18, 2026
I’m dealing with the same issue.
RN: 0.81.5
Expo: 54.0.33
NewArchEnabled: true
I also received this crash from 4 devices via Crashlytics. These 4 crash reports affected 2 users. In all cases, the device was a Pixel 6 Pro running Android 12 (just like @muhammad-kumail, I also received this crash on a Pixel 6 Pro with Android 12).
Crashlytics report:
When I first received this crash report, I tried setting Expo’s
useLegacyPackaging: truein the config. As a result, it becametrueingradle.propertiesduring the build. After that, I compared the production builds of this version with the version where it wasfalseusing Android Studio, but I couldn’t see any difference. I still released it, and I received the same crash report 3 more times.At this point, I honestly don’t know what exactly I should do. What is the correct and effective solution for this?
I also saw someone using
useLegacyPackaging trueinbuild.gradleinstead ofgradle.properties. But how much would this increase the app’s storage size? And is this actually an effective solution? I’m concerned about both.For now, I’ve removed
useLegacyPackaging truefromgradle.propertiesand will continue like this until an effective solution for this crash is found.Nader-CS commentedon Feb 24, 2026
same issue
Fatal Exception: com.facebook.soloader.SoLoaderDSONotFoundError: couldn't find DSO to load: libreactnative.so
existing SO sources:
SoSource 0: ApplicationSoSource[DirectorySoSource[root = /data/app/~~Dk7m9pf26IMXaF1P9X2BGg==/com.fnb.ca.ths-AD-RrWB8HtIUeQo0ahsFbQ==/lib/arm64 flags = 0]]
SoSource 1: DirectApkSoSource[root = [/data/app/~~Dk7m9pf26IMXaF1P9X2BGg==/com.fnb.ca.ths-AD-RrWB8HtIUeQo0ahsFbQ==/base.apk!/lib/arm64-v8a]]
SoSource 2: DirectorySoSource[root = /system/lib64 flags = 2]
SoSource 3: DirectorySoSource[root = /vendor/lib64 flags = 2]
Native lib dir: /data/app/~~Dk7m9pf26IMXaF1P9X2BGg==/com.fnb.ca.ths-AD-RrWB8HtIUeQo0ahsFbQ==/lib/arm64
17 remaining items
hardik978 commentedon May 28, 2026
libreactnative.soMissing Crash on Android (SoLoaderDSONotFoundError)Issue Description
We are facing the same crash on Android devices:
The crash appears to be related to
SoLoaderfailing to locatelibreactnative.so.Affected Devices
This issue is occurring mostly on the following devices:
Stack Trace
Attached full stack trace:
[StackTrace.txt](https://github.com/user-attachments/files/28345898/StackTrace.txt)
Environment Information
React Native Version
Output of
npx @react-native-community/cli infoSystem: OS: macOS 26.2 CPU: (10) arm64 Apple M4 Memory: 148.80 MB / 16.00 GB Shell: version: "5.9" path: /bin/zsh Binaries: Node: version: 20.19.5 path: /usr/local/bin/node npm: version: 10.8.2 path: /usr/local/bin/npm Watchman: version: 2025.10.13.00 path: /opt/homebrew/bin/watchman Managers: CocoaPods: version: 1.16.2 path: /opt/homebrew/bin/pod SDKs: iOS SDK: Platforms: - DriverKit 25.4 - iOS 26.4 - macOS 26.4 - tvOS 26.4 - visionOS 26.4 - watchOS 26.4 Android SDK: Not Found IDEs: Android Studio: 2025.2 AI-252.27397.103.2522.14617522 Xcode: version: 26.4.1/17E202 path: /usr/bin/xcodebuild Languages: Java: version: 17.0.16 path: /usr/bin/javac Ruby: version: 2.6.10 path: /usr/bin/ruby npmPackages: "@react-native-community/cli": installed: 20.1.3 wanted: ^20.0.0 react: installed: 19.1.0 wanted: 19.1.0 react-native: installed: 0.81.5 wanted: 0.81.5 npmGlobalPackages: "*react-native*": Not Found Android: hermesEnabled: true newArchEnabled: true iOS: hermesEnabled: true newArchEnabled: trueAdditional Notes
Any insights or fixes regarding this issue would be greatly appreciated.
faisaljawad commentedon Jun 30, 2026
Facing same issue with Pixel 7 as well. Seems to be related to device-specific. Haven't seen this reported on any Samsung yet.
vexenuch commentedon Jul 6, 2026
After 6 months it's still happening on Google Pixel devices. Any updates? Please keep this issue warm.
abdullahbayram commentedon Jul 7, 2026
Any update?
maXXCZ1 commentedon Jul 22, 2026
@hardik978 are you sure, that these are real devices of real users? I am experiencing same issue (or similar) on these exact same devices.
Considering our user base is fairly small, this seems very suspicious. We use default gradle setup for RN Android with bare RN 0.81.5
rd273001 commentedon Jul 23, 2026
Also Pixel 7a... I got all these crash events occurring on Android 11 & 12 devices, which include these 4 models (OnePlus 8 Pro, Huawei HRY-LX1T, Google Pixel 6 Pro and Google Pixel 7a)
AF-appointhq commentedon Aug 27, 2026
I'm getting the same issue with react native 0.86.0. It's occurring on:
OnePlus 8 Pro - Android 11,
Huawei HRY-LX1T - Android 11,
Google Pixel 8 Pro - Android 14,
Google Pixel 7a - Android 12,
LGE Nexus 5X - Android 13
arvindyadav2 commentedon Aug 30, 2026
did anyone finds fix for this issue ?
Asharalikhan4 commentedon Aug 31, 2026
not yet.
arvindyadav2 commentedon Aug 31, 2026
ohh bhai fix mil gya
fahad86 commentedon Sep 1, 2026
adding the following codeto
android/app/build.gradle(along with the upgrade to react-native 0.87.X) seemed to solve the issue for me:christopherboisvert commentedon Sep 3, 2026
Hi everyone! I’ve done some research into this error, and it seems to be related to the CPU architecture.
According to the crash report, the affected device is using an ARM64 CPU. However, the logs show React Native looking for its native libraries under x86_64.
My current theory is that something is going wrong during the build/packaging process, where React Native’s native binaries are being generated or packaged for the wrong CPU architecture. As a result, the phone is trying to load a library that doesn’t match its architecture, which causes the crash.
I’m still investigating, but the ABI/architecture mismatch seems to be the most likely cause so far.
Could it be the way Google Play process the .aab we generate ?
vexenuch commentedon Sep 3, 2026
Just to add some more context: I’m still seeing this crash report in Firebase Crashlytics. It has been triggered around 10–15 times across 2–3 devices (all Google Pixel devices, as far as I’ve seen), so Crashlytics keeps sending alert emails for it.
However, when I check Android Vitals, ANRs, and crash metrics in the Google Play Console, everything looks completely normal and there doesn’t seem to be any issue reported there.
Given this, I’m not quite sure how to behave to this crash. Is this something we should actively investigate and try to fix, or could it be something like where Crashlytics reports something that looks like a crash even though there isn’t actually a user-facing issue?
Jack-Gill-TH commentedon Sep 10, 2026
We're seeing this same crash in production. Our data may help with a root cause.
Our setup:
React Native 0.81.5, Expo SDK 54, new architecture enabled.
@sentry/react-native 8.20.0, with useNativeInit: true in the Sentry Expo config plugin.
Sentry shows about 100 occurrences across 31 users over five weeks. Low frequency, not every launch on an affected device.
Confirmed device models: Pixel 6 Pro, Pixel 7 Pro, Pixel 8 Pro, OnePlus 8 Pro, Huawei HRY-LX1T.
A possible trigger we found:
The crash started the same release we enabled Sentry's native init (useNativeInit: true). That option makes the Sentry Expo config plugin add this line to MainApplication.onCreate, ahead of the call that loads React Native:
RNSentrySDK.init(this) is itself a SoLoader client. It loads Sentry's native libraries and builds SoLoader's list of "SO sources" before React Native gets a chance to. We think this may make the underlying packaging defect easier to hit, because SoLoader has already resolved its source list by the time loadReactNative() asks it for libreactnative.so.
We have not proven this causes the bug. It is a correlation: the crash's first release lines up with the commit that added this line. No other change in that release touches Android native startup. If your app calls any native SDK's init method early in onCreate, before loadReactNative(), that may be worth checking as a shared factor across reports in this thread.
The effects of the workaround:
We set useLegacyPackaging: true (via expo-build-properties, since we're on the Expo managed workflow).
The setting is correctly encoded in the built AAB (bundletool dump config shows uncompressNativeLibraries disabled).
On a physical device, native libraries are extracted to lib// at install time, not left inside a split APK
Size tradeoff, measured on a real device install (single-ABI, matching a Play Store delivery)
Download size: about 19% smaller with legacy packaging (native libs stay compressed).
On-device storage: about 11% larger with legacy packaging (native libs end up stored twice: compressed in the APK, and extracted as a second copy on disk).
We haven't been able to reproduce the issue, so we can't say that this has fixed it, but once this change goes into a release we'll monitor and report back here.
Happy to share more detail if it helps track this down.
Jack-Gill-TH commentedon Oct 13, 2026
Follow-up to my comment above, with four weeks of production data.
Setup: React Native 0.81.5, Expo SDK 54, new architecture, AAB via Google Play, four ABIs (
armeabi-v7a,arm64-v8a,x86,x86_64).Change:
useLegacyPackaging true, i.e.extractNativeLibs=true.Result: the crash stopped on Play Store installs. Unique affected users per release, split by whether Sentry attributes the install to a store (
isSideLoaded):Caveat - two pre-fix releases were also zero. Four consecutive releases at zero is suggestive, but not proof.
A detail that may help others verify their own build.
The error message prints SoLoader's source list, and that list tells you which packaging the binary actually used:
DirectApkSoSource[...]meansextractNativeLibs=false(the default).BackupSoSource[root = /data/data/<pkg>/lib-main ...]meansextractNativeLibs=true(legacy packaging).What the residual crashes look like.
After the change, every remaining event comes from an install that Play did not install (installer package is null) or from an x86_64 emulator. They all print:
Only
base.apk. With ABI splits enabled,base.apkcarries no native libraries at all; they live insplit_config.<abi>.apk.BackupSoSourcein SoLoader 0.12.1 does scansplitSourceDirs, but it only adds a split that containslib/<abi>/*.so, and none was present. So the library is genuinely absent from those installs.This points away from an ABI resolution bug. For our residual population the failure is a missing ABI config split, not SoLoader looking in the wrong architecture folder. That is consistent with installs produced by APK extraction, app cloning, phone-to-phone transfer tools, and emulators, and it possibly hints at why no one can produce a repro: the defect lives in the install, not in the app.
This also means I no longer believe my earlier hypothesis about Sentry's native init (
RNSentrySDK.initbeforeloadReactNative). The packaging evidence explains the crash better, and I have no evidence for the init-order theory.Mitigation for anyone who needs those installs to work: put the native libraries in
base.apk, withbundle { abi { enableSplit false } }. The cost is download size, because every user then receives every ABI you ship. We have not done this.Upstream state, for the record: SoLoader's newest published artifact is 0.12.1 (September 2024), and
0.82-stable,0.83-stableandmainall pinsoloader = "0.12.1". So upgrading React Native does not change this code path today. My assumption was that we would age out of the need for useLegacyPackaging, but it seems like there's no sign of it becoming deprecated/unusable.Happy to share the raw aggregates if they are useful.