isRunning() for an Animator indicates whether an animator has gone
past its start delay and not yet finished. As a subclass of Animator,
AnimatorSet should follow the same principle. The implemention prior
to this CL returns whether any child animation is running, which is
inconsistent with the javadoc for isRunning() and general behavior
for Animator.
Change-Id: Iece814dfcd609ee292dbc00bd55dc64c7bda8e57
end() and cancel() in ValueAnimator will trigger onAnimationCancel
or onAnimationEnd callback on its listeners. If additional end()
or cancel() request comes from the callback, a loop will be formed.
Therefore, we need to mark when the end is reuqested so we do not
process end() or cancel() request multiple times during one animation
run, and also effectively terminate the loop.
Bug: 23596652
Change-Id: Iefb69eb8969071b43124c09d7cccbe9ff5ba5dcc
This CL includes the following changes:
1) Remove redundant field mPlayingState in ValueAnimator.
2) Refactor AnimationHandler so that all of its interaction with Choreographer
is through an interface. A custom provider that implements this interface can
be plugged in and provide timing pulse that are independent of Choreographer.
3) Better encapsulate AnimationHandler and ValueAnimator. Interaction between
the two is done through register/unregister frame callbacks as well as
AnimationFrameCallback interface.
4) Change how animation delay is handled.
Change-Id: Icd49f727321c362dab49b5b33815333c9ea559e0
Each animator's total druation is cached in the set, so that when
their duration changes, the dependency graph will be updated to
reflect the change.
Change-Id: I677bc289f2ba430466f2d90ebc14368cb7b75118
This CL fixes the bug where when there're AnimatorSet inside of
AnimatorSet, incorrect AnimatorListeners get notified of the
Animator's lifecycle events.
Bug: 22940651
Bug: 22954352
Change-Id: I2bf66413d54dcfc75dc7fa779e723443763a30a5
This refactor changes how relationships (i.e. with/after/before)
among Animators in an AnimatorSet are represented. Specifically,
a directed graph is used: parent-child indicates sequential
relationship, and siblings will fire simultaneously.
This CL also fixed the issue where start delays for Animators that
play together are not handled correctly.
Bug: 11649073
Bug: 18069038
Change-Id: I5dad4889fbe81440e66bf98601e8a247d3aedb2e
Behavior is different than spec'd for one-shot animators, clarified
docs to reflect that.
Issue #21087798 better docs for isStarted()
Change-Id: I499a5d52cf02ef715acb6ae0635ede4328c93de8
Previously, changes have been made to infer value types for
PropertyValuesHolder when no value type is defined. This CL applies
the same inferring logic to ObjectAnimator too.
Bug: 21645431
Change-Id: Ifdf163a7d32da990dc2281080f87f94c0df0e9ce
This fix is to take advantage of ArrayMap, which is a key-value
mapping data structure that is more memory efficient than HashMap.
Bug: 11604254
Change-Id: I57006880de570a4d7f3899e274cf0a06355d116b
Themes now use an array of applied styles rather than a String to store
their history. They are keyed based on a hash code computed from the
history of applied styles. The themed drawable cache has been abstracted
out into its own class.
Also updates system context to use DayNight as the default and ensures
that GlobalActions uses the correct context, which exercises the change.
CTS tests have been added in another CL.
Bug: 20421157
Change-Id: I9eb4b7dffd198ad24d02f656eaf0839570b59caa
Previously, an OnPreDrawListener was added to clean things up, including
removing the listener, after animations are started.
But if the view is detached before that listener is called, the
listener will remain on that ViewTreeObserver.
This change adds an OnAttachStateChangeListener to perform that cleanup
step when the view is detached, just in case.
Issue #20824645 Leak in LayoutTransition
Change-Id: I264812f8e02dda673789712ba83d208e87cdc5a4
Duration scale based on screen size was using the area of the screen
excluding system bars to compare with our reference device's screen
size. This caused the following issues:
1) On baseline device (i.e N5) a scaling factor that is not 1 will be
applied to the duration.
2) Scaling on the same device will be different in landscape vs.
portrait, as the system bars take different amounts of space in
different orienations.
This CL fixes both of the above issues.
Bug: 20309042
Change-Id: I9d1d0a471d968bee1330b80f0f69a0066d6a1860
In order to preserve the same look and feel of an animation across different
devices, we need to maintain the same angular velocity for the animation in
users' field of view. Since the animation path may span different angles on
different devices, we need to therefore adjust the duration accordingly.
Change-Id: Ia37f213e5a894a046edbb1a45a4ced04e406d85d
The Choreographer carefully schedules animation updates to occur
after input but before traversals occur. This ensures that the
effects of animations are perceived immediately in the next frame.
The start time of animation is usually set the moment the animator
first runs. The start time serves as a reference for timing the
remainder of the animation.
Setting the start time during the animation callback works well except
when traversals take a long time to complete. In that case, we may
end up drawing the initial frame of the animation then skipping several
following frames (because a lot of time has already passed since the
animation start time was set), effectively shortening the duration
of the animation.
To resolve this issue, we introduce a new COMMIT phase within the
Choreographer. The COMMIT callback runs after traversals complete
and may provide an updated frame time that more accurately reflects
the time when the frame finished drawing.
In the case where an animation is just starting, we note the fact
that its initial start time has not yet been committed (the user
hasn't actually seen anything on screen yet). Then, during the
COMMIT phase, we adjust the animation start time to better reflect
the time when the animation's first frame was drawn, effectively
causing the animation actually start after the expensive traversal
operations occurred such that no frames will be skipped.
Bug: 17258911
Change-Id: I279603d01fd4ed1de8f51a77c62f4fec5e9b746a
Support different interpolators on every keyframe by running
interpolators on proportional duration instead of raw fraction.
Bug: 19928396
Change-Id: Ifb8c3a3b56785582cd6b0121d7bfb44534866300
A recent change to ValueAnimator caused infinitely repeating animators with
duration 0 to be ended immediately. BatterySaver mode can cause animators
to have 0 duration, which means that apps depending on animator update events
no longer receive those events due to this behavior change.
The fix is to restore the previous behavior of allowing repeating animators
to continue, regardless of duration.
Issue #19113776 Fix infinite-repeating, zero-duration animator behavior
Change-Id: I4d1c7afb6d06ca45ef41db73c160f6a6d5754e24
A recent fix to seeking behavior injected a couple of issues that need
to be addressed:
- the start time should be updated when seeking so that future calculations
that depend on it (such as the next animation frame) will use the updated
start time based on this seek request. This allows, for example, seeking
into a running animator so that that animator will update its current fraction
to the new seeked value.
- calling reverse() on an unstarted animation would incorrectly set the initial
frame of the animation to the end value for one frame before the reverse animation
actually began.
Issue #18567716 No icons in folders in battery saving mode
Issue #18511989 Search bar flashes when icon is picked up and dropped
Change-Id: Ie30b7e797468c6ccb3d17d4fb3aba6b9849436b0
A recent change to seeking behavior altered the logic of
setCurrentPlayTime() (which is called when animations are first
started) to set the current animated fraction to 0 for 0-duration
animations. This fix ensures that 0-duration animations snap to
their end value (fraction == 1) instead, matching the behavior
prior to the seeking fix.
Issue #18542543 Animations with 0 duration stay in initial state when calling setCurrentPlayTime(0)
Change-Id: I9916d962cf46453a9e3e1207f58baf16f4a5830a
The animation scaled was not being factored in early enough in the
activity lifecycle. Also, setCurrentPlaytTime() was not accounting for
the scaled duration correctly. Finally, added setCurrentFraction() as
a more general-purpose seeking facility.
Issue #18222006 Animator duration scale ignored in some situations
Issue #17951668 add ability to seek fraction, not just time
Change-Id: Idad401f5ff5026d7046c36eee09d78a4793215dc
Bug 17978210
When Properties are used with PropertyValuesHolders or
ObjectAnimators, the reflection lookup for getters and
setters is unnecessary.
Fixed problem in which static maps were being protected
by instance locks.
Fixed problem where we were repeatedly doing a
reflection lookup on methods that don't exist.
Change-Id: Ic0a1b62357f3aaaa4c900fef6087583ad0e964b6
