Lottie Android 5.0

As Lottie’s celebrates its 5th anniversary, Lottie Android 5.0 is ready for release. At the surface are a few new features, but under the hood are a number of significant rendering capabilities, performance improvements, and bug fixes paired with the largest changelog to date.

Supporting Lottie

Lottie Android is built and maintained entirely on nights and weekends. If you are using Lottie in your app, please consider sponsoring us. To do so, click the sponsor button in the top right corner of the GitHub repo. Links to GitHub Sponsors or Open Collective can be found there.

Both platforms have launched new initiatives to streamline payments from organization/business accounts to make it easier for teams and companies to sponsor projects.

Many thanks to Airbnb, Lottiefiles, Coinbase, and Stream for their ongoing sponsorship of Lottie.

With that out of the way, on to the changes!

Stability

Lottie is used in tens (or hundreds?) of thousands of apps and has become the industry standard for shipping high-quality animations and vector assets in apps. As a result, maintaining stability and backward compatibility is extremely important. In this release, I have spent a huge amount of time triaging and fixing numerous long-standing bugs and feature requests that have come in via GitHub. At the time of this writing, there are only 14 open issues and feature requests with over 32,000 GitHub stars. In the past, I have tried to keep open issues under 1 per 1,000 stars but 5.0 halves that.

Rounded Corners

Lottie now supports the Rounded Corners effect for shape and rectangle layers.

Migrating Away From View Layer Types

Since Lottie 1.0, Lottie has leveraged View.setLayerType() APIs. In the hardware accelerated path, this would cause Android to allocate a dedicated hardware buffer for the animation that had to be uploaded to the GPU separately. In the software case, LottieAnimationView would rely on View’s internal drawing cache which draws views to a bitmap and then draws the bitmap to the original canvas.

This was causing a few problems:

• The hardware/software distinction happened at the LottieAnimationView level. That means that consumers of LottieDrawable (such as Lottie Compose) had no way to choose a render mode.
• Dedicated memory for Lottie was always allocated. In the software case, it would be a bitmap that is the size of the LottieAnimationView and in the hardware case, it was a dedicated hardware layer.

In 5.0, Lottie no longer leverages this API. In the hardware accelerated path, Lottie draws directly to the original canvas. In the software accelerated path, it internally manages a bitmap that it draws directly to the original canvas. This provides several key advantages:

• Reduced memory consumption: In the hardware case, no new memory is allocated. In the software case, Lottie will create a bitmap that is the intersection of your View/Composition bounds mapped with the drawing transformation which often yields a surface area that is smaller than the entire LottieAnimationView.
• RenderMode: Lottie Compose and LottieDrawable now support setting a RenderMode.
• Caching: When using software rendering, Lottie will only redraw the bitmap if the underlying animation changes. If it didn’t, it will simply re-draw the same bitmap which is heavily optimized by Android.
• Clipping: Lottie can now render outside of the original composition bounds (see below)

You should not have to change anything in your code as a result of this change. It is intended to be an entirely internal implementation detail that led to the benefits mentioned above. However, this change was paired with many changes to how canvas transformations are handled internally so please file issues if you encounter any.

Rendering Outside Composition Bounds

Lottie for Android has always clipped animations to the composition bounds set in After Effects. However, there are times when you want part of your animation to extend beyond the bounds of the composition. For example, you might want the bounds of a heart animation to be tight around the primary heart shape so it can be aligned with other UI elements on screen but want a sparkle effect when it transitions states to extend beyond its bounds.

Lottie Android and Lottie Compose both offer a new clipToCompositionBounds API that defaults to true and can be set to false. When using software rendering, there is a slight performance overhead in enabling this. Lottie has to measure the bounds of the animation to create an appropriately sized bitmap and then allocate and draw a larger bitmap as a result. This should work in most cases, but hardware acceleration is preferred if you are disabling clipping.

Moving Lifecycle Handling to LottieDrawable

LottieAnimationView has always handled its own lifecycle. It would auto-pause and resume if the view’s visibility or window attach state changed. However, the view lifecycle is a tricky beast. APIs like onVisibilityAggregated were only added in API 24 and subtleties of RecyclerView led to long-standing bugs. In addition, custom usages of LottieDrawable outside of LottieAnimationView were forced to get this behavior exactly right or they could leak animators and impact battery life. Given how widespread Lottie is used, it was important to reevaluate this.

In 5.0, all of this logic has been moved into LottieDrawable via Drawable’s setVisible APIs which are automatically called by all platform views when appropriate. This brings Lottie in line with how other classes like AnimationDrawable behave.

Text and Image Dynamic Properties

Dynamic Properties are a great way to change animations during runtime. They can be used to apply theme colors, tie progress to gestures or events, and much more. However, text and images had separate APIs (TextDelegate and ImageAssetDelegate) due to their functionality predating the full dynamic properties API.

Lottie 5.0 adds support for both text and images to the existing dynamic properties APIs which gives them full support in Lottie Compose and is easier to learn.

Removal of setScale APIs

Lottie has had a setScale API that allowed you to directly scale up/down an animation. This API was created many years ago before Lottie properly supported Android scaling APIs well. Now that support for existing Android APIs has been improved, the expected behavior of setScale is ambiguous. As a result, this API has been removed and it is recommended to use size paired with ImageView.ScaleType, Compose ContentScale, and Compose Alignment APIs instead.

These are just the highlights from Lottie for Android 5.0. The full changelog can be found here. Try it out and show me what you build with it!