- 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)
Previously, the VectorDrawable animators modify the VD properties by
doing reflection based on the property name. This CL avoids the overhead
of calling reflection by wrapping the setters of VD objects in
Float/IntProperty.
Bug: 28124049
Change-Id: I562c8d749fdfe508564c82a700a92e835cdd9ff4
(cherry picked from commit 9f3b31b953)
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
am: d38541009b
* commit 'd38541009b847cba108a71a49d64d809b0bb5f42':
Add more doc for Object animators defined with a single value
Change-Id: Icbc5a547c8a586335d4a826059765103cb59f26f
Previously, the VectorDrawable animators modify the VD properties by
doing reflection based on the property name. This CL avoids the overhead
of calling reflection by wrapping the setters of VD objects in
Float/IntProperty.
Bug: 28124049
Change-Id: I562c8d749fdfe508564c82a700a92e835cdd9ff4
Animators that are created with Object values may have undefined
behavior when those objects are changed outside of the animator itself.
For example, an animator created with a start Rect and end Rect
will animate the bounds between those two objects. But if the caller
changes either the start or end rect before or during the animation,
that will affect the values used on every frame of the animation.
Issue #28304520 Strange interpolation of property values holder values
Change-Id: Id6ac19c8369ae34450e6b53d68f5e492b27c577e
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
