I’ve been banging my head against this issue for several days. Push notifications work fine in every scenario except for when the app is closed on android. (It works fine on iOS when the app is closed, and it also works on android when the app is open or has been recently opened.) Here’s the rundown of my app setup, to preempt some basic questions:
Standalone app on android and iOS, using Expo (not ejected)
Using FCM for notifications, was running SDK 28 and updated to 29 to see if it would fix issues (it didn’t)
All of the push notification receipts return “OK” when I check the ID against the API
As I mentioned, push notifications work just fine on iOS and in android when app has been recently opened; this behavior can only be reproduced if app is entirely closed with force stop or a phone restart
My app requires a login that is restricted to my company in order to receive notifications, so I can’t include the app here to reproduce. It would be very helpful to know if others are experiencing this as well or have any pointers if they have run into it before. Could someone confirm for me that they can indeed receive notifications on a standalone Expo android app when the app is closed?
Steps to reproduce:
Long hold on the standalone app icon on android, go to app info, and tap “force stop”
Go to the expo push notification tool online and enter in the push notification token to send: Push Notification Tool — Expo
Check to see if a notification has appeared on the android device
Although I’m not sure this issue is fully resolved, I have made some headway.
I’ve read inconsistent information about how android apps in general receive notifications after the app has been force closed; some say that the android OS blocks the app from receiving any notifications whatsoever after the app has been force closed, and others say there are workarounds. I did try force closing a separate non-Expo app and triggered a push notification and didn’t receive anything, so it does seem to be part of a larger pattern in android apps in general. If there is any sort of workaround for this, it would be great to see it in Expo.
I think the larger issue I had was that I had called the Notifications.addListener() function inside of a component that was displayed within the root component but not the root component itself. I had to do some really deep digging online to find some stack overflow issues on React Native that said notification listeners had to be defined on the root component and not inside of anything that requires a render, because when an app has been closed and is opened when receiving a notification, it does not render anything. I was able to get it working when I put the notification listener in the componentDidMount() function of the root component.
It would be great to update the Expo documentation to specify that the listener needs to be added to the root component in a non-rendering function in order to fire; it currently says that notification handling is not even necessary in Android, which does not seem to be the case if the app is closed.
I think it is the default android-behaviour. Its the same with ‘native-android’-apps:
When app is forced stop: notifications are not working; Some brand-specific devices may act differently, but when I test on ‘pure android’ like the android-simulator with google-play image or an ‘android-one-device’ —> then I realize this default behaviour
When app is closed by ‘recent-apps-button’ → ‘select app’ → ‘wipe right or left’: now the app is still ‘enabled’ but closed: notifications are working good
@anil_from_the_alps Thank you for confirming that force stop will prevent notifications from sending. I think that was a separate issue, unfortunately, but I’m glad that piece of the puzzle has been solved. I’m still noticing that the majority of the time when my device is asleep that an FCM push notification never reaches the device, and not shown either while it is still asleep or after it has been woken up. Frustratingly, it’s not 100% consistent, so it can be difficult to reproduce, but I’m noticing that more times than not I never receive a notification when my phone is asleep, even though Expo is returning “ok” from the push receipt. I’ve seen this behavior not only with my own backend, but also directly using the Expo online notification tool with a specific push token.
@mlight It would be great to get some more information from the Expo team on this. I’m curious if the new firebase implementation behaves differently. The Expo docs say that notification handling is not even necessary on android, and that it will be taken care of by the OS, but I’m not sure that it is still an accurate statement. Dozens of times now I’ve seen push notifications that were successfully sent by every measure but that never appear on the actual device, and I’ve noticed differences in behavior depending on if the app has been recently opened or not. I’ve also read inconsistent information online about the differences between FCM “notifications” and “data” messages and whether the different types will start up an app that’s unopened or not. I noticed in my firebase dashboard that 100% of the pushes being sent from Expo are the “data” type, so maybe that’s part of the issue. I’m not knowledgeable enough on these matters to say for sure.
For what it’s worth, iOS notifications are working 100% of the time for me, so that’s why I suspect an issue with FCM.
After further testing, I can verify and reproduce a consistent issue with FCM push notifications not being received on an android device when the device is in doze mode. Because android emulator devices can receive push notifications and also be placed programmatically into doze mode, this should be easy for others to reproduce as well without having to be concerned with different device OSes, etc. I have tested with priority set to both “high” and “max” and have seen the same behavior. When the phone is awakened from doze mode, the notification still does not appear.
I’m running a Pixel 2 emulator with API 28 installed; I haven’t tried other emulator devices, but I imagine behavior would be similar, as I’m seeing the same behavior on an actual device with a different device/OS
Install an Expo standalone app on the emulator by dragging and dropping the apk file onto the device, with notification permissions turned on, and make sure push notifications are allowed by logging into the device with a google account
If you send a notification using Expo’s notification tool and the device’s push token, verify that the notification is successfully received, to establish that baseline notification functionality is working
Per the documentation above, on the command line, run adb shell dumpsys deviceidle force-idle to put the emulator into doze mode
Send a notification once again – for me, it does not appear
Wake the device from doze mode using the command: adb shell dumpsys deviceidle unforce For me, the notification sent during doze mode also does not appear after waking.
Send another notification after waking. I see it arrive successfully.
I hope that helps to reproduce the issue for others. This is a really big deal that users can’t receive push notifications that are sent while the device is in doze mode, as that is generally when most notifications are sent! It’s really the primary use case for push notifications. I sincerely hope that we can get some help from the Expo team on this one, as push notifications are pretty much a moot point on android devices because of this issue. Thanks!
(Note: I also just opened a github issue if anyone would like to track it or add their support if seeing the same issue: https://github.com/expo/expo/issues/2194)
Thank you very much for the detailed report on this issue. I just pinged internally regarding this and hopefully we can get back to you soon with some more information.
Just wanted to let anyone following this know there’s been some action on this issue in github, looks like there’s a pretty simple workaround by setting priority to high on the server side when sending a notification: https://github.com/expo/expo/issues/2194 Seems to be working for me so far, woohoo! Thanks!
Sorry for the delay. Glad you found a easy to use workaround in the mean time, we were starting to dig into this yesterday when Google started doing their audit for Advertising ID requests so we had to shift focus to that. Hopefully we’ll have something concrete for you soon.