16 KB Page Size and SDK 35/36: Android Platform Changes at Fulldive

Written by the Fulldive product engineering team, based on direct inspection of the repositories listed below.

If you maintain Android apps, 2025 was the year of three overlapping platform changes: 16 KB memory page alignment for native libraries, a bumped target API requirement for Google Play, and the usual Android Gradle Plugin / Gradle upgrade cycle that rides along with them. This post explains what each change was, why it mattered, and how Fulldive’s apps absorbed them across multiple repositories in the same window.

We write this up because the same pattern hit most of the Fulldive apps catalog at once — and because, read together, the commits show what an ecosystem-wide Android modernization sprint actually looks like.

What the three changes are

16 KB page size. Historically, Android ran on devices whose Linux kernels used 4 KB memory pages. In 2024-2025, Google moved toward supporting 16 KB page sizes on newer devices, and required that apps using native libraries align those libraries to 16 KB so they can be loaded by processes on a 16 KB-page kernel. Apps that do not meet this requirement can crash on 16 KB devices and, starting in late 2025, fail Play Store compatibility expectations. The canonical reference is Android Developers — Support 16 KB page sizes.

Target SDK 35, then 36. Google Play requires apps to target a recent Android API level. New apps and updates must target a minimum level that steps forward each year; Android 15 (API 35) and Android 16 (API 36) were the relevant targets during 2025. The current policy is documented at Android Developers — Meet Google Play’s target API level requirements.

AGP and Gradle. Each Android target SDK bump tends to require a matching Android Gradle Plugin upgrade, a newer Gradle, and often newer Kotlin. Skipping this cycle is not optional.

None of these were surprises. The problem was coordination across a catalog of separately-released apps.

Repository evidence, app by app

Wize AdBlock VPN (`fulldiveVR/FulldiveExtension.AdShield`)

This app is the clearest trace of the sprint because it ships as both a regular Android app and a local VPN service, so both app code and native dependencies had to align.

ead5d3b1 — 16 KB library alignment, October 2025. Native library packaging was updated to meet the Android 16 KB requirement.
585b28e8 — AGP / Gradle update in the same window, necessary to produce a build that respects the alignment.
886a3f2c — graceful VPN teardown, shipped alongside the build work so that the new runtime behavior did not leak sessions when the VPN restarted.
57dcd6a6 — Gradle plugin upgrade in November 2025.
b8315876 — target SDK 36 bump.
7a6c12d9 — version 1.0.17 shipped after the modernization stack was green.

The combination is the point: alignment alone is not enough; toolchain and VPN lifecycle code had to move together. More in Cold-start and DNS lifecycle bugs in a VPN ad blocker.

DataGuard No Root Firewall (`fulldiveVR/FulldveExtension.DataGuard`)

DataGuard runs as a local-VPN firewall, so native code paths are central to the app. The 2025 commits show the same pattern:

2821d5e0 — SDK 35 preparation, done ahead of the Play Store deadline.
b2af3518 — 16 KB alignment for the DataGuard build.
cdc04c9f — version 2.334 release once the platform upgrades were green.
f008c1b2 — app-name consistency and Gradle/Kotlin updates that tidied up the release pipeline.

DataGuard also contains 4165205e from 2023 for Android 13 notification permissions — a reminder that “modernization sprint” is not new. See A Decade of DataGuard: Android maintenance for more context on what no-root firewalls have to track.

One Emulator (`FulldiveExtension.FullRoid`)

The emulator is mostly Kotlin and Compose, but it bundles emulation cores as native code, which makes 16 KB alignment relevant. In November 2025:

acf79d78 — target SDK bump.
be65800d — bumped cores, some of which had their own 16 KB-related work upstream.
f71aade4 — deprecated desmume and lazily migrated saves to melonDS, which is tangential to the platform sprint but landed in the same push because we were already touching the native core surface.

For product context on the emulator work beyond the platform bumps, see Controllers for an Android emulator and Save states vs in-game saves on Android emulators.

Other repositories

WizeUp / FD Browser (fulldive-android-apps): most of the browser’s 2025-2026 work was product (feeds, trends, AI chat, wizeup:// deep links) rather than platform, but ANR reduction in 3166bfe28f is partially related — app startup cost is a first-class concern once you are also absorbing a toolchain upgrade. More in Reducing ANRs and cold start in the browser.
WizeSMS (DiveSMS): 2025-11 reliability fixes (68ecf707, 5895a312, 3838a63b, 0f382e4a) landed in the same window. Ensuring an SMS app still works across a target SDK change is its own small project because default-SMS behavior and SMS/MMS APIs are unusually sensitive to Android version changes. See Default SMS app on Android.
Fulldive VR (fulldive-unity): the Unity app had its own migration track (Unity version upgrade in 2024, dfc07c05) that partly answered the same questions by moving the engine forward. Rebuilding Fulldive VR: the Unity migration tells that side of the story.

Why do this across a whole catalog in one window

Three reasons, all of which fell out of the “many small apps” decision we wrote about in Why Fulldive ships small apps, not one mega app:

Play Store deadlines do not negotiate per app. If a target SDK deadline is set for August 31, every app on the account has to meet it, or it stops accepting updates. There is no staggered path.
Shared infrastructure rewards batch work. Our AGP, Gradle, and Kotlin versions are not fully shared across repos, but they move in the same direction. Doing the upgrade once and then porting the same patch shape into each repo is cheaper than doing each one cold.
User-visible regressions have to be caught in each app. A 16 KB alignment bug in an emulator looks like a core that refuses to load. In DataGuard, it looks like a VPN that cannot start on a new Pixel. In AdBlock VPN, it looks like DNS never coming up. We needed separate smoke tests per app, not one shared one.

What did not change, and what we did not do

A few things to flag, because “modernization sprint” sometimes reads as “we rewrote everything”:

We did not rewrite native code that was not ours. Emulation cores, VPN tunnel libraries, and SMS/MMS libraries that Fulldive depends on were updated by bumping upstream versions, not by rewriting them. Core bumps (be65800d) are doing that work.
We did not flip to a new architecture to satisfy platform changes. Compose migration in One Emulator (def0215f, 47c9c8c3) was a separate track that happened to overlap in time; it was not done because of 16 KB or SDK 36.
We did not use this window to change privacy behavior. Ad blocking, DNS filtering, firewall, SMS forwarding, and cleaner behavior were held steady across the platform upgrades. Platform work should not quietly shift product behavior.

Limits and caveats

Commit hashes above are abbreviated and tied to the repository state inspected on 2026-04-13. Upstream projects sometimes rewrite history, so if a specific SHA does not resolve, look for the neighbors in the same date range. Some Gradle files in the repositories still show upstream package IDs rather than Fulldive’s release IDs — we flagged this in the internal brief and will reconcile them before publishing any version-specific claim. Finally, 16 KB alignment is an Android and Play Store concern; this post does not cover iOS or macOS changes, which show up in AdBlock VPN’s separate iOS/macOS branch (d9a99dec for macOS private DNS detection, 98671f41 for iOS development run targets). Those are documented in macOS private DNS and iOS targets for Wize AdBlock.

External references: Android Developers — Support 16 KB page sizes and Android Developers — target API level requirements.

Last updated: 2026-04-16. Commit hashes and version numbers are drawn from Fulldive repositories inspected on 2026-04-13.