java.lang.Object | |
↳ | android.app.job.JobInfo.Builder |
Builder class for constructing JobInfo
objects.
Public Constructors | |||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Public Methods | |||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Set up the back-off/retry policy.
| |||||||||||
Set optional extras.
| |||||||||||
Specify that this job should be delayed by the provided amount of time.
| |||||||||||
Set deadline which is the maximum scheduling latency.
| |||||||||||
Specify that this job should recur with the provided interval, not more than once per
period.
| |||||||||||
Set some description of the kind of network capabilities you would like to have.
| |||||||||||
Specify that to run this job, the device needs to be plugged in.
| |||||||||||
Specify that to run, the job needs the device to be in idle mode.
|
[Expand]
Inherited Methods | |||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
From class
java.lang.Object
|
jobId | Application-provided id for this job. Subsequent calls to cancel, or jobs created with the same jobId, will update the pre-existing job with the same id. |
---|---|
jobService | The endpoint that you implement that will receive the callback from the JobScheduler. |
Set up the back-off/retry policy.
This defaults to some respectable values: {5 seconds, Exponential}. We cap back-off at
1hr.
Note that trying to set a backoff criteria for a job with
setRequiresDeviceIdle(boolean)
will throw an exception when you call build().
This is because back-off typically does not make sense for these types of jobs. See
jobFinished(android.app.job.JobParameters, boolean)
for more description of the return value for the case of a job executing while in idle
mode.
initialBackoffMillis | Millisecond time interval to wait initially when job has failed. |
---|---|
backoffPolicy | is one of JobInfo.BackoffPolicy
|
Set optional extras. This is persisted, so we only allow primitive types.
extras | Bundle containing extras you want the scheduler to hold on to for you. |
---|
Specify that this job should be delayed by the provided amount of time.
Because it doesn't make sense setting this property on a periodic job, doing so will
throw an IllegalArgumentException
when
build()
is called.
minLatencyMillis | Milliseconds before which this job will not be considered for execution. |
---|
Set deadline which is the maximum scheduling latency. The job will be run by this
deadline even if other requirements are not met. Because it doesn't make sense setting
this property on a periodic job, doing so will throw an
IllegalArgumentException
when
build()
is called.
Specify that this job should recur with the provided interval, not more than once per
period. You have no control over when within this interval this job will be executed,
only the guarantee that it will be executed at most once within this interval.
A periodic job will be repeated until the phone is turned off, however it will only be
persisted beyond boot if the client app has declared the
RECEIVE_BOOT_COMPLETED
permission. You can schedule
periodic jobs without this permission, they simply will cease to exist after the phone
restarts.
Setting this function on the builder with setMinimumLatency(long)
or
setOverrideDeadline(long)
will result in an error.
intervalMillis | Millisecond interval for which this job will repeat. |
---|
Set some description of the kind of network capabilities you would like to have. This
will be a parameter defined in JobInfo.NetworkType
.
Not calling this function means the network is not necessary.
Bear in mind that calling this function defines network as a strict requirement for your
job if the network requested is not available your job will never run. See
setOverrideDeadline(long)
to change this behaviour.
Specify that to run this job, the device needs to be plugged in. This defaults to false.
requiresCharging | Whether or not the device is plugged in. |
---|
Specify that to run, the job needs the device to be in idle mode. This defaults to false.
Idle mode is a loose definition provided by the system, which means that the device is not in use, and has not been in use for some time. As such, it is a good time to perform resource heavy jobs. Bear in mind that battery usage will still be attributed to your application, and surfaced to the user in battery stats.
requiresDeviceIdle | Whether or not the device need be within an idle maintenance window. |
---|