summaryrefslogtreecommitdiffstats
path: root/core/java/android/animation
Commit message (Collapse)AuthorAgeFilesLines
* Make LayoutTransition.setInterpolator() actually do somethingChet Haase2013-10-101-5/+33
| | | | | | | | | | | 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
* Merge "Reversing immediately after starting animator ends it" into klp-devChet Haase2013-09-111-0/+2
|\
| * Reversing immediately after starting animator ends itChet Haase2013-09-061-0/+2
| | | | | | | | | | | | | | | | | | | | | | 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
* | Transition API changes from API council recommendationsChet Haase2013-09-042-14/+4
|/ | | | | | | Issue #10460684 KLP API Review: android.view.transition and android.animation Issue #10570740 Transitions: inflate transition targets from xml Change-Id: I7a3f6d3aece2fcafc5efd555d033f79e86635c98
* Fix typo in JavaDoc for TypeEvaluator.Sascha Haeberling2013-08-151-2/+2
| | | | Change-Id: Ice2b2db117e1f91ad70ed55d4cc0b14b86804c1c
* pause/resume for AnimatorsChet Haase2013-08-124-5/+257
| | | | | | | | | | | | 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
* Optimize calls to Trace for animatorsChet Haase2013-06-041-4/+8
| | | | | | | | | | | 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
* Give animators more useful names in systraceChet Haase2013-04-242-4/+40
| | | | | | | Also, fix ObjectAnimator.getPropertyName() to return useful info for ObjectAnimators not created with string-based property names. Change-Id: If7ab6dbcc3be13f5978840b02f4a91ef7eee1c50
* Remove Animatable interfaceChet Haase2013-04-162-81/+50
| | | | | | | | | 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
* Merge "API and doc cleanup, plus small animation/UI features" into jb-mr2-devChet Haase2013-04-124-48/+108
|\
| * API and doc cleanup, plus small animation/UI featuresChet Haase2013-04-124-48/+108
| | | | | | | | | | | | | | | | | | Adding features which round out the animation APIs (missing getters, etc.). Also fix doc typos. Issue #8350510 Add APIs needed for future animation capabilities Change-Id: I063736848ba26e6d6c809b15fc3a103c74222f46
* | Trace ValueAnimator based animations in systraceRomain Guy2013-04-101-10/+13
|/ | | | Change-Id: I1a81e157dea46743a737ed864f4aa0781651ccfd
* Make adding views specific to a ViewGroup's overlayChet Haase2013-04-081-1/+1
| | | | | | | | | | | | | | | | | | | | | | Adding views to views (possible with the new Overlay API) is weird. This change moves the view-management facilities of Overlay to a subclass that is specific to the overlay returned from ViewGroup.getOverlay(). So now you can add drawables to all view overlays, but only add/remove views to/from the overlay returned from ViewGroup.getOverlay(). Also, the previous approach of using an interface for Overlay was changed to classes for both ViewOverlay and ViewGroupOverlay. Finally, this change makes not handling touch correctly the proper, and documented, behavior of overlay views. There are various tricky issues to sort out with input in overlays (including click handling as well as focus) and we don't want developers starting to use overlays as some kind of general container hierarchy, so we're purposely constraining overlays to have visual-only behavior. Issue #8459085 Overlay needs to handle touch correctly Change-Id: I207b8dbf528f87c92369d270d8b0a6556826d207
* Adding small animation featuresChet Haase2013-04-041-0/+45
| | | | | | | | | | RectEvaluator is useful when animating object bounds. The other change is a hidden API that allows temporary suspension of layout, useful for animations which need to animate view bounds without conflicting with layout passes that might happen in the middle of the animation. Change-Id: I3dc08cb6ec455dfa3409e825506b218d3ea63d7a
* Add auto-cancel ability to ObjectAnimatorChet Haase2013-03-202-8/+83
| | | | | | | | | | | | Add a method that enables a new auto-cancel option to ObjectAnimator. When set, any ObjectAnimator (when started) will cause any running ObjectAnimator instance (with that flag set) that has the same target and properties to cancel() itself prior to starting the new one. Issue #7426129 Add auto-cancel to animators Change-Id: I586659c365289cdb9afb6c416bdbaf5630477149
* Merge "Reset reverse state when an animator ends" into jb-mr2-devChet Haase2013-03-151-0/+1
|\
| * Reset reverse state when an animator endsChet Haase2013-03-151-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Seeking an animation after the animator has reverse()'d to the beginning will result in seeking in reverse. Starting the animation will make it proceed normally, and calling reverse() will also give expected behavior. But seeking causes this unexpected behavior because the state of reversing is not reset until the next time the animation is played (either by start() or reverse()). Fix is to reset the internal flag when the animator ends. Issue #8234676 Reversing an Animator Leaves it in A Reversed State Until Explicitly Started Change-Id: I9d212ae1879aa277d1add7eb4c7ec61432af059e
* | Merge "Log warning when animator detects NaN value" into jb-mr2-devChet Haase2013-03-151-2/+15
|\ \
| * | Log warning when animator detects NaN valueChet Haase2013-03-151-2/+15
| |/ | | | | | | | | | | Issue #8350458 Add exception to Animators when NaN detected Change-Id: I926c3f35b661b0bb1d9e3c7c0df55e7513734589
* | Use same default duration (300) for animator resources as for other animatorsChet Haase2013-03-151-1/+1
|/ | | | | | Issue #7492926 Animator resources should use same default duration as code-created Animators Change-Id: I337a2c37ff26ebb6cb8b2fb2b58523c464af518b
* am 768d9e1a: Merge "Correct executable bit for source files"Kenny Root2012-11-071-0/+0
|\ | | | | | | | | * commit '768d9e1a72ceee7d4a5f608776b87b62d6ce4a04': Correct executable bit for source files
| * Correct executable bit for source filesKenny Root2012-11-071-0/+0
| | | | | | | | | | | | | | | | | | Many media files and source code files were marked as executable in Git. Remove those. Also a shell script and python script were not marked as executable. Change-Id: Ieb51bafb46c895a21d2e83696f5a901ba752b2c5
* | end() a reverse()'d animation correctlyChet Haase2012-09-121-7/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | Previously, an animator that had been reverse()'d (and was thus playing backwards) would not end() at the right value. That is, a call to end() would cause the animation to snap to its original end value, not the reverse-playing end value (i.e., its start value). Logic to handle calculating the proper end value was not taking the reversing behavior into account. Issue #6583656 When you call end() after calling reverse() on an animation that has not started leads to forward animation finishing. Change-Id: Ifca60a32d4973c21b85aed9c459f802526c0207e
* | Fix clone() for Animators with just a 'to' valueChet Haase2012-09-101-3/+7
| | | | | | | | | | | | | | | | | | | | | | Previously, clone() on an Animator with only one value would mistakenly think that the clone had a real starting value (which would end up being 0 in the int and float cases). Fix is to set the 'mHasFirstValue' flag appropriately for the clone, based on the state of the cloned animator. Issue #7106442 ObjectAnimator.clone() does not work properly for single parameter Change-Id: I08bf03b7687a65eb613c1671a58e4cbfae66a30e
* | Make animators more robust against ending mid-streamChet Haase2012-08-161-18/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The logic in the frame processing code of ValueAnimator did not handle the situation of animators being ended while the current animation list was being processed. In particular, if a call to an animation update (which could result in a call out to user code) caused that animation, or other current animators, to end, then there was the risk of running off the end of the list of current animators. The fix is to work from a copy of the current animator list, processing frames on each one only if they also exist in the real animations list. Issue #6992223 Frequent System UI crash Change-Id: I742964558f8354f04c311b7b51c7686f26a4dacf
* | Apply ValueAnimator scale factor immediately in WM.Jeff Brown2012-08-151-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Normally the ValueAnimator scale factor is applied the first time a ViewRootImpl window session is created but that may be too late for animators created by system services that start early in the boot process. So set the scale factor immediately whenever the setting changes. Also make ValueAnimator.getDurationScale() accessible (but @hide) for custom animators that want to apply the same scale to their animations. Change-Id: I0f5a750ab5b014f63848445435d8dca86f2a7ada
* | New status bar capable of multiple sliding panels.Daniel Sandler2012-08-131-0/+6
| | | | | | | | | | | | | | There are some visual glitches but almost everything should be put back pretty much where it was. Change-Id: I2f9b0591d44599b07bd83f03c4e09e6dd98e1448
* | Fix shift/mask error in ArtbEvaluatorChet Haase2012-08-091-2/+2
|/ | | | | | | | | | | | Shifting from the left copies the MSB along with it. This causes a problem in ArgbEvaluator, which shifts the top byte down by 24 for the start/end colors, and then uses those values to interpolate alpha values. The correct appraoch (used with the other color components) is to mask by 0xff after the shift. Issue #6960514 External bug: ArgbEvaluator can't evaluate alpha value properly Change-Id: I750d38ddfecc5f30d8dab7c6d27d1a7ac06361c3
* docs: fix several linksScott Main2012-06-221-1/+1
| | | | Change-Id: I89d9fd64dc22c90680bb05415cc966c255165af9
* Clone the list of listeners before notifing any event.Luca Zanolin2012-06-191-16/+36
| | | | | | | | This is required, otherwise the listener cannot remove it-self from the list of listeners during the notification. Bug: 6692355 Change-Id: I07762feb4f9b97ec4b6148d2f604d53e266b84d7
* Skip LayoutTransition animations on objects of size (0,0)Chet Haase2012-06-011-0/+8
| | | | | | | | | | | | | | LayoutTransition runs changing animations on all objects that change between now and the next layout. This works in most normal situations, but when a container is becoming visible, or being added to its container, or other first-time situations, then some of the views and parent hierarchy may be of size (0,0). The user really shouldn't need to see an animation up from these nonsense values, so we just skip running the animation on these objects and simply place the objects where they need to go. Issue #6597648 view should not animate up from size (0,0) Change-Id: I2c355a68bf1ce3b41fbec01ad95c78d83562ba32
* Avoid running layout transitions on unattached views and windowsChet Haase2012-05-231-0/+9
| | | | | | | | | | | | | | | | | | | | LayoutTransition causes artifacts in some situations where a window is just becoming visible or a container is just being added to the view tree when animations are kicked off in LayoutTransition due to the normal automatic mechanism of running animations when views are added/removed/etc. The problem is that containers in these situations may have children with positions and sizes of (0, 0), causing the animation to animate from this default/nonsense value to whatever is appropriate for the views when they are first laid out and drawn. The end result is correct, but the animation is superfluous and silly. The fix is to avoid running any kind of transition animation on windows that are not currently visible or containers that are not currently atached to the view hierarchy. This should avoid the situation by only allowing the animations to run after the containers and windows are visible and set up correctly. Issue #6544410 issue with layout transition when first showing the activity Change-Id: I737b2598887ef806dec3b02a483a8e8ff2c3d4e2
* Improve animation timing.Jeff Brown2012-05-071-1/+1
| | | | | | | | | | | | | | | Detect when a vsync message was significantly delayed which may indicate that a frame was skipped. When this happens, update the frame time to reflect the approximate start time of the current frame instead of the start time of the frame that was skipped a long time ago. Removed an unnecessary call to getCurrentPlayTime() in the animator framework. The result was always zero and the call just made the code confusing. Bug: 6443611 Change-Id: I92b24f7ffd74c59b75a727b6bfc0bb51fc92a73a
* Better error logs for faulty ObjectAnimatorsChet Haase2012-05-031-10/+22
| | | | | | | | | | | | Previously, if you set up an ObjectAnimator with the name of a property which could not be resolved to an existing method (e.g., "foo" becomes "getFoo()" or "setFoo()"), the errors in the log could be a bit obscure and the animation might just crash sometime later with an unexplained NPE. This change provides a more detailed log message detailing the actual method/class involved. Issue #5990756 NullPointerException on no such property Change-Id: Ic5bf7069c4879623e00ab8a794b799773cce487c
* Use choreographer frame time to schedule animations.Jeff Brown2012-04-262-61/+45
| | | | | | | | | | Instead of using the current uptime millis, which can exhibit substantial jitter depending on when the code runs, use the current frame's vsync time when performing animations. The frame time provides a more consistent pulse. Bug: 6375101 Change-Id: Icf307cd8524246607db7496c6fef9a5eeb7c0439
* Fix logic of animator start/cancel/end callbacksChet Haase2012-04-172-17/+35
| | | | | | | | | | | | | | | | | The callbacks for animators in some corner cases were not being called correctly. For example, startDelayed animators that were started and then ended didn't send out the proper events. This CL fixes that logic. Specifically: - An animator that is end()'d will implicitly start() itself and then assign an end value. This was already the case, but listeners were not getting notified. Now this situation causes callbacks to listeners for both the start and end events. - startDelayed animators that are end()'d or cancel()'d prior to finishing the startDelay phase will send out events (start and cancel/end, as appropriate) to listeners. Change-Id: I40a0f2fdb19d9ec7c3726a91363686c6ecb7d915
* Adding new CHANGING transition to LayoutTransition.Chet Haase2012-04-171-64/+273
| | | | | | | | | | | | | | | LayoutTransition used to depend on child views being added/removed or shown/hidden in the transition container. These evens would trigger animations to fade the child view as well as those to animate the side-affected changes to sibling views. This CL enables a new feature in LayoutTransition that enables animating any changes to the layout of the children in the container whenever a layout occurs. For example, you can change the LayoutParams of a child view and call requestLayout() to automatically animate those changes. This capability is not enabled by default. To enable, call the new LayoutTransition.enableTransitionType(LayoutTransition.CHANGING) method. Change-Id: I4d07a3b36245353b2151f0dca4f75080ab6a4592
* Fix AnimatorSet duration issueChet Haase2012-04-121-5/+9
| | | | | | | | | | | | Setting the duration on an AnimatorSet should propagate that value to its children. This works, but only if all children are added to the set before setDuration() is called. This fix delays that propagation until the set is started, making it possible to have a more flexible order of when the children are added and when the duration is set. Issue #6324904 AnimatorSet durations too long Change-Id: I797971c2310eb2e3fe931b4aa35de505f2a519f7
* Enable vsync traversals by default.Jeff Brown2012-03-291-1/+1
| | | | | | | | | | | | Improved how the various callbacks are managed and sequenced to reduce code duplication. Added a heuristic to avoid postponing traversals until the next vsync frame if we did not actually do any drawing during the previous frame. This helps in the very common case where drawing occurs in response to input. Change-Id: I277d9eeaf50408f8745a3cfd181db1d140770658
* Reduce redundant animation processingChet Haase2012-03-161-11/+13
| | | | | | | | | | | | | | | | Starting several animations will place separate events onto the animation queue, which may cause the active animations to get processed more than once in any frame when one of those start messages is processed. This change moves the logic of starting pending animations into the animation frame processing itself. Now when a start event is processed, it only calls the animation frame logic if there are unstarted animations pending. Issue #6172602 Inconsistent animation callbacks Change-Id: I3a546f0c849f42b2dd998f099fcdfafd7d780ad9
* Fix obvious typos under frameworks/base/coreKen Wakasa2012-03-092-3/+3
| | | | Change-Id: Ia5fc3db1bb51824e7523885553be926bcc42d736
* Use the Choreographer for Drawable animations.Jeff Brown2012-03-071-1/+1
| | | | Change-Id: Ifcbf33434bf3c32d1900fd0b3f5bde004604ce8a
* Simplify Choreographer API.Jeff Brown2012-02-151-15/+9
| | | | | | | | | Removed the listeners and schedule animation / draw methods. Instead all requests are posted as one-shot callbacks, which is a better match for how clients actually use the Choreographer. Bug: 5721047 Change-Id: I113180b2713a300e4444d0d987f52b8157b7ac15
* Make the TimeAnimator class public.Chet Haase2012-02-031-12/+11
| | | | | | | | This class has existed since ICS, but was hidden. This change just makes it public API. Also, cleaned up some internal javadocs. Change-Id: Id69408446ced183e01d2b065a67397eb305d9665
* Fix bug in LayoutTransition that caused views to stay invisibleChet Haase2012-02-021-14/+16
| | | | | | | | | | | | | | | | | | LayoutTransition side-effects the alpha property on View to fade views in and out. This works fine if the layout transition is always used on those views' container. But if you fade out a disappearing view and then set the transition to null on the container and set that view to VISIBLE, there is no transition logic to restore the alpha value to 1 (opaque). The fix is to always restore alpha to its pre-animation value when fading the view out. Also, added extra info to alpha and the various View transform properties to help hierarchyviewer debugging. Issue #5958434: LayoutTransition temporary disablement may leave some views invisible Change-Id: I3c21b0e7334dc29c10c5e372b589f0e2b59c2883
* Add Developer Option setting for Animator scaling.Chet Haase2012-02-021-11/+9
| | | | | | | | | | | | | | | | This new setting allows users to set a scale factor for the duration and startDelay of all Animator-based animations. This setting is very similar to the Transition animation scale and Window animation scale settings, except this one applies specifically to Animator animations. The property is only accessible by users through the Settings UI, not programmatically. The value applies system-wide and is picked up per-process at the time of the first ValueAnimator construction. This is an update to a previous CL; this approach uses the WindowManager to store the animator scale settings, instead of SystemProperties. Change-Id: I8295fab060aa6d597ae507ded8f9c9d6077be966
* Add Developer Option setting for Animator scaling.Chet Haase2012-02-011-4/+20
| | | | | | | | | | | | | This new setting allows users to set a scale factor for the duration and startDelay of all Animator-based animations. This setting is very similar to the Transition animation scale and Window animation scale settings, except this one applies specifically to Animator animations. The property is only accessible by users through the Settings UI, not programmatically. The value applies system-wide and is picked up per-process at the time of the first ValueAnimator construction. Change-Id: I3d5fbc956695c88d01c30820259da3e107ffd8a3
* Fix bug in LayoutTransition for INVISIBLE viewsChet Haase2012-01-301-10/+70
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When a view is becoming VISIBLE or INVISIBLE in a container with a LayoutTransition, animations run to fade the view in and out and also to run 'changing' animations on the view's other siblings. This logic also cancels any running 'changin' animations to account for new ones running. However, in the specific case of INVISIBLE changes, there will be no layout changes in the container - layout has already accounted for that view (unlike in the case of GONE views); the visibility is just a matter of drawing the view (or not). Therefore, we're canceling 'changing' animations that should continue running and not replacing them with any other animations, since new animations would only be started on layout chnages which are not forthcoming. One artifact seen from this bug is that the navigation bar buttons sometimes disappear when changing orientation. This is because the menu button may toggle between VISIBLE and INVISIBLE, causing animations on the other buttons to get canceled, which leaves those views in a completely wrong state. The right thing to do is to avoid canceling in-process 'changing' animations and to skip the logic of setting up new 'changing' animations which won't fire anyway. There is some minor API work in here because we did not previously have the necessary information in LayoutTransition to know whether a view was being hidden or shown to/from the INVISIBLE state. Issue #5911213: LayoutTransitions ending in an odd state Change-Id: I5c60c8583c8ea08965727b4ef17b550c40a3882c
* Bug fix for android.animation.LayoutTransition getStartDelay (int ↵Rajdeep Dua2012-01-051-4/+4
| | | | | | | | transitionType) Bug Id : 5813366 Change-Id: Icc482ad820a91a1896c61db67bb6b95cc2ae4c5b
* am 201469f5: am bb7f590a: Merge "docs: Add developer guide cross-references, ↵Joe Fernandez2011-12-224-5/+26
|\ | | | | | | | | | | | | Project ACRE, round 4" into ics-mr1 * commit '201469f54522436be79d4d6665721049bfc74320': docs: Add developer guide cross-references, Project ACRE, round 4
generated by cgit v1.1 at 2024-09-19 18:05:50 +0000