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.