In my application which was supposed to trigger an alarm at a specified time, alarm whose purpose was to inform the user via a Notification
, I despaired at obtaining a non precise result. The alarm was ringing, but not at the specified time. This was systematic when the time between the setting of the alarm and the time it was supposed to go off was long.
For this, I was using setExact(RTC_WAKEUP,time,intent)
. After many attemps to make it work, I finally saw and tried the setAlarmClock
function, and everything went fine!!
According to the javadoc, setAlarmClock
is identical to setExact
except that it implies RTC_WAKEUP
. As far as I see, at least one other difference exists. Does anyone know it?
Alarms only. Unlike WorkManager, AlarmManager wakes a device from Doze mode. It is therefore not efficient in terms of power and resource management.
These kinds of alarms — called exact alarms — have the ability to bring the device out of “Doze mode,” one of Android's core battery-saving restrictions.
There are two general clock types for alarms: "elapsed real time" and "real time clock" (RTC). Elapsed real time uses the "time since system boot" as a reference, and real time clock uses UTC (wall clock) time.
setExact()
and setAlarmClock()
both make very similar calls to setImpl()
. If you use RTC_WAKEUP
for your setExact()
call, the only difference is the final arg of type AlarmClockInfo
.
On the service side, the call is received in set(). At the end of that method, we can see the difference the extra argument makes:
@Override
public void set(int type, long triggerAtTime, long windowLength, long interval, int flags,
PendingIntent operation, WorkSource workSource,
AlarmManager.AlarmClockInfo alarmClock) {
final int callingUid = Binder.getCallingUid();
if (workSource != null) {
getContext().enforcePermission(
android.Manifest.permission.UPDATE_DEVICE_STATS,
Binder.getCallingPid(), callingUid, "AlarmManager.set");
}
// No incoming callers can request either WAKE_FROM_IDLE or
// ALLOW_WHILE_IDLE_UNRESTRICTED -- we will apply those later as appropriate.
flags &= ~(AlarmManager.FLAG_WAKE_FROM_IDLE
| AlarmManager.FLAG_ALLOW_WHILE_IDLE_UNRESTRICTED);
// Only the system can use FLAG_IDLE_UNTIL -- this is used to tell the alarm
// manager when to come out of idle mode, which is only for DeviceIdleController.
if (callingUid != Process.SYSTEM_UID) {
flags &= ~AlarmManager.FLAG_IDLE_UNTIL;
}
// If the caller is a core system component, and not calling to do work on behalf
// of someone else, then always set ALLOW_WHILE_IDLE_UNRESTRICTED. This means we
// will allow these alarms to go off as normal even while idle, with no timing
// restrictions.
if (callingUid < Process.FIRST_APPLICATION_UID && workSource == null) {
flags |= AlarmManager.FLAG_ALLOW_WHILE_IDLE_UNRESTRICTED;
}
// If this is an exact time alarm, then it can't be batched with other alarms.
if (windowLength == AlarmManager.WINDOW_EXACT) {
flags |= AlarmManager.FLAG_STANDALONE;
}
// If this alarm is for an alarm clock, then it must be standalone and we will
// use it to wake early from idle if needed.
if (alarmClock != null) {
flags |= AlarmManager.FLAG_WAKE_FROM_IDLE | AlarmManager.FLAG_STANDALONE;
}
setImpl(type, triggerAtTime, windowLength, interval, operation,
flags, workSource, alarmClock, callingUid);
}
If there's a non-null alarmClock
argument, the request gets the FLAG_WAKE_FROM_IDLE
flag, on top of FLAG_STANDALONE
, which you'll get in both cases. And the comment for FLAG_WAKE_FROM_IDLE
says:
Flag for alarms: this alarm would like to wake the device even if it is idle. This is, for example, an alarm for an alarm clock.
If you want, you can dig into the usage of FLAG_WAKE_FROM_IDLE
-- but that's the difference, as far as I can tell. Your "normal" exact alarms do not wake the device from idle, but the alarm set with setAlarmClock() does.
Doze mode, introduced in Android 6.0 (API level 23), adds further restrictions to those outlined above: (TL;DR: only setAlarmClock
triggers in doze mode, and adds a system icon)
Doze restrictions
The following restrictions apply to your apps while in Doze: [...]
- The system ignores wake locks.
- Standard
AlarmManager
alarms (includingsetExact()
andsetWindow()
) are deferred to the next maintenance window.
- If you need to set alarms that fire while in Doze, use
setAndAllowWhileIdle()
orsetExactAndAllowWhileIdle()
.- Alarms set with
setAlarmClock()
continue to fire normally — the system exits Doze shortly before those alarms fire. [...]
The devices enter the low-power doze-state with periodic wake-ups to perform the other alarms etc.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With