Issue #7211769: Crash dialog from background user has non-working "report"
The report button now launches the issue reporter for the correct user.
Also for crashes on background users, either disable the report button,
or simply don't show the dialog depending on the build config.
Issue #7244492: Bugreport button in Quick Settings doesn't actually do anything
Now they do.
Issue #7226656: second user seeing primary user's apps
I haven't had any success at reproducing this. I have tried to tighten up
the path where we create the user to ensure nothing could cause the
user's applications to be accessed before the user it fully created and thus
make them installed... but I can't convince myself that is the actual problem.
Also tightened up the user switch code to use forground broadcasts for all
of the updates about the switch (since this is really a foreground operation),
added a facility to have BOOT_COMPELTED broadcasts not get launched for
secondary users and use that on a few key system receivers, fixed some debug
output.
Change-Id: Iadf8f8e4878a86def2e495e9d0dc40c4fb347021
Bug: 7252218
Also lock the screen before doing the user switch. This prevents the
janky behavior of showing the target user's homescreen after the switch
and then the lock screen. This is also a privacy issue.
Change-Id: I9f8db047335d06fc93505d7b5cca71e27ca3ac39
Migrate networking, storage, battery, DropBox, and PackageManager
related Secure settings to Global table.
Bug: 7232014, 7231331, 7231198
Change-Id: I772c2a9586a2f708c9db95622477f235064b8f4d
Also tweak bind flags for new location services so they
aren't put so aggressively up in the oom adj list.
Change-Id: I9da25a3fea7681013b4d95b7db7e9a808f2d733b
...Forground Sometimes Doesn't Take
The main change here is a one-liner in ActiveServices to check the
uid when deciding whether to remove an item from mPendingServices.
This could cause the problem being seen -- if the same service for
two users is starting at the same time, the second one would blow
away the pending start of the first one. Unfortunately I have had
trouble reproducing the bug, so I don't know if this is actually
fixing it. It's a bug, anyway.
The reason so much has changed here is because I spread around
logging and printing of the user ID associated with operations and
objects to make it easier to debug these kind of multi-user things.
Also includes some tweaks to the oom manager to allow more background
processes (I have seen many times in logs where we thrash through
processes because the LRU list is too short), plus to compensate an
additional time-based metric for when to get rid of background processes,
plus some new logic to try to help things like Chrome keep around
their service processes.
Change-Id: Icda77fb2a1dd349969e3ff2c8fff0f19b40b31d3
Fixed one setting that was migrated but not marked deprecated.
Removed a hidden setting that is no longer used by the new
power manager service.
Bug: 7231172
Change-Id: I332f020f876a18d519a1a20598a172f1c98036f7
Required wiring up startActivitiesAsUser()
Bug: 7224950
Also fix a bug in navigateUp in secondary user
Change-Id: I114ae2de0457362d62e899fdb94b12239a3eb778
...service com.android.systemui.SystemUIService: java.lang.NullPointerException
- Don't acquire the activity manager lock in handleIncomingUser(),
there is really no need to do so.
- Rework the settings provider client side cache code to not hold
locks while calling into the provider.
I also changed the way the settings provider uses system properties
so that there is one property for all users. We can't do one per
user, since the system property name space is limited with a fixed
size. And we don't really need to do that; the worse that happens
by combining all users is that if one running user changes one of its
settings, all other running users will think they need to reload
settings when they go to fetch them next.
Change-Id: I13b90b832310d117eb6d721aacd122cfba7d749a
Also fix a bunch of system services that should be doing this. And
while doing that, found I needed to fix PendingIntent to evaluate
USER_CURRENT at the point of sending, not creation.
Note that this may end up with us having some notification shown to
non-primary users that lead to settings UI that should only be for
the primary user (such as the vpn notification). I'm not sure what
to do about this, maybe we need a different UI to come up there or
something, but showing the actual notification for those users at
least seems less broken than not telling them at all.
Change-Id: Iffc51e2d7c847e3d05064d292ab93937646a1ab7
Otherwise services like SystemUI will always open content://-style
Uris as USER_OWNER. Surfaces through createPackageContextAsUser()
which points all ContentResolver operations towards a given user.
Start using in RemoteViews, so that Notifications correctly resolve
image Uris to the sending user. Also add user support for "content"
shell tool.
Bug: 7202982
Change-Id: I8cb7fb8a812e825bb0b5833799dba87055ff8699
Keep track of user creation and last logged-in time.
adb shell dumpsys users
User switcher shouldn't show users about to be removed.
No need to check for singleton for activities.
Bug: 7194894
Change-Id: Ic9a59ea5bd544920479e191d1a1e8a77f8b6ddcf
New APIs let you indicate what user(s) to monitor, and tell you
what user is changing when receiving a callback.
Fix package manager to only deliver package brpadcasts to the
running users. (This isn't really a change in behavior, since
the activity manager would not deliver to stopped users anyway).
Make sure all broadcasts that package monitor receives also include
user information for it to use.
Update wallpaper service to (hopefully) now Really Correctly
monitor package changes per user.
Change-Id: Idd952dd274abcaeab452277d9160d1ae62919aa0
Activity manager now updates window manager's current user id
directly and immediately rather than waiting for a broadcast
update. Window manager passes this through policy to the
KeyguardViewMediator and into LockPatternUtils. LockPatternUtils
no longer goes to Activity to get the current user id if it finds
that its local id is non-default.
Fixes bug 7193726.
Change-Id: Id5613e7a9fe9e5b49e83c26b74504f587c3998c2
The way it should have been, and with the new recents enter animation
the way it must be.
Added a new method to retrieve this thumbnail, since it would be less
efficient to use the existing API (which always returns the "base"
thumbnail). Probably at some point that existing API should be tweaked
to always return the top thumbnail instead, but that is for a later time.
Also removed code that would clear the thumbnail associated with an
activity when it is resumed. I don't think there should ever be a
reason to clear a thumbnail -- it's much better to have *something*
for the task, even if it is a little out of date.
Change-Id: I83e6ca6403eb2df5e4de3009dfe8c210e8cf8d5b
The current MTP kernel driver at /dev/mtp_usb is exclusive, meaning
only one process can have it open. In addition, each MTP session
with a desktop requires unique object IDs, which doesn't hold true
across users on the device.
To solve these two issues, when switching users we cycle the USB host
stack to disconnect both local and remote MTP connections, giving the
new user's media process a chance to claim /dev/mtp_usb, and causing
the desktop to initiate a new MTP session.
This change also allows BroadcastReceivers to registerReceiver()
allow retrieval of a current sticky broadcast. Adds a system property
to override maximum users. Removes MOUNTED broadcasts for secondary
users. Allows INTERACT_ACROSS_USERS to getCurrentUser().
Bug: 6925114
Change-Id: I02b4a1b535af95fb2142655887b6d15a8068d18a
Add a new call to the activity manager to tell it when the activity
is resumed, so it can mark its state as dirty then instead of when
it first tries to create it.
Also tweak things to update the LRU list for the upcoming activity
at the point we start pausing the current activity, to avoid an
inefficiency where we may decide to kill the process of the upcoming
activity if it is at the end of the LRU list.
Change-Id: Ia6dc8c34dc6d4b085a1efbe3a5d5f47721d55078
- New public APIs to find out when a user goes to the foreground,
background, and is first initializing.
- New activity manager callback to be involved in the user switch
process, allowing other services to let it know when it is safe
to stop freezing the screen.
- Wallpaper service now implements this to handle its user switch,
telling the activity manager when it is done. (Currently this is
only handling the old wallpaper going away, we need a little more
work to correctly wait for the new wallpaper to get added.)
- Lock screen now implements the callback to do its user switch. It
also now locks itself when this happens, instead of relying on
some other entity making sure it is locked.
- Pre-boot broadcasts now go to all users.
- WallpaperManager now has an API to find out if a named wallpaper is
in use by any users.
Change-Id: I27877aef1d82126c0a1428c3d1861619ee5f8653
