Status Update
Comments
ra...@google.com <ra...@google.com> #2
This is a particularly hard device to come by - do you happen to have access to the device? If so could you provide us with the output of: adb shell dumpsys media.camera > info.txt
Thanks!
wi...@gmail.com <wi...@gmail.com> #3
Stacktrace:
Caused by: java.lang.IllegalArgumentException: Can not get supported output size under supported maximum for the format: 34
at androidx.camera.camera2.internal.SupportedSurfaceCombination.getSupportedOutputSizes(SupportedSurfaceCombination.java:355)
at androidx.camera.camera2.internal.SupportedSurfaceCombination.getSuggestedResolutions(SupportedSurfaceCombination.java:197)
at androidx.camera.camera2.internal.Camera2DeviceSurfaceManager.getSuggestedResolutions(Camera2DeviceSurfaceManager.java:198)
at androidx.camera.core.CameraX.calculateSuggestedResolutions(CameraX.java:943)
at androidx.camera.core.CameraX.bindToLifecycle(CameraX.java:293)
at androidx.camera.lifecycle.ProcessCameraProvider.bindToLifecycle(ProcessCameraProvider.java:227)
Below are some findings based on our debugging
When Dex is connected
previewConfig.getMaxResolution() is returning "731x411" as maxSize.
Inside Preview.Builder.build() -> Default_MAX_resolution is set to "CameraX.getSurfaceManager().getPreviewSize()" which is 731x411
this is being picked as maxSize.
While rendering maxSize is 731x411 and minSize is 640x480 and below are available outputSizes
0 = {Size@11860} "4032x3024"
1 = {Size@11861} "3984x2988"
2 = {Size@11862} "4032x2268"
3 = {Size@11863} "3024x3024"
4 = {Size@11864} "2976x2976"
5 = {Size@11865} "3840x2160"
6 = {Size@11866} "3264x2448"
7 = {Size@11867} "4032x1960"
8 = {Size@11868} "2880x2160"
9 = {Size@11869} "3264x1836"
10 = {Size@11870} "2160x2160"
11 = {Size@11871} "2560x1440"
12 = {Size@11872} "2224x1080"
13 = {Size@11873} "2048x1152"
14 = {Size@11874} "1920x1080"
15 = {Size@11875} "1440x1080"
16 = {Size@11876} "1088x1088"
17 = {Size@11877} "1280x720"
18 = {Size@11878} "1024x768"
19 = {Size@11879} "1056x704"
20 = {Size@11880} "960x720"
21 = {Size@11881} "960x540"
22 = {Size@11882} "720x720"
23 = {Size@11883} "800x450"
24 = {Size@11884} "720x480"
25 = {Size@11885} "640x480"
26 = {Size@11886} "352x288"
27 = {Size@11887} "320x240"
28 = {Size@11888} "256x144"
29 = {Size@11889} "176x144"
and couldn't find any size in this range.
When Dex not connected
minsize = 640x480
maxsize = 1920x1080
0 = {Size@11836} "4032x3024"
1 = {Size@11837} "3984x2988"
2 = {Size@11838} "4032x2268"
3 = {Size@11839} "3024x3024"
4 = {Size@11840} "2976x2976"
5 = {Size@11841} "3840x2160"
6 = {Size@11842} "3264x2448"
7 = {Size@11843} "4032x1960"
8 = {Size@11844} "2880x2160"
9 = {Size@11845} "3264x1836"
10 = {Size@11846} "2160x2160"
11 = {Size@11847} "2560x1440"
12 = {Size@11848} "2224x1080"
13 = {Size@11849} "2048x1152"
14 = {Size@11850} "1920x1080"
15 = {Size@11851} "1440x1080"
16 = {Size@11852} "1088x1088"
17 = {Size@11853} "1280x720"
18 = {Size@11854} "1024x768"
19 = {Size@11855} "1056x704"
20 = {Size@11856} "960x720"
21 = {Size@11857} "960x540"
22 = {Size@11858} "720x720"
23 = {Size@11859} "800x450"
24 = {Size@11860} "720x480"
25 = {Size@11861} "640x480"
26 = {Size@11862} "352x288"
27 = {Size@11863} "320x240"
28 = {Size@11864} "256x144"
29 = {Size@11865} "176x144"
and we have 12 available sizes in this range
Camera2DeviceSurfaceManager.java:: getPreviewSize()
mCameraSupportedSurfaceCombinationMap.get(cameraId).getSurfaceDefinition().getPreviewSize() = "1920x1080"
cameraId=0
ra...@google.com <ra...@google.com> #4
The issue root cause is that CameraX will default filter out sizes smaller than 640x480. For Preview, the max size will be limited to under display size. I checked the HW spec info for the issue related devices. Display size of FUJITSU F-04J/F-05J is 360x640. That will result int that no size exists in the conditions that is larger or equal to 640x480 and smaller or equal to 360x640.
A temporary workaround for this situation is to use Preview.Builder#setTargetResolution() to set a size smaller than 640x480 to bypass the problem.
For device FUJITSU arrowsM04, I checked its HW spec info and its display size I found is 1280x720. It seems that the problem should not exist in the device.
Could you confirm that the problem exist on arrowsM04 device? What will be the returned value when using Display#getRealSize to obtain the display size?
ga...@gmail.com <ga...@gmail.com> #5
> A temporary workaround for this situation is to use Preview.Builder#setTargetResolution() to set a size smaller than 640x480 to bypass the problem.
OK. I will try it.
> Could you confirm that the problem exist on arrowsM04 device?
We receive the crash report (Crashlytics) that this crash has occurred on arrowsM04.
We don't have this device so we can't confirm that the problem really exist on arrowsM04.
> What will be the returned value when using Display#getRealSize to obtain the display size?
We can't investigate it for the same reason.
Thank you.
wi...@gmail.com <wi...@gmail.com> #6
This issue happened on devices that the display size is smaller than 640x480. In original auto-resolution mechanism, supported sizes smaller than 640x480 will be default filter out.
The auto-resolution mechanism encodes the guaranteed configurations tables in CameraDevice#createCaptureSession(SessionConfiguration). It defines that the PREVIEW size is the small one of the device display size and 1080p. The PREVIEW size will be the maximal size limitation for Preview use case. The reason it limits the size to display size and 1080p is the stream output in display size or 1080p has been able to provide good enough preview quality. Therefore, auto-resolution mechanism will limit the selected size to be smaller than the small one of the device display size and 1080p.
With above two conditions, in this issue, all sizes smaller than 640x480 have been filter out, therefore, there is no size smaller than the display size 320x240 can be selected to use. And cause the exception.
Solution:
When the display size is smaller than 640x480, auto-resolution mechanism won't filter out those small sizes smaller than 640x480. This makes those small size be left and can be selected for the Preview use case on small display devices.
The solution has been merged and will be included in next CameraX release.
ba...@gmail.com <ba...@gmail.com> #7
Hello.
This crash still occurs.
- CAMERAX VERSION: 1.0.0-beta4
- ANDROID OS BUILD NUMBER: Android 7.1.1
- DEVICE NAME: FUJITSU F-02H
We receive following crash report from FUJITSU F-02H. So far We have received this crash report only from F-02H.
java.lang.IllegalArgumentException
Can not get supported output size under supported maximum for the format: 34
androidx.camera.camera2.internal.SupportedSurfaceCombination.getSupportedOutputSizes (SupportedSurfaceCombination.java:349)
androidx.camera.camera2.internal.SupportedSurfaceCombination.getSuggestedResolutions (SupportedSurfaceCombination.java:197)
androidx.camera.camera2.internal.Camera2DeviceSurfaceManager.getSuggestedResolutions (Camera2DeviceSurfaceManager.java:198)
androidx.camera.core.CameraX.calculateSuggestedResolutions (CameraX.java:949)
androidx.camera.core.CameraX.bindToLifecycle (CameraX.java:351)
androidx.camera.lifecycle.ProcessCameraProvider.bindToLifecycle (ProcessCameraProvider.java:230)
(our application's package name).CameraFragment.bindCameraUseCases (CameraFragment.java:174)
ra...@google.com <ra...@google.com> #8
Could you help to provide the following information to clarify the issue?
1. Is the full name of the device Fujitsu Arrows NX F-02H that has a 1440x2560 display?
2. Please help to provide the supported output sizes of ImageFormat.PRIVATE that is obtained by StreamConfigurationMap#getOutputSizes(int).
ba...@gmail.com <ba...@gmail.com> #9
- Is the full name of the device Fujitsu Arrows NX F-02H that has a 1440x2560 display?
Yes
- Please help to provide the supported output sizes of ImageFormat.PRIVATE that is obtained by StreamConfigurationMap#getOutputSizes(int).
Since we don't have this device, we'll try to collect this information in the next version of our app. The next version will be released later this month.
ra...@google.com <ra...@google.com> #10
Hello.
- Please help to provide the supported output sizes of ImageFormat.PRIVATE that is obtained by StreamConfigurationMap#getOutputSizes(int).
We have collected the output of the device where the crash occurs.
Device1
- Model : arrows Be F-05J
- Android Version : 7.1.1
- Supported output sizes of ImageFormat.PRIVATE
CameraId 0: 480x480
CameraId 1: 2048x1536 ,1920x1080 ,1280x720 ,960x720 ,640x480 ,320x240 ,176x144
Device2
- Model : Fujitsu arrows M04
- Android Version : 7.1.1
- Supported output sizes of ImageFormat.PRIVATE
CameraId 0: 480x480
CameraId 1: 2048x1536 ,1920x1080 ,1280x720 ,960x720 ,640x480 ,320x240 ,176x144
Additional Information
CameraX version : 1.0.0-beta04
We collect the supported output sizes by following code.
val errorString = buildString {
append("The supported output sizes of ImageFormat.PRIVATE: ")
(requireContext().getSystemService(Context.CAMERA_SERVICE) as CameraManager).apply {
cameraIdList.forEachIndexed { index, cameraId ->
val msg = if (VERSION.SDK_INT >= VERSION_CODES.M) {
val configurationMap =
getCameraCharacteristics(cameraId).get(CameraCharacteristics.SCALER_STREAM_CONFIGURATION_MAP)
val sizes = configurationMap?.getOutputSizes(ImageFormat.PRIVATE)
"CameraId $index: ${sizes?.joinToString(" ,")}"
} else {
"CameraId $index: This device version is under M."
}
append(msg)
}
}
}
ra...@google.com <ra...@google.com> #11
ba...@gmail.com <ba...@gmail.com> #12
I tried to find the device specs and both 720x1280
size display. For the camera id 0 device, it is a different case that the display size is larger than 640x480
but the device only supports a 480x480
size. The case also caused the same IllegalArgumentException and was also fixed by 1.0.0-beta04
release. Before 480x480
size would be filtered out and then caused the IllegalArgumentException. After it was merged, the 640x480
size threshold was removed and then the 480x480
size would be kept and selected to use.
It looks like 1.0.0-beta04
release had been used to collect the supported sizes information. But the issue should have been fixed by 1.0.0-beta04
release. Did you only check the device model name to collect the supported sizes information or collect the information when the IllegalArgumentException issue happens again?
CameraX's 1.0.0-beta04
version. Maybe you can also consider to upgrade to the latest 1.0.0-rc01
version for your application. Thanks.
ay...@magicpin.in <ay...@magicpin.in> #13
Did you only check the device model name to collect the supported sizes information or collect the information when the IllegalArgumentException issue happens again?
We collect informations only from the device on which IllegalArgumentException happened.
Our latest app uses CameraX version 1.0.0-beta10
and this issue still occurres.
However we don't receive crash report from Fujitsu arrows Be F-05J
or Fujitsu arrows M04
so far. (This doesn't mean this issue is fixed on these devices because our app is heavily rely on camera so these device's user wouldn't use our app anymore.)
Instead, we receive crash report from
- Model : Fujitsu F-03K
- Android Version : 7.1.2
- Supported output sizes of ImageFormat.PRIVATE
CameraId 0 : 480x480
CameraId 1 : 2048x1536 ,1920x1080 ,1280x720 ,960x720 ,640x480 ,320x240 ,176x144
[Deleted User] <[Deleted User]> #14
I missed some settings when I simulated the issue by robolectric test so that I was not able to reproduce it. Now, I can reproduce the issue if the device only supports one 480x480 resolution. I'm working on the solution and target to make it included in next release.
sh...@magicpin.in <sh...@magicpin.in> #15
Branch: androidx-main
commit 69d15dff7bb857ee33a0f643ff42a0f8bc475ab2
Author: charcoalchen <charcoalchen@google.com>
Date: Fri Jan 08 18:30:03 2021
Fixed IllegalArgumentException issue happened when all preview supported sizes are smaller than 640x480 and display size is larger than 640x480.
Do not filter out sizes smaller than 640x480 when all preview supported sizes are smaller than 640x480 and display size is larger than 640x480.
Relnote:"Fixed IllegalArgumentException issue happened when all preview supported sizes are smaller than 640x480 and display size is larger than 640x480."
Bug: 150506192
Test: SupportedSurfaceCombinationTest
Change-Id: I2a63ce8e2ad42a9cc060c8635ac3603bf440b1ec
M camera/camera-camera2/src/main/java/androidx/camera/camera2/internal/SupportedSurfaceCombination.java
M camera/camera-camera2/src/test/java/androidx/camera/camera2/internal/SupportedSurfaceCombinationTest.java
ra...@google.com <ra...@google.com> #16
ze...@gmail.com <ze...@gmail.com> #17
"Fatal Exception: java.lang.IllegalStateException
JobScheduler 100 job limit exceeded. We count 0 WorkManager jobs in JobScheduler; we have 6 tracked jobs in our DB; our Configuration limit is 20." [WorkManager v.2.3.3].
[Your app is probably using JobScheduler directly...]
I found in merged manifest that AppMeasurementJobService and AnalyticsJobService (play-services-analytics library) use "android.permission.BIND_JOB_SERVICE". Is it means that analytics use JobScheduler directly and could produce such crashes?
Regards, Denys.
ra...@google.com <ra...@google.com> #18
Yes, AppMeasurementJobService
would be an example.
[Deleted User] <[Deleted User]> #19
Hi,
I am using the version 2.3.4 of the work manager library and I am still having the same problem.
I didn't do JobScheduler.cancelAllJobs() before WorkManager is initialized. You can do it inside Application.onCreate() in your Application subclass.
because we are using a third party library that is scheduling jobs and we don't really know how could affect the behaviour of the app if we cancel everything.
Is there anyway to get the only stale jobs that can be cancelled?
Regards!
ri...@gtempaccount.com <ri...@gtempaccount.com> #20
Fatal Exception: java.lang.IllegalStateException: JobScheduler 100 job limit exceeded. We count 99 WorkManager jobs in JobScheduler; we have 20 tracked jobs in our DB; our Configuration limit is 20.
at androidx.work.impl.background.systemjob.SystemJobScheduler.scheduleInternal(SystemJobScheduler.java:204)
at androidx.work.impl.background.systemjob.SystemJobScheduler.schedule(SystemJobScheduler.java:132)
at androidx.work.impl.Schedulers.schedule(Schedulers.java:108)
at androidx.work.impl.utils.ForceStopRunnable.forceStopRunnable(ForceStopRunnable.java:176)
at androidx.work.impl.utils.ForceStopRunnable.run(ForceStopRunnable.java:102)
at androidx.work.impl.utils.SerialExecutor$Task.run(SerialExecutor.java:91)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641)
at java.lang.Thread.run(Thread.java:923)
ra...@google.com <ra...@google.com> #21
You have another JobService
in your application which is scheduling too many jobs.
The exception from WorkManager
clearly states that we only scheduled 20
jobs.
ri...@gtempaccount.com <ri...@gtempaccount.com> #22
[Deleted User] <[Deleted User]> #23
* Devices: Pixel 2 and Pixel 2XL only (!)
Attached logs below for your reference. Please help us in resolving this.
As it was said before, I can't cancel all the jobs in my application class as I am not sure of consequences.
ra...@google.com <ra...@google.com> #24
Re: #23.
The error is very similar. You have another job service running & another part of the application is scheduling jobs directly using JobScheduler's APIs.
There are 30 jobs being tracked, and you have 48 jobs attributed to WorkManager
based on the error message.
Someone else is scheduling 52+ jobs.
lb...@gmail.com <lb...@gmail.com> #25
Have you guys solved it? I can see this issue even on relatively new versions of WorkManager
ra...@google.com <ra...@google.com> #26
That is because, the bug is in another library and not WorkManager. Just because you see it does not mean WorkManager caused it.
lb...@gmail.com <lb...@gmail.com> #27
Also, how can you be sure it's not WorkManager, if multiple developers here reported about it?
Which library do you think of that you say that it's from it?
Which libraries do you know that cause this issue?
ra...@google.com <ra...@google.com> #28
Why can't you at least show the stack trace of which function tried to create a new task? Or better: the place of each of the tasks that were created?
How can we do that if its not our code scheduling work with JobScheduler ?
Also, how can you be sure it's not WorkManager, if multiple developers here reported about it?
The error message makes it very clear how many jobs WorkManager actually knows about.
In the attached screenshot, WorkManager
s configuration limit is 50, and there are 48 known jobs. The app however is exceeding scheduling limits.
So some jobs are not managed by WorkManager
.
lb...@gmail.com <lb...@gmail.com> #29
Alternatively, you could have a listener that we could have, so that each time some scheduling is added, we could write it into some log (or Firebase Crashlytics).
Do you have such a thing? This way, I could add a listener whenever a task is added, logging each time a task is created, and if the app reaches 40 or some other large number, I could send a (non-fatal) crash report to Crashlytics that includes information of all of them.
Again, how can you know which libraries cause it? And which libraries do it? How do you even know that it's libraries? Could it even be Google's libraries?
I've recently noticed a very similar issue on the app I have to work on, and I've noticed it occurs (for the past 90 days, at least) only on Xiaomi and Huawei devices.
Couldn't it be that WorkManager is incompatible with the terrible behavior that such OEMs have, which is the reason for these:
?
ra...@google.com <ra...@google.com> #30
@28 You can always access the stack trace. And, when there is about to be a crash, you can query which tasks are pending and print all the information about them.
You could do that too, if you were really curious. And if you find bugs in other Google libraries, please file bugs.
[Deleted User] <[Deleted User]> #31
[Deleted User] <[Deleted User]> #32
Hi,
This issue is marked as fixed but to me it appears that some of the comments are NOT clearly addressed. We are also facing this issue using v2.5.0 and the stack trace is very similar to the #20:
Fatal Exception: java.lang.IllegalStateException: JobScheduler 100 job limit exceeded. We count 101 WorkManager jobs in JobScheduler; we have 20 tracked jobs in our DB; our Configuration limit is 20.
at androidx.work.impl.background.systemjob.SystemJobScheduler.scheduleInternal(SystemJobScheduler.java:204)
at androidx.work.impl.background.systemjob.SystemJobScheduler.schedule(SystemJobScheduler.java:132)
at androidx.work.impl.Schedulers.schedule(Schedulers.java:108)
at androidx.work.impl.utils.ForceStopRunnable.forceStopRunnable(ForceStopRunnable.java:176)
at androidx.work.impl.utils.ForceStopRunnable.run(ForceStopRunnable.java:102)
at androidx.work.impl.utils.SerialExecutor$Task.run(SerialExecutor.java:91)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641)
at java.lang.Thread.run(Thread.java:923)
It explicitly says that 101 jobs belongs to the WorkManager. This rules out the possibility that the jobs may be scheduled by another library that directly use JobScheduler APIs. In fact, I created a sample project to test this and verified that when JobScheduler APIs are used, the number in the stack trace becomes 0 as jobs are not scheduled by WorkManager.
From what I could gather after reading the source code where this exception occurs, it is impossible to create a scenario that would result in this exception using WorkManager APIs since the stack trace says the configuration limit is 20 and it should not be possible for WorkManager to schedule more than 20 jobs. (see: Schedulers#schedule, eligibleWorkSpecsForLimitedSlots)
ra...@google.com <ra...@google.com> #33
Fatal Exception: java.lang.IllegalStateException: JobScheduler 100 job limit exceeded. We count 101 WorkManager jobs in JobScheduler; we have 20 tracked jobs in our DB; our Configuration limit is 20.
This means that you have only scheduled 20 jobs that WorkManager
is aware of. There is another JobService
being used in the app (I would look at your merged app-manifest) that is the offender here.
[Deleted User] <[Deleted User]> #34
This means that you have only scheduled 20 jobs that WorkManager is aware of
I am not sure if this inference is correct for the stack trace I've shared.
Looking at the source code for the SystemJobScheduler#getPendingJobs
where the number 101 in the stack trace comes from, I can see that it is the number of jobs that JobScheduler
is aware of and uses SystemJobService
as the service component. SystemJobService
is the service used by WorkManager to schedule jobs. Even if the JobScheduler
is used directly by another library as you pointed out, it would not use the SystemJobService
and therefore would not show up or add up to the number we see in the stack trace.
ra...@google.com <ra...@google.com> #35
No, we tabulate both. Jobs we own (like you suggested) and jobs scheduled overall.
Like I said, this is not something WorkManager can help with. You need to figure out the actual component to blame. Even something as simple as adb shell dumpsys jobscheduler
will tell you what's going on.
[Deleted User] <[Deleted User]> #36
No, we tabulate both. Jobs we own (like you suggested) and jobs scheduled overall.
Again, I would have to disagree. Below is the related part of the source code:
@Nullable
private static List<JobInfo> getPendingJobs(
@NonNull Context context,
@NonNull JobScheduler jobScheduler) {
List<JobInfo> pendingJobs = null;
try {
// Note: despite what the word "pending" and the associated Javadoc might imply, this is
// actually a list of all unfinished jobs that JobScheduler knows about for the current
// process.
pendingJobs = jobScheduler.getAllPendingJobs();
} catch (Throwable exception) {
// OEM implementation bugs in JobScheduler cause the app to crash. Avoid crashing.
Logger.get().error(TAG, "getAllPendingJobs() is not reliable on this device.",
exception);
}
if (pendingJobs == null) {
return null;
}
// Filter jobs that belong to WorkManager.
List<JobInfo> filtered = new ArrayList<>(pendingJobs.size());
ComponentName jobServiceComponent = new ComponentName(context, SystemJobService.class);
for (JobInfo jobInfo : pendingJobs) {
if (jobServiceComponent.equals(jobInfo.getService())) {
filtered.add(jobInfo);
}
}
return filtered;
}
The first number does NOT contain all the scheduled jobs as there is an explicit filtering for counting only the jobs that belong to WorkManager. Wouldn't this mean that 101 jobs in the stack trace I've shared were actually scheduled by the WorkManager at some point? Otherwise it would've been filtered out in the last part above.
I think what you suggest is a separate scenario where bug with a similar stack trace could be encountered but in that case I would expect a different stack trace from what I've shared. What you suggest would look more like the stack trace in the
ra...@google.com <ra...@google.com> #37
WorkManager 2.5.x is over 2 years old at this point. Please upgrade to the latest stable version and then file a new bug report.
In the latest alpha version, you can go further and use a SchedulingExceptionHandler
(an @Restricted
API) to get better signals on where the underlying problem might be.
Also, 2.5.x is not supported on Android S+ devices at all. You will need a minimum of 2.7.1
.
ng...@gmail.com <ng...@gmail.com> #38
```Fatal Exception: java.lang.IllegalStateException: JobScheduler 100 job limit exceeded. We count 12 WorkManager jobs in JobScheduler; we have 20 tracked jobs in our DB; our Configuration limit is 20.
at androidx.work.impl.background.systemjob.SystemJobScheduler.scheduleInternal(SystemJobScheduler.java:218)
at androidx.work.impl.background.systemjob.SystemJobScheduler.schedule(SystemJobScheduler.java:133)
at androidx.work.impl.Schedulers.schedule(Schedulers.java:108)
at androidx.work.impl.utils.ForceStopRunnable.forceStopRunnable(ForceStopRunnable.java:226)
at androidx.work.impl.utils.ForceStopRunnable.run(ForceStopRunnable.java:110)
at androidx.work.impl.utils.SerialExecutor$Task.run(SerialExecutor.java:91)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641)
at java.lang.Thread.run(Thread.java:923)```
My version of "androidx.work:work-runtime-ktx" is 2.7.1. Most of the devices got this crash is Xiaomi 11 Lite.
I have check the source code, no implementation call `Context.getSystemService(Context.JOB_SCHEDULER_SERVICE)` to get the JobScheduler. I just see the implementation of WorkManager. But the report said that only 12 WorkManager jobs were found. So where are the remaining come from?
[Deleted User] <[Deleted User]> #39
Caused by java.lang.IllegalStateException: Apps may not schedule more than 100 distinct jobs
at android.os.Parcel.createException(Parcel.java:2079)
at android.os.Parcel.readException(Parcel.java:2039)
at android.os.Parcel.readException(Parcel.java:1987)
at android.app.job.IJobScheduler$Stub$Proxy.schedule(IJobScheduler.java:308)
at android.app.JobSchedulerImpl.schedule(JobSchedulerImpl.java:43)
at androidx.work.impl.background.systemjob.SystemJobScheduler.scheduleInternal(SystemJobScheduler.java:191)
at androidx.work.impl.background.systemjob.SystemJobScheduler.schedule(SystemJobScheduler.java:137)
at androidx.work.impl.Schedulers.schedule(Schedulers.java:108)
at androidx.work.impl.utils.ForceStopRunnable.forceStopRunnable(ForceStopRunnable.java:255)
at androidx.work.impl.utils.ForceStopRunnable.run(ForceStopRunnable.java:134)
at androidx.work.impl.utils.SerialExecutorImpl$Task.run(SerialExecutorImpl.java:96)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641)
at java.lang.Thread.run(Thread.java:919)
Any update on fixe?
ra...@google.com <ra...@google.com> #40
You are very likely using another library that is scheduling jobs directly. I would look at the merged AndroidManifest.xml
to find the other JobService instance.
gu...@scoompa.com <gu...@scoompa.com> #41
We are using androidx.work:work-runtime:2.9.0
and getting the same exception in Firebase Crashlytics.
Fatal Exception: java.lang.IllegalStateException: JobScheduler 100 job limit exceeded. We count 100 WorkManager jobs in JobScheduler; we have 20 tracked jobs in our DB; our Configuration limit is 20.
at androidx.work.impl.background.systemjob.SystemJobScheduler.scheduleInternal(SystemJobScheduler.java:223)
at androidx.work.impl.background.systemjob.SystemJobScheduler.schedule(SystemJobScheduler.java:140)
at androidx.work.impl.Schedulers.schedule(Schedulers.java:133)
at androidx.work.impl.utils.ForceStopRunnable.forceStopRunnable(ForceStopRunnable.java:266)
at androidx.work.impl.utils.ForceStopRunnable.run(ForceStopRunnable.java:135)
at androidx.work.impl.utils.SerialExecutorImpl$Task.run(SerialExecutorImpl.java:96)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641)
at java.lang.Thread.run(Thread.java:919)
Caused by java.lang.IllegalStateException: Apps may not schedule more than 100 distinct jobs
at android.os.Parcel.createException(Parcel.java:2096)
at android.os.Parcel.readException(Parcel.java:2056)
at android.os.Parcel.readException(Parcel.java:2004)
at android.app.job.IJobScheduler$Stub$Proxy.schedule(IJobScheduler.java:324)
at android.app.JobSchedulerImpl.schedule(JobSchedulerImpl.java:43)
at androidx.work.impl.background.systemjob.SystemJobScheduler.scheduleInternal(SystemJobScheduler.java:194)
at androidx.work.impl.background.systemjob.SystemJobScheduler.schedule(SystemJobScheduler.java:140)
at androidx.work.impl.Schedulers.schedule(Schedulers.java:133)
at androidx.work.impl.utils.ForceStopRunnable.forceStopRunnable(ForceStopRunnable.java:266)
at androidx.work.impl.utils.ForceStopRunnable.run(ForceStopRunnable.java:135)
at androidx.work.impl.utils.SerialExecutorImpl$Task.run(SerialExecutorImpl.java:96)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641)
at java.lang.Thread.run(Thread.java:919)
More information:
- All of the places we enqueue work are using the
enqueueUnique
version, with theKEEP
flag - We do not bind directly to the
JOB_SCHEDULER_SERVICE
anywhere in our code. - I checked the merged manifest, here are the list of services to bind to the
JOB_SCHEDULER_SERVICE
, they are all part of Firebase:com.google.android.datatransport.runtime.scheduling.jobscheduling.JobInfoSchedulerService
,com.google.android.gms.measurement.AppMeasurementJobService
,com.google.android.gms.analytics.AnalyticsJobService
,androidx.work.impl.background.systemjob.SystemJobService
Any ideas?
ch...@gmail.com <ch...@gmail.com> #42
I am also seeing this error state with WorkManager 2.8.1 and 2.9.0, possibly arising in connection with crashes in the app using WorkManager.
2024-05-29 18:52:43.792824737 +0000 10041 23649 23685 E AndroidRuntime: java.lang.IllegalStateException: JobScheduler 100 job limit exceeded. We count 151 WorkManager jobs in JobScheduler; we have 20 tracked jobs in our DB; our Configuration limit is 20.
2024-05-29 18:52:43.792824737 +0000 10041 23649 23685 E AndroidRuntime: at androidx.work.impl.background.systemjob.SystemJobScheduler.scheduleInternal(SystemJobScheduler.java:220)
There is no direct JobScheduler API use at all in the codebase, only WorkManager.
ra...@google.com <ra...@google.com> #43
Are you seeing reference to other job services when you run adb shell dumpsys jobscheduler
?
The error message is more confusing than it needs to be. The number of WorkRequests that WorkManager
is aware of is 20. Even though the error message uses the name WorkManager jobs
, its actually referring to the total number of jobs that JobScheduler
knows about.
There seem to be other jobs that a dependency might be scheduling.
ch...@gmail.com <ch...@gmail.com> #44
In the incident quoted at #42, there are no jobs scheduled for the app other than WorkManager jobs.
We've gone so far as to decompile and audit the deployed APK for any Job Scheduler use that might have been brought in "silently" via libraries. I can confirm that the only scheduled job access by this app is via WorkManager. (And WM's androidx.work.impl.background.systemjob.SystemJobService
is the only job service declared in the APK, also verified via direct inspection with aapt
.)
ra...@google.com <ra...@google.com> #45
That is extremely strange. Can you try and turn on verbose logging using the instructions in:
Could you please Log.DEBUG
as your log level so we get more information. Also, can you consistently reproduce this?
Description
Version used:2.3.0
Theme used:
Devices/Android versions reproduced on:
honor 8C / 8.1.0
Primo GM2 Plus/ 7.0
Galaxy Note9 / 10
- Relevant code to trigger the issue.
WorkManager.getInstance(this)
.beginUniqueWork("StatsInTime", ExistingWorkPolicy.REPLACE, workerRequest)
.enqueue()
- Stacktrace:
Fatal Exception: java.lang.IllegalStateException: JobScheduler 100 job limit exceeded. We count 101 WorkManager jobs in JobScheduler; we have 20 tracked jobs in our DB; our Configuration limit is 20.
at androidx.work.impl.background.systemjob.SystemJobScheduler.scheduleInternal(SystemJobScheduler.java:199)
at androidx.work.impl.background.systemjob.SystemJobScheduler.schedule(SystemJobScheduler.java:127)
at androidx.work.impl.Schedulers.schedule(Schedulers.java:92)
at androidx.work.impl.WorkerWrapper.onWorkFinished(WorkerWrapper.java:369)
at androidx.work.impl.WorkerWrapper$2.run(WorkerWrapper.java:318)
at androidx.work.impl.utils.SerialExecutor$Task.run(SerialExecutor.java:91)
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)
Caused by java.lang.IllegalStateException: Apps may not schedule more than 100 distinct jobs
at android.os.Parcel.readException(Parcel.java:2024)
at android.os.Parcel.readException(Parcel.java:1962)
at android.app.job.IJobScheduler$Stub$Proxy.schedule(IJobScheduler.java:180)
at android.app.JobSchedulerImpl.schedule(JobSchedulerImpl.java:49)
at androidx.work.impl.background.systemjob.SystemJobScheduler.scheduleInternal(SystemJobScheduler.java:181)
at androidx.work.impl.background.systemjob.SystemJobScheduler.schedule(SystemJobScheduler.java:127)
at androidx.work.impl.Schedulers.schedule(Schedulers.java:92)
at androidx.work.impl.WorkerWrapper.onWorkFinished(WorkerWrapper.java:369)
at androidx.work.impl.WorkerWrapper$2.run(WorkerWrapper.java:318)
at androidx.work.impl.utils.SerialExecutor$Task.run(SerialExecutor.java:91)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1162)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:636)
at java.lang.Thread.run(Thread.java:784)