This new setting allows users to set a scale factor for the
duration and startDelay of all Animator-based animations. This
setting is very similar to the Transition animation scale and
Window animation scale settings, except this one applies specifically
to Animator animations. The property is only accessible by users
through the Settings UI, not programmatically. The value applies
system-wide and is picked up per-process at the time of the first
ValueAnimator construction.
This is an update to a previous CL; this approach uses the WindowManager
to store the animator scale settings, instead of SystemProperties.
Change-Id: I8295fab060aa6d597ae507ded8f9c9d6077be966
Some apps have managed to hit this edge case in monkey runs. In
layoutChildren an attempt to findFocus() fails when items are
focusable. When ListView attempts to restore focus to this view,
bad things happen.
Change-Id: Ie8bb1bab847898e342c16fbe3ff1a6153d6f69df
This really shouldn't have been here to begin with, since the wrapper version
should be meaningless to libRS.
Change-Id: I329446ed96d1a70197247735e267b8539a8c83a2
The render threat is likely to break your application if you initiate it.
As such it must be explicitely requested using the following meta-data
tag in your manifest's application tag:
<meta-data android:name="android.graphics.renderThread" android:value="true" />
Change-Id: Ibf0a48af2a0d091562bf6907eac970e3d1d601c4
This new setting allows users to set a scale factor for the
duration and startDelay of all Animator-based animations. This
setting is very similar to the Transition animation scale and
Window animation scale settings, except this one applies specifically
to Animator animations. The property is only accessible by users
through the Settings UI, not programmatically. The value applies
system-wide and is picked up per-process at the time of the first
ValueAnimator construction.
Change-Id: I3d5fbc956695c88d01c30820259da3e107ffd8a3
Before now, receiving a broadcast would cause a process to be hoisted
to foreground priority / cgroup. This is no longer the case: broadcasts
by default are handled in the background, with a suitably increased
timeout interval. When a given broadcast needs to be dealt with in a
more timely manner, the issuer can set the new FLAG_BROADCAST_FOREGROUND
flag on the Intent, which will produce the old foreground-priority
behavior.
To avoid priority inversions, foreground broadcasts are tracked on a
separate outgoing queue and can be in flight simultaneously with a
background-priority broadcast. If there is already a background-level
broadcast in flight to a given app and then a foreground-level one is
dispatched to that app, the app [and its handling of both broadcasts]
will be properly hoisted to foreground priority.
This change is also essentially the first step towards refactoring the
broadcast-handling portions of the Activity Manager into a more
independent existence. Making BroadcastQueue a top-level class and
regularizing its operation viz the primary Activity Manager operation
is the next step.
Change-Id: If1be33156dc22dcce318edbb5846b08df8e7bed5
