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
We never use this field as a rectangle, we only depend on its left-top
corner. Using a frame is only confusing about the purpose of this field.
Change-Id: I5d6e6321db4fa3203bb7e0f1975ae6ddd1ec09bb
Total duration is the total amount of time an animation takes from
start to finish. It include start delay (if any), child animation
sequence, accounting for repeat.
Change-Id: Id5b36a63c02e25586aefd38612aa5867492e1adb
When multi-thread renderer is used, delay the report to draw to the
first doFrame in ResizeFrameThread. Otherwise we could unfreeze the
window before the frame is drawn.
Also when content draw bounds is updated for the first frame, let
content draw before ResizeFrameThread so that the bounds get applied.
bug: 24715185
Change-Id: I5485dc0be3eae24c555bcc31ee8f71523b68ca8d
Status & nav bars are always visible and opaque when freeform or docked
stack is visible
We still need to refactor the code to allow force opaque to be updated
independently for the status bar and nav. bar. Once that is done, the
status bar should be transcluent if freeform stack is visible and
docked stack isn't and the status bar should be opaque if freeform
& docked stack are both visible.
Bug: 24365214
Change-Id: I48ecc6067c9b0f7239c12c98eb46f3fcefacd4f9
