Delete the 16 KB plugin, state the API floor, release 1.4.0

[adulbrich]

Closes #255.

The plugin goes

plugins/withAndroid16KBSupport.js never affected 16 KB page support. The gradle property its filter removed — android.bundle.enableUncompressedNativeLibs — is absent from the Expo template on both SDK 54, where the plugin was written, and SDK 57. So the filter removed nothing, and the plugin's only net effect was adding android.enableJetifier=true, a Support Library rewriting flag unrelated to page size.

Measured on both artifacts before deleting — debug APK and release AAB, each built with and without it:

same set of libraries      : True
libraries differing         : 0     (of 100)
BundleConfig.pb identical   : True

Both control builds also succeeded without Jetifier, so nothing in the dependency tree needed it.

The app is 16 KB ready and stays that way: every 64-bit .so links with PT_LOAD alignment 16384, and the bundle manifest carries extractNativeLibs="false" so those libraries are mapped rather than extracted.

The API floor becomes explicit

@adulbrich recalled this originated in a Play Console notice, which turned out to be the key to the whole thing. What answered that notice was the compileSdkVersion / targetSdkVersion / buildToolsVersion 35 bump in the same commit (9d3668a) — build against API 35 and AGP and the NDK do the alignment for you. The plugin rode along.

Those pins were then dropped in 5c24c26, and compliance survived only because Expo's own default had moved past 35 by then. Nothing in the repo said the requirement existed, so anything setting a lower compileSdkVersion would have dropped 16 KB support with no signal — and the plugin would not have caught it, having never touched page size.

expo-build-properties now pins compileSdkVersion and targetSdkVersion at 36, which is what Expo SDK 57 already resolves to. Verified by prebuild: the generated project is unchanged apart from Jetifier going away.

__tests__/androidSdkFloor.test.ts is what notices if either slips below 35. Confirmed it fails when they do:

✕ pins compileSdkVersion at or above the level 16 KB page support needs

Raising the pins on an SDK upgrade is expected. Lowering them is the thing that must not pass quietly.

Version 1.4.0

package.json and app.json both go to 1.4.0; they are kept in step by hand. eas.json sets appVersionSource: "remote" with autoIncrement, so EAS owns versionCode — the last store build was versionCode 12 / 1.3.0.

1.4.0 rather than 1.3.1 because this is not only fixes. Reconciling the two export formats changed the CSV's birth_control.*.notes column from Time Taken: X Notes: Y to Time: X, Notes: Y, and a patch release would imply there is nothing to notice. Everything else since 1.3.0 is internal work plus nine user-visible defect fixes — stale calendar filters, the day-tap prediction refresh, the flow ring's timezone window, pregnancy weeks past full term, the notes marker, CSV quote escaping, PDF month ordering on non-English locales, and the first-launch migration race.

Verification

npm test, npm run typecheck, npm run lint all pass. 407 tests.

Not smoke-tested on a device for this change: the plugin's removal is covered by the two artifact comparisons above, and the SDK pins were verified through prebuild rather than inferred. If you are publishing from this, a release build through EAS is the real check.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
ephira	Ready	Preview	Aug 21, 2026 8:43pm