Bug: 30889568
Fixes an issue where mLayer didn't have
the mSurface set on it in certain resume
scenarios.
Change-Id: Ib75065d3d75e6141d6cd8f306584f6a569b9907c
This type behaves like a normal TYPE_APPLICATION, except that WM
will always wait for it to be drawn before starting a transition.
WM always waits for TYPE_BASE_APPLICATION (main window), but for
TYPE_APPLICATION, it only waits if the window relayouts to visible
and gets a surface before the main window is drawn. If main window
itself is ready very fast, transition could start without the other
window.
bug: 30830849
Change-Id: Ife71a9812db7c8eba6ee4ead10ce4f31d9e93b40
As discussed in ag/1192965/ we have a special case for rotation
animation selection in launch from double tap. This was set to
ROTATION_ANIMATION_CROSSFADE as the goal was just to avoid
ROTATION_ANIMATION_ROTATE on the viewfinder surface and
seamless rotation in launch scenarios was initially descoped. Now we
are aiming at fixing this though, and ROTATION_ANIMATION_CROSSFADE
does not quality for seamless rotation. ROTATION_ANIMATION_JUMPCUT
also would not be a good choice because in the situation that the
rotation occurs before the app starting window appears, then we would
jump cut from unrotated wallpaper to rotated app, I think we want
a crossfade in this scenario. To this end introduce and use a new @hide constant
ROTATION_ANIMATION_SEAMLESS which qualifies for seamless but falls back
to CROSSFADE if seamless can't occur.
Bug: 30171992
Change-Id: If1945b17b5159be4cd5ba0b139d6bea9f7fcca33
In Android N, View#isTemporarilyDetached() returns true if it is called
when the same View instance is handling View#onFinishTemporaryDetach().
Returning true there is, however, sometimes confusing, especially
scenarios like the following case:
@Override
public void onFinishTemporaryDetach() {
doSomeRestoringWorks();
}
private void doSomeRestoringWorks() {
doSomething();
}
private doSomething() {
if (isTemporarilyDetached()) {
// As of N, we hit here if this is called as a result of
// View#onFinishTemporaryDetach().
} else {
// but is the logic here is more likely to be appropriate
// when handling View#onFinishTemporaryDetach()?
}
}
What this CL aims to do is to let View#isTemporarilyDetached() return
false when it is called while handling View#onFinishTemporaryDetach(),
because it should make View#onFinishTemporaryDetach() more useful.
Regarding the app compatibility, View#isTemporarilyDetached() was added
in API 24 hence the impact on this change is still limited.
Bug: 30791718
Change-Id: If384da9f9e6ff849598896901626fd021bae5cda
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
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
Prior to N, our widgets were not converting MarginLayoutParams
properly between ViewGroups. The fix intrudced some issues in
older apps as the broken conversion code would hide developer
errors. This CL guards the change with a target API check so
that we don't affect older apps.
Bug: 30378230
Change-Id: I215281d261b553c3b4cedcd29ea0a861df809471
Bug: 30587465
Someday maybe the technology will exist to
allow sharing a simple constant between
Java and C++, but today is not that day.
Change-Id: I17694746cb8712058133cd5ea10c47b9909f740b
