Status Update
No update yet.
Comments
dr...@gmail.com
Information redacted by Android Beta Feedback.
dr...@gmail.com
Thank you for reporting this issue. We have shared this with our product and engineering team and will update this issue with more information as it becomes available.
[Deleted User] <[Deleted User]>
Could you please let me know if without Android Auto usage and not using com.njm.njmsafedrivego and com.august.bennu lessen battery drain?
dr...@gmail.com
su...@google.com
Could you please capture a bug report and share it here?
dr...@gmail.com
Please provide the requested information to proceed further. Unfortunately the issue will be closed within 7 days if there is no further update.
ra...@google.com
Unfortunately this is not something WorkManager can do out of the box. This is because when you create an instance of PeriodicWorkRequest using the default constructor (i.e. PeriodicWorkRequestBuilder<YourWorker>(intervalDuration, timeUnit) ) you are essentially telling JobScheduler that the Job can run any time during that interval.
For e.g.
I-1 I-2 I-3 I-4
[---------------][---------------][---------------][---------------]
| |
Lets say you have an interval duration of 15 minutes. JobScheduler could in theory start your job at 14th minute in the interval and then again start another instance of work at the 16th (or the 1st minute in the next interval).
This is because when you don't specify a flex period, JobScheduler rightly assumes that your Job can run at any point in the interval.
Because WorkManager does not have access to JobSchedulers state machine you could in theory get the same Worker (Job) executed back to back or in quick succession, and we don't have a good way to tell if they are for the same or a different period.
If you really don't want 2 instances of the PeriodicWork executing back to back, I recommend specifying a flexDuration as well. Bear in mind that specifying a flex period does not actually _fix_ the bug. There is still a chance that this might happen for other reasons.
For e.g.
I-1 I-2 I-3 I-4
[---------------][---------------][---------------][---------------]
| |
Lets say you have an interval duration of 15 minutes. JobScheduler could in theory start your job at 14th minute in the interval and then again start another instance of work at the 16th (or the 1st minute in the next interval).
This is because when you don't specify a flex period, JobScheduler rightly assumes that your Job can run at any point in the interval.
Because WorkManager does not have access to JobSchedulers state machine you could in theory get the same Worker (Job) executed back to back or in quick succession, and we don't have a good way to tell if they are for the same or a different period.
If you really don't want 2 instances of the PeriodicWork executing back to back, I recommend specifying a flexDuration as well. Bear in mind that specifying a flex period does not actually _fix_ the bug. There is still a chance that this might happen for other reasons.
dr...@gmail.com
OK thanks for the suggestion. Should flexInterval be used in combination with a hand-crafted check for a double call (on the basis that with flexInterval in place you can safely assume that two calls in quick succession are duplicates and not merely two calls from different intervals)? Or just use a flexInterval (of e.g. 5 mins) in isolation?
[Deleted User] <[Deleted User]>
Do we have any workaround for Unique OneTimeWorkRequest executing twice?
ra...@google.com
Hi Thiago: Your issue is not related to the tracked issue (for PeriodicWorkRequests').
We fixed a few issues around OneTimeWork in our recent beta's. Can you reproduce this issue with beta05?
If so, can you send us a sample project and logs ?
We fixed a few issues around OneTimeWork in our recent beta's. Can you reproduce this issue with beta05?
If so, can you send us a sample project and logs ?
dr...@gmail.com
Regarding the suggestion in #9: "If you really don't want 2 instances of the PeriodicWork executing back to back, I recommend specifying a flexDuration as well" (I assume you mean flexInterval)
Out of interest, will any flexInterval do? At present I'm using an arbitrary flexInterval of half the interval, but this has the effect that *most often* the first work runs half-way through the first period, and then at each full interval after, so to the user this looks a bit odd (they expect things to be timed relative to the starting point). (I appreciate that the work needn't be performed at the start of the flex window, but could be at any time within it, but it seems that it most often fires at the start at least when the device is awake.)
So could I e.g. set a flexInterval that is e.g. 1 minute shorter than the interval... will that have the desired effect of masking the framework bug referred to above? With such a short flexInterval, it will behave almost like not having a flexInterval, but will hopefully prevent any "double firing" mentioned in the original post?
Out of interest, will any flexInterval do? At present I'm using an arbitrary flexInterval of half the interval, but this has the effect that *most often* the first work runs half-way through the first period, and then at each full interval after, so to the user this looks a bit odd (they expect things to be timed relative to the starting point). (I appreciate that the work needn't be performed at the start of the flex window, but could be at any time within it, but it seems that it most often fires at the start at least when the device is awake.)
So could I e.g. set a flexInterval that is e.g. 1 minute shorter than the interval... will that have the desired effect of masking the framework bug referred to above? With such a short flexInterval, it will behave almost like not having a flexInterval, but will hopefully prevent any "double firing" mentioned in the original post?
dr...@gmail.com
OK sorry I think I understand this "workaround" better now... or rather the underlying reason for the "double run"... it's because with no flex set, the first periodic work in the series *after* network restore can run at any time in the entire first interval, which is quite likely to be immediately after network restore, which is the same time as the deferred periodic work runs. By setting a *small* flex, you force the first periodic run after network restore towards the *end* of the first interval, i.e. well away from the deferred work. So really the solution is to specify a *small* flex, to get work running at or near the end of each interval, safely away from any deferred work that runs when network is restored after an absence.
Description
Is this normal behaviour? I would expect doWork() to be called only _once_ when network is restored, and then again 15 mins later (if network is still available) etc.