It is now possible to pause Animator-based animations. Pausing an
animator causes it to hold the current time/value indefinitely, or
until end/cancel/resume is called. When resume() is called, it continues
from where it left off.
There is a new listener interface on Animator, AnimatorPauseListener,
which can be used to listen to pause/resume events.
Change-Id: I77d1535e792fb7bf349f549a0ac0a0d85958cb47
Previously, ValueAnimator would always call into the Trace class to
log start/end events. When the animator is an ObjectAnimator, this
call necessitated building a new String to capture the animated property
name. This fix puts the calls to Trace inside a check for isTagEnabled(),
to ensure that we only bother building the trace name when tracing is
actually enabled.
Change-Id: I56ef093f3b67b31a19c861f9d1e44a84341edf53
Also, fix ObjectAnimator.getPropertyName() to return useful info
for ObjectAnimators not created with string-based property names.
Change-Id: If7ab6dbcc3be13f5978840b02f4a91ef7eee1c50
Push the interface methods from the new Animatable interface back
down into Animator, from whence they came.
Issue #8634310 Remove Animatable interface
Change-Id: I79e26001709d791d54fcb02561640fe2e008b1fd
Adding features which round out the animation APIs (missing
getters, etc.). Also fix doc typos.
Issue #8350510 Add APIs needed for future animation capabilities
Change-Id: I063736848ba26e6d6c809b15fc3a103c74222f46
Adding views to views (possible with the new Overlay API) is weird.
This change moves the view-management facilities of Overlay to a subclass
that is specific to the overlay returned from ViewGroup.getOverlay().
So now you can add drawables to all view overlays, but only add/remove
views to/from the overlay returned from ViewGroup.getOverlay().
Also, the previous approach of using an interface for Overlay was
changed to classes for both ViewOverlay and ViewGroupOverlay.
Finally, this change makes not handling touch correctly the proper,
and documented, behavior of overlay views. There are various tricky issues
to sort out with input in overlays (including click handling as well as focus)
and we don't want developers starting to use overlays as some kind of general
container hierarchy, so we're purposely constraining overlays to have visual-only
behavior.
Issue #8459085 Overlay needs to handle touch correctly
Change-Id: I207b8dbf528f87c92369d270d8b0a6556826d207
RectEvaluator is useful when animating object bounds.
The other change is a hidden API that allows temporary suspension
of layout, useful for animations which need to animate view bounds
without conflicting with layout passes that might happen in the middle
of the animation.
Change-Id: I3dc08cb6ec455dfa3409e825506b218d3ea63d7a
Add a method that enables a new auto-cancel option to
ObjectAnimator. When set, any ObjectAnimator (when started) will
cause any running ObjectAnimator instance (with that flag set)
that has the same target and properties to cancel() itself prior
to starting the new one.
Issue #7426129 Add auto-cancel to animators
Change-Id: I586659c365289cdb9afb6c416bdbaf5630477149
Seeking an animation after the animator has reverse()'d to the beginning
will result in seeking in reverse. Starting the animation will make it proceed
normally, and calling reverse() will also give expected behavior. But seeking
causes this unexpected behavior because the state of reversing is not reset until
the next time the animation is played (either by start() or reverse()).
Fix is to reset the internal flag when the animator ends.
Issue #8234676 Reversing an Animator Leaves it in A Reversed State Until Explicitly Started
Change-Id: I9d212ae1879aa277d1add7eb4c7ec61432af059e
Many media files and source code files were marked as executable in Git.
Remove those.
Also a shell script and python script were not marked as executable.
Change-Id: Ieb51bafb46c895a21d2e83696f5a901ba752b2c5
Previously, an animator that had been reverse()'d (and was thus
playing backwards) would not end() at the right value. That is, a call
to end() would cause the animation to snap to its original end value, not
the reverse-playing end value (i.e., its start value). Logic to handle
calculating the proper end value was not taking the reversing behavior
into account.
Issue #6583656 When you call end() after calling reverse() on an animation that has not started leads to forward animation finishing.
Change-Id: Ifca60a32d4973c21b85aed9c459f802526c0207e
Previously, clone() on an Animator with only one value would mistakenly
think that the clone had a real starting value (which would end up being 0 in the
int and float cases). Fix is to set the 'mHasFirstValue' flag appropriately for the
clone, based on the state of the cloned animator.
Issue #7106442 ObjectAnimator.clone() does not work properly for single parameter
Change-Id: I08bf03b7687a65eb613c1671a58e4cbfae66a30e
The logic in the frame processing code of ValueAnimator did not handle
the situation of animators being ended while the current animation list
was being processed. In particular, if a call to an animation update
(which could result in a call out to user code) caused that animation, or
other current animators, to end, then there was the risk of running off the
end of the list of current animators.
The fix is to work from a copy of the current animator list, processing frames
on each one only if they also exist in the real animations list.
Issue #6992223 Frequent System UI crash
Change-Id: I742964558f8354f04c311b7b51c7686f26a4dacf
Normally the ValueAnimator scale factor is applied the first
time a ViewRootImpl window session is created but that may
be too late for animators created by system services that
start early in the boot process. So set the scale factor
immediately whenever the setting changes.
Also make ValueAnimator.getDurationScale() accessible (but @hide)
for custom animators that want to apply the same scale to
their animations.
Change-Id: I0f5a750ab5b014f63848445435d8dca86f2a7ada
Shifting from the left copies the MSB along with it. This causes a problem
in ArgbEvaluator, which shifts the top byte down by 24 for the start/end
colors, and then uses those values to interpolate alpha values. The correct
appraoch (used with the other color components) is to mask by 0xff after the
shift.
Issue #6960514 External bug: ArgbEvaluator can't evaluate alpha value properly
Change-Id: I750d38ddfecc5f30d8dab7c6d27d1a7ac06361c3
This is required, otherwise the listener cannot remove it-self from the
list of listeners during the notification.
Bug: 6692355
Change-Id: I07762feb4f9b97ec4b6148d2f604d53e266b84d7
LayoutTransition runs changing animations on all objects that change between
now and the next layout. This works in most normal situations, but when a container
is becoming visible, or being added to its container, or other first-time situations,
then some of the views and parent hierarchy may be of size (0,0). The user really
shouldn't need to see an animation up from these nonsense values, so we just
skip running the animation on these objects and simply place the objects where they
need to go.
Issue #6597648 view should not animate up from size (0,0)
Change-Id: I2c355a68bf1ce3b41fbec01ad95c78d83562ba32
LayoutTransition causes artifacts in some situations where a window is just
becoming visible or a container is just being added to the view tree when animations
are kicked off in LayoutTransition due to the normal automatic mechanism of running
animations when views are added/removed/etc. The problem is that containers in these
situations may have children with positions and sizes of (0, 0), causing the animation to
animate from this default/nonsense value to whatever is appropriate for the views when
they are first laid out and drawn. The end result is correct, but the animation is
superfluous and silly.
The fix is to avoid running any kind of transition animation on windows that are not
currently visible or containers that are not currently atached to the view hierarchy.
This should avoid the situation by only allowing the animations to run after the containers
and windows are visible and set up correctly.
Issue #6544410 issue with layout transition when first showing the activity
Change-Id: I737b2598887ef806dec3b02a483a8e8ff2c3d4e2
Detect when a vsync message was significantly delayed which may
indicate that a frame was skipped. When this happens, update
the frame time to reflect the approximate start time of the
current frame instead of the start time of the frame that was
skipped a long time ago.
Removed an unnecessary call to getCurrentPlayTime() in the
animator framework. The result was always zero and the call
just made the code confusing.
Bug: 6443611
Change-Id: I92b24f7ffd74c59b75a727b6bfc0bb51fc92a73a
Previously, if you set up an ObjectAnimator with the name of a property
which could not be resolved to an existing method (e.g., "foo" becomes "getFoo()"
or "setFoo()"), the errors in the log could be a bit obscure and the animation might
just crash sometime later with an unexplained NPE. This change provides a more
detailed log message detailing the actual method/class involved.
Issue #5990756 NullPointerException on no such property
Change-Id: Ic5bf7069c4879623e00ab8a794b799773cce487c
Instead of using the current uptime millis, which can exhibit
substantial jitter depending on when the code runs, use the
current frame's vsync time when performing animations. The frame
time provides a more consistent pulse.
Bug: 6375101
Change-Id: Icf307cd8524246607db7496c6fef9a5eeb7c0439
The callbacks for animators in some corner cases were not being
called correctly. For example, startDelayed animators that were
started and then ended didn't send out the proper events.
This CL fixes that logic. Specifically:
- An animator that is end()'d will implicitly start() itself and then
assign an end value. This was already the case, but listeners were not
getting notified. Now this situation causes callbacks to listeners for
both the start and end events.
- startDelayed animators that are end()'d or cancel()'d prior to finishing
the startDelay phase will send out events (start and cancel/end, as appropriate)
to listeners.
Change-Id: I40a0f2fdb19d9ec7c3726a91363686c6ecb7d915
LayoutTransition used to depend on child views being added/removed or
shown/hidden in the transition container. These evens would trigger animations
to fade the child view as well as those to animate the side-affected changes
to sibling views. This CL enables a new feature in LayoutTransition that
enables animating any changes to the layout of the children in the container
whenever a layout occurs. For example, you can change the LayoutParams of a
child view and call requestLayout() to automatically animate those changes.
This capability is not enabled by default. To enable, call the new
LayoutTransition.enableTransitionType(LayoutTransition.CHANGING) method.
Change-Id: I4d07a3b36245353b2151f0dca4f75080ab6a4592
Setting the duration on an AnimatorSet should propagate that value
to its children. This works, but only if all children are added to the set
before setDuration() is called. This fix delays that propagation until
the set is started, making it possible to have a more flexible order of when
the children are added and when the duration is set.
Issue #6324904 AnimatorSet durations too long
Change-Id: I797971c2310eb2e3fe931b4aa35de505f2a519f7
Improved how the various callbacks are managed and sequenced
to reduce code duplication.
Added a heuristic to avoid postponing traversals until
the next vsync frame if we did not actually do any drawing during
the previous frame. This helps in the very common case where
drawing occurs in response to input.
Change-Id: I277d9eeaf50408f8745a3cfd181db1d140770658
Starting several animations will place separate events onto the
animation queue, which may cause the active animations to get
processed more than once in any frame when one of those start messages
is processed.
This change moves the logic of starting pending animations into
the animation frame processing itself. Now when a start event is
processed, it only calls the animation frame logic if there are
unstarted animations pending.
Issue #6172602 Inconsistent animation callbacks
Change-Id: I3a546f0c849f42b2dd998f099fcdfafd7d780ad9
Removed the listeners and schedule animation / draw methods.
Instead all requests are posted as one-shot callbacks, which is a
better match for how clients actually use the Choreographer.
Bug: 5721047
Change-Id: I113180b2713a300e4444d0d987f52b8157b7ac15
This class has existed since ICS, but was hidden. This change
just makes it public API.
Also, cleaned up some internal javadocs.
Change-Id: Id69408446ced183e01d2b065a67397eb305d9665
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
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
When a view is becoming VISIBLE or INVISIBLE in a container with a
LayoutTransition, animations run to fade the view in and out and also
to run 'changing' animations on the view's other siblings. This logic
also cancels any running 'changin' animations to account for new ones
running.
However, in the specific case of INVISIBLE changes, there will be no
layout changes in the container - layout has already accounted for that
view (unlike in the case of GONE views); the visibility is just a matter of
drawing the view (or not). Therefore, we're canceling 'changing' animations
that should continue running and not replacing them with any other animations,
since new animations would only be started on layout chnages which are not
forthcoming.
One artifact seen from this bug is that the navigation bar buttons sometimes
disappear when changing orientation. This is because the menu button may
toggle between VISIBLE and INVISIBLE, causing animations on the other
buttons to get canceled, which leaves those views in a completely wrong
state.
The right thing to do is to avoid canceling in-process 'changing' animations
and to skip the logic of setting up new 'changing' animations which won't fire
anyway.
There is some minor API work in here because we did not previously have the
necessary information in LayoutTransition to know whether a view was being
hidden or shown to/from the INVISIBLE state.
Issue #5911213: LayoutTransitions ending in an odd state
Change-Id: I5c60c8583c8ea08965727b4ef17b550c40a3882c
Both animations and drawing need to march to the beat of
the same drum, but the animation system doesn't know
abgout the view system and vice-versa so neither one
can drive the other.
We introduce the Choreographer as a drummer to keep
everyone in time and ensure a magnificent performance.
This patch enabled VSync based animations and drawing by
default. Two system properties are provided for testing
purposes to control the behavior.
"debug.choreographer.vsync": Enables vsync based animation
timing. Defaults to true. When false, animations are
timed by posting delayed messages to a message queue in
the same way they used to be before this patch.
"debug.choreographer.animdraw": Enables the use of the animation
timer to drive drawing such that drawing is synchronized with
animations (in other words, with vsync or the timing loop).
Defaults to true. When false, layout traversals and drawing
are posted to the message queue for execution without any delay or
synchronization in the same way they used to be before this patch.
Stubbed out part of the layoutlib animation code because it
depends on the old timing loop (opened bug 5712395)
Change-Id: I186d9518648e89bc3e809e393e9a9148bbbecc4d
LayoutTransition was making an incorrect assumption that there could
only be one transition animation on a child of a transitioning container.
But if multiple children are added/removed to/from that container, there would
be multiple calls to set up changing animations for each existing child
of that container. This meant that the child would have multiple, new
OnLayoutChangeListeners added to it as part of the setup process.
Meanwhile, we would cache only the latest listener in a hashmap that used
the child as a key for the listener. Then when we cleaned up the hashmap later,
we would remove only the latest listener from the child, leaving the rest there
for eternity.
The fix is to skip the setup entirely for children that already have listeners
set on them; they must, if that's the case, already have been set up and are
already listening for layout changes. Setting up the animation is redundant,
and adding another listener is a leak.
issue #5588509: memory leak in systemui
Change-Id: I2c9f312cc2bcf4f2d08ac6b5d8f8e495aa4f3597
