How do the Android animations work under the hood?

Question

During the past few months, I built an open-source tweening engine in Java (Universal Tween Engine) to be able to easily add smooth animations and transitions to my android games. It works like a breeze for games and is successfully used by many people (mostly in the LibGDX community). The library is generic and can be used to animate anything (Swing UI components, opengl game objects, etc). Now, I want to create an addon to the lib dedicated to android UIs, since I believe it can greatly ease the creation of very complex animations compared to the built-in animation framework.

My lib exposes a .update(float deltaTime) method that has to be called each time you want to update all the running animations. It was tailored for games since every game exposes an infinite loop, but that's not the case for UIs.

Therefore, I was wondering how the animation framework of the Android API works under the hood. Is there a static thread dedicated to animations that runs continuously and updates animations frame-by-frame and get paused until there is a new animation running?

I was thinking about something like that, but I'm not really happy with this code since it doesn't take the device refresh rate into account for instance.

Chabot

+1 for the nice link, great library. – Diacaustic

Answer 1

A good place to start is to take a look at how the Android view system implements it. The joy of open source.

When you call .animate() on a view, you get back a ViewPropertyAnimator which, upon startAnimation() starts a ValueAnimator.

The ValueAnimator has a Handler which drives the loop.

https://github.com/CyanogenMod/android_frameworks_base/blob/ics/core/java/android/view/ViewPropertyAnimator.java

https://github.com/CyanogenMod/android_frameworks_base/blob/ics/core/java/android/animation/ValueAnimator.java

Acicula

Thanks for the links. It seems that animations do not use a different thread, but just a dedicated handler on the current thread message queue. I'm not sure I understand the strategy behind this, this may cause lag and stutters if animating while there are messages coming to the thread... – Chabot

Now that I remember, I read something a while ago saying that Android did the animations differently than iOS. The latter uses a dedicated thread with a maximum priority. This leads to very smooth animations at the expense of data processing and UI responsivness. I'm not sure I don't prefer iOS way... – Chabot

I will try to implement the dedicated thread/queue with max priority with the Tween Engine for Android UIs. We'll see if that's more suitable for eye pleasure. This may even lead to a proof-of-concept to Google that they may be wrong. – Chabot

The iOS way leads to smoother animations AND better UI resposiveness. You don't think smooth scrolling etc means better UI responsiveness? I think Android will eventually have to move to the same model. – Replevin