Retrieve FCM data payload from active notifications

Question

We have a back-end server that sends FCM push notifications with a data payload to Android and iOS devices. I am working on the Android app. When the app is in the foreground, onMessageReceived is called and the data is retrievable from RemoteMessage. When the app is in the background, a system notification is posted. A user clicks this and the data is retrievable from the Intent extras. All is well.

I am trying to figure out how to handle the case of multiple notifications coming in while the app is backgrounded or dead. The desired behavior is to "suck in" any active notifications and be able to retrieve their data payloads. I can get and clear (cancel) the active notifications using the NotificationManager (API >= 23), or implementing a NotificationListenerService. I have not been able to figure out a way to get the data payloads associated with them. The StatusBarNotification.getNotification().extras seemed promising but did not contain the data. I have even used the Android Studio debugger to inspect the notifications returned from getActiveNotifications() and have not found anything.

I think the "correct" answer, from my research, is to send the "notification" portion for iOS pushes, but omit it for Android pushes (ie. data only), and then post my own notifications locally on the device when my app is not in the foreground. Then onMessageReceived should always get called and I can save away the data payloads and have complete control. However, I am not sure we can change the back-end server to support a split Android/iOS path at this point. And from I've read, I have concerns about the service not being called on certain devices if the app is killed.

So, does anyone know of a way to retrieve the data payload of other active notifications? Or have alternative methods of going about this without requiring back-end server changes?

Thanks!

Answer 1

I think the "correct" answer, from my research, is to send the "notification" portion for iOS pushes, but omit it for Android pushes (ie. data only), and then post my own notifications locally on the device when my app is not in the foreground. Then onMessageReceived should always get called and I can save away the data payloads and have complete control.

this is the correct approach. (currently the only available)

However, I am not sure we can change the back-end server to support a split Android/iOS path at this point.

We are working on improving the API to better support your use case.
Unfortunately I cannot share an ETA for that work.

And from I've read, I have concerns about the service not being called on certain devices if the app is killed.

Those devices would not receive notification-messages neither :( .
Those devices don't even receive AlarmManager events, and neither system broadcast.
If you encounter such device please contact the manufacturer and let them know that their behavior is not standard and it's breaking your app.