Fixed
Status Update
Comments
ma...@google.com <ma...@google.com>
ka...@mercari.com <ka...@mercari.com> #2
Bringing setMaxSchedulerLimit to say 49 doesn't help. Same error.
an...@google.com <an...@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 ?
ka...@mercari.com <ka...@mercari.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)
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?
ap...@google.com <ap...@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.
an...@google.com <an...@google.com>
ka...@mercari.com <ka...@mercari.com> #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.
st...@google.com <st...@google.com> #8
I don't have to to rummage through traces. Here's code snippet that sends app into a crash loop. https://pastebin.com/NcTAnwjZ
na...@google.com <na...@google.com> #9
I tried to reproduce this on alpha04. However, I cannot reproduce your issue.
For reference, this is what my activity looks like:
class MainActivity : AppCompatActivity() {
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
setContentView(R.layout.activity_main)
findViewById<Button>(R.id.scheduler_limits_testcase1).setOnClickListener {
for (i in 1..100) {
val a1 = newWorkRequest("--- A1 ---")
val b1 = newWorkRequest("--- B1 ---")
val b2 = newWorkRequest("--- B2 ---")
val c1 = newWorkRequest("--- C1 ---")
WorkManager.getInstance()!!
.beginWith(a1).then(b1).enqueue()
WorkManager.getInstance()!!
.beginWith(a1).then(b2).enqueue()
WorkManager.getInstance()!!
.beginWith(b1, b2).then(c1).enqueue()
}
}
}
companion object {
private fun newWorkRequest(message: String): OneTimeWorkRequest {
val data = mapOf(TestWorker.KEY_MESSAGE to message).toWorkData()
return OneTimeWorkRequestBuilder<TestWorker>()
.setInputData(data)
.build()
}
}
}
This is what my Worker looks like:
class TestWorker : Worker() {
companion object {
private const val TAG = "TestWorker"
private const val MESSAGE_DEFAULT = "Default"
const val KEY_MESSAGE = "KEY_MESSAGE"
}
override fun doWork(): Result {
val message = inputData.getString(KEY_MESSAGE, MESSAGE_DEFAULT)
val random = Random()
val time = 500L + random.nextInt(300)
Log.d(TAG, "Before. $message")
Thread.sleep(time)
Log.d(TAG, "After. $message")
return Result.SUCCESS
}
}
For reference, this is what my activity looks like:
class MainActivity : AppCompatActivity() {
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
setContentView(R.layout.activity_main)
findViewById<Button>(R.id.scheduler_limits_testcase1).setOnClickListener {
for (i in 1..100) {
val a1 = newWorkRequest("--- A1 ---")
val b1 = newWorkRequest("--- B1 ---")
val b2 = newWorkRequest("--- B2 ---")
val c1 = newWorkRequest("--- C1 ---")
WorkManager.getInstance()!!
.beginWith(a1).then(b1).enqueue()
WorkManager.getInstance()!!
.beginWith(a1).then(b2).enqueue()
WorkManager.getInstance()!!
.beginWith(b1, b2).then(c1).enqueue()
}
}
}
companion object {
private fun newWorkRequest(message: String): OneTimeWorkRequest {
val data = mapOf(TestWorker.KEY_MESSAGE to message).toWorkData()
return OneTimeWorkRequestBuilder<TestWorker>()
.setInputData(data)
.build()
}
}
}
This is what my Worker looks like:
class TestWorker : Worker() {
companion object {
private const val TAG = "TestWorker"
private const val MESSAGE_DEFAULT = "Default"
const val KEY_MESSAGE = "KEY_MESSAGE"
}
override fun doWork(): Result {
val message = inputData.getString(KEY_MESSAGE, MESSAGE_DEFAULT)
val random = Random()
val time = 500L + random.nextInt(300)
Log.d(TAG, "Before. $message")
Thread.sleep(time)
Log.d(TAG, "After. $message")
return Result.SUCCESS
}
}
al...@mercari.com <al...@mercari.com> #10
Do you have another part of your codebase that is scheduling jobs with JobScheduler?
an...@google.com <an...@google.com> #11
We have 1 job that schedules once on app start, that's it.
Description
Jetpack Compose version: 1.3.0 & 1.4.0-alpha02
Android Studio Build: IntelliJ IDEA 2022.2.3
Kotlin version: 1.7.10
Steps to Reproduce or Code Sample to Reproduce:
We're seeing an issue where a Lazy layout with a BoxWithConstraints in the
item
will add new items to the saved bundle every time the user scrolls. The entries appear to be AbsSavedState.EMPTY_STATE, but there are so many of them that the bundle fills up quickly and can cause a "TransactionTooLargeException".I've attached a sample project demonstrating the issue. The issue only appears on Android 9, and the sample project does not exhibit the issue in either Android 8.1 or Android 10. Nor does the issue happen when swapping BoxWithConstraints with Box. Also it appears to have been introduced some point after Compose 1.2.0, as the sample also doesn't experience the issue on Android 9 when using Compose 1.2.0.