React-native: [ANDROID] SoLoader error using App Bundle

[vanydeasy]

🐛 Bug Report

Please help!
There are some crashes happening in android using app bundle but I am not sure how to reproduce it. It happens on our app with daily crash of 200 users.

Fatal Exception: java.lang.UnsatisfiedLinkError: couldn't find DSO to load: libreactnativejni.so
       at com.facebook.soloader.SoLoader.doLoadLibraryBySoName(SoLoader.java:738)
       at com.facebook.soloader.SoLoader.loadLibraryBySoName(SoLoader.java:591)
       at com.facebook.soloader.SoLoader.loadLibrary(SoLoader.java:529)
       at com.facebook.soloader.SoLoader.loadLibrary(SoLoader.java:484)
       at com.facebook.react.bridge.ReactBridge.staticInit(ReactBridge.java:30)
       at com.facebook.react.bridge.NativeMap.(NativeMap.java:19)
       at com.facebook.react.jscexecutor.JSCExecutorFactory.create(JSCExecutorFactory.java:25)
       at com.facebook.react.ReactInstanceManager$5.run(ReactInstanceManager.java:944)
       at java.lang.Thread.run(Thread.java:764)

The errors have multiple variations that occur on various android versions.

Fatal Exception: java.lang.UnsatisfiedLinkError
couldn't find DSO to load: libreactnativejni.so caused by: couldn't find DSO to load: libfb.so caused by: couldn't find DSO to load: libgnustl_shared.so caused by: dlopen failed: "/data/data/com.traveloka.android/lib-0/libgnustl_shared.so" is 64-bit instead of 32-bit

Fatal Exception: java.lang.UnsatisfiedLinkError
couldn't find DSO to load: libreactnativejni.so caused by: couldn't find DSO to load: libfb.so caused by: Dynamic section string-table not found



md5-d488a0b1a1c0af66be85bbfa0f21799b



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



md5-1e984d8b749e69002cade9b3e8f519be



android {
    ...
    defaultConfig {
       ...
        ndk {   
            abiFilters "armeabi-v7a", "x86", "arm64-v8a"
        }
    }
}



md5-8baa1e8468f49b17436211d7e9b01cd5



React Native Environment Info:
    System:
      OS: macOS 10.14
      CPU: x64 Intel(R) Core(TM) i7-7820HQ CPU @ 2.90GHz
      Memory: 4.93 GB / 16.00 GB
      Shell: 5.3 - /bin/zsh
    Binaries:
      Node: 8.10.0 - ~/.nvm/versions/node/v8.10.0/bin/node
      Yarn: 1.13.0 - /usr/local/bin/yarn
      npm: 6.8.0 - ~/.nvm/versions/node/v8.10.0/bin/npm
      Watchman: 4.9.0 - /usr/local/bin/watchman
    SDKs:
      iOS SDK:
        Platforms: iOS 12.1, macOS 10.14, tvOS 12.1, watchOS 5.1
      Android SDK:
        Build Tools: 23.0.1, 24.0.0, 24.0.3, 26.0.2, 26.0.3, 27.0.0, 27.0.3, 28.0.0, 28.0.2, 28.0.3
        API Levels: 23, 24, 25, 26, 27, 28
    IDEs:
      Android Studio: 3.3 AI-182.5107.16.33.5264788
      Xcode: 10.1/10B61 - /usr/bin/xcodebuild
    npmPackages:
      react: 16.6.3 => 16.6.3 
      react-native: 0.58.4 => 0.58.4 

[radeno]

Can you sync config files with RN0.58 Android template https://github.com/facebook/react-native/tree/0.58-stable/local-cli/templates/HelloWorld/android and try again?

EDIT:

And update to latest RN 0.58.6 please.

[RoJoHub]

Some Device haven't the lib of armeabi .

How to get lib?

1. rename your apk to xxxx.rar.
2. Go into xxxx/lib/,now you can see armeabi directory.
3. Get libreactnativejni.so

[vanydeasy]

@radeno I have synced all config files to 0.58 except BUCK. Although it's hard to copy it as it is since our app is brownfield. Pretty sure there is no native changes from 0.58.4 to 0.58.6.

@RoJoHub Do you mean that the libreactnativejni.so is not included on some ABIs? since I'm sure it's all there.

[RoJoHub]

Also you should create directory of armabi.
Copy files from armeabi-v7a to armabi.

For your question, please confirm what architecture your device is.
If the device is an armabi architecture, then you can solve your problem.

[radeno]

@vanydeasy i understand your concerns. You can diff files with for example VSCode (Compare file). Or if you upgraded from lower version check it with https://github.com/react-native-community/rn-diff-purge. I just want to as much as possible to have identical configs, to eliminate diffs. It sometimes really helps to find problematic issue.

But i think i have found your issue.
As you can see this commit https://github.com/facebook/react-native/commit/07d1075 in description is that SoLoader was updated to newer version for Supporting App Bundle. It is available in 0.59-RC version.
Official production ready should be released in monday/tuesday.

[vanydeasy]

@RoJoHub from this doc, i got that armabi is deprecated meanwhile the crashes happen on several other architectures as well.

@radeno yes we use https://github.com/react-native-community/rn-diff-purge as well to upgrade our app. Do you want me to list down every possible difference based on it?
And also, from what I understand, SoLoader 0.6.0 has been included on 0.58.4.

[radeno]

@vanydeasy you are right. SoLoader was backported. My mistake.
Then it is weird. Is it same results for clean RN 0.58 init?
We don't use 64bit for Android yet because some other packages are not compatible yet.

[RoJoHub]

I think we should browse this page.
https://developer.android.com/ndk/guides/abis?hl=en

Specially.

---

Automatic extraction of native code at install time

When installing an application, the package manager service scans the APK, and looks for any shared libraries of the form:

lib/<primary-abi>/lib<name>.so

If none is found, and you have defined a secondary ABI, the service scans for shared libraries of the form:

lib/<secondary-abi>/lib<name>.so

When it finds the libraries that it's looking for, the package manager copies them to /lib/lib.so, under the application's data directory (data/data//lib/).

If there is no shared-object file at all, the application builds and installs, but crashes at runtime.

[RoJoHub]

To Reproduce
We have tried to reproduce it with many devices but we can only reproduce it in one condition.

Install the release app
Upgrade OS from 32bit to 64bit
Open the app

If you update android,maybe system will not search again.Unless reinstall

[miguelslemos]

I had the same issue with AGP 3.3.2. For now, we are downgrading to AGP 3.2.0 until bump RN to 0.59

https://github.com/facebook/SoLoader/pull/26
https://github.com/facebook/react-native/pull/23239

https://github.com/facebook/SoLoader/pull/26#issuecomment-456538570

[dulmandakh]

@vanydeasy could you please check CPU architecture of devices crashing. It seems that x86_64 is missing from abiFilters, and that might causing issues on x86_64 architecture.

[dulmandakh]

also could you please check if it still persists on 0.59.x?

[grabbou]

Is this something that could be fixed by: https://github.com/facebook/react-native/commit/4b996da470b43f97fd0426b54bda739d7717fb28? Would be good to know whether this issue persists on 0.59.1 where this commit is included.

[vanydeasy]

@RoJoHub You are probably right but doesn't that mean that the fault is on android side then?

@miguelslemos SoLoader v0.6.0 was backported to RN v0.58.4 which we are using. The problem still persists.

@dulmandakh x86_64 just got included on 0.59, right? So I don't think that's the case. It even crashes on Samsung s10 which uses ARM architecture. But I'm going to update you after I upgrade to 0.59.

@grabbou Don't think that's the case since x86_64 is not even included on RN 0.58.

@ollydixon Oh really? I'm using gradle plugin 3.3.2 now. What version of RN are you using btw?

[RoJoHub]

Is this something that could be fixed by: 4b996da? Would be good to know whether this issue persists on 0.59.1 where this commit is included.

It's just a temple.

[RoJoHub]

@RoJoHub你可能是对的，但这是不是意味着故障在android方面呢？

@miguelslemos SoLoader v0.6.0被反向移植到我们正在使用的RN v0.58.4。问题仍然存在。

@dulmandakh x86_64刚被纳入0.59，对吗？所以我认为不是这样的。它甚至在使用ARM架构的三星s10上崩溃。但升级到0.59后我会更新你。

@grabbou不要认为是这种情况，因为RN 0.58甚至没有包含x86_64。

@ollydixon哦真的吗？我现在正在使用gradle插件3.3.2。您使用什么版本的RN btw？

In you gradle

android {
    ...
    defaultConfig {
       ...
        ndk {   
            abiFilters "armeabi-v7a", "x86", "arm64-v8a"
        }
    }
}

---

Different Android handsets use different CPUs, which in turn support different instruction sets. Each combination of CPU and instruction sets has its own Application Binary Interface, or ABI. The ABI defines, with great precision, how an application's machine code is supposed to interact with the system at runtime. You must specify an ABI for each CPU architecture you want your app to work with.

---

Some device will run on armeabi architecture.

---

I have already said it before. Why don't you try it.
I am very confused.

https://github.com/facebook/react-native/issues/23764#issuecomment-471407517

[ollydixon]

@RoJoHub many of us use deployment pipelines and don't have access to directories. Also this is a hack not a fix and for any other team members on the project they need to be aware of this on each build.

[RoJoHub]

@RoJoHub many of us use deployment pipelines and don't have access to directories. Also this is a hack not a fix and for any other team members on the project they aware of this on each build.

---

In a reply, I chose the wrong people.Sorry. @ollydixon
Now re-edited.

https://github.com/facebook/react-native/issues/23764#issuecomment-475837480

---

I did not say to add lib at build time.
If you look at my statement carefully.

https://github.com/facebook/react-native/issues/23764#issuecomment-469996007

---

This image is just to express the results after the file is added.

---

I correct my answer.
We should create armeabi at projectpath/android/app/src/main/jniLibs.
And copy files from apk/lib/armeabi-v7a to projectpath/android/app/src/main/jniLibs/armeabi.

[RoJoHub]

How anyone else having issues downgrading to gradle plugin 3.2.+ solved it for me.

In the top level build.gradle file change to:

dependencies {
    classpath 'com.android.tools.build:gradle:3.2.+'
}

I'm using React 57.1 I cannot get 58 and 59 to work, have many libraries in a large project.

In addition, according to my experience, your solution is not related to her problem.

I think this is not a react-native issue, and this issue should be closed.

[vanydeasy]

@RoJoHub I'm confused. We do not even include armeabi on ndkFilters. But the lack of several so files on armeabi architecture can still be the source of the problem?

[RoJoHub]

@RoJoHub I'm confused. We do not even include armeabi on ndkFilters. But the lack of several so files on armeabi architecture can still be the source of the problem?

For example,my device is ARMv7 Processor rev 1 (v7l)

Use adb

Use Java Code

/**
     * The name of the instruction set (CPU type + ABI convention) of native code.
     * @deprecated Use {@link #SUPPORTED_ABIS} instead.
     */
String cpuInfo = android.os.Build.CPU_ABI;

---

---

1. First, determine what CPU architecture is on the device where the problem occurred.
2. If the architecture of the device is armeabi, then your problem is caused by this cause.

[slestang]

I had the same issue while using Android bundle with RN 0.59.0. Some devices work and other don't and I didn't find the key differences.

It seems I have fixed it by removing the override of the versionCode for each variants in android/app/build.gradle:

-    // applicationVariants are e.g. debug, release
-    applicationVariants.all { variant ->
-        variant.outputs.each { output ->
-            // For each separate APK per architecture, set a unique version code as described here:
-            // http://tools.android.com/tech-docs/new-build-system/user-guide/apk-splits
-            def versionCodes = ["armeabi-v7a":1, "x86":2, "arm64-v8a": 3, "x86_64": 4]
-            def abi = output.getFilter(OutputFile.ABI)
-            if (abi != null) {  // null for the universal-debug, universal-release variants
-                output.versionCodeOverride =
-                        versionCodes.get(abi) * 1048576 + defaultConfig.versionCode
-            }
-        }
-    }

The Android doc says it is no longer require when using bundle (I don't have enough knowledge of Android's internal to understand why it was require in the first place).

Note: I don't have any abiFilters.

I am not 100% sure of the fix yet as I only tested locally on 1 device with an APK extracted from my bundle with bundletool. I will confirm the fix latter after deploying the APKs on enough devices through Google Play console.

[vanydeasy]

@RoJoHub the devices that crash have 2 or 3 supported ABIs; arm64-v8a, armeabi-v7a, armeabi. So, I don't think that's the case? Except the devices only support armeabi, right?

@slestang we have removed the following code but still get the same error. Weird that re-installing fix the issues for us.

[slestang]

@vanydeasy after more than one day of debugging I still haven't figure it out in which conditions the bug is triggered (my "fix" above is definitively not working) :-[

In my case it seems very random; in most cases it crash but sometimes after a re-install, the App works fine until a re-start and then it keep crashing. I will try to find more time later this week to investigate the differences between the working and non-working APKs.

[oferRounds]

@slestang did you find any solution to this one? Got some crashes of this kind, using RN v0.59.5

Could your comment above work?

[dongzhixuanyuan]

In my case ,this crash 100% happened when use google App Bundle.

[slestang]

@oferRounds no sorry. The crash don't happens too often in our case so I didn't spend more time on it.

[oferRounds]

@slestang got you, thank you!

[dongzhixuanyuan]

this crash was resovled on version 0.58.6
Thanks

---Original---
From: "Ofer Morag"[e-mail]
Date: Fri, May 17, 2019 16:14 PM
To: "facebook/react-native"[e-mail];
Cc: "Magina"[e-mail];"Comment"[e-mail];
Subject: Re: [facebook/react-native] [ANDROID] SoLoader error using App Bundle (#23764)

@slestang got you, thank you!

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

[varunkumar2]

We are using react-native:0.59.1 and getting this crash for following devices (using google app bundle)-

1. OPPO -  CPH1727, F9
2. Xiaomi- Redmi Note 6 Pro, Redmi Note 7 Pro, MI MAX 2
3. Samsung- Galaxy J7 Pro, Galaxy J7(2016)
4. Galaxy J7(2016)- GI-I9500_TMMARS

Config in build.gradle-

defaultConfig {
  ndk {
    abiFilters "armeabi-v7a", "arm64-v8a", "x86", "x86_64"
  }
}

[Nahani]

Hello,

I use RN 0.59.8 I have the same issue, the app not works with 64 bits phones, it work only with 32 bits phone.

As recommented in RN 0.59.8 I removed the ndk.abiFilters, the app not crash but I still have error at SoLoader with all lib.so :
libjscexecutor.so found on /data/app/com.app.test-SFnTD8ddIPtzG5-VSr7cKA==/lib/x86_64

Regards,

[radeno]

Guys, you should check 3rd party packages if they support 64bit ABI.
Please post your package list always. You can check default demo app on 64bit phone. If it doesn't crash then try to find a problem elsewhere.

[djendacott]

We are experiencing this issue as well. Is the consensus now that this is caused by 3rd party packages?

[dongzhixuanyuan]

Upgrade to react_native 0.58.6 will sovled.
The reason is react-native build script.
You can the patch

---Original---
From: "djendacott"[e-mail]
Date: Fri, May 24, 2019 08:10 AM
To: "facebook/react-native"[e-mail];
Cc: "Magina"[e-mail];"Comment"[e-mail];
Subject: Re: [facebook/react-native] [ANDROID] SoLoader error using App Bundle (#23764)

We are experiencing this issue as well. Is the consensus now that this is caused by 3rd party packages?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

[dongzhixuanyuan]

Maybe not all libxxx.so both have 32bit and 64bit.You can analasy the apk to confirm it.

---Original---
From: "Varun Kumar"[e-mail]
Date: Thu, May 23, 2019 17:02 PM
To: "facebook/react-native"[e-mail];
Cc: "Magina"[e-mail];"Comment"[e-mail];
Subject: Re: [facebook/react-native] [ANDROID] SoLoader error using App Bundle (#23764)

We are using react-native:0.59.1 and getting this crash for following devices (using google app bundle)-

1. OPPO - CPH1727, F9 2. Xiaomi- Redmi Note 6 Pro, Redmi Note 7 Pro, MI MAX 2 3. Samsung- Galaxy J7 Pro, Galaxy J7(2016) 4. Galaxy J7(2016)- GI-I9500_TMMARS
   Config in build.gradle-
   defaultConfig { ndk { abiFilters "armeabi-v7a", "arm64-v8a", "x86", "x86_64" } }
   —
   You are receiving this because you commented.
   Reply to this email directly, view it on GitHub, or mute the thread.

[vanydeasy]

I'm using 0.59.0 but the problem still persists. Not quite sure if it's a misconfiguration on my side. If someone can confirm this, that would be great. We have analyzed the apk and can confirm that all so files are in place.

[viveksoneja28]

Hi, Even we are facing the same issue. It works fine with Standalone Apks (generated from bundle). But starts crashing with multi-apk install. Kindly help to resolve this.

Tried with RN Version 0.53.3, 0.58.6 and 0.59.0.

java.lang.UnsatisfiedLinkError: couldn't find DSO to load: libreactnativejni.so
        at com.facebook.soloader.SoLoader.loadLibraryBySoName(SoLoader.java:11)
        at com.facebook.soloader.SoLoader.loadLibrary(SoLoader.java:6)
        at com.facebook.react.bridge.ReactBridge.staticInit(ReactBridge.java:2)
        at com.facebook.react.bridge.NativeMap.<clinit>(NativeMap.java:1)
        at com.facebook.react.bridge.JSCJavaScriptExecutorFactory.create(JSCJavaScriptExecutorFactory.java:1)
        at com.facebook.react.ReactInstanceManager$5.run(ReactInstanceManager.java:9)
        at java.lang.Thread.run(Thread.java:764)

[pacozaa]

I have the same problem so I have to change the config in build.gradle
from
include 'arm64-v8a', 'armeabi-v7a', 'x86'
to
include "armeabi-v7a", "x86"
but still looking for the answer to fix when I am forced to use include 'arm64-v8a', 'armeabi-v7a', 'x86'

[vanydeasy]

Update from me: we are still having this issue but the number of users has been decreasing. we just found out that our application got published on Vivo Store, without our consent, and it contributed about 50% of our crash number.

[khemrajiitk]

After adding below code to app level build.gradle file. It will works but increse the apk size.

bundle {
abi {
enableSplit false
}
}

any solution for it ?

[manithin]

for me the issue was resolved when set

def enableProguardInReleaseBuilds = false

when its true, the app crashes on release with the so loader error. bare in mind that this increases the apk size

[eduduardo]

I disabled on gradle.properties:

android.enableR8=false 

and updated some proguard rules and it works (no crashes on release mode) with:

def enableSeparateBuildPerCPUArchitecture = true
def enableProguardInReleaseBuilds = true

[vanydeasy]

@eduduardo So based on your hypothesis, soloader has bugs when using R8? Btw, can you repro the crash from release mode? Did the crash happen intermittently?

[sultan-arshi]

Some Device haven't the lib of armeabi .

How to get lib?

1. rename your apk to xxxx.rar.
2. Go into xxxx/lib/,now you can see armeabi directory.
3. Get libreactnativejni.so

what to do after that

[plecesne]

Does SoLoader support mmapping the .so files from the APK on M+?

[iain-merrick-fanduel]

From inspecting the source, no, it does not. It always manually extracts the libraries from the APK(s).

[wsdt]

Still having this issue

[ThomasGHenry]

just hit this on 0.59.10

[jedashford]

We also hit this today on .59.10

[wsdt]

Just for everyone coming here: You need to have react-native 0.60.2 or higher to run Hermes.
See the docs: React-Native with Hermes

[MorgadoKnivet]

I have this issue in "react-native": "0.59.4",

[MorgadoKnivet]

I was able to solve the problem using ndk {abiFilters 'armeabi-v7a', 'x86' } but when I went to post in the store he didn't let me continue.

[MorgadoKnivet]

happens when I use ndk.abiFilters 'armeabi-v7a', 'arm64-v8a', 'x86', 'x86_64'

java.lang.UnsatisfiedLinkError: couldn't find DSO to load: libreactnativejni.so caused by: couldn't find DSO to load: libfb.so caused by: couldn't find DSO to load: libc++_shared.so caused by: dlopen failed: "/data/data/com.bimp/lib-4/libc++_shared.so" is 32-bit instead of 64-bit
FATAL EXCEPTION: create_react_context
Process: com.bimp, PID: 15797
java.lang.UnsatisfiedLinkError: couldn't find DSO to load: libreactnativejni.so caused by: couldn't find DSO to load: libfb.so caused by: couldn't find DSO to load: libc++_shared.so caused by: dlopen failed: "/data/data/com.bimp/lib-4/libc++_shared.so" is 32-bit instead of 64-bit
at com.facebook.soloader.SoLoader.doLoadLibraryBySoName(SoLoader.java:738)
at com.facebook.soloader.SoLoader.loadLibraryBySoName(SoLoader.java:591)
at com.facebook.soloader.SoLoader.loadLibrary(SoLoader.java:529)
at com.facebook.soloader.SoLoader.loadLibrary(SoLoader.java:484)
at com.facebook.react.bridge.ReactBridge.staticInit(ReactBridge.java:31)
at com.facebook.react.bridge.NativeMap.(NativeMap.java:19)
at com.facebook.react.jscexecutor.JSCExecutorFactory.create(JSCExecutorFactory.java:25)
at com.facebook.react.ReactInstanceManager$5.run(ReactInstanceManager.java:944)
at java.lang.Thread.run(Thread.java:764)

[MorgadoKnivet]

I think for now I managed to solve the problem, but my apk doubled in size.
edit: This only worked with APK, bundle didn't work

defaultConfig {
...
ndk.abiFilters 'armeabi-v7a','arm64-v8a','x86','x86_64'
multiDexEnabled true
}
...
splits {
abi {
reset()
// enable enableSeparateBuildPerCPUArchitecture
universalApk false // If true, also generate a universal APK
include 'armeabi-v7a','arm64-v8a','x86','x86_64'
}
}

[brasrox]

some devices ( Nexus 4 LGE) just hit this on 0.59.10 for me (bugsnag alert)

java.lang.UnsatisfiedLinkErrorMainActivity couldn't find DSO to load: libreactnativejni.so

im using app bundle 'armeabi-v7a','arm64-v8a','x86','x86_64'
and this packages:

"@react-native-community/async-storage": "^1.4.2",
    "axios": "^0.19.0",
    "bugsnag-react-native": "^2.22.4",
    "color": "^3.1.1",
    "date-fns": "^2.0.0-beta.4",
    "lodash": "^4.17.11",
    "native-base": "^2.13.4",
    "prop-types": "^15.7.2",
    "react": "16.8.3",
    "react-native": "^0.59.10",
    "react-native-accordion": "^1.0.1",
    "react-native-app-auth": "^4.4.0",
    "react-native-base64": "0.0.2",
    "react-native-camera": "^2.11.1",
    "react-native-collapsible": "^1.4.0",
    "react-native-device-info": "^2.2.2",
    "react-native-gesture-handler": "^1.2.1",
    "react-native-ionicons": "^4.6.1",
    "react-native-motion": "^1.0.4",
    "react-native-onesignal": "^3.3.1",
    "react-native-pdf": "^5.1.4",
    "react-native-permissions": "^1.1.1",
    "react-native-popup-dialog": "^0.18.3",
    "react-native-popup-menu": "^0.15.6",
    "react-native-qrcode-scanner": "^1.2.1",
    "react-native-render-html": "^4.1.2",
    "react-native-rss-parser": "^1.4.0",
    "react-native-share": "^1.2.1",
    "react-native-snap-carousel": "^3.8.0",
    "react-native-splash-screen": "^3.2.0",
    "react-native-status-bar-height": "^2.3.1",
    "react-native-vector-icons": "^6.5.0",
    "react-native-webview": "^5.8.2",
    "react-native-xml2js": "^1.0.3",
    "react-native-youtube": "^1.1.0",
    "react-navigation": "^3.11.0",
    "recyclerlistview": "^2.0.10-beta.1",
    "rn-fetch-blob": "^0.10.15",
    "socket.io-client": "^2.2.0",
    "styled-components": "^4.2.0",
    "utf8": "^3.0.0"

[Subway19]

+1 This is happening on 0.59.10 with Android App Bundle.
Happening on Vivo devices as seen on Play Console Dashboard in Android Vitals --> Crashes

[jedashford]

We upgraded to RN .60.5 and made sure the app/build.gradle has all of the
things in the upgrade diff. I think we had some duplicate things and/or
missing things in the Gradle file. The most recent uploads we have to
Google do not contain the error anymore. Just a hint to those struggling
with this.

On Fri, Aug 23, 2019, 6:54 AM Sumant Bagade [e-mail]
wrote:

+1 This is happening on 0.59.10 with Android App Bundle.
Happening on Vivo devices.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/facebook/react-native/issues/23764?email_source=notifications&email_token=AA7LVT46GKWGNPPO56625HDQF7MWXA5CNFSM4G3XQR4KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5ADWTY#issuecomment-524303183,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AA7LVT2ZID5FXRNHYC5FCB3QF7MWXANCNFSM4G3XQR4A
.

[adnkh]

Sill happening with 60.5 in Android 4

[vanydeasy]

@Subway19 You probably have the same problem as I did stated here. https://github.com/facebook/react-native/issues/23764#issuecomment-500284885

[Noltibus]

We are using react-native:0.59.1 and getting this crash for following devices (using google app bundle)-

1. OPPO -  CPH1727, F9
2. Xiaomi- Redmi Note 6 Pro, Redmi Note 7 Pro, MI MAX 2
3. Samsung- Galaxy J7 Pro, Galaxy J7(2016)
4. Galaxy J7(2016)- GI-I9500_TMMARS

Config in build.gradle-

defaultConfig {
  ndk {
    abiFilters "armeabi-v7a", "arm64-v8a", "x86", "x86_64"
  }
}

We also have this error for about the same devices. We use ArCore, so at first, I thought the error is due to those devices being rooted because ArCore is not available for them. But after reading this thread I think its another error. we use ract-native 59.8.

[maskaravivek]

Well, i have Google Play installed and up to date.

I found a crash report in my phone. Here is the error i have, if it can help :

java.lang.UnsatisfiedLinkError: couldn't find DSO to load: libreactnativejni.so
  at com.facebook.soloader.SoLoader.doLoadLibraryBySoName(SoLoader.java:703)
  at com.facebook.soloader.SoLoader.loadLibraryBySoName(SoLoader.java:564)
  at com.facebook.soloader.SoLoader.loadLibrary(SoLoader.java:500)
  at com.facebook.soloader.SoLoader.loadLibrary(SoLoader.java:455)
  at com.facebook.react.bridge.ReactBridge.staticInit(ReactBridge.java:18)
  at com.facebook.react.bridge.NativeMap.<clinit>(NativeMap.java:19)
  at com.facebook.react.bridge.JSCJavaScriptExecutorFactory.create(JSCJavaScriptExecutorFactory.java:21)
  at com.facebook.react.ReactInstanceManager$5.run(ReactInstanceManager.java:914)
  at java.lang.Thread.run(Thread.java:764)

For information, i have Messenger Lite (also up to date) installed on this phone.

I am also getting the same error when using react native 60.5. Did anyone manage to fix the issue? Will moving back to an older version help?

[minhh1]

Try adding this in your app build.gradle:

android {
...
packagingOptions {
        pickFirst '**/armeabi-v7a/libc++_shared.so'
        pickFirst '**/x86/libc++_shared.so'
        pickFirst '**/arm64-v8a/libc++_shared.so'
        pickFirst '**/x86_64/libc++_shared.so'
        pickFirst '**/x86/libjsc.so'
        pickFirst '**/armeabi-v7a/libjsc.so'
    }
}

[bemnet4u]

@minhh1 the so file that is causing issue is not listed in your fix above. Most of us are seeing this issue with libreactnativejni.so. is your suggestion enough to fix the issue being discussed here?

Anyone tried this fix?

[shaktimoyal]

I think for now I managed to solve the problem, but my apk doubled in size.
edit: This only worked with APK, bundle didn't work

defaultConfig {
...
ndk.abiFilters 'armeabi-v7a','arm64-v8a','x86','x86_64'
multiDexEnabled true
}
...
splits {
abi {
reset()
// enable enableSeparateBuildPerCPUArchitecture
universalApk false // If true, also generate a universal APK
include 'armeabi-v7a','arm64-v8a','x86','x86_64'
}
}

Hey what solution did you use.
I am getting the same issue

[aliceathens]

+1

"react": "16.8.3",
"react-native": "0.59.10",

[39otrebla]

Happening on react native 0.59.10 when using AppBundle, quite bothersome considering we have an urgent rollout blocked at 3% by this. But...

we successfully deployed an app in the mid of August, with react native 0.59.5 and the same build.gradle configuration. No crash at all on this one.

[mcorner]

We are seeing this show up in BugSnag as well after we went to App Bundles. Interestingly Google Play is reporting 0 crashes for apps installed from Play, but some for those "Installed from Anywhere". The count from Bugsnag is a good bit higher than Play Console.

Top devices we see are vivo x9, Samsung Galaxy A70, Pixel, vivo S1, and a few others.

We are on RN 0.59.10, Gradle 3.3.0. Some relevant bits from build.gradle:

defaultConfig {

...
ndk {
abiFilters "armeabi-v7a", "x86", "arm64-v8a", "x86_64"
}
}

splits {
    abi {
        reset()
        enable enableSeparateBuildPerCPUArchitecture
        universalApk false  // If true, also generate a universal APK
        include "armeabi-v7a", "x86", "arm64-v8a", "x86_64"
    }
}

[39otrebla]

@mcorner we've seen the exact same devices crashing on Crashlytics, always close (in time) to the rollout of a new release. We're wondering if it couldn't be Google which is testing the app via TestLab for the "Pre-launch Report" feature... (although it is showing no crash).

[ddenisen]

For Vivo devices specifically, the come with their own app store, which we've discovered redistributes a lot of Play Store apps without permission. I've found our app on their store, and the package that they were distributing was just the base APK without platform-specific native library parts. I was able to reproduce the reported SoLoader crash by launching our app after installing it via the Vivo Appstore.

[aliceathens]

Having the same issue we can't release the new update to our app as it crashes on every test we run in fire base - installs fine on simulator and other devices. I need to know what is causing this so we aren't releasing an update to users that crashes on them:

"react-native": "0.59.10",

java.lang.UnsatisfiedLinkError: couldn't find DSO to load: libreactnativejni.so caused by: couldn't find DSO to load: libfb.so caused by: couldn't find DSO to load: libc++_shared.so caused by: dlopen failed: "/data/data/com.app/lib-4/libc++_shared.so" is 32-bit instead of 64-bit FATAL EXCEPTION: create_react_context Process: com.app, PID: 16854 java.lang.UnsatisfiedLinkError: couldn't find DSO to load: libreactnativejni.so caused by: couldn't find DSO to load: libfb.so caused by: couldn't find DSO to load: libc++_shared.so caused by: dlopen failed: "/data/data/com.app/lib-4/libc++_shared.so" is 32-bit instead of 64-bit at com.facebook.soloader.SoLoader.doLoadLibraryBySoName(SoLoader.java:738) at com.facebook.soloader.SoLoader.loadLibraryBySoName(SoLoader.java:591) at com.facebook.soloader.SoLoader.loadLibrary(SoLoader.java:529) at com.facebook.soloader.SoLoader.loadLibrary(SoLoader.java:484) at com.facebook.react.bridge.ReactBridge.staticInit(ReactBridge.java:31) at com.facebook.react.bridge.NativeMap.<clinit>(NativeMap.java:19) at com.facebook.react.jscexecutor.JSCExecutorFactory.create(JSCExecutorFactory.java:25) at com.facebook.react.ReactInstanceManager$5.run(ReactInstanceManager.java:944) at java.lang.Thread.run(Thread.java:764)

[FelipePaiva1992]

"react-native": "0.60.2",

Same error

[andrew-koster-]

This is a huge problem. There's no solution???

[FelipePaiva1992]

android {
...
packagingOptions {
pickFirst '/armeabi-v7a/libc++_shared.so'
pickFirst '/x86/libc++_shared.so'
pickFirst '/arm64-v8a/libc++_shared.so'
pickFirst '/x86_64/libc++_shared.so'
pickFirst '/x86/libjsc.so'
pickFirst '/armeabi-v7a/libjsc.so'
}
}

@andrew-koster- this solution works for me

[fabio-alss-freitas]

android {
...
packagingOptions {
pickFirst '/armeabi-v7a/libc++_shared.so'
pickFirst '/x86/libc++_shared.so'
pickFirst '/arm64-v8a/libc++_shared.so'
pickFirst '/x86_64/libc++_shared.so'
pickFirst '/x86/libjsc.so'
pickFirst '/armeabi-v7a/libjsc.so'
}
}

@andrew-koster- this solution works for me

Works for me too, thank you!

[maman]

Hi,

Is there any possibility that the issue here is similiar with https://github.com/Kudo/react-native-v8/issues/29, which fixed by this changes: https://github.com/Kudo/react-native-v8/commit/5a78dd52b0678c18e62972ae5f6cb0f2025e28b4 ?

I'm raising this because the stacktrace is roughly similiar - both mentions soloader failed to load some libraries (although in my case, I'm using react-native-v8 instead of jsc/hermes).

the tl;dr version of the referenced issue above is android versions before Marshmallow had a bug that causes it to load the system library instead of private app library.

[iain-merrick-fanduel]

Is there any possibility that the issue here is similiar with Kudo/react-native-v8#29, which fixed by this changes: Kudo/react-native-v8@5a78dd5 ?

I'm raising this because the stacktrace is roughly similiar - both mentions soloader failed to load some libraries (although in my case, I'm using react-native-v8 instead of jsc/hermes).

the tl;dr version of the referenced issue above is android versions before Marshmallow had a bug that causes it to load the system library instead of private app library.

That sounds plausible, but if so I'd expect to see crashes only on pre-Marshmallow devices (Android 5.1 and lower). Checking the crash logs for the span of time when we had app bundles enabled, I see SoLoader crashes on these OS versions:

• Android 6: 35%
• Android 7: 28%
• Android 8: 7%
• Android 9: 19%
• Android 10: 11%

So I think there's definitely a bug in SoLoader itself, unconnected with the Android OS version.

(There might _also_ be a separate issue related to that Bionic bug, but if so I don't think it's a significant contributor to our crash reports.)

[moneymc]

Same issue. RN 0.59.10

P.S. Looks like it happens only with Nexus 5X and Samsung Galaxy A70 with Root access. I think it's virtual devices from firebase test lab. Unfortunately, i can't reproduce that issue on same devices.

[cmcleese]

Hey if you guys are you getting these errors reported on Firebase Crashlytics, then its very likely only due to a potential bug that was recently fixed on Firebase Crashlytics.
See my comment in the this thread: https://github.com/facebook/react-native/issues/26075#issuecomment-553432192

[santaMoni]

By default, APKs generated from the Android App Bundle have the native libraries uncompressed on devices on Android P+. Not only does that often reduce the download size but that also considerably reduce the size of the app on devices since the Android platform can directly read the native libraries from the APK instead of having to extract them to a separate location. There was a talk at last I/O on how to reduce the size of your app and how that impacts install numbers, and they detailed how this works if you're interested in understanding this better.

So, now that you know why Google Play is doing this, you have the following options:

You can choose to revert to the original APK behaviour, and this can be done by adding the flag android.bundle.enableUncompressedNativeLibs=false in your gradle.properties file. This will effectively disable this optimization, leading to a bigger size of your app for all your users on M+.

You can ensure that the native library is loaded by the Android platform (e.g. using System.loadLibrary) or you if you're reading the library directly yourself for some reason, read it from the APK directly as well.

If the native libraries are loaded by a third party library you're depending on, consider filing a bug for them to address this issue so they follow the same logic as the platform.

[santaMoni]

I hope this can help you, adding the flag android.bundle.enableUncompressedNativeLibs=false in your gradle.properties file

[marcoautiero]

I had, I think, a similar problem. While upgrading from rn 0.55 to 0.60, the build was successful but launching the app I received the following errors:

E/SoLoader: couldn't find DSO to load: libjscexecutor.so caused by: dlopen failed: library "libgnustl_shared.so" not found
E/SoLoader: couldn't find DSO to load: libhermes.so
E/AndroidRuntime: FATAL EXCEPTION: create_react_context

Process: com.xxxx, PID: 9025
    java.lang.UnsatisfiedLinkError: couldn't find DSO to load: libhermes.so
        at com.facebook.soloader.SoLoader.doLoadLibraryBySoName(SoLoader.java:738)
        at com.facebook.soloader.SoLoader.loadLibraryBySoName(SoLoader.java:591)
        at com.facebook.soloader.SoLoader.loadLibrary(SoLoader.java:529)
        at com.facebook.soloader.SoLoader.loadLibrary(SoLoader.java:484)
        at com.facebook.hermes.reactexecutor.HermesExecutor.<clinit>(HermesExecutor.java:20)
        at com.facebook.hermes.reactexecutor.HermesExecutorFactory.create(HermesExecutorFactory.java:27)
        at com.facebook.react.ReactInstanceManager$5.run(ReactInstanceManager.java:952)
        at java.lang.Thread.run(Thread.java:764)

I resolved it adding in the android/build.gradle

allprojects {
    repositories {
        maven {
            // Android JSC is installed from npm
            url("$rootDir/../node_modules/jsc-android/dist")
        }
    }
}

hope it will help someone :)

[m-ramp]

I resolved it adding in the android/build.gradle

allprojects {
    repositories {
        maven {
            // Android JSC is installed from npm
            url("$rootDir/../node_modules/jsc-android/dist")
        }
    }
}

hope it will help someone :)

Did the same thing, manually upgraded to 0.60.0 from 0.59.1, missed this line, adding it fixed it! :)

[tapz]

This fixed the issue for me in RN 0.62.2:

rm -rf $HOME/.gradle/caches/

[soroushm]

This fixed the issue for me in RN 0.62.2:

rm -rf $HOME/.gradle/caches/

I have same issue it coming after clear caches and reinstall it happend
v0.62.2

[soroushm]

Dublicate issue
https://github.com/facebook/react-native/issues/28163

this command work for me
cd android/
Run
./gradlew clean

That should probably fix this.

[Michaelvons]

This fixed the issue for me in RN 0.62.2:

rm -rf $HOME/.gradle/caches/

@tapz is correct. Just do what he suggested.
Works like charm!!

[vanydeasy]

In my case, the error does not appear on 0.61.5 anymore. Should I close this?

[xgAnd]

In my case, the error does not appear on 0.61.5 anymore. Should I close this? my RN version is "react-native": "^0.61.5", still has the error.
java.lang.UnsatisfiedLinkError: couldn't find DSO to load: libflipper.so caused by: dlopen failed: library "libfbjni.so" not found result: 0
at com.facebook.soloader.SoLoader.doLoadLibraryBySoName(SoLoader.java:825)
at com.facebook.soloader.SoLoader.loadLibraryBySoName(SoLoader.java:673)
at com.facebook.soloader.SoLoader.loadLibrary(SoLoader.java:611)
at com.facebook.soloader.SoLoader.loadLibrary(SoLoader.java:559)
at com.facebook.flipper.android.EventBase.(EventBase.java:19)
at com.facebook.flipper.android.FlipperThread.run(FlipperThread.java:25)

[nickarora]

This is _not_ fixed for us. I would not close this issue.

v 0.62.2
rm -rf $HOME/.gradle/caches/
completely clean android install.

Fails on an emulator installed with API 30 and API 28 with several errors all following the same format.

Strangely, it runs on API 29. This might be a clue. It seems the targeted emulator plays a role.

java.lang.UnsatisfiedLinkError: dlopen failed: "/data/user/0/<BUNDLE-ID>/lib-main/libc++_shared.so" is for EM_ARM (40) instead of EM_386 (3)

The issue referenced on the SoLoader repo perfectly describes the problem -- but., since SoLoader, ships with react-native this seems like a ReactNative problem too.

[bill2004158]

I have got same issue:
Fails on an emulator installed with API 30, but runs on API 29

[ryd0rz]

I also have this issue, are there any temporary workarounds? I don't mind editing some node modules manually :)

[danielbattat]

I am getting:
unknown:NativeModuleInitError: java.lang.UnsatisfiedLinkError: couldn't find DSO to load: libreactnativeblob.so caused by: Error: Cannot load /data/app/com.***********-1/lib/arm/libreactnativeblob.so result: 0

with
"react": "16.13.1",
"react-native": "0.63.2",

```
android {
...
buildtypes {
...
release {
// Caution! In production, you need to generate your own keystore file.
// see https://reactnative.dev/docs/signed-apk-android.
signingConfig signingConfigs.release
minifyEnabled true
proguardFiles getDefaultProguardFile("proguard-android.txt"), "proguard-rules.pro"
}

I've tried all the suggestions in this thread and nothing worked. Any suggestions?

[fabriciodanioj]

cd android && ./gradlew clean worked for me

[jimmyceroneii]

@fabriciodanioj do you know why that worked? I'm having the same issue with the following specs:

• Detox: ^17.0.0
• React Native: 0.62.2
• Node: 12.18.0
• Jest: ^24.9.0
• Jest Circus: ^26.1.0
• Typescript: ^3.8.3
• Yarn: 1.22.4

[fabriciodanioj]

@fabriciodanioj do you know why that worked? I'm having the same issue with the following specs:

* Detox: ^17.0.0

* React Native: 0.62.2

* Node: 12.18.0

* Jest: ^24.9.0

* Jest Circus: ^26.1.0

* Typescript: ^3.8.3

* Yarn: 1.22.4

@jimmyceroneii sorry. I dont know.

[jimmyceroneii]

@fabriciodanioj I just tried it out and it kind of worked for me. The crashing is gone (yay!) but now it is refusing to connect with my development server. I don't know if the two are connected, but I'm guessing no. Anyway, thanks for your help!

[shukerullah]

I have got same issue:
Fails on an emulator installed with API 30, but runs on API 29

Same, it's crashing on emulator installed with API 30. How did you fix this issue?