| 1219c924bdf98fd5342fe5bb7cd09da1012d2e1a |
|
20-Jun-2016 |
Nicolas Prevot <nprevot@google.com> |
Don't allow showing an activity if user is stopping or shutting down.
BUG:29264996
Change-Id: I9fc97c5dc37e6d5656b82b277954b5963eb345c4
/frameworks/base/services/core/java/com/android/server/am/UserController.java
|
| 899608a83f9a05d64b3fa4743215c9dd1af66077 |
|
27-May-2016 |
James Hawkins <jhawkins@google.com> |
am/UserController: Log system uptime at two 'boot complete' markers.
ACTION_LOCKED_BOOT_COMPLETED and ACTION_BOOT_COMPLETED.
Bug: 28070626
Change-Id: I6ff8e840a1c1faf804d6889ac0c3ad96cca8d6f3
(cherry picked from commit 64ce4e7e810c9e002771afbe0838742a82fc4ef9)
/frameworks/base/services/core/java/com/android/server/am/UserController.java
|
| ac06a4907bff7d5ee0612dbb85180222e1455791 |
|
25-May-2016 |
Fyodor Kupolov <fkupolov@google.com> |
Remove ActivityManager calls with PM.mInstallLock held
UserController now pushes user state to UMS.
PM now checks user running/unlocking/unlocked state by calling
UserManagerInternal.
Bug: 28090199
Change-Id: I20e62b37f78238f28dd81f49f876732bbd3c6b34
/frameworks/base/services/core/java/com/android/server/am/UserController.java
|
| 4266feeb93fae4603e8a43d065160430a4c784a5 |
|
23-May-2016 |
Ricky Wai <rickywai@google.com> |
Unlock work profile storage even work mode is off
Bug: 28860823
Change-Id: Ic89027f163e4c4e1ba9e8c24174475b6a4a983a4
/frameworks/base/services/core/java/com/android/server/am/UserController.java
|
| ae13e18c5561537e062f46ddda8e5dff30d1fe26 |
|
17-May-2016 |
Tony Mak <tonymak@google.com> |
Should check isDeviceSecure in shouldConfirmCredentials
The NPE is because createConfirmDeviceCredentialIntent returns a null
intent when it founds that user does not set a secure lock.
So the fix is we should check is the user set a secure lock screen as well.
The reason the crash only happens in multi-window flow because
we have null checking in
the normal flow (i.e. interceptWithConfirmCredentialsIfNeeded).
But I think we better check it explicitly.
Bug: 28716456
Change-Id: Ib204cd02c0007bd1df36908bb3b5254ec4ffb914
/frameworks/base/services/core/java/com/android/server/am/UserController.java
|
| 6c915ead38db0a2a6393c40d4fbac959399439c5 |
|
10-May-2016 |
Fyodor Kupolov <fkupolov@google.com> |
Push unlocking/unlocked state to UserManager
Push unlocking/unlocked state to UserManagerInternal when it's changed in
UserController. Use UserManagerInternal.isUserUnlockingOrUnlocked when
updating flags for filtering in PackageManager.
Bug: 28629076
Change-Id: I8440af090f533f93870d0cff0e3871e114c37efa
/frameworks/base/services/core/java/com/android/server/am/UserController.java
|
| cca1c654f8d0d2ec4671e3b1342a2db5a5256eab |
|
04-May-2016 |
Fyodor Kupolov <fkupolov@google.com> |
Call unlockUserKey in a synchronized section
This will make callers of isUserRunning to wait for the unlock to finish.
Bug: 28530527
Change-Id: I272e2166cdc3df8e34c3436c9c18ba6765da0625
/frameworks/base/services/core/java/com/android/server/am/UserController.java
|
| ec6faca0078263dfbf2b41d11cdb14586e40fd75 |
|
29-Apr-2016 |
Amith Yamasani <yamasani@google.com> |
Merge "Stop user faster and clear stale broadcasts" into nyc-dev
|
| ad2e4bf9f36cf612db6c397feca8effb125ee541 |
|
26-Apr-2016 |
Amith Yamasani <yamasani@google.com> |
Stop user faster and clear stale broadcasts
Moved several USER_STOPPING registered receivers to listen
to USER_STOPPED, since they don't need to be blocking the
shutdown of the user.
Clear all stale broadcasts when stopping a user, so that we
don't unnecessarily start up processes and deliver stale
broadcasts. This was causing code to run when the user was
already stopped and resulted in crashes when other providers
and services couldn't be started anymore. Hopefully this fixes
many of those races.
Bug: 28371487
Change-Id: Ic35a7a23fa8fe009a53f8bf7545d4dad5fa34134
/frameworks/base/services/core/java/com/android/server/am/UserController.java
|
| ce18c8167766f92856f94a8e88e19de4698960e6 |
|
28-Apr-2016 |
Jeff Sharkey <jsharkey@android.com> |
Introduce "unlocking" vs "unlocked" nuance.
There is a narrow window of time during user unlock where we're
reconciling user storage and dispatching the "unlock" status to
various internal system services. While in this "unlocking" state,
apps need to be told that the user still isn't actually "unlocked"
so they don't try making calls to AccountManager, etc.
The majority of internal services are interested in merging together
both the "unlocking" and "unlocked" state, so update them.
Clarify naming in AccountManagerService to make it clear that a local
list is being used, which mirrors the naming in MountService.
To match UX/PM requested behavior, move PRE_BOOT_COMPLETED dispatch
after the user is unlocked, but block BOOT_COMPLETED dispatch until
after all PRE_BOOT receivers are finished to avoid ANRs.
Bug: 28040947, 28164677
Change-Id: I57af2351633d9159f4483f19657ce0b62118d1ce
/frameworks/base/services/core/java/com/android/server/am/UserController.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/UserController.java
|
| fd24108ca9876ac4f3598cf06464b78b61f32a96 |
|
19-Apr-2016 |
Jeff Sharkey <jsharkey@android.com> |
Don't block while dispatching PRE_BOOT.
While we're waiting on the final UX around PRE_BOOT_COMPLETED, don't
frustrate users by giving them a lockscreen that appears frozen
for several seconds.
Bug: 28164677
Change-Id: I54b62cea9bb83bc0f82fdf7e6e46a4640e1a30de
/frameworks/base/services/core/java/com/android/server/am/UserController.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/UserController.java
|
| f6ef828a7495be3bfe767ad0bb67ad155c6101de |
|
14-Apr-2016 |
Ricky Wai <rickywai@google.com> |
Fix cannot unlock keyguard when work challege is unified and work mode is off
Bug: 28138657
Change-Id: I20e2f571d9ac76c0cd92251de7e068f6c7fb3367
/frameworks/base/services/core/java/com/android/server/am/UserController.java
|
| 155e5d6de7059198b21f3f220fbff7bf0baf306c |
|
11-Apr-2016 |
Jeff Sharkey <jsharkey@android.com> |
Send USER_UNLOCKED broadcasts before PRE_BOOT.
Apps handling the PRE_BOOT_COMPLETED broadcast expect the user to be
fully unlocked and working. Most system internals are using the
SystemServer interface, and we dispatch the unlocked event through
them before starting the PRE_BOOT process.
However, there are still some system internals that haven't been
converted to SystemServer, so we need to also send USER_UNLOCKED
for them to pick up before starting PRE_BOOT work.
Bug: 28086245
Change-Id: Ie847b463ea55a6dddcc49d243ef8fb308e5179a7
/frameworks/base/services/core/java/com/android/server/am/UserController.java
|
| 27b5d2e2f992d4f3c3984fa73f1fb861b4c456c5 |
|
11-Apr-2016 |
Jeff Sharkey <jsharkey@android.com> |
Skip unlock requests for users who aren't running.
Bug: 28111989
Change-Id: I80b6dd1e5a2d919b0a198667e18b7979effe6999
/frameworks/base/services/core/java/com/android/server/am/UserController.java
|
| 7661a316b43aed875019e288dcf9d2736c706439 |
|
07-Apr-2016 |
Jeff Sharkey <jsharkey@android.com> |
Unlock newly created managed profiles.
We only need to delay unlocking managed profiles if the parent user
is currently locked.
Bug: 28068215
Change-Id: Ic59872a10417cfc166bd6e79cf94719545c7f45a
/frameworks/base/services/core/java/com/android/server/am/UserController.java
|
| 5dab713ff0c28ff264d5b26dd1a97bc37eee2d55 |
|
07-Apr-2016 |
Jeff Sharkey <jsharkey@android.com> |
Delay unlock attempts for managed profiles.
Managed profiles may not have a credential challenge, so we need to
make sure we don't unlock them until their parent user has been
unlocked. Otherwise the managed profile will get into all sorts of
trouble trying to reach into its still-locked parent.
Bug: 28051109, 27457806
Change-Id: If2ca59834024e5ad039f659d611ef708ed751fad
/frameworks/base/services/core/java/com/android/server/am/UserController.java
|
| 083807d61cd87f0e7d531612c7d6a139901b1078 |
|
06-Apr-2016 |
Jeff Sharkey <jsharkey@android.com> |
Send onUnlockUser() before PRE_BOOT broadcasts.
Before this change, a PRE_BOOT_COMPLETED receiver could try calling
back into the system to ask for AccountManager details, only to be
told the user wasn't unlocked yet. If the broadcast code was probing
in a loop, it would force us to wait around for the 60-second ANR
timeout. Since typical devices have ~7 PRE_BOOT receivers, this
would delay BOOT_COMPLETED and other operations, like mounting the
SD card, for up to 7 minutes.
Bug: 28024024
Change-Id: Ibf8611e6fe94b0deb5ae5715c86f897ff6779088
/frameworks/base/services/core/java/com/android/server/am/UserController.java
|
| 98c0556f4096698003131a68a8dc70b72b89d210 |
|
30-Mar-2016 |
Amith Yamasani <yamasani@google.com> |
Fix deadlock during user state transitions
performReceive() is called with the activity manager lock held.
Don't call out to other system services (such as user state
callbacks) with the lock held. Post a runnable to the handler
instead.
Bug: 27589217
Change-Id: I5c2f8debe1ae365682b27af65e0bf02bcce50d4a
/frameworks/base/services/core/java/com/android/server/am/UserController.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/UserController.java
|
| 8c536f91f1a72f671d41d54b3aeda4d70ee90d49 |
|
21-Mar-2016 |
Tony Mak <tonymak@google.com> |
Show work challenge directly when there is no device lock
The trick is to switch to home stack first and then start the activity
of the targeted task again to trigger the intercepting code.
And back button in the lock screen page brings user to launcher
instead of the work app.
Change-Id: Ic0305dbcb63fec2a8287b12f3e76e70d4268d423
/frameworks/base/services/core/java/com/android/server/am/UserController.java
|
| d5a3f3df4097e4a57e0d31fba994c91d8996abf8 |
|
09-Mar-2016 |
Paul Lawrence <paullawrence@google.com> |
Merge "Add API to IMountService to get encryption state" into nyc-dev
|
| 20be5d62471d520eed3a52d90c11944464a71c07 |
|
26-Feb-2016 |
Paul Lawrence <paullawrence@google.com> |
Add API to IMountService to get encryption state
Bug: 18002358
Change-Id: If7d9c9a5ed38ac37849fcf638ec10c76d2f419a1
/frameworks/base/services/core/java/com/android/server/am/UserController.java
|
| 7745c14aa0128da1358ec5d6e6ba4b609a5ac52b |
|
08-Mar-2016 |
Suprabh Shukla <suprabh@google.com> |
Setting TaskRecord#mUserSetupComplete directly from Settings
TaskRecord#mUserSetupComplete flag was being set by checking
UserController#mSetupCompletedUsers which was being populated by a
callback which was getting delayed long enough for some tasks being
launched with mUserSetupComplete set to false, which is not expected for
any task other than Setup Wizard. This change checks the flag directly
from Settings before setting the property.
Bug: b/27455564
Change-Id: I9ae2e969b590a95f71002a54c7de224b26e9da79
/frameworks/base/services/core/java/com/android/server/am/UserController.java
|
| 1ddda4793c26fd249590fd3549cf060ecb7c157b |
|
12-Feb-2016 |
Lenka Trochtova <ltrochtova@google.com> |
Prevent ephemeral user from being re-entered after stop.
Once the ephemeral user stops, the user's deletion is scheduled.
It takes a while before the user actually disappears and it is not
desirable for the user to be re-entered in the meantime.
Mark the user as disabled on stop and check this flag
in the activity manager to prevent the user from being switched
to again. Also hide the user from user-switching UI.
BUG: 26795729
BUG: 26780152
Change-Id: I83a61674958954b5a210114b88ffa5ae55922c1f
/frameworks/base/services/core/java/com/android/server/am/UserController.java
|
| b93522a7dbe8167e9f88bacd53463c4ae1b01e1c |
|
23-Feb-2016 |
Rubin Xu <rubinxu@google.com> |
Do not show work challenge when profile is turned off.
When the profile is turned off, the associated user is not running so it
makes no sense to try to unlock the profile challenge.
Also adjust order of activity startup interception so suspend package takes
precedence, as that's a state user cannot recover from by his own actions.
Bug: 26928131
Change-Id: Ibb4c8ce02ba4ed2e5a5b4366cbe7b59d1535dbd7
/frameworks/base/services/core/java/com/android/server/am/UserController.java
|
| b5f0049f9841dfe877c070e4aba41516ed7df710 |
|
15-Feb-2016 |
Rubin Xu <rubinxu@google.com> |
Fix typo in filling ACTION_MANAGED_PROFILE_UNLOCKED extras.
Change-Id: Ic949a0d7f72d46d7cc36018b4b0fc54024c3b180
/frameworks/base/services/core/java/com/android/server/am/UserController.java
|
| faf9bdcdba11f53d00b5ad9e03c034ad4840574c |
|
12-Feb-2016 |
Rubin Xu <rubinxu@google.com> |
Small refactoring to eliminate the need to allocate array.
Change-Id: Ib08a16e40c342b12e4f7106376f46d6279f29f2b
/frameworks/base/services/core/java/com/android/server/am/UserController.java
|
| 716a9e189297beba9e2205a335614e1750b9fdd4 |
|
12-Feb-2016 |
Kenny Guy <kennyguy@google.com> |
Merge "Support FBE for managed profiles." into nyc-dev
|
| b1b302660cf5b1b1c5b342cc90eca93b8f66890c |
|
09-Feb-2016 |
Kenny Guy <kennyguy@google.com> |
Support FBE for managed profiles.
Allow launcher to see and attempt to launch non-crypto
aware application when profile is locked.
Hide unlock notification until parent user is unlocked.
Have unlock notitication use confirm credentials to unlock
the profile.
Updated notification strings as per suggestions in mocks
to make it clearer between users and profiles.
Bug: 27038260
Change-Id: If2d2c8148670d814544f4edd44193d15da32a289
/frameworks/base/services/core/java/com/android/server/am/UserController.java
|
| 5eb0f3b3008e9983d97f7414f4ff2738741e5ab5 |
|
12-Feb-2016 |
Rubin Xu <rubinxu@google.com> |
Maintain mSetupCompletedUsers for profiles correctly
When listening for USER_SETUP_COMPLETE changes, refresh the state for
the affected user instead of the current foreground user which excludes
the active managed profile.
Bug: 27061092
Change-Id: Iae525464d3d3faab9afb76aaf4304b9f10382e01
/frameworks/base/services/core/java/com/android/server/am/UserController.java
|
| faeb3eb0ba190e6d6cfe2b82ce20af587848de57 |
|
08-Feb-2016 |
Paul Crowley <paulcrowley@google.com> |
Password security for FBE disk encryption keys
Add the means to protect FBE keys with a combination of an auth token
from Gatekeeper, and a hash of the password. Both of these must be
passed to unlock_user_key. Keys are created unprotected, and
change_user_key changes the way they are protected.
Bug: 22950892
Change-Id: Ie13bc6f82059ce941b0e664a5b60355e52b45f30
/frameworks/base/services/core/java/com/android/server/am/UserController.java
|
| f80170f455c269b8e0264a5441770faf39e69416 |
|
05-Feb-2016 |
Wale Ogunwale <ogunwale@google.com> |
Exclude tasks manipulated before user setup is complete from Recents
We don't want any tasks manipulated before the user is done setting-up
their device included in the tasks list we give to the Recents activity.
However, the task can be included back in Recents if it is manipulated
after the user set-up is complete. E.g. you go into the gmail activity
during setup the task will be exclude, but if the user goes back into
gmail after setup then we start including the task.
Bug: 25959392
Change-Id: I421d48f0a9bcfc782d1ef19aa2f63e8b34a668e2
/frameworks/base/services/core/java/com/android/server/am/UserController.java
|
| 2e6acce4bd2e16c7bf70cb95601aa8bf73d69340 |
|
29-Jan-2016 |
Fyodor Kupolov <fkupolov@google.com> |
Synchronously finish boot when user starts in background
Previously call to finishUserBoot method was delayed until ActivityManager
enters idle state. This could lead to unpredictable timeouts, especially
when AM was already idle.
Bug: 26762234
Change-Id: Iae90c3a9b09ff675478b42271469866e1604df0f
/frameworks/base/services/core/java/com/android/server/am/UserController.java
|
| f13c9801697ccac3171137df10dd15f491dd15bd |
|
21-Jan-2016 |
Rubin Xu <rubinxu@google.com> |
Turn off profile by stopping the user.
Bug: 22541941
Change-Id: I713ab9b87f3dd1b7bd6206af137562d20a44d76d
/frameworks/base/services/core/java/com/android/server/am/UserController.java
|
| 3ee3b9d17b2aec84e791f3efa6b9453cab0d9c9b |
|
16-Jan-2016 |
Suprabh Shukla <suprabh@google.com> |
Merge "Keeping only running users recents in memory"
|
| 09a88f5f3e7d4a3bbfce04ac06594ac590c67d27 |
|
02-Dec-2015 |
Suprabh Shukla <suprabh@google.com> |
Keeping only running users recents in memory
Currently, all the users' recent tasks are loaded into memory and kept
in sync with the persistent storage. This changes the system so
that it loads a users recents into memory lazily (i.e. when
getRecentTasks is called for that user) and unloads them from the
memory as soon as the user is stopped. This also required bucketizing
the taskIds per user, so that the next available taskId can be assigned
without having knowledge of all the tasks that are stored away in
persistent storage but are not available in memory.
Bug-Id: b/24569398
Change-Id: Ia5cb64d9f4ee727225dce34e45ca63e946ac27a8
/frameworks/base/services/core/java/com/android/server/am/UserController.java
|
| 0e62384ccbd00e9f78851929ca88b919679ee32e |
|
14-Jan-2016 |
Jeff Sharkey <jsharkey@android.com> |
Prepare app data only when storage is available.
Before this change, scanning a package aggressively tried checking
to ensure that private app data was prepared. However, in an FBE
world we may not have access to that data at scan time. So this
change shifts the preparing of private app data until later: it
prepares DE storage when a user is started, and CE storage when a
user is unlocked. Wire ourselves into the user lifecycle so we can
prepare storage at both user start and unlock.
When DE/CE storage becomes available, this change reconciles any
found packages against known installed apps, and deletes any orphaned
data directories.
We now need to store the last-restorecon hash in an xattr on a
per-user directory basis, since we can't restorecon CE storage until
it's unlocked, or adopted storage until it's mounted. Remove a
bunch of used logic for loading dynamic SELinux policy at runtime;
our policy always comes from the system image.
Bug: 26466827, 26544104
Change-Id: I8d0a4ef862c35f4e4ef5c7f20d3bb8f12ba3fd4b
/frameworks/base/services/core/java/com/android/server/am/UserController.java
|
| a1771110d67fa7361f92d92f2e91019882ce3305 |
|
18-Dec-2015 |
Clara Bayarri <clarabayarri@google.com> |
Create Work Challenge per-user condition
Change the current static condition to a per-user condition so we
can check and enable/disable the work challenge properly. Also add
an isAllowed API, as the Work Challenge can only be used when the
user's DPC targets N or above to maintain backwards compatibility.
Change-Id: I0cb8b475838816801868ffb24726407aa257b4de
/frameworks/base/services/core/java/com/android/server/am/UserController.java
|
| ea9b10e64419edbd5d3ed13f82007ffed97af418 |
|
04-Dec-2015 |
Clara Bayarri <clarabayarri@google.com> |
Work Challenge: Handle Recents launches
Intercept calls to start activities from the recents
stack and show the Work Challenge if needed. This requires
passing the taskId to ConfirmDeviceCredential so it can
launch the recents task itself when the credentials are
confirmed.
Change-Id: I013b134f3f31a35b551ad683c68cc89b8af44499
/frameworks/base/services/core/java/com/android/server/am/UserController.java
|
| 63f3b888735994e1157ad4272ba3b75f4b13a536 |
|
04-Jan-2016 |
Fyodor Kupolov <fkupolov@google.com> |
Merge "Return USER_OP_SUCCESS when force stopping a user"
|
| 7b4a8a4e808c09b2229a1e3d0a0b691662fba396 |
|
04-Jan-2016 |
Fyodor Kupolov <fkupolov@google.com> |
Return USER_OP_SUCCESS when force stopping a user
Bug: 26379502
Change-Id: I08dc18eec5b8dccf63a806acc9b3bfda890ceedb
/frameworks/base/services/core/java/com/android/server/am/UserController.java
|
| d046a013921c2ac67318c1543a8b7b9c83b40d65 |
|
24-Dec-2015 |
Wale Ogunwale <ogunwale@google.com> |
Consolidate resume activity code around focused stack.
Cleaned up the code to make it obvious that only the top
activity in the focused stack should be in the resumes state.
Bug: 26273032
Change-Id: I8d60270f707fe022007c59d25f5678b33a005acf
/frameworks/base/services/core/java/com/android/server/am/UserController.java
|
| b4484bacf1462fcba7098aa23873cd2f6ed34da3 |
|
16-Dec-2015 |
Lenka Trochtova <ltrochtova@google.com> |
Stop and remove the ephemeral user when it goes to background.
BUG: 24883058
Change-Id: I0e15487fafe08234cde5eebfb9f1d7b96fc7f9fe
/frameworks/base/services/core/java/com/android/server/am/UserController.java
|
| 458ac463742cbac35a2dc8aea0f7a68b9eb6f0f4 |
|
18-Dec-2015 |
Amith Yamasani <yamasani@google.com> |
Fix broken user removal
Check target user instead of current user, when deciding if
user can be stopped.
Bug: 26207032
Change-Id: Ibf9cb827943f8fbf8fa3b96a9e04c96d11a36d0a
/frameworks/base/services/core/java/com/android/server/am/UserController.java
|
| a242f825e67fdef83c2b12e4a2bb4d1d91c8f4bf |
|
17-Dec-2015 |
Jeff Sharkey <jsharkey@android.com> |
Send LOCKED_BOOT_COMPLETED to background apps.
This mirrors how we're treating the normal BOOT_COMPLETED broadcast.
Bug: 26151835
Change-Id: Ibe1df0df8b89aafbe9af073e14fdd428710a6a40
/frameworks/base/services/core/java/com/android/server/am/UserController.java
|
| af6ec296ec200726ac86ff53efc64e221ed6f2f6 |
|
17-Dec-2015 |
Jeff Sharkey <jsharkey@android.com> |
Make AppWidgets encryption-aware.
Only parse and load AppWidget configuration details after a user has
been unlocked. Yell loudly if someone accidentally tries loading
data for a locked user.
Tidy up protected broadcast logic a bit more to handle persistent
processes. Add backwards compatible behavior for APPWIDGET_UPDATE
broadcast simliar to APPWIDGET_CONFIGURE, since some apps are sending
it to themselves.
Add hidden USER_HANDLE extra to a handful of broadcasts to make
logic more consistent.
Bug: 26247049, 26219971
Change-Id: I54e4f2e343488571f9baa1a316962f41186c1a2c
/frameworks/base/services/core/java/com/android/server/am/UserController.java
|
| 6ac42aeed905181b484f97a53db57a17134ef7a8 |
|
09-Dec-2015 |
Dianne Hackborn <hackbod@google.com> |
Add a mechanism for broadcasts to control background dispatching.
Right now this is just for the BOOT_COMPLETED broadcast to allow
all apps to receive it.
Also clean up the dumpsys of the broadcast queue to not have
every little detail of ResolveInfo+ActivityInfo+ApplicationInfo,
which is just not useful and makes reading the broadcast queue
debug output a lot harder because of so much noise there is.
And rename the package shell query-intent-* commands to a
shorter query-* form.
Change-Id: I0d01565babb87e68b840c9756a2ea730d699efc7
/frameworks/base/services/core/java/com/android/server/am/UserController.java
|
| b9fe53705ca851c39abe44e980219fd6733bf821 |
|
03-Dec-2015 |
Jeff Sharkey <jsharkey@android.com> |
Attempt to unlock users with null token.
When starting a locked user, try unlocking their storace will a null
token, which will typically succeed if there is an insecure
lockscreen (no PIN or pattern).
For users with a secure lockscreen, pass through a stub token for
now to indicate that it came from a user challenge. Eventually we'll
hook that up to gatekeeperd.
Without this, we were only unlocking users with secure lockscreens.
Bug: 25943941
Change-Id: Ia0324d50f43f55dfe0b8366793ddc5d25d885922
/frameworks/base/services/core/java/com/android/server/am/UserController.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/UserController.java
|
| f23b5d3d6d6d6d72876603c8f72b82d5de022735 |
|
02-Dec-2015 |
Jeff Sharkey <jsharkey@google.com> |
Merge "API to determine user locked/unlocked state."
|
| 0825ab284c01402d030a24471ac5a6491d79d28b |
|
02-Dec-2015 |
Jeff Sharkey <jsharkey@android.com> |
API to determine user locked/unlocked state.
Bug: 25946804
Change-Id: I2b8c8c75fda161a446d79fac811fdd446aa3a4db
/frameworks/base/services/core/java/com/android/server/am/UserController.java
|
| 9cbfc9e212151e84910a22387365644916dde446 |
|
08-Oct-2015 |
Fyodor Kupolov <fkupolov@google.com> |
Added DISALLOW_RUN_IN_BACKGROUND user restriction
It forces the user to stop instead of going into the background. Also
changed behavior of stopUser method. Now it also attempts to stop related
users along with the specified userId.
Based on ag/807976, with the only difference that it's now a user restriction.
Bug: 24579258
Bug: 24708668
Change-Id: I357298908816fc58feeed83b7e9979fc33d25da6
/frameworks/base/services/core/java/com/android/server/am/UserController.java
|
| 8924e8759f9a8cffb5ad538ca40a7826793aac07 |
|
30-Nov-2015 |
Jeff Sharkey <jsharkey@android.com> |
Wire up lifecycle, send unlocked broadcast.
When the correct lock pattern is presented, ask the system to also
unlock credential-encrypted storage, if enabled. The token passed
along is empty for now, but can be wired up to gatekeeper in the
future.
During each system boot, ask vold to lock all users keys to give us
a known starting state. This also has the effect of chmod'ing away
any CE data when in emulation mode.
Define and send a new foreground broadcast when the CE storage is
unlocked for the first time. Add stronger last-ditch checking for
encryption-awareness before starting an app.
Bug: 22358539
Change-Id: Id1f1bece96a2b4e6f061214d565d51c7396ab521
/frameworks/base/services/core/java/com/android/server/am/UserController.java
|
| edcfc1873a4f35c0e4e92fe4f13ff91f0141a779 |
|
24-Nov-2015 |
Suprabh Shukla <suprabh@google.com> |
Merge "Changing the message on user switching dialog."
|
| 4fe508b6d3ceb3c72a79471d3a3a424ffeb71a0a |
|
21-Nov-2015 |
Suprabh Shukla <suprabh@google.com> |
Changing the message on user switching dialog.
On systems where primary user is different from the system user,
the message "Switching to Owner..." is displayed while logging out
from any user. Changing it to "Logging out <username>".
Bug: b/25749937
Change-Id: Id519bbd444c6b3f951511d6e566c503d06c510a1
/frameworks/base/services/core/java/com/android/server/am/UserController.java
|
| ca0ac5c6b245aca55c7b78c0d1e4929ed9ee3ff5 |
|
20-Nov-2015 |
Amith Yamasani <yamasani@google.com> |
Fix missing observer reply callbacks
This was causing upto 2 seconds in user switching delay.
Also switched to using Log.wtf for the timeout message to
track any regressions in this due to new clients.
Bug: 25813588
Change-Id: Icf23b021f134a8ccfa2dae470af02b2da7454acc
/frameworks/base/services/core/java/com/android/server/am/UserController.java
|
| 1fae502824dfb77a109fedd80dad61fe094d8284 |
|
19-Nov-2015 |
Makoto Onuki <omakoto@google.com> |
Merge "More work on layered user restrictions."
|
| 1a2cd74526113b45d9108b6997609122c4311fb1 |
|
16-Nov-2015 |
Makoto Onuki <omakoto@google.com> |
More work on layered user restrictions.
- Now when DO/PO sets a user restriction, DPMS pushes it to UMS and
then UMS persists it, in order for UserManager.hasUserRestriction()
to never have to talk with DPMS, which would cause lock inversion.
- Also apply user restrictions when a user start.
- This is an updated version of the abandoned CL -- the difference
is, ActivityManager no longer has to call DPMS.
- Also removed an unnecessary write to userlist.xml in UMS.
upgradeIfNecessaryLP().
Bug 23902097
Bug 25388912
Bug 25354031
Bug 25641040
Change-Id: I0948aea06ad7d0f45fe612a431d765faddfe3c58
/frameworks/base/services/core/java/com/android/server/am/UserController.java
|
| ba51235ef5c598d845b77fcf14491329493da34f |
|
13-Nov-2015 |
Jeff Sharkey <jsharkey@android.com> |
More file-based encryption work.
Add new "am unlock-user" command so we can trigger changes from the
command line.
Move FBE check to static method so it can safely be called early
during boot before the mount service is ready. Move FBE emulation
to persisted system property, and start reading/writing that value.
Change default permission grants to ignore current encryption-aware
flags, since many of the target apps aren't crypto aware.
Always prepare package data directories, which is how we create the
new "user_de" paths during boot.
Bug: 22358539
Change-Id: I6f58ea2d34b3a466d3775d614f8a13de92272621
/frameworks/base/services/core/java/com/android/server/am/UserController.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/UserController.java
|
| e17ac1569793c333bb4dce86607a342e7c982ae7 |
|
07-Nov-2015 |
Jeff Sharkey <jsharkey@android.com> |
More APIs for encryption-aware apps.
Apps can mark manifest components as being encryption-aware, which
means they can safely be run before the credential encrypted storage
is available.
Start adding filtering logic so that we only return these components
when a user is running "with amnesia." That is to say, only device
encrypted storage is available, so the user is running but with only
partial knowledge of its data.
To avoid calling into ActivityManager with the PackageManager lock
held, we quickly determine user state and splice the state into the
flags for later per-component evaluation.
Bug: 22358539
Change-Id: Idc56ec29f1ef04da8963e004314d7f5e47400997
/frameworks/base/services/core/java/com/android/server/am/UserController.java
|
| f63b89c0a10b4e3220b0a4aa1703be3aed0c5a98 |
|
28-Oct-2015 |
Fyodor Kupolov <fkupolov@google.com> |
UserController refactoring
Addressed comments from the previous cl. Added getters for UserController
fields, direct access is no longer allowed. Moved the following methods:
- getUserManagerLocked. Became getUserManager() - because locking is not
necessary, double checked locking will suffice.
- startUserInForeground /showUserSwitchDialog/sendUserSwitchBroadcastsLocked
- handleIncomingUser/unsafeConvertIncomingUserLocked/isUserRunningLocked/
getUsers/getProfileIds
Bug: 24745840
Change-Id: Id5a5cfb9604e08add29bd9a03c8fe5200bc51fef
/frameworks/base/services/core/java/com/android/server/am/UserController.java
|
| 610acda80a02317080ebaed79b0c1ce26835b8f9 |
|
20-Oct-2015 |
Fyodor Kupolov <fkupolov@google.com> |
Introduced UserController for multi-user functionality
The new helper class encapsulates user life-cycle management, provided by
ActivityManagerService.
Bug: 24745840
Change-Id: I8ebfa38febc4090390d1c45a9fc47398e52693ae
/frameworks/base/services/core/java/com/android/server/am/UserController.java
|