Previously, the Flutter Android embedding accepted engine configuration flags (such as `--dart-flags`, `--route`, or tracing flags) at launch time through Android `Intent` extras in all build modes. This mechanism allowed developers and tools—including the Flutter CLI when using `--use-application-binary`—to dynamically configure running applications without modifying their source code or manifest.
Original behavior
The Flutter engine accepts configuration flags (such as `--dart-flags`, `--route`, or `--trace-startup`) to configure runtime behavior when running or driving an application. Historically, the Flutter Android embedding accepted these flags at runtime through `Intent` extras. Both developers (using `adb shell am start` or native code) and the Flutter CLI (via `adb`) relied on `Intent` extras to pass flags to running apps.
New behavior
### Android embedding behavior
- Who is affected
- Applications and packages relying on the previous behaviour or signature. Code that uses Intent, AndroidManifest.xml, FlutterActivityAndFragmentDelegate.Host.getFlutterShellArgs and related APIs.
- Practical impact
- Behaviour or API differences that can break builds or change runtime behaviour.
- What action should I take?
- Follow the official migration guide below, update affected call sites, run `dart fix --apply` where a fix is available, then run your tests.
Official migration guide (excerpt, © The Flutter Authors, CC BY 3.0)
-
You build and run standard release apps with the Flutter CLI (
flutter run --release,flutter build apk --release, orflutter build appbundle). -
You run tests and benchmarks in debug or profile mode.
-
You use
--use-application-binarywithout passing engine configuration flags. -
You launch release builds using Android
Intentextras directly (such as withadb shell am startor custom launch intents in native code) to pass engine configuration flags or route arguments. -
Your CI/CD pipelines, automated scripts, or test runners pass flags to prebuilt release binaries using
--use-application-binary. -
You build Flutter Android applications using non-Gradle or hermetic build systems (such as Bazel) and configure release binaries with launch-time flags.
If your workflows are affected, use one of the following migration paths:
Switch testing and benchmarking to profile mode
If your automated test pipelines, scripts, or benchmarks pass flags to release binaries dynamically at launch time:
- Switch your test target to profile mode (
--profile). Profile mode mirrors release performance characteristics while retaining support for dynamic runtime flag configuration throughIntentextras and the Flutter CLI without recompilation.
Configure direct Intent launches and hermetic build systems
If you launch release builds using Android Intents directly
(for example, via adb shell am start or custom test runners),
or if you build Flutter Android apps with non-Gradle or hermetic build systems
(such as Bazel) that separate compilation from execution:
- Do not rely on
Intentextras for release builds. Any engine flags passed inIntentextras to a release binary are silently ignored by the embedding at runtime. - Use profile mode for dynamic testing: For integration tests or performance benchmarks that require varying flags dynamically at launch time, compile and run a profile build instead of a release build.
- Declare flags statically in
AndroidManifest.xml: If you must run a release binary with specific engine flags, statically declare those flags in yourAndroidManifest.xmlbefore compiling the release binary. For details, refer to Declare engine flags inAndroidManifest.xml.
Build release binaries with flags directly using the Flutter CLI
If you must run tests against a release binary with the Flutter CLI:
- Run
flutter buildorflutter runwith your configuration flags without--use-application-binary. The CLI automatically embeds the flags into the compiled manifest. - Alternatively, compile separate release binaries for each required configuration.
Configure engine flags programmatically in native host code
If you launch Flutter from native Android code
(such as in an add-to-app integration or custom native activity)
and previously passed engine flags through Intent extras:
-
Override
getFlutterEngineFlags(): If you subclassFlutterActivityorFlutterFragment, overridegetFlutterEngineFlags()instead of usingIntentextras or the deprecatedgetFlutterShellArgs():class MyFlutterActivity : FlutterActivity() { override fun getFlutterEngineFlags(): List<String> { val flags = super.getFlutterEngineFlags().toMutableList() flags.add("--trace-startup") return flags } } -
Use
FlutterFragment.NewEngineFragmentBuilder: If you host aFlutterFragment, pass flags using the builder:val fragment = FlutterFragment.withNewEngine() .flutterEngineFlags(listOf("--trace-startup")) .build<FlutterFragment>() -
Pre-initialize and cache a
FlutterEngine: If you manage the engine lifecycle directly, supply engine arguments to theFlutterEngineconstructor:val args = arrayOf("--trace-startup", "--enable-impeller=true") val flutterEngine = FlutterEngine(context, args) FlutterEngineCache.getInstance().put("my_engine_id", flutterEngine)
Declare engine flags in manifest
To configure engine flags statically in release builds,
add <meta-data> elements under the <application> tag in
your android/app/src/main/AndroidManifest.xml file:
<manifest xmlns:android="http://schemas.android.com/apk/res/android">
<application
android:label="my_app"
android:name="${applicationName}"
android:icon="@mipmap/ic_launcher">
<!-- Declare engine configuration flags statically -->
<meta-data
android:name="io.flutter.embedding.android.DartFlags"
android:value="--some-dart-flag" />
<meta-data
android:name="io.flutter.embedding.android.EnableDartProfiling"
android:value="false" />
<activity
...
</activity>
</application>
</manifest>AI_PROVIDER (for example to openai-compatible with a local Ollama or LM Studio endpoint) to enable grounded explanations. Everything else on this page works without an AI provider.Listed in the official breaking-changes index (docs.flutter.dev/release/breaking-changes).
An official announcement or migration guide documents an intended behaviour or API change. A verified source change (git diff) shows code changed but does not by itself prove a public API is breaking. AI interpretations are labelled and never used to classify a change.
- Source commit
- b3045439b7c0
- Source last updated
- Oct 21, 2026
- Last synchronized
- Oct 21, 2026
- Publication status
- published
Publication history
- Oct 21, 2026, 8:31 PM: new → published (ingestion) — Backed by an official breaking-change/migration guide.
AI_PROVIDER (for example to openai-compatible with a local Ollama or LM Studio endpoint) to enable grounded explanations. Everything else on this page works without an AI provider.