4aa47e58c4
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