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. androidx.work.impl.background.systemjob.SystemJobScheduler.scheduleInternal [149092520]

Fixed

Bug

Status Update

No update yet.

Description

ga...@gmail.com

created issue #1

Feb 8, 2020 07:35AM

Artifact used androidx.work:work-runtime-ktx
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)

Comments

ra...@google.com <ra...@google.com> #2Feb 10, 2020 06:19PM

Marked as fixed, reassigned to ra...@google.com.

A couple of questions:

1. Have you saw crash in real device or only in simulators?
2. Do you use dynamic feature for language ID?

wi...@gmail.com <wi...@gmail.com> #3Feb 14, 2020 07:19AM

Tested on Android 12 Emulator with custom executor, but cannot repro this issue.

ra...@google.com <ra...@google.com> #4Feb 14, 2020 06:12PM

Second crash in the description is from a real device. Experienced it myself on two different Xiaomi phones, plus lots of crashes from users in the Google Play console.
Dynamic features are not used in the application.

As a wild guess, I have downgraded build tools from 31.0.0 to 30.0.3, compileSdk from 31 to 30, and moved all work with Language ID to the service in a separate process (just to be sure that crash can kill secondary process instead of main). This combination is in beta for 2 days by now and I don't see any SIGSEGV crashes.

ga...@gmail.com <ga...@gmail.com> #5Feb 14, 2020 06:17PM

Hmm, I feel the crash might be something related to separate/secondary process.

I also changed compileSdk and targetSDK to 31 but still cannot repro this issue.

wi...@gmail.com <wi...@gmail.com> #6Feb 15, 2020 04:54AM

On the contrary, there was no separate process before, when crashes started.

In the new build (with the aforementioned changes) I can see SIGSEGV crash, but only one instead of dozens and it has a bit different backtrace:

signal 11 (SIGSEGV), code 1 (SEGV_MAPERR)
liblanguage_id_jni.so (offset 0x11e000)

backtrace:
  #00  pc 000000000003c7c0  /data/app/azagroup.reedy-mF7zTu2bv_ELlbFArwNgqA==/split_config.arm64_v8a.apk!lib/arm64-v8a/liblanguage_id_jni.so (offset 0x11e000)
  #00  pc 000000000003b960  /data/app/azagroup.reedy-mF7zTu2bv_ELlbFArwNgqA==/split_config.arm64_v8a.apk!lib/arm64-v8a/liblanguage_id_jni.so (offset 0x11e000)
  #00  pc 000000000003bb48  /data/app/azagroup.reedy-mF7zTu2bv_ELlbFArwNgqA==/split_config.arm64_v8a.apk!lib/arm64-v8a/liblanguage_id_jni.so (offset 0x11e000)
  #00  pc 000000000003bafc  /data/app/azagroup.reedy-mF7zTu2bv_ELlbFArwNgqA==/split_config.arm64_v8a.apk!lib/arm64-v8a/liblanguage_id_jni.so (offset 0x11e000)
  #00  pc 0000000000036c98  /data/app/azagroup.reedy-mF7zTu2bv_ELlbFArwNgqA==/split_config.arm64_v8a.apk!lib/arm64-v8a/liblanguage_id_jni.so (offset 0x11e000)
  #00  pc 0000000000032714  /data/app/azagroup.reedy-mF7zTu2bv_ELlbFArwNgqA==/split_config.arm64_v8a.apk!lib/arm64-v8a/liblanguage_id_jni.so (offset 0x11e000)
  #00  pc 0000000000031cac  /data/app/azagroup.reedy-mF7zTu2bv_ELlbFArwNgqA==/split_config.arm64_v8a.apk!lib/arm64-v8a/liblanguage_id_jni.so (offset 0x11e000)
  #00  pc 0000000000057438  /data/app/azagroup.reedy-mF7zTu2bv_ELlbFArwNgqA==/oat/arm64/base.odex (offset 0x57000)

ba...@gmail.com <ba...@gmail.com> #7Feb 17, 2020 09:21AM

FYI, ML Kit launched a new language ID SDK in the latest release, which uses a new language ID model. https://developers.google.com/ml-kit/release-notes#august_11_2021

Could you try the new SDK version(17.0.0) to check if you can still repro this native crash? Thanks!

ra...@google.com <ra...@google.com> #8Feb 18, 2020 05:01PM

Thank you, I'll try it and check.

ba...@gmail.com <ba...@gmail.com> #9Feb 19, 2020 01:21AM

Hello. I have similar experience.

I'm using mlkit-language 16.1.1
I didnot meet this error until using AGP 4.2
I can get this error since using AGP 7.0
This error raised on Release build only(minimized by R8)
This error raised without obfuscation.

ra...@google.com <ra...@google.com> #10Feb 19, 2020 01:26AM

Also I found there is a post which presents same issue on stackoverflow.

https://stackoverflow.com/questions/68832304/mlkit-translate-sdk-crashes-in-release-build

ra...@google.com <ra...@google.com> #11Feb 19, 2020 01:26AM

I created reproducible project.

$ git clone https://github.com/ganadist/VersionCodeDemo -b mlkit_agp7 mlkit_agp7
$ cd mlkit_agp7
$ ./gradlew :app:pPRUA
$ adb install app/build/outputs/universal_apk/productionRelease/app-production-release-universal.apk
$ adb shell am start -n com.example.myapplication/.MainActivity

$ adb logcat -b crash -d
10-19 19:41:49.844 17810 17810 F libc    : Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x7acf9d733c in tid 17810 (e.myapplication), pid 17810 (e.myapplication)
10-19 19:41:50.473 17849 17849 F DEBUG   : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
10-19 19:41:50.473 17849 17849 F DEBUG   : Build fingerprint: 'google/crosshatch/crosshatch:12/SPB5.210812.002/7671067:user/release-keys'
10-19 19:41:50.473 17849 17849 F DEBUG   : Revision: 'MP1.0'
10-19 19:41:50.473 17849 17849 F DEBUG   : ABI: 'arm64'
10-19 19:41:50.473 17849 17849 F DEBUG   : Timestamp: 2021-10-19 19:41:49.903736988+0900
10-19 19:41:50.473 17849 17849 F DEBUG   : Process uptime: 0s
10-19 19:41:50.473 17849 17849 F DEBUG   : Cmdline: com.example.myapplication
10-19 19:41:50.474 17849 17849 F DEBUG   : pid: 17810, tid: 17810, name: e.myapplication  >>> com.example.myapplication <<<
10-19 19:41:50.474 17849 17849 F DEBUG   : uid: 10240
10-19 19:41:50.474 17849 17849 F DEBUG   : signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x7acf9d733c
10-19 19:41:50.474 17849 17849 F DEBUG   :     x0  0000000000000000  x1  00000000000008fc  x2  0000007a76760c71  x3  0000000000000000
10-19 19:41:50.474 17849 17849 F DEBUG   :     x4  0000000000000010  x5  0000007ba4db49d0  x6  0000007b34dc3680  x7  3de38e3900000608
10-19 19:41:50.474 17849 17849 F DEBUG   :     x8  0000007bb4dbedf0  x9  0000007acf9db2aa  x10 0000000000000000  x11 0000007acf9d6640
10-19 19:41:50.474 17849 17849 F DEBUG   :     x12 0000000000000009  x13 0000000000000000  x14 0000000000000061  x15 00000000ebad6a89
10-19 19:41:50.474 17849 17849 F DEBUG   :     x16 0000007a767cfef8  x17 0000007d9a564b40  x18 0000007da3830000  x19 0000007feaf56a08
10-19 19:41:50.474 17849 17849 F DEBUG   :     x20 0000000000000000  x21 0000007ba4da50b0  x22 0000007bb4dbedf0  x23 0000007ba4da50b8
10-19 19:41:50.474 17849 17849 F DEBUG   :     x24 0000000000000009  x25 000000000000067e  x26 0000000000000012  x27 0000000000000008
10-19 19:41:50.474 17849 17849 F DEBUG   :     x28 0000007b64dc8440  x29 0000000000000000
10-19 19:41:50.474 17849 17849 F DEBUG   :     lr  0000007a7678a964  sp  0000007feaf56810  pc  0000007a7678b7c0  pst 0000000060000000
10-19 19:41:50.474 17849 17849 F DEBUG   : backtrace:
10-19 19:41:50.474 17849 17849 F DEBUG   :       #00 pc 000000000003c7c0  /data/app/~~mHaMq-e9ocbm9UfYnkCGkQ==/com.example.myapplication-HgG9vkluwDDO1K78-Vzr0A==/lib/arm64/liblanguage_id_jni.so (BuildId: 859ec0ec2000a39e6ae8ed42e1704f46)
10-19 19:41:50.474 17849 17849 F DEBUG   :       #01 pc 000000000003b960  /data/app/~~mHaMq-e9ocbm9UfYnkCGkQ==/com.example.myapplication-HgG9vkluwDDO1K78-Vzr0A==/lib/arm64/liblanguage_id_jni.so (BuildId: 859ec0ec2000a39e6ae8ed42e1704f46)
10-19 19:41:50.474 17849 17849 F DEBUG   :       #02 pc 000000000003bb48  /data/app/~~mHaMq-e9ocbm9UfYnkCGkQ==/com.example.myapplication-HgG9vkluwDDO1K78-Vzr0A==/lib/arm64/liblanguage_id_jni.so (BuildId: 859ec0ec2000a39e6ae8ed42e1704f46)
10-19 19:41:50.474 17849 17849 F DEBUG   :       #03 pc 000000000003bafc  /data/app/~~mHaMq-e9ocbm9UfYnkCGkQ==/com.example.myapplication-HgG9vkluwDDO1K78-Vzr0A==/lib/arm64/liblanguage_id_jni.so (BuildId: 859ec0ec2000a39e6ae8ed42e1704f46)
10-19 19:41:50.474 17849 17849 F DEBUG   :       #04 pc 0000000000036c98  /data/app/~~mHaMq-e9ocbm9UfYnkCGkQ==/com.example.myapplication-HgG9vkluwDDO1K78-Vzr0A==/lib/arm64/liblanguage_id_jni.so (BuildId: 859ec0ec2000a39e6ae8ed42e1704f46)
10-19 19:41:50.474 17849 17849 F DEBUG   :       #05 pc 00000000000324a4  /data/app/~~mHaMq-e9ocbm9UfYnkCGkQ==/com.example.myapplication-HgG9vkluwDDO1K78-Vzr0A==/lib/arm64/liblanguage_id_jni.so (BuildId: 859ec0ec2000a39e6ae8ed42e1704f46)
10-19 19:41:50.474 17849 17849 F DEBUG   :       #06 pc 0000000000031b5c  /data/app/~~mHaMq-e9ocbm9UfYnkCGkQ==/com.example.myapplication-HgG9vkluwDDO1K78-Vzr0A==/lib/arm64/liblanguage_id_jni.so (Java_com_google_mlkit_nl_languageid_internal_LanguageIdentificationJni_nativeIdentifyLanguage+100) (BuildId: 859ec0ec2000a39e6ae8ed42e1704f46)

But after downgrade to AGP 4.2, crash is not reproducible.

$ git clone https://github.com/ganadist/VersionCodeDemo -b mlkit_agp42 mlkit_agp42
$ cd mlkit_agp42
$ ./gradlew :app:pPRUA
$ adb install app/build/outputs/universal_apk/productionRelease/app-production-release-universal.apk
$ adb shell am start -n com.example.myapplication/.MainActivity

Also, I tried to disable inline optimizers on R8 with AGP 7.0, and crash is not reproducible.

$ git clone https://github.com/ganadist/VersionCodeDemo -b mlkit_agp7_r8_disable_inline_optimizer  mlkit_agp7_r8
$ cd mlkit_agp7_r8
$ ./gradlew :app:pPRUA
$ adb install app/build/outputs/universal_apk/productionRelease/app-production-release-universal.apk
$ adb shell am start -n com.example.myapplication/.MainActivity

ba...@gmail.com <ba...@gmail.com> #12Feb 19, 2020 03:01PM

I tried the repro steps but got a NPE when I run ./gradlew :app:pPRUA

FAILURE: Build failed with an exception.

* What went wrong:
java.lang.NullPointerException
> java.lang.NullPointerException (no error message)

Could you also check if this is reproducible on 17.0.0 or 17.0.1? If yes, could you attach the full log that I can take a look? Thanks!

ay...@magicpin.in <ay...@magicpin.in> #13Apr 2, 2020 06:28AM

Here are gradle build scan logs for each branches.
All builds were clean build, and disabled build cache.

mlkit_agp7 : https://scans.gradle.com/s/qrymdqfzwokbq
mlkit_agp42 : https://scans.gradle.com/s/b6644hzfyfhaw
mlkit_agp7_r8_disable_inline_optimizer : https://scans.gradle.com/s/c6h5hy2nxod4u
- You can see R8 debug mode on build log : https://scans.gradle.com/s/c6h5hy2nxod4u/console-log#L95

Also, I pushed to update MLKit Language Id version 17.0.1 on mlkit17_agp7 branch And here is gradle build scan

https://scans.gradle.com/s/ytaa2kkbp5vc4
- Here is version of com.google.mlkit:language-id

And here is crash log after apply 17.0.1
You can see that BuildId of liblanguage_id_l2c_jni.so was changed from 859ec0ec2000a39e6ae8ed42e1704f46 to be6e59455cc10135330c93acdebfc121

10-20 03:07:24.522 24587 24628 F libc    : Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x7acf995426 in tid 24628 (pool-3-thread-3), pid 24587 (e.myapplication)
10-20 03:07:25.190 24710 24710 F DEBUG   : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
10-20 03:07:25.190 24710 24710 F DEBUG   : Build fingerprint: 'google/crosshatch/crosshatch:12/SPB5.210812.002/7671067:user/release-keys'
10-20 03:07:25.190 24710 24710 F DEBUG   : Revision: 'MP1.0'
10-20 03:07:25.190 24710 24710 F DEBUG   : ABI: 'arm64'
10-20 03:07:25.190 24710 24710 F DEBUG   : Timestamp: 2021-10-20 03:07:24.583346246+0900
10-20 03:07:25.190 24710 24710 F DEBUG   : Process uptime: 0s
10-20 03:07:25.190 24710 24710 F DEBUG   : Cmdline: com.example.myapplication
10-20 03:07:25.190 24710 24710 F DEBUG   : pid: 24587, tid: 24628, name: pool-3-thread-3  >>> com.example.myapplication <<<
10-20 03:07:25.190 24710 24710 F DEBUG   : uid: 10240
10-20 03:07:25.190 24710 24710 F DEBUG   : signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x7acf995426
10-20 03:07:25.190 24710 24710 F DEBUG   :     x0  0000007b54da9d30  x1  0000007d9a5fe7cc  x2  0000000000000000  x3  0000000000000010
10-20 03:07:25.190 24710 24710 F DEBUG   :     x4  0000000000000000  x5  0000007c34dbc79c  x6  0000002f0000083b  x7  000003c300002dd5
10-20 03:07:25.190 24710 24710 F DEBUG   :     x8  0000000000000001  x9  0000000000000004  x10 0000000000000010  x11 0000000000000000
10-20 03:07:25.190 24710 24710 F DEBUG   :     x12 0000000000000000  x13 000000000000217e  x14 0000007acf9932a8  x15 000000000000217e
10-20 03:07:25.190 24710 24710 F DEBUG   :     x16 0000000000000000  x17 0000007d9a564c78  x18 0000007a6ef18000  x19 0000007c34dbc580
10-20 03:07:25.190 24710 24710 F DEBUG   :     x20 0000007ca4dc7170  x21 0000007ca4dc7800  x22 0000007ca4dc71e0  x23 0000000000000000
10-20 03:07:25.190 24710 24710 F DEBUG   :     x24 0000000000000018  x25 0000000000000007  x26 0000000000000006  x27 0000000000000004
10-20 03:07:25.190 24710 24710 F DEBUG   :     x28 0000007ca4dc7090  x29 0000007cb4da9940
10-20 03:07:25.190 24710 24710 F DEBUG   :     lr  0000007a770a9624  sp  0000007a6f7de9c0  pc  0000007a770a96a8  pst 0000000020000000
10-20 03:07:25.190 24710 24710 F DEBUG   : backtrace:
10-20 03:07:25.190 24710 24710 F DEBUG   :       #00 pc 00000000000386a8  /data/app/~~KjjULZV48O7KSOgOP1wYNQ==/com.example.myapplication-vFUidUPTjaGg4oo3SRAYJw==/lib/arm64/liblanguage_id_l2c_jni.so (BuildId: be6e59455cc10135330c93acdebfc121)
10-20 03:07:25.190 24710 24710 F DEBUG   :       #01 pc 00000000000388a0  /data/app/~~KjjULZV48O7KSOgOP1wYNQ==/com.example.myapplication-vFUidUPTjaGg4oo3SRAYJw==/lib/arm64/liblanguage_id_l2c_jni.so (BuildId: be6e59455cc10135330c93acdebfc121)
10-20 03:07:25.190 24710 24710 F DEBUG   :       #02 pc 00000000000844a0  /data/app/~~KjjULZV48O7KSOgOP1wYNQ==/com.example.myapplication-vFUidUPTjaGg4oo3SRAYJw==/lib/arm64/liblanguage_id_l2c_jni.so (BuildId: be6e59455cc10135330c93acdebfc121)
10-20 03:07:25.190 24710 24710 F DEBUG   :       #03 pc 000000000008783c  /data/app/~~KjjULZV48O7KSOgOP1wYNQ==/com.example.myapplication-vFUidUPTjaGg4oo3SRAYJw==/lib/arm64/liblanguage_id_l2c_jni.so (BuildId: be6e59455cc10135330c93acdebfc121)
10-20 03:07:25.190 24710 24710 F DEBUG   :       #04 pc 0000000000035fc4  /data/app/~~KjjULZV48O7KSOgOP1wYNQ==/com.example.myapplication-vFUidUPTjaGg4oo3SRAYJw==/lib/arm64/liblanguage_id_l2c_jni.so (BuildId: be6e59455cc10135330c93acdebfc121)
10-20 03:07:25.190 24710 24710 F DEBUG   :       #05 pc 0000000000034954  /data/app/~~KjjULZV48O7KSOgOP1wYNQ==/com.example.myapplication-vFUidUPTjaGg4oo3SRAYJw==/lib/arm64/liblanguage_id_l2c_jni.so (BuildId: be6e59455cc10135330c93acdebfc121)
10-20 03:07:25.190 24710 24710 F DEBUG   :       #06 pc 00000000000340e8  /data/app/~~KjjULZV48O7KSOgOP1wYNQ==/com.example.myapplication-vFUidUPTjaGg4oo3SRAYJw==/lib/arm64/liblanguage_id_l2c_jni.so (Java_com_google_mlkit_nl_languageid_internal_ThickLanguageIdentifier_nativeIdentifyPossibleLanguages+108) (BuildId: be6e59455cc10135330c93acdebfc121)
10-20 03:07:25.191 24710 24710 F DEBUG   :       #07 pc 00000000002d9a44  /apex/com.android.art/lib64/libart.so (art_quick_generic_jni_trampoline+148) (BuildId: cdecb8dde1264c9871695c29854aa3b1)
10-20 03:07:25.191 24710 24710 F DEBUG   :       #08 pc 000000000020a700  /apex/com.android.art/lib64/libart.so (nterp_helper+5648) (BuildId: cdecb8dde1264c9871695c29854aa3b1)
10-20 03:07:25.191 24710 24710 F DEBUG   :       #09 pc 00000000000cd0dc  /data/app/~~KjjULZV48O7KSOgOP1wYNQ==/com.example.myapplication-vFUidUPTjaGg4oo3SRAYJw==/oat/arm64/base.vdex
10-20 03:07:25.191 24710 24710 F DEBUG   :       #10 pc 000000000020a044  /apex/com.android.art/lib64/libart.so (nterp_helper+3924) (BuildId: cdecb8dde1264c9871695c29854aa3b1)
10-20 03:07:25.191 24710 24710 F DEBUG   :       #11 pc 00000000000ccfa8  /data/app/~~KjjULZV48O7KSOgOP1wYNQ==/com.example.myapplication-vFUidUPTjaGg4oo3SRAYJw==/oat/arm64/base.vdex
10-20 03:07:25.191 24710 24710 F DEBUG   :       #12 pc 0000000000557cb4  /system/framework/arm64/boot-framework.oat (android.os.Binder.transact+148) (BuildId: 43a571a0ad85d6451b47016336a541ecb0eb12bb)
10-20 03:07:25.191 24710 24710 F DEBUG   :       #13 pc 000000000020b53c  /apex/com.android.art/lib64/libart.so (nterp_helper+9292) (BuildId: cdecb8dde1264c9871695c29854aa3b1)
10-20 03:07:25.191 24710 24710 F DEBUG   :       #14 pc 00000000000b7aba  /data/app/~~KjjULZV48O7KSOgOP1wYNQ==/com.example.myapplication-vFUidUPTjaGg4oo3SRAYJw==/oat/arm64/base.vdex
10-20 03:07:25.191 24710 24710 F DEBUG   :       #15 pc 000000000020a044  /apex/com.android.art/lib64/libart.so (nterp_helper+3924) (BuildId: cdecb8dde1264c9871695c29854aa3b1)
10-20 03:07:25.191 24710 24710 F DEBUG   :       #16 pc 00000000000a7496  /data/app/~~KjjULZV48O7KSOgOP1wYNQ==/com.example.myapplication-vFUidUPTjaGg4oo3SRAYJw==/oat/arm64/base.vdex
10-20 03:07:25.191 24710 24710 F DEBUG   :       #17 pc 000000000020a044  /apex/com.android.art/lib64/libart.so (nterp_helper+3924) (BuildId: cdecb8dde1264c9871695c29854aa3b1)
10-20 03:07:25.191 24710 24710 F DEBUG   :       #18 pc 00000000000a7360  /data/app/~~KjjULZV48O7KSOgOP1wYNQ==/com.example.myapplication-vFUidUPTjaGg4oo3SRAYJw==/oat/arm64/base.vdex
10-20 03:07:25.191 24710 24710 F DEBUG   :       #19 pc 000000000020ae64  /apex/com.android.art/lib64/libart.so (nterp_helper+7540) (BuildId: cdecb8dde1264c9871695c29854aa3b1)
10-20 03:07:25.191 24710 24710 F DEBUG   :       #20 pc 000000000009e46c  /data/app/~~KjjULZV48O7KSOgOP1wYNQ==/com.example.myapplication-vFUidUPTjaGg4oo3SRAYJw==/oat/arm64/base.vdex
10-20 03:07:25.191 24710 24710 F DEBUG   :       #21 pc 000000000020ae64  /apex/com.android.art/lib64/libart.so (nterp_helper+7540) (BuildId: cdecb8dde1264c9871695c29854aa3b1)
10-20 03:07:25.191 24710 24710 F DEBUG   :       #22 pc 00000000000d33d6  /data/app/~~KjjULZV48O7KSOgOP1wYNQ==/com.example.myapplication-vFUidUPTjaGg4oo3SRAYJw==/oat/arm64/base.vdex
10-20 03:07:25.191 24710 24710 F DEBUG   :       #23 pc 000000000020ae64  /apex/com.android.art/lib64/libart.so (nterp_helper+7540) (BuildId: cdecb8dde1264c9871695c29854aa3b1)
10-20 03:07:25.191 24710 24710 F DEBUG   :       #24 pc 000000000009df0a  /data/app/~~KjjULZV48O7KSOgOP1wYNQ==/com.example.myapplication-vFUidUPTjaGg4oo3SRAYJw==/oat/arm64/base.vdex
10-20 03:07:25.191 24710 24710 F DEBUG   :       #25 pc 0000000000209124  /apex/com.android.art/lib64/libart.so (nterp_helper+52) (BuildId: cdecb8dde1264c9871695c29854aa3b1)
10-20 03:07:25.191 24710 24710 F DEBUG   :       #26 pc 000000000009e350  /data/app/~~KjjULZV48O7KSOgOP1wYNQ==/com.example.myapplication-vFUidUPTjaGg4oo3SRAYJw==/oat/arm64/base.vdex
10-20 03:07:25.191 24710 24710 F DEBUG   :       #27 pc 000000000037b9ac  /apex/com.android.art/javalib/arm64/boot.oat (java.util.concurrent.ThreadPoolExecutor.runWorker+988) (BuildId: ab2bf4ec264efdb6c452a238be38fe624de826b8)
10-20 03:07:25.191 24710 24710 F DEBUG   :       #28 pc 00000000003751d4  /apex/com.android.art/javalib/arm64/boot.oat (java.util.concurrent.ThreadPoolExecutor$Worker.run+68) (BuildId: ab2bf4ec264efdb6c452a238be38fe624de826b8)
10-20 03:07:25.191 24710 24710 F DEBUG   :       #29 pc 000000000020aec4  /apex/com.android.art/lib64/libart.so (nterp_helper+7636) (BuildId: cdecb8dde1264c9871695c29854aa3b1)
10-20 03:07:25.191 24710 24710 F DEBUG   :       #30 pc 000000000009e370  /data/app/~~KjjULZV48O7KSOgOP1wYNQ==/com.example.myapplication-vFUidUPTjaGg4oo3SRAYJw==/oat/arm64/base.vdex
10-20 03:07:25.191 24710 24710 F DEBUG   :       #31 pc 00000000001bf35c  /apex/com.android.art/javalib/arm64/boot.oat (java.lang.Thread.run+76) (BuildId: ab2bf4ec264efdb6c452a238be38fe624de826b8)
10-20 03:07:25.191 24710 24710 F DEBUG   :       #32 pc 00000000002d0164  /apex/com.android.art/lib64/libart.so (art_quick_invoke_stub+548) (BuildId: cdecb8dde1264c9871695c29854aa3b1)
10-20 03:07:25.191 24710 24710 F DEBUG   :       #33 pc 000000000031ccac  /apex/com.android.art/lib64/libart.so (art::ArtMethod::Invoke(art::Thread*, unsigned int*, unsigned int, art::JValue*, char const*)+156) (BuildId: cdecb8dde1264c9871695c29854aa3b1)
10-20 03:07:25.191 24710 24710 F DEBUG   :       #34 pc 00000000003cf8a0  /apex/com.android.art/lib64/libart.so (art::JValue art::InvokeVirtualOrInterfaceWithJValues<art::ArtMethod*>(art::ScopedObjectAccessAlreadyRunnable const&, _jobject*, art::ArtMethod*, jvalue const*)+380) (BuildId: cdecb8dde1264c9871695c29854aa3b1)
10-20 03:07:25.191 24710 24710 F DEBUG   :       #35 pc 0000000000460894  /apex/com.android.art/lib64/libart.so (art::Thread::CreateCallback(void*)+992) (BuildId: cdecb8dde1264c9871695c29854aa3b1)
10-20 03:07:25.191 24710 24710 F DEBUG   :       #36 pc 00000000000b1910  /apex/com.android.runtime/lib64/bionic/libc.so (__pthread_start(void*)+264) (BuildId: ba489d4985c0cf173209da67405662f9)
10-20 03:07:25.191 24710 24710 F DEBUG   :       #37 pc 00000000000513f0  /apex/com.android.runtime/lib64/bionic/libc.so (__start_thread+64) (BuildId: ba489d4985c0cf173209da67405662f9)

Message last modified on Apr 2, 2020 06:29AM

[Deleted User] <[Deleted User]> #14Apr 2, 2020 01:51PM

Cross-posted on R8 issue tracker. https://issuetracker.google.com/issues/203573699

Message last modified on Apr 3, 2020 08:21AM

sh...@magicpin.in <sh...@magicpin.in> #15Apr 5, 2020 08:00PM

Hi,

Looks like we figured out the root cause in b/203573699

For temporary workarounds for the existing SDKs, you need to add this rule

-keep class com.google.mlkit.nl.languageid.internal.LanguageIdentificationJni { *; }

for language-id 16.1.1, and add this rule

-keep class com.google.mlkit.nl.languageid.internal.ThickLanguageIdentifier { *; }

for version language-id 17.0.0+ for the newer model.

We'll fix this issue in the upcoming release so that you'll not need these workarounds in the future release.

Thanks a lot for reporting this issue!

ra...@google.com <ra...@google.com> #16Apr 6, 2020 04:10PM

Added workarounds in Known issues section in public docs.

ze...@gmail.com <ze...@gmail.com> #17Jun 23, 2020 01:38PM

https://issuetracker.google.com/issues/250610583

https://issuetracker.google.com/issues/250609756

https://issuetracker.google.com/issues/250609759

https://issuetracker.google.com/issues/250610272

https://issuetracker.google.com/issues/250610273

https://issuetracker.google.com/issues/250610276

https://issuetracker.google.com/issues/250610278

https://issuetracker.google.com/issues/250610593

https://issuetracker.google.com/issues/250610280

https://issuetracker.google.com/issues/250610923

https://issuetracker.google.com/issues/250610282

https://issuetracker.google.com/issues/250611106

https://issuetracker.google.com/issues/250610598

https://issuetracker.google.com/issues/250611463

https://issuetracker.google.com/issues/250611111

https://issuetracker.google.com/issues/250610933

https://issuetracker.google.com/issues/250610935

https://issuetracker.google.com/issues/250611113

https://issuetracker.google.com/issues/250610937

https://issuetracker.google.com/issues/250611116

https://issuetracker.google.com/issues/250611466

https://issuetracker.google.com/issues/250612724

https://issuetracker.google.com/issues/250612604

https://issuetracker.google.com/issues/250612726

https://issuetracker.google.com/issues/250611471

https://issuetracker.google.com/issues/250177858

https://issuetracker.google.com/issues/250172577

https://www.endezo-it.com/2022/10/the-dark-event-of-indonesian-football.html

https://www.49erssports.com/2022/10/kanjuruhan-tragedy-arema-fc-management.html

https://one-piece-red-full-movie-english.webflow.io/

https://documenter.getpostman.com/view/21828632/2s83tJGAat

ra...@google.com <ra...@google.com> #18Jun 23, 2020 05:26PM

Yes, AppMeasurementJobService would be an example.

[Deleted User] <[Deleted User]> #19Nov 9, 2020 11:10AM

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> #20Aug 11, 2021 05:14PM

Hi Team, I am running into this issue after updating the library to v2.5.0. Please find the logs below for your reference. Kindly please help me in resolving this. Also, I can't cancel all the jobs in my application class as I am not sure what all jobs are scheduled by other libraries.

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)

Message last modified on Aug 11, 2021 05:15PM

ra...@google.com <ra...@google.com> #21Aug 11, 2021 05:49PM

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> #22Aug 11, 2021 06:00PM

Comment has been deleted.

Message last modified on Aug 11, 2021 06:09PM

[Deleted User] <[Deleted User]> #23Oct 13, 2021 10:00AM

Hi Team! I am still running into this issue. Library version 2.5.0.
* 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.

Message last modified on Oct 13, 2021 10:03AM

Wed Oct 13 2021 15:56:08 GMT+0600 (East Kazakhstan Time).png

150 KB

View

Download

ra...@google.com <ra...@google.com> #24Oct 13, 2021 05:38PM

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> #25Oct 13, 2021 07:43PM

Why is it marked as fixed?
Have you guys solved it? I can see this issue even on relatively new versions of WorkManager

ra...@google.com <ra...@google.com> #26Oct 13, 2021 08:08PM

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> #27Oct 14, 2021 06:13PM

@26 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?

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?

Message last modified on Oct 14, 2021 06:15PM

ra...@google.com <ra...@google.com> #28Oct 14, 2021 06:39PM

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, WorkManagers 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> #29Oct 14, 2021 06:54PM

@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.

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:

https://dontkillmyapp.com/

https://issuetracker.google.com/issues/122098785
?

ra...@google.com <ra...@google.com> #30Oct 14, 2021 07:03PM

@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]> #31Oct 19, 2021 06:06PM

Comment has been deleted.

Message last modified on Oct 21, 2021 11:59AM

[Deleted User] <[Deleted User]> #32Aug 25, 2022 08:49AM

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)

Message last modified on Aug 26, 2022 09:13AM

ra...@google.com <ra...@google.com> #33Sep 6, 2022 08:13PM

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]> #34Sep 6, 2022 08:32PM

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> #35Sep 6, 2022 08:33PM

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]> #36Sep 6, 2022 09:33PM

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 #15 where it says there are only 3 jobs scheduled by WorkManager whereas in my case it says 101.

ra...@google.com <ra...@google.com> #37Sep 6, 2022 09:46PM

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> #38Oct 17, 2022 02:53PM

This still happen in my case. Here is firebase crashlytics report:

```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]> #39Sep 13, 2023 03:51PM

We are using androidx.work:work-runtime-ktx" is 2.8.1, still getting the same exception on Firebase Crashlytics

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> #40Sep 13, 2023 07:58PM

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> #41Feb 15, 2024 01:31PM

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 the KEEP 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?

Message last modified on Feb 15, 2024 01:32PM

ch...@gmail.com <ch...@gmail.com> #42Jun 4, 2024 06:57PM

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> #43Jun 4, 2024 08:16PM

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.

Message last modified on Jun 4, 2024 08:16PM

ch...@gmail.com <ch...@gmail.com> #44Jun 4, 2024 10:12PM

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.)

Message last modified on Jun 4, 2024 10:29PM

ra...@google.com <ra...@google.com> #45Jun 4, 2024 11:56PM

That is extremely strange. Can you try and turn on verbose logging using the instructions in:

https://developer.android.com/develop/background-work/background-tasks/testing/persistent/debug

Could you please Log.DEBUG as your log level so we get more information. Also, can you consistently reproduce this?

ra...@vuclip.com <ra...@vuclip.com> #46Jul 30, 2024 06:21PM

We too observed this in crashlytics. We can see the status of this issue is "Fixed". What is the cause and fix given? Which version of the library has this fix?

al...@gmail.com <al...@gmail.com> #47Feb 25, 2025 01:39AM

I’ve encountered a similar issue while working on the

https://essutumishiportal.co.tz/ It usually happens when WorkManager jobs aren’t properly canceled or cleaned up. Make sure to cancel completed jobs and review your job scheduling logic to stay within the JobScheduler limit.

va...@gmail.com <va...@gmail.com> #48Mar 3, 2025 12:30PM

We are also seeing this error in the crashlytics.

#47, How did you resolve the issue, are you doing pruneWork in Application.onCreate? Were you able to replicate the issue?

Message last modified on Mar 3, 2025 12:36PM

ra...@google.com <ra...@google.com> #49Mar 3, 2025 05:14PM

For posterity: If you are seeing this on a new version of WorkManager - some other component in the app is scheduling jobs and that is what is causing this.

va...@gmail.com <va...@gmail.com> #50Mar 4, 2025 12:41PM

Thank you for reverting back.
Yes, we are using the latest version of WM, that is 2.9.0. The error mentions the count of WM jobs scheduled. "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."

And internally observed, that WM jobs are filtered from all pending jobs:

// 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);
  }
}

Please let me know if I am missing something here.

Message last modified on Mar 4, 2025 12:45PM