Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Difference between 'setExact' and 'setAlarmClock'

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?

like image 551
Zelig63 Avatar asked Mar 20 '16 06:03

Zelig63


People also ask

How is AlarmManager different from WorkManager?

Alarms only. Unlike WorkManager, AlarmManager wakes a device from Doze mode. It is therefore not efficient in terms of power and resource management.

What is exact alarm API?

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.

What is RTC alarm in android?

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.


2 Answers

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.

like image 102
Snild Dolkow Avatar answered Sep 28 '22 12:09

Snild Dolkow


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 (including setExact() and setWindow()) are deferred to the next maintenance window.
    • If you need to set alarms that fire while in Doze, use setAndAllowWhileIdle() or setExactAndAllowWhileIdle().
    • 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.

like image 44
serv-inc Avatar answered Sep 28 '22 14:09

serv-inc