Google Play Target API 36 and 16 KB Page Size: What Blocks Uploads

Two build requirements decide whether Google Play will take your next upload. Since August 31, 2026, new apps and app updates must target Android 16 (API level 36) to be submitted to Google Play, with an extension to November 1, 2026 available on request. Separately, apps targeting Android 15 or higher must support 16 KB memory pages on 64-bit devices, and starting February 1, 2027, Google says updates without that support can’t be released. The first rule hits everyone. The second only matters if your app ships native code, which includes a lot of apps whose developers never wrote a line of C++.

This post covers both: who’s affected, how to check a build, and what to change. If you’re working through a whole launch, the Google Play publishing checklist tracks both items alongside the store listing, App content declarations, and signing.

Requirement 1: target API level 36

Google’s target API level requirements page sets the current rules for phone and tablet apps:

Who	Rule	Date
New apps	Must target Android 16 (API 36) or higher to be submitted	August 31, 2026
App updates	Must target Android 16 (API 36) or higher to be submitted	August 31, 2026
Existing apps you don’t update	Must target Android 15 (API 35) or higher to stay available to new users	Current requirement

Other form factors have their own targets on the same page:

Form factor	New apps and updates must target
Wear OS	API 35 or higher (from August 31, 2026)
Android Automotive OS	API 35 or higher (from August 31, 2026)
Android TV	API 34 or higher (from August 31, 2025)
Android XR	API 34 or higher (from August 31, 2026)

Permanently private apps, restricted to users in one organization for internal distribution, are exempt.

The extension

If you need more time, Google says you can request an extension to November 1, 2026. The form lives on the details page of the warning or issue on the Policy status page in Play Console, and affected apps get a link through their Play Console notifications. It’s an extension, not an exemption. Plan to ship an API 36 build before November.

What happens to apps you stop updating

Nothing gets deleted. An existing app that targets API 34 or lower “will only be available on devices running Android OS that are the same or lower than your apps’ target API level.” So an app targeting API 33 can still be found by new users on Android 13 phones, but not on a phone running Android 14 or later. People who already installed it keep it: Google says existing users can still discover, reinstall, and use the app.

That’s a slow loss of reach rather than a hard stop, and it’s easy to miss because your current user count doesn’t change. The hard stop comes the day you try to ship a bug fix and the upload is refused for targeting an old API level.

Bumping targetSdk

The change itself is one line in your module’s build.gradle(.kts):

android {
    compileSdk = 36
    defaultConfig {
        targetSdk = 36
    }
}

The work is in what changes at runtime. Each target level opts your app into that Android version’s behavior changes, so read Android’s behavior-change notes for every level you’re skipping over, not just 36. Test on a device or emulator running Android 16 before you upload. Your SDK dependencies matter too: an old ads or analytics SDK can break under new behavior even if your own code is fine.

Requirement 2: 16 KB memory page size

Android has used 4 KB memory pages for most of its history. Newer devices can run with 16 KB pages, and code that assumes 4 KB can crash or fail to load on them.

Google’s 16 KB page size guide states the Play rule like this: “all apps targeting Android 15 (API level 35) and higher must support 16 KB memory page sizes on 64-bit devices on Google Play. Starting February 1, 2027, if your app updates don’t support 16 KB memory page sizes, you won’t be able to release these updates.”

The deadline has moved

When Google announced the requirement in May 2025, the date was November 1, 2025, for “all new apps and updates to existing apps” targeting Android 15+. The current guide gives February 1, 2027 and talks only about updates. It doesn’t give a separate date for new apps.

Google doesn’t explain the gap, so don’t read the silence as permission. The Play Console technical quality requirements page lists “Apps that contain native code must support devices with 16 KB memory page sizes” as a current requirement and says “Not meeting a requirement can affect an app’s visibility and publishing capabilities on Google Play.” Since every new app now has to target API 36, every new app is in scope. Ship 16 KB-aligned builds now and the date stops mattering.

The same page lists earlier dates for other form factors: 64-bit and 16 KB support on Android TV “Required as of 1 Aug, 2026” and on Wear OS “Required as of 15 Sep, 2026.”

Are you affected?

Per Google’s guide: “If your app only uses code written in the Java programming language or in Kotlin, including all libraries or SDKs, then your app already supports 16 KB devices.”

You’re affected if any of these are true:

• Your app has C or C++ code built with the NDK.
• Your app links any third-party native library or SDK. Game engines, media and image libraries, database wrappers, crypto, ML runtimes, and some ad and analytics SDKs can ship .so files.
• Your app is built by a third-party app builder that uses native libraries on the device.
• Your app is built with a cross-platform framework. Flutter, React Native, and Unity all ship native libraries in every Android build.

The quick test: if your APK or bundle has a lib/ folder with .so files in it, you have native code.

How to check a build

Use more than one of these. Each one catches different problems.

Tool	Command or location	What a pass looks like
APK Analyzer (Android Studio)	Build > Analyze APK, open the lib folder	No warnings in the Alignment column
check_elf_alignment.sh	check_elf_alignment.sh APK_NAME.apk	Every arm64-v8a and x86_64 library prints ALIGNED
llvm-objdump	llvm-objdump -p libfoo.so | grep LOAD	LOAD segments show align 2**14
zipalign (build-tools 35.0.0+)	zipalign -c -P 16 -v 4 APK_NAME.apk	Last line says “Verification successful”
bundletool	bundletool dump config --bundle=app.aab | grep alignment	PAGE_ALIGNMENT_16K
Lint	Android Studio lint run	No native-library alignment warnings
Play Console	App bundle explorer for the uploaded bundle	No 16 KB compliance issue

A few notes on these:

• check_elf_alignment.sh doesn’t ship with Android Studio. Google links to it in AOSP at system/extras/tools/ on cs.android.com. It runs on Linux and macOS.
• There are two separate things to check. ELF alignment (objdump, the script) is about how each .so was linked. Zip alignment (zipalign, bundletool) is about how uncompressed .so files sit inside the APK. You need both.
• Google’s announcement post says the app bundle explorer page in Play Console lets you check build compliance and suggests where to update. Upload to an internal testing track first and look there before you push anything wider.

Test on a real 16 KB system

Alignment checks catch build problems, not code that hard-codes a 4 KB page. To test at runtime, Google’s guide offers:

• The 16 KB page size emulator system images (ARM 64 or x86_64, Android 15 or higher) from the SDK Manager.
• The Boot with 16KB page size developer option on certain Pixels: Pixel 8, 8 Pro and 8a (Android 15 QPR1 or later), Pixel 9, 9 Pro and 9 Pro XL (Android 15 QPR2 or later), and Pixel 9a (Android 16 or later).

Confirm the mode with adb shell getconf PAGE_SIZE. It should return 16384.

How to fix it

1. Upgrade the Android Gradle Plugin to 8.5.1 or higher

Google says devices with 16 KB pages “require apps that ship with uncompressed shared libraries to align them on a 16 KB zip-aligned boundary,” and that this takes AGP 8.5.1 or higher. This fixes zip alignment for you.

If you truly can’t upgrade, Google’s fallback is to ship compressed native libraries with useLegacyPackaging = true under packagingOptions { jniLibs { } }. It warns this increases installed size, so treat it as a stopgap. On AGP 8.0 or lower you also need android.bundle.enableUncompressedNativeLibs=false in gradle.properties.

2. Build native code with NDK r28 or higher

Google’s guide: “NDK version r28 and higher compile 16 KB-aligned by default.” If you’re stuck on r27 or lower, add the linker flags yourself:

target_link_options(${CMAKE_PROJECT_NAME} PRIVATE
    "-Wl,-z,max-page-size=16384"
    "-Wl,-z,common-page-size=16384")

For ndk-build, the same flags go in LOCAL_LDFLAGS.

3. Replace hard-coded page sizes

Search your native code for PAGE_SIZE, 4096, and any mmap() call that assumes 4 KB offsets. Google says to use getpagesize() or sysconf(_SC_PAGESIZE) instead, and notes that PAGE_SIZE is undefined in 16 KB mode on NDK r27 and higher, so some of this shows up as compile errors.

4. Update or rebuild every third-party .so

This is where most apps get stuck. Your own code can be perfect while one old SDK ships a 4 KB-aligned library. Run check_elf_alignment.sh and look at which file names come back UNALIGNED, then match each to its dependency. Google’s advice is to check each SDK provider for a 16 KB-compatible version, and to recompile any prebuilt libraries you own with the flags above. If a vendor hasn’t shipped a fix, you need to replace that dependency before the deadline.

Android also has a 16 KB backcompat mode that lets some 4 KB-aligned apps run on 16 KB devices, controlled by android:pageSizeCompat in the manifest. Google says it “allows some apps to work, but for best reliability and stability, apps should still be 16 KB aligned.” It doesn’t change what Play requires.

Framework notes

Only versions stated in each project’s own docs or release notes are listed here. Whatever framework you use, the plugins and packages you add still need checking on their own.

Framework	What its own docs say
React Native	The 0.77 release post says “With the 0.77 release, React Native is ready to fully support 16 KB page size.” Upgrade to 0.77 or later, then check native modules.
Flutter	The Flutter 3.38 release post says it “updates the default Android ndkVersion to NDK r28,” which it calls “the minimum required for native code to achieve the proper alignment for 16 KB support.” If your build.gradle pins an older ndkVersion, remove or raise it. Plugins with native code need their own updates.
Unity	Unity’s Unity 6 Android requirements page says to update to 6000.0.38f1 or later, update native plug-ins, rebuild, and resubmit. The Editor warns during the build if a plug-in has a 4 KB-aligned .so. Android’s Unity page says 16 KB support exists for Unity 2021, 2022, and Unity 6; check Unity’s notes for the exact patch on older versions.

For Flutter and React Native, also set the target SDK to 36 in your Android build files and confirm it in the merged manifest. A framework default that looks like 36 isn’t proof until you check the build output.

A pre-upload checklist

1. targetSdk = 36 and compileSdk = 36, tested on Android 16.
2. AGP 8.5.1 or higher.
3. NDK r28 or higher, or the two linker flags on older NDKs.
4. check_elf_alignment.sh shows every arm64-v8a and x86_64 library ALIGNED.
5. zipalign -c -P 16 -v 4 passes on a universal APK, or bundletool shows PAGE_ALIGNMENT_16K.
6. App launches and runs core flows with getconf PAGE_SIZE returning 16384.
7. Upload to internal testing first and check the app bundle explorer before promoting.

If you’re on a new personal account, fix both before you start the 12-tester closed test. The bundle your testers run should be the one you promote, and rebuilding for a toolchain upgrade mid-test means asking testers to update to an untested build. And while you’re in the build config, make sure you know where your upload keystore lives. Our upload key vs app signing key guide covers what to do if it’s lost.

The Google Play publishing checklist includes both items in its build step, with links to the Google pages these rules come from.