Make sure we don't try to dispatch key events to services
that have died. Doing so crashes the device.
Bug: 30866905
Change-Id: I1cc0515cca8924b0c2744de98ac75a901b94246d
Replaces the display changed listener with a
rotation watcher. The display listener fired
too late and did not produce a rotated frame
in time. Also cleans up logging tags.
Change-Id: I3336275ae123f868ed9ee8cc28a6285a06f2e1a6
Fixes: 30312602
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
Increasing the inactivity timeout to 90 seconds to accomodate the longest
app. demo video for retail. Also, removing the warning dialog by setting
the countdown timeout to 0, so it can be re-enabled by overriding the value
through gservices if needed.
Bug: 30426773
Bug: 30866394
Change-Id: I6735943adfaf3d210ed9eb9163b5c7ce8dcf53ec
In what can only be called an unfortunate workaround we require
seamlessly rotated child windows to have the
TRANSFORM_TO_DISPLAY_INVERSE
flag. Due to limitations in the client API, there is no way for the
client to set this flag in a race free fashion. If we seamlessly rotate
a window which does not have this flag, but then it gains it,
we will have an incorrect visual result (rotated buffer contents). This
means if we want to support seamlessly rotating windows which could gain
this flag, we can't seamlessly rotate windows which don't have it. This
unfortunately limits seamless rotation in N to Camera framework users,
native code, and applications without child windows. This is unfortunate
but having the camera work was always our primary use case, and it's not
as if we are offering an API for it, it's a behind the scenes
enhancement of ROTATION_ANIMATION_JUMPCUT.
Bug: 30171992
Change-Id: I082e323ee569cfc1ff2559657cc22194c251c7ec
Editable TextViews are implicitly selectable. Setting the selectable
property to true however causes a bug where the onTouch logic thinks
the view is not editable and thus doesn't show the IME when clicking
that view.
Change-Id: I9dd6139195bd98b26293e330290650d4e5549a6d
Fixes: 30595718
In case of double tapping from Home, there could be two set of
transitions, first is launcher->Recents, followed shortly by
Recents->app. On the second transition, it should be running
a wallpaper close, but because of the way we pick wallpaper
target, sometimes we pick launcher if both launcher & Recents
are animating away. This makes us to run a different animation
which could involve dimming the wallpaper briefly.
Also, findWallpaperTarget() sometimes could toggle between two
valid wallpaper targets, picking either of them gives correct
result for showing the wallpaper, but could result in different
exit transition.
This change prefers the visible target if there is only one
visible, otherwise the one in opening or closing app list. This
helps maybeUpdateTransitToWallpaper to better choose transition.
bug: 30831873
Change-Id: I0eaa89bdc35f5f51875d5cbeceba11ce40f4791f
The difference between mTopFullscreenOpaqueWindowState != null
and mTopIsFullscreen relates to whether the status bar is animating.
However the flag won't be cleared until the next layout pass following
the animation. As long as the window isn't animating we are fine to
rotate seamlessly. This check was copied from selectRotationAnimationLw.
A little code archaeology implies it was perhaps historical and
introduced before the flag had this meaning.
Bug: 30171992
Change-Id: I326bf7766f8ebe307b833d1ca0c0cdfe80b1eb6c
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
