This release fixes a potential memory leak that might cause fragments to be retained by AdditiveAnimator animations, especially infinite animations. There is a breaking API change with regards to cancelling animations to catch this kind of leak easily: cancelAnimations() has been replaced with cancelAnimationsForObject() and cancelAnimationsInCollection().

Also, don't forget to cancel your infinite animations when the fragment/view is being destroyed!

See below for a short explanation of the issue*.

Furthermore, a new API for building animations has been added that allows simple orchestration of multiple AdditiveAnimator instances. Three new methods are available: AnimationSequence.playTogether(), AnimationSequence.playSequentially() and AnimationSequence.playWithDelayBetweenAnimations(). Each of these methods takes a List<AnimationSequence>, so the calls to these methods can be nested like this:

AnimationSequence.playSequentially(
    AnimationSequence.playTogether(…),
    AnimationSequence.playSequentially(
          AdditiveAnimator.animate(…),
          AnimationSequence.playTogether(…)
    )
).start();

Although this syntax doesn't introduce any new features to the library, it does provides a different way of building animations through composition – which can map more nicely to specific architectures. For example, it allows outsourcing some of the animation creation code to different methods without passing around an AdditiveAnimator object. The API is also made extensible, so you can provide your own AnimationSequence implementations – for example, adding support for keyframe-based animations with relative timings would be relatively simple with this approach.

*Explanation for the breaking change: Since cancelAnimations() was overloaded to both take an Object and a List<Object> as a parameter, the compiler couldn't know which one you meant when you passed in an ArrayList – and it would incorrectly call the one taking an Object, causing the animations to not actually be canceled.