AlarmManager.SetRepeating(AlarmType, Int64, Int64, PendingIntent) Method

  • Reference

Definition

Namespace:
Android.App
Assembly:
Mono.Android.dll

Schedule a repeating alarm.

[Android.Runtime.Register("setRepeating", "(IJJLandroid/app/PendingIntent;)V", "GetSetRepeating_IJJLandroid_app_PendingIntent_Handler")]
public virtual void SetRepeating (Android.App.AlarmType type, long triggerAtMillis, long intervalMillis, Android.App.PendingIntent operation);
[<Android.Runtime.Register("setRepeating", "(IJJLandroid/app/PendingIntent;)V", "GetSetRepeating_IJJLandroid_app_PendingIntent_Handler")>]
abstract member SetRepeating : Android.App.AlarmType * int64 * int64 * Android.App.PendingIntent -> unit
override this.SetRepeating : Android.App.AlarmType * int64 * int64 * Android.App.PendingIntent -> unit

Parameters

type
AlarmType

type of alarm.

triggerAtMillis
Int64

time in milliseconds that the alarm should first go off, using the appropriate clock (depending on the alarm type).

intervalMillis
Int64

interval in milliseconds between subsequent repeats of the alarm.

operation
PendingIntent

Action to perform when the alarm goes off; typically comes from PendingIntent#getBroadcast IntentSender.getBroadcast().

Attributes
RegisterAttribute

Remarks

Schedule a repeating alarm. <b>Note: for timing operations (ticks, timeouts, etc) it is easier and much more efficient to use android.os.Handler.</b> If there is already an alarm scheduled for the same IntentSender, it will first be canceled.

Like #set, except you can also supply a period at which the alarm will automatically repeat. This alarm continues repeating until explicitly removed with #cancel. 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.

<p class="note"> <b>Note:</b> 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.

Apps targeting Build.VERSION_CODES#S will need to set the flag PendingIntent#FLAG_MUTABLE on the PendingIntent being used to set this alarm, if they want the alarm count to be supplied with the key Intent#EXTRA_ALARM_COUNT.

Java documentation for android.app.AlarmManager.setRepeating(int, long, long, android.app.PendingIntent).

Portions of this page are modifications based on work created and shared by the Android Open Source Project and used according to terms described in the Creative Commons 2.5 Attribution License.

Applies to

See also

  • Handler
  • <xref:Android.App.AlarmManager.Set(Android.App.AlarmType%2c+System.Int64%2c+System.Int64)>
  • <xref:Android.App.AlarmManager.SetExact(Android.App.AlarmType%2c+System.Int64%2c+System.Int64)>
  • <xref:Android.App.AlarmManager.SetWindow(Android.App.AlarmType%2c+System.Int64%2c+System.Int64%2c+System.Int64)>
  • Cancel(PendingIntent)
  • SendBroadcast(Intent)
  • <xref:Android.Content.Context.RegisterReceiver(Android.Content.BroadcastReceiver%2c+Android.Content.IntentFilter)>
  • FilterEquals(Intent)