When a child animator is being manipulated outside of the AnimatorSet,
such as when the child animator is running before the AnimatorSet gets
started, we need to make sure we maintain the behavoir on N:
The child animator will be re-started at its scheduled start time in
the AnimatorSet.
BUG: 37507882
Test: Repro steps in comment #1 & ag/2144081/
Change-Id: Ib97e85706f01d18a2e72fb4d1d678e22cf959894
This CL fixed an issue where pre-O apps receive animation
end callbacks before all animations have ended.
BUG: 36157561
Change-Id: Id0ea05e76c91a21a678ec05b1ed0c898ee36ee43
Workaround: 36241584
Test: repro steps in comment #1
This CL ensures that doAnimationFrame() is called the frame
after start() is called, so that AnimatorSet can pulse frames
into single animators as soon as they are start()'ed.
Test: new cts test in same topic branch
Change-Id: I4f9522ce9e1a54ca3bcad6c696e6b248c945ff90
An app has Animators (NoPauseAnimatorWrapper) that does not
check their listeners against null before cloning. The previous
implementation of AnimatorSet has masked this issue. But the
underlying bug should be fixed in this app.
For now, work around the bug by adding a listener to all the child
animators.
BUG: 34736819
Test: Manual
Change-Id: I968450aab62cf5d308e3b64e76dcf018178af67e
This CL adds reverse and seek to AnimatorSet's capabilities.
Structural changes:
1) Child animators are now being pulsed by AnimatorSet in a more
timeline manner, as opposed to the old listener based style.
This timeline based approach avoids the time offset in between
sequential animations, and therefore produces a more accurate
overall duration.
2) Timeline is done by representing start and end of each child animator
in two separate events. All the events are then sorted based on the
time they happen, such that it's clear what should happen in between
last frame and the new frame (i.e. which animations should start
or end).
Test: CTS (in the same topic branch)
Bug: 30993532
Change-Id: If1dc6e8dbc93a4bf5ade8c5b0dcf43d3ee6ba7b5
Animators can be scaled to have zero duration globally in any device.
This can happen either via Developer Options (an uncommon path) or
Battery Saver mode (much more common for real users).
In general, this works fine; it just causes app animations to be jump-cuts
instead (which is the desired effect, either to make transitions faster
(Developer Options setting) or to optimize battery usage by rendering
fewer frames (Battery Saver mode).
But sometimes, choreographed animations can have undesired artifacts. For
example, an animation that calls an end listener to restart itself
will end up doing this almost constantly due to this effect. Other artifacts
can also occur, such as intermediate results in a complex choreography of
multiple animations can show several intermediate results in a way that is
confusing to the user.
For these cases, there is nothing that the platform can do to automatically
determine how to best handle the result. Instead, we surface this new
API to help developers discover this behavior and compensate accordingly.
Bug: 31052471 Animation playback is abnormally fast during Battery saver mode
Test: unit tests, CTS test upcoming
Change-Id: Id7ef1a9652ac5c6cdaca0c126756e82582d49b1c
- Reset mAnimationEndRequested to false in ValueAnimator#start(boolean)
so that previously canceled animated (with a start delay) can be
canceled again.
- In ObjectAnimator#animateValue(float) check if target == null
regardless of mTarget == null since it's possible the target was
explicitly set to null prior to the animator being cancelled.
Bug: 30190459
Change-Id: I6da55737df30a28f48355fc7a41ab91d05979deb
In case of interpolating between x+1 and x in a color channel, the
previous implementation would jump to x in the *beginning* of the
animation, as it rounds down the interpolated float that's [x, x+1].
This CL rounds the per-channel interpolated float to the closest
integer.
Change-Id: I8610fb14ab3dd0ee2b1816868977c5653c178660
Also fix the behavior for calling reverse() immediately after
start(). Such case now triggers end() right away, which is
consistent with what the animation would do in M.
Bug: 29271714
Change-Id: I045e36e039179a3c462f22bc6a3a765437de4074
Bug 18122022
Previously, each animator would wait a frame after it was
started the animation was actually started. This is fine
for the first frame of an animation, but when it is within
an AnimatorSet, each animator will add a frame of delay.
This skews the animations so that they can no longer be
synchronized.
This CL refrains from waiting for an animation frame when it
is started during the animator callback and just start
the animation immediately on that frame.
Change-Id: I007dad9aef7596f0e954377a36a17afd4801b7fe
Previously, wrong valueType error is swallowed in jni. As a result,
some animations are quietly skipped without letting developers know.
This CL maintains that behavior for pre-N, and throws Exception
to notify developers of the error for N and above.
Bug: 29009391
Change-Id: I3e8f003cdb97d214da72af3f93a84f64797b1c2c
(cherry picked from commit 94db09917a)
