Query Android 13 onBackgroundEvent vs getInitialNotification

[dorisaward]

I have an android 10 device and an android 13 device.

When the app is exited on the android 10 device and a notification is pressed, onBackgroundEvent handles the notification correctly.
However, on the android 13 device, onBackgroundEvent doesn't pick up the notification. Only getInitialNotification works.
If I implement both there are issues on android 10 as the notification is being handled twice.
Is this how notifee is supposed to be working? The documentation makes it appear that getInitialNotification should not be required in my case.

[pavelustenko]

If I implement both there are issues on android 10 as the notification is being handled twice.

Hi! You can use Platform.Version to avoid double handling
https://reactnative.dev/docs/platform
For downvoters:
This is just workaround. I totally agree, that the documentation should preferably be more complete.

[github-actions]

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.

[Yupeng-li]

We noticed some android 12 or 13 devices can trigger onBackgroundEvent when launching the app from a notification, but some cannot. It's unclear what the difference between them yet.

[Darex1991]

Same situation, any ideas? I saw for sure it is not working for me on android 13 Samsung's devices ie Galaxy S23.
To reproduce:
I have active app, I'm sending firebase notification, I'm killing app and click notification. App is opening but onBackgroundEvent is not running so not able to interact somehow

[github-actions]

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.

[liamjones]

Not stale

[github-actions]

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.

[liamjones]

Not stale

[mikehardy]

Indeed - hopefully I'm able to reward your faith in this repo with some solid maintenance, it's a struggle but I am here and watching

[github-actions]

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.

[liamjones]

Not stale

[github-actions]

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.

[liamjones]

Not stale

[github-actions]

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.

[liamjones]

Not stale

[github-actions]

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.

[liamjones]

Not stale

[github-actions]

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.

[Yupeng-li]

Not stale

[github-actions]

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.

[Yupeng-li]

Not stale

[github-actions]

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.

[Yupeng-li]

Not stale

[github-actions]

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.

[liamjones]

Not stale

[Eclipses-Saros]

I was wondering about this; after Android 12, onBackgroundEvent won't receive events when app was killed. I don't know why, but it does. so let's just say answer first: you should filter onBackgroundEvent and use getInitialNotification. (note: getInitialNotification returns same data when you do hot-reload.)

this comment (#616 (comment)) says onForegroundEvent, but I'm not sure It's working. in my device, I can only receive data from getInitialNotification. really confusing.

We noticed some android 12 or 13 devices can trigger onBackgroundEvent when launching the app from a notification, but some cannot. It's unclear what the difference between them yet.

check #621 (comment). If some devices can fire event, but some others not, you can suspect reactContext might be null.

[Yupeng-li]

Hi @Eclipses-Saros, thanks for the heads up. The first comment you shared is about iOS. On android, when you launch the app (app was closed), the onForegroundEvent will not fire.

We run the same app on different devices, but they have different behaviours. Is it possible that reactContext is null on some devices but not on others?

[Eclipses-Saros]

okay, I'll make the answer more clearly:

"reactContext is null" problem is you cannot receive any notification events whether foreground or background. because reactContext is null, native library cannot emit events and nothing happened at all. however, I'm not sure notification from killed (exited) status also emit background event. and as far as I know, getting notification data when app was killed is a different.

The first comment you shared is about iOS. On android, when you launch the app (app was closed), the onForegroundEvent will not fire.

I remember notifee fires onBackground event when you press the notification at the app was closed; (https://notifee.app/react-native/docs/events#background-events) but looks like now it's no longer do it. (I'm not sure, but at least my android devices won't send any background events when it's killed)

If you want to receive data from onBackground event but some devices won't do this, reactContext might be a problem. you should check context exist first. also, double-check permission and policy settings to make sure it's working.

If not (just want to receive notification data on boot), try to use notifee.getInitialNotification(). it should be there. I'm currently check all initial notifications from firebase messaging and notifee.

const firebaseNotification = await messaging().getInitialNotification();
const notifeeNotification = await notifee.getInitialNotification();

(if there is NO data exists, then that is an another problem)

Is it possible that reactContext is null on some devices but not on others?

well... yes. I have two Android devices, which versions are 12 and 14. both are have same problem: reactContext is null. but once I tested someone's device, there is no problem. weird.

[github-actions]

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.

[liamjones]

I don't believe this is stale but I've not had a chance to check the latest Notifee releases to see if behaviour has changed

[mikehardy]

This may be fixed in v9.1.2 here - there was definitely a problem with new architecture if it was in use, and it would not work until v9.1.2 just now

[liamjones]

We (Doris, Yupeng and I) are on old architecture still but we'll give it a retest on 9.1.2 when we're able to do the upgrade.

[badalsaibo]

What I expect is notifee.onBackgroundEvent to fire when I receive a notification. I have rnfb already integrated and notification comes wonderfully when in background, but the``notifee.onBackgroundEvent` is just not firing. I'm on the latest version 9.1.2. Firebase one works beautifully in background.

messaging().setBackgroundMessageHandler(async (remoteMessage) => {
  console.log('setBackgroundMessageHandler', remoteMessage);
});

notifee.onBackgroundEvent(async ({ type, detail }) => {
  const { notification, pressAction } = detail;
  console.log('notifee on background event', { type, detail });
});

EDIT: So the onBackgroundEvent fires only for event and not when message comes