tree 7ca15b9a69b6df287d0cc96b1d1da7f51b347c95
parent 2d3c59c389bbd74b4efb02b9021e34e970ba4603
author Christopher Tate <ctate@google.com> 1443720271 -0700
committer Christopher Tate <ctate@google.com> 1446232455 -0700

Introduce direct listener API for alarm delivery

The Alarm Manager now supports a set() variant that takes a listener
callback to invoke at alarm trigger time rather than a PendingIntent.
This is much lower overhead and has guaranteed low delivery latency
from the trigger time.  The tradeoff is that the app must be running
*continuously* from the time the alarm is set to the time it is
delivered.  If the app exits for any reason before the alarm fires,
the listener becomes invalid and the alarm will be dropped.  This is
more or less equivalent to setting an alarm with a broadcast
PendingIntent that matches only a runtime-registered receiver.

The app's alarm listener can be any object that implements the new
AlarmManager.OnAlarmListener interface and implements its onAlarm()
method.  There is no data delivered at alarm trigger time: whatever
state needs to be associated with the specific alarm instance should
simply be packaged inside the OnAlarmListener instance.

An alarm using OnAlarmListener can request that the onAlarm() method
be called on an arbitrary handler.  If the program passes 'null' for
this parameter when setting the alarm, the callback occurs on the
application's main Looper thread.

Bug 20157436

Change-Id: I2eb030a24efdd466a2eee1666c5231201b43684b