As part of the work we are doing to better secure FlutterActivity and FlutterFragment against attacks via setting engine flags via Intent extras, we are removing the ability to set engine flags on Android via Intents entirely. See below for details.

The problem this solves

As described in #172553, malicious actors can take advantage of the Intent extras mechanism for setting engine flags on Android by using flag vulnerabilities to run malicious code. For example, attackers could specify a malicious path for the --aot-shared-library-name= flag that allows for the running of native C code; see go/flutter-fragment-flag-security-analysis for analysis of this specific case. Though not all engine flags are open to this vulnerability, this design pattern is dangerous and gives leeway to security vulnerabilities to Flutter Android apps, especially those in release mode (production).

The solution

In order to combat this, we are removing support for setting flags via Intents entirely, which means that flags can no longer be set dynamically. Instead, Flutter developers will have to used one of the following more secure mechanisms:

• Statically in the manifest (AndroidManifest.xml)
• Via the command line

Steps involved in removing Intent support

• Add the ability to set engine flags via the manifest (done in [Android] Add mechanism for setting Android engine flags via Android manifest (take 2) #181632)
• Remove the Flutter tool's reliance on Intent extras to pass engine flags to the embedding (see go/flutter-android-no-more-intents for design discussion)
• Remove support for setting flags via Intents entirely (will likely require better warnings and a migration guide on the website)

Outstanding concerns

We recognize that adding the ability to set engine flags via the manifest may add additional startup time to apps due to the newly introduced parsing of the manifest, but ultimately, we think that the security benefit of preventing attacks via running arbitrary code outweigh that extra startup time.

Part of #172553.