Back to results for “Security”
Flutter › Flutter Plugin & Package Development

How do you properly handle a breaking native API change on one specific platform, such as a new required Android permission model, while genuinely still maintaining backward compatibility for consumers of your plugin using an older version of that same platform?

Advanced

Answer

Handling a genuinely breaking native platform change, such as Android introducing a meaningfully new required runtime permission model in a newer specific API level, typically requires your plugin's own native implementation code to properly check the actual current device's specific API level at runtime and conditionally branch its own internal logic accordingly, continuing to correctly support older devices using the previous established approach while properly adopting the newer required approach specifically on devices that genuinely support it, and clearly documenting this specific compatibility nuance within your plugin's own README helps consuming developers properly understand exactly what genuine behavior to actually expect across these different specific device API levels.
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.TIRAMISU) {
    // Use newer required permission model
} else {
    // Use older, previously established permission model
}
Real-world example A media picker plugin's native Android implementation properly checks the actual current device's specific API level, correctly using the considerably newer granular media permission model on genuinely newer Android versions while still properly falling back to the previous established broader storage permission on older devices.

Common follow-ups: How do you properly and clearly communicate a genuine breaking native platform change to consumers of your plugin?;What specific testing strategy genuinely helps catch a platform compatibility issue like this before an actual official plugin release?