Rive Android is the runtime that plays Rive animations inside an app

What the runtime does and where it sits

Rive is a real-time, collaborative design and animation tool that helps teams create and run interactive, animated graphics anywhere, and the Android repository is its runtime library. The workflow it enables is worth stating plainly. Designers and developers work together in the editor to create a Rive file that responds to different states and user inputs, and the lightweight open source runtime libraries load that file into apps, games and websites. The design consequence is that the behaviour of an animation is a state machine authored in a design tool rather than a set of keyframes and transitions written in code, and a developer connects the two through inputs and data binding. The getting started section points at the Android section of the runtime docs and then at the reference pages for artboards, layout, state machines, data binding and loading assets, which is the vocabulary you need to know before the API makes sense. The library is distributed through Maven as app.rive.rive-android, and the primary language of the repository is Kotlin.

System font fallback, and the locale problem it creates

There is a long section on system font fallback and locale changes, and it reads like a changelog entry for a real bug. System font fallback uses the process's default Java locale to prefer regional font faces, including CJK variants, and this behavior is shared by the legacy and the new Android APIs. Rive.init(context) installs an application-level configuration observer so that locale changes take effect on subsequent fallback lookups, while other configuration changes such as rotation and dark mode leave the font caches intact. The subtlety is in what does not happen. Calling Locale.setDefault changes the default Java locale for the current process, but it does not change the device language and does not send an Android configuration notification, and Rive does not poll for such changes during fallback lookups. So the documented sequence is to set the locale and then invalidate the caches explicitly:

import app.rive.runtime.kotlin.fonts.FontHelper
import java.util.Locale

Locale.setDefault(Locale.forLanguageTag("ja-JP"))
FontHelper.invalidateSystemFallbacks()

For per-app language handling that does not notify the application-level observer, including some AppCompat configurations before Android 13, the invalidation has to be called after the default locale used by font selection has actually been updated, and invalidation does not itself set the locale. It also does not reshape text that is already displayed, since existing shaped text keeps its font references, which is a limitation worth knowing if you change language while a screen is on screen.

Building it, and the flags that control what goes in the AAR

The build begins with Gradle and also includes CMake and Premake at lower levels, and the library is built with the Gradle command:

./gradlew :kotlin:assembleRelease

The output is kotlin/build/outputs/aar/kotlin-release.aar, which is the Android Archive published on Maven. There are two build options for advanced use cases, and both are worth knowing. The first narrows the architectures, since by default the build produces all four common variants, armeabi-v7a, arm64-v8a, x86 and x86_64, and you can select a subset with a property such as -PabiFilters=arm64-v8a, or a comma separated list of several. The second removes the audio engine. Rive Android includes an audio engine by default by linking miniaudio, which allows playback of audio assets from Rive files, and if you do not need that and want to minimise binary size you can exclude it and save 600kb with the -PnoAudio property. The supported versions are a minimum SDK of 21 and a target SDK of 35.

The example app is the real API documentation

The examples section points at the app/ folder for an example application, and the way it is run is worth noting. You set the app build variant to preview to run it, and in Android Studio you select the variant through Build and Select Build Variant. The preview variant uses the hosted Rive dependency, while contributors set the variant to debug, which requires extra configuration, and the CONTRIBUTING.md explains it. The example is worth reading as a document because it covers the ways you actually work with Rive files: including them in a project and referencing them, setting layout and loop mode options, displaying single or multiple artboards in one component, setting up and manipulating a state machine through inputs, handling events, and using a low-level API to build a render loop for more control over the scene. That last item is the one that matters for anyone who has used a simpler animation library, because the runtime exposes a render loop rather than only a play call, which is what makes interactive and game-like scenes possible at the cost of owning the frame timing.

The repository is more than the Kotlin wrapper

The top level of the repository shows how much sits under the Kotlin API. There is a kotlin/ directory for the public surface, a submodules/ directory for the native dependencies, and the .rive_head and .rive_renderer directories, which are the upstream render engine sources. There is a buildSrc/ directory for the Gradle build logic, a compatibilitytest/ directory, a benchmark/ directory, a dev/ directory, and tools/. The MEMORY_MANAGEMENT.md file at the root is notable, because a graphics runtime that loads many files is exactly where memory behaviour becomes a design question rather than an implementation detail, and documenting it separately from the README suggests the maintainers treat it as such. The build is also set up for release through a GitHub Actions workflow with a release badge, and the version file and CHANGELOG.md sit at the root, with releases running at 11.14.1, 11.14.2 and 11.14.3 in October 2026, so the cadence is frequent and the runtime is actively developed rather than maintained.

Troubleshooting points at CMake, and the community is where examples live

The troubleshooting section starts by telling you something useful about the build. Rive Android uses CMake to build the library, and the section goes on to describe an error you might hit, which is the standard advice for a project where the wrapper is Gradle but the real work happens in a native toolchain. The contributing section points at the contributing docs for how to run the project locally, and the issues section asks for both problems with the runtime and API suggestions, with a note that older issues and discussion threads are worth browsing for solutions that may have worked for common problems. For examples beyond the bundled app, the README points at the Awesome Rive repository and the Rive community, which is the pattern for a runtime that has a design-tool ecosystem around it: the runtime covers loading and playback, and the community carries the recipes. The support channels are a Discord and an X account, and the licence is MIT.

Editorial conclusion

Adopt the Rive Android runtime when your designers work in Rive and you want their animations to carry state machines and data binding rather than exported video or hand written motion. Do not adopt it if your animation needs are simple, since a vector animation library adds a native dependency for little gain. Verify first that your minimum SDK is 21 or higher, that the target SDK of 35 matches your app, and that the Rive file format your designer exports is supported by the runtime version you take.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. rive-app/rive-android on GitHub