# AndroidAnimationExercise: five Fragments, one Kotlin module, two branches

> AndroidAnimationExercise gathers Android animation and custom view code written during one developer's daily work into 5 Fragments plus a Kotlin module named imitate. New code goes only into imitate, while the Gradle plugin material that depended on the Transform API was deleted from main at AGP 8.0.

**REBOOTERS/AndroidAnimationExercise** — Various Android animation implementations, summarizing frame animation, tween animation and property animation.

- Repository: https://github.com/REBOOTERS/AndroidAnimationExercise
- Stars: 2,117 · Forks: 364
- Language: Java
- License: Apache-2.0
- Published: 2026-10-14 · Updated: 2026-10-14 · Language: en
- Canonical page: https://hysenlabs.com/projects/rebooters-androidanimationexercise

## A code archive split across five Fragments, not a library

AndroidAnimationExercise collects the Android view code its author wrote during daily development and while writing blog posts, with animation and custom views as the declared subjects. The shape is an app you scroll rather than a library you import: the accumulated code is grouped into 5 Fragments, and each entry is one small effect that you read next to the running screen.

The sorting is by technique, not by platform area. ImitateFragment holds copies of effects from shipping apps, TraditionFragment holds frame animation and tween animation, PropertyFragment holds property animation, ViewsFragment holds custom drawing, and OtherFragment takes everything with no obvious home. Several entries link out to a written walkthrough instead of carrying in-file commentary, including the Alipay payment animation and a separate article that compares the two animation families, so part of the explanation lives off the repository.

That makes this a reference set rather than a dependency. You open the effect you need, copy the code, and own it afterwards. The README gives no artifact coordinates and no compatibility range, so treat every class you lift as code you will maintain on your own schedule.

## New effects go into the Kotlin imitate module, not app

The stated reason for the split is build time. As animation effects accumulated, the code inside the project grew, and both running and compiling slowed down, so a separate imitate module was carved out and all new content was routed there. Everything inside imitate is written in `kotlin`, while app stays as the historical accumulation, explicitly parked as code that should not change much.

The same paragraph gives imitate two roles. It can sit as a dependency component of app, or run on its own as a standalone application, and the switch lives in `gradle.properties`. Page jumps across that boundary are handled by ARouter, which the author credits with solving the navigation problem outright.

Two details a skim misses sit in that paragraph as well. The property name inside `gradle.properties` is never written down, so learning how to flip between dependency and standalone means reading the module build script yourself. And the repository's primary language is Java while all new work is Kotlin, which means a fresh clone mixes 2 languages in one Gradle project. The topic tags add coroutine, coroutines-android, jetpack-android and motionlayout, and not one of them gets a line of prose in the README.

## What each Fragment actually demonstrates on screen

TraditionFragment is the shortest list and the most dated: frame animation and tween animation code, a frosted glass demo built on Blur Android, an Activity transition animation, and a ViewPager transition animation.

PropertyFragment is the busier half, carrying an Alipay payment animation, an Ele.me add-to-cart animation, the official Viewgroup animation demo and a Reveal Animation. ViewsFragment collects the drawing work instead: a PlayView driven by property animation, custom view basics, a Drawable wave animation, and a 3D province-city linkage wheel described as looking like the iOS one. Its heading carries an instruction to close that section first, which is the only admission of unfinished state anywhere in the README.

OtherFragment is where everything else lands: saving a screenshot into the phone album, a puzzle game that inherits from RelativeLayout, Java calling JavaScript inside a WebView, opening the Camera or the gallery and compressing the bitmap so the app does not run out of memory, a Bottom Action Sheet menu, and Bitmap LRUCache with `LruDiskCache` on the side. Read that last entry carefully if you came for animation, since cache eviction is a different subject that only shares the module.

## Getting the app on a phone when no install command exists

There is no clone command, no Gradle invocation and no required Android SDK level anywhere in the README, so a first run has to be assembled from what the repository does publish. Two routes exist. The fast one is the prebuilt apk linked under the scan-to-try heading, and the honest one is to build from source with the wrapper committed at the root.

The prebuilt route is a single link:

```text
http://d.7short.com/tm15
```

The build route looks like this at the top level, with the wrapper scripts and the module folders beside each other:

```text
.github/
.gitignore
.travis.yml
LICENSE
README.md
animationkey
app/
build.gradle.kts
diagram.svg
docs/
gradle.properties
gradle/
gradlew
gradlew.bat
imitate/
imitation.jks
settings.gradle.kts
subs/
```

Run `gradlew` on macOS or Linux and `gradlew.bat` on Windows from that directory, and expect `settings.gradle.kts` to decide what actually builds. Here is the catch: the README names neither the Android Gradle Plugin version nor the JDK level the wrapper expects, and the CI badge points at an `android.yml` workflow without publishing what it runs. A build on a current toolchain can fail before a single line of animation code is compiled.

## AGP 8.0 removed the Transform API and split the branches

The Gradle section is where this project admits its own breakage. Gradle removed the Transform API starting at AGP 8.0, which made the build pipeline instrumentation described here inapplicable to any newer toolchain. The response was surgical: the code was deleted from the `main` branch, the work still compiles and can be studied on the `master` branch for anything below AGP 8.0, and a rewrite on the new API for main was announced as future work rather than delivered.

What that instrumentation does is worth knowing even if you never run it. 5 capabilities are listed under `buildSrc`: renaming the generated apk per flavor, printing every task in the build with its duration so slow compiles stand out, timing annotated methods and classes during the build, instrumenting click events in your own code, and applying configurable instrumentation to third-party library code to add behaviour you could not otherwise inject.

The cost is split across 2 branches that behave differently. If you are on AGP 8.0 or later, that half of the repository is prose plus a branch name, not code, and the topic tags still carry transform and asm long after the directory that used them was dropped from main.

## The buildSrc recipe describes a directory main no longer has

Here is the contradiction a close read turns up. The README spends a section describing custom Gradle content inside `buildSrc` and then lists what it does, yet the top level of `main` carries no buildSrc entry at all: what sits there is `.github`, `.gitignore`, `.travis.yml`, README.md, animationkey, app, build.gradle.kts, diagram.svg, gradle.properties, `gradlew`, `gradlew.bat`, imitate, `imitation.jks`, `settings.gradle.kts` and `subs`. The pipeline being described lives on the other branch, so on main the Gradle story shrinks to what the root scripts and the module build files do.

The module count deserves the same scepticism. There are 3 folders that look like modules, app, imitate and subs, and only 2 of them appear in the README. subs is never explained, nor are animationkey, docs or diagram.svg, and none of the 4 has a line of documentation anywhere in the published text. Before you plan around the componentised layout, read `settings.gradle.kts` and `gradle.properties` yourself, because the written description covers 2 of the 3 module folders and names neither the switch nor the flag.

## Two CI systems, a committed keystore, unexplained root folders

Continuous integration shows up twice in the root. A `.travis.yml` from the Travis era sits beside a `.github` directory whose workflow file, `android.yml`, supplies the Android CI badge at the top of the README. Two generations of CI in one repository usually means one of them is history, but the README does not say which is authoritative or whether that workflow still runs, so a green badge is not evidence that your local build will pass.

More pointed for anyone copying code out of here is `imitation.jks`, a signing keystore committed at the repository root. Nothing in the README says what it signs or whether the apk offered through the download link was signed with it. Treat any key found in a public sample repository as unknown until you check which Gradle signing config points at it, and keep your own signing keys out of a project you import this way.

The last push landed on 2026-09-10 and the repository is not archived, so the layout described here is the one a clone gives you now. Code is published under the Apache-2.0 licence, so a file you copy keeps its notice and attribution terms with it.

## Hand-written animation against constraint sets and Compose links

Most of the recipes here are imperative: you write code that drives the animation rather than declaring it in a resource file, which is exactly why reading one class teaches more than reading a description. The repository also carries a declarative route that a skim misses, since one screenshot is labelled ConstraintLayout AnimationSet animation and the topic tags include motionlayout. Keyframes and transitions there live in XML files that can be reviewed as data and diffed like any other asset, where the property animation code in PropertyFragment can only be reviewed as code.

Then there is Compose. The section exists, and it holds exactly 2 links, one to a Jetpack Compose series and one to a page about which Compose API to use. No compose module appears in the root tree and the tags still lead with android-view, so the project's Compose story is reading, not migrated code. Anyone starting a new screen on Compose gets behaviour reference from these files, and still writes the port by hand.

That is the trade-off in using this repository: hand-written Java and Kotlin you can trace line by line, or declarative XML and Compose you can diff, with the cost of owning whichever one you copy.

## Conclusion

AndroidAnimationExercise is worth browsing as a reference shelf and not worth depending on: 5 Fragments of readable animation and custom view code, with imitate as the one module its author intends to keep growing. Copy an effect when you are stuck on radar scans, add-to-cart motion or a province-city wheel, and leave the Gradle plugin material alone unless you build below AGP 8.0, because main no longer holds it. Before you reuse any signing setup, check what imitation.jks was committed for and treat that key as public.

## FAQ

### What is AndroidAnimationExercise used for?

It is a sample app that collects Android animation and custom view code from one developer's daily work and blog writing, sorted into 5 Fragments covering imitations, traditional animation, property animation, custom views and other items. Nothing is packaged for reuse, so the value is in reading and copying the individual effects.

### Which module should new animation code go into?

The imitate module. Everything inside it is written in kotlin, app is kept as the older accumulation that should barely change, and imitate can act as a dependency of app or run standalone once you change a setting in gradle.properties.

### Can AndroidAnimationExercise be built with AGP 8.0?

Not the Gradle plugin part of it. Gradle removed the Transform API in AGP 8.0, that code was deleted from main, and the master branch still compiles for anything below AGP 8.0. Porting it to the new API is announced as future work rather than shipped.

### How do I install or try AndroidAnimationExercise?

The README publishes no install or build command. It links a prebuilt apk for download, points a CI badge at the android.yml workflow, and the root ships gradlew and gradlew.bat for a source build; the newest listed version is v5.0.2 from 2026-01-15.

### Does AndroidAnimationExercise contain Jetpack Compose code?

The Compose section holds 2 links, one to a Jetpack Compose series and one to a page about which Compose API to use. No compose module appears at the top level of the repository, and the animation work described is View based.

### What licence is AndroidAnimationExercise under?

Apache-2.0. Files you copy out carry their own headers, so the notice and attribution terms travel with any code you reuse.

## Sources

- [Issues](https://github.com/REBOOTERS/AndroidAnimationExercise/issues)
- [License: Apache-2.0](https://github.com/REBOOTERS/AndroidAnimationExercise/blob/main/LICENSE)
- [README](https://github.com/REBOOTERS/AndroidAnimationExercise/blob/main/README.md)
- [REBOOTERS/AndroidAnimationExercise on GitHub](https://github.com/REBOOTERS/AndroidAnimationExercise)
- [Releases](https://github.com/REBOOTERS/AndroidAnimationExercise/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/rebooters-androidanimationexercise