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
This will be used for window divider (for multi-window mode).
See I40443356f9151f8a8024f6a62517dd74e68fce41
Bug: 24415739
Change-Id: If1cd34cc5253c9f8a50decba90498001093a9db7
EXIT event does not have to udpate the pointer icon shape, because
when it immediately moves to another window, its HOVER_ENTER will
handle the icon shape.
Also HOVER_EXIT can happen after the HOVER_ENTER of the new window,
and in that case updating pointer icon at HOVER_EXIT will overwrite
the pointer icon for the new window.
Bug: 24415739
Change-Id: I08fc72cc69bbc3a6eef36d501d93e8e9ad36df85
With the original logic, if an app creates a system window, when the
user goes to home screen, the system window will be still there and
become unable to receive input events, because the system window will
be also changed to the stopped state with the app window, and the
current logic of ViewRootImpl forbid a stopped window receiving input
events.
This change prevents assigning the token of the app window to system
windows created by the app, so that when the app goes to the stopped
state, its system windows won't be affected (can still receive input
events).
This change is related to the following changes:
a5d29971f815ed2754a3c3672cd3f741725dedc3
Bug:
https://code.google.com/p/android/issues/detail?id=189710
Change-Id: I515e47bafcf39a2b1bdf92f11f623bef8fb6263c
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.
Change-Id: Ic33915043380ab8cd9eb4920e224b35234ed867d
Right now, it only supports I-beam on EditText, but further
rules will come in the future.
The png files for the icons are from chromium.
Bug: 24180385
Change-Id: I8de4ec8a5412b4830c08aa232c5083841c5c751c
