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
In the case of scaled SurfaceViews with a fixed size.
It is possible for the surface layout size to change
without a change to the surface size or position. In this
case we need to inform the window manager so it can update
frames and scaling. This has presented in Camera and required
workarounds such as changing the fixed surface size to trigger
an update (leading to visual artifacts).
Bug:23974105
Change-Id: I195aa0832907c32874b294101b56e198e853dce5
(cherry picked from commit a8fe43f09c)
In the case of scaled SurfaceViews with a fixed size.
It is possible for the surface layout size to change
without a change to the surface size or position. In this
case we need to inform the window manager so it can update
frames and scaling. This has presented in Camera and required
workarounds such as changing the fixed surface size to trigger
an update (leading to visual artifacts).
Bug:23974105
Change-Id: I195aa0832907c32874b294101b56e198e853dce5
The staged content bounds need to be set by the content renderer
and not by the resize thread.
Bug: 24671393
Change-Id: I8f84ec01a4ac6c1e783cc6208ca77ca6c01ba838
Move add/removeWindowCallbacks to onAttachedToWindow/onDetachedFromWindow.
There might be more than one windows in an app process, the window
callbacks need to be per window, not global.
bug: 24679461
Change-Id: I216ff27b2a41ecfe7399a8161df362bebc0ac96a
A change was made back in ICS that prevents the view hierarchy from rendering
during window animations. Specifically, it allows the hierarchy to render once (to draw
the results of its first layout), but further drawing is suppressed at the
ViewRoot/performTraversals level until the window animation is complete.
This change was introduced to avoid jank problems that were resulting from
thrashing the GPU by issuing drawing commands from multiple processes simultaneously,
and limited the number of rendering processes to mainly the system server (and
possibly the System UI), which allowed window animations to be much smoother.
This fix contributed to another source of jank, however, in which applications
which attempt to animate when they first appear will not render any frames of
animations until the window animation is done, resulting is a snapping to the resulting
state once the window animations are complete.
Meanwhile, hardware has gotten faster and GPUs have gotten better, and it is time to
revisit this logic. This change disables the earlier fix and allows view hierarchies
to draw normally, regardless of whether window animations are taking place.
Issue #22232939 Remove flag that prevents drawing during window animations
Change-Id: I4c960180771ff09a7088abd77b437586e835a991
Whether acitvity window should be preserved during the relaunch is
controlled by the activity manager and the existence of
non-client-decor should not affect it. For example, docked activities
will not have non-client-decor, but we would like to preserve them
anyway.
Bug: 24573657
Change-Id: I5d4852c3b7c26ac3ec1bbc105639f75b67d1d3ad
Using a multi threaded render node to render the window frame
asynchronously from the application relayout.
Bug: 22527834
Bug: 24400680
Bug: 24459827
Bug: 24409773
Bug: 24537510
Change-Id: I1010fc6a8b6e38424178140afa3ca124433ab7e4
The goal is to make this value shareable with Settings code (without
adding dependency on com.android.server)
Change-Id: Ic41af575dcf8081de69bdcdb20fba430bcf3257e
This is achieved by not having the decor view hold onto the activity
context. Instead, we are wrapping application context, so that we can
have theme support and also have a special instance of window manager
that is aware of the phone window (the same way as activity do).
This reverts commit a5ffea3b7d.
Change-Id: I924f4c7ef8f0d20e9174bd7b3e00ec00b44443b9
The only time AppWindowToken.willBeHidden is used is for determining
if the app should contribute to calculating orientation. In the same
check AppWindowToken.hiddenRequested will be or-ed with willBeHiden,
so it's enough that hiddenRequested to be set.
The only place where willBeHidden is set, is right before
WMS.setAppVisibility is called, which will set hiddenRequested.
Because of this willBeHidden is unnecessary.
Change-Id: Iea35f39f72e7f0dcd76205ef580f3a74cac72d08
We don't need intermediate stack traces for re-thrown inflater
exceptions. Yes, we care that you failed to inflate some class.
No, we don't care how many times you recursed in LayoutInflater
before you got there.
Change-Id: Ie9bba7cebab6cdf73ceead49f080dcf23e0a9f25
This means that right-clicking/long pressing on a view that is registered for
context menu will show the context menu as a popup menu instead.
Bug: 20016398
Change-Id: I96fea60435fff2f981d288521f490f8ff24ada15
