SoLoader not compatible with uncompressed native libraries Android feature about soloader

[passy]

Hi @plecesne, thanks for reaching out. Can you confirm that this is still happening with 0.6.0? I was under the impression that the PR #26 should have fixed exactly that issue.

[iain-merrick-fanduel]

It looks like the fix for this bug was to extract libraries from the APK(s) manually.

Is that correct?

If so, that doesn't seem like a great solution, as it adds more startup time (especially on first launch when the .so files are extracted) and uses more storage space. Is it not possible just to load uncompressed libraries directly from the APK, as is standard since Android M?

[plecesne]

PR #26 seems only related to support of split APKs, i.e. the fact that the native libraries are in a separate APK.
What I'm mentioning is the fact that the native libraries are not extracted from the APK at installation time for App Bundles built from Gradle 3.3 (for devices on M+), hence any attempt at loading the libraries differently than System.load or System.loadLibrary, such as trying to locate them in the install directory (e.g. new File(<install-dir>/libxxx.so) like I see here) will lead to a crash or at least a file not found.

[lucalooz]

Today I have investigated the exact same issue and it seems that with 0.6.0 it's already solved.

We're using react-native 0.56.0 and we've encountered the issue when we upgraded the gradle plugin from 3.2.1 to 3.3.x.

react-native 0.56.0 depends on SoLoader 0.3.0 and unfortunately for some ABI changes introduced in 0.5.0 I cannot force the 0.6.0 version.

This seems to happen only when using App Bundle with gradle plugin 3.3.x and SoLoader < 0.6.0.

We have temporarily reverted to gradle plugin 3.2.1 while waiting to be able to upgrade react-native.

[plecesne]

Great to know, thanks!
Do you know by any chance in which release react-native depends on SoLoader 0.6.0? Otherwise, I can chase that information on react-native GitHub project.