Argthtjtr

According to FCM documentation high-priority messages might become de-prioritized, if the FCM server detects a pattern in which high-priority messages do not result into user interactions. The details of this mechanism are left unspecified. Questions:

• How exactly does this work?


• How does the detection algorithm gathers the data?


• For how long are messages de-prioritized?

Secondly, the Android app has a method that checks how old the most recently received message is. This methods sometimes reports wrong results, if messages with normal priority have not been delivered yet but are still cached at the FCM server. Question:

• How can make the Android app to fetch all messages first?

Some optional background information:

I am writing a monitoring app for some safety critical application. The on-premise server can be in one out of two mutually exclusive states: "idle" or "alarm". The state is sent via FCM to all registered clients. To ensure that the server is still running, the state is periodically broadcasted as a heartbeat. These heartbeat messages are sent with normal priority. Moreover, whenever the state changes from "idle" to "alarm" an additional, offbeat message with high priority is sent immediately. E.g. the sequence of messages is something like

...  idle  idle  idle  *alarm*  alarm  alarm  alarm  idle  idle  ...

As the first alarm message in a row triggers a notification and all other messages have only normal priority, there is (hopefully) no risk of being de-prioritized by FCM.

The Android app incorporates a PeriodicWorkRequest that serves as a watchdog and checks if the heartbeat is still coming in. If the most recently received message is too old (older than 30mins), a "Connection lost" notification is displayed to the user to warn him.

Here is the problem:

The usual heartbeat messages have normal priority and are cached at the FCM server. The watchdog raises a false "connection lost" notification. The device is woken up (due to the notification) and suddenly the most recent heartbeat message comes in (they are collapsed at the server).

I see two solutions (or workarounds):

• Make all messages high-priority messages, so that they are delivered immediately and the watchdog always sees the most recent message. However, I fear that the FCM de-prioritization algorithm kicks in. (99,95% are boring "idle" messages)




• Before the watchdog checks the time of the latest message and eventually raises a warning, I have to ensure programmatically that all messages have been fetched.

Side note:

I totally understand why Google is enforcing more and more restrictions on background executions and asynchronous tasks. (Broadcast receivers have become more or less useless, AlarmManager has been restricted, JobScheduler can be deferred and Android 9 introduces the concept of "standby buckets".) Many developers have abused these APIs to do insane things for which a better (battery-friendly) solution would have existed. However, all these restrictions make it a very hard job to implement a safety-critical application that is governed by legal regulations, that must provide reliability guarantees and therefore requires line-monitoring of an unreliable network.

All the power management mechanism do not seem to consider safety-related scenarios. The user has no intent to use the app (which is perfectly fine) and no news are good news in this particular case. I.e. the app simply stays in the background. Unfortunately, the app is categorized into the standby bucket for "rare" apps and the app gets penalized which is not good.