expo-notifications FCM V1 Migration Tracking Issue

[christopherwalter]

This is a tracking issue for user-reported issues related to the Spring 2024 migration of Expo Push Notifications from FCM Legacy to FCM V1 for Android devices. There have been reported instances of brokenness in production when moving from FCM Legacy to FCM V1, and this issue will serve as a central place to track our investigation and resolution of these issues.

The known issues are as follows:

• null data payload in client when receiving push notifications
  • Status: Fixed, see [expo-notifications][Android] Ensure response is correctly mapped in useLastNotificationResponse hook #28938
  • Published in expo-notifications@0.28.4
• handlers are not being called when app is backgrounded
  • Status: Fixed, see these comments from @douglowder
• handlers are being called when app is foregrounded, but app resets itself (seen in development build, unconfirmed in production)
  • Status: Fixed
• Notification icon not working
  • Status: Fixed in [expo-notifications][Android] Fix FCMv1 icons and NPE #29204, and fix is published in expo-notifications@0.28.5
• useLastNotificationResponse() has null data
  • Status: Fixed

Here is a table showing the overall state of these issues, as of 6/11. Package versions are expo@51.0.11 and expo-notifications@0.28.8:

App State	Sound	Banner	Icon	Data	Badge Count
Foreground	✅	✅	✅	✅	In Progress
Background	✅	✅	✅	✅	In Progress
Killed	✅	✅	✅	✅	In Progress

New issues filed in expo/expo will be merged into this tracking issue for easier management. The deadline for migrating to FCM V1 is June 20.

[fdelu]

Something else I noticed that might be worth noting is that notification images (not icons) don't seem to be working when the app is in the foreground.

Edit: Just to clarify, I tested this by sending the request to the FCM V1 api directly

[haplionheart]

To add on to "the notification icon is not working", on Android I'm finding that the icon displays when the app is in the foreground. But I get a blank circle as an icon when the app is in the background

This is happening with a development build

[jnoleau]

No issue with the icon when we add the correct name/value pair on the Android manifest but it seems there is no "plugin" on the package expo-notification or this one is not working as expected.

But this issue can be fixed "simply" by adding a manual plugin specified here #24844 (comment) in addition to the config.notification.icon in the app.config

[zandvakiliramin]

Hi,
I am facing the same issue,
I am using expo-server-sdk: 3.10.0 to send notifications. When I change the useFcmV1 to true on Android, my app does not get the data from the notification, and the icon shows a blue circle with thick borders. When I set it to false, everything works. On iOS, everything works fine.

I am using Expo SDK 49.

[krazykriskomar]

#24844 (comment)

For me, the plugin here is unnecessary because the AndroidManifest that's created seems fine. I have 2 notification_icon additions.
<meta-data android:name="com.google.firebase.messaging.default_notification_icon" android:resource="@drawable/notification_icon"/>
and
<meta-data android:name="expo.modules.notifications.default_notification_icon" android:resource="@drawable/notification_icon"/>
I also see mapping files declaring the png and naming it to the correct asset name.
I am on expo 51.0.2 and expo-notifications 0.28.1 (both latest).
On prebuild, the png file is processed and correctly placed into all the xdpi drawable asset out put folders.
I've also triple checked with our UX designer that the requirements are met: it's a white-only transparent PNG at 72 dpi at 96x96 pixels exactly.
Hopefully this info helps someone. I think there's been a mismatch of actual problems going on between expo 49, 50, and 51, because the manifest is now correct and I no longer need the withFirebaseMessagingNotificationIcon plugin.

[NickTillinghastKrazy]

Something else I noticed that might be worth noting is that notification images (not icons) don't seem to be working when the app is in the foreground.

Edit: Just to clarify, I tested this by sending the request to the FCM V1 api directly

I have the same issue on IOS.

[douglowder]

PR #28883 has been submitted to fix the Android notification response issues when app is in background or not running.

[briazzi64]

PR #28883 has been submitted to fix the Android notification response issues when app is in background or not running.

Awesome. thank you so much for tracking this down for all of us. Any idea when it will be available?

[krazykriskomar]

PR #28883 has been submitted to fix the Android notification response issues when app is in background or not running.

Awesome. thank you so much for tracking this down for all of us. Any idea when it will be available?

Second that! Really need it :)

[krazykriskomar]

0.28.2 didn't fix anything :(

[fdelu]

In my case I can confirm that with the new version, useLastNotificationResponse now does get notifications received when the app is in the background (sent with FCM v1)
However in that same scenario I'm not getting the full request payload, the data is missing. Trying to debug if it's something I can change on my end to fix it

[douglowder]

@fdelu see the fix that was just added in #28883 , specifically the new method in NotificationSerializer.java, toResponseBundleFromExtras():

https://github.com/expo/expo/pull/28883/files#diff-385373049872662646fd4faf3b47aea7c97480a25b6de9a96259bef1e856d790

That is the method that takes the bundle passed into onNewIntent() when the notification is opened while the app is in the background, and constructs the notification response object.

If you are missing part of the payload, you should have a look to see if there are parts of the bundle that are not being mapped by NotificationSerializer.java. The payload is being logged to logcat in ExpoNotificationsLifecycleListener.java:

https://github.com/expo/expo/pull/28883/files#diff-f558167185b0f06ac4e093b7f22c59f01ca8096f127a1605245962f0927ed7e1

[douglowder]

@fdelu in looking at this further, it may be that you rebuilt your Android app with the new expo-notifications package, but did not rebuild your JS bundle to pick up the required changes on the JS side: https://github.com/expo/expo/pull/28883/files#diff-37b24aeb2e0d5d7c4365c987c51f03db4b6d20a0927f3eefe0d9e0a35b2c4df7

The data is passed as a string from Android native to the JS code, and is unpacked there, so if you did not rebuild your bundle with the new library, the data would indeed be missing.

[fdelu]

@fdelu in looking at this further, it may be that you rebuilt your Android app with the new expo-notifications package, but did not rebuild your JS bundle to pick up the required changes on the JS side: https://github.com/expo/expo/pull/28883/files#diff-37b24aeb2e0d5d7c4365c987c51f03db4b6d20a0927f3eefe0d9e0a35b2c4df7

The data is passed as a string from Android native to the JS code, and is unpacked there, so if you did not rebuild your bundle with the new library, the data would indeed be missing.

Yes, that seems like it. I noticed later that I had "dataString" but not "data" so I'm probably missing that. Not sure how that happened though. Thanks for your help!

[deivijt]

After updating to expo-notifications@0.28.2 and building, this works 🎉. Thanks, @douglowder. Great work! 👏

... the only minor issue is that the notification icon is not displaying correctly with FCM V1.

[douglowder]

Fix for #28883 has been published. Pick up latest expo package (51.0.7) and do npx expo install --fix to pick up expo-notifications 0.28.2. You will also get a new version of expo-dev-client that fixes an unnecessary reload issue on Android (see #28893).

[fdelu]

@fdelu in looking at this further, it may be that you rebuilt your Android app with the new expo-notifications package, but did not rebuild your JS bundle to pick up the required changes on the JS side: https://github.com/expo/expo/pull/28883/files#diff-37b24aeb2e0d5d7c4365c987c51f03db4b6d20a0927f3eefe0d9e0a35b2c4df7
The data is passed as a string from Android native to the JS code, and is unpacked there, so if you did not rebuild your bundle with the new library, the data would indeed be missing.

Yes, that seems like it. I noticed later that I had "dataString" but not "data" so I'm probably missing that. Not sure how that happened though. Thanks for your help!

An update on this @douglowder: I verified and it is using the latest version.

When my app is in the foreground, I get a notificationd and click on it, I see the "response received" log and everything works fine. However, when my app is closed (fully), I get a notification and click on it to open the app, then I don't see that "response received" log, the "data" field is missing and the request content contains the "dataString" field.

Looking at the code for useLastNotificationResponse, I believe this happens because in the first scenario, the notification comes from the response received listener, which does parse the "dataString" (that's the change from the link you sent me). In the second scenario though, the notification seems to be coming from getLastNotificationResponseAsync which does not parse the "dataString".

Another issue I've been having is that if I get a notification when the app is open, I fully close it and then I reopen the app by clicking the notification, useLastNotificationResponse returns an almost empty notification. My code:

  const notification = useLastNotificationResponse();

  console.log("LAST RESPONSE", notification);
  console.log(
    "LAST RESPONSE CONTENT",
    notification?.notification?.request?.content
  );
  console.log(
    "LAST RESPONSE TRIGGER",
    notification?.notification?.request?.trigger
  );

The logs:

 LOG  response received: {
  "notification": {
    "request": {
      "trigger": {
        "channelId": null,
        "type": "push"
      },
      "content": {
        "title": null,
        "dataString": null,
        "body": null
      },
      "identifier": null
    },
    "date": 0
  },
  "actionIdentifier": "expo.modules.notifications.actions.DEFAULT"
}
 LOG  LAST RESPONSE {"actionIdentifier": "expo.modules.notifications.actions.DEFAULT", "notification": {"date": 0, "request": {"content": [Object], "identifier": null, "trigger": [Object]}}}
 LOG  LAST RESPONSE CONTENT {"body": null, "dataString": null, "title": null}
 LOG  LAST RESPONSE TRIGGER {"channelId": null, "type": "push"}

[douglowder]

@fdelu yes indeed that is a bug! I think cutting and pasting the new code from NotificationEmitter should fix it... I really appreciate you taking the time to track that down.

[christopherwalter]

Hi folks, if you're in this thread due to icon-related issues (@deivijt @zandvakiliramin @haplionheart):

Can you try using a config plugin like in this comment to ensure the correct fields are in your manifest? And let me know if that changes anything?

@krazykriskomar re: your comment here, I wasn't sure if you have it working or not? Can you confirm if icon behavior is correct for you when sending notifs using FCM V1?

[mgscreativa]

@codercoder292, please check out my demo repo which applies the last patch needed for this to work https://github.com/mgscreativa/expo-notifications-test

[mgscreativa]

Just tested expo-notifications@0.28.9 and it works just fine. Updated test repo here https://github.com/mgscreativa/expo-notifications-test

useFcmV1=true

App State	Sound	Banner	Icon	Data
Foreground	✅	✅	✅	✅
Background	✅	✅	✅	✅
Killed	✅	✅	✅	✅

[NoZiL]

There is an issue after updating to the latest version.

When using useFcmV1=true in the Master App for push notifications: - In terminated or background state, the top alert does not appear, but the push notification is received. - In terminated state, when the push notification is touched, the link data is missing. (data)

Resolved Issues:
    - Icon is displayed correctly.
    - Link data is available in the background state.

• only android
• sdk 51
• expo-notifications 0.28.8

I am facing the same issue migrating to fcm v1, I found out that the notification that I get from getLastNotificationResponseAsync when app is killed has unparsed "dataString" instead of "data". After going up the thread, I found that the issue was already discussed.
I did not found out yet why the parse did not occurred.

If you want to quickfix it, you can do something like:

const url =notification.request.content.data?.url ?? JSON.parse((notification.request.content as any).dataString)?.url;

[Codelica]

@codercoder292 and @NoZiL are you doing a fresh build after updating to expo-notifications 0.28.8? The symptoms described (like banner not appearing, missing/unparsed data) all required native code fixes.

A few suggestions:

• Use the latest expo-notifications which is currently 0.28.9
• For configuration (in app.json / app.config.js) for the notifications plugin, include defaultChannel set to whatever channelId you use, and any icon/color info. For example:

[
  "expo-notifications",
    {
      "icon": "./assets/images/android-notification.png",
      "color": "#D84F4F",
      "defaultChannel": "default"
    }
]

• Consider using the useLastNotificationResponse() hook to handle notifications, as I know that's what several of us who have been testing are using successfully across all Android app states.
• Make sure you do a fresh build, as expo-notifications has updated native code that's needed.

[mgscreativa]

expo-notifications is at v0.28.9 at the moment

[leabaertschi]

I just tested 0.28.9 and I still have the issue that I don't get any payload using useLastNotificationResponse:
{"date": 1718267477072, "request": {"content": {"body": null, "dataString": null, "title": null}, "identifier": "0:1718267477079609%3c054adc3c054adc", "trigger": {"channelId": null, "type": "push"}}}

We don't use the expo service to send push notifications, we send them directly to the firebase API using the API V1. The request we send to firebase looks as follows:

{"message":{"android":{"notification":{"body_loc_args":[],"body_loc_key":"mobile.pushNotification.ScanLoginQRCode.body"}},"data":{"_type":"ScanLoginQRCode","_data":"{\"timestamp\":\"2024-06-13T10:25:00.870066531Z\"}"},"token":"TOKEN"}}

Can you see any issue with that request or can you point me to where this is handled in the native code so I can provide more information?

[NoZiL]

hi @Codelica @mgscreativa , thanks for your time.

All dependencies were up to date, plugin config and a fresh build also, only difference was your 3rd point, I was using getLastNotificationResponseAsync.
I managed to make it work with the hook useLastNotificationResponse instead of getLastNotificationResponseAsync

Odd thing is the useLastNotificationResponse hook documentation states:

If you don't want to use a hook, you can use `Notifications.getLastNotificationResponseAsync()` instead.

but the handling of dataString parsing seems to differ.

Here are my latest tests results:

App State	Sound	Banner	Icon	Data (useLastNotificationResponse)	Data (getLastNotificationResponseAsync)
Foreground	✅	✅	✅	✅	✅
Background	✅	✅	✅	✅	✅
Killed	✅	✅	✅	✅	❌

FYI: The expo-notifications docs uses the getLastNotificationResponseAsync instead of useLastNotificationResponse

Following are my snippets for testing, used the code from the hook documentation for he hook usage and from the expo docs for usage without hook:

export function useNotificationObserverWithFunc() {
  React.useEffect(() => {
    let isMounted = true;

    async function redirect(notification: Notifications.Notification) {
      const url = notification.request.content.data?.url;
      if (url) {
        router.navigate(url);
      }
    }

    Notifications.getLastNotificationResponseAsync().then((response) => {
      if (!isMounted || !response?.notification) {
        return;
      }
      // ❌ => case killed state, notification has unparsed `dataString`
      redirect(response?.notification);
    });

    const subscription = Notifications.addNotificationResponseReceivedListener(
      (response) => {
        // ✅ => case foreground/background state, notification has parsed `data`
        redirect(response.notification);
      },
    );

    return () => {
      isMounted = false;
      subscription.remove();
    };
  }, []);
}

export function useNotificationObserverWithHook() {
  const notification = Notifications.useLastNotificationResponse();
  // ✅ => all app states, notification has parsed `data`

  React.useEffect(() => {
    const url =
      notification &&
      notification.notification.request.content.data.url;
    if (
      url &&
      notification.actionIdentifier ===
        Notifications.DEFAULT_ACTION_IDENTIFIER
    ) {
      router.navigate(url);
    }
  }, [notification]);
}

[douglowder]

Today's updates:

• Background tasks have been tested and seem to be working correctly with expo-notifications 0.28.9 (expo-notifications background task with registerTaskAsync not working as expected #29622)
• Working on backport to SDK 50 (Merge expo-notifications FCMv1 fixes to SDK 50 #29714)

[Codelica]

@NoZiL to be honest that doesn't really surprise me. Notifications for Android in the killed state have been an issue for a loooong time -- far before useFcmV1 was introduced (which just added to the complications) @nakedgun and @douglowder patched various issues that got us to a "working" plugin for useLastNotificationResponse() which we were testing with, but it doesn't surprise me that there are other code paths which may still be broken. Hopefully now that there is at least one "usable" scenario (with useLastNotificationResponse()) prior to next week, some time can be taken to more systematically trace the message paths inside the Android code.

[jludwiggreenaction]

I've been trying to test FCMV1 after upgrading to the newest push notification version and run into two issues:

useLastNotificationResponse default behavior has changed

When the app is launched without any pending notification present, useLastNotificationResponse always returns something with an empty payload (e.g. content.data is undefined).

It should be returning just null or undefined if no notification was pressed, as indicated by the typescript types. In no instance should it be returning a null for the payload data.

If there is a pending notification pressed, useLastNotificationResponse works as expected. It's only when there was no notification pressed that the behavior is wrong.

---

Different behavior across legacy and FCMV1 notifications

So far I've only tested with https://expo.dev/notifications sending notifications to a client running expo notifications 0.28.9, but I'm noticing different behavior when I force legacy vs force v1.

When forcing legacy, there is a banner and vibration (working normally).

When forcing FCMv1, there is no banner or vibration.

When forcing FCMv1 with a channel id explicitly set to default, there is no banner, but there is a vibration -- albeit the pattern is not the same as when using legacy.

Are these differences just due to the testing tool or have defaults been switched up somewhere?

[douglowder]

@jludwiggreenaction thanks for the report. I do have a documentation task ENG-12500 where we will be updating docs to reflect all the recent changes, and what happens with FCMv1 (since that will soon be the only option). We will either adjust the doc for useLastNotificationResponse(), or fix that behavior to match what is documented.

[douglowder]

For SDK 50 developers only, expo-notifications 0.27.8 has just been published, containing all the recent FCMv1 fixes backported to SDK 50.

If you are staying with SDK 50, I do recommend that you upgrade to expo 50.0.19 and do npx expo install --fix to get all SDK 50 fixes from other packages, before adding expo-notifications 0.27.8.

SDK 51 developers should use expo-notifications 0.28.9.

[appsgenie]

@douglowder thank you for porting down to SDK 50.
Since SDK 49 is still live and supported, we for sure will not get this fix into this version?

[douglowder]

@appsgenie we do not plan to backport these changes to SDK 49. I took a look at doing this, and unfortunately there were a lot of incompatible changes to expo-notifications between SDK 49 and SDK 50, making this backport tricky and higher risk for regressions.

[jludwiggreenaction]

@jludwiggreenaction thanks for the report. I do have a documentation task ENG-12500 where we will be updating docs to reflect all the recent changes, and what happens with FCMv1 (since that will soon be the only option). We will either adjust the doc for useLastNotificationResponse(), or fix that behavior to match what is documented.

@douglowder Thanks for the info, however I think that task is not public so I can't see the details. I can adjust for the changes regarding the default channel and return value for now anyway.

I narrowed down the other issues I had to being problems with the channel id: The channelId field in the notification request is not being respected.

I was opting to not set the new defaultChannel property in the expo configuration since I was already going to specify channelId in the server side. To me it seems like that should lead to the same behavior.

When using the testing tool or using the API myself, the notification is not being sent to the specified channel anyway (it's always going to the default "Miscellaneous" channel).

Setting the defaultChannel property in the app.json and using that channel does work as expected, though.

[collinahn]

Hi again.

Anyone facing notification not displayed(no banner, no vibration, not added to status bar) when unread notification count is over 24+?

    "expo": "^51.0.13",
    "expo-notifications": "^0.28.9",

when received notification, adb log shows nothing weird compared with unread notification less than 24.
all the hander & listeners for notification regardless of app state works

notificationHandler
notificationReceivedListener
notificationResponseReceivedListener
they all handled notification received correctly, but push notication itself is not visible to user when unread ones are over 24.

[DSp4wN]

I am using following packages:

"expo": "~51.0.13",
"expo-notifications": "~0.28.9",

I tried testing notification using force fcmv1 in my development build through the expo push notification tool and I am still unable to get the notification data when the app is killed rest all cases are working as before.

Hooks being used to test:
-getLastNotificationResponseAsync
-addNotificationResponseReceivedListener

P.S. I am able to receive notification and their icons properly

[Codelica]

I narrowed down the other issues I had to being problems with the channel id: The channelId field in the notification request is not being respected.

I was opting to not set the new defaultChannel property in the expo configuration since I was already going to specify channelId in the server side. To me it seems like that should lead to the same behavior.

When using the testing tool or using the API myself, the notification is not being sent to the specified channel anyway (it's always going to the default "Miscellaneous" channel).

Setting the defaultChannel property in the app.json and using that channel does work as expected, though.

@jludwiggreenaction I was suspicious of this and planned on testing it once I had time -- but you beat me to it. I think the only way to avoid that built-in default "Miscellaneous" channel in the background and killed states is via the new defaultChannel property at the moment. For those utilizing multiple channels, that will be an issue of course.

Currently I think the only safe route for things to "work" on Android across all app states in SDK v51 is:

• expo-notifications 0.28.9
• Setting a defaultChannel property for the plugin to the channel you use (only allows for 1 of course)
• Use the useLastNotificationResponse() hook for responses.

Using other listeners and methods can result in issues currently as @DSp4wN and others have seen, as will not setting defaultChannel or using previous versions of expo-notifications depending on how you send your notifications.

[appsgenie]

thank you @Codelica
I am also trying to find the best functioning setup now that I've upgraded to SDK 51.

So for channel, if I use multiple channels in my app but also the default one, then just put defaultChannel = default in the config?

as for useLastNotificationResponse, what is this even used for I am a bit confused? is this ONLY if we want to leverage deep links and if we have some sort of navigation framework? like I've never used this and I think was fine. What does that give me that addNotificationReceivedListener and addNotificationResponseReceivedListener can't give?

[appsgenie]

Also do you guys know if the icon property can be a url to an icon hosted on my website? or it now has to be a local file always?
or what are the cons and pros for doing one vs the other?

[DSp4wN]

@Codelica, So I have to make use of useLastNotificationResponse only ?

[Codelica]

thank you @Codelica I am also trying to find the best functioning setup now that I've upgraded to SDK 51.

So for channel, if I use multiple channels in my app but also the default one, then just put defaultChannel = default in the config?

@appsgenie Yes, as far as I know your only real option is to pick one for now and set it as defaultChannel. Everything should then get delivered to that channel, but if users have different notification settings based on channel or if you do things differently when a notification is touched based on channel that will probably have issues. I'm not sure if setting the channelId on a message will change it properly when the app is the the foreground off hand. Also not sure if setting channelId on a message will still make it through in the actual notification data, but I think it will -- at least I saw it coming through during some testing. Although it won't actually be used for the delivery by Android in some states.

as for useLastNotificationResponse, what is this even used for I am a bit confused? is this ONLY if we want to leverage deep links and if we have some sort of navigation framework? like I've never used this and I think was fine. What does that give me that addNotificationReceivedListener and addNotificationResponseReceivedListener can't give?

It serves the same basic function as other listeners/methods -- giving you information on the notification that was touched. So it just depends how/if you use that notification data in your app in some way. But currently I think useLastNotiicationResponse() is the only safe way to get the full notification information (including custom data) across all Android app states (foreground, background, killed).

[Codelica]

@Codelica, So I have to make use of useLastNotificationResponse only ?

@DSp4wN I think that's currently the only reliable way to get all notification information (including custom data) across all app states (foreground, background, killed). At least that's what a couple of us were using during testing here. It's not to say the other listeners and methods won't work work fine in some states, but that hook is the only one I know is safe across the board since that's what I'm using.

[mgscreativa]

Remember guys that you can check test repo here https://github.com/mgscreativa/expo-notifications-test, it's used by me to test latest modifications/patched by the community and @douglowder

[douglowder]

@DSp4wN @Codelica :

I think that's currently the only reliable way to get all notification information (including custom data) across all app states (foreground, background, killed). At least that's what a couple of us were using during testing here. It's not to say the other listeners and methods won't work work fine in some states, but that hook is the only one I know is safe across the board since that's what I'm using.

This is correct. Specifically, you need the useLastNotificationResponse to capture the notification response when tapping a notification to open the app from a non-running (killed) state. The reason is that the native code is processing the response before the JS code has time to fully initialize and call addNotificationResponseReceivedListener to set up your response listener. The native code can cache the response in the native structure used later by useLastNotificationResponse, so that hook will still work.

We will be adding some text on these issues soon when we update our documentation.

[appsgenie]

@douglowder and @Codelica, I am sure you are aware of this (sorry if I am stating the obv) but this killed state notification issue on Android has been there for a long time. I found my solution a while back (I think from #11933). I know that it was solved for me (at least in the older SDK versions) by placing the addNotificationResponseReceivedListener very high in the app structure. Like above App class for me. That solved the issue and even in killed state it was passing the response fine.

I am in the middle of upgrading to SDK 51 to see if my existing code as-is still works in killed state so TBD.

Currently dealing with Constants.installationId that finally got removed in SDK 51 😄 and I depend on it from the start so trying to get to the notification part but struggling ...

[Codelica]

@appsgenie I think you'll find that previous hack (listener very early in code) no longer works, at least as of v51 and useFcmV1. I was using something similar. But as long as you implement with useLastNotificationResponse() you won't need it. Which should simplify things for you.