IssueTracker

As part of this, I'm confused as to why we would NOT want to call .setExpedited(OutOfQuotaPolicy.RUN_AS_NON_EXPEDITED_WORK_REQUEST) on our work request builder. Surely this is a win-win (from the app point of view)? It's saying "treat me as important... but if not then just treat me as normal". I mean, there is no penalty in setting the work as expedited... there is a quota yes, but there is "no harm in asking"? So why not just set this all the time?

If everything is important, nothing is. This is a bad idea for a couple of reasons. Expedited apps are latency sensitive i.e. the Platform tries to schedule these jobs as quickly as possible, as they are by some definition important to the user. There are also a fixed number of such execution slots in the platform. Some or all the following will happen:

• The platform, will never give you a "full" execution slot. This is because the number of expedited jobs scheduled > the number of execution slots and you will be interrupted and asked to yield very often.
• You only get a finite number of expedited jobs (based on the quotas that apply to your app standby bucket), so if something is truly important - then you can't really do much (given you may have used up your quota).

I'm currently having some users reporting that the periodic work request is failing, and can't work out why, but want to explore whether I using .setExpedited() might help... and it got me wondering whether/why I shouldn't just use this all the time.

What you do you actually mean when you say that the PeriodicWorkRequest is failing ?

• Is it not getting scheduled at all ?
• Is it getting delayed ?
• setExpedited() is not a magical silver bullet. It cannot apply to jobs that have an initial delay at all (given they are by definition not latency sensitive).

You are better of investigating what might be going on on the devices where jobs are not scheduled / getting delayed.

Thanks for the helpful insight. I'll steer clear of setExpedited().

What you do you actually mean when you say that the PeriodicWorkRequest is failing ?

Well I suspect that, in most cases, it is caused by the ever-more complicated web of optimisations and power/batter savers put in place (in many different ways) by different manufacturers (and many too by core Android itself). It's almost impossible to second-guess why a user's widget might not be auto updating (with a schedule driven by WM) but usually it's a case of tracking it down to a secret non-standard setting somewhere that unlocks it... so many different problems and solutions here: https://dontkillmyapp.com/

Case in point, today a user eventually found that they needed to pin/lock my app to the recent apps list (as described here: https://dontkillmyapp.com/xiaomi), just in order to get the widget to auto update... the updating is driven by a periodic work request. Nothing else helped. There's even an option in my app to do the widget updating work in the foreground, using WM's setForegroundAsync(), but that didn't work either. Only thing that worked was to pin the app itself to the recent apps list, which then enabled the widget to auto update successfully.

setExpedited() is not a magical silver bullet

It would be great if WM did have a magical silver bullet to cut through all of these non-standard obstacles put in place... but I suspect that there isn't :-(

Jake, Ben, as far as I remember you're already working on improvements of docs around setExpedite / FGS restrictions, right?

We are. Info will land on d.android.com soon. Until that's published this Twitter thread might be able to help.