This is needed as window animations are being ported over to use
ValueAnimator, and thus ValueAnimator need to ability to support
custom duration scales per object.
Test: ValueAnimatorTests
Bug: 64674361
Change-Id: Iea8d673b66e52866929174bbf6ca4a7ae882807b
- Move the bounds animation onto the animation thread
- Remove existing code referencing the old sf-vsync choreographer
- Add ability for ValueAnimator subclasses to reference a different
AnimationHandler, which uses a different FrameCallbackProvider with the
sf-vsync choreographer in the animations that require it
- Ensure that PiP touch events are batched and sent aligned with the
sf-vsync
- Move GC onto its own thread to not block other BackgroundThread calls
Bug: 36371375
Test: android.server.cts.ActivityManagerPinnedStackTests
Test: bit FrameworksServicesTests:com.android.server.wm.BoundsAnimationControllerTests
Test: go/wm-smoke
Change-Id: I6a41b35a4e4d4d6dbea82c2673452825fe3ffa58
AnimationHandler.doAnimationFrame() iterates on a list that may be changed
during the course of the lopp, especially when Battery Saver is enabled, or
animators have zero duration, coupled with user code launching new animators
when old ones end.
The fix is to iterate through the old size of the list, and avoid processing
new animators in the current frame.
Bug: 37376806 Keyboard doesn't come up when battery saver is turned on on Android O
Test: manual
Change-Id: I40ca1d849e6f337779c23edbab22d80760c22f9b
A cache was introduced in I677bc289f2ba430466f2d90ebc14368cb7b75118 to
optimise calls to createDependencyGraph(), but the update was removed in
If1dc6e8dbc93a4bf5ade8c5b0dcf43d3ee6ba7b5. This patch reintroduces the
update when calculating child animation start/end times to re-enable the
optimisation.
Test: cts-tradefed run cts-dev --module CtsAnimationTestCases
Change-Id: Ie9dad4049c07a151889b57809bf844ab854ff482
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
