Fixed
Status Update
Comments
ra...@google.com <ra...@google.com>
ra...@google.com <ra...@google.com> #2
Hello,
We recently launched an update that includes "androidx.work:work-runtime:2.0.1", and we used it to schedule all our tasks now, in a satisfactory way. I just want to inform, (as you can see in the images attached below), that this problem keeps happening sporadically.
Keep in mind that the number of users affected in our case is small, since the app has several million active users, but it also starts to be worrisome, since the number of errors generated by each user is high.
The errors mainly occur in Android 6 and 7, and sometimes in 8, but especially in Android 7.
I do not expose implementation details, since the documentation of this SDK has been thoroughly studied, and in case there was a bad implementation, the number of errors would be infinitely greater.
Greetings.
PD: If you need any information that I can provide you, you just have to ask me.
We recently launched an update that includes "androidx.work:work-runtime:2.0.1", and we used it to schedule all our tasks now, in a satisfactory way. I just want to inform, (as you can see in the images attached below), that this problem keeps happening sporadically.
Keep in mind that the number of users affected in our case is small, since the app has several million active users, but it also starts to be worrisome, since the number of errors generated by each user is high.
The errors mainly occur in Android 6 and 7, and sometimes in 8, but especially in Android 7.
I do not expose implementation details, since the documentation of this SDK has been thoroughly studied, and in case there was a bad implementation, the number of errors would be infinitely greater.
Greetings.
PD: If you need any information that I can provide you, you just have to ask me.
su...@google.com <su...@google.com>
da...@gmail.com <da...@gmail.com> #3
Thanks for re-uploading the screenshots.
A couple of questions:
* Can you reproduce this issue at all on your end ? If so, can you send us all WorkManager logs after turning on logging. For this you will have to use custom initialization and use Log.DEBUG. For more information look athttps://developer.android.com/topic/libraries/architecture/workmanager/advanced/custom-configuration
* Can you send us a breakdown of devices and total # of users affected ? The number of crashes will be dis proportionally high because once the app gets into this state - its hard to get out of it.
A couple of questions:
* Can you reproduce this issue at all on your end ? If so, can you send us all WorkManager logs after turning on logging. For this you will have to use custom initialization and use Log.DEBUG. For more information look at
* Can you send us a breakdown of devices and total # of users affected ? The number of crashes will be dis proportionally high because once the app gets into this state - its hard to get out of it.
Description
I recently switched my JobManager TriggerContentUri implementation to WorkManager and am noticing a major slowdown in the speed at which it responds to ContentUri changes vs. JobManager.
In JobManager, there is an api call to builder.setTriggerContentMaxDelay() that I use as follows to ensure a response within 3 seconds of the content change - this allows my widget UI to be responsive and show a new calendar event created in the Google Calendar app quickly.
public static void scheduleJob(Context context) {
JobScheduler js = context.getSystemService(JobScheduler.class);
JobInfo.Builder builder = new JobInfo.Builder(JOB_TAG_CALENDAR,
new ComponentName(context, CalendarContentTriggerJob.class));
builder.addTriggerContentUri(new JobInfo.TriggerContentUri(CalendarContract.CONTENT_URI,
JobInfo.TriggerContentUri.FLAG_NOTIFY_FOR_DESCENDANTS));
builder.setTriggerContentUpdateDelay(DateUtils.SECOND_IN_MILLIS);
builder.setTriggerContentMaxDelay(3 * DateUtils.SECOND_IN_MILLIS);
js.schedule(builder.build());
}
My WorkManager implementation looks as follows. There is no way of specifying a Max Delay and as a result the response to the content change is significantly slower than the JobManager implementation.
fun scheduleJob() {
// Define the constraints
val constraints = Constraints.Builder()
.addContentUriTrigger(CalendarContract.CONTENT_URI, true)
.build()
// Create the job definition
val calendarSync = OneTimeWorkRequest.Builder(CalendarContentTriggerWorker::class.java)
.setConstraints(constraints)
.addTag(JOB_TAG_CALENDAR)
.build()
// Start the job
WorkManager.getInstance().enqueueUniqueWork(JOB_TAG_CALENDAR, ExistingWorkPolicy.REPLACE,
calendarSync)
}