Android "best practice" is often to use the v4 support library's FragmentActivity because it has a strict superset of the functionality in the Android framework's Activity class. In fact, the only reason not to use FragmentActivity is if you need to avoid the binary size increase that goes along with bundling the v4 support library JAR in your app. However, so many Android apps need that support library anyway that virtually all apps include it (and correspondingly use FragmentActivity).

Because that's true for non-Flutter Android apps, many native libraries built on top of the Android APIs deal directly with FragmentActivity, assuming that apps won't have a problem with the reliance on the v4 support library.

This poses a problem for Flutter plugin authors. Since they're calling APIs in various Android libraries, they're often going to be faced with APIs that require a FragmentActivity. Yet, FlutterActivity extends Activity directly rather than FlutterActivity specifically to avoid the dependency on the v4 support library.

The solution thus far (used internally in Google) has been to copy/paste FlutterActivity into a version that extends from FragmentActivity but is identical in all other ways. This is not only a burden on app developers, but it means:

• They won't benefit from new functionality or bug fixes in the engine's FlutterActivity
• They'll suffer more from internal API changes like the move to the PluginRegistry APIs

The fact that we don't bundle the v4 support library in the Flutter engine is a good thing. Rather than going down that road, we can probably make better use of composition in FlutterActivity with public classes that can easily be composed into an app-specific FragmentActivity subclass.