IssueTracker

Thank you for your feedback. Team may reach out for more feedback in reproducing or triaging this issue.

Thank you for the detailed report. We are looking into it.

The issue seems to be related to apps installed on ASEC storage when the native libraries are uncompressed.

ASEC storage has been deprecated several years ago and installs are banned since Android O (8.0), so I suspect that the exceptions you see on version 8.0+ are unrelated. Could you please check that the exceptions on devices on 8.0+ have indeed different stacktraces?

To mitigate this issue, bundletool could leave the native libraries compressed in the APKs on O+ whenever installLocation is set to "auto" or "preferExternal".

Looking at Crashlytics.... here is a stack trace for an Android 8.0.0 device (The device was a SM-J337A)....

Fatal Exception: java.lang.UnsatisfiedLinkError: dalvik.system.PathClassLoader[DexPathList[[zip file "/data/app/org.lds.ldssa-Ms3Se_bJEm53xgnoNTHnxg==/base.apk"],nativeLibraryDirectories=[/data/app/org.lds.ldssa-Ms3Se_bJEm53xgnoNTHnxg==/lib/arm, /system/lib, /vendor/lib]]] couldn't find "libsqliteX.so"
       at java.lang.Runtime.loadLibrary0(Runtime.java:1011)
       at java.lang.System.loadLibrary(System.java:1657)
       ....


Here is another one for a Android 8.1.0 on device LM-V405
Fatal Exception: java.lang.UnsatisfiedLinkError: dalvik.system.PathClassLoader[DexPathList[[zip file "/data/app/org.lds.ldssa-v8dzvQ_3IHJacrVlTX6c5A==/base.apk"],nativeLibraryDirectories=[/data/app/org.lds.ldssa-v8dzvQ_3IHJacrVlTX6c5A==/lib/arm64, /system/lib64, /vendor/lib64]]] couldn't find "libsqliteX.so"
       at java.lang.Runtime.loadLibrary0(Runtime.java:1011)
       at java.lang.System.loadLibrary(System.java:1657)
       ....


Here is another one for a Android 8.1.0 on device SM-J327W
Fatal Exception: java.lang.UnsatisfiedLinkError: dlopen failed: couldn't map "/mnt/asec/org.lds.ldssa-1/split_config.armeabi_v7a.apk!/lib/armeabi-v7a/libsqliteX.so" segment 1: Permission denied
       at java.lang.Runtime.loadLibrary0(Runtime.java:1016)
       at java.lang.System.loadLibrary(System.java:1657)
       ....

Let me know if you need more logs or more data....

We started running into this issue after releasing an update that switched to app bundles. We have since released an update that disables the ability to install the app on external storage (via android:installLocation="internalOnly"). This has significantly reduced the number of crashes / UnsatisfiedLinkErrors reported, but we're still getting some. Our first native library that's loaded is the Crashlytics NDK, so that's what shows up in all the stack traces. Here are a couple examples from the Play Console:

Samsung Galaxy S9+ (star2qltesq), Android 9
java.lang.UnsatisfiedLinkError:
  at java.lang.Runtime.loadLibrary0 (Runtime.java:1012)
  at java.lang.System.loadLibrary (System.java:1669)
  at com.crashlytics.android.ndk.JniNativeApi.<clinit> (JniNativeApi.java:13)
  at com.crashlytics.android.ndk.CrashlyticsNdk.onPreExecute (CrashlyticsNdk.java:50)
  ...
  at io.fabric.sdk.android.Fabric.with (Fabric.java:339)
  at [Application class].onCreate
  at android.app.Instrumentation.callApplicationOnCreate (Instrumentation.java:1154)
  ...
  at com.android.internal.os.ZygoteInit.main (ZygoteInit.java:1445)

LGE LG Stylo 4 (cv7a), Android 8.1
java.lang.UnsatisfiedLinkError:
  at java.lang.Runtime.loadLibrary0 (Runtime.java:1016)
  at java.lang.System.loadLibrary (System.java:1657)
  at com.crashlytics.android.ndk.JniNativeApi.<clinit> (JniNativeApi.java:13)
  at com.crashlytics.android.ndk.CrashlyticsNdk.onPreExecute (CrashlyticsNdk.java:50)
  ...
  at io.fabric.sdk.android.Fabric.with (Fabric.java:339)
  at [Application class].onCreate
  at android.app.Instrumentation.callApplicationOnCreate (Instrumentation.java:1120)
  ...
  at com.android.internal.os.ZygoteInit.main (ZygoteInit.java:810

Since we've disabled the ability to install the app to external storage, I'm not sure if this is the same issue or if I should open a new one.

as...@gmail.com (comment #6)  This seems to be the very same issue that we are seeing.   In our case, we switch back to using an apk to fix the issue (our users got pretty upset when we released a version that prevented them from moving the app to the SD Card)