bedbaa9ea6e41eaa34a35098c913c096ddf2ce0f |
|
03-Dec-2015 |
Jeff Sharkey <jsharkey@android.com> |
Flesh out user locked/unlocked lifecycle. When a user is first started, we assume that they're "locked" meaning that credential-encrypted data is unavailable. Once credentials have been supplied, we can transition the user to a fully running state. To facilitate this lifecycle, UserState now has two separate RUNNING_LOCKED and RUNNING states. To ensure consistent events are sent on all devices, we always step through RUNNING_LOCKED before arriving at RUNNING. This consistency means that apps processing data based on the new ACTION_LOCKED_BOOT_COMPLETED broadcast and system services using the new onUnlockUser() event will be less bug-prone over time. If the user storage is unlocked (which is the case on the majority of legacy devices), we immediately transition from the RUNNING_LOCKED into the RUNNING state. Add logging for all state transitions. When we "recover" a user in the process of being shut down, return to the last known state. Bug: 25943941 Change-Id: I5fec980f10b0d0fb2c272a662d193dc15136f9b9
/frameworks/base/services/core/java/com/android/server/SystemService.java
|
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/SystemService.java
|
29564cd24589867f653cd22cabbaac6493cfc530 |
|
07-Aug-2014 |
Narayan Kamath <narayan@google.com> |
Remove system_server classes from the boot image. We set the system_server classpath in the environment (like we do with BOOTCLASSPATH). After the zygote forks the system_server, we dexopt the classpath (if needed) and then launch the system server with the correct PathClassLoader. This needed several small / medium refactorings : - The logic for connecting to installd is now in a separate class and belongs in the system_server. - SystemService / SystemServiceManager have now moved to classes.jar. They are only used from there, and since they use Class.forName, we want them to be loaded by the system_server classloader, and not the bootclassloader. - BootReceiver now moves to frameworks.jar, because it is used by ActivityThread and friends. bug: 16555230 Change-Id: Ic84f0b2baf611eeedff6d123cb7191bb0259e600
/frameworks/base/services/core/java/com/android/server/SystemService.java
|
b102b2cc73baa20e8cc9e4c081235b031c4e8fe0 |
|
20-Dec-2013 |
Adam Lesinski <adamlesinski@google.com> |
Move SystemService code to frameworks/base/core Paves the way for building services without needing to see the rest of frameworks/base/services. Change-Id: I8ac4bc9d25471e96076cd888c1fc24b918d8911f
/frameworks/base/services/core/java/com/android/server/SystemService.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/SystemService.java
|