We're seeing crashes in SoLoader in production when loading libreactnativejni.so
. We're using React Native 0.59 and SoLoader 0.6.0.
The crash occurs on a range of devices, on Android OS versions 6 through 10. Google devices seem especially prone, notably the Pixel and Chromebook Plus V2.
The crashes appear to stem from our switch to using an app bundle rather than an APK on the Google Play store. This looks possibly related to https://github.com/facebook/SoLoader/issues/30, but that issue is marked as resolved in 0.6.0.
It looks like the app is sometimes attempting to link against old copies of some of the libraries. Here are some examples:
Fatal Exception: java.lang.UnsatisfiedLinkError: couldn't find DSO to load: libreactnativejni.so caused by: dlopen failed: cannot locate symbol "_ZN3fLI7FLAGS_vE" referenced by "/data/app/com.fanduel.android.self-1/lib/arm/libglog.so"...
Fatal Exception: java.lang.UnsatisfiedLinkError: couldn't find DSO to load: libreactnativejni.so caused by: dlopen failed: cannot locate symbol "_ZN8facebook5react15makeJIntOrThrowEx" referenced by "/data/app/com.fanduel.android.self-7bFAALdOGMNizGU2gL_5nA==/lib/arm/libreactnativejni.so"...
Fatal Exception: java.lang.UnsatisfiedLinkError: couldn't find DSO to load: libreactnativejni.so caused by: dlopen failed: library "/data/user/0/com.fanduel.android.self/lib-0/libreactnativejni.so" not found
Fatal Exception: java.lang.UnsatisfiedLinkError: couldn't find DSO to load: libreactnativejni.so caused by: dlopen failed: library "libfb.so" not found
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: dlopen failed: library "/data/user/0/com.fanduel.android.self/lib-0/libfb.so" not found
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: libc++_shared.so caused by: dlopen failed: "/data/data/com.fanduel.android.self/lib-1/libc++_shared.so" is 32-bit instead of 64-bit
(this last one started appearing after we added 64-bit support)
I wonder if the problem is just that the filesystem sometimes isn't fully flushed and ends up in an inconsistent state. Inspecting the SoLoader code, it tries to be robust (e.g. comparing a manifest of extracted files against the contests of the APK zipfiles) but it's hard to say if it's bulletproof. Maybe the manifest file is updated, but the writes to the .so files aren't completed, so the app thinks it has the current libraries installed when in fact it still has the old ones.
Sorry for the lack of detail, I'm still trying to get a clearer picture of what's going on!
The crash rate is quite low and we haven't managed to reproduce it ourselves. However, I think I've seen enough to be confident that it's the combination of SoLoader and app bundles that causes the problem.
We plan to switch back to using an APK instead of an app bundle to see if that avoids the problem.