[Firebase messaging]: Duplicate notifications on android

[iosephmagno]

Is there an existing issue for this?

• I have searched the existing issues.

Which plugins are affected?

Messaging

Which platforms are affected?

Android

Description

_firebaseMessagingForegroundHandler and _firebaseMessagingBackgroundHandler are fired multiple times for the same silent (data-only) notification - with firebase messaging 15.2.1

I'm reproducing the issue on android sdk34 Xiaomim Mi Lite 5g, though I saw past similar issues on IOS and this may still affect IOS as well.

Honestly, I’d rather deal with duplicate notifications than miss them entirely.
As a workaround, I’ve implemented a simple cache of notification IDs and filter out duplicates before displaying any alerts. Example code below:

const String kFirebaseNotificationIds = 'firebase_notification_ids';
...

final content = notification.content as ChatNotificationContent;
debugPrint(“DEBUG notification content ${content.id}");
final notificationIds = SharedPrefs.instance.getStringList(kFirebaseNotificationIds) ?? [];
if (notificationIds.contains(content.id)) {
  debugPrint("DEBUG skip duplicate notification");
  return;
} else {
  notificationIds.add(content.id);
  SharedPrefs.instance.setStringList(kFirebaseNotificationIds, notificationIds);
  ...
  // ShowNotification with flutter local notification 
}

...

// Clear kFirebaseNotificationIds when app is paused

I'm still experiencing issues with Android intermittently throttling or blocking push notifications, only to deliver them all at once later. Disabling battery optimizations and enabling autostart improves reliability somewhat, but overall, notification delivery on Android remains inconsistent.

It would be great if the Firebase team could collaborate with the Android team to address this — ideally establishing a more consistent behavior across devices and limiting the ability of manufacturers to interfere with notification delivery mechanisms.

Reproducing the issue

Send a notification to your device.

Firebase Core version

^3.1.1

Flutter Version

3.24.5

Relevant Log Output

Flutter dependencies

Expand Flutter dependencies snippet

Replace this line with the contents of your `flutter pub deps -- --style=compact`.

Additional context and comments

No response

[iosephmagno]

Hi @russellwheatley, in regards to when notifications randomly stop completely when app is in background, can you please let me know if this GPT answer is valid?

It is suggesting that issue is not really the data-only payload, but the DART isolate being killed by the system when app is quit or in background. And it is suggesting to handle notifications with FirebaseMessagingService (native). I start to think it might be right, on IOS we indeed solved the notification issue by handling them natively with the IOS NotificaitonServiceExtension and using Firebase Messaging plugin to still handle the alert onTap. If GPT is right, we could achieve a similar result by handling notification natively on android as well.

GPT:
Why Native FCM Works More Reliably
When using the Flutter Firebase Messaging plugin, you’re relying on:

• Dart isolate lifecycle
• Flutter engine startup
• Plugin initialization order
• FirebaseMessaging.onBackgroundMessage() logic

This makes notifications less reliable, especially when:

• The app is terminated or killed
• The device is in doze mode / battery optimization
• Manufacturer-specific restrictions exist (e.g. Xiaomi, Oppo)

In contrast, Native Android (Java/Kotlin) FCM integration:

1. Runs as a system-level Service

• Your FirebaseMessagingService subclass is registered with Android itself - not Flutter.
• It runs even if Flutter hasn’t started or the app is killed.

2. Receives messages via native OS broadcast

• Android delivers high-priority data-only messages directly to your service, with no Dart engine boot required.

3. Does not depend on Flutter plugins being ready

• Dart and plugin init times (or failures) don’t block it.
• You can decrypt + show the notification instantly from the native thread.

Why This Is Better for Silent + Custom Alerts
With this setup, you:

• Bypass Dart entirely for notification logic
• Have full control over decryption, fallback behavior, retry logic, and visual customization
• Avoid issues from delayed or dropped Dart isolates

But Isn’t It Still a Data Message?
Yes - it’s still a data-only message, but who’s receiving and handling it changes:

• FirebaseMessagingService (native): Receiver is Android system (Lifecycle Sensitive?: NO)
• FirebaseMessaging in Dart: Receiver is Dart (Lifecycle Sensitive?: YES)

TL;DR
You’re replacing a Flutter plugin-based receiver with a native Android system service that is more reliable, faster, and doesn’t require Flutter to be alive - perfect for decrypted, silent notifications.