🗣️
Discuss
SG
Sveva Guida
·Posted in Discuss

Is there a supported way to override the default `flutter_deeplinking_enabled=true` meta-data generated when a URL Scheme is configured, for apps handling deep links entirely through a third-party package?

Best Practices

Context

  1. Project is not pinned to a specific FlutterFlow version (currently can't pin it yet, since some Hub & Spoke libraries used by this project are still being actively migrated/stabilized, so we need to stay on the latest version for now).

  2. A URL Scheme is configured under General Settings > Routing & Deep Linking.

  3. Deep link handling in the app is done entirely through the app_links package via a custom DynamicLinkService, independent of Flutter's native deep-linking route interception.

  4. Per Flutter's own breaking-change notes (https://docs.flutter.dev/release/breaking-changes/deep-links-flag-change), apps using app_links (like this one) are required to explicitly set flutter_deeplinking_enabled to false, since Flutter's default changed to true starting with stable 3.27. To do this, we added a custom Android Manifest hook ("Disable default Flutter deep linking") that inserts:

<meta-data android:name="flutter_deeplinking_enabled" android:value="false" />

Current Behavior

For context on how we got here: in early May, this project still used Branch.io for deep linking, and at that time flutter_deeplinking_enabled was true (FlutterFlow's default, generated because a URL Scheme is configured) with no override hook at all — Branch worked fine alongside that default, using its own intent-filter and io.branch.sdk.* meta-data keys, with no conflict. We later migrated away from Branch to the app_links package with a custom DynamicLinkService, and per Flutter's own breaking-change guidance (linked above), we added the custom "Disable default Flutter deep linking" hook to set the flag to false. That's when the structural duplicate below started happening (FlutterFlow's own default true node, generated whenever a URL Scheme is configured, plus our added false node, both in the same Activity block).

The Android build now fails at the manifest merge step:

AndroidManifest.xml:59:7-114 Error:
	Element meta-data#flutter_deeplinking_enabled at AndroidManifest.xml:59:7-114 duplicated with element declared at AndroidManifest.xml:35:7-83
AndroidManifest.xml Error:
	Validation failed, exiting
 
FAILURE: Build failed with an exception.
* What went wrong:
Execution failed for task ':app:processReleaseMainManifest'.
> Manifest merger failed with multiple errors, see logs

Looking at the generated manifest, there are now two flutter_deeplinking_enabled meta-data elements inside the same <activity> tag, in the same generated file:

  1. Line 35: android:value="true", generated automatically as part of the default Activity template whenever a URL Scheme is configured (not from any custom hook we authored).

  2. Line 59: android:value="false" tools:replace="android:value", from our custom hook.

We attempted to fix this by adding tools:replace="android:value" to our hook (namespace xmlns:tools is already declared on the root <manifest> tag), but the build fails with the identical duplicate error even with that attribute present. As we understand it, tools:replace resolves conflicts between different manifest sources being merged (e.g., app manifest vs. a library's manifest), not two literal duplicate elements already present in the same single source file before any merge across sources happens — which appears to be the case here, since both elements are generated into the same primary Activity block.

Question / Request for Clarification

  1. Is there a supported way to prevent FlutterFlow from generating its own default flutter_deeplinking_enabled=true meta-data (and the accompanying default intent-filter) for apps that have a URL Scheme configured but handle deep linking entirely through a third-party package?

  2. If there's no such setting today, could tools:node="remove" (rather than tools:replace) or a different hook type be used to suppress the default-generated element instead of adding a second conflicting one? We're not sure which manifest-hook mechanism (if any) is appropriate for removing/overriding a node generated by FlutterFlow's own template, as opposed to only adding new nodes (which is all the current Activity Tag hook seems able to do).

  3. More generally: is this interaction (URL Scheme configured + a third-party deep-linking package requiring the flag set to false) a known/expected friction point? If so, it might be worth a note in the Deep & Dynamic Linking docs, since the current guidance to "keep the URL Scheme in sync" doesn't mention this side effect.

Thanks for reading and for adding your experience/ideas. 

3