Status Update
Comments
su...@microsoft.com <su...@microsoft.com> #2
I'm not sure how to edit the description. But forgot to add that this will work when the app is in the foreground. It just doesn't work when you lock your device. I test this by moving the app to the background and then locking my device and checking the logs in Android Studio.
ku...@google.com <ku...@google.com> #3
It would be great if you could prioritize a fix for this issue. Additionally, if there are any alternative ways we can address this from our side, please let us know. Thank you!
su...@microsoft.com <su...@microsoft.com> #4
We also experienced issues with the new version 2.10.0. In our app a Job that is launched at start of the app is triggered and then immediatly cancelled because constraints are not meet anymore. I tried everything from putting it as a foreground job removing all constraints on the job but the behavior stay the same. I will rollback to 2.9.1 until it's fixed. You will find attached some logs of the WM in our app, take a look at job fec664f7-e40c-4df1-baca-3cbc7e1b1ff9.
su...@microsoft.com <su...@microsoft.com> #5
Looks like there is a default tag that contains class name, so we should be able to remove the work by class name.
You can close this issue.
abstract class Builder<B : Builder<B, *>, W : WorkRequest> internal constructor(
internal val workerClass: Class<out ListenableWorker>
) {
internal var backoffCriteriaSet = false
internal var id: UUID = UUID.randomUUID()
internal var workSpec: WorkSpec = WorkSpec(id.toString(), workerClass.name)
internal val tags: MutableSet<String> = mutableSetOf(workerClass.name)
``
Description
Component used:work manager
Version used: 2.8.1
Devices/Android versions reproduced on:
Issue: Our application uses a WorkerFactory class to manage background tasks scheduled through WorkManager. When we refactor code and move worker classes around, the old class names used in existing work entries become invalid. This results in a ClassNotFoundException when the WorkManager tries to create instances of these workers.
Question:
Is there an elegant way to run code during app upgrades that cleans up outdated work entries associated with previously used worker classes? This would prevent the ClassNotFoundException and ensure smooth execution of scheduled tasks after a code refactoring.
Code Sample below*: