When fetching system services early during boot, if the underlying
binder interface hasn't been published yet, we end up caching a
manager class that is broken for the remainder of the process
lifetime, and innocent downstream callers end up using the broken
cached manager.
Fix this by using an explicit exception to quickly abort manager
creation when the underlying binder is missing. The exception is
only used to skip the remainder of the manager creation, and it
doesn't actually crash the process.
Bug: 28634953
Change-Id: I0cb62261e6d6833660704b93a11185aa11a2ac97
Bug: 30442298
We already do this for initialize(), fix
it so that update() is parallel with the
UI thread as well.
Shaves ~7ms off of the 99th percentile on
NotificationShade open & close
Change-Id: I1791df495453fb9e1e12362c68e3d20e837e62be
Make UserSwitcherController subclassable
Add ability for keyguard to animate in without a screen freeze
by adding a keyguardAnimatingIn state that WindowAnimator and
WallpaperController can use to prevent graphical glitches
Bug: 29329555
Change-Id: Idfd40156538b4bfb1777ad1a9a566e7da54e8f32
Given config_customUserSwitchUi, AM/UserController will not show any
UI during user-switch (no dialog or screen-freeze).
Provides a mechanism (WM.setSwitchingUser) by which a custom user-switch
UI can notify WM/Keyguard when it expects a user-switch operation to
be running.
Bug: 29329555
Change-Id: Ic903fc251d7ec3a54bc6a77906d3afa45a6a5fac
Add code to adjustWindowLw to force the flag
FLAG_NOT_FOCUSABLE to be set for layer type
TYPE_SCREENSHOT.
Bug: 30485483
Change-Id: I11725eb89fda59b6d50fa1700845cdfe9ffb930b
This CL fixes an edge case that my previous CL [1] forgot to handle.
The goal of my previous CL was to avoid InputMethodManager from getting
confused by a false focus-in event from temporarily detached Views.
However, my CL forgot to take care of the case where the temporarily
detached View is still focused even after the temporary detach mode is
done.
The bad news is that such a situation is relatively easy to trigger by
having a ListView that has EditText as follows, which seems to be
known to be a common technique in Android developer community to put an
EditText in a ListView.
ListView#listView.addHeaderView(new EditText(context), null, true);
If the ListView is initialized as above, and the EditText has input
focus, View focus and IME focus start to disagree immediatelly after the
ListView's layout is re-evaluated. This is really easy to trigger, for
example just by dismissing the IME window.
In summary, the root cause is that InputMethodManager#focusIn(View) is
now always ignored as long as the View is temporarily detached, under an
assumption that IMM#focusIn(View) will be called back again with a View
that is not temporarily detached when everything is stable. Hence the
fix is to do so by hooking up View#dispatchFinishTemporaryDetach() to
call IMM#focusIn(View) again when the View is actually focused in the
final state.
[1]: Ia79bbd8468f768d546354382b47b39dd31ef7bb5
a4ed0cfcb6
Bug: 30022872
Bug: 30578745
Bug: 30706985
Change-Id: Iecbdb00dcef8c72e4f7b31035c9bf0f4a40a578f
- Adds a trusted signal from Keyguard to PhoneWindowManager
- Allows PhoneWindowManager to exempt DISMISS_KEYGUARD windows from force hiding
- Allows PhoneWindowManager to dismiss Keyguard while occluded
Bug: 27410215
Change-Id: I3ad490b64a5805b6f3888a9f37fcfbdd0116395e
Adds "panic" detection to the back button. Implemented solution
uses 4x button presses in a short duration to detect for "panic".
The value used to determine the duration between key up and key down
that still count as a multi-button press is configurable via the
Settings Provider.
BUG: 28027764
Change-Id: Ibf1370ff3cb539a9a54002a8704922744a3ca5d7
