| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
Change-Id: I8f64fe6c4c44a92ff6d07250223ba590a1d691b0
|
|
|
|
|
|
|
|
|
|
|
|
| |
BUG: 17424511
Introduce an "isOverrideDeadlineExpired" which will allow clients
to know when they are being run due to an expiry.
Nb that we check deadline expiry by checking that the constraints on
the job are not satisfied at execution time. Really this is the same
thing, as a job will not be run without its constraints being met,
unless the job has expired.
Change-Id: I4b91e5b5eadccabd91296d5a5ca66b859dbfaf5c
|
|
|
|
|
|
|
|
| |
BUG: 17005336
Took the opportunity to clean up some back-off logic
Change-Id: Ibc8ae34d1d44dd064ba071e4cbad17872f7e38cf
|
|
|
|
|
|
| |
BUG: 12876556
Minor changes to test app to make persisting an option.
Change-Id: I1b40347878ec5ca44cd717ebfeb544f6c58473b5
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Client can jobFinished() before getting a cancel msg.
1) Do better clean up of JobServiceContext after client jobFinished()
to remove superfluous MSG_CANCELs
2) When processing MSG_CANCEL check whether the context is still active
3) Do JobServiceContext cleanup before calling back to JobSchedulerService
Client can get a cancel msg even after calling jobFinished() (opposite to above)
1) explicitly check whether there are any MSG_CALLBACKs in the queue before
processing a MSG_CANCEL. If there are we can throw away the cancel.
Bug: 16547638
Change-Id: I90644586c7895a9ce97de752a5d657faf7f74b78
|
|
|
|
|
|
| |
adds the rest of the constraints - charging, idle, and allows you
to cancel all.
Change-Id: I43b7cac94446f6860ca0387440b3c8f995a2c0f3
|
|
|
|
|
|
|
|
| |
Switch to the official "JobScheduler" etc naming.
Bug 14997851
Change-Id: I73a61aaa9af0740c114d08188bd97c52f3ac86b7
|
|
Schedule either a delay/deadline task, or a task with
connectivity constraints
Change-Id: Ie7ea731d0f6673b680cef79f894cb609a61b795d
|