Required wiring up startActivitiesAsUser()
Bug: 7224950
Also fix a bug in navigateUp in secondary user
Change-Id: I114ae2de0457362d62e899fdb94b12239a3eb778
If any window on the default display has focus, then it
gets focus as usual. If no window on the default display
has focus, then we consider windows on the secondary display.
In the future we will need more elaborate schemes for
managing focus across multiple displays, but this is enough
for testing purposes now.
Bug: 7183618
Change-Id: I21ddb9904eb9e574e42d28743aeca51f4ffebf64
...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
1. Since adb is restarted on user switch it makes no sense to
try to reconnect the ui automation service since it will
be killed on a user switch.
Disabling touch exploration on UI automation service
connect since it can explicitly put the device in this
state if needed.
bug:6967373
Change-Id: I8cfde74f28f3f03d4ccf24746d43b8178ae2b5ef
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
The worst case WPS timeout for GO negotiation is two minutes.
Until, we better handle cancelling/disconnecting and re-syncing the
WFD framework with the wifi direct framework/supplicant, increase
the time out to 60s to help with dogfood
Bug: 7217600
Change-Id: I1ba0d9963b957454e2c6f47bfdf05176dea07be7
When PackageManagerService deals with external storage, always bind
to DefaultContainerService as USER_OWNER. This avoids binding to a
stopped user, which would fail.
Bug: 7203111
Change-Id: I8e303c7558e8b5cbe4fea0acc9a472b598df0caa
This restores MR0's behavior in this regard - apps calling
LocationManager.getProviders() or LocationManager.getBestProvider()
will no longer receive a SecurityException if they do not have
any location permissions. Instead, as was the behavior in MR0, they
only receive providers that their permissions grant them access to,
including an empty list if they have no permission whatsoever.
Bug: 7207864
Change-Id: I027df425e258d436c4821c34a25bc46a2a292824
Issue #7209355: Intent on the secondary user results in an intent picker
in the Primary user.
Issue #7214271: Crash in system UI
Also fix a bug where I recently broke the removeTask() operation in the
activity manager where it would remove the wrong task.
Change-Id: I448c73a0e83a78d9d8d96b4629658c169888d275
Since SettingsProvider can call back into PMS, query the default
enforcement state before acquiring mPackages lock.
Bug: 7182437
Change-Id: Ie218aedfc7a943e5b221814af3e0356c7199b0e4
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
Also shows the owner info and next alarm for the current user.
AppWidgetService now assumes that any widgets running in the system process are for the
current user, so that lockscreen shows widgets for the current user
Bug: 7211754
Bug: 7212421
Change-Id: Iaf0edc60e49af0afe42625c0b2dcf100c9ecc178
1. This change converts the accessibility manager service to
maintain a state per user. When the user changes the services
for the user that is going away are disconnected, the local
accessibility managers in the processes for this user are
disabled, the state is swapped with the new user's one, and
the new user state is refreshed.
This change updates all calls into the system to use their
user specific versions when applicable. For example, regisetring
content observers, package monitors, calls into other system
services, etc.
There are some components that are shared across users such
as UI created by the system process and the SystemUI package.
Such components are managed as a global state shared across
all users and are updated accordingly on a user switch. Since
the SystemUI is running in a normal app process this change
adds hidden APIs on the local window manager to allow the
SystemUI to notify the accessibility layer that it will run
accross users.
Calls to AccessibiltyManager's isEnabled(), isTouchExplorationEnabled()
and sendAccessibilityEvent return false or a are a nop for a
background user sice he should not send accessibility events,
and should not perform touch exploration.
Update the internal accessibility tests due to changes in the
AccessibilityManager.
This change also fixes several issues that were encountered
such as calling out the accessibility manager service with a
lock held.
Removed some incorrect debugging code from the TouchExplorer
that was leading to a system crash.
bug:6967373
Change-Id: I2cf32ffdee1d827a8197ae4ce717dc0ff798b259
FusionEngine now attaches a secondary location that has never seen
GPS data to its result. LocationFudger uses the GPS-less location so
that COARSE apps never see data from the GPS provider.
When the previous location is updated, the previous GPS-less location
is carried over if the location update was GPS-only.
Additionally, apps without FINE permission are not notified when GPS
location changes, and any attempt to use GPS_PROVIDER without FINE
permission is met by a stern SecurityException.
Bug: 7153659
Change-Id: I12f26725782892038ce1133561e1908d91378a4a
