Android-job: Rescheduling timer is going crazy

[deviant-studio]

Greetings, Ralf!
I use Nougat device to test exact job (i need just alarm manager fashioned behavior)
The problem occurs when i return Job.Result.RESCHEDULE in my onRunJob(). Looks like the lib trying to reschedule the failed job with startMs +backoffMs (which is backoffMs * mNumFailures in fact) delay. So for example if i schedule the task on +5 hours, the next rescheduled task will trigger in 10 hours + some backoff millis. Which is wrong in my opinion. The rescheduling time should be something like currentTime + currentBackoffMs

I suppose the reason is this piece from com.evernote.android.job.JobProxy.Common#getStartMs:

 public static long getStartMs(JobRequest request) {
            return checkedAdd(request.getStartMs(), request.getBackoffOffset());
        }

Will appreciate any advices.

[vRallev]

Thanks for your feedback. After reading the JobScheduler documentation again, I noticed that the JobScheduler does what you're suggesting.

I'll change that.

[vRallev]

Fixed in version 1.1.5. Thanks!

[akramShokri]

Would you please elaborate a bit on this problem?
I am using exponential backoff withouth setExact and I need to know should I update my code with new version or not.
Thanks.

[vRallev]

The behavior has slightly changed. Previously when a job was rescheduled the start and end window increased by the corresponding back-off criteria.

Imagine this job:

new JobRequest.Builder(DemoSyncJob.TAG)
        .setExecutionWindow(3_000L, 4_000L)
        .setBackoffCriteria(5_000L, JobRequest.BackoffPolicy.LINEAR)
        .build();

When this job was rescheduled for the first time, then the execution window changed to (8_000, 9_000), 2nd fail (13_000, 14_000), ...

Now it has changed in that way, that the start and end window aren't added to the back-off criteria anymore. First fail (5_000, 5_000), 2nd fail (10_000, 10_000), ...

Is this helpful?

[akramShokri]

Yes, very helpful.
Thank you.