7ab4025474d3ce80b00fbc96962a585f918a0be1 |
|
16-Jun-2016 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #29371078: Foreground jobs should not count... ...as active for idle maintenance Nor jobs of whitelisted apps. Now they don't. Also remove the no longer used "active download" tracking code. Change-Id: I553197801f6eabaf15716f3201dd65257a0d4e94
/frameworks/base/core/java/android/os/IDeviceIdleController.aidl
|
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/core/java/android/os/IDeviceIdleController.aidl
|
ca5edbb6b5300e07a5f7bfbec36f08df65d8f6e7 |
|
13-Jan-2016 |
Yao Chen <yaochen@google.com> |
Changes in DeviceIdlecontroller and JobScheduler to support Auto GarageMode. Changes made in the cl: 1. Let DeviceIdleController take listeners on whether background maintanence services are active. This currently includes JobScheduler, SyncManager, DownloadService. Note this is the last known states reported by these services. 2. In JobScheduler, make the idle threshold and alarm window configurable. So in the car case, we don't need to wait 71 mins after screen off to kick off any jobs that require device idle. ------------------------------------------------------------------- * We are not going to suppress JobScheduler, DownloadService, SyncManager entirely while user is driving. Because apps may not be working properly if these services are suspended. * The jobs that we don't allow to run while driving are the jobs submitted to JobScheduler that require device idle. And this is already taken care of, because screen is ON and JobScheduler will not consider the device to be idle while driving (unless user turns off the head unit). * We will need to give the JobScheduler a chance to run the device idle jobs when car is turned off. This is the scope of GarageMode. If DownloadService and SyncManager want to run, we will allow them to run too. * The headunit is treated as wall power device, so it's always charging. The charging state will not toggle. Change-Id: I55b92cf92efd61c48dd6c9b8197c2b68078a4439
/frameworks/base/core/java/android/os/IDeviceIdleController.aidl
|
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/core/java/android/os/IDeviceIdleController.aidl
|
4a503b1ece485d44c15eb02ec2bcd464b46e6f7f |
|
07-Aug-2015 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #22989030: Separate battery whitelists We now have a new whitelist you can put apps in, which opts them out of the old battery saver mode and new app idle, but doesn't keep them from going in to doze. This is for a few special cases that we had previously whitelisted for battery saver, and inherited to the new modes... ultimately we should figure out how to get these apps out of the whitelist completely, but this will help for now. Apps in this new whitelist are not shown in the UI, because they are still significantly restricted by not being able to operate normally in doze. This also means they are still visible in the list of all apps for the user to be able to put them on/off the complete whitelist if that is what they really want. In the course of doing this, I needed to clean up code in the network policy manager to better separate management of the two firewall rules that now have different whitelists applied to them. This also hopefully just generally simplifies and cleans up that code. Hopefully! Change-Id: I92e15f2f85899571dd8b049b5e3eb1354f55f353
/frameworks/base/core/java/android/os/IDeviceIdleController.aidl
|
451c3468b9186790d5381334a736a35f9b1dab36 |
|
22-Jul-2015 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #22612630: Ensure SMS/Call delivery during Doze Add whitelist timeout for SMS. Change-Id: I3392093000ad177a93b6ef36fb18f0398a671423
/frameworks/base/core/java/android/os/IDeviceIdleController.aidl
|
fd854ee58c5d56f84047007ead9f88a767ae956f |
|
14-Jul-2015 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #21626564: MMS should be receivied while Dozing We now place whoever is receiving the MMS on the temporary whitelist while doing so, so they can get network access to download it. There was also an issue that needed to be fixed where we were no longer updating the list of allowed uids while dozing based on their proc states... we now do that. Also did a bit of optimization of the temp white list update path do the network policy manager, instead of going through a broadcast we now directly call in to the network policy manager. This also allows us to have a synchronous version of updating the list, so we can know the app has network access before we tell it to do anything. Finally added battery stats events for things going on and off the whitelist so we can diagnose the behavior there. Change-Id: Ic7fe010af680034d9f8cb014bb135b2addef7455
/frameworks/base/core/java/android/os/IDeviceIdleController.aidl
|
b6683c428698105f715985a96066192aa62e9f53 |
|
19-Jun-2015 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #20494208: Go out of device idle when headset button is pressed Rework how we record active transitions in battery stats to be more general, and add an API that others can call in to DeviceIdleController to request that we go out of idle mode. use this for VOICE_SEARCH_HANDS_FREE. Change-Id: Ie58de60e63036a4142881283835961fbcceec892
/frameworks/base/core/java/android/os/IDeviceIdleController.aidl
|
af575b9f8e1b59be9c8862b6a65c0dcb88145a23 |
|
30-May-2015 |
Amith Yamasani <yamasani@google.com> |
Temporarily whitelist an app for network during doze API to allow an app to be whitelisted for network and wakelock access for a short period. So even if the device is in idle mode, such apps can be given a chance to download the payload related to a high priority cloud-to-device message. This API is meant for system apps only. A new permission CHANGE_DEVICE_IDLE_TEMP_WHITELIST is required to make this call. Bug: 21525864 Change-Id: Id7a761a664f21af5d7ff55aa56e8df98d15511ca
/frameworks/base/core/java/android/os/IDeviceIdleController.aidl
|
06bf824628c118fbd5ad6756913d7fd63a6f4ce5 |
|
09-May-2015 |
Amith Yamasani <yamasani@google.com> |
Idle timebase Use screen on time as timebase for idling out apps that have been inactive. Store the time when an app was last active as an additional package state in UsageStats. Compare it to screenOnTime to decide if it's inactive. Exclude device idle whitelist from apps that can go inactive. Bug: 20066058 Change-Id: I709f9f31a9affa7ca6e1ae3e4c5729c5fb221669
/frameworks/base/core/java/android/os/IDeviceIdleController.aidl
|
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/core/java/android/os/IDeviceIdleController.aidl
|