R.styleable.Window_windowResizingBackground allows an activity to
specify the background drawable that should be used when it is being
resized in multi-window mode. If unset, the system will try to use
R.styleable.Window_windowBackground if set, then
R.styleable.Window_windowBackgroundFallback if set. Otherwise, the
system default resizing background color set by
R.integer.config_windowResizingBackgroundColorARGB.
Also, use decor title color as caption background color when resizing
instead of black.
Bug: 24534744
Change-Id: I83313865b4044b976ebc78d598e14e17e0f37212
An initial sorting step before applying modifiers to the ChooserTarget
scores provided by apps was backwards, causing subsequent target
scores to be heavily penalized. Targets are then heavily influenced by
the lowest score in the set relative to the targets from other apps.
Bug 25013559
Change-Id: I39d5d7c601712fc6a19e694d5846d2c8d17a214f
The SystemUI visibility listener in DecorView
gets called between the measure and layout passes
and is therefore not allowed to change layout parameters.
This change makes sure that changes to the color view
layout parameters are applied eagerly when the insets
change instead of waiting for the views to become visible.
Bug: 24614374
Change-Id: If9df18f582163d0869c28a852c36697b1ce50621
We are dropping CAP_BLOCK_SUSPEND since that prevents correct suspension in
Chrome OS. This change makes it so that it only requests that capability if it
is not running inside a container.
TEST=Android boots correctly
BUG:24952794
(cherry picked from commit 5e38447a9bf81bb7d58d33c71498495e1e0f575f)
(cherry picked from commit dc3943951ee475ef09cc7a4825368f9b707e1344)
Change-Id: If39357f22955442d5532d1408ce74360384521bb
* Wait to start animations until all state has been initialized, as
the process of starting an Animator will set initial values,
triggering other events relying on the configured state.
* Correctly track underlying item indexes for columns.
* Do not over-extend the ResolverDrawerLayout when multiple rows
animate in.
Bug 24926885
Bug 24928706
Change-Id: I4772e1a0ba79b17b5dc19c778f3ef0cb5200c533
Freeform window surfaces are translucent because most of the time they
have shadows. During a resize we stop displaying the shadow, which
might change the surface opacity from translucent to opaque. This change
only happens if the activity gets recreated during the resize, as this
triggers recalculation of the necessary opacity. If configuration change
happens the relayout will now contain new, opaque pixel format and cause
the recreation. The second blink will happen after we finish resizing,
as the surface needs to become translucent again.
Bug: 24668341
Change-Id: I450323276c49f176f0f6dfb3b21a5f6d742a8418
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
Currently required for apps like recents to resize correctly
with the 2-render thread approach. Eventually we will want to
separate the functionality from the non-client-decor.
Bug: 24742523
Bug: 24810450
Change-Id: Id241bf8fe47dd8c4ec570c90149c859c45aa6285
Introduced some regressions. Reverting until we can do better testing.
This reverts commit 8375d63998.
Change-Id: I9b15d63e52c814ef8985b86f8a50359e39355d39
Prevents multiple-threads from accessing/changing member variables at
the same time that can lead to the app crashing.
Also, setName on ResizeFrameThread so we can easily find it in systrace.
Bug: 24745288
Change-Id: Ic2fc7d661db5360c13314197c40e8b2315d2b7e5
When activity doesn't have a non client decor view but we preserve its
windows, we need to remove the children directly from the decor view
instead.
Bug: 24750271
Change-Id: I50e83ef61deba92e668ee165c4a297547a56071f
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
Bundles cascading menu information and stores it in a stack representing
the hierarchy of added menus.
Bug: 23970448
Change-Id: Icc0a96ea2dd4320fd4dae9626435ed82a6165480
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
It is possible that while a config change is going on, the
view hiererchy got created but not layouted. In that case
the reported size of the main window would be 0,0. In this
event we need to use the cached window sizes from the past
render.
Bug: 24595899
Change-Id: Ia41f7ae0999e4f2bda364506029bcbdfd7d3f4b4
Dejank the process of bringing in new ChooserTargets from queried
services. Animate the service target rows in upward so that if the
user's finger is already headed for a visible choice we don't inject
something wrong right under them at the last second. Keep things sane
if the user is dragging the UI while we're bringing in new items.
To animate this, since we can't use RecyclerView from the framework we
treat the height of rows as a conceptual data set change for
ListView. To get away with doing this per-frame we pre-measure the
item height (which remains constant) instead of doing more expensive
wrap_content calculations. ResolverDrawerLayout is now aware of how to
account for a cheat-measured ListView to compensate.
Bug 24038066
Change-Id: I01414a5746815255ff948a6d0887bb5ad0897285
Dejank the process of bringing in new ChooserTargets from queried
services. Animate the service target rows in upward so that if the
user's finger is already headed for a visible choice we don't inject
something wrong right under them at the last second. Keep things sane
if the user is dragging the UI while we're bringing in new items.
To animate this, since we can't use RecyclerView from the framework we
treat the height of rows as a conceptual data set change for
ListView. To get away with doing this per-frame we pre-measure the
item height (which remains constant) instead of doing more expensive
wrap_content calculations. ResolverDrawerLayout is now aware of how to
account for a cheat-measured ListView to compensate.
Bug 24038066
Change-Id: I01414a5746815255ff948a6d0887bb5ad0897285
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
