Bug: 7255777
Bug: 7263657
When userId is neither CURRENT nor ALL, the correct list of receivers
was not being built, due to a typo in ActivityManagerService;
Change-Id: Ib1dc627f0dbd1c91d02c718d2e4d2384ad687d1f
This takes the easy way around notifying the correct users
about GPS state transitions by notifying ALL the users(!).
I've also laid groundwork for proper multiuser support in
LocationManager and did a tiny bit of cleanup in
GpsNetInitiatedHandler while I was looking at notifications.
Bug: 7213552
Change-Id: I2d6dc65c459e55d110ac0f5f79ae7a87ad638ede
Headsets are now detected from calls coming in from the input switch
subsystem if a config.xml value is set to true.
Bug: 6548391.
Change-Id: I79259d2742e157b106a746474f32ffd1c171ddf3
...#testScreenLayout failures on JO
This doesn't actually fix it; I have concluded that the test is broken
(the platform is correctly reporting that this is a NOT LONG device
because in portrait once you account for the status bar and system
bar our size is 880dp high and 600dp wide, which is not enough for us
to be in the LONG config).
However while working on this I noticed that the code for computing
the configuration of the external display was wrong. I have fixed
that by putting this code for computing these parts of the configuration
in a common place that both the window manager and external display
code can use.
Change-Id: Ic6a84b955e9ec345a87f725203a29e4712dac0ad
1. A recently added check was preventing touch exploration being
disabled when the last touch exploring service was turned off.
As a consequence enabling explore by touch was initializing the
input filter with the magnification and the not disabled
screen magnification features.
bug:7256223
Change-Id: I9ed5457705d625805462e4d316b2c8a5af9aabca
1. In explore-by-touch when the user slides two fingers in the same
direction we consider it a drag gesture. We merge the pointers into
one and deliver a touch event. When one of the pointers goes up
we were transitioning into touch exploring state. This means that
were transitioning to another state in the middle of a gesture which
creates complications and leads for interaction end event not being
sent.
This change transitions out of dragging state when all pointers go up
- simple and all events are properly sent. Consequentially, staring a
drag the user has to lift all pointers to touch explore. Since usually
users either drags or touch explores this seems the simplest and
*least risky* fix.
bug:7253731
Change-Id: Ie8588fbe9b26cb81312bd7fd377c94732e41e3f8
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
1. The touch explorer is relying on the hover exit accessibility event to be sent
from the app's view tree before sending the exploration end and last touch
accessibility events. However, if the app is buggy and does not send the hover
exit event, then the interaction ending events are never sent. Now there is a
timeout in which we wait for the hover exit accessibility event before sending
the gesture end and last touch accessibility events. Hence, we are making a
best effort to have a consistent event stream.
2. Sneaking in the new nine patch for the border around the magnified region
since the current one is engineering art.
bug:7233616
Change-Id: Ie64f23659c25ab914565d50537b9a82bdc6a44a0
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
1. The problem is that we have a gesture detection timeout after which we transition
to touch exploration state. This handles the case where the user is using too high
velocity while trying to touch explore. The delayed command that transitions from
gesture detection state to touch exploration state was not firing an event for the
end of gesture detection and begin of touch exploration before doing its main work
to transition to touch exploring state.
bug:7233819
Change-Id: I5c4855231aa3826dadbee324e74a3c9e52c96cd9
1. If an accessibility service does not specify that it handles any
event types it was never added to the list of services while
the system is bound to it. Since the service is not in the list
with enabled services we never unbind it, hence it consumes
resources without doing nothing. This is also semantically
incorrect because a sevice may not want to receive events while
handling only gestures.
bug:5648345
Change-Id: Id478a4704cdeeb1729330f6ae4b8ff9e06320952
1. This change adds a global gesture for enabling accessibility.
To enable this gesture the user has to allow it from the
accessibility settings or use the setup wizard to enable
accessibility. When the global gesture is enabled the user
can long press on power to bring the global actions dialog
and then hold with two fingers for a few seconds to enable
accessibility. The appropriate feedback is also provided.
2. The global gesture is writing directly into the settings for
the current user if performed when the keyguard is not on. If
the keygaurd is on and the current user has no accessibility
enabled, the gesture will temporary enable accessibility
for the current user, i.e. no settings are changed, to allow
the blind user to log into his account. As soon as a user
switch happens the new user settings are inherited. If no
user change happens after temporary enabling accessibility
the temporary changes will be undone when the keyguard goes
away and the device will works as expected by the current user.
bug:6171929
3. The initialization code for the owner was not executed due
to a redundant check, thus putting the accessibility layer in
an inconsistent state which breaks pretty much everything.
bug:7240414
Change-Id: Ie7d7aba80f5867b7f88d5893b848b53fb02a7537
