Gradle plugin 3.3.+ with apk bundles causes CANNOT LINK EXECUTABLE runtime error in a process using “LD_LIBRARY_PATH” environment path.

45 views
Skip to first unread message

Martin Rajniak

unread,
Feb 8, 2019, 12:58:22 PM2/8/19
to adt-dev
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
Reply all
Reply to author
Forward
0 new messages