Google Play rejects for "16 KB page size" — LOAD segments are aligned, but PT_GNU_RELRO end is not


I'm hitting a wall with the 16 KB page size requirement on a Flutter app that uses a large closed-source SDK (Tuya/ThingClips IPC SDK) which ships prebuilt .so files.

Google Play Console rejects my release with "Your app does not support 16 KB memory page sizes."

I've already done everything the official docs say:

  • AGP 8.7.3, Gradle 8.9, NDK 27, build-tools 35.0.0

  • packagingOptions { jniLibs { useLegacyPackaging = false } }

By every official check, the app looks compliant:

  • AOSP check_elf_alignment.sh → "ELF Verification Successful" + zip-alignment successful

  • llvm-objdump -p libX.so | grep LOAD → align 2**14 (16 KB) on every lib

  • zipalign -c -P 16 → pass

So all LOAD segments are 16 KB aligned.

But Android Studio's APK Analyzer (and apparently Play's check) flags ~31 libraries with:

> RELRO is not a suffix and its end is not 16 KB aligned

When I check with llvm-readelf -lW, the PT_GNU_RELRO segment's end (VirtAddr + MemSiz) is not a multiple of 16,384, even though PT_LOAD align is 0x4000. Example libs: libThingCameraSDK.so, libavcodec.so, libopenh264.so, libreactnativejni.so, libv8android.so, libsqlcipher.so, etc.

I've tried/ruled out:

  • AGP/NDK/build-tools upgrade → only affects LOAD + zip, not RELRO

  • patchelf / objcopy → can change header fields but can't insert RELRO padding

  • android-16kb-fix (the popular drop-in script) → only patches PT_LOAD p_align, not RELRO

  • Compressed libs (useLegacyPackaging=true) → doesn't bypass the requirement

My understanding is that RELRO end-padding is added at link time (LLD 18+ / NDK r28+), so prebuilt .so linked with an old toolchain can't be fixed without re-linking — which only the SDK vendor can do.

My questions:

  1. Has anyone actually had Play accept a build where LOAD is aligned but PT_GNU_RELRO end isn't? Is RELRO a genuine hard-block now, or is something else triggering the rejection?

  2. Is there any way to fix the RELRO segment of a prebuilt .so locally (some tool that re-pads + fixes offsets), or is vendor re-linking the only path?

  3. For those who depend on a vendor SDK that hasn't shipped 16 KB-RELRO-aligned libs yet — what did you do to ship?

1
Jun 11 at 8:12 AM
User AvatarHannan Sani
#android#google-play#tuya#16kb-page-size

No answer found for this question yet.