Scheduling Alarms
Alexander Nelson
September 27, 2021
University of Arkansas - Department of Computer Science and Computer Engineering
AlarmManager
Alarms
An alarm is used to wake the Android System and perform some
kind of operation
Operation is handled through the Alarm Manager
https://developer.android.com/reference/android/app/AlarmManager.html
These slides 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.
Alarms enable Active Behavior
Active Behavior
Passive transactions are initiated by the user
while
Active transactions are initiated by the system
Active Transactions
Active transactions can be defined by these properties:
1. Transaction initiated by system, user is given an opportunity
to respond
2. Require timely response from user
3. Interactions are sequential and serial
4. Between system and a single user
Example: Some 2-Factor authentication schemes
Alarm Operation
Alarms are scheduled for a future time, and are specified with an
Intent
When an alarm fires, the Intent is broadcast by the system
The Intent is created as a PendingIntent
• Grants the AlarmManager to run the Intent as if it was within
the Application itself
Intended for longer time requirements that operate outside the
lifetime of the application
Alarm Operation
When the Intent is broadcast by the system, the application is
automatically started if not already running
Registered alarms are retained until the device is restarted
Alarm Operation
The AlarmManager will hold a CPU wake lock while
AlarmReceiver’s onReceive() method is running
• Prevents the phone from sleeping until Broadcast is handled
• Releases wake lock after return
If the onReceive method tries to launch a service, the CPU may
sleep before the service Intent is handled
Using the Alarm Manager Class
Instances of the AlarmManager may be obtained by
• Context.getSystemService(AlarmManager.class) or
• Context.getSystemService(“Context.ALARM SERVICE”)
Alarm Manager Specifics
After API 19 (KitKat), alarm delivery is inexact
• Attempt to batch alarms to save battery
New APIs to support this functionality
setWindow() – Choose a window in which a wake-up call is
allowable
setExact() – Choose the specific time in which a wake up call will
occur
Best Practices
• Add randomness (jitter) to any network requests as a result ofrepeating alarms
• Do local work when alarm triggers
• Schedule the alarm that contains network requests to fire at a
random point in time
• Keep alarm frequency to a minimum
• Don’t wake device unnecessarily
• Don’t make alarms trigger time more precise than needed
• Avoid basing alarm on clock time if possible
• Doesn’t scale well (Can DDOS your own server)
• Exponential Backoff – When job fails, increase interval
between retries exponentially
AlarmManager Functions
• set() – Older functionality, now Android chooses when to fire
• setAlarmClock() – Same, but implies Wake-Up and system
may show info to the user
• setWindow() – Inexact alarm, but with constraints about
wake-ups
• setExact() – Set exact alarm
• setRepeating() – Create exact repeating alarm (no longer
exact after API 19)
• setInexactRepeating() – Create inexact repeating alarm
• ...AndAllowWhileIdle() – Can be appended to several of these,
and allows wake-up during low-power modes
Examples
Example to create inexact repeating alarm to fire every 30 minutes
Will fire alarmIntent
Examples
Set inexact alarm (using old API call) for a one-time alarm to be
fired in 60 seconds
Real-Time Clock Example
Wake at approximately 2:00 PM, and once a day thereafter
Real-Time Clock Example
Wake at 8:30 AM, and every 20 minutes thereafter
Cancel an Alarm
There are some instances where you may wish to cancel an alarm
cancel() – Function within the AlarmManager class
Call on the instance of your AlarmManager, and pass the
pendingIntent to be cancelled
Starting Alarm on Device Boot
By default, all alarms are cancelled when the device shuts down
You can design your application to automatically restart an Alarm
when the device is rebooted
To do so, you must:
1. Set RECEIVE BOOT COMPLETED permission in manifest
2. Implement a BroadcastReceiver to handle boot broadcast
3. Add receiver into the application manifest file
Set Permissions
Set the permission in the manifest file
Register BroadcastReceiver
Register the BroadcastReceiver to handle the boot broadcast
Add Receiver to the application manifest
Create the Broadcast Receiver in the application manifest
<android:enabled=“false”>– Receiver will not be called unless
application explicitly enables it
Enable/Disable the BroadcastReciever
Enable the receiver programmatically, persists after reboots
Can disable by changing:
COMPONENT ENABLED STATE ENABLED to
COMPONENT ENABLED STATE DISABLED
Additional Resources
Android Framework JobScheduler
JobScheduler became available in API 21 (Lollipop)
Implemented in the platform, therefore can collect information
about all jobs needed run
Makes batching jobs easier
Recommended over AlarmManager for APIs 21 and above
Additional Resources
Firebase JobDispatcher
Open-source library that provides a similar interface to
JobScheduler
Provides compatibility for JobScheduler for apps targeting lower
than API 21
Additional Resources
Sync Adapter – Designed specifically to sync data between device
and server
Android N and above – Implemented on top of JobScheduler
Services – You can always perform tasks running in the background