Repeating a 0-duration animation makes no sense. In the case of
battery saver mode, all animators are set to 0 duration, and
repeating the 0 duration animations not only waste battery power
but also potentially produce flickers on screen. In this CL,
0-duration animations are skipped to the end, regardless their
repeat count.
Bug: 25451472
Change-Id: I20f9dc2f0ff9c027782a8363ff4cf4a4d390736c
For pre-N, we have inconsistent behavior between ValueAnimator and
AnimatorSet in the case of calling end() when already ended:
ValueAnimator would start() and immediately end, whereas AnimatorSet
would be no-op. We made a decision to be consistent within Animation
Framework from N forward, which means that AnimatorSet will have the
new behavior of starting and immediately ending just like
ValueAnimator. This new behavior will be guarded by an API check.
Bug: 25601129
Change-Id: I2d952a93d8521c547ec8cde173c80d1d8ead0639
- Use a future to provide the app thumbnail so the app can restart
in parallel when recents draws the bitmap (extremely expensive).
- Don't call startRecents from AM when recents is already running - this
messes up the transition information.
- Make sure to put the task into resizing mode if it needs to be restored
from the disk.
- Some minor fixes for the transition animation spec.
- Add NO_MOVE_ANIMATION to recents flags to prevent wallpaper
flickering.
Bug: 27607141
Change-Id: I7d0c75b88775ab467927b8cf94303ddb60222e7f
Bug 27142336
Using a type variable in a varargs leads to a javac warning
because type variables are treated as Object after compilation.
Because these uses do not require a specific typed array, we
can use @SafeVarargs to suppress the warning.
Change-Id: I860bcc79667a9c85c381c7994fd1d798209d7c66
Previously we were using native config flags in some places that expected
Java flags, and vice-versa. All usages of config flags are now annotated
to ensure we're using the right type.
Cleans up annotations on most methods that were touched.
Bug: 21161798
Change-Id: Ifd87dfb12199fc8258915d8a510e03ddb681ca89
Bug 27418573
While an animator was paused, it continued to receive
Choreographer callbacks. This has been changed now so
that after the first callback, it is removed.
Change-Id: If73483404b38f1f354a63fc98d07696f442987e6
In order to satisfy the requirement that clients can
cache a Resources object when a configuration change happens,
we move the caches and all other method bodies to ResourcesImpl.
These can then be swapped out for the correct version when needed,
while allowing clients to keep holding the existing Resources references.
This is part 1 of 2 CLs. The next one will do the actual switching of implementations
based on configuration changes for multiwindow.
Bug:26854894
Change-Id: I41156194a3541e59053b4048c3a15981c7d8a506
This is reverting the revert of what reverts the revert of the original
implementation. Fourth revert is a charm!
This reverts commit df7fdb1e0b.
Change-Id: I6fc3a5accfd8b79c3da31bbc101ad9e9b4d6e7dd
This CL runs VectorDrawable animation on RenderThread. The changes in this CL
include:
- Convert all the animators in AnimatorSet for AVD into a set of RenderNodeAnimators.
- Hook up the new animators with RenderThread
- Add drawOp in RecordingCanvas for drawing VD so that during the animation
on RenderThread, all the property changes on VD can be reflected on the screen.
TODO:
- Implement reverse and reset for AVD.
Change-Id: I2df1d754f2db0ad098d9c15dde4bb2bdfafc2315
There is logic in PVH.setupValue() that sets the value of
the appropriate keyframe from a Property, if that Property object
exists for the animator. But after that is done, it goes ahead and sets
the same keyframe value based on the getter for the target object.
This is not only redundant; it is wrong (in the odd situation in which
a getter would return something different than Property.get()).
The solution is to return early once we've set the value with the
Property object.
Issue #26471646 PropertyValuesHolder uses reflection in setupValue when a Property is being used
Change-Id: I12634a25661400f13f44872ba17625b32e93ca19
Introduced PathData in Java, which is effectively a thin layer around the
native instance. PathData holds the verbs and points which is being used
in path morphing/interpolation. The verbs and points can be interpreted
into skia path commands, which is now done in native and therefore saves
a handful of JNI calls during path creation.
Removed the old PathDataNode mechanism and changed the PathEvaluator
to use PathData instead.
Also added tests and a microbench. Also ran CTS tests for VectorDrawable
and AnimatedVectorDrawable, and passed all of the existing tests.
Change-Id: Ia166f5172ff031fe18b154327967f911a62caec1
Total duration is the total amount of time an animation takes from
start to finish. It include start delay (if any), child animation
sequence, accounting for repeat.
Change-Id: Id5b36a63c02e25586aefd38612aa5867492e1adb
mPlayingBackwards is confusing when placed next to mReversing.
One means the overall direction of animation playing, the other
indicates the direction of playing in the current iteration.
mCurrentIteration and mPlayingBackward are redundant together,
as the latter can be derived from the former, given the overall
direction of animation playing. Redundant variables pose risk of
getting out of sync and therefore are refactored out in this CL.
Instead, an overall fraction that ranges from 0 to mRepeatCount + 1
was introduced. It can capture both the current iteration and the
fraction in the current iteration. It gives a much better idea of
the overall progress of the animation.
Change-Id: Ic0ea02c86b04cfc01c462687d1ebbd46184cbab7
Return a valid value for the current play time if the animator has
been seeked to a play time or fraction, but not yet started.
Issue #24717972 animator.getCurrentPlayTime() is all messed up
Change-Id: I15f1329b65410b4b0366a23a3419b5987305a865
This CL maintains the behavior that animators without any
start delay will get started right away, instead of being delayed
to the first frame as it was in the previous refactor.
Bug: 23825781
Change-Id: I7873bc6c7a761c1b4d48ee5e17af631b359fd676
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
