1

I'm sending a data-message via FCM with HIGH priority.

curl -X POST -H "Authorization: Bearer ya29.c.b0AXv..." -H "Content-Type: application/json" -d '{
  "message": {
    "topic" : "mytopic",
    "data": {
      "message": "my_unique_data"
    },
    "android":{
      "priority":"high"
    },

  }
}' https://fcm.googleapis.com/v1/projects/myproject/messages:send

After receipt - I call a notification. If Android is active, this works.

But if the smartphone's screen is off, and the smartphone is stationary for a while, and I send the data message again, the notification doesn't show up until I little move the phone.

I guess the Android is in DOZE mode, but the documentation states that a high-priority message FCM puts the smartphone out of this mode.

Help solve the problem, please.

Igor Antoshkin
  • 11
  • 4

2 Answers2

0

There are 2 reasons this may be happening (from here):

  1. There are high priority notification quotas for each app, and if you send too many of those notifications, the OS will de-prioritize them
  2. Google requires that there is some kind of user interaction with the high-priority FCM messages (to prevent abuse by developers). So, if you send "hidden" FCM notifications that, for example, show up in a silent notification channel, your app's quota will be de-prioritized. Also, the user needs to either open the app, or click on the notification within some interval (I didn't see the actual time frame documented). If they don't, it gets de-prioritized as well.
  3. List item

So, it sounds like your app's FCM quota was de-prioritized, and you'll need to figure out which scenario applies

user496854
  • 6,461
  • 10
  • 47
  • 84
0

In general, you are correct, as stated in:

FCM is optimized to work with Doze and App Standby idle modes. FCM high priority messages let you reliably wake your app to engage the user. In Doze or App Standby mode, the system delivers the message and gives the app temporary access to network services and partial wakelocks, then returns the device or app to the idle state. For time sensitive, user-visible notifications, consider using high priority messages to enable delivery in Doze mode. High priority messages are expected to result in notifications. See FCM's guidance on high priority messages for more information.

How ever, they also mention:

lmost all apps should be able to support Doze by managing network connectivity, alarms, jobs, and syncs properly, and by using FCM messages. For a narrow set of use cases, this might not be sufficient. For such cases, the system provides a configurable list of apps that are partially exempt from Doze and App Standby optimizations. An app that is partially exempt can use the network and hold partial wake locks during Doze and App Standby. However, other restrictions still apply to the app, just as they do to other apps. For example, the app’s jobs and syncs are deferred (on API level 23 and below), and its regular AlarmManager alarms do not fire. An app can check whether it is currently on the exemption list by calling isIgnoringBatteryOptimizations().

Sometimes, OEM's also change the behavior of doze mode which creates bit different functionality than those stated in Google's documentation. So I'd suggest following their tip in the documents:

Users can manually configure the list of exempted apps in Settings > Battery > Battery Optimization. Alternatively, the system provides ways for apps to ask users to exempt them: Most apps should invoke an intent that contains the ACTION_IGNORE_BATTERY_OPTIMIZATION_SETTINGS. Apps that satisfy an acceptable use case can instead invoke an intent that contains the ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS intent action to let the user add the app to the exemption list directly, without going to system settings. Note: Google Play policies prohibit apps from requesting direct exemption from Power Management features in Android 6.0+ (Doze and App Standby) unless the core function of the app is adversely affected. An app can check whether it is currently on the exemption list by calling isIgnoringBatteryOptimizations().

I believe this should fix your problem

Doc - https://developer.android.com/training/monitoring-device-state/doze-standby

Dan Baruch
  • 1,063
  • 10
  • 19