My question is about standard remote push notifications on iOS and Android devices when the app is terminated.
In a nutshell:
There are different app states/modes:
Foreground
Background
Suspended
Terminated
There are different notification types:
Normal Notification (contains alert information)
Data/Silent Notification (contains data payload)
Mixed Notification (alert and data)
For foreground, background and suspended mode it is clear and does work very well on iOS and Android. Dependent on the notification type the expected behavior as stated in the docs.
But it seems there is an essential difference in remote notifications for iOS and Android when the app is terminated.
For iOS: If the app is terminated (not suspended) a standard remote notification is received by the iOS system and displayed in the notification center. There is no delegate called and the app is not put to background mode (not even if remote push background mode is enabled). When the user clicks the notification the app is started and the notification object is provided via the appropriate delegate. Summarized: The user can receive push notifications on his device even if the app was force-quitted.
For Android: When the app is terminated a standard remote push notification is not displayed in the notification center. (As soon the app is started and put to the background the notifications are received and displayed properly.
The documentation is very unclear because only foreground and background mode are mentioned.
https://firebase.google.com/docs/cloud-messaging/concept-options
https://firebase.google.com/docs/cloud-messaging/android/receive
There are many discussions that conclude that remote notifications are not displayed in the system tray (notification center) after the app as been force-quitted. But there is quite less discussion about the expected behavior after device restart and not starting the app.
But there are also discussions indicating that remote pushes are always displayed in the system tray, even if the app has been terminated (Android push notifications not being received when app closed). That would be the same behavior as for iOS.
To get to the point: Is it possible on Android to send remote push notification to the device's system tray, even if the app is terminated/force-quitted/not running?
I can answer now my own question: It is possible to send push notifications to Android devices (in the notification center) while the app is not running.
The issue with notifications not being delivered was caused by Huawei's EMUI and specific battery saving settings. On Huawei P8, P9 and probably many other devices with EMUI the apps are not allowed to receive notifications when not running. They must be authorized explicitly in the battery saving settings.
Related
In Firebase push notifications, the payload can be of type "notification" or "payload", but they arrive (or not) depending on whether the app is in background or not and other details. Please clarify them.
(This answer focuses on Android devices)
Firebase Cloud Messaging (FCM) push notifications can be of three types : notification, data and notification+data.
Notification messages are meant to be received by the Android operating system itself, with no intervention by the app. When received by Android, they will be shown as a notification in the tray. Some details:
The tray notification will not be shown if received when your app is in the foreground.
You can implement a FirebaseMessagingService (see the data payload for more info on this), which will receive the message if your app is in the foreground. In your FirebaseMessagingService, you can show a tray notification yourself (or do whatever you want) when you receive the message.
When sending the message, you can specify what happens when the user clicks on the notification; this can be controlled by either specifying an activity in the click_action Android-specific option (see this) or by specifying an URL in the link property and having your app configure an intent filter associated with the URL you specified.
Data messages are meant to be received by an Android service of your app. This service can, in principle (see below [*]), receive the messages when your app is in the foreground, in the background, or not running at all. Some details:
To implement the service, you have to extend FirebaseMessagingService and configure it in your app's manifest.
When you receive the message in your FirebaseMessagingService, you can decide to emit a local notification to be shown in the tray. You can do this either when your app is in the background or in the foreground, in principle (see below [*]). Of course, you may also decide to do other stuff instead (or apart) of showing the tray notification.
[*] Some phone manufacturers, especially Chinese ones like Xiaomi and Oppo, implement some mechanisms to save battery that include killing services. This means that, by default, your FirebaseMessagingService will not be running on those phones unless your app is on the foreground and, therefore, it will NOT receive your data payloads when your app is not on the foreground. There is no way around this, except if the user whitelists your app specifically. The famous apps like Whatapp or Gmail are by default included in the whitelist, but yours won't; therefore, if you rely on data payloads and you want your app to work on that kind of phones, you'd better guide your user to configure their phone to allow it; here you can see how to do it for Xiaomi (Miui) devices. This can also happen in vanilla Android devices since Android 9 (API level 28) with background restrictions, but the behaviour is opposite: your service won't be killed unless the user requests it; you can check this with ActivityManager.isBackgroundRestricted
Notification + data messages include both types of payloads. They behave exactly like notification payload-only messages:
When your app is in background, Android shows the notification in the tray. The data payload is accessible to the app if it receives the intent invocation when the user clicks (described above) in intent.extras.
When your app is in foreground, your FirebaseMessagingService receives the notification with the contents of the data payload.
Current Implentation:
When event is generated at server I am sending notifications to android app using FCM, some notification are with normal priority and some with high priority.
When notifications with high priority are sent to android app, app trigger custom alarms with sound to inform user about event.
It is working in android 5,6,7 without any issues.
Issue:
In phones with android 8+ I am facing issue of late notification due to Doze mode and App Stanby mode, so notifications are sent on time but received late on phone with delay of 20-25 minutes
What I have tried:
I have done all required settings like keeping Power saving disabled, Keep app rinning in background, Autostart enabled, Priority notification are enabled,
Also sending notifications with normal and high priority but still issue not resolved.
I have tried using foreground service but that remains active untill app is open, as soon as app is closed service stops.
How to send emergency alerts from server to android app in realtime even when app is closed? Using foreground service or by using other channel?
I am using nativescript-plugin-firebase for the APP and I get the notifications when the app is closed.
However, if the app is open I don't get any notifications. Is there any way to force showing push notifications even when the app is open or do I have to create a custom notification with sound within the app?
Another problem that I have is the way the push notifications are displayed. I use Laravel-FCM to send push notifications from the server-side, I have the priority set to 'high' and everything else set to default but when I receive the notification to the android device there is no floating notification, only a badge icon and a notification in the notifications center.
In the app notifications settings, there is Miscellaneous Notification Category with Importance set to Default, Vibration set to OFF and LED Light is also OFF but if I manually change those settings then firebase notifications appear with floating notification and vibration.
Any way to actually make these notifications with high priority by default?
P.S. The device I am testing on is Xiaomi Redmi Note 8 Pro
I have the same problem when using Nativescript-firebase as yours. When the app is open, the push notification is delivered but not shown (see onMessageReceived callback) then you can use Nativescript-local-notification to show the content of the push notification received when app is open.
Customers can turn off push notifications at the app level. When that happens, we all know the the notification tray UI will not show up. But,
Does GCM/FCM (android) and APNS (iOS) continue to deliver notification to the customer's phone regardless ?
Specifically, on android & iOS, will I be able to execute some logic in the push event listener regardless of whether the user turned the push notifications on/off ?
In Android, when we disable push notifications, does the OS automatically unregister the app from GCM/FCM ?
Note:
I am NOT interested in background app refresh on iOS or background refresh through WorkManager on Android. I am NOT interested in iOS silent notifications or other kinds of Background Executions.
My question is specifically whether the code block is invoked (or not) when push notifications are turned off at app level (using the toggle).
I am not sure about the android, but in iOS this thing is possible.
You can do this but just keep in mind, that Background App Refresh is enable in device.
For more details, look into this link
https://www.urbanairship.com/blog/watch-list-ios-8-opt-in-changes
I hope you get your answer from above link
I am working on a Cordova Android app that handles push notifications using the PushPlugin. The app will correctly receive push notifications when the app is open. However no push notifications are received (or at least handled) if the app is not open.
This makes some sense given that the plugin has code that specifically handles receiving push notifications. What does not make much sense to me is why this code even exists at all. Before building this app, I assumed that the OS had some sort of queuing system that received any/all notifications.
Does a notification queue exists in Android that handles push notifications for all apps or does each app need to handle the notifications on their own.
Can Android apps process push notifications while closed?
Can Cordova Android apps process push notifications while closed?
In Google Cloud Messaging (which is the push notifications mechanism used by the PushPlugin) each application decides how to handle the notification. When a push notification arrives to the device, GCM triggers a BroadcastReceiver in the recipient application, and the application is responsible for handling the notification data.
Android apps can process push notifications when closed unless they are explicitly stopped by the user (in which case no notifications will reach the app until it is restarted again by the user). If they leave the foreground by the user switching to another app or going to the home screen, the can still receive and process notifications.
Yes. According to the PushPlugin you posted a link to, it seems that they can. When the app is not in the foreground, the notification is handled differently - a notification is added to the notification bar, and when it is tapped, it should open the app.
With PushPlugin, when sending push notifications to GCM (for GCM to send them to the device) one has to include a msgcnt key value pair after the message key value pair in the payload value in the JSON message, like this:
{
"GCM":"{\"data\":{\"message\":\"hello\",\"msgcnt\":\"1\"}}"
}
or else PushPlugin will not handle the notification when the app is in the background. It has to do with the way the GCMIntentService.java file is written in the plugin.