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.

Recommend that users should now be on [email protected] and [email protected] or later.

The remaining issues (as of 2024-08-06) are as follows:

• Issues with channel ID and vibration pattern not being set correctly in notifications
  • Status: In progress
  • ENG-12759 and ENG-12770
  • Vibration pattern issue being fixed in [expo-notifications][Android] fix vibration pattern serialization #30495
  • Channel issue is being worked in [expo-notifications] Channel is ignored when the app is not in foreground #30762
• Issue with custom sound not working when app in background
  • Status: Investigating
  • Custom Sound for Expo Push Notifications Only Works in Foreground #27978 and ENG-12780
• Issue with complex remapping of notification payload on Android FCMv1
  • Status: Investigating
  • [expo-notifications] FCMv1 payload structure should be simplified #30533

Fixed issues:

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

The deadline for migrating to FCM V1 is 2024-07-22. See this link for up to date info from Firebase on the legacy API shutdown process.

Update 2024-09-08: It appears that the FCM legacy service is now fully shut down. Later this week, we intend to close this issue and lock comments. Any remaining or new issues should be created as new issues in this repo, per the usual process.

[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 [email protected] 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?

[douglowder]

@rranjan14 you cannot get notification responses in terminated state.

Thank you for responding. As I already mentioned, useLastNotificationResponse is what I already use as of now. But the thing is, i'll get the response only when I open the app. I want some advice regarding how can I immediately receive the response even in terminated state and process it?

We do not support that. It may be possible on Android, I am not sure. It is definitely not possible on iOS, as far as I know.

[jb-5murf]

Hi, I'm still having issues with notifications on Android. I'm testing on an old Samsung S9+ running Android 10. I'm using latest versions of libraries at this moment ([email protected], [email protected], [email protected]). I'm calling setNotificationChannelAsync before registering push token like this:

if (Platform.OS === 'android') {
    await setNotificationChannelAsync('default', {
        name: 'default',
        importance: AndroidImportance.MAX,
    });
}

I'm using Expo Push notifications tool with Channel ID set do 'default' and forced FCM V1 with { "value": "123" } in data.

I'm getting completely different data structure depending on the app state:

1. App is in FOREGROUND and I send notification = processed by addNotificationReceivedListener:

{
    "request": {
        "trigger": {
            "remoteMessage": {
                "originalPriority": 2,
                "sentTime": XXXXXXXXXX,
                "notification": {
                    "usesDefaultVibrateSettings": false,
                    "color": null,
                    "channelId": null,
                    "visibility": null,
                    "sound": null,
                    "tag": null,
                    "bodyLocalizationArgs": null,
                    "imageUrl": null,
                    "title": "Test notification",
                    "ticker": null,
                    "eventTime": null,
                    "body": "This is message body",
                    "titleLocalizationKey": null,
                    "notificationPriority": null,
                    "icon": null,
                    "usesDefaultLightSettings": false,
                    "sticky": false,
                    "link": null,
                    "titleLocalizationArgs": null,
                    "bodyLocalizationKey": null,
                    "usesDefaultSound": false,
                    "clickAction": null,
                    "localOnly": false,
                    "lightSettings": null,
                    "notificationCount": null
                },
                "data": {
                    "channelId": "default",
                    "message": "This is message body",
                    "title": "Test notification",
                    "body": "{\"value\":\"123\"}",
                    "scopeKey": "XXXXXXXXXX",
                    "experienceId": "XXXXXXXXXX",
                    "projectId": "XXXXXXXXXX"
                },
                "to": null,
                "ttl": 0,
                "collapseKey": "XXXXXXXXXX",
                "messageType": null,
                "priority": 2,
                "from": "XXXXXXXXXX",
                "messageId": "XXXXXXXXXX"
            },
            "channelId": "default",
            "type": "push"
        },
        "content": {
            "autoDismiss": true,
            "title": "Test notification",
            "badge": null,
            "sticky": false,
            "sound": "default",
            "body": "This is message body",
            "subtitle": null,
            "data": {
                "value": "123"
            }
        },
        "identifier": "XXXXXXXXXX"
    },
    "date": XXXXXXXXXX
}

2. App is in BACKGROUND or KILLED, I send notification and then open the app NOT BY TAPPING the notification in the notifications center = processed by getPresentedNotificationsAsync:

{
    "date": XXXXXXXXXX,
    "request": {
        "identifier": "expo-notifications://foreign_notifications?tag=FCM-NotificationXXXXXXXXXX&id=0",
        "content": {
            "subtitle": null,
            "priority": "default",
            "badge": null,
            "title": "Test notification",
            "sticky": false,
            "sound": null,
            "body": "This is message body",
            "autoDismiss": true
        },
        "trigger": null
    }
}

⚠️ Big issue - "data" field is missing in "content". ⚠️

3. App is in BACKGROUND or KILLED, I send notification and then open the app BY TAPPING the notification in the notifications center = processed by useLastNotificationResponse and extracting "notification" object:

{
    "request": {
        "trigger": {
            "channelId": "default",
            "type": "push"
        },
        "content": {
            "title": "Test notification",
            "body": "This is message body",
            "data": {
                "value": "123"
            }
        },
        "identifier": "XXXXXXXXXX"
    },
    "date": XXXXXXXXXX
}

It's the same in dev client and production build.
I don't see any notification bubbles regardless the app is in foreground / background.
Everything works fine on iOS.

[douglowder]

I'm using Expo Push notifications tool with Channel ID set do 'default' and forced FCM V1 with { "value": "123" } in data.

I'm getting completely different data structure depending on the app state:

@jb-5murf I took a look at this today. It is expected that the structure when the app is in background is going to be completely different, as that structure is synthesized from onCreate()/onNewIntent() intent bundles.

However, the missing data from getPresentedNotificationsAsync() does appear to be a real bug. We will be internally tracking this in ENG-13418.

[fawzii0x3]

I'm experiencing an issue where attachments included in a notification are not being displayed on iOS devices. The following code snippet shows how I'm setting up the notification:

const notificationAttachment = {
  identifier: 'image-001',
  url: 'https://example.com/sample.jpg',
  type: 'image/jpeg',
};

await Notifications.scheduleNotificationAsync({
  content: {
    title: 'Test Notification',
    body: 'This is a test notification with an attachment.',
    attachments: [notificationAttachment],
  },
  trigger: null,
});

[douglowder]

@jb-5murf I took a look at this today. It is expected that the structure when the app is in background is going to be completely different, as that structure is synthesized from onCreate()/onNewIntent() intent bundles.

However, the missing data from getPresentedNotificationsAsync() does appear to be a real bug. We will be internally tracking this in ENG-13418.

In testing this today, the missing data seems to be expected on Android. In debugging the native code, the call to the Android broadcast receiver to get the currently presented notifications does not receive the notification triggers that contain the data objects.

[avishekdev]

@douglowder can you please give me the current status that I had posted earlier regarding the useLastNotificaton() hook doesn't clear the last interaction/tapped notification from it's state? This bug creates a navigation loop inside the app. Thanks

[moppd]

@douglowder Could you give me the status regarding the custom sound not working when app in background?

[jb-5murf]

@jb-5murf I took a look at this today. It is expected that the structure when the app is in background is going to be completely different, as that structure is synthesized from onCreate()/onNewIntent() intent bundles.
However, the missing data from getPresentedNotificationsAsync() does appear to be a real bug. We will be internally tracking this in ENG-13418.

In testing this today, the missing data seems to be expected on Android. In debugging the native code, the call to the Android broadcast receiver to get the currently presented notifications does not receive the notification triggers that contain the data objects.

Thank you very much for your information. Do you have any idea when a fix might be released?

[nyenloop]

@douglowder,

My app is experiencing two issues that you marked as fixed above:

1. Null data payload in the client when receiving push notifications
2. Handlers are not being called when the app is in the background

Additionally, most notifications being sent are missing. These issues have only started happening around a week ago. Before that, everything worked fine. The app is still using Expo v48.

[douglowder]

@christopherwalter, @douglowder,

My app is experiencing two issues that you marked as fixed above:

1. Null data payload in the client when receiving push notifications
2. Handlers are not being called when the app is in the background

Additionally, most notifications being sent are missing. These issues have only started happening around a week ago. Before that, everything worked fine. The app is still using Expo v48.

A few days ago, we started seeing 100% failure rates from the Expo push service when sending to the FCM legacy endpoint. Per Firebase docs, it appears that they have now actually shut down the legacy service.

Accordingly, we have now modified the Expo push notification service to default to the new FCMv1 endpoint and protocol if the useFcmV1 parameter is not passed into requests.

Apps built with SDK 48 do not have all the recent changes that have been done in SDK 51 (and to some extent in SDK 50) to support the new protocol on Android. We recommend that such apps be upgraded to SDK 51.

[douglowder]

@jb-5murf I took a look at this today. It is expected that the structure when the app is in background is going to be completely different, as that structure is synthesized from onCreate()/onNewIntent() intent bundles.
However, the missing data from getPresentedNotificationsAsync() does appear to be a real bug. We will be internally tracking this in ENG-13418.

In testing this today, the missing data seems to be expected on Android. In debugging the native code, the call to the Android broadcast receiver to get the currently presented notifications does not receive the notification triggers that contain the data objects.

Thank you very much for your information. Do you have any idea when a fix might be released?

It is not yet clear that this can be fixed, but we are still investigating.

[iM-GeeKy]

@douglowder I have followed the documentation to Add Google Service Account Keys using FCM V1 and it works great, but whether it was the right approach or not, the legacy FCM server key was used for our dev and prod environments and served notifications for both landscapes. As a result, in the new approach it appears only a single FCM V1 service account key can be added via the UI. Is there a recommended way to tackle this problem? Ideally, it'd be nice to upload two (whether that is the best approach or not) or something along those lines to replicate the prior behavior.

[nyenloop]

@douglowder Unfortunately, I did not receive emails or instructions indicating that I needed to upgrade the Expo version soon, only to update the new FCM Server key. 🤦‍♂️

[douglowder]

@douglowder I have followed the documentation to Add Google Service Account Keys using FCM V1 and it works great, but whether it was the right approach or not, the legacy FCM server key was used for our dev and prod environments and served notifications for both landscapes. As a result, in the new approach it appears only a single FCM V1 service account key can be added via the UI. Is there a recommended way to tackle this problem? Ideally, it'd be nice to upload two (whether that is the best approach or not) or something along those lines to replicate the prior behavior.

Our solution for this has been to have different Android package names for development and production... the Firebase configuration can support multiple package names each with its own entry in google-services.json, but sharing a common FCM private key.

[iM-GeeKy]

@douglowder I have followed the documentation to Add Google Service Account Keys using FCM V1 and it works great, but whether it was the right approach or not, the legacy FCM server key was used for our dev and prod environments and served notifications for both landscapes. As a result, in the new approach it appears only a single FCM V1 service account key can be added via the UI. Is there a recommended way to tackle this problem? Ideally, it'd be nice to upload two (whether that is the best approach or not) or something along those lines to replicate the prior behavior.

Our solution for this has been to have different Android package names for development and production... the Firebase configuration can support multiple package names each with its own entry in google-services.json, but sharing a common FCM private key.

Would you mind sharing a small snippet of how you accomplished this (feel free to block out the sensitive values, I figured others might be interested in this in the future)? I appreciate the input!

[DSp4wN]

I'm experiencing an issue where attachments included in a notification are not being displayed on iOS devices. The following code snippet shows how I'm setting up the notification:

const notificationAttachment = {
  identifier: 'image-001',
  url: 'https://example.com/sample.jpg',
  type: 'image/jpeg',
};

await Notifications.scheduleNotificationAsync({
  content: {
    title: 'Test Notification',
    body: 'This is a test notification with an attachment.',
    attachments: [notificationAttachment],
  },
  trigger: null,
});

is this working in android?

[hramchandani]

Good day.

Over the past month or two (perhaps coinciding with the FCM v1 migration) I have started to experience inconsistent behavior while using the Expo push notification service.

I am not sure where the issue lies but it is causing a significant degradation in service for my end users. So I am hopeful it can be resolved as soon as possible.

At this point I do not feel it is an issue with the my application server side implementation (calling the expo push api) nor client side implementation (using the expo notifications package). I will state why as part of providing the full details below.

I am a user of my own application. I have been closely monitoring each push notification I should be receiving, and what I have seen is sometimes I receive the push notification and sometimes I don't.

Scenario 1:
Here is an example of the expo push api (https://exp.host/--/api/v2/push/send) being called and my app installed on my personal phone not receiving the notification:
Expo push ticket receipt: 0191f821-b489-72b1-a1fa-ee1688b58f1d
Date time sent: Approximately Sept 15 6 PM (GMT -6)
Result: Notification not received

Scenario 2:
Here is an example of the same scenario above being executed at another time but my app on my personal phone receiving the notification
Expo push ticket receipt: 0191fba0-8b91-7fa6-b8d6-1059e80bc649
Date time sent: Approximately Sept 16 10 AM (GMT -6)
Result: Notification received

In the case of scenario 1 I did call the https://exp.host/--/api/v2/push/getReceipts endpoint passing in the push ticket receipt and Expo confirmed the notification was successfully delivered.

For my mobile app I am using expo ~51.0.31 and expo notifications ~0.28.16

Kindly assist in any way possible in determining why the inconsistent behavior of my app receiving only some of the notifications being sent to it. I am concerned my other users are also experiencing this same issue leading to significant degradation in the service I am providing.

Thank you.

[viljark]

• @hramchandani are you calling the api with useFCMv1: true flag when sending out push notifications?

[hramchandani]

• @hramchandani are you calling the api with useFCMv1: true flag when sending out push notifications?

Yes I am.

[Codelica]

@hramchandani I think more info is needed to understand what you are seeing:

• Are you testing with Android or iOS? And if Android, are you using notification channels?
• Are there certain app states that align with you not receiving the push message? (app backgrounded, killed, etc).
• What call(s) are you using to handle notifications? Currently only useLastNotificationResponse and getLastNotificationResponseAsync are reliable across all Android app states.

[hramchandani]

@hramchandani I think more info is needed to understand what you are seeing:

• Are you testing with Android or iOS? And if Android, are you using notification channels?
• Are there certain app states that align with you not receiving the push message? (app backgrounded, killed, etc).
• What call(s) are you using to handle notifications? Currently only useLastNotificationResponse and getLastNotificationResponseAsync are reliable across all Android app states.

Hi @Codelica
Thank you for engaging with this issue. Here are my responses to the questions asked:

1. I am testing with Android. I have an Android phone. I do not have an iOS phone so I am not sure if this issue is occurring on iOS devices. As stated the issue occurs intermittently, During testing, push notifications were received on iOS devices. However, I am not sure if my iOS users are receiving all the notifications that are being sent to them.
2. I have not been able to narrow down the issue to any specific app state. This issue does not occur when the app is in the foreground. It does occur when the app is in the background and also when it is not started.
3. I am using useLastNotificationResponse to handle notifications.

If there is any other information I can provide, do let me know. Thank you.

[vonovak]

Hello and thanks everyone for contributing to the discussion.
There have been a lot of issues raised and questions asked. Many questions and issues were resolved but given the number of comments that have accumulated in the issue, it has gotten extremely hard to manage this and have a meaningful discussion.

I'm now locking the discussion because it has become almost impossible to find relevant information in it.

Status update:

• The Expo push service delivers all Android push notifications via the fcmv1 api.
• The SDK-51 branch https://github.com/expo/expo/commits/sdk-51/ contains several fixes for issues on Android which we will publish soon. When that's done, I will post an update here.
• The issue tracker still contains notification-related issues: see here. We are continuing to look into these issues and working on resolving them.
• If you're experiencing an issue which is not listed among the open issues, please open a new issue for your problem and follow the issue template. It's especially important that you include:

1. runnable reproduction
2. what behavior you're seeing (with steps to reproduce) and what you expect to see instead.
3. For push notifications: the request you're sending to the Expo push service in order to send the notification (especially the request body is important)
4. Add the "Notifications" label to the Github Issue - this helps with visibility.

If all this information is clearly laid out, we will be able to debug your issue and deliver a solution faster. Conversely, we won't be able to prioritize issues where important information is missing.

Thank you 🙂

[vonovak]

@jb-5murf I have looked into the issue you reported in #28656 (comment). Unfortunately, there's nothing we can do about the case "2" that you reported.

When calling getPresentedNotificationsAsync, Android OS provides us with a list of StatusBarNotification objects. There's no way to extract the data out of presented notifications. User needs to tap the notification for you to be able to read the data.

It may be possible to work around you problem by using data-only notifications, though I cannot 100% confirm it.

[vonovak]

Hello, just to confirm, latest fixes are published: https://www.npmjs.com/package/expo-notifications/v/0.28.17