Skip to content

feat(share_plus): launch share target in its own task on Android#3838

Closed
leonardo-oliveir-a wants to merge 1 commit into
fluttercommunity:mainfrom
leonardo-oliveir-a:feat/share-plus-flag-activity-new-task
Closed

feat(share_plus): launch share target in its own task on Android#3838
leonardo-oliveir-a wants to merge 1 commit into
fluttercommunity:mainfrom
leonardo-oliveir-a:feat/share-plus-flag-activity-new-task

Conversation

@leonardo-oliveir-a
Copy link
Copy Markdown

Summary

Adds Intent.FLAG_ACTIVITY_NEW_TASK to the chooser intent on Android so the destination app (WhatsApp, Telegram, Drive, etc.) launches in its own task instead of being stacked on top of the calling app's task.

Motivation

Resolves the long-standing UX inconsistency described in:

Without the flag, the recents switcher shows a single entry for the calling app with the target app visible inside it — inconsistent with how native Android apps (Google Keep, Instagram, etc.) handle share, where target and caller appear as separate recents entries.

Demonstration from #2267 (linked videos): Keep → Drive works correctly; Thunder (using share_plus) → Drive does not.

Previous attempts

This PR uses the same minimal approach as #3751 with a conventional-commits-compliant title.

Change

One file, ~10 lines (including comment):

// packages/share_plus/share_plus/android/src/main/kotlin/dev/fluttercommunity/plus/share/Share.kt
chooserIntent.addFlags(Intent.FLAG_ACTIVITY_NEW_TASK)

Applied right after Intent.createChooser(...) and before the file-permission grant + startActivity.

Trade-off considered

@miquelbeltran's comment on #2267 noted that some apps (e.g. Twitter) do share within the same task and asked for "choice". This PR opts for always-on rather than introducing a new API surface, matching what #3751 attempted. Rationale:

  • The same-task behavior is generally considered a UX regression vs. native Android share — most apps that need same-task behavior do so unintentionally.
  • An always-on flag has zero API surface change → no migration burden, no deprecation noise.
  • If the team prefers opt-in, happy to convert this to a ShareParams.newTask (default true) — let me know and I'll push.

Test plan

  • Manual test on Android 11 (OnePlus 6T): share text + image to Telegram and WhatsApp → target apps now appear as separate recents entries (was: single consolidated entry).
  • Manual test: back button in target app still returns to caller app correctly.
  • Manual test: deep links (https://...) inside shared text are preserved and handled by target.

Checklist

  • I read the Contributor Guide and followed the process outlined there for submitting PRs.
  • I titled the PR using Conventional Commits.
  • I did not modify the CHANGELOG.md nor the plugin version in pubspec.yaml files.
  • All existing and new tests are passing.
  • The analyzer (flutter analyze) does not report any problems on my PR.

Breaking Change

No API surface change. Behavioral change only: target apps will now appear as separate recents entries (the same way native Android share behaves). Apps that explicitly relied on the previous same-task stacking would need to wrap share calls in a task-affinity workaround — but I'm not aware of any documented case.

…roid

When share_plus opens the share sheet and the user picks a target app
(WhatsApp, Telegram, Drive, etc.), the target activity is currently
stacked on top of the calling app's task. In the recents switcher this
shows up as a single entry for the calling app with the target app
visible inside it — inconsistent with how native Android apps like
Google Keep or Instagram handle share, where the target appears as a
separate recents entry.

Adding `Intent.FLAG_ACTIVITY_NEW_TASK` to the chooser intent before
`startActivity` instructs Android to launch the target in its own task,
matching the behavior users expect from system share.

This unblocks issue fluttercommunity#2267 (open since Oct 2023) and addresses the
underlying mechanism in fluttercommunity#2682. Equivalent fix attempted in fluttercommunity#3751 but
that PR was closed minutes after creation by a CI bot complaining
about the title format.

The change is one-line behavior addition with no API surface change.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant