How can I implement push notifications on Android without using Firebase cloud messaging and Google play services. I would use MQTT, but I don't know how would I handle it on Android client. Background services are very restricted since Oreo, and I see no way of keeping reliable connection to MQTT broker when app is in background.
I was thinking AlarmManager and starting scheduled jobs to check for new messages, but Android seems to ignore that while in "Doze" mode.
I could have foreground service running constantly but that just seems wrong.
Maximum tolerable latency between sending and receiving notification is 20-30 seconds.
There are some 3rd party services that offer push notifications, how are they doing it?
I need to be independent of FCM because Google is blocked in China, and that's my use case.
Related
I've been reading about non-standard app killing on https://dontkillmyapp.com/. In particular, I'm worried about how manufacturers are implementing mechanisms under the name of 'battery optimisations' which cripple the local notification API, by cancelling all alarms scheduled by an app after some time of inactivity: AlarmManager not working in several devices
Since there is no fix we as developers can implement to make local notifications work reliably, I'm wondering if I can just switch to push notifications. But I'm also not sure whether I can rely on push notifications, as there seems to be conflicting information:
Signal seem to say that their push notifications may be unreliable when battery optimisations are at work, though it's not clear whether this only applies to their custom web-socket push notification system, which it apparently uses when FCM isn't available: https://support.signal.org/hc/en-us/articles/360007318711-Troubleshooting-Notifications#android_notifications_troubleshooting_phone
It seems that push notifications which are sent via Firebase Cloud Messaging (FCM) will actually be received by the Google Play Services, so is it possible they may be received even if your app has been 'battery optimised'?
Can anyone shed some light on this? Can push notifications via FCM be more reliable than local notifications, when working around non-standard app killing?
Push notifications will work but still they will be affected by battery optimizations. Things like Doze mode will make your app poll-rate depend on things like user's usage of the phone; battery-level and etc.
There are things that we just cannot fight as developers and if the underlying OS decides that your app won't wake up it's better that the user gets a better phone...
Apparently using FCM is no guarantee that notifications will be received - they may still fail to show due to non-standard battery optimisations.
This is documented by the following article:
https://hackernoon.com/notifications-in-android-are-horribly-broken-b8dbec63f48a
Which states that:
Google GCM said that the notification was sent but there was no trace of the notification in the app’s logs, it was as if the OS was swallowing notifications
After disabling battery optimisations, the notifications apparently worked again. Their workaround to this issue was:
GCM delivery receipts essentially tell you whether the device received the push notification or not. We coupled this with duplicate notification delivery receipts from inside of the app. So any device where we got ack’s from GCM but not from the device, was potentially missing pushes. Once the devices were identified, we started sending them bot messages on how to add flock in their device’s auto-start list.
I wonder how to push notifications to my Flutter app users in both Android and iOS devices Without using any external service like Firebase or OneSignal?
I want to implement a code in PHP which can send push real time notifications to all/spesific users in my Flutter app which works in both Android and iOS.
I found some solutions like flutter_local_notifications with workmanger which can fetch the API in the background only minimum 15 minuts. Workmanger is Not good solution because its work only during 15 min and it will consume the battery and internet.
I need an efficient solution to my flutter app for both Android & iOS devices, which can listen on real time to the coming messages from the server even when the app is closed.
How to fix that? thanks
iOS
You will always need to integrate with Apple's Push Notification Server (APNS) if your app needs make API calls in the background. The reason is that once an app is put into the background, iOS will often put the app to sleep soon afterwards.
The correct approach to this is to use a silent push notification to wake up the app. When received, no message is shown on device but the app get's about 30 seconds in order to make API calls.
In your case, the app can make the API call and then schedule a local push notification to display your message.
Background updates via push notifications
Scheduling local push notifications
Android
It looks like WorkManager is your best bet. I don't see how it can affect battery.
FYI
You don't need to use Firebase or OneSignal for push notifications, silent or otherwise. They are simply 3rd party services that interact with the official Apple or Google Push Notification Servers.
Unfortunately, I think this is not possible. Even OneSignal uses the Firebase API to deliver the notifications, as you can see here. For all other solutions, you will have to balance the update frequency with internet use and battery consumption.
Goal
Create a long-running background service with a network connection, similar to Zello app.
Problem
Starting with API level 26 (Oreo), there're tight restrictions on background services and their network activity.
Looking at the Zello app which has a constantly running background service which is able to accept audio and text messages even if the device is sleeping, I wonder how they achieved that?
Their service is not running on the foreground. Also, it doesn't look like they use push messages for that, since the app works quite stable in conditions where there's a problem with push messages reception (e.g. low-end Xiaomi phones).
Any ideas would be appreciated.
From what I gathered these apps use the Firebase Cloud messaging service:
https://firebase.google.com/docs/cloud-messaging/
The Firebase Service is embedded in the Android system and maintains a constant network connection to the firebase server. The apps then contact the firebase server which in turn to notifies the destination device.
Advantages:
The Android system is responsible of keeping the server connection alive and running
The network load is minimized because one connection is used for all apps using the firebase service.
Disadvantages:
All data is sent through the firebase server and is therefore (in theory) directly accessible by Google
Depedning on how many devices use your app, you need to pay for the service.
A similar question asked might be helpful in tackling the problem too:
How does push notification technology work on Android?
These apps don't have long-running services with constant network connections. They use push notifications. When there is a new message for a user, the server sends a push notification to wake the device up.
I'm using startForeground to run a service in my app. Does this impact Play Store auto updates when it's running? It seems like it does because I'll release a new version and a test tablet will still be running the old one for days after the release. The app shows "pending update" in Google Play on the device.
As background, this is not a normal consumer app and does need to run all the time to sync data. Without the foreground service I found even persistent alarms would stop running in a timely fashion after a few days, so as far as I'm aware, startForeground is the only way to keep the app running permanently.
Thanks for reading!
You can create an application which the Android system puts under whitelist application.
Under certain circumstances, a background app is placed on a temporary whitelist for several minutes. While an app is on the whitelist, it can launch services without limitation, and its background services are permitted to run.
An app is placed on the whitelist when it handles a task that's visible to the user, such as:
Handling a high-priority Firebase Cloud Messaging (FCM) message.
Receiving a broadcast, such as an SMS/MMS message.
Executing a PendingIntent from a notification.
Starting a VpnService before the VPN app promotes itself to the
foreground.
So you can create a high-priority FCM message for your update and send it as an update notification or just a blank message.
Set Up a Firebase Cloud Messaging Client App on Android
I just started developing with Parse's Push Notifications. I'm using them for pushing to Android right now and when I just started off, the notifications were delivered fast (instantaneous delivery).
However, as I'm sending more and more notifications to the same device - I'm noticing that it is taking about 10 minutes to deliver the notifications. Is this normal? If not, is this an issue with Parse or GCM?
Is there any way to "simulate" the notifications for development purposes so that they can be tested?
I'm generating the notifications from the REST API and have a Wifi enabled device.
According to my experience in GCM or any other related service, should only be used if you have to push notification to some target devices i.e. to selected users from your database.
--For Higher scalability and maintainability
You should make background service instead to fetch the notification and create a api for that, as there would be direct integration through your server, its is reliable fast and it has higher accuracy.
Whereas gcm does make a background service and hit gcm server and responds accordingly, but sometimes it misses the notification or delay as per the server load.