Fixed
Status Update
Comments
na...@gmail.com <na...@gmail.com> #2
Thanks for your patience with this bug. At this point you are just racing against JobScheduler itself. JobScheduler's book keeping. Unbinding a Job is asynchronous. So you if are creating jobs and completing jobs faster than JobScheduler can do book-keeping you are going to run against this limit.
JobScheduler's behavior is more deterministic on newer versions of the platform (O and above). So its harder to get close to this limit on these versions of the OS.
For your use-case, I suggest using a lower limit on the number of jobs you want WorkManager to schedule on your behalf. Use Configuration#setMaxSchedulerLimit() and use a limit << 100. I tried to reproduce your test case with a limit of 50, and we no longer exceed the scheduling limits.
In alpha08 we will clamp down the max limit to something more reasonable than 100 so developers don't race against the underlying scheduler.
JobScheduler's behavior is more deterministic on newer versions of the platform (O and above). So its harder to get close to this limit on these versions of the OS.
For your use-case, I suggest using a lower limit on the number of jobs you want WorkManager to schedule on your behalf. Use Configuration#setMaxSchedulerLimit() and use a limit << 100. I tried to reproduce your test case with a limit of 50, and we no longer exceed the scheduling limits.
In alpha08 we will clamp down the max limit to something more reasonable than 100 so developers don't race against the underlying scheduler.
ra...@google.com <ra...@google.com> #3
Okay, we will try setMaxSchedulerLimit 50. Thanks for your operative work.
Description
Version used: 1.0.0-alpha11
Devices/Android versions reproduced on: Android oreo - 8.1
If this is a bug in the library, we would appreciate if you could attach:
- Sample project to trigger the issue.
- A screenrecord or screenshots showing the issue (if UI related).