Backup +and Restore on Scheduled Tasks in Persistent Schedules

When scheduling tasks in persistent schedules, special consideration must +be given to the effects of backup and restore operations. Persistent schedules +and tasks associated with them are backed up during a backup operation. This +results in the storage of their status at the time of backup. When the data +is restored on the same phone or another phone, the persistent scheduled tasks +are recreated. This results in the overwrite of any existing persistent schedule +and task on the phone.

Note: Transient schedule and tasks are affected by the backup or +restore process.

Impact of backup and restore on persistent schedules and tasks

State +information associated with a phone, such as date, time and conditions are +not backed up with schedules and tasks, during a phone backup. The date or +time of a phone at the time of a backup is always likely to be different from +the date or time of the target phone during restore. The conditions that are +based on RProperty values that indicate the various states +of a phone might also be different between the time of backup and the time +of restore. One example is the network status, which may be unavailable at +the time of backup, but available at the time of restore.

Possible +problems

When a task is scheduled in a persistent schedule, its +execution depends on a specific time or condition to become due. If the phone +is backed up before the schedule is due, the schedule information is also +part of the backup. Later, when the time or condition is satisfied, the task +is executed on the phone. But, when a phone restore is done after the task +is executed on the phone, the schedule may be due again and the task may get +executed, if the same time or condition is satisfied again.

For example, +assume that a condition-based task is created to send an SMS when the network +is available. In addition, assume that when this task is created the network +is unavailable and a phone backup is taken. After the backup, the phone network +may become available and the SMS may be sent. In this scenario, when a phone +restore is done the SMS may be sent again when the network is available, which +can result in additional SMS costs.

Recommended alternatives

The +non-repeatable nature of the tasks cannot be determined by the task scheduler +automatically, and there is no mechanism for setting per-schedule backup options. +For this reason, clients that create non-repeatable tasks must be aware of +backup and restore implications and consider this fact in their designs.

Clients +can use transient schedules for non-repeatable tasks, which eliminates this +problem because transient schedules are not backed up or restored. If the +use of a persistent schedule is necessary, clients can choose to become backup-aware +by registering for notifications through CBaBackupSessionWrapper or +using the Secure Backup +Engine APIs, and taking appropriate actions. These actions might be +to delete the non-repeatable task before backup or after restore, or rescheduling +it after restore to a different time for time-based schedules.

Note: Any +schedule that expires or becomes ready to execute when a backup or restore +is in progress is delayed, and is only executed when the backup or restore +process is completed.