These new priority buckets are designed to allow the system to be smarter about how resources are distributed between applications — if there is an app that you rarely use trying to do some background work whilst you’re in the process of using an intensive app that you regularly use, why would you want that background service to be able to kick off and pose a disruption on what you’re currently doing? And on another note, it would be great to be able to block out so called high-priority messages from an application that you rarely use and have no real care for, whilst at the same time still being able to receive ones for applications that you frequently use. For these purposes and more we now have the concept of Priority Buckets that group our applications into one of five different buckets that each have different operational rules that are imposed by the system. An application will fall into one of five buckets:

Now, once an application has been assigned to a bucket it doesn’t mean that that is where it will stay forever. These buckets are dynamic, which means that the system will reassign an application bucket based on recent behaviours. For example, if your user never often used your app and then found something of value that gradually increased their usage then your application would move up through the level of buckets. If available on the device, then the system will use machine learning to determine the frequency of apps and then these will be placed into buckets based on those predictions. Otherwise, applications will be sorted into buckets based on how recently they have been used. By usage there are several things that count as this such as:

So, we know now that our application will fall into one of these buckets — but what does this exactly mean for us? Each of these buckets has it’s own individual behaviours which are enforced by the system.

Whilst these restrictions are only applied when the device is running off of battery power, it’s important to be aware of them and optimise your applications in ways that may still allow them to operate as intended in these scenarios. To begin with, if your application falls into the Active bucket then there are no restrictions that are put in place, so you don’t need to worry about any application behaviour changing in these circumstances.

On the other hand, when your application has entered the Working Set bucket then there are few mild restrictions that are put in place. In this case, any Jobs that are run can be deferred by up to 2 hours and any alarms being triggered may be deferred by up to 6 minutes. Next, when our application moves into the Frequent bucket, registered Jobs may be deferred by up to 8 hours and alarms deferred by up to 30 minutes — this is quite a bit of a jump up from the previous bucket. At this point restrictions also enter for high-priority FCM messages as Frequent applications will only be able to receive 10 of these a day. Finally, when our application falls into the Rare bucket, Jobs can be deferred by up to 24 hours and alarms up to 2 hours. High priority notifications also drops to a limit of 5 a day and there is now a network restriction introduced, meaning that network operations can be deferred by up to 24 hours.

Note: It’s important to be aware that if an application is split into different packages, then these can all fall into different priority buckets. Do not rely on the same behaviours to occur between packages as this will not be the case.

If you wish to check what bucket your application is in for a user, then you can do so using the getAppStandbyBucket() function. Whilst your application should be built in a way that makes it optimal for all situations, this function can be handy for situations where timing is important. For example, maybe something being posted to an API is crucial within some timeframe — if an application is in the Rare bucket then it might not make sense to schedule a Job for this as it could be deferred by up to 24 hours.

With that in mind, it’s important that you do not try and change the behaviour of your application to move your application between packages. To begin with, different device manufacturers may change how priority buckets work so you can never rely on how the deciding factors for where an application will be placed. Secondly, you shouldn’t force prompts to the user to regain interactivity just to move up through priority buckets — for example, trying to regain interaction through high-priority notifications in an attempt to reinstate bucket status would be bad practice. If your notifications provide value, that’s great — but don’t abuse the system to move up through the bucket levels. Plus, you might hit your high-priority quota and not be able to show any further notifications for the rest of that day.

I hope this has given some insight into the new Priority Buckets and how they operate. If you have any questions or comments on this topic then please do reach out 🙂

Tweets by hitherejoe

Leave a Reply Cancel reply