Recents to freeform animation must hang on the first frame and inform
Recents to hide its views. This mirrors the transition from freeform
to Recents, where the animation needs to hang on the last frame.
We need a special window flag for recents to force a redraw after the
animation launches. At this point Recents will become not visible
from the perspective of the activity manager, which would prevent
further drawing. We make recents ignore that and instead depend on
window visibility which will change after recents exit animation
finishes.
Bug: 24913782
Change-Id: Ief743b7e6fcebb3d8789d4745fb122ac607c1cf0
Also separates magnification state and touch event handling. Moves
callbacks for window manager changes and display state changes into
the magnification controller.
Bug: 22718911
Change-Id: I3a8ba060a07d8f1f51856855a5f85601766fd45d
Fast rounding doesn't work for negative values, so use Math.round()
where we might encounter negative values. Use Math.floor() and ceil()
for rounding down and up, respectively.
Bug: 25695621
Change-Id: I94831b8eb7552fc24cbe5808e923de1674d8ba6d
As a preparation to fix Bug 25373872, this CL does a mechanical
code clean-ups. Literally there is no behavior change.
Bug: 24504456
Change-Id: I6e3062bda17e748a3c5f1450d6752239dd260520
On some chips, SurfaceControl.setSize will not take effect for several
frames. We have to also do a updateSurface/invalidate (which destroys
and creates the EGLSurface) to get the size right.
Keep track of SurfaceControl size changes in window manager, and pass
that to ViewRootImpl, so that a updateSurface is done either the surface
itself or its size is changed.
Note that we don't use frame size change to trigger updateSurface, because
frame size could be different from the surface size that window manager set.
For example during drag resizing, the surface size is fullscreen although
frame size changes constantly. Doing updateSurface upon frame size change
could cause us to do many unnecessary updateSurface.
bug: 25583942
Change-Id: I1989613a187bb6ef1c179bd2800c6a7b01fcdb3a
Bug: 25411780
Partial-revert for now, reopened b/22565656 to
deal with the memory use in a followup
Change-Id: I1ec636bc811a85eb2dc4f8c91562dc81b6261355
mPendingConfiguration is a parameter of IWindowSession.relayout.
And IWindowSession.aidl declared "out Configuration outConfig",
it will always create a new configuration for remote side to write.
If remote side does not write (WMS does not have config change),
the new default configuration will be returned.
In original code passes mPendingConfiguration to updateConfiguration
directly, then callbacks (sConfigCallbacks) receive the same
instance of mPendingConfiguration. And because the implementation
of callback may use the configuration after relayout has reset
the configuration to default, then it may have timing that results
"showing hybrid of portrait and landscape modes" which try to fix
in commit e36d6e27.
To avoid this, always create a copy to updateConfiguration.
MSG_RESIZED_REPORT from dispatchResized also did the same thing.
Related commit:
e36d6e277e694f79b5d1
Change-Id: Ic1abd596e384918224b3a7020583d9a04641cccc
In the hardware accelerated case, RenderThread needs
to be the authority of information on the geometry of
the SurfaceView (this will occur via moving the
repositionWindow call to RenderThread). In order
to support this we have to enable calling relayoutWindow
without geometry (so that it will not fight with
repositionWindow). Add such a mode to relayoutWindow
and use it from SurfaceView. Add size to repositionChild
while we are here.
Bug: 22802885
Change-Id: Ie45132c22f34cc6ecfe2446912b30bd1df414406
Before, the surface was made full-screen only after
a certain amount of time. Now, immediately make the surface
full-screen, as soon as the divider is touched, to make
resizing much snappier.
Bug: 24507122
Change-Id: I9425785fca4e62964a959a432c80a81d346602c5
When we start a resize with the docked stack divider,
set the surface background to be full-screen, and use
the traditional surface clipping/positioning in window
manager to adjust the size. This ensures that we don't
have any black holes because of asynchronicity (except
at the very beginning, but this can be worked around
later), and the position of the right/bottom activity
is always in sync with the position of the divider.
Also fix a bug in NonClientDecorView where the first
request to draw was dropped (because the thread hasn't
started up yet), and the main thread was waiting for it
indefinitily.
Bug: 24507122
Change-Id: I623bd48d5be64fac2fba45241b84f265944d200d
Move docked divider drawing to SysUI. This let's us have real
time shadows in the future. Keep DockedStackDividerController
for placing/visibility in window manager.
Change-Id: I82c10add626d30f2ba180ee2a21cdbe6ddfe0371
Because we retain activity surfaces now, the app transition specs
which were calculated/generated after the onPause() call when going
from recents -> app were too slow. Instead, supply a cross-process
future, which gets fetched when the window manager is about to be
ready to execute the app transition. In practice, this still gets
executed immediately after the onPause call.
If we have a retained surface, this adds some latency, but since we
absolutely need the specs to execute the transition, we have that
latency no matter where exactly we generate the specs.
If we don't have a retained surface, the specs are not calculated on
the critical path, so it's faster.
Bug: 19940527
Change-Id: I80d2c6f6b3a6568a70339619ecefbc3bd8409bd8
Bug 24873983
Focus follows top->bottom left->right by default (LTR),
but that could put next focus on a View in the middle
of a focus chain (something else points to the View with
nextFocusForwardId). That means that the View pointing
to it may get skipped or it may end in a focus loop
in the chain.
Instead, we now prefer to have the next view be one that
is at the head of a chain (forward) or tail of a chain
(backward).
Change-Id: Icb59f01c1406bc89ef3494fdc5be109e465aa8bc
When maximizing the transition should originate from visible bounds, so
the first frame matches what is visible to the user. When switching to
the big surface, we only need to increase the layer by one, instead of
having artificially large value. If we use the large value, it will
cause a flicker over system windows.
Also includes some cleanup, like static imports and necessary logging.
Bug: 24913915
Change-Id: I84d7594622aa639e2008c662f941edf9c20b3202
In the hardware accelerated case, RenderThread needs
to be the authority of information on the geometry of
the SurfaceView (this will occur via moving the
repositionWindow call to RenderThread). In order
to support this we have to enable calling relayoutWindow
without geometry (so that it will not fight with
repositionWindow). Add such a mode to relayoutWindow
and use it from SurfaceView. Add size to repositionChild
while we are here.
Change-Id: I12f85f586a38bf86367f3d964cb49f19003d441f
We achieve the desired result by prolonging the last frame of the
animation until recents tells that it drew its content. The CL also
includes cleanup that moves code that depends heavily on WindowState
fields into that class.
Bug: 24913782
Change-Id: I5ee5b18504dd4a86c24033d17eca21cd31936bca
Adding performLongClick(x,y) broke compatibility for widgets that
overrode the no-arg performLongClick() and expected to receive a call.
This CL ensures that the no-arg method is called and the (x,y) data is
preserved for use in the default implementation.
Bug: 25411884
Change-Id: Ib0a3fb02d4c08ef64ce3a7165aa83bf0688aa50e
Helps make the code easier to follow since we are no longer checking
multiple stack ids at various decision points.
Bug: 25282299
Change-Id: Ifa6864a1ef56ce2eca4c94f87a4e0b993de987cd
In order to provide pixel perfect movement of SurfaceViews
'within' other views (e.g. scrolling) we need to be able to
synchronize the attached (parent window) painting with the
movement of the SurfaceView (recall, SurfaceViews are positioned
behind their attached windows and the parent must render a
transparent region for the SurfaceView to appear). Provide
a new WindowManager method to reposition an attaching window
(that is to say, a window which has an attached window like
SurfaceView) and defer the transaction until the parent frame.
SurfaceView is hooked up to use this for movement. This is still
'racy' in the hardware accelerated case as the render thread
could be on either side of dequeing the frame we are working on.
Bug: 22802885
Change-Id: I025d2bdcbe15c1c11047cc0dbca2cf2b7d67c632
Doing this while dragging is really necessary for System UI shelf.
Also, not forgetting to remove the child from the "interested" set when
the child is removed.
Bug: 25231591
Change-Id: I26f5086a0a842868b2d7e9809f7483152098f314
(cherry picked from commit a82c8709f0914064f4b00262f1d411594bab467f)
Add a Window API for setting a view which will be placed in
the decoration area (next to the window control buttons).
Change-Id: Ie106cbea653ff95fdba987a2a43506d394600612
Also shows anchored menu on D-Pad long press and uses the center of the
view as the anchor point. This is how we already handle hotspot feedback
when there is no explicit center, so there's no visual change there; it's
just more obvious from the View side of things what the result will be.
Bug: 25215353
Change-Id: I930c3aeffc993b7c553ffb626d1b5103c6cb1267
returns partially cached windows list.
It could happen that AccessibilityWindowInfo cache is
cleared. And after that calling
AccessibilityInteractionClient.getWindow(windowId)
would add that window to cache. And while cache is
not empty after that AccessibilityInteractionClient
returns its content on getWindows() request even
if it does not contain all windows.
Change-Id: I70dc96d50e3368285fd482a98769a93ae2c15f22
