[firebase_messaging] Unexpected Duplicate `main` in Call Stack on Android when Using `FirebaseMessaging.onBackgroundMessage`

[SaadSafan]

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 I include FirebaseMessaging.onBackgroundMessage(firebaseMessagingBackgroundHandler); in my code and run the app on an Android device, I observe two main functions in the call stack. This appears in both VS Code and Android Studio (Flutter Inspector). While the duplicate main might be a result of the background message handler running in a separate Dart isolate, it is unclear whether this is intended behavior or a potential issue.

In VSC.

Using Android Studio and Flutter Inspector.

Reproducing the issue

Reproducing the issue

1. Clone the Firebase Messaging Example App.
2. Run the app on an Android device.
3. Open the call stack in VS Code and inspect the Flutter Inspector in Android Studio to observe two main functions.

Firebase Core version

3.12.1

Flutter Version

3.27.4

Flutter dependencies

Expand Flutter dependencies snippet

Dart SDK 3.6.2
Flutter SDK 3.27.4
flutterfire_workspace 0.0.0

dev dependencies:
- cli_util 0.4.2 [meta path]
- glob 2.1.3 [async collection file path string_scanner]
- intl 0.19.0 [clock meta path]
- melos 5.3.0 [ansi_styles args async cli_launcher cli_util collection conventional_commit file glob graphs http meta mustache_template path platform pool prompts pub_semver pub_updater pubspec string_scanner yaml yaml_edit]
- path 1.9.1
- pub_semver 2.1.5 [collection meta]
- yaml 3.1.3 [collection source_span string_scanner]

transitive dependencies:
- ansi_styles 0.3.2+1
- args 2.6.0
- async 2.13.0 [collection meta]
- boolean_selector 2.1.2 [source_span string_scanner]
- charcode 1.4.0
- cli_launcher 0.3.1 [path yaml]
- clock 1.1.2
- collection 1.19.1
- conventional_commit 0.6.0+1
- file 7.0.1 [meta path]
- graphs 2.3.2 [collection]
- http 1.3.0 [async http_parser meta web]
- http_parser 4.1.2 [collection source_span string_scanner typed_data]
- io 1.0.5 [meta path string_scanner]
- json_annotation 4.9.0 [meta]
- matcher 0.12.17 [async meta stack_trace term_glyph test_api]
- meta 1.16.0
- mustache_template 2.0.0
- platform 3.1.6
- pool 1.5.1 [async stack_trace]
- process 5.0.3 [file path platform]
- prompts 2.0.0 [charcode io]
- pub_updater 0.4.0 [http json_annotation process pub_semver]
- pubspec 2.3.0 [path pub_semver yaml uri]
- quiver 3.2.2 [matcher]
- source_span 1.10.1 [collection path term_glyph]
- stack_trace 1.12.1 [path]
- stream_channel 2.1.4 [async]
- string_scanner 1.4.1 [source_span]
- term_glyph 1.2.2
- test_api 0.7.4 [async boolean_selector collection meta source_span stack_trace stream_channel string_scanner term_glyph]
- typed_data 1.4.0 [collection]
- uri 1.0.0 [matcher quiver]
- web 1.1.1
- yaml_edit 2.2.2 [collection meta source_span yaml]

Additional context and comments

• The Firebase Messaging background handler typically runs on a separate Dart isolate. According to the FlutterFire documentation, this might naturally result in a separate main function in the call stack.

[SelaseKay]

Hi @SaadSafan, thanks for the report. I'll keep this opened for further investigation.

[imtoori]

it's happening to me too
I think this might be causing issues in production too

[MichaelVerdon]

This seems like intended behaviour as an isolate only runs on Android for background message handling and is not needed on iOS and so on. I will confirm with the rest of the team. What issues do you think this could be producing @imtoori ?

[imtoori]

I'm not sure, we're having a small issue in the app and we think it might be due to this, but I'm really brainstorming

I think you're right, but I thought the additional isolate would run only when we actually get the message and not by default on app launch. Can you confirm it's the correct behaviour?

[MichaelVerdon]

Hi there @imtoori apparently this behaviour is not intended and something we tried to fix before but couldn't but like @SelaseKay said we will keep this open and keep investigating.

[imtoori]

ok sounds good, I'll investigate on my side to understand if my issues are actually related
Thanks for the quick reply!

[binuashiq]

I am having the same issue. Using flutter firebase_messaging: 15.2.3 and firebase_core: 3.6.0. When loading the android app all the app initialisation is done twice

[PhantomRay]

It might be related:
While the app is in foreground, the following code is triggered even though it should only happen when the app is not in foreground. This can be observed when the app is in foreground and keep sending a few push notifications.

@pragma('vm:entry-point')
Future<void> _firebaseMessagingBackgroundHandler(firebase.RemoteMessage message) {
  print("('Push Manager Firebase RemoteMessage received while app is in background;")
}

[PhantomRay]

Some dude from Reddit says:

https://www.reddit.com/r/androiddev/comments/113wsyy/does_anyone_face_high_anr_rate_for_android_13/

I know if you start a foreground service and don't actually show a notification within 5 sec of that call, your app will ANR. Are you showing a running notification to the user while you have a foreground service running? And doing it timely?

I'm thinking could this cause ANR as mentioned here? #12832