diff options
| author | Jeff Sharkey <jsharkey@android.com> | 2015-12-02 16:42:25 -0700 |
|---|---|---|
| committer | Jeff Sharkey <jsharkey@android.com> | 2015-12-03 13:55:09 -0700 |
| commit | bedbaa9ea6e41eaa34a35098c913c096ddf2ce0f (patch) | |
| tree | 498eb35060aa691c636f54ac9541db135e3d00bf /tools/aapt2/java/JavaClassGenerator_test.cpp | |
| parent | 10ad84a17d7248488c1653bacc9f20d3a7193999 (diff) | |
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
Diffstat (limited to 'tools/aapt2/java/JavaClassGenerator_test.cpp')
0 files changed, 0 insertions, 0 deletions