[GH-ISSUE #232] Play will reject the next release: adblock native libs are 4 KB aligned #213

New issue

Open

opened 2026-10-29 12:17:03 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-29 12:17:03 +00:00

Owner

Originally created by @dkodr on GitHub (Sep 11, 2026).
Original GitHub issue: https://github.com/cylonid/NativeAlphaForAndroid/issues/232

Google Play rejects apps targeting Android 15+ whose native code is not 16 KB
aligned since 1 November 2025, so the next release is blocked independently of
the target SDK bump. libadblock-client.so, shipped through
com.github.Edsuns.AdblockAndroid:ad-filter:v0.9.1, is 4 KB aligned in all four ABIs.

Android 17 already surfaces it at install time, naming the library and telling the
user to contact the developer ("This app is incompatible with 16 KB mode. ELF
compliance check failed"). Screenshot available if useful.

Evidence

LOAD alignment read out of the ELF program headers of a universal APK built from
current dev:

ABI	LOAD alignment
arm64-v8a	4096
armeabi-v7a	4096
x86	4096
x86_64	4096

16384 is required. Reproduce with:

unzip -o app.apk 'lib/*' -d out
$ANDROID_HOME/ndk/<version>/toolchains/llvm/prebuilt/<host>/bin/llvm-objdump -p \
  out/lib/arm64-v8a/libadblock-client.so | grep LOAD

Patching the headers is not a shortcut

Tools exist that rewrite p_align in place, and I checked whether that would be
enough here. It is not. ELF requires p_vaddr ≡ p_offset (mod p_align) for loadable
segments (elf(5)), and the second LOAD segment of every ABI breaks that
congruence at 16 KB — it is off by exactly 0x1000, the signature of a 4 KB layout:

ABI	`p_vaddr % 16K`	`p_offset % 16K`
arm64-v8a	0x1878	0x878
armeabi-v7a	0x27fc	0x17fc
x86	0x2bec	0x1bec
x86_64	0x39a8	0x29a8

Bumping p_align alone would produce a file that violates the spec. It would likely
pass a static scan while still being rejected by the loader on a real 16 KB device,
which is worse than the current state. The library has to be relinked.

Also worth noting: AGP 8.5.1+ only fixes zip alignment inside the archive, not the
alignment inside the .so, so a toolchain bump on this repo alone changes nothing here.

The fix, and where it has to land

The upstream library carries its own native sources (adblock-client/CMakeLists.txt),
so the change is one line — per the official guidance, either build with NDK r28+,
which aligns to 16 KB by default, or for r27 and lower add:

target_link_options(adblock-client PRIVATE
    "-Wl,-z,max-page-size=16384" "-Wl,-z,common-page-size=16384")

The catch is that it has to land in Edsuns/AdblockAndroid, which has had no commit
since August 2021 and currently has open issues reporting that JitPack can no longer
clone it. So the practical decision is yours and it is about the dependency, not about
this line: fork and publish, vendor the sources into this repo, or move to a different
engine.

Happy to prepare a PR for whichever route you pick — I did not open one because
pointing the dependency at a fork of mine is not something a maintainer should have to
accept unasked.

Filed separately from #231 because it is independent of the edge-to-edge work and
blocks the same release on its own.

Originally created by @dkodr on GitHub (Sep 11, 2026). Original GitHub issue: https://github.com/cylonid/NativeAlphaForAndroid/issues/232 Google Play [rejects apps targeting Android 15+ whose native code is not 16 KB aligned][1] since 1 November 2025, so the next release is blocked independently of the target SDK bump. `libadblock-client.so`, shipped through `com.github.Edsuns.AdblockAndroid:ad-filter:v0.9.1`, is 4 KB aligned in all four ABIs. Android 17 already surfaces it at install time, naming the library and telling the user to contact the developer ("This app is incompatible with 16 KB mode. ELF compliance check failed"). Screenshot available if useful. ## Evidence `LOAD` alignment read out of the ELF program headers of a universal APK built from current `dev`: | ABI | LOAD alignment | |---|---| | arm64-v8a | 4096 | | armeabi-v7a | 4096 | | x86 | 4096 | | x86_64 | 4096 | 16384 is required. Reproduce with: ``` unzip -o app.apk 'lib/*' -d out $ANDROID_HOME/ndk/<version>/toolchains/llvm/prebuilt/<host>/bin/llvm-objdump -p \ out/lib/arm64-v8a/libadblock-client.so | grep LOAD ``` ## Patching the headers is not a shortcut Tools exist that rewrite `p_align` in place, and I checked whether that would be enough here. It is not. ELF requires `p_vaddr ≡ p_offset (mod p_align)` for loadable segments ([elf(5)][2]), and the second `LOAD` segment of every ABI breaks that congruence at 16 KB — it is off by exactly 0x1000, the signature of a 4 KB layout: | ABI | `p_vaddr % 16K` | `p_offset % 16K` | |---|---|---| | arm64-v8a | 0x1878 | 0x878 | | armeabi-v7a | 0x27fc | 0x17fc | | x86 | 0x2bec | 0x1bec | | x86_64 | 0x39a8 | 0x29a8 | Bumping `p_align` alone would produce a file that violates the spec. It would likely pass a static scan while still being rejected by the loader on a real 16 KB device, which is worse than the current state. The library has to be relinked. Also worth noting: AGP 8.5.1+ only fixes zip alignment inside the archive, not the alignment inside the `.so`, so a toolchain bump on this repo alone changes nothing here. ## The fix, and where it has to land The upstream library carries its own native sources (`adblock-client/CMakeLists.txt`), so the change is one line — [per the official guidance][3], either build with NDK r28+, which aligns to 16 KB by default, or for r27 and lower add: ```cmake target_link_options(adblock-client PRIVATE "-Wl,-z,max-page-size=16384" "-Wl,-z,common-page-size=16384") ``` The catch is that it has to land in `Edsuns/AdblockAndroid`, which has had no commit since August 2021 and currently has open issues reporting that JitPack can no longer clone it. So the practical decision is yours and it is about the dependency, not about this line: fork and publish, vendor the sources into this repo, or move to a different engine. Happy to prepare a PR for whichever route you pick — I did not open one because pointing the dependency at a fork of mine is not something a maintainer should have to accept unasked. Filed separately from #231 because it is independent of the edge-to-edge work and blocks the same release on its own. [1]: https://android-developers.googleblog.com/2025/05/prepare-play-apps-for-devices-with-16kb-page-size.html [2]: https://man7.org/linux/man-pages/man5/elf.5.html [3]: https://developer.android.com/guide/practices/page-sizes#build