Your Android image compressor might crash on Android 15 — so I built a pure-JVM one

Android 15 quietly changed the rules for native code. Since November 2025, apps targeting API 35 on
Google Play must support 16 KB memory pages, and every bundled .so has to be 16 KB-aligned —
including the ones inside your third-party libraries. An unaligned native lib doesn't warn; it
crashes on 16 KB-page devices.

That sent me looking at how my apps compress images. The most popular option, Luban 2, is
excellent — but it ships libjpeg-turbo, a native encoder. The original Luban and its fork
AdvancedLuban were pure-JVM… and abandoned.

So I revived that lineage as PixelDiet: a pure-JVM, zero-native Android image compressor.

What "pure-JVM" buys you

• No .so → no 16 KB page-size risk. Nothing to align, no NDK, no per-ABI builds.
• Tiny footprint. The release AAR is ~44 KB.
• Honest guarantee. A CI step unzips the AAR and fails the build if it ever contains a .so. The claim is enforced, not promised.

The trade-off, stated plainly: you give up libjpeg-turbo's raw encode speed. In exchange you get a
dependency that can't break on a platform page-size change and won't bloat your APK.

What I kept, and what I modernized

The valuable part of Luban is its WeChat-Moments-style "gear" sizing strategy — I ported that
math faithfully (and unit-tested it). Around it, everything is new:

• Kotlin coroutines core: suspend get(), getFirst(), and asFlow() for progress.
• Java-friendly OnCompressListener path backed by Dispatchers.IO — no RxJava.
• Scoped-storage safe inputs: File, content:// Uri, InputStream, Bitmap.
• androidx ExifInterface orientation handling read from streams.
• WebP lossy/lossless output (smaller than JPEG), plus JPEG/PNG.

val out = PixelDiet.with(context)
    .load(uri)
    .format(OutputFormat.WEBP_LOSSY)
    .getFirst()

The feature Luban 2 removed

Luban 2 dropped setMaxSize. If your code relied on "compress to under N KB," upgrading silently
breaks it. PixelDiet brings it back as hardCap(kb) — and makes it a real guarantee with a
two-phase quality-loop + resize-fallback, so the output is actually ≤ your target on any gear:

PixelDiet.with(context).load(uri).hardCap(200).getFirst()  // ≤ 200 KB, guaranteed

Does it actually compress?

From the sample app: an 863 KB photo → 78 KB (−91%) in ~223 ms (Custom gear → PNG). With Smart
gear + WebP + a 300 KB cap: 863 KB → 250.8 KB (−71%).

The part nobody writes about: licensing

PixelDiet is a fork, and I'm explicit about that. Luban and AdvancedLuban are Apache-2.0, which
permits forking, renaming, and redistribution — but it has conditions: keep the original copyright
headers, ship LICENSE + a NOTICE stating your changes, and don't imply endorsement. The
compression strategy is Curzibn's and shaohui's work; my contribution is the modern API, the
scoped-storage/EXIF fixes, the native-free guarantee, and ongoing maintenance. Presenting that
honestly is both the legal requirement and the more credible story.

Try it

JitPack:

implementation("com.github.basheerpaliyathu.PixelDiet:pixeldiet:0.1.0")

Code, sample app, and the full comparison table: https://github.com/basheerpaliyathu/PixelDiet

If you maintain an Android app targeting API 35, it's worth auditing your dependencies for bundled
.so files this week. You might be one transitive dependency away from a 16 KB crash.