For now, only animators use it but we can consider migrating
drawable cache to it as well.
Bug: 17456416
Change-Id: I571b96856805edb171f0fc52e6bff5a365f46b70
When Battery Saver mode is enabled, we set the animation duration
scale factor to 0 to effectively disable all animations. Later
when it is disabled, we reset the animation duration scale
factor to 1.
This change ensures that we reapply the duration scale factor
whenever the animation is started instead of only applying it
once when the duration is set (usually when the animation is
created). This ensures that the correct scale factor is applied
even when it changes after the animation has been initialized.
Previously, certain animations would continue to be suppressed
even after Battery Saver mode was disengaged. This wasn't much
of an issue when the duration scale was initially implemented as
a developer setting but now that it is exposed via Battery Saver
the artifacts caused by this bug have become visible to users.
Bug: 17887431
Change-Id: I91ba5ca0505d02ac389a31d067e38886112fa0c8
Complex animated vector drawables can be expensive to load due to
sub-optimal parsing of the String-based pathData. Suffering that penalty
every time the same drawable is loaded (such as material-themed
ProgressBars) is painful.
The new approach caches constant state of both the VectorDrawable (including
the pathData geometry) and the animators (which includes potentially expensive
path-based interpolators).
issue #17366831 Material ProgressBar taking 200+ms to inflate
Change-Id: Iba3b541e24cfce8c07f5aa9fe6aa7d7b92b2fe1c
Bug 16984007
Animated Vector Drawables were using the viewport dimensions for
calculating the allowable animation error. Instead of using viewport
dimensions, it is better to use the intrinsic dimensions. Using
the viewport dimensions meant that a small viewport (e.g. 1x1)
would mean that animation paths within would only have an accuracy
of 50% of the dimensions of the drawable.
Change-Id: Id0152eabb4effd1e50c644eea7a371b38baeb7c1
Bug: 17317184
Unfortunately this will disable *all* RT animations in a scene,
but we don't have more selective targetting currently
Change-Id: I57e1c0ae43957f45229473bdcdaf34c05825fab7
Bug: 16161431
Also re-writes RevealAnimator to avoid using any listeners internally,
removing the logic around shadowing the update listeners.
Change-Id: I6ed8126398eed971a87f20bccb7584c9acafbb6c
This avoids NullPointerException crash when changing values without
first canceling a running animator.
Issue #16245303 KeyframeSet crash on null keyframe or evaluator
Change-Id: I50ce5223310fe87e3382c446e2d36d93ae38a8fe
Basically extended the ValueAnimator to support a new type: pathType.
Add the PathDataEvaluator internally to interpolate path data.
Update test to show the path morphing.
Change-Id: I89db0199cbc12e3041790a6115f3f50b80213cdb
The test case is showing that AnimatedVectorDrawable is able to use path to
define time interpolator and object movement now.
Change-Id: If3c0418265d0fd762c8f5f0bb8c39cce3ad34ef3
Currently as a hidden class.
It can support many the animations now as far as ObjectAnimator and
hierarchical group can support.
And we don't have path morphing yet.
Also support the Animator / Interpolator inflation from Context and Resources.
Change-Id: I948bbdf7373ad291171eed0b497959dce8c2edf3
Long is used in PropertyValuesHolder class to store native pointers
as they can be 64-bit. Note that jmethodID, a pointer to structures,
is also carried in long rather than int to support 64-bit system.
Signed-off-by: Marcus Oakland <marcus.oakland@arm.com>
Signed-off-by: Ashok Bhat <ashok.bhat@arm.com>
(cherry picked from commit 0141e88434)
Change-Id: I80408a7227427732db0d8b4c960bcb849b7c8060
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
