Scheduling Alarms

Alexander Nelson

September 23, 2019

University of Arkansas - Department of Computer Science and Computer Engineering

Reminders

Projects

Project 2 is out!

Due Friday October 6th Final Project Report 2 due Friday

Create a (temporary) App Name

Make your title be “AppName: Longer Description of Application”

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