A flowchart for background work, alarms, and your Android app
Pro-tip by +Ian Lake
For many apps, doing work in the background can be an important part of building a great experience.
An alarm registered with AlarmManager (http://goo.gl/FtpShV) is one way to schedule your app to be run sometime in the future, even if your app isn’t in the foreground. What alarm type and API should you use for your app or are alarms even the best option? Let’s go through some of the factors that should influence your opinion:
How often do you want to trigger?
For events less than 60 seconds apart, alarms aren’t the best choice: use the much more efficient Handler (http://goo.gl/CE9vAw) for frequent work.
Want to set a user visible alarm clock?
On API 21+ devices, new APIs allow you to set a user visible alarm via setAlarmClock(): the system UI may display the time/an icon and apps can retrieve the next alarm clock with getNextAlarmClock(). Note that alarms set with setAlarmClock() work even when the device/app is idle (similar to setExactAndAllowWhileIdle()): getting you as close to an exact wake up call as possible. For backward compatibility, you’ll follow the same guide below for a single alarm.
Wake up the device/app while idle (i.e., doze, app standby)?
On Android 6.0+ (API 23) devices, additional power-savings optimizations (http://goo.gl/dVtgz6) have been added in the form of Doze (triggered by a completely stationary, unplugged, and idle device) and App Standby (triggered by an unplugged device on idle apps that haven’t been used recently). You’ll use setAndAllowWhileIdle() for inexact and setExactAndAllowWhileIdle() for exact alarms if you need it to fire an alarm while in these idle states. If it can wait until the user returns to their device/your app, use the standard set() and setExact() to be the best Android citizen and save your user’s battery.
(We’ll be talking more specifically about Doze and App Standby later!)
Just a single alarm?
A single alarm can be set with the aptly named set() method. One thing to keep in mind is that on API 19+ devices when you target API 19+, the system will be treated as inexact, potentially batching alarms together – the alarm will never go off before the time specified, but may go off afterwards. If you have some flexibility in the start time but have a hard deadline, consider using setWindow() to gain more control over the exact time period to be used.
You can use setExact() for a precisely timed single alarms on API 19+ devices, but use these only when the exact timing is required (such as with a calendar reminder).
Need to repeat at a constant rate?
For repeating alarms, batching is the key to good battery life. setInexactRepeating() does exactly that. Prior to API 19, you can use one of the INTERVAL_ constants (such as INTERVAL_HOUR to batch alarms of the same interval. On API 19+ devices, all repeating alarms (no matter what the interval) set with setInexactRepeating() will be batched.
You’ll note there’s also setRepeating() – similar to set() the behavior changes with API 19 from exact to inexact repeating alarms, meaning if you are on an API 19+ device and target API 19+, this functions identically to setInexactRepeating(). If you really need exact repeating alarms on API 19+, set an exact alarm with setExact() and schedule the next alarm once your alarm has triggered – keep in mind the battery implications though!
BUT WAIT: should you even use alarms?
If you want to be as battery efficient as possible (and you should!), consider using JobScheduler (https://goo.gl/CQjbsp) on API 21+ devices or GcmNetworkManager (https://goo.gl/CGNi3p) on all Google Play services enabled devices of API 9+.
Supporting both one off and periodic work, these APIs lack the ability to wake from idle, but gain the ability to wait for network access, wait until the battery is charging, take advantage of automatic backoff and retry, persist across reboots, and batch jobs across the system (meaning lower battery usage!).
That’s a lot of good reasons to use JobScheduler and GcmNetworkManager so consider them strongly in your push to #BuildBetterApps