3 ms·

FCM is integrated in kernel, so it cannot be killed. And it starts a persistent TCP connection to Google server. If all apps uses FCM, then all notification wou

by 188201 8y ago

FCM is integrated in kernel, so it cannot be killed. And it starts a persistent TCP connection to Google server. If all apps uses FCM, then all notification would route through this connection, and this significantly reduce battery consumption than the alternative, where each app uses its own web socket server. So, assume using a degoogled android, can this notification replaced FCM if more apps use this notification server? This server uses web socket, so what does FCM use for its connection? Does web socket battery efficient enough?

gruez 8y ago
>FCM is integrated in kernel, so it cannot be killed. What do you mean it's "integrated in kernel"? Are you saying google play services includes a kernel module?
- londons_explore 8y ago
  It does not. It's a plain-old TCP connection in GMSCore, but has special permissions to ignore various power save modes. I personally wish Google would work with mobile networks to replace it with something lower level (eg. Based on the same thing used to initiate phone calls), because a hanging TCP connection open for many hours gets unreliable as NAT drops it and as the phone migrates from one mobile network to another (eg. Across country boundaries)
  - sofaofthedamned 8y ago
    That was how BlackBerry worked wasn't it?
- nimrody 8y ago
  It's handled by Play services which is whitelisted to allow network access when the device is in light/deep doze mode. Play services can also instruct Google's servers to stop sending notifications when the device is in deep doze and re-open the connection when the device is active again -- thus saving power (messages are queued at Google's servers)
qwertox 8y ago
FCM uses XMPP https://firebase.google.com/docs/cloud-messaging/xmpp-server-ref https://firebase.google.com/docs/cloud-messaging/xmpp-server... I really like the idea of Google providing a single, efficient connection for push-notifications, but having it bundled with Firebase (and therefore with Google Play Services) is an unfriendly approach.
- damian2000 8y ago
  XMPP is only one option for communicating with the FCM server. The most popular method is using HTTP/REST. XMPP is only needed when you have bidirectional messages - server to client app (downstream) and client app to server (upstream).

by 188201 8y ago

gruez 8y ago

>FCM is integrated in kernel, so it cannot be killed. What do you mean it's "integrated in kernel"? Are you saying google play services includes a kernel module?

londons_explore 8y ago
It does not. It's a plain-old TCP connection in GMSCore, but has special permissions to ignore various power save modes. I personally wish Google would work with mobile networks to replace it with something lower level (eg. Based on the same thing used to initiate phone calls), because a hanging TCP connection open for many hours gets unreliable as NAT drops it and as the phone migrates from one mobile network to another (eg. Across country boundaries)
- sofaofthedamned 8y ago
  That was how BlackBerry worked wasn't it?
nimrody 8y ago
It's handled by Play services which is whitelisted to allow network access when the device is in light/deep doze mode. Play services can also instruct Google's servers to stop sending notifications when the device is in deep doze and re-open the connection when the device is active again -- thus saving power (messages are queued at Google's servers)

qwertox 8y ago

FCM uses XMPP https://firebase.google.com/docs/cloud-messaging/xmpp-server-ref https://firebase.google.com/docs/cloud-messaging/xmpp-server... I really like the idea of Google providing a single, efficient connection for push-notifications, but having it bundled with Firebase (and therefore with Google Play Services) is an unfriendly approach.

damian2000 8y ago
XMPP is only one option for communicating with the FCM server. The most popular method is using HTTP/REST. XMPP is only needed when you have bidirectional messages - server to client app (downstream) and client app to server (upstream).