In this article

Find the incompatible native binary and the dependency that supplies it before changing your Android build settings. A Flutter plugin can bring native libraries into an app even when your own application code is Dart.

As checked on October 8, 2026, Android’s 16 KB compatibility guide says Play updates targeting Android 15/API 35 or higher must support 16 KB pages on 64-bit devices, with updates blocked from February 1, 2027 if unsupported. Older deadline summaries can differ. Verify the current guide and your Console warning for the exact requirement.

Begin with the artifact that received the warning#

Record its package, build number, build configuration and file checksum. Keep the warning text. Do not inspect an unrelated local debug APK and assume it represents the uploaded bundle.

The practical evidence chain is:

text
warning → uploaded build → native library path → dependency owner
        → supported replacement/rebuild → new artifact → verification

This chain is an editorial diagnostic method. It prevents a generic “upgrade everything” response from hiding which change fixed the problem.

Inventory the native libraries#

Use the guide’s APK Analyzer instructions or documented tooling to list native .so files and architectures. Record the exact filename and ABI for each reported incompatibility.

For each library, identify whether it comes from Flutter, an owned native component or a third-party SDK. A plugin package can wrap a native dependency maintained elsewhere, so the Dart package name alone may not identify the binary owner.

A hypothetical ledger entry might be: libexample.so, ARM64, plugin A, native SDK B, resolved version C. Those names are placeholders. Your real entry should point to the dependency version actually packaged.

Separate the compatibility checks#

Android’s guide distinguishes ELF alignment, package alignment and runtime issues. Passing one check is not proof of passing the others. Follow its tooling instructions, including the relevant RELRO checks where applicable, rather than inventing an alignment test from file size.

Keep the exact command/tool version and output in your private build record. The guide provides platform-specific commands; select those for your installed SDK/NDK and artifact. Do not paste an example path as if it were your machine’s actual tool location.

Fix the owner, not the symptom#

For a prebuilt vendor library, check the vendor’s compatible release. Changing your app’s NDK setting does not necessarily rebuild a binary distributed precompiled by that vendor.

For native code you own, follow Android’s current build guidance and rebuild it. For a transitive dependency, confirm that the chosen plugin release resolves to the intended native SDK.

Changing minSdk alone is not evidence that binary compatibility changed. Record a before/after library inventory and repeat the check on the rebuilt artifact.

Verify a relevant runtime path#

Use a documented 16 KB test environment, confirm its page-size configuration and exercise the feature that loads the affected library. A home-screen smoke test may never load a camera, map or media library that fails later.

Do not rely on a successful check of one ABI to infer every shipped ABI passed. Keep the tested artifact identity alongside the checks and known limitations.

If the remaining failure belongs to an external SDK, send its maintainer the library path, version, relevant tool output and a minimal non-sensitive reproduction. Exclude credentials and customer data.

For the wider release path, Meet CascadeCI separates build execution, upload and store availability. This guide describes documented diagnostics; we have not inspected your app’s binaries.