Question posted in 
I am relatively new to Android programming and invested a lot of time in reading and testing all about Services and Push-Notifications. I have the requirement for my App to deliver reliable (in terms of delivery time under one minute) Notifications for Users. For this I have some Questions, which I still haven’t found an answer for:
-
Is FirebaseCloudMessaging (FCM) still “unreliable”. In reference to this statement from 2014, the Connection refresh rate by Google is with wifi every 15 Minutes and with mobile-connection every 28 Minutes https://productforums.google.com/forum/#!msg/nexus/fslYqYrULto/lU2D3Qe1mugJ. Is this still the case? Has Firebase a more reliable connection-management than GCM? I am aware that this doesn’t mean, that Notifications are pushed only after this time, but when a warning or error message has to be pushed to the user, the possibility that die connection has failed and is re-established only after 15 Minutes is not acceptable for my use-case.
-
What is the best way to create a Service for Android, which holds an connection to a Server and listens for Messages. My problem is, that (especially with API-Level 23 /Android 6.0 and its radical Power Management) every Service is paused or stopped nearly immediately. Even a Wake-Lock is not reliable that is is somehow released after one hour. Yes, i could try to merge all ways to reactivate the Phone or the App (Timer, Alarm, Delayed Handler, Wake-Locks, …) to Hold a connection, but it is still possible that all these fail and my warning is not delivered. Am i missing something here?
-
Is is possible to create a deamon for non-rooted devices which is not likely to be killed by the System? Is is possible to create someting like a watchdog, to observe a Service and its state, and restart it, if necessary?
-
How is this implemented by big Apps like Facebook or Whatsapp? Is Facebook still using MQTT?
-
Are there any OpenSource Projects which implement such a service?
2
Answers
1) Notifications sent via GCM / FCM are still quite unreliable and unsuitable for real-time, mission-critical delivery. The heartbeat intervals have slightly decreased since 2014, but popular apps like WhatsApp and Facebook still make use of their own push notification solutions, implemented using the XMPP and MQTT protocols. This must mean that FCM is not reliable enough yet for mission-critical delivery.
2) Dealing with the recent power-saving optimizations in recent Android versions becomes more and more difficult in regards to maintaining a background connection for push notifications. Doze mode will kill your service’s network connectivity and Background Execution Limits will terminate your service when your app goes to background.
3) A foreground service comes to mind, but this will require your app to display a non-cancelable notification while the service is running. The system will not terminate your foreground service as long as it is running, but the obvious drawback is that your app must display this notification which the user will probably find annoying. Otherwise, try using the JobScheduler APIs to adapt your service to the new battery optimization features.
4) As mentioned, WhatsApp still uses XMPP and Facebook Messenger still uses MQTT.
5) You may be able to find and piece together several open source projects to achieve this, such as the paho.mqtt.android client library and Mosquitto broker.
Alternatively, consider a paid product, Pushy (https://pushy.me/) which provides reliable push notifications via a fine-tuned MQTT socket. The SDK includes support for recent Android OS battery optimizations.
Full disclosure – I founded Pushy.
You may need to use Oksocket on your client and maybe solve the problem.
Your problem is very common in China, as FCM/GCM is prohibited in this country. Apps developed in China use OkSocket communication library, and implement Notification, Alert, or RPC based on TCP/IP transmission protocol provided by OkSocket.
https://github.com/xuuhaoo/OkSocket this is the library in Github.