| afa8b980acddd7667cdcc242c77a925664929051 |
|
11-Aug-2016 |
Christopher Tate <ctate@google.com> |
Base date-change alarm on 24h "hour zero," not 12h
Bug 30628519
Change-Id: Ie504748c7fc2d43c713ddc72c39c56a976cc0df0
/frameworks/base/services/core/java/com/android/server/AlarmManagerService.java
|
| cf02471cde404992f63f2571f34b9478f4ecd407 |
|
05-Aug-2016 |
Christopher Tate <ctate@google.com> |
Reschedule date-change alarm whenever the time is set
Bug 30628519
Change-Id: Ic4180b9f3c822f3dfb7e35199f3d058938acf778
/frameworks/base/services/core/java/com/android/server/AlarmManagerService.java
|
| 76389c00d3d3ce79e48d9e87b597707ed3e8970c |
|
03-Aug-2016 |
Christopher Tate <ctate@google.com> |
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
/frameworks/base/services/core/java/com/android/server/AlarmManagerService.java
|
| 7b5b7cb63be71c9e7250dfece6401837f99ef4d7 |
|
07-Jul-2016 |
Christopher Tate <ctate@google.com> |
Don't walk mutexed collections outside the mutex
In particular, don't call rescheduleKernelAlarmsLocked() without
the lock held, or Bad Things will happen.
Bug 29931253
Change-Id: I93a7f16d543b5af2adff27f949a68f3d54169285
/frameworks/base/services/core/java/com/android/server/AlarmManagerService.java
|
| e555cb9f4afdd7a8e7c55379a13e8be696cca3e2 |
|
18-Jun-2016 |
Christopher Tate <ctate@google.com> |
Unspecified alarm worksource names are the rule, not the exception
Bug 29443799
Change-Id: I6457a3680a26c900ed9c8e2ac2ab3f5fc4dfc007
/frameworks/base/services/core/java/com/android/server/AlarmManagerService.java
|
| 0029f57123688fc3599dda5c5a583ce528770d07 |
|
14-Jun-2016 |
Christopher Tate <ctate@google.com> |
Note null alarm worksource names under the alarm's package
And log a nastygram because it implies the app is misbehaving.
Bug 29333122
Change-Id: Ia683304b8a9eafb234df81e874ee3f0636c4e56a
/frameworks/base/services/core/java/com/android/server/AlarmManagerService.java
|
| aa9a59d410eea64e3bb86b2f9bf1f03206a3e1f0 |
|
24-May-2016 |
Dianne Hackborn <hackbod@google.com> |
Work on issue #27995384: Time in the top bar different...
...from time in the clock app
Always reset the kernel's next wake up time when we come
out of it, even if it didn't say an alarm went off.
Also add some more debugging to try to figure out what is
going on.
Change-Id: Ibf36d65b78c841128774d81517a7eb670c396c29
/frameworks/base/services/core/java/com/android/server/AlarmManagerService.java
|
| 78bcdf91edb18c8775d736f8819085d9febc01b2 |
|
09-May-2016 |
Joe Onorato <joeo@google.com> |
Properly blame the correct uid for wakeup alarms that don't have a WorkSource.
It was setting the uid to -1, but BatteryStats should be tracking the actual uid.
Bug: 28637246
Change-Id: If6577602e3fe59a95b5cece4fc99e704ba43c03e
/frameworks/base/services/core/java/com/android/server/AlarmManagerService.java
|
| 2fefbcf0d1b91f37684387971721c90112a9ac89 |
|
18-Mar-2016 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #27653326: Sync doesn't work in doze maintenance
Add a (configurable) delay between when we start a maintenance
window until the minimum time we will end it.
Also switch to using the alarm manager callback API. (Yay!)
Also fix a little printing problem in the alarm manager dump
so we put the package name and not some class hash in the
summary string of an alarm entry.
Change-Id: I4281e5c80bc8b26ebc1fb6f603ec33ec0e379daa
/frameworks/base/services/core/java/com/android/server/AlarmManagerService.java
|
| 262ae5c8eb1579bccaa0f6953b39e6fd65ff2288 |
|
11-Feb-2016 |
Dianne Hackborn <hackbod@google.com> |
DO NOT MERGE: Add separate information about user whitelist.
Use this in the alarm manager to allow user whitelisted apps
to have free access to scheduling alarms.
Coming next: lifting sync/job restrictions.
Bug #26851107: Allow user whitelist apps more freedom
(Cherry-picked to nyc since it got lost in the branch from master.)
Change-Id: I4dc9f07514627ebdb6b6eff7c7a749f2c51a3797
/frameworks/base/services/core/java/com/android/server/AlarmManagerService.java
|
| 24cd46f392baacec17adc90b4e30918e096bdfcf |
|
02-Feb-2016 |
Christopher Tate <ctate@google.com> |
Send ALARM_CLOCK_CHANGED broadcast with REPLACE_PENDING
Spammy behavior, including app bugs, has been seen in the field to induce
situations where there were thousands of duplicate ALARM_CLOCK_CHANGED
broadcasts in the queue awaiting delivery. They're relatively inexpensive
to deliver but not free, and this has considerable impact on both the
system's ability to issue broadcasts and the ability of this broadcast's
subscribed receivers to do other work besides processing them.
Bug 26910849
Change-Id: Ic91f25514a26d41a1b1b4cb44489d1575fe1867c
/frameworks/base/services/core/java/com/android/server/AlarmManagerService.java
|
| ff6390cda43a0333a93c6b87a8eac5484e5ba8e9 |
|
10-Dec-2015 |
Christopher Tate <ctate@google.com> |
Allow direct-callback alarms for non-wakeup alarms
Turns out there are known use cases for it, in particular to avoid
interfering with doze/idle type optimizations. In addition, it is
not reliably possible to aim for a specific *wall-clock* trigger time
when posting work to a Handler, since the time base used there is
uptime rather than elapsed.
Bug 26114467
Change-Id: I7cede733fc7e09704b63dfe3e98b00365bbdff35
/frameworks/base/services/core/java/com/android/server/AlarmManagerService.java
|
| 7f2a035242fb8a118e8bcbf57db4f29697ed98bf |
|
08-Dec-2015 |
Christopher Tate <ctate@google.com> |
Don't leak alarm wakelock when delivery fails
If an app sets an alarm and then cancels the underlying PendingIntent,
delivery will fail in such a way that the OnFinished callback is not
invoked. The Alarm Manager relies on that callback for managing
wakelock lifetime, however; this meant that the wakelock acquisition
would leak, burning down the battery.
We now detect these sorts of delivery failures and manage the
wakelock appropriately.
Bug 25864361
Change-Id: I74af48e81002b29b129c41a76c0a8329c647390d
/frameworks/base/services/core/java/com/android/server/AlarmManagerService.java
|
| 1a3c1650ccc0b15668f44b2911f5daf93573c0e0 |
|
24-Nov-2015 |
Lorenzo Colitti <lorenzo@google.com> |
Merge "Don't crash when canceling alarms if a direct listener is present"
|
| 9b43ce0c98ce9f865d6db547529d098c8982ccc2 |
|
22-Nov-2015 |
Lorenzo Colitti <lorenzo@google.com> |
Don't crash when canceling alarms if a direct listener is present
If a direct listener alarm attempts to match a regular
PendingIntent alarm, it will attempt to fetch the binder of the
regular alarm's direct listener, which is null, and crash the
system with an NPE.
Bug: 25823676
Change-Id: I85fb98b43436930a2513274dc5ab408f7d41d97f
/frameworks/base/services/core/java/com/android/server/AlarmManagerService.java
|
| de9c48b3d1db099b58f9366029362a95ed2d50da |
|
20-Nov-2015 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #25779155: Random crash in the system server
Change-Id: I7c6ef4dcb9b88ca2d9b54010b2007b6bf88f9958
/frameworks/base/services/core/java/com/android/server/AlarmManagerService.java
|
| bef28feba57be7fd6a4d14a85a8229154338b2ed |
|
30-Oct-2015 |
Dianne Hackborn <hackbod@google.com> |
Initial stab at background check.
Actually, this implementation is more what we want for ephemeral
apps. I am realizing the two are not really the same thing. :(
For this implementation, we now keep track of how long a uid has
been in the background, and after a certain amount of time
(currently 1 minute) we mark it as "idle". Any packages associated
with that uid are then no longer allowed to run in the background.
This means, until the app next goes in the foreground:
- No manifest broadcast receivers in the app will execute.
- No services can be started (binding services is still okay,
as this is outside dependencies on the app that should still
be represented).
- All alarms for the app are cancelled and no more can be set.
- All jobs for the app are cancelled and no more can be scheduled.
- All syncs for the app are cancelled and no more can be requested.
Change-Id: If53714ca4beed35faf2e89f916ce9eaaabd9290d
/frameworks/base/services/core/java/com/android/server/AlarmManagerService.java
|
| 627dfa1ddafc96b912ae938677a48a16f7ab255c |
|
12-Nov-2015 |
Dianne Hackborn <hackbod@google.com> |
Be smarter about determining when we can stop idle maintenance.
The device idle service now knows when the system is actively
doing significant things (syncs, jobs, alarms, downloads). It
uses this, when in an idle maintenance window, to determine when
it can end that window early -- when such work is no longer
happening.
For now this just allows us to shorten the windows. In the future
we should use this to allow us to expand the windows to a longer
potential time, adjusting future windows to shorter durations if
earlier ones use more time. This will allow us to batch occasional
long operations (such as downloads) into one window, making up
for that with much shorter later windows.
Change-Id: Ie482abd50bc43be9a8917a769a5175851eee4ec4
/frameworks/base/services/core/java/com/android/server/AlarmManagerService.java
|
| 14a7bb0d370fffdf902a4e2345f46754ed2d7684 |
|
01-Oct-2015 |
Christopher Tate <ctate@google.com> |
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
/frameworks/base/services/core/java/com/android/server/AlarmManagerService.java
|
| 4c9564567b016e44d8ae2fe638df5e72391b843c |
|
28-Oct-2015 |
Dianne Hackborn <hackbod@google.com> |
Merge "Add some debugging for device idle alarms."
|
| 24f2cca6ed3582326fd52df18ff28a8f85394377 |
|
27-Oct-2015 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #25289999: Lower device idle alarm limit to 10 mins. am: 7682b26ea1 am: 26654c92ca
am: 40bced1d6e
* commit '40bced1d6ed2dadbd1fff116dad382582c430297':
Fix issue #25289999: Lower device idle alarm limit to 10 mins.
|
| 7682b26ea164ba1078495e24910f22d73766c192 |
|
27-Oct-2015 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #25289999: Lower device idle alarm limit to 10 mins.
This helps with some cases where perisistent network connections
need a more frequent keep alive signal. Actually make it 9
minutes to ensure that things needing a 10 minute cycle will
execute within that time.
Change-Id: Ife8c7b7f7f82b108d5a6c1624bd6115e6087c3be
/frameworks/base/services/core/java/com/android/server/AlarmManagerService.java
|
| ae78bf8552d0a3ff83b8300630d47188434173ea |
|
26-Oct-2015 |
Dianne Hackborn <hackbod@google.com> |
Add some debugging for device idle alarms.
Change-Id: I6792f0ffc5cc40af5ec35cb03ab78b52c17678fd
/frameworks/base/services/core/java/com/android/server/AlarmManagerService.java
|
| 700d1fbd0ee0e65a3bf6587f6dd0e7d9a4e114a2 |
|
16-Oct-2015 |
Dianne Hackborn <hackbod@google.com> |
am 401f68b9: am 510f03c5: am 56f41971: Merge "Fix issue #24571425: Device does not come out of idle mode for maintenance" into mnc-dr-dev
* commit '401f68b93aa9eca88d8dd126b92128bdc3371064':
Fix issue #24571425: Device does not come out of idle mode for maintenance
|
| f383129b0914809e9a1a011f48c945f97ccce333 |
|
15-Oct-2015 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #24571425: Device does not come out of idle mode for maintenance
Don't allow alarms to push the idle maintenance alarm later
than it was set for.
Change-Id: I947718ffc9d2b984a793d7e4f2d027d8ddeee41b
/frameworks/base/services/core/java/com/android/server/AlarmManagerService.java
|
| 937b0978be5cda5ab4e12bc277dad42cde0e27b6 |
|
31-Aug-2015 |
Bart Sears <bsears@google.com> |
am aaebdd7f: am 02be9316: am 06fb3b2d: am 0e2e8589: Merge "Don\'t throttle "while idle" alarms while not dozing" into mnc-dev
* commit 'aaebdd7f91163382065d3b56d57cafef5e46c7fd':
Don't throttle "while idle" alarms while not dozing
|
| aa244dafede47dcdaf0084b96e7410dde64c41cb |
|
28-Aug-2015 |
Christopher Tate <ctate@google.com> |
Don't throttle "while idle" alarms while not dozing
Specifically, reduce the non-doze "while idle" minimum interval to
be the same as the generally-enforced minimum futurity of new alarms.
Bug 21602742
Change-Id: I044deaedc2daeff5d6f418f0fe091fea85f73fcf
/frameworks/base/services/core/java/com/android/server/AlarmManagerService.java
|
| 6f612a619de8331210bae6c1c9249c8a26c8af94 |
|
27-Jun-2015 |
Prashant Malani <pmalani@google.com> |
am 2e268478: am b29eeb5a: am b3d02465: am 9a3eacbe: Merge "Revert "Always re-establish kernel alarms when considering new alarm set"" into cw-d-mr1-dev
* commit '2e26847865bc388531e6cf6e9fc0acfd56e112d2':
Revert "Always re-establish kernel alarms when considering new alarm set"
|
| b29eeb5af148097bf55c22a4ce3b040ad2ecc792 |
|
27-Jun-2015 |
Prashant Malani <pmalani@google.com> |
am b3d02465: am 9a3eacbe: Merge "Revert "Always re-establish kernel alarms when considering new alarm set"" into cw-d-mr1-dev
* commit 'b3d02465f859dbe62b14c787c7de966abd6c7381':
Revert "Always re-establish kernel alarms when considering new alarm set"
|
| b3d02465f859dbe62b14c787c7de966abd6c7381 |
|
26-Jun-2015 |
Prashant Malani <pmalani@google.com> |
am 9a3eacbe: Merge "Revert "Always re-establish kernel alarms when considering new alarm set"" into cw-d-mr1-dev
* commit '9a3eacbe9ce0e6a65429c721b6f4e60a28dbdaab':
Revert "Always re-establish kernel alarms when considering new alarm set"
|
| 753e9e0f2d0c6c15eeb3e4905d67bfb4f12e0f87 |
|
11-Jun-2015 |
Prashant Malani <pmalani@google.com> |
Revert "Always re-establish kernel alarms when considering new alarm set"
This reverts commit c83d3e4b72f8f25bbac39a577f125f0ca04354da.
While the above patch does help deal with the issue of "lost" kernel
alarms, experiments found it to also cause the unnecessary duplicate
setting of non-lost alarms in other devices.
This leads to a situation where the CPU constantly tries to sleep, but
occasionally keeps failing to do so, because of a collection of these
duplicate alarms constantly activating the "alarm" kernel wakeup source
, presumably due to them being triggered.
These might have accumulated over several iterations when the kernel
alarms were set again (via rescheduleKernelAlarmsLocked()).
To prevent the CPU thrashing (which heavily drains power on more
battery-constrained devices, and increases the number of alarms being
set), the aforementioned commit is backed out.
Change-Id: I2a189cb303deb78a2faf476b0e789445407f3e11
(cherry picked from commit d19ffd4f2ca4130c41dd5f6baddad1830598ecbc)
/frameworks/base/services/core/java/com/android/server/AlarmManagerService.java
|
| 2133afc77aa36f186b9e5c0ff9954d0d26848e3e |
|
18-Jun-2015 |
Dianne Hackborn <hackbod@google.com> |
am d21b695f: am 22433a33: Merge "Fix issue #21814207 and issue #21814212 (alarm manager)" into mnc-dev
* commit 'd21b695f8b344b12e623694db86856a89642d934':
Fix issue #21814207 and issue #21814212 (alarm manager)
|
| a750a63d639f6936af456df904fa6b9ba941885e |
|
17-Jun-2015 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #21814207 and issue #21814212 (alarm manager)
Issue #21814207: AlarmManager.setAndAllowWhileIdle should also allow wake locks.
Introduce a whole new infrastructure for providing options when
sending broadcasts, much like ActivityOptions. There is a single
option right now, asking the activity manager to apply a tempory
whitelist to each receiver of the broadcast.
Issue #21814212: Need to allow configuration of alarm manager parameters
The various alarm manager timing configurations are not modifiable
through settings, much like DeviceIdleController. Also did a few
tweaks in the existing DeviceIdleController impl.
Change-Id: Ifd01013185acc4de668617b1e46e78e30ebed041
/frameworks/base/services/core/java/com/android/server/AlarmManagerService.java
|
| 52047ab160629275f77d9dba6d69eb223986bdda |
|
13-Jun-2015 |
Chris Tate <ctate@android.com> |
am 386a5a29: am 396b83b0: Merge "Fix overflow/underflow problem in comparison"
* commit '386a5a2940acd346f1d9e81c87dfa87e7d146065':
Fix overflow/underflow problem in comparison
|
| 3d1933c45fe9ba2389ebd166d96abeceab1971d1 |
|
11-Jun-2015 |
Dianne Hackborn <hackbod@google.com> |
Implement some control over ALLOW_WHILE_IDLE alarms.
Since these alarms allow you to bypass the idle restrictions,
we don't want them to be so open-ended like other alarms. This
implements a policy where the alarm manager will only deliver these
types of alarms every X minutes to each application. For this
initial implementation, X is 1 minute under normal operation and
15 minutes when in idle mode.
To do this, I needed to introduce a new internal allow-while-idle
flag for system alarms, which applications can't get, and doesn't
have these new restrictions.
Also tweaked how the alarm manager handles the alarm window, so it
doesn't change if the alarm gets rescheduld; the window is now always
what as computed based on the time when the alarm was first
given to it.
Finally, fix TimeUtils to be able to correctly print times that
are > 999 days.
Change-Id: Ibad8c6a7c14b0624b54e82267be23224b4c31e84
/frameworks/base/services/core/java/com/android/server/AlarmManagerService.java
|
| cdaaeeec0dadbe38ed069da0eb4b1532cd620f3f |
|
20-May-2015 |
Charles Tsai <charles_tsai@htc.com> |
Fix overflow/underflow problem in comparison
Here's overflow/underflow problem in comparators.
"when1 - when2" may suffer in overflow/underflow condition.
Comparing them directly can avoid this problem.
Change-Id: Id46af3db2adac90654210182d26ade1986ee0661
/frameworks/base/services/core/java/com/android/server/AlarmManagerService.java
|
| 88fb14532421f049614c34120c706c26a9af6bbd |
|
01-Jun-2015 |
Chris Tate <ctate@android.com> |
Merge "DO NOT MERGE Fix bug regarding the comparator sorts Alarms into increasing time order." into mnc-dev
|
| 604a5eeed7ffd5b4bd790980a1b3144015d1ea1c |
|
01-Jun-2015 |
John Spurlock <jspurlock@google.com> |
Next alarm clock updates.
- Add explicit user setup signal to status bar icon policy.
- Include per-user next alarm clock info in service dump.
Bug: 21551365
Change-Id: Ib16636522bbe04d205a377567007145f146e9d39
/frameworks/base/services/core/java/com/android/server/AlarmManagerService.java
|
| 1acd32a60b9ec67878302f6d629c5d5e7e2ee813 |
|
27-May-2015 |
jinho.park <jinho.park@lge.com> |
DO NOT MERGE Fix bug regarding the comparator sorts Alarms into increasing time order.
The comparator used variable "when" in IncreasingTimeOrder class.
variable "when" means "elapsed time" or "real time"(RTC) and these types have different unit of time.
so, I recommend that you use a "whenElapsed" which has the equal unit of time as its default value.
Signed-off-by: Jinho Park <jinho.park@lge.com>
Cherry-pick from master
Change-Id: Ib95531bf235e8fc628a7eda1c24d187c12a9ab3b
/frameworks/base/services/core/java/com/android/server/AlarmManagerService.java
|
| df7f900cf44bc1759c353ab9696fbf6894a69d1d |
|
27-May-2015 |
jinho.park <jinho.park@lge.com> |
Fix bug regarding the comparator sorts Alarms into increasing time order.
The comparator used variable "when" in IncreasingTimeOrder class.
variable "when" means "elapsed time" or "real time"(RTC) and these types have different unit of time.
so, I recommend that you use a "whenElapsed" which has the equal unit of time as its default value.
Change-Id: I248863ef8a5c49cc7114cb2965f3d6b78f4faa59
Signed-off-by: Jinho Park <jinho.park@lge.com>
/frameworks/base/services/core/java/com/android/server/AlarmManagerService.java
|
| c352722e8af0a5510144b5f32ea87561db553f42 |
|
13-May-2015 |
Dianne Hackborn <hackbod@google.com> |
Ignore small time changes in alarm manager.
It turns out switching to the new kernel alarm
reporting causes lots and lots of spurious flags
that the clock has changed. The alarm manager
would blindly trust these, thinking the world has
changed on it and recomputing everything and reporting
this to everyone else. This was expensive.
We now verify that the time has changed sufficiently
that it is worth caring about. This is basically the
same algorithm that battery stats was using to avoid
recording small clock changes, so we are really just
pushing this down into the alarm manager and can now
remove that from battery stats.
Also since we are getting these so much, make use of
the other information in about the wakeup that tells us
if an alarm went off to avoid doing anything if it didn't.
Change-Id: I6f4f4226db6eb2b38ca73860786e7cf7c9136cc3
/frameworks/base/services/core/java/com/android/server/AlarmManagerService.java
|
| 0b4daca9ba54b7252ea8c159218391380eb00c8a |
|
27-Apr-2015 |
Dianne Hackborn <hackbod@google.com> |
Implement user-settable power save whitelist.
The whitelist is now maintained by DeviceIdleController,
which is moving out into its own independent system service.
Network stats now queries it for the whitelist, instead of
collecting that itself.
Also did a few improvements in alarm manager -- made the
code for moving alarms out of the pending list more robust,
and fixed the debug output to always print the contents of
the pending list even if we aren't in a pending state. (That
would have helped me identify the problem much earlier.)
Change-Id: I0f7119d4c553c3af4d77b2f71246fa6e2c13c561
/frameworks/base/services/core/java/com/android/server/AlarmManagerService.java
|
| 35d54037758a2bbf14da8d54a85394a02d1dc8d8 |
|
23-Apr-2015 |
Dianne Hackborn <hackbod@google.com> |
Hopefully fix issue #20297662: Statusbar clock not updating
Make sure that whenever we no longer have a pending-idle-until
alarm, we get all of the pending alarms re-added.
Change-Id: I7e80bc02afff22827d876ef5d4a381ebb62ec8e3
/frameworks/base/services/core/java/com/android/server/AlarmManagerService.java
|
| f70faed503c8482266e6acb94dd5281488a9117e |
|
21-Apr-2015 |
Dianne Hackborn <hackbod@google.com> |
Work on issue #20401752: device idle and alarms.
Main change is to fix problems in the alarm manager where it
was not doing a good job at scheduling the device idle wakeup
before an alarm. To fix this, we now keep explicit track of
the next "wake from idle" alarm so we can consistently use that
to adjust the time of the device idle alarm if needed.
Also a bunch of debugging stuff to help further diagnose this
problem:
- Alarm summary now includes the last time the alarm went off.
- Improved dumpsys output of alarms.
- New event log tags for changes related to idle state.
Change-Id: Idd2c8d24ae23379f7c75815ddbc6835c2a04656c
/frameworks/base/services/core/java/com/android/server/AlarmManagerService.java
|
| 1e38382b542f5cef9957a89692b02c55a3dd351c |
|
10-Apr-2015 |
Dianne Hackborn <hackbod@google.com> |
Fixes to idle alarm scheduling, package importance.
- Add new API to ask the activity manager what the current
importance of a particular package name is (along with a few
new useful importance levels).
- Fix my last alarm manager change to actually execute the
alarms we have now decided should run even while we are idle.
Change-Id: I1f14712b4e390770d53b185c96a1b36f6aadd687
/frameworks/base/services/core/java/com/android/server/AlarmManagerService.java
|
| 4870e9d5eba59fb257a87f97f1adf0b734cf48d3 |
|
09-Apr-2015 |
Dianne Hackborn <hackbod@google.com> |
More work on device idle mode and other power stuff.
Add idle mode support to the alarm manager. Introduce
a new concept of flags associated with alarms to tell
the alarm manager how to treat the alarm -- they allow
everything from the alarm that will bring us out of idle
mode, to alarms that are allowed when idle or should
also bring us out of idle. The standalone boolean is
now also a flag.
(Note there is currently no protection from user space
setting the flags however it wants; I will be working
on that in a follow-up change.)
When in idle mode, the alarm manager pushes all alarms
that shouldn't execute during that time over to a
separate list that is not executed until out of idle.
To help with this, I reworked a bit how Alarm objects
are managed, so that when rebatching or moving between
lists we don't have to allocated new objects but can
just use the same existing instance.
Also tweaked the sync manager to deal with idle mode,
which currently just means doing the same thing as when
low on storage -- turning off sync.
Add new ACTION_CHARGING and ACTION_DISCHARGING broadcasts
that apps can listen for to know when the device is actively
charging and discharging. These are better than the old
POWER_CONNECTED and POWER_DISCONNECTED ones because we only
report charging when we actually see that there is enough
power being provided to charge the battery (and will report
discharging if there is not enough power).
The job controller uses these new actions for scheduling
jobs that want to run while plugged in. Removed the
"stable charging" stuff while doing so, since the new
charging state serves as an even better signal for that.
Introduced two new process states: FOREGROUND_SERVICE and
TOP_SLEEPING. This will allow us to treat foreground services
specially (such as still allowing network access to them for
background music playback) while not mixing them together with
whatever happens to be the top activity while the device is
asleep.
Also some other small cleanup here and there.
Change-Id: I7a9808b578bad6f50deb8e1baf919298512a0d3a
/frameworks/base/services/core/java/com/android/server/AlarmManagerService.java
|
| 4fdac61388bd25a4a5bf6caef5bee0360e48ab51 |
|
06-Feb-2015 |
Dianne Hackborn <hackbod@google.com> |
am 5c2fdc33: Merge "Always re-establish kernel alarms when considering new alarm set" into lmp-mr1-dev
automerge: 29039a2
* commit '29039a2bdbadcc427a966f5e7a6021fd424c4266':
Always re-establish kernel alarms when considering new alarm set
|
| c83d3e4b72f8f25bbac39a577f125f0ca04354da |
|
04-Feb-2015 |
Christopher Tate <ctate@google.com> |
Always re-establish kernel alarms when considering new alarm set
As a backstop against missed alarm delivery / wakeups or clock slew,
make sure to always schedule a kernel alarm for the next alarm events
of interest when we've reexamined the set of deliverable alarms.
Bug 19201933
Change-Id: I3cd37a63dfb0c8258941497d4ba516ed00e2edad
/frameworks/base/services/core/java/com/android/server/AlarmManagerService.java
|
| 7c1f995b7bf171a1b556dcaa4dc16cf46db853be |
|
16-Dec-2014 |
Christopher Tate <ctate@google.com> |
am 892e65cb: am 0dab4dc0: Fix bad alarm delivery
* commit '892e65cb2ac4b4917b41060300bbaa3414233394':
Fix bad alarm delivery
|
| 0dab4dc03d1daae72bba9d364e15f6055cb339fd |
|
16-Dec-2014 |
Christopher Tate <ctate@google.com> |
Fix bad alarm delivery
The man bent over his hourglass,
A programmer of sorts. The day was green.
They said, "You have a blue hourglass,
You do not fire alarms when they're asked."
The man replied, "Alarms as they're asked
are changed within the blue hourglass."
And they said then, "But fire, you must
Alarms beyond us, yet themselves,
Alarms within the blue hourglass
That trigger exactly when they're asked."
---
Fix the delivery-fuzzing semantics that had been introduced in
81f9882b5aadd6a2289c9f521a06a7af5f35ebf0. That patch turned out
to be incomplete; in particular, alarms scheduled later might require
the validity of an already-scheduled kernel alarm even if they did
not affect the head alarm batch directly, and this was not being
addressed. For now, roll back the fuzzed delivery logic entirely.
(This is not a full revert because that patch also caused exact alarms
to be considered standalone for batching purposes, and we need to
preserve that new policy.)
Bug 18726690
Bug 18765436
This is a 'git revert' of 81f9882b5aadd6a2289c9f521a06a7af5f35ebf0
*except* that this CL preserves the "exact alarms are treated as
standalone" portion of the original patch.
(Cherrypick of 5c3e277fb42bd799287936c5aee0d30fbcc7e65c from its
original branch.)
Change-Id: Ib9c3200f7e6bc6fa0c9928ee9db4cfd87f039353
/frameworks/base/services/core/java/com/android/server/AlarmManagerService.java
|
| 75070f2f18bbbaa8065000684da64359d8545de9 |
|
12-Dec-2014 |
Christopher Tate <ctate@android.com> |
am 125579ca: am 012de64e: Merge "Fix bugs regarding delay the dispatching of non-wakeup alarms"
* commit '125579caa1b4fb2de4242b0af3f4749bac9fa699':
Fix bugs regarding delay the dispatching of non-wakeup alarms
|
| 649acab38956759213309835de39b14d43c1417e |
|
12-Dec-2014 |
minho.choo <minho.choo@lge.com> |
Fix bugs regarding delay the dispatching of non-wakeup alarms
checkAllowNonWakeupDelayLocked() method determines that delay the dispatching of non-wakeup alarms.
(there are no wakeup alarms and the screen is off, it can delay until the future.)
if there is any pending non-wakeup alarms, non-wakeup alarm delivery time is bigger than nowELAPSED.
but, checkAllowNonWakeupDelayLocked() returns false and non-wakeup alarm is not delay until future.
i think it is necessary to reverse the inequality symbol on "mNextNonWakeupDeliveryTime > nowELAPSED"
if it isn't, Could you let me know when we get ¡°stuck in a loop¡± in the comment of checkAllowNonWakeupDelayLocked () method?
Change-Id: I7e972064547f4d0a9b4175dbd4cf735b4837abfd
Signed-off-by: Minho Choo <minho.choo@lge.com>
/frameworks/base/services/core/java/com/android/server/AlarmManagerService.java
|
| 81f9882b5aadd6a2289c9f521a06a7af5f35ebf0 |
|
05-Dec-2014 |
Christopher Tate <ctate@google.com> |
Tune delivery and batching of alarms
* Inexact alarms no longer coalesce with exact alarms. The motivation here
is that exact alarms are far more likely to be wall-clock aligned, and in
general pulling all alarms toward wall-clock alignment is a bad idea.
* Wakeup times are now fuzzed within the target batch's allowed window
rather than being hard pinned at the start of the window.
Bug 18631821
Change-Id: Iefaf34eee3f2a6546abefc27e177ee2fdcff935f
/frameworks/base/services/core/java/com/android/server/AlarmManagerService.java
|
| 864d42eb96a9127b7d2f10ad11e709c24b4b4304 |
|
02-Dec-2014 |
Christopher Tate <ctate@google.com> |
Properly recognize repeating wakeup alarms
The code in place was inappropriately treating all recurring alarms
as non-wakeup for purposes of deferral. Worse, it was overriding the
"this deliverable batch of alarms includes a wakeup alarm" bookkeeping,
so could potentially cause inappropriate deferral of even standalone
wakeup alarms.
Bug 18591317
Change-Id: I2a62ed4badcaeb549c1ac4f086014aa829e45427
/frameworks/base/services/core/java/com/android/server/AlarmManagerService.java
|
| 9c4a707912da2c954b2d3d1311b8a691ded8aa16 |
|
21-Nov-2014 |
Selim Cinek <cinek@google.com> |
Fixed several time related states for secondary users
The 24 hour setting was not respected correctly. Also
fixed a bug where the next alarm would not display itself
in the QS panel.
Bug: 16239208
Change-Id: I89734f783912dead5831db49db53fba04dbf54ee
/frameworks/base/services/core/java/com/android/server/AlarmManagerService.java
|
| 498c6cbd78f42d4f6d2568ead6c2697fcfaa326e |
|
18-Nov-2014 |
Christopher Tate <ctate@google.com> |
Prevent some alarm pathologies
* Sanity-check the recurrence interval. Some buggy apps pass seconds
where the API expects milliseconds, with the result that the device
pins the CPU at 100% trying to deliver alarm broadcasts every 60 ms
or what have you. The minimum recurrence is now 1 minute.
* Sanity-check alarms being scheduled for the immediate future. As
with the above this will catch people trying to schedule alarms
in a spammy way that keeps the device from entering low-power state.
The minimum futurity of a new alarm is now 5 seconds.
Bug 17495168
Change-Id: If8ff7d88da48960532ac21a0ba20094af9912603
/frameworks/base/services/core/java/com/android/server/AlarmManagerService.java
|
| 1590f1ee7b7b7962f08e8cc29b9891b2ad124c9b |
|
03-Oct-2014 |
Christopher Tate <ctate@google.com> |
Fix alarm delivery-order sorting
We also refine the order of delivery within any given package. Now,
we identify which apps have wakeup alarms being delivered in the
current pass, and deliver all of that app's alarms before moving
on to alarm delivery to apps who are only receiving non-wakeup alarms
in the current delivery pass. The TIME_TICK alarm is also hoisted to
the start of the current delivery pass if present.
Bug 17778686
Change-Id: I6306a00fe657787a77d0254c0807ac51e810fdcf
/frameworks/base/services/core/java/com/android/server/AlarmManagerService.java
|
| 2ff5a73c3c39d144ef4195928000d5666d04c947 |
|
18-Sep-2014 |
Christopher Tate <ctate@google.com> |
Log alarm delivery only when localLOGV
Logspam is spam.
Change-Id: I3bb63f3026fc6222eb8e1496b3a5db4cdf3c7f57
/frameworks/base/services/core/java/com/android/server/AlarmManagerService.java
|
| aeb88ed612d44576f53dbdfb89dfe74793a2d8dc |
|
12-Sep-2014 |
Dianne Hackborn <hackbod@google.com> |
Merge "Work on issue #17477510: Time change notifications sent too often" into lmp-dev
|
| 998e608ddde20be32b79466963a285009525b3d2 |
|
12-Sep-2014 |
Dianne Hackborn <hackbod@google.com> |
Work on issue #17477510: Time change notifications sent too often
Record the number of time change events seen by the alarm manager.
Change-Id: I154e7e068626c71f76ee7b26f3e38a885025e0fa
/frameworks/base/services/core/java/com/android/server/AlarmManagerService.java
|
| 91b3566bec73fc7f66c9ea8415392ae8f5a24236 |
|
27-Aug-2014 |
Xin Guan <a18772@motorola.com> |
Temp enable the log to identify the wake up cause.
Bug: 17276890
Change-Id: I1c2b95807026539d8e5f1e8695019626468c00c1
/frameworks/base/services/core/java/com/android/server/AlarmManagerService.java
|
| 235510e67210f90de30c2d5582a2077ccc589619 |
|
13-Aug-2014 |
Jose Lima <joselima@google.com> |
Made AlarmClockInfo a nested class in AlarmManager
Bug: 16959028
Change-Id: I150eaaff765d1e214c3621c1bf50162ec0dac8ec
/frameworks/base/services/core/java/com/android/server/AlarmManagerService.java
|
| c42a1e1071937ae48b7aa5d6291a32c29078b74b |
|
07-Jul-2014 |
Adrian Roos <roosa@google.com> |
Add AlarmClock API to AlarmManager
Adds a new kind of alarm that represents an alarm clock and
a way to query the next scheduled alarm clock.
Deprecates Settings.System.NEXT_ALARM_FORMATTED.
Bug: 14589952
Change-Id: I297eeeff36d07adcda010afac183d0f5ee37dc99
/frameworks/base/services/core/java/com/android/server/AlarmManagerService.java
|
| d4e6d467cd61d6bec1ae25744a415a96f0a0f760 |
|
17-May-2014 |
Dianne Hackborn <hackbod@google.com> |
Delay the dispatching of non-wakeup alarms.
When the screen is off, there are no guarantees about when
non-wakeup alarms will be dispatched. Historically they are
dispatched any time the device wakes up. With this change,
we will delay the dispatch until sometime later.
The amount of delay is determined by how long the screen has
been off. Currently there are three possible delays: up to
2 minutes if the screen has been off for less than 5 minutes;
up to 15 minutes if it has been off for less than 30 minutes;
and otherwise up to an hour.
When the screen is turned on or a wakeup alarm is dispatched,
all delayed alarms will also be dispatched.
Note that one of the things this delays is TIME_TICK, which
means the in many cases we won't deliver TIME_TICK until the
screen is in the process of waking up. The current
implementation causes this to be delayed until the SCREEN_ON
broadcast is sent; we probably want to improve this to have
the power manager tell the alarm manager about the screen
turning on before it sends that broadcast, to help make sure
things like the lock screen can update their current time
before the screen is actually turned on.
In addition, switch all of the alarm stats to use the new
PendingIntent "tag" identifier for its operations, instead
of the old code to try to construct a pseudo-identifier
by retrieving the raw Intent.
Also add a new package manager command to immediately write
packages.xml.
Change-Id: Id4b14757cccff9cb2c6b36de994de38163abf615
/frameworks/base/services/core/java/com/android/server/AlarmManagerService.java
|
| 4590e52f3d0558e01322fe4dd55bb612afdfb079 |
|
24-Mar-2014 |
Dianne Hackborn <hackbod@google.com> |
Battery stats: wake locks, radio active, cleanup.
- Improve wake lock work source updates to also update the current
history tag, in case the new work source gets recorded in the
history.
- Fix bug in recording radio active time that was not distributing
any time to apps.
- No longer hold a wake lock while dispatching data conn active call,
since it comes with its own timestamp.
- Fix issue where the top app was not being cleared while the screen
was off.
- Remove obsolete STATS_LAST stats type.
- Fix bug that was not clearing the total run time when resetting
the stats.
Change-Id: Iabe17a9edf34f762374ae09fcffb8a819cf72e30
/frameworks/base/services/core/java/com/android/server/AlarmManagerService.java
|
| a1bd79268be693f04f4adee90673d6ed400cc9fd |
|
21-Mar-2014 |
Dianne Hackborn <hackbod@google.com> |
Battery stats: track actually running time
Use the uptime while creating the battery stats history to
generate a new event indicating when the CPU is actually running.
We can do this in combination with the new event reporting when
the CPU comes awake, looking at the difference between the
uptime and elapsed time at that point to determine when it last
when to sleep.
Also use this information to generate a new set of aggregated
states, the uptime caused by each wake reason.
Finally use new radio down timestamp to adjust the times we
compute for radio use. Note that this information is not (yet)
being used to adjust how these are recorded in the history.
Change-Id: I723b3b526c8e7d64de0cac9d1193e04132d5a3e4
/frameworks/base/services/core/java/com/android/server/AlarmManagerService.java
|
| e5167ca61e2c5607aad9041b44158581bc61b4d8 |
|
08-Mar-2014 |
Dianne Hackborn <hackbod@google.com> |
Reduce wake lock noise in battery history.
When the work source of a wake lock was changed, this would
cause the old wake lock to be released in battery stats before
the new one was acquired (the power manager would correctly
keep holding the associated wake lock). This resulted in a
pointless entry in the battery history showing the last wake
lock being released and a new one acquired.
This change adds a new path in to battery stats to report
when a wake lock has changed, allowing it to acquire the
new wake locks first before the old ones, so it can't drop
down to zero wake locks. This also provides better timing
information, as the same current time can be used for both
operations.
In addition, added a new kind of history entry for the
current time, so you can tell when in actual world clock
time the battery data is happening.
Change-Id: Ibbf2eed83bb93f31f60267889b7bc5b9e71e355f
/frameworks/base/services/core/java/com/android/server/AlarmManagerService.java
|
| c51cf03cf2458c8c137f60c7379f2cccf681d16f |
|
03-Mar-2014 |
Dianne Hackborn <hackbod@google.com> |
Start recording wakeup reasons in battery history.
Depends on a modification to libsuspend so that we can get
a callback each time the device wakes up, to read the current
wakeup reasons from the kernel. These are then stuffed in
to a new field in the battery history.
Also add new dump options --history-start and --charged
to better control what is dumped.
Finally the alarm manager uses a "*walarm*" tag for history
item wake locks that are coming from a wakeup alarm.
Change-Id: I457571973d5b2b5fdc4e4b63ab16275db20d7edd
/frameworks/base/services/core/java/com/android/server/AlarmManagerService.java
|
| a1f1a3c573acd91024fda0ceb3b921c73b186963 |
|
25-Feb-2014 |
Dianne Hackborn <hackbod@google.com> |
More battery stats.
- Add events for sync.
- Add more descriptive tags for wake events.
- Fix battery reset.
- Fix tracking of wifi data.
Change-Id: Ic07f2a86a5ed33e7da57eb1108c31c777ecd801f
/frameworks/base/services/core/java/com/android/server/AlarmManagerService.java
|
| 4418372b21e91f6d4b9e11931dd87a90a023d79e |
|
22-Feb-2014 |
Greg Hackmann <ghackmann@google.com> |
am 5f652b9f: am 0cab896a: resolved conflicts for merge of 9e413bf4 to klp-modular-dev-plus-aosp
* commit '5f652b9fdfbcc279353955f7ef86b72d2ef9f5fb':
open("/dev/rtc0") failure in AlarmManagerService.setTime() should be non-fatal
Move time setting code from SystemClock to AlarmManagerService
|
| 0cab896a987f6687affd5c50c3bdbe10745c8dff |
|
22-Feb-2014 |
Greg Hackmann <ghackmann@google.com> |
resolved conflicts for merge of 9e413bf4 to klp-modular-dev-plus-aosp
Change-Id: Ibc41f0248235afca9546829e00b31003d09f4f7e
|
| cab8617b8ccea3a99b1ee15e15915c512a10c738 |
|
11-Feb-2014 |
Jeff Brown <jeffbrown@google.com> |
am 25df673b: am 1b51c9cb: Merge "Make SystemService constructor take a Context." into klp-modular-dev
* commit '25df673b849de374cf1de40250dfd8a48b7ac28b':
Make SystemService constructor take a Context.
|
| b880d880c6cd989eacc28c365fc9a41d31900da1 |
|
11-Feb-2014 |
Jeff Brown <jeffbrown@google.com> |
Make SystemService constructor take a Context.
This change simplifies the process of initializing a SystemService
by folding the onCreate() step back into the constructor. It removes
some ambuiguity about what work should happen in the constructor and
should make it possible for services to retain most of their final
fields after refactoring into the new pattern.
Change-Id: I25f41af0321bc01898658ab44b369f9c5d16800b
/frameworks/base/services/core/java/com/android/server/AlarmManagerService.java
|
| 3d658bf20e2d56e36941e7407deebeec1276fbcf |
|
05-Feb-2014 |
Dianne Hackborn <hackbod@google.com> |
Improve logging of first wake lock, history size.
We now try to have a better label for the first wake lock
that is acquired in the log. This is done in two ways:
- The alarm manager now sorts the alarms it is going to
execute so that wakeup alarms are first, which are more
important w.r.t. which one should be logged.
- There is a new power manager facility to make a wake lock
as "unimportant for logging," which just means in battery
stats that a wake lock acquired after that can be considered
the actual one to log. This is only used by the alarm manager
to mark its TIME_TICK alarms as unimportant for logging.
Also reworked the battery history code to be cleaner and a bit
smaller. There is no longer a separate EVENT command, instead
the event code and tag are just another thing that can be included
in an UPDATE command.
The bits used in the first history int are also re-arrange, so
that only the ones that really change a fair amount in the state
bits are up at the top and there is no longer space used for
the command code (since now it is always just UPDATE). This
allows us to have more room for the time delta at the bottom,
to better avoid situations where we need to write an int delta.
Change-Id: I1bb860ae5b558a248800b090b03a84fbf7acd68a
/frameworks/base/services/core/java/com/android/server/AlarmManagerService.java
|
| 099bc627c463d9941e23e480f25a78a154429c55 |
|
22-Jan-2014 |
Dianne Hackborn <hackbod@google.com> |
Battery stats improvements.
- Adjust total power use when there is unaccounted power so that our
percentages don't end up > 100%.
- Fix accounting of isolated uids to be against the owning real app
uids.
- Rework how we put cpu use into the battery stats to no longer need
this uid name cache that can confuse the uid it is associated with.
- Finish implementing events in the history, adding a string pool and
reading/writing/dumping them.
- Add first two events: processes starting and finishing.
- Fix alarm manager reporting of wakeup alarms to be adjusted by the
WorkSource associated with the alarm, so they are blamed on the
correct app.
- New "--history" dump option allows you to perform a checkin of
only the history data.
- Fixed BitDescription bug that would cause incorrect printing of
changes in some states.
Change-Id: Ifbdd0740132ed178033851c58f165adc0d50f716
/frameworks/base/services/core/java/com/android/server/AlarmManagerService.java
|
| 9158825f9c41869689d6b1786d7c7aa8bdd524ce |
|
22-Nov-2013 |
Amith Yamasani <yamasani@google.com> |
Move some system services to separate directories
Refactored the directory structure so that services can be optionally
excluded. This is step 1. Will be followed by another change that makes
it possible to remove services from the build.
Change-Id: Ideacedfd34b5e213217ad3ff4ebb21c4a8e73f85
/frameworks/base/services/core/java/com/android/server/AlarmManagerService.java
|