- type
- One of AlarmManager.ELAPSED_REALTIME, AlarmManager.ELAPSED_REALTIME_WAKEUP, AlarmManager.RTC, or AlarmManager.RTC_WAKEUP.
- triggerAtMillis
- time in milliseconds that the alarm should first go off, using the appropriate clock (depending on the alarm type).
- intervalMillis
- interval in milliseconds between subsequent repeats of the alarm.
- operation
- Action to perform when the alarm goes off; typically comes from PendingIntent.GetBroadcast(Android.Content.Context, System.Int32, System.Int32, System.Int32).
Schedule a repeating alarm. Note: for timing operations (ticks, timeouts, etc) it is easier and much more efficient to use Android.OS.Handler. If there is already an alarm scheduled for the same IntentSender, it will first be canceled.
Like AlarmManager.Set(AlarmType, System.Int64, System.Int64), except you can also supply a period at which the alarm will automatically repeat. This alarm continues repeating until explicitly removed with AlarmManager.Cancel(PendingIntent). If the stated trigger time is in the past, the alarm will be triggered immediately, with an alarm count depending on how far in the past the trigger time is relative to the repeat interval.
If an alarm is delayed (by system sleep, for example, for non _WAKEUP alarm types), a skipped repeat will be delivered as soon as possible. After that, future alarms will be delivered according to the original schedule; they do not drift over time. For example, if you have set a recurring alarm for the top of every hour but the phone was asleep from 7:45 until 8:45, an alarm will be sent as soon as the phone awakens, then the next alarm will be sent at 9:00.
If your application wants to allow the delivery times to drift in order to guarantee that at least a certain time interval always elapses between alarms, then the approach to take is to use one-time alarms, scheduling the next one yourself when handling each alarm delivery.
Note: as of API 19, all repeating alarms are inexact. If your application needs precise delivery times then it must use one-time exact alarms, rescheduling each time as described above. Legacy applications whose targetSdkVersion is earlier than API 19 will continue to have all of their alarms, including repeating alarms, treated as exact.