Methodology

Everything on this site is measured from real published files, not copied from release notes or written by a model. 80 libraries have a published page; the full method is also documented in the kit's own README.md for anyone who buys it and wants to rebuild the dataset themselves.

How a library gets measured

1. Maven coordinates are listed by hand (Maven Central, Google Maven, plus the Flutter engine jars on download.flutter.io) — all public, unauthenticated file downloads.
2. Every published version is listed, then up to ~24 are sampled (first/last 8 plus evenly spaced), with a bisection step wherever the measured verdict changes between neighbouring versions, so the fix boundary isn't guessed.
3. Each candidate AAR/JAR is downloaded, every arm64-v8a/x86_64 .so inside it is read directly as an ELF file, the minimum PT_LOAD segment alignment (p_align) is recorded, then the download is deleted. 16 KB-compatible needs p_align >= 16384 (2^14).
4. The newest stable and newest overall release of every artifact is always measured, plus every stable version between the highest offending and lowest aligned one, so the first-aligned version isn't a sampling gap.
5. POM-only relocation stubs (an old coordinate pointing at a new one) and artifacts whose newest release ships no native code are detected and labelled, not silently marked "fixed".

Independent spot-checks

After the dataset is built, a random sample of entries (6-8 each, different random seeds) is re-measured independently as a sanity check, recorded in spotcheck-2026-10-01.json, spotcheck-2026-10-01b.json in the kit. The checker was also cross-checked once against objdump -p on two known Flutter engine builds (3.13.9, 4 KB-aligned; 3.16.0, 16 KB-aligned) to confirm it agrees with an independent tool.

What this does and doesn't tell you

• Sampled, not exhaustive. "Offending versions" lists only measured versions; unmeasured versions in between are unknown. A non-monotone history (an aligned release followed by a later offending one, from parallel release lines or backports) means a higher version number alone doesn't guarantee alignment — each page flags this when it applies.
• Artifact-level, not app-level. Only the artifact itself is measured; a transitive native dependency it pulls in is a separate entry. AAR-level ELF alignment is not the same as your final APK/AAB passing Play's own check (AGP >= 8.5.1 / zipalign handles APK zip alignment separately).
• Not checked: RELRO and other linker details, and your own native code's build flags (use NDK r28+ or -Wl,-z,max-page-size=16384).
• Dates shown per library are the repository file's last-modified time, not the vendor's official release date.

Always run the free checker on your own final build — that's the only check that reflects your exact dependency resolution. Dataset last regenerated 2026-10-01.