f3a62fbc58bbc7f081a53248cae48a8951294e8f added support for drawing
the background draweable when resizing an activity window.
However, after some additional discussion we decided that
R.styleable.Window_windowResizingBackground and
R.integer.config_windowResizingBackgroundColorARGB are not needed.
We use R.styleable.Window_windowBackground for the background
drawable and fallback to using R.styleable.Window_windowBackgroundFallback
which is now public if the first isn't set.
Bug: 24534744
Change-Id: Ia0507e25a1893ea941d259f1d4e88ce500dda154
Also enlarges the touch targets for the AM/PM buttons by redirecting
unhandled touches within the containing view group.
Bug: 20257430
Change-Id: I28e8d8894a4702116bb68cc6a6d4115e5aa87a69
Resolver/ChooserActivity sort apps based on usage factors for the last
two weeks. A score of zero means no usage data within that timeframe.
For system health and UI relevance, don't bother even waking up apps
that have zero scores.
Bug 25126166
Change-Id: Iae34a9667eb1985d6fe986670f3fb3f1177576da
This mode turns on after the screen has been off for 15 minutes,
and then cycles through 15 minutes of idle and 1 minute of
maintenance, ragardless of whether the device is moving around.
It currently only impacts network access and sync/job scheduling.
It does not remove access to wake locks or alarms for any apps.
It also doesn't report in the public API that the device is in
idle mode (since it isn't modifying the behavior of the power
manager) -- this is probably what we desire, since we don't want
stuff like GCM to be reporting these frequent changes.
We'll probably at least want to have the alarm manager do some
kind of more aggressive batching of alarms in this most (not allowing
more than one wakeup every minute?). That's for the future.
Also updated batterystats to include this new information, which
means the format of some of the data has changed -- device_idle
is no longer a flag, but an enum of (off, light, full), and there
is no information about time spent in light modes.
Also added new data about the maximum duration spent in both light
and full idle modes, to get a better understanding of how those
are behaving.
And did a little cleanup of DeviceIdleController, removing the
sensing alarm which was redundant with the regular alarm.
Change-Id: Ibeea6659577dc02deff58f048f97fcd9b0223307
An old optimization in ViewRoot prevents updating a window surface
while a window animation is playing. SystemUI and other small system
components that blend these animations disable this for a smoother
experience. Disable it in ResolverActivity as well.
Bug 24989381
Change-Id: Iac7d1c7b1101ed8d2bc4c3557277a773ce871beb
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 8375d639986529969ea5e118de548d29db16ec97.
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
