We are starting a process using the ProcessBuilder with the
“LD_LIBRARY_PATH” environment path set to nativeLibraryDir:
processBuilder.environment().put(“LD_LIBRARY_PATH”,
context.getApplicationInfo().nativeLibraryDir);
We are having .so libraries located in “lib/” path for different
architectures. (arm64-v8a, armeabi-v7a, x86, x86_64)
We are building bundles and .apks(s) with splits for each architecture.
The issue is:
With gradle plugin 3.3.0 and 3.3.1 we are getting CANNOT LINK EXECUTABLE
runtime error when our executable tries to load an .so library.
With gradle plugin 3.2.1 it works.
Tested with gradle 4.10.3 and 5.0. CompileSdk: 28. buildTools: 28.0.3,
bundle generated in AS 3.2.1, signing with debug certificate.
We found 2 differences in .aab bundles when comparing a build generated
with gradle plugin 3.2.1 vs 3.3.1:
The BundleConfig.pb generated using gradle plugin 3.2.1, which works,
starts with:
0.5.0
the BundleConfig.pb generated using gradle plugin 3.3.1, which does not
work, starts with:
0.6.0
Does this specify some tool version(s) or procedure used for generating the
apks?
Another difference is the base-[arm64_v8a].apk size inside the generated
.apks:
Using gradle plugin 3.2.1: 2.2 MB
using gradle plugin 3.3.1: 5.1 MB
Note: After unzipping the base-[arm64_v8a].apk, the size of the .so
libraries inside is 5.1 MB.
This looks like the .apk or the libraries inside were not compressed when
using gradle plugin 3.3.1.
Couldn’t this different/wrong format of files/compression cause the issue
with loading .so libraries during runtime?
Thanks!
https://issuetracker.google.com/issues/124064887
--
You received this message because you are subscribed to the Google Groups
"adt-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to adt-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
