libs file(*.so) inside split apk doesn't extracted to folder "lib" in App Bundle about bundletool HOT 14 CLOSED

From Android M, the Android platform supports uncompressed native libraries in APKs, which allows the platform to read the native libraries directly from the APK without having to extract them. This is why you don't see them in the "lib/" directory if you're testing on a device on Android M or later.

Since the Android platform reads the native libraries from the APK directly, you should probably do the same if you need to verify something on them.

There is a flag in Gradle to disable this feature but that leads to bigger APKs on users devices since the native libraries are extracted out of the APK (and thus also longer installation times), so unless there is no workaround for what you're trying to achieve, I would strongly discourage disabling it.

from bundletool.

You can set the property android.bundle.enableUncompressedNativeLibs=false in the gradle.properties. Would you mind sharing why this is causing you issue?

from bundletool.

You can set the property android.bundle.enableUncompressedNativeLibraries=false in the gradle.properties. Would you mind sharing why this is causing you issue?

@plecesne Thanks, but the correct property is android.bundle.enableUncompressedNativeLibs

We would like you to be aware that we couldn't use uncompressed native libs feature as we need to use the path of the .so files. For example, when we use pure data, a audio manipulating engine, we shall providing the native library path to its API for it to discover the custom externals that we built for it to consider in audio processing. So native library path is critical for our purposes. If we leave native libs uncompressed in apk, the path returned by ApplicationInfo.nativeLibraryDir does not contain native libraries anymore. So puredata engine wouldn't discover our custom externals.

Hope that makes sense. I wonder if there is a way to get valid native libraries path even if we keep native libs uncompressed in the apk.

from bundletool.

Ah, sorry about the name, I'll edit my comment in case somebody finds it later.

Loading the library using System.loadLibrary (in java) or in dlopen (in C++) should just work on Android, the platform will find the library even if it's uncompressed in the APK. So I guess it depends how this SDK loads the library you're giving it.

from bundletool.

Depending on non-Android SDKs may require you to leave APKs compressed indeed.

Note that the warning you see was removed in 3.6 canary 3.

from bundletool.

android {
packagingOptions {
jniLibs {
useLegacyPackaging = true
}
}
}
it works for me

from bundletool.

Hy @plecesne thanks for your info and suggestion.
seems I'll choose to read native libs from Apk directly. J

from bundletool.

@plecesne "There is a flag in Gradle to disable this feature" Could you give detail about this? I want to try disable it.

from bundletool.

I just want to have more free space to push some data into apk

from bundletool.

By compressing the native libraries, the APKs served to your users will be bigger! I explained this a bit better in #118

Although the App Bundle looks bigger and the APK files look bigger, the compression performed over the wire will be more efficient, leading to smaller downloads, and the size on device will be saved as well since the platform will not have to extract it at install time (which would result in two copies of the native libraries on device: one compressed in the APK, and one uncompressed in the installation directory).

Note also regarding size limits that the Play Console doesn't not validate the size based on the size of the App Bundle but based on the download size of the generated APKs, so compressing the native libraries doesn't gain you anything there either.

from bundletool.

Good to know that dlopen would work fine. Still there are libraries that need a lookup "path" to discover and load plugins/extensions in the form of .so files (like puredata mentioned above). This is typically the case with audio libraries. We used to supply them with the path provided by ApplicationInfo.nativeLibraryDir. As mentioned, this path is reported empty when native libs are uncompressed in the apk. Thus it doesn't work. So we could take advantage of this feature only if the platform provides a filesystem path that present native libs even though they still reside in apk.

Until then, android.bundle.enableUncompressedNativeLibs=false is critical for our purposes if we intend to use app bundle. We are glad to use app bundle as it reduced our app size by half! However, currently we get this warning (which is bit unsettling :--)

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

from bundletool.

you can use :
getContext().getApplicationInfo().nativeLibraryDir;
to fetch the actual native lib path if you want to use these libs like export the env with these so libs;

from bundletool.

android.bundle.enableUncompressedNativeLibs=false
It helped me a lot, I suffered a lot with this error

from bundletool.

I have tried with android.bundle.enableUncompressedNativeLibs=false, unfortunately it does not create lib/arm64 folder on release builds

from bundletool.