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