tree 6a79d172b6d22dbf3c897eec2a4bc69609df6bdf
parent 13a6158d6e516b9ea4ecf159a131332bcee42c86
author Christopher Tate <ctate@google.com> 1443720271 -0700
committer Randy Pan <zpan@google.com> 1449792410 -0800

DO NOT MERGE 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.

Cherry-picked from 14a7bb0d370fffdf902a4e2345f46754ed2d7684
Bug 20157436

Change-Id: I2eb030a24efdd466a2eee1666c5231201b43684b