How can you design a plugin's own public Dart API to remain genuinely stable and backward compatible across several successive plugin versions, even as its own internal native implementation continues to meaningfully evolve and change over time?

Designing a genuinely stable, backward compatible public API means deliberately exposing only the specific minimal, carefully considered set of methods and properties consumers genuinely actually need, keeping your plugin's own internal native implementation details properly and fully hidden and private, and when a genuine new capability or feature does eventually need to be added, doing so by properly adding an entirely new optional method or an optional parameter with a genuinely sensible default value, rather than modifying an already existing method's own established signature in a way that would otherwise genuinely break any existing code that already depends on your plugin's own current established API.

// Adding a new optional parameter preserves backward compatibility
Future<int> getBatteryLevel({bool includePercentage = true}) async { ... }