3

I'm working on a messaging app where messages need to come through so we're sending our messages as "High Priority" to bypass Doze.

In Android P they added a new thing called "App Standby Buckets" which limit how many FCM messages you can send if the app isn't in the "active" or "working set" app list.

The buckets are detailed at this link

https://developer.android.com/about/versions/pie/power

The documentation also says

If, in response to a high priority message, a notification is displayed in a way that is visible to the user, then your app standby bucket quota will not be consumed by that message.

If the screen is off and the notification sound plays, but the user doesn't see or interact with the notification since the screen is off, will that count against our bucket limit?

These notifications need to come through and being placed in the frequent or rare bucket could be very problematic.

I know we can request permission to bypass battery optimizations (I believe we fall in the allowed category) but there's no guarantees that will be granted.

Henry
  • 17,490
  • 7
  • 63
  • 98
Ben987654
  • 3,280
  • 4
  • 27
  • 50
  • Did you find the answer for this? – Henry May 26 '20 at 07:55
  • No, I never did. I was recently getting more reports of delayed FCM messages so added logging to show me which StandBy bucket they are in. I don't have lots of logs submitted with the new logging yet, but what I have noticed is that when battery optimization is ON, they are in the whitelisted bucket (5), and when they aren't, even if they were listed as active when active (10) and working set (20) when not in immediate use, overnight when the device was not in use they were being shoved into rare (40). Going from active to working set to rare in the same day seems bonkers to me. – Ben987654 May 27 '20 at 00:58
  • I know it's been almost 2 years since you posted last update on this, but I wonder if you can provide some more insight since then? Also does the "sound" matter in this context? We want to use FCM high priority message with a visible notification but no sound. – thankyoussd Jan 13 '22 at 21:12
  • 1
    @thankyoussd I don't believe the screen off causes a problem, we haven't been getting enough reports of problems that I would expect in those circumstances. However, Samsung is up to their old tricks and completely ignores a users usage of the app, and puts people into the Rare (40) bucket indiscriminately, even if they used the app multiple times that day, and daily, which has caused problems. Any bug report we get now includes a users standby buckets for the past 24h, and if it's got a 40 in it, we tell them to disable battery optimizations. – Ben987654 Jan 14 '22 at 01:09
  • 1
    @thankyoussd Also, our notifications themselves are silent, and we play sounds via soundpool as the sounds are server driven. I don't know if that counts as sound or no sound in terms of the notification itself? – Ben987654 Jan 14 '22 at 01:12
  • @Ben987654 Thanks a lot for your help. So we're just implementing this now. My understanding is that we can make the high-priority FCM message itself a "Data message" without the "Notification" property set, so it can be guaranteed to hit `OnMessageReceived`. Then in this method itself, as long as we manually generate some notification that is "visible to the user", Android will not count this message against the bucket quota. Is this correct? Thanks again. – thankyoussd Mar 13 '22 at 16:59
  • @thankyoussd ya that should be fine, but standby buckets going into 40 even though they use the app daily will still cause interference as they are separate. E.g 10 during day but goes to 40 overnight because Samsung thinks they are asleep and shouldn't be alerted – Ben987654 Mar 13 '22 at 23:59
  • @Ben987654 I'm just a little confused, doesn't the "If, in response to a high priority message, a notification is displayed in a way that is visible to the user, then your app standby bucket quota will not be consumed by that message." wording imply that if we make the notification visible, it should *not* count against the quota, hence it shouldn't matter if Samsung puts our app in rare or active? – thankyoussd Mar 14 '22 at 01:08
  • @thankyoussd Samsung will put an app into the rare bucket if they decide a user doesn't use the phone frequently at a specific time of day (usually evening/overnight). If they put your app in the rare bucket it will override your high priority notification. It has nothing to do with quota's. I've seen dozens of bug reports where they are in the 10 bucket during the day time and 40 in the evening repeated over multiple days. The only way around this is to have them disable the samsung battery optimizations. – Ben987654 Mar 14 '22 at 06:07
  • @thankyoussd From the docs (I think it's added since my original post?) "By contrast, when the prediction uses machine learning to predict behavior, buckets are chosen in anticipation of the user's next actions rather than based on recency of usage. For example, a recently used app could end up in the rare bucket because machine learning predicts that the app won't be used for several hours. " ... and then the part about rare "If an app is in the rare bucket, the system imposes strict restrictions on its ability to run jobs, trigger alarms, and receive high-priority FCM messages." – Ben987654 Mar 14 '22 at 06:19
  • @Ben987654 I see what you mean. I was looking at this page https://developer.android.com/topic/performance/power/power-details which lists that when the app is in the "Rare" bucket, High priority FCM is restricted to "5 per day". So I was thinking, since the earlier quoted doc says if we make the message visible, then "app standby bucket quota will not be consumed by that message", hence the "5 per day" should become irrelevant. So what you're saying is that in reality, if app is in "Rare", high priority FCM stops working altogether, unlike what the doc implies, which wouldn't be surprising. – thankyoussd Mar 14 '22 at 16:00
  • @thankyoussd On Samsung anyway yes. They were the only ones we had this problem with. – Ben987654 Mar 14 '22 at 17:29

0 Answers0