[🐛] [ANDROID] Warning - No background message handler has been set. Set a handler via the "setBackgroundMessageHandler" method - when setBackgroundMessageHandler isn't used

[leolusoli]

Issue

Android shows me the warning using onNotificationOpenedApp event handler and without using setBackgroundMessageHandler.

I see the code of FirebaseMessagingModule. Looking inside the constructor it seems that this is required, even when I don't want to use a background message handler.

There's something that I'm missing?

Thank you in advice.

Project Files

Disable AutoLinking in Android. But everything works correctly.

Javascript

Classical implementation a listeners onNotificationOpenedApp and onMessage.

package.json:

{
  "dependencies": {
   .....
    "@notifee/react-native": "1.10.1",
    "@react-native-firebase/analytics": "^12.7.3",
    "@react-native-firebase/app": "^12.7.3",
    "@react-native-firebase/dynamic-links": "^12.7.3",
    "@react-native-firebase/messaging": "^12.7.3",
   .....
    "react": "17.0.2",
    "react-native": "0.65.1",
    .....
  },
  "devDependencies": {
    .....
  },
}

firebase.json for react-native-firebase v6:

NO

iOS

Click To Expand

#### `ios/Podfile`: - [ ] I'm not using Pods - [x] I'm using Pods and my Podfile looks like this: Using auto-linking for iOS #### `AppDelegate.m`: Configure firebase with firOptions

---

Android

Configure using google_service.json

Have you converted to AndroidX?

• [ ] my application is an AndroidX application?
• [ X] I am using android/gradle.settings jetifier=true for Android compatibility?
• [ ] I am using the NPM package jetifier for react-native compatibility?

Environment

Click To Expand

**`react-native info` output:** ``` System: OS: macOS 11.2.3 CPU: (8) x64 Intel(R) Core(TM) i7-7700HQ CPU @ 2.80GHz Memory: 123.78 MB / 16.00 GB Shell: 3.2.57 - /bin/bash Binaries: Node: 15.14.0 - ~/.nvm/versions/node/v15.14.0/bin/node Yarn: 1.22.4 - ~/.yarn/bin/yarn npm: 7.7.6 - ~/.nvm/versions/node/v15.14.0/bin/npm Watchman: 4.9.0 - /usr/local/bin/watchman Managers: CocoaPods: 1.10.1 - /usr/local/bin/pod SDKs: iOS SDK: Platforms: iOS 14.5, DriverKit 20.4, macOS 11.3, tvOS 14.5, watchOS 7.4 Android SDK: API Levels: 28, 29, 30 Build Tools: 28.0.3, 29.0.2, 29.0.3, 30.0.2, 30.0.3, 31.0.0 System Images: android-29 | Google APIs Intel x86 Atom, android-30 | Google APIs Intel x86 Atom Android NDK: Not Found IDEs: Android Studio: 2020.3 AI-203.7717.56.2031.7621141 Xcode: 12.5/12E262 - /usr/bin/xcodebuild Languages: Java: 1.8.0_144 - /usr/bin/javac npmPackages: @react-native-community/cli: Not Found react: 17.0.2 => 17.0.2 react-native: 0.65.1 => 0.65.1 react-native-macos: Not Found npmGlobalPackages: *react-native*: Not Found ``` - **Platform that you're experiencing the issue on**: - [ ] iOS - [X ] Android - [ ] **iOS** but have not tested behavior on Android - [ ] **Android** but have not tested behavior on iOS - [ ] Both - **`react-native-firebase` version you're using that has this issue:** - `e.g. 12.7.3` - **`Firebase` module(s) you're using that has the issue:** - `Messagging` - **Are you using `TypeScript`?** - `N`

[mikehardy]

:thinking: that warning is very useful for developer experience, as nearly everyone that uses this package for notification listeners (as opposed to react-native-push-notifications if you just want some notification handling) wants the ability to handle FCM, which may come in the background.

If we were to add some sort of toggle that you could use to signal that no, you did not want a background handler, it would not in practice be much different than adding firebase.messaging().setBackgroundMessageHandler(() => {}); in index.js.

So, I can see how this warning could be a bit a bit off-putting but we are balancing a couple tensions at once, and there is a workaround I think.

What happens when you add a dummy handler as prescribed above?

[leolusoli]

Hi @mikehardy. It's not possible to add a configuration field property in order to jump the activation of this message handler? I think that is more correct to disable a thing if it's not used.

Anyway, thanks for the tip and the explanation ;)

[mikehardy]

Of course it's possible, it's software, but less software and fewer changes is fewer bugs, with a config param reducing to effectively the same experience as a dummy handler, so I prefer not to

[keima]

I also would like to have the ability to disable this feature.

My app is running redux-saga on startup, but it seems that every time I receive a notification, saga is running, causing unexpected communication. I understand that there is a problem with my implementation, but it is difficult to solve it immediately because it is currently being referred directly to everywhere. For me, if I can disable this feature, I can ignore the problem I am having. So I hope you will consider implementing it.

[mikehardy]

@keima

So I hope you will consider implementing it.

Please report how it goes when you add a dummy handler set in index.js. I'm under the impression this will remove the warning for you.

[keima]

@mikehardy If set a dummy handler, the behavior of the app wakeup silently (headless) is not changed, but warning message will no longer be displayed.

[mikehardy]

Right, that's going to happen no matter what (app wakeup) it's a function of FCM via firebase-android-sdk, if you send an FCM to the app, the underlying SDK receives it and starts the app. I don't think having a handler set or not would affect that.

[keima]

I see. I understand now. Thank you.

I remember it didn't behave that way in v5, so I'm pondering. I want to prepare a project to reproduce the situation when I have time.

[leolusoli]

@mikehardy Another question. If you exclude the com.google.firebase.MESSAGING_EVENT intent service to the AndroidManifest of the react-native-firebase/messaging project, the SDK still wakes up the application when receives data messages from FCM?

[mikehardy]

I believe if you look at the fully merged AndroidManifest.xml that gets packed in the app (via Android Studio or whatever tool you are comfortable with - you can find it in android/app/build/.... as well) it's the broadcast receivers not the intent? but in general yes if you edit that chunk out of the merged manifest (somehow) then you have effectively removed the handle the android system was using to get hold of the app and wake it up. That would sever the connection between FCM and wakeup, bit would likely kill foreground as well

[leolusoli]

@mikehardy So, there's the possibility to not wake up the application (and so, the possibility to avoid dummy handler). But disable this behaviour isn't a responsibility of this SDK. Right?

Thank you in advice for the detailed discussion :)

[mikehardy]

What we're discussing here with regard to wake-ups is firebase-android-sdk, it is below us (thought of as layers) or before us (in terms of when things execute) and we are not in control of it, it is not the responsibility of this module no

To be honest, I do not see any point to avoiding the dummy handler and would just set one if you are using remote handlers. Well to be honest I'd set a real handler because using the background messaging feature is kind of useful and I don't know why anyone would use the messaging package here and not set the appropriate handlers? But each project is different of course

[swizes]

Hi,

I have not needed any sort of remote handling and wondering if I am missing something. Can you give an example use case or few of using background message handler :) ?

[mikehardy]

@swizes it's a way for you to use cloud infrastructure (your own servers or Firebase Cloud Functions) in combination with device tokens, to send data directly from cloud to device. It's not easy to incorporate it reliably in the user experience but you can for instance have a sharing scenario where one user shows a QR code that is a Firebase Dynamic Link to their public profile in your app, and a second person that scans that QR code will go through an app install flow from the app store. On first app open your app will be able to tell it was opened via a dynamic link and you can forward directly to the first users profile page. You can have a "connect" button there for the second user and when they hit it, Firebase Cloud Messaging can come in to make a better experience. You can have your user association cloud function also generate an FCM message to the first user saying "hey! you've got a new connection to user XYZ". Could be just data and cause the app to refresh things or run things, could generate a user visible notification, you can do whatever you want, but it allows for positive confirmation.

Just one example.

A less reliable idea since it's data-only and those are not guaranteed execution is to send a data-only FCM to every app at 7am and 7pm and in response to the message your app can check whether the screen is on or not, or something similarly interesting for psychological research studies or user mindfulness management / quantified self purposes

[github-actions[bot]]

Hello 👋, to help manage issues we automatically close stale issues.

This issue has been automatically marked as stale because it has not had activity for quite some time.Has this issue been fixed, or does it still require attention?

This issue will be closed in 15 days if no further activity occurs.

Thank you for your contributions.

[edadma]

thinking that warning is very useful for developer experience, as nearly everyone that uses this package for notification listeners (as opposed to react-native-push-notifications if you just want some notification handling) wants the ability to handle FCM, which may come in the background.

If we were to add some sort of toggle that you could use to signal that no, you did not want a background handler, it would not in practice be much different than adding firebase.messaging().setBackgroundMessageHandler(() => {}); in index.js.

So, I can see how this warning could be a bit a bit off-putting but we are balancing a couple tensions at once, and there is a workaround I think.

What happens when you add a dummy handler as prescribed above?

Should be,

import messaging from '@react-native-firebase/messaging'

messaging().setBackgroundMessageHandler(() => new Promise((resolve) => resolve()))

[humaidk2]

+1 would be really nice to disable the js part of notifications. especially if u use sagas, events start firing and app state changes that could cause unnecessary issues if you're not using javascript, it doesn't make sense to load it. I did patch it and remove headless service from manifest file, seems to work for me.