Previously, you could set a new interpolator on a LayoutTransition object,
but it wouldn't have any effect, since the value was only used at construction
time. This change makes the intended behavior work, byt assigning that
new interpolator to the appropriate animations when they are run.
Issue #11163487 LayoutTransition.setInterpolator() has no effect
Change-Id: I1b390a30c008ac2bf26491dc352e28f276357388
Previously, an animator that had started but not yet played its
first frame would be reversed from its end state, which was not the
desired behavior. Now, we detect that condition (started, but not yet
actually running) and simply end() the animator immediately.
Issue #10136266 ValueAnimator.reverse right after calling start() does the full animation
Change-Id: I2a48d267336241ce74079c75758026c6f07ebc3a
Issue #10460684 KLP API Review: android.view.transition and android.animation
Issue #10570740 Transitions: inflate transition targets from xml
Change-Id: I7a3f6d3aece2fcafc5efd555d033f79e86635c98
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
