Introduce second snooze timestamp to support dismissal of data usage
warning notification. Also explicitly set notification "when" to
avoid fighting with other notifications, such as ongoing downloads.
Bug: 5443756, 5262414
Change-Id: I03342c25b0410b1b2db84de9a40884f04cb1d8ae
This fixes a regression caused by making the lock screen window slippery where
dragging the target over the system bar would incorrectly cause it to
snap to an invisible target. It now interprets MotionEvent.ACTION_CANCEL
the same as an "up" event and resets to the initial state.
Change-Id: I9a3c195371d64e1a4613f6f1fb0a043e9a47a601
LayoutTransition side-effects the alpha property on View to fade views
in and out. This works fine if the layout transition is always used on
those views' container. But if you fade out a disappearing view and then
set the transition to null on the container and set that view to VISIBLE,
there is no transition logic to restore the alpha value to 1 (opaque).
The fix is to always restore alpha to its pre-animation value when fading
the view out.
Also, added extra info to alpha and the various View transform properties
to help hierarchyviewer debugging.
Issue #5958434: LayoutTransition temporary disablement may leave some views invisible
Change-Id: I3c21b0e7334dc29c10c5e372b589f0e2b59c2883
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
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
In our current environment with very many translations, this can
save a lot of RAM -- for example over 200K in Gmail just by sorting
the strings in the Gmail .apk (not the framework).
Also add a new aapt command to print the contents of the resource
table string pool.
Change-Id: I1da037b3e2c377b890833ff57ab158965314ac48
Users have requested the ability to sequence ViewPropertyAnimator
animations. it is not possible with AnimatorSet, which only takes objects
of type Animator (which VPA does not extend). But the AnimatorSet model
is not appropriate for VPA anyway, since it is not possible to set up
a VPA ahead of time to start later; it's just not the way that VPA is
intended to work.
Instead, there are now two new methods on VPA, onStart() and onEnd(). These
methods take a Runnable which is executed when the animation starts or ends.
These methods should allow other VPAs or other arbitrary code to execute at the
start or finish of any particular VPA animation, allowing simple sequencing
without the overhead of creating listeners and monitoring the cancelation status
of the VPA.
Additionally, this change adds a new method withLayer() which sets a hardware
layer on the VPA's target view for the duration of the animation. This
was already possible, but required writing boilerplate code to create a listener
and override the start/end methods to add and remove the layer. This utility method
makes this common use case much simpler and less error-prone.
Change-Id: I819978517e17c647ffb7028063cd0adde68ff691
These markers will be used to group the GL commands by View in the
OpenGL ES debugging tool. This will help correlate individual GL
calls to higher level components like Views.
Change-Id: I73607ba2e7224a80ac32527968261ee008f049c6
