Eliminate next-alarm-clock broadcast flapping

When multiple alarm clocks are scheduled at the same time, we would
flap among the alternatives for considering them the 'next upcoming
alarm clock', which in turn would generate [many] spurious broadcasts
about changes to the upcoming alarm situation.  This is now fixed;
once we have found the soonest upcoming alarm clock, we stick with
that one until it becomes unavailable, eliminating the spurious
broadcast traffic.

Bug 29501073

Change-Id: Ice1892490bb339e05fa8bd9d324fa1c6718b4942
(cherry picked from commit 76389c00d3)
This commit is contained in:
Christopher Tate
2016-08-03 14:57:47 -07:00
committed by Chris Tate
parent c5a17fc39f
commit c60da1edc1

View File

@@ -1732,9 +1732,10 @@ class AlarmManagerService extends SystemService {
Alarm a = alarms.get(j);
if (a.alarmClock != null) {
final int userId = UserHandle.getUserId(a.uid);
AlarmManager.AlarmClockInfo current = mNextAlarmClockForUser.get(userId);
if (DEBUG_ALARM_CLOCK) {
Log.v(TAG, "Found AlarmClockInfo at " +
Log.v(TAG, "Found AlarmClockInfo " + a.alarmClock + " at " +
formatNextAlarm(getContext(), a.alarmClock, userId) +
" for user " + userId);
}
@@ -1742,6 +1743,10 @@ class AlarmManagerService extends SystemService {
// Alarms and batches are sorted by time, no need to compare times here.
if (nextForUser.get(userId) == null) {
nextForUser.put(userId, a.alarmClock);
} else if (a.alarmClock.equals(current)
&& current.getTriggerTime() <= nextForUser.get(userId).getTriggerTime()) {
// same/earlier time and it's the one we cited before, so stick with it
nextForUser.put(userId, current);
}
}
}