Locate the Android module configuration
The Flutter release guide shows the Android Gradle configuration and Flutter-managed defaults. Current templates can use values such as flutter.minSdkVersion; a project's older template may differ.
Do not edit a generated cache file when the app module is the intended configuration owner.
Change the value for a documented reason
| Reason | Review |
|---|---|
| Plugin requires a higher minimum | Plugin's declared requirement and affected users |
| New platform API used | Runtime guards or raised minimum |
| Business chooses to drop old devices | Reach and update compatibility |
| Play requests a newer target API | Usually targetSdk, not automatically minSdk |
Raising the minimum can exclude existing devices. It should not be the first workaround for every manifest merge error.
Respect the build-script language
A Kotlin DSL fragment might use:
defaultConfig {
minSdk = 24 // Example policy choice, not a universal recommendation.
}
Use the actual required value and the syntax supported by the project. Keep the application identity unchanged when modifying SDK settings.
Inspect the merged result
Build the intended release and verify its manifest's minimum and target SDK values. Plugins or variant configuration can make the result differ from the line you edited.
Test both the oldest supported platform and a current Android version, including the feature that motivated the change.
Keep the compatibility claim narrow
APKLint's SDK and compatibility tools can inspect declared values, but they cannot prove that every plugin behaves correctly on every supported device. Record the chosen minimum, its rationale, excluded population and runtime test evidence before publishing the update.
Assess the plugin that requests a higher minimum
Suppose adding a native plugin produces a manifest-merger diagnostic requiring a newer minimum API. Identify the exact plugin version and the API its Android implementation needs. Decide whether the product can adopt that minimum, use a supported alternative plugin version, or redesign the feature. Forcing the merger to ignore the requirement can allow packaging while leaving calls that fail on older devices.
The Flutter Android deployment guide documents module configuration and framework-provided defaults. A project using an explicit value and one using Flutter's managed default can respond differently to a framework upgrade. Inspect the effective value after the build instead of assuming the source template is unchanged.
Keep device eligibility separate from target behavior
A minimum API controls the oldest declared platform, while a target API selects relevant compatibility behavior and store requirements. Raising the target for a release requirement does not inherently require choosing the same number as the minimum. Test the platform behavior changes introduced by the target update while preserving the intended device population where supported.
For the plugin example, run the feature on the chosen oldest supported platform and a current platform. Include its unavailable or denied-resource path, not only successful initialization. Check other plugins too, since the app's effective support promise includes the whole release rather than only the dependency that caused the latest error. A successful installation followed by failure on the first native call still violates that declared support boundary.
If the minimum is deliberately raised, document the affected existing users and distribution implications before release. The configuration change should be visible in the final manifest and release record. Do not alter the application ID as a workaround, because that creates a separate installed identity rather than upgrading the existing product. Keep the rationale, dependency version and device evidence with the change so a later update does not unknowingly lower the declaration below what its native code supports. An artifact checker can confirm the declared values; installation and feature tests establish that the selected boundary works for the actual application.
Sources and further reading
Reference review: 29 September 2026. Examples illustrate the workflow; check your installed versions, release artifact and account-specific Console requirements before applying them. This guide is not a claim that APKLint executed your project or verified your private account.
Android inspection tools and practical release guides. About APKLint · Report a correction
