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)

As a temporary workaround, you can also use android.bundle.enableUncompressedNativeLibs=false in your gradle.properties until we address this more permanently.

see also https://github.com/android-ndk/ndk/issues/979 which seems to be more developers hitting this issue.

The suggested workaround emits a warning during sync:

    WARNING: The option setting 'android.bundle.enableUncompressedNativeLibs=false' is experimental and unsupported. The current default is 'true'.

Is this expected? Sounds scary.

Yes, this is expected. We should remove this warning.

Actually, let me file another bug for that so I can keep track of the work on this one.
https://issuetracker.google.com/issues/132721337

I filed https://github.com/android-ndk/ndk/issues/979

I can confirm that using android.bundle.enableUncompressedNativeLibs=false fixes this issue. The crash disappeared in the update that we rolled out with this setting, and we have reports from users that did have the issue on their device before, that confirm that this fixes it. Some were also able to confirm that they did have the app on external storage when it crashed.

This workaround is the safest and makes sense since it exactly reverses the behavior introduced in android gradle plugin v3.3.0, and builds I made after updating the plugin are the ones that had the issue.

I would very strongly suggest making the 'false' setting the default in subsequent android gradle plugin updates. This on-disk optimization is unusable as the combo of building app bundles, devices that have noexec external storage, users storing apps on said external storage, and ndk libs, will always result in these hard to track down, hard to reproduce for the developer but systematic crashes, unless the server-side split apk delivery blacklists these devices for delivering the optimization (there's quite a few of these devices).

Play will no longer leave native libraries uncompressed before Android P to address this issue.
See https://github.com/google/bundletool/releases/tag/0.10.0

This change will be effective when testing locally in Android Studio 3.6.