Fixed
Status Update
Comments
ia...@gmail.com <ia...@gmail.com> #2
Bringing setMaxSchedulerLimit to say 49 doesn't help. Same error.
il...@google.com <il...@google.com> #3
If you are using work-firebase then you should not be using JobScheduler directly. Can you please send us the full bug report so we can investigate ?
ma...@gmail.com <ma...@gmail.com> #4
java.lang.IllegalStateException: Apps may not schedule more than 100 distinct jobs
at android.os.Parcel.readException(Parcel.java:1692)
at android.os.Parcel.readException(Parcel.java:1637)
at android.app.job.IJobScheduler$Stub$Proxy.schedule(IJobScheduler.java:158)
at android.app.JobSchedulerImpl.schedule(JobSchedulerImpl.java:42)
at androidx.work.impl.background.systemjob.SystemJobScheduler.scheduleInternal(SystemJobScheduler.java:126)
at androidx.work.impl.background.systemjob.SystemJobScheduler.schedule(SystemJobScheduler.java:95)
at androidx.work.impl.Schedulers.scheduleInternal(Schedulers.java:104)
at androidx.work.impl.Schedulers.schedule(Schedulers.java:73)
at androidx.work.impl.WorkerWrapper.setSucceededAndNotify(WorkerWrapper.java:393)
at androidx.work.impl.WorkerWrapper.handleResult(WorkerWrapper.java:255)
at androidx.work.impl.WorkerWrapper.run(WorkerWrapper.java:181)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1133)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:607)
at java.lang.Thread.run(Thread.java:761)
at android.os.Parcel.readException(Parcel.java:1692)
at android.os.Parcel.readException(Parcel.java:1637)
at android.app.job.IJobScheduler$Stub$Proxy.schedule(IJobScheduler.java:158)
at android.app.JobSchedulerImpl.schedule(JobSchedulerImpl.java:42)
at androidx.work.impl.background.systemjob.SystemJobScheduler.scheduleInternal(SystemJobScheduler.java:126)
at androidx.work.impl.background.systemjob.SystemJobScheduler.schedule(SystemJobScheduler.java:95)
at androidx.work.impl.Schedulers.scheduleInternal(Schedulers.java:104)
at androidx.work.impl.Schedulers.schedule(Schedulers.java:73)
at androidx.work.impl.WorkerWrapper.setSucceededAndNotify(WorkerWrapper.java:393)
at androidx.work.impl.WorkerWrapper.handleResult(WorkerWrapper.java:255)
at androidx.work.impl.WorkerWrapper.run(WorkerWrapper.java:181)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1133)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:607)
at java.lang.Thread.run(Thread.java:761)
il...@google.com <il...@google.com>
ap...@google.com <ap...@google.com> #5
What do you mean I shouldn't use JobScheduler directly? Isn't work-firebase is just for <21 devices, otherwise JobScheduler always used?
il...@google.com <il...@google.com> #6
I think i was confused by your previous comment. You are right, we only use work-firebase for API < 23.
JobScheduler is used for API >= 23.
This issue should have been resolved in `alpha03` and `alpha04` (we addressed different parts of the problem). If you can reproduce this on a device, then can you do:
1. adb shell dumpsys jobscheduler for your app.
2. Reboot your device.
3. After the reboot, can you re-run adb shell dumpsys jobscheduler ?
I want to check if you see any differences in the jobs created before and after the reboot.
Thanks for your patience.
JobScheduler is used for API >= 23.
This issue should have been resolved in `alpha03` and `alpha04` (we addressed different parts of the problem). If you can reproduce this on a device, then can you do:
1. adb shell dumpsys jobscheduler for your app.
2. Reboot your device.
3. After the reboot, can you re-run adb shell dumpsys jobscheduler ?
I want to check if you see any differences in the jobs created before and after the reboot.
Thanks for your patience.
[Deleted User] <[Deleted User]> #7
Actually for step 2, the easier thing to do is to force stop your app. You don't need to fo a full reboot.
Description
Version used: 1.0.0-alpha01
Devices/Android versions reproduced on: Device running Android P, compiled in SDK 27
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).
In order to instantiate the view of my first fragment, some data needs to be passed from the current Activity to the primary fragment. Currently, I don't see a clear way to do this. In the same way one can navigate from fragment to fragment while passing arguments via the NavController's navigate method, it would be helpful if there was some method to pass a bundle to the first nav fragment and update the graph associated with the NavHostFragment before inflating the view.
Please do let me know if there is some way to do this that I'm missing. Currently I'm setting up a dummy fragment to start with that will manage passing the data to the intended first fragment.