| 24d949138fe85e0efe55f181f270e6791b06f603 |
|
07-Jul-2016 |
Jeff Sharkey <jsharkey@android.com> |
Suppress PRE_BOOT notifications for some profiles.
When a profile is unlocked as a side effect of it's parent user being
unlocked, it's confusing to see two sets of identical notifications,
so suppress the set belonging to the profile.
Profile notifications are still shown when the profile has a separate
authentication challenge.
Bug: 29931646
Change-Id: Id8d621451996c9e2f159560894596292ceb00f8d
/frameworks/base/services/core/java/com/android/server/am/UserState.java
|
| 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
|