50191db10ac137add9bd06d3a8a660294a75bfad |
|
10-May-2017 |
Christopher Tate <ctate@google.com> |
Allow NEXT_ALARM_CLOCK_CHANGED to launch manifest receivers Bug 37452651 Test: manual Change-Id: If74fe1baff956d8cd888fe40b521f2c0b852b3ee
/frameworks/base/services/core/java/com/android/server/AlarmManagerService.java
|
5cdf9f8938f1deebc44722ec2ae9b500b4450bb1 |
|
04-May-2017 |
Christopher Tate <ctate@google.com> |
Allow TIMEZONE_CHANGED to launch apps Bug 37866305 Test: manual Change-Id: If15df909e99e910c012f2a7b33ae8600c0f97d8d
/frameworks/base/services/core/java/com/android/server/AlarmManagerService.java
|
4274a6d9b4669cbbfb53fd6d4abefa9d77947e06 |
|
21-Apr-2017 |
Makoto Onuki <omakoto@google.com> |
Add more log to track down the "idle until changed" issue. Bug 34724174 Test: Tested manually with intentionally adding a bug. Change-Id: I1789285068203b22ce271180667eb9cb1eb0b182
/frameworks/base/services/core/java/com/android/server/AlarmManagerService.java
|
24757146d1a70f3f483b660a2d20bbdd71152782 |
|
10-Apr-2017 |
Christopher Tate <ctate@google.com> |
Ensure the system boots with a halfway sane time/date Just in case the kernel or vendor glue don't initialize the system time sensibly, we now make sure the current time at boot is at least up to the build time of the system disk image. Bug 36736983 Test: manual Change-Id: I46f776300ca4f5ad01396fc17c83fc833e1713f9
/frameworks/base/services/core/java/com/android/server/AlarmManagerService.java
|
6df866a8510af2776c48425a361f708ae7f5d7d6 |
|
31-Mar-2017 |
Jeff Sharkey <jsharkey@android.com> |
Enforce PACKAGE_USAGE_STATS for usage data. Some system services are offering package usage data through both public/system APIs and through dump() calls. In principle, usage data hould always be protected with PACKAGE_USAGE_STATS, so start enforcing that. (Otherwise if a user blocked PACKAGE_USAGE_STATS access to an app, that app could still obtain the data via dump() if they held the DUMP permission.) Bottom line, let's respect the user's wishes. Protecting the entire output like this is pretty blunt, but future CLs can add more nuance to the output if desired. Test: cts-tradefed run commandAndExit cts-dev -m CtsSecurityTestCases -t android.security.cts.ServicePermissionsTest Bug: 32806790 Change-Id: I46173562713bea7d89e12a4313c78eb52ea8d77d
/frameworks/base/services/core/java/com/android/server/AlarmManagerService.java
|
fe9a53bc45fd0124a876dc0a49680aaf86641d3e |
|
31-Mar-2017 |
Jeff Sharkey <jsharkey@android.com> |
Consistent dump() permission checking. This change introduces new methods on DumpUtils that can check if the caller has DUMP and/or PACKAGE_USAGE_STATS access. It then moves all existing dump() methods to use these checks so that we emit consistent error messages. Test: cts-tradefed run commandAndExit cts-dev -m CtsSecurityTestCases -t android.security.cts.ServicePermissionsTest Bug: 32806790 Change-Id: Iaff6b9506818ee082b1e169c89ebe1001b3bfeca
/frameworks/base/services/core/java/com/android/server/AlarmManagerService.java
|
291df4fc0c3fc7a28bf0d89619b7e7bc0ea672e1 |
|
14-Mar-2017 |
Chad Brubaker <cbrubaker@google.com> |
Expose Intents to Instant Apps This exposes Intents used by Android widgets to Instant Apps. The following Intents are exposed: Intent.ACTION_TIME_TICK Intent.ACTION_DATE_CHANGED Intent.ACTION_TIMEZONE_CHANGED Intent.ACTION_TIME_CHANGED Intent.ACTION_CONFIGURATION_CHANGED Intent.ACTION_LOCALE_CHANGED Intent.ACTION_SCREEN_OFF Intent.ACTION_SCREEN_ON Intent.ACTION_USER_PRESENT Bug: 33350280 Test: Manually verified that broadcasts are received. Change-Id: Ife94f594c1ff30f2625a57e1cc69f36cc00d1f34
/frameworks/base/services/core/java/com/android/server/AlarmManagerService.java
|
8025580449081ddd21f449f8719bc87d1cc9fc7b |
|
04-Mar-2017 |
Sudheer Shanka <sudheersai@google.com> |
Update IUidObserver.onUidStateChanged to include procStateSeq. This procStateSeq is associated with the process state change of an uid and will help in identifying if network policy rules have been updated for a process state change. Bug: 27803922 Test: runtest -c com.android.server.am.ActivityManagerServiceTest frameworks-services Change-Id: Iaab8d004f476b96f28d08c886c7b0a6b585b9fef
/frameworks/base/services/core/java/com/android/server/AlarmManagerService.java
|
3e7d845161870f6289aeecdf4bfd762097f487d6 |
|
03-Mar-2017 |
Makoto Onuki <omakoto@google.com> |
Make sure to call the original reply-to receiver when... replacing a queued broadcast. - Also don't replace a broadcast for a different user. Test: Manual test with the following test code: Intent intent = new Intent(Intent.ACTION_PROVIDER_CHANGED) .addFlags(Intent.FLAG_RECEIVER_REPLACE_PENDING); AlarmManager alm = this.getSystemService(AlarmManager.class); long time = SystemClock.elapsedRealtime() + 5 * 1000; for (int i = 0; i < 5; i++) { alm.setExact(AlarmManager.ELAPSED_REALTIME, time, PendingIntent.getBroadcast(this, i, intent, PendingIntent.FLAG_UPDATE_CURRENT)); } Without this CL, after the alarm fires, AlarmManagerService.mBroadcastRefCount is left > 0 and the wake lock is held forever. With this CL, mBroadcastRefCount eventually gets back to 0. Bug: 35779096 Change-Id: I4e21c94b08f25f9ca1242182670ff4a69f8bd9f2
/frameworks/base/services/core/java/com/android/server/AlarmManagerService.java
|
33955e10bb834d72f66c5a16b8a848c1ef7070bc |
|
02-Mar-2017 |
Makoto Onuki <omakoto@google.com> |
Improve dumpsys output for AlarmMAnager Test: manual test with dumpsys alarm Change-Id: I788be58d3cdc5e10045908b6d4501933b1603cb9
/frameworks/base/services/core/java/com/android/server/AlarmManagerService.java
|
2b6e459e33a128ed18b1f89c2af7368c545dd3e8 |
|
17-Feb-2017 |
Christopher Tate <ctate@google.com> |
Send TIME_SET to manifest receivers, too Also expand the slew window for minimizing the effects of time-set flapping from 500ms to 1000ms. Bug 35319393 Change-Id: I6d6df1e086115ebe12c0bc4b9d761a11a0267012
/frameworks/base/services/core/java/com/android/server/AlarmManagerService.java
|
0ef403e53e2762d077750dd0a50b73c2125cadb0 |
|
25-Jan-2017 |
Dianne Hackborn <hackbod@google.com> |
Add some new experiment constants for activity and power manager. Activity manager now has constants, starting with two: bg check and process limit. Power manager now has constants, starting with one: controlling disabling of wake locks from cached processes. Test: manual Change-Id: I05db42e2104e9d31584f85251412df2d5efb34b6
/frameworks/base/services/core/java/com/android/server/AlarmManagerService.java
|
c3af19a87dc70c321ffcc1e90453bb6f0545aef2 |
|
21-Jan-2017 |
Dianne Hackborn <hackbod@google.com> |
Optimize bg check flow. No longer need to look up the application info, target SDK is explicitly passed in to the check. For the external method, we change this to just checked to see if background is completely disabled, which doesn't need a target SDK check (and is the only thing any of the current clients care about). Now allow SystemUI to put targets of notification pending intents on the temporary whitelist when they fire, so developers can avoid dealing with background restrictions in this case (if the user interacts with their notification, they will temporarily be considered in the foreground). Remove any thoughts of enforing restrictions on registerReceiver(), so we don't need to deal with target SDK versions there (which can't be done all that efficiently). Also bring back the old "allow starts coming from foreground apps" only for the MODE_IGNORE app op, since it should provide some better compatibility. Test: ran them. Change-Id: Id4ea7f992d12ce4bd8e54f1dbaeb4a460a3dee59
/frameworks/base/services/core/java/com/android/server/AlarmManagerService.java
|
dc589ac82b5fe2063f4cfd94c8ae26d43d5420a0 |
|
11-Nov-2016 |
Sudheer Shanka <sudheersai@google.com> |
Update usage of ActivityManagerNative. - Remove references to ActivityManagerProxy. - Add isSystemReady to ActivityManager. Bug: 30977067 Test: cts/hostsidetests/services/activityandwindowmanager/util/run-test android.server.cts adb shell am instrument -e class com.android.server.am.ActivityManagerTest,com.android.server.am.TaskStackChangedListenerTest \ -w com.android.frameworks.servicestests/android.support.test.runner.AndroidJUnitRunner Change-Id: I07390b6124fb1515821f5c0b37baf6ae74adc8fa
/frameworks/base/services/core/java/com/android/server/AlarmManagerService.java
|
e07641d4fbdd0528c18305213e861a6e1aff4a3b |
|
10-Nov-2016 |
Dianne Hackborn <hackbod@google.com> |
Start implementing background restrictions for eph apps. This implements the additional intended path for checking allowed background operations, APP_START_MODE_DISABLED, which doesn't allow an app to launch in the background at all. Also change the semantics of delivering broadcasts to manifest receivers to always restrict those, not changing based on whether the app is currently idle. This is the desired intended behavior for apps as they explicitly update to work with bg check. And now that we have ephemerality associated with the uid state in the activity manager, we can propagate this through the relevant callbacks in IUidObserver so things watching these changes can immediately determine whether they should do their more aggressive shut down work for the uid rather than having to walk through all their state looking for package associated with that uid and whether they should be shut down. Also remove the "lenient" bg check mode, since that was just an early experiment that we won't actually use. Add a new "make-idle" activity manager command to immediately put a uid into the idle state (if possible) to make it easier to test. Test: manually against an eph app Change-Id: I43a138ff281f69a9251d3f29ab6e13f48cff8ad6
/frameworks/base/services/core/java/com/android/server/AlarmManagerService.java
|
5614bf5a1ae4522dfc1a041f003cebc9b25c8b93 |
|
08-Nov-2016 |
Dianne Hackborn <hackbod@google.com> |
Move code for handling uid obs "cutoff" to activity manager To do this, I had to fix the PROCESS_STATE_NONEXISTENT constant to be the last value (instead of the special magical -1 value) so it semantically matches the public importance constants. I think this is better anyway. Also this fixes a big problem in the implementation, where we weren't keeping track of the last proc state per uid...! Duh. Test: manually ran testUidImportanceListener Change-Id: Ie3008f824446089840f896885e6033472abb065e
/frameworks/base/services/core/java/com/android/server/AlarmManagerService.java
|
058f1e4468bd54d0ac39fdf81b4df7221b28721a |
|
03-Nov-2016 |
Dianne Hackborn <hackbod@google.com> |
Implement system API for monitoring uid importance changes. Changed the permission for registerUidObserver to be PACKAGE_USAGE_STATS, which better matches the semantics of this API and is accessible to system apps. Test: Added testUidImportanceListener() Change-Id: Ib47d02bd654fbe399a9c92550c89ecbd38f928dc
/frameworks/base/services/core/java/com/android/server/AlarmManagerService.java
|
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
|