[Lyokone]

Description

Reproduced the reports in #17206 in the iOS simulator by delivering pushes through UIApplication.delegate the way iOS does (simctl push never reaches application:didReceiveRemoteNotification:fetchCompletionHandler:). Three bugs:

1. Every push was handled twice on iOS. The plugin is both a GoogleUtilities app delegate interceptor and a Flutter application delegate (addApplicationDelegate, #13525). The GoogleUtilities proxy calls the interceptor and forwards to FlutterAppDelegate, which calls the plugin again, so onMessage and onBackgroundMessage fired twice per push. The second call within the same delivery is now dropped by gcm.message_id (the ID is forgotten on the next main loop turn, so a later push that reuses it is still handled), and still calls its completion handler, otherwise the proxy never calls the system one.

2. Background messages were dropped at startup. When a push arrives as the app starts (background launch), it can reach Dart before main() has called FirebaseMessaging.onBackgroundMessage. If the app used FirebaseMessaging.instance first (e.g. getToken() / requestPermission()), the channel handler was already attached and the message was handed to a null handler: no error, no handler call. It now waits for a handler during the first 10 seconds after the app starts using messaging (native completes the push after 25 seconds). It only waits for apps that register one: the plugin remembers whether Dart registered a handler during this run or the previous one, and says so before each background message.

3. onMessage / onMessageOpenedApp received nothing until another messaging API was called. The Dart channel handler was only attached when FirebaseMessagingPlatform.instance was first used, which FirebaseMessaging.instance and the streams don't do. Listening to either stream now attaches it.

The plugin also enlarges the channel buffer (Flutter keeps a single message by default) so messages sent before Dart is ready are not overwritten. It is sent with every message, because Flutter drops messages until the engine runs Dart, which is when UIScene apps register plugins.

Also fixed: with FirebaseAppDelegateProxyEnabled=NO, the plugin copies its didReceiveRemoteNotification:fetchCompletionHandler: onto the app delegate, which then ran plugin code with the app delegate as self. It now hands the call to Flutter's forwarding (so other plugins still get it), or else to the plugin. Verified on the simulator with the proxy disabled, and now covered in CI (below).

Repro (push injected during startup, handler registered after getToken)	before	after
push 30 ms after engine start	not handled	handled once
push 200 ms after engine start	not handled	handled once
push after registration / app in background	handled twice	handled once

Messages sent to Dart before it handles the channel are now kept (up to 64) instead of all but the last being dropped, so an app that starts using messaging late gets the messages received in between.

Tests

• Unit tests (firebase_messaging_platform_interface): messages arriving before the handler are held and handled, the 10 s startup window, waking from the setter, onMessage works without any other API call, and listening without a binding. They fail on main.
• iOS e2e (example/integration_test/e2e_test.dart, run by e2e-messaging on the simulator): a test-only channel in the example app (RemoteNotificationTestChannel.swift, like tests/permissions on Android) delivers data messages through the app delegate in foreground and background. They check onMessage / onBackgroundMessage run exactly once, the push completes once with NewData, and a later push reusing a message ID is handled again. The once-only tests fail on main (each message received twice); all pass with this change on an iOS 27 simulator, also with FirebaseAppDelegateProxyEnabled=NO.

CI

• The delivery tests moved to integration_test/remote_notification_delivery.dart. They are run by e2e_test.dart, and on their own by a new ios-app-delegate-proxy-disabled job in e2e-messaging with FirebaseAppDelegateProxyEnabled=false, through a new info-plist-overrides input of reusable_e2e_ios.yaml.
• New e2e tests:
  • a background message that arrives before onBackgroundMessage is set runs it once it is (fails on main);
  • messages sent before Dart handles the channel are all kept (fails without the buffer resize).

Related Issues

Related to #17206 (core cause of the "background handler not called" reports), probably #18776 and #17339.

Checklist

• I read the Contributor Guide and followed the process outlined there for submitting PRs.
• My PR includes unit or integration tests for all changed/updated/fixed behaviors (See Contributor Guide).
• All existing and new tests are passing.
• I updated/added relevant documentation (doc comments with ///).
• The analyzer (melos run analyze) does not report any problems on my PR.
• I read and followed the Flutter Style Guide.
• I signed the CLA.
• I am willing to follow-up on review comments in a timely manner.

Breaking Change

• No, this is not a breaking change.

[gemini-code-assist]

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize the Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counterproductive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here.