* commit 'ec1996131d2e17408a22fd55fbc3edba5ea80d02':
Fix surface view on secondary display.
Fix drag and drop surfaces on secondary displays.
Allow a window on a secondary display to have focus.
1. The crash was happening if: two active pointers are performing a drag;
there are some inactive pointers down; the main dragging pointer (we are
merging the dragging pointers into one) goes up; now an inactive pointer
goes up and the explorer tries to inject up for the dragging pointer
which is no longer in the event resulting in a crash. Basically two
problems: inactive pointers were not ignored; 2) having only one
active pointer should not only send the up event but also transition
the explorer in touch exploring state.
bug:6874128
Change-Id: I341fc360ebc074fe3919d5ba3b98ee5cb08dd71e
Required wiring up startActivitiesAsUser()
Bug: 7224950
Also fix a bug in navigateUp in secondary user
Change-Id: I114ae2de0457362d62e899fdb94b12239a3eb778
1. The keyguard force hides some windows when it is shown and as soon
as the keyguard goes away there windows are made visible. However,
the window transition that the keyguard is moving away is reported
before the force hidden windows are shown which makes the screen
magnifier compute the magnified region with an incomplete list of
windows of interest.
bug:7215285
Change-Id: I3abc4d97b7a74de8183ad20477dadf66c82da037
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
