How does stopping&throttling a Worker/JobScheduler work?

61 views Asked by At

Background

I work on some Worker that could take some time, but probably not too much time and it would be fine to reschedule it again in case the OS said it's too much.

We plan to use setRequiresDeviceIdle so that the work will be done while the device's screen is turned off, to reduce the chance of slowing things for the user.

As Worker is based on JobScheduler, it seems that for Android API 21-22, the execution time is up to 1 minutes, and from API 23 it's up to 10 minutes and maybe more:

In Android version Build.VERSION_CODES.LOLLIPOP, jobs had a maximum execution time of one minute. Starting with Android version Build.VERSION_CODES.M and ending with Android version Build.VERSION_CODES.R, jobs had a maximum execution time of 10 minutes. Starting from Android version Build.VERSION_CODES.S, jobs will still be stopped after 10 minutes if the system is busy or needs the resources, but if not, jobs may continue running longer than 10 minutes.

Note: Beginning with API 30 (Build.VERSION_CODES.R), JobScheduler will throttle runaway applications. Calling schedule(android.app.job.JobInfo) and other such methods with very high frequency can have a high cost and so, to make sure the system doesn't get overwhelmed, JobScheduler will begin to throttle apps, regardless of target SDK version.

The problems and what I've found

There are multiple definitions here that are missing, which I can't find about them:

  1. Meaning of "device is in active use" for setRequiresDeviceIdle. It says there that it's not "related to the system's "device idle" or "doze" states". I hope I can assume it's when its display isn't turned off. Someone said (here) that it seems as such, but I can't find anything that supports this claim. I tried to use it and run it, together with some setInitialDelay of one minute, but I didn't see it get triggered even for half an hour (when the display is turned off), so I don't get when such a thing occurs.

  2. Meaning of Worker/JobScheduler being "stopped". It seems it will call onStopped (or onStopJob), which means I need to signal the long running work to stop. What I don't understand is what happens because of it in terms of the process and the work itself.

  3. Meaning of "throttle" in this context, and when it happens. To me it seems like 2 possible scenarios are described in the quote I've written above: when you schedule too much, and when you have a "runaway application", which I assume it means an app that has the job running for too long.

The questions

  1. For "setRequiresDeviceIdle", can I assume it's for when the device display is turned off? For how long?

  2. For Worker/JobScheduler being "stopped", what happens to the work and/or app and/or process in case it took too much time and it reached the onStopped/onStopJob callbacks? The result is probably gone, but does the process continue as usual and not killed till I handle it properly? Could the OS kill the process?

  3. What does the "throttle" mean? That the OS will now sometimes delay jobs in general of the app (of all of them) ? Or maybe this specific one? Or make it slower?

  4. What does "runaway application" mean? What are the described scenarios to trigger throttling? What's described is 2 scenarios or just one?

0

There are 0 answers