Android Question B4XGifView and 16kb alignment thread

[EduardoElias]

Update: I updated the B4A IDE itself (previously on 14.00) hoping it would fix the zip-level packaging, but the issue persists exactly the same way.


To recap: after updating B4XGifView (removed the old 1.2.20.androidx version that caused a dex duplicate-class conflict, kept only 1.2.29), readelf -l confirms the library’s own ELF LOAD segments are correctly aligned to 16 KB:



libpl_droidsonroids_gif.so (arm64-v8a and x86_64):
LOAD ... R E 0x4000
LOAD ... RW 0x4000

So the library itself is fine. But Play Console’s App Bundle Explorer still reports “Does not support 16 KB”:

“Uncompressed native libraries are not zip aligned for 16 KB within your app. To fix this, correct your Android Gradle Plugin configuration.”

I inspected the generated .aab directly with Python’s zipfile module — even after updating B4A — and the four .so entries (one per ABI) are still stored with compress_type=8 (DEFLATE/compressed), not STORED (uncompressed). AndroidManifest.xml has no android:extractNativeLibs attribute set either way.


Since updating both the library and the IDE didn’t change this, it really looks like B4A’s AAB builder doesn’t yet pack native libraries uncompressed and 16 KB zip-aligned — which is what the new Play Store requirement (and Google’s AGP 8.5.1+ guidance) expects. Is this a known limitation, and is there a setting (manifest attribute, project setting) to force uncompressed/aligned native libs in the generated AAB, or does this still need to be added to B4A’s build process?

 

[Erel]

Is this a warning? An error? There are many B4A apps with B4XGifView in Google Play.

If you think that the SO compression is causing problems then you can exclude *.so files by putting this file in the project folder (same folder as the b4a file) and adding the so extension.

 

[EduardoElias]

Is this a warning? An error? There are many B4A apps with B4XGifView in Google Play.

If you think that the SO compression is causing problems then you can exclude *.so files by putting this file in the project folder (same folder as the b4a file) and adding the so extension.

Hi Erel,


Following up on your suggestion to exclude .so files from compression using a bundleconfig.json file — I tried this and wanted to report that it did not change anything, even after placing it correctly and restarting the IDE. Sharing full details in case this helps pinpoint what’s going on, or in case I’m missing something.


Setup:

• B4A version: 14.20
• Project: DashenPDV, VersionCode 2 / VersionName 1.0.198
• Library involved: B4XGifView (android-gif-drawable), already updated to the latest version
• Build type: standard “Release” / AAB build from inside the B4A IDE (not B4ABuilder.exe)

Background:
The original Play Console error was about ELF alignment on libpl_droidsonroids_gif.so (the classic “16 KB native library alignment” issue). I fixed that already — confirmed via readelf -l that all LOAD segments on arm64-v8a and x86_64 are now aligned to 0x4000 (16 KB), after updating the library.


After that fix, a different, more generic Play Console error appeared during the release review step:


“As bibliotecas nativas descompactadas não estão de acordo com os 16 KB para arquivos zip no app. Para resolver isso, corrija a configuração do Plug-in do Android para Gradle.”
(English: “Uncompressed native libraries are not zip aligned for 16 KB within your app. To fix this, correct your Android Gradle Plugin configuration.”)


This is a separate, zip-container-level check: it’s not about the ELF alignment anymore, but about whether the .so files are stored uncompressed (and 16 KB-aligned) inside the .aab zip itself. I verified this directly with Python’s zipfile module on the generated .aab: all 4 .so entries (arm64-v8a, armeabi-v7a, x86, x86_64) consistently show compress_type=8 (DEFLATE/compressed), never compress_type=0 (STORED), across every build I’ve generated so far.


What I tried, in order, with no change to this symptom:

1. Updated the B4XGifView/android-gif-drawable library to the latest AAR — this fixed the ELF alignment issue, but the zip-compression issue appeared right after, unrelated to this update.
2. Updated the B4A IDE (applied the system file update you mentioned in another thread) — recompiled, same compress_type=8 result.
3. Created bundleconfig.json per your suggestion. First attempt: I placed it in the B4A installation folder (C:\Program Files\Anywhere Software\B4A), but it turned out to be just the stock default content (media extensions list) without .so added — so no change was expected there, understandably.
4. Second attempt: placed bundleconfig.json in the project folder itself (same folder as the .b4a file), with this content:

json
{
"optimizations": {
"uncompressNativeLibraries": {
"enabled": true
}
},
"compression": {
"uncompressedGlob": [
"**/*.3g2", "**/*.3gp", "**/*.3gpp", "**/*.3gpp2", "**/*.aac", "**/*.amr",
"**/*.awb", "**/*.gif", "**/*.imy", "**/*.jet", "**/*.jpeg", "**/*.jpg",
"**/*.m4a", "**/*.m4v", "**/*.mid", "**/*.midi", "**/*.mkv", "**/*.mp2",
"**/*.mp3", "**/*.mp4", "**/*.mpeg", "**/*.mpg", "**/*.ogg", "**/*.png",
"**/*.rtttl", "**/*.smf", "**/*.wav", "**/*.webm", "**/*.wma", "**/*.wmv",
"**/*.xmf", "**/*.so"
]
}
}

1. Fully closed and reopened the B4A IDE (in case the config is only read at startup), then recompiled.

Result after all of this: identical .so compression (compress_type=8) in the newly generated AAB. No change whatsoever, even though the changelog for v11.2 says this file “can be overridden by putting such file in the project folder.”


Questions:

1. Does bundleconfig.json in the project folder actually get consulted by the normal IDE compile/build-AAB flow, or is it only used by B4ABuilder.exe (the separate command-line tool)? I noticed both files live in the same installation folder, and wondered if that’s the actual scope of this setting.
2. If it does apply to the IDE build, is there a different expected file name, location, or JSON structure than what I used above?
3. Is this zip-compression-level 16 KB check actually a hard blocker for submitting to the Play Store, or just a non-blocking warning? You mentioned earlier that many B4A apps using B4XGifView are already live on the Play Store, which made me wonder if this specific message might not actually prevent release submission.

Any guidance would be greatly appreciated — happy to share the full AAB/zipfile inspection output if useful.


Thanks!

 

[Erel]

1. Yes. In both cases. You can also change the bundleconfig.json in the installation folder (which usually requires an admin privileges).
2. Your change looks correct.
3. As far as I remember, you are the first one to encounter this warning and no one excluded it from the compression. So I'm not yet sure what caused it. If it is just a warning then ignore it for now.