[firebase_messaging]: Android: a burst of background messages starts a FlutterEngine per service start, and can lose all of them
Los mantenedores suelen responder en 1 día
Evaluación
- Dificultad
- 1/5
- Tiempo estimado
- Menos de una hora
- Aptitud para principiantes
- 45/100
Línea de trabajo
Read FlutterFirebaseMessagingBackgroundExecutor.java around line 140 and trace how startBackgroundIsolate() assigns the engine before the queued callback runs. Reproduce with a burst of background data messages on Android, then check that only one engine is created and every queued message is handled. The issue reports a one-line fix and a successful 12-message run, though it does not name a test file.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
Is there an existing issue for this?
- I have searched the existing issues.
Which plugins are affected?
Messaging
Which platforms are affected?
Android
Description
When several data messages reach an app that isn't running (a device switched on, or back online, after missing a few), FlutterFirebaseMessagingBackgroundExecutor creates a background FlutterEngine for every FlutterFirebaseMessagingBackgroundService start that lands before the first engine exists, instead of one.
Expected: one background engine, and every message handled.
Actual: one engine per early service start. On a profile build, 12 messages held while the device was off, then boot: 6 × Creating background FlutterEngine instance. and 6 × FlutterFirebaseMessagingBackgroundService started! in one process. On a debug build, 22 held messages: 22 engines, then the low-memory killer, and no notification shown.
Cause: onCreate calls startBackgroundIsolate(), whose guard is if (backgroundFlutterEngine != null) return;. But the engine is only assigned inside the callback that method posts to the main looper after ensureInitializationCompleteAsync. Every service start before then posts another callback. The callback checks only isNotRunning(), which stays true until Dart sends MessagingBackground#initialized, so each one creates a new engine, overwrites backgroundFlutterEngine and backgroundChannel, and starts another isolate. The queued intents drain only in onInitialized. Their work was already completed, so if the process dies first (memory pressure from N engines) they are lost.
Fix (FlutterFirebaseMessagingBackgroundExecutor.java, L140 on 16.7.0 and on main at 90c22c8dd9):
- if (isNotRunning()) {
+ if (isNotRunning() && backgroundFlutterEngine == null) {
onCreate, the posted runnable and its callback all run on the main looper, so once the first callback assigns the engine, every later one skips. With that change, the same 12-message boot burst makes one engine and shows all 12 notifications.
Reproducing the issue
- Register a handler with
FirebaseMessaging.onBackgroundMessage. - Power the device off.
- Send ≥10 high-priority, data-only messages to it.
- Boot the device without opening the app.
- Count
Creating background FlutterEngine instance.in logcat: one per early service start, not one.
A profile or release build shows the duplicate engines cleanly. On a debug build the first engine's kernel load on the main thread (7–10 s) can also trip a background ANR on the pending FCM broadcast, which is a separate, debug-only effect.
Firebase Core version
4.15.0
Flutter Version
3.47.7
Relevant Log Output
# Profile build, 12 held data messages, device booted without opening the app (one process):
I FLTFireBGExecutor: Creating background FlutterEngine instance. (×6)
I FLTFireMsgService: FlutterFirebaseMessagingBackgroundService started! (×6)
# The same burst with the one-line fix:
I FLTFireBGExecutor: Creating background FlutterEngine instance. (×1)
I FLTFireMsgService: FlutterFirebaseMessagingBackgroundService started! (×1)
Flutter dependencies
firebase_messaging 16.7.0, firebase_core 4.15.0.
Additional context and comments
- Versions: firebase_messaging 16.7.0 and
mainat 90c22c8dd9. Earlier 16.x releases (checked: 16.4.2, 16.4.3, 16.6.0) have the sameisNotRunning()-only check in the callback. - Tested on an Android 16 emulator.
- We're carrying the one-line change above as a build-time patch until a fix ships, and we're happy to open a PR with it if that helps.
- Lenguaje dominante
- Dart
- Estrellas
- 9.3k
- Forks
- 4.1k
- Merge medio
- 2 d 8 h
- PR fusionados (30 d)
- 46
Preparar el entorno
- Sin Dockerfile ni archivo de Docker Compose
- Tiene una plantilla de pull request
- Leer la guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de firebase/flutterfire
-
[firebase_auth]: authStateChanges() never emits null when the user is force-signed-out before the stream is listened to (iOS, macOS, Android)Posiblemente ocupada @JulianPscheid la tomó hace 1 día. AbiertoNeeds Attention platform: android platform: ios platform: macos plugin: auth reproduced type: bug
Dificultad 4/5 1-2 días Aptitud para principiantes 15/100
firebase/flutterfire#18796 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
blocked: customer-response Needs Attention platform: ios plugin: messaging type: bug
Dificultad 4/5 3-5 días Aptitud para principiantes 48/100
firebase/flutterfire#18776 · 4 comentarios ·
Los mantenedores suelen responder en 1 día
-
[📚] Remote Config Windows Support still N/A on ReadmePosiblemente ocupada @nightcityblade la tomó hace 7 días. Abiertoblocked: customer-response good first issue Needs Attention platform: windows plugin: remote_config type: documentation
Dificultad 1/5 Menos de una hora Aptitud para principiantes 30/100
firebase/flutterfire#18763 · 3 comentarios ·
Los mantenedores suelen responder en 1 día
-
[cloud_firestore]: a snapshots() listener cancelled while it registers is never removed nativelyPosiblemente ocupada @chiliec la tomó hace 19 días. AbiertoNeeds Attention platform: android platform: ios platform: macos plugin: cloud_firestore reproduced type: bug
Dificultad 3/5 1-2 días Aptitud para principiantes 72/100
firebase/flutterfire#18724 · 2 comentarios ·
Los mantenedores suelen responder en 1 día
-
[firebase_storage] Windows native crash in upload progress callback, sink ownership and thread dispatchQuizá libre de nuevo Un pull request para esta issue se cerró sin fusionarse. Abiertoblocked: flutter platform: windows plugin: storage reproduced type: bug
Dificultad 5/5 Más de una semana Aptitud para principiantes 25/100
firebase/flutterfire#18664 · 3 comentarios ·
Los mantenedores suelen responder en 1 día
Todos los issues de firebase/flutterfire
Issues similares
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 85/100
Los mantenedores suelen responder en 1 día
-
[Bug]: The daily reminder keeps its old language after the app language changesPosiblemente ocupada Un pull request vinculado a esta issue está abierto o ya se fusionó. Abiertobacklog:low bug localization
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
simonoppowa/OpenNutriTracker#1366 ·
Los mantenedores suelen responder en 1 día
-
Mobile reading view shows a sender without display name as "<[email protected]>" with angle bracketsAbiertoai-driven-qa bug Cosmetic
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
linagora/tmail-flutter#4999 ·
Los mantenedores suelen responder en 1 día
-
waiting for response
Dificultad 2/5 Menos de una hora Aptitud para principiantes 72/100
flutter/flutter#194381 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
newrelic/newrelic-flutter-agent#243 · 3 comentarios ·