1. If there is a non-speaking accessibility service installed and the
global gesture is performed an exception is thrown since an attempt
is made to modify the list with services returned by the accessibility
manager (to remove the non-speaking ones) but this list is immutable.
Now the returned services are put into a mutable list before removing
the non-speaking ones.
bug:7280996
Change-Id: I2852a3e169c1d34d942b50fb439e0961394c92bc
-> When user is switched, we immediately show their security, if present
-> If a user taps on the active user, it shows the glow pad unlock hint
Change-Id: I074ed63123a6bc6a38051cb77b5d86bd3f0e93ea
This fixes a performance issue on the 7" tablet where disabling hardware
layers in landscape mode resulted in extremely bad drawing performance.
The code now enables hardware layers for all the widgets while the user
is dragging.
Fixes bug 7274971
Change-Id: Iafd18fb317fcd3caad45791fe5a0f111d40a1ed4
Since the new PowerManager changes are in, keyguard needs to handle
keeping the screen awake. This change does this in a few places in
addition to the existing security screens:
- when the widget page changes
- when the user interacts with any widget other than the status widget
- when the user taps on the target in the selector screen
Fixes bug 7273646
Change-Id: If4c76a38e9b886dd359ba96cd2aae03652007b66
-> Updated user switcher to be closer to spec (issue 7047393)
-> Drawing keyguard overscroll gradient manually in KeyguardWidgetFrame
(eliminates need for assets, eliminates banding)
-> Fixed clipping of overscroll on sw600dp using negative margin
Change-Id: I90ec7f820ca7dccebf7e05628a3185e95d41af08
This attempts to fix a bug where the transport control would sometimes be
inoperative. The problem is that we had two transport control layouts
on some devices because they were being declared in the layout file.
The fix is to only inflate the layout once when KeyguardHostView
is created.
Also removes redundant KeyguardStatusView.
Fixes bug 7254833
Change-Id: Iab84e8326ff745ee57be5177ab2561114c8dc6f0
Includes telephony, WindowManager, PackageManager, and debugging
settings. Update API to point towards moved values.
Bug: 7231764, 7231252, 7231156
Change-Id: I5828747205708872f19f83a5bc821ed0a801cb79
Sending the unmasked soft input mode int setAttachedWindowFrames
included the SOFT_INPUT_STATE bits and guaranteed that the adjust
test would always pass.
Bug 7256294
Change-Id: Iaf5368432c7b350fe70687d08c0a08e814b35e94
-> Showing correct page, as per discussions (issue 7205431)
-> Hide the time when the system status widget is showsing (issue 7216577)
Change-Id: I5b79d72e8fd8226952f6a8ea99b776feb4ddde1f
When there are multiple activities that respond to MediaStore.INTENT_ACTION_STILL_IMAGE_CAMERA_SECURE
we need to show the disambiguation dialog to the user. However the disambiguation "dialog"
is actully an activity themed as a dialog. Hence, we can't show it in the secure keyguard.
This works around the issue by prompting the user for their credentials directly when the
intent needs disambiguation. This will take them out of keyguard and prompt them for
which activity they want to use.
We'll provide a more robust solution in a future release.
Fixes bug 7109816
Change-Id: I94e643d3cb503e1ce6de24c82400b4d5fcbb9d95
This now replaces the internal user activity timer that
keyguard maintained. We can probably simplify things a great
deal further now.
Bug: 7165399
Change-Id: Ia0d5a156a4ff0c339bbd094380b9f7ab3cec5d9b
- new flow for PUK screen
- clean up SIM and PUK screen to match UX designs
- simplified logic for showing emergency call button
Change-Id: I66fcd312f3c52dd212d9836dc020735dbc88d5ee
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
The hide call delays removal of mKeyguardView but the inflate call
occurred before the delay expired. The method inflateKeyguardView
would have removed it except hide() also nulled out mKeyguardView.
Consequently there were two KeyguardHostViews in the view hierarchy.
The findViewById returned the first view which got the callback
assigned. Later that view was removed from the hierarchy and when
the new view was called it had no callback assigned => NPE!
This fix removes the KeyguardHostView from the mKeyguardHost by
referncing the id rather than the null mKeyguardView.
Fixes bug 7250008.
Change-Id: Ic9da3415d72187628f06271c12d5184f9d01059b
Some monkey tests could hit a case where a posted overflow button
click event was still lingering after the menu was no longer in a
created state, which could lead apps to crash. Just drop open-overflow
requests on the floor if the menu is in a weird state when we try.
Bug 7242431
Change-Id: Ieebb1fccfeeccbf17fd7c6cff06efbcb19b11ce3
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
This reverts commit 4bd149ef83c8e3e2ffb61885e71f44df9a9ccfa7
This change introduced a regression in the device rotation policy. Suppose you hold the device in landscape orientation then put it flat on a table. At this time, the accelerometer has no information about which way the device is oriented so the sensor expresses no preference over the orientation. Now switch to an application that forces portrait. Then go back to the original app that auto-rotates. We should remain portrait from this point onwards unless the device is picked up and we have accelerometer information from which to establish a new preferred orientation.
Bug: 7173556
Change-Id: I3684af3369e4ea55042081e19d96773c4d4bbe76
