c94c2493717264641bdfd205fd1f023193caa535 |
|
21-Apr-2016 |
Fyodor Kupolov <fkupolov@google.com> |
Broadcast USER_INITIALIZE after user is unlocked Previously USER_INITIALIZE was sent before USER_UNLOCKED. This was leaving BOOT_COMPLETED as the only option for non-directBootAware apps to do one time initialization. Now USER_INITIALIZE is sent immediately after the user is unlocked. Bug: 28278011 Change-Id: Id82eae91af80a66454d4027050120ae841decfeb
/frameworks/base/services/core/java/com/android/server/am/UserState.java
|
84a4c971c484f05f2a2494d6353f36f4d954a5e0 |
|
18-Apr-2016 |
Jeff Sharkey <jsharkey@android.com> |
Unlock should always wait for pending PRE_BOOT. While processing an unlock request, we might go async to handle long-running operations like dispatching PRE_BOOT_COMPLETED. This change ensures that all unlock requests for a particular user wait in line behind any pending async operations. Without this CL, any subsequent unlock requests would immediately return successful, even though PRE_BOOT_COMPLETED events were still being processed. Bug: 28240584 Change-Id: I307d6aaebfb8f38028f3666a2e19e4399b7cf3a7
/frameworks/base/services/core/java/com/android/server/am/UserState.java
|
bd91e2f3f6aca512a02be645b2515b5e3331e177 |
|
22-Mar-2016 |
Jeff Sharkey <jsharkey@android.com> |
Update PRE_BOOT_COMPLETED for FBE. Now that CE data isn't available until after a user is unlocked, we need to delay the PRE_BOOT_COMPLETED broadcasts. This is done by adding a new RUNNING_UNLOCKING user state to the UserController lifecycle. We now track the last fingerprint a user was logged in under, and we dispatch PRE_BOOT receivers when that fingerprint changes. To work around battery pull issues, we only persist the updated fingerprint once all PRE_BOOT receivers have finished. This is less granular than the original solution, but it's still correct. We only consider a user as "logged in" once it transitions into the RUNNING_UNLOCKED state. When starting a process, track if the user was "unlocked" when started, so that we only spin up unaware providers in processes started before user unlock. Add generic IProgressListener to communicate PRE_BOOT progress and strings up to lock screen. For now, LockSettingsService just blocks until finished, but it could display these strings in the future. Bug: 27220885 Change-Id: I349439776b885acd32f6a578d8951ffd95640be2
/frameworks/base/services/core/java/com/android/server/am/UserState.java
|
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/am/UserState.java
|
f9fc6d6cc05595241bc7ced6d4cab97b45f9b901 |
|
09-Nov-2015 |
Jeff Sharkey <jsharkey@android.com> |
More file-based encryption work. Add granular StorageManager APIs for key creation/destruction and unlocking/locking. Start passing through an opaque token as part of the unlock command, but leave it empty for now. We now have a separate "prepare" method that sanity checks that user directories are correctly setup. Define a handful of system properties used for marking devices that should be operating in FBE mode, and if they're emulating FBE. Wire a command to "sm", but persisting will come later. Start using new "encryptionAware" flag on apps previously marked with coreApp flag, which were apps running in the legacy CryptKeeper model. Small tweaks to handle non-encryptionAware voice interaction services. Switch PackageManager to consult StorageManager about the unlocked state of a user. Bug: 22358539 Change-Id: Ic2865f9b81c10ea39369c441422f7427a3c3c3d6
/frameworks/base/services/core/java/com/android/server/am/UserState.java
|
37a40c24deb02bca3868a8085069afae112f22e4 |
|
17-Jun-2015 |
Amith Yamasani <yamasani@google.com> |
App Standby : Association between content providers and their sync adapter Set sync adapters to active if the associated content providers are used at foreground process state. Minimize how frequently published content providers are reported by keeping track of last reported time. Also cache sync adapters associated with an authority in SyncManager. Bug: 21785111 Change-Id: Ic2c8cb6a27f005d1a1d0aad21d36b1510160753a
/frameworks/base/services/core/java/com/android/server/am/UserState.java
|