monline

Boot animations on Android devices are (usually) played by the /system/bin/bootanimation executable. As it happens, the source of this executable is available (as part of Android) in the official repository in the platform/frameworks/base section. You can easily check it out with the git clone https://android.googlesource.com/platform/frameworks/base command (however be ready for a 600-700 MB download ). Afterwards you can jump to any released (tagged) version by specifying a tag, eg. git checkout android-4.0.1_r1 will roll back the repo state to the first released version of Ice Cream Sandwich.

Once it's done, you'll find the source of this utility in the base/cmds/bootanimation subdirectory. The essential stuff is in BootAnimation.cpp. I've attached the initial version of this file from all major Android versions for easier reference/review in case somebody is looking for it (as I was).

If you're not really into C++, you can read a pretty nice guide on making boot animations here. It's not yet updated (at the time of writing, ie. 15th July 2012) with Jelly Bean's new features (afaik only the "c" part type is new in this release), but it's still quite detailed.

However if you do look into the sources, you can see that feature-wise (i.e. in the syntax and interpretation of desc.txt) there was no change between Eclair (2.0.*/2.1.*), Froyo (2.2.*), Gingerbread (2.3.*), Honeycomb (3.*) and Ice Cream Sandwich (4.0.*). But Jelly Bean (4.1.*) did bring a few small changes. Up til now the first character of an animation section (ie. a "part") line had to be the "p" letter. From now on it can be any letter. If it's a "c", then the given part will be played (at least once) to it's end despite of the state of the boot process. If it's not a "c", then it'll behave like it did in earlier versions with the "p" letter ... i.e. it'll stop the animation when the boot process finishes.

Using the "c" animation type (it's called "pathType" in the source) makes boot animations more portable since boot time varies between devices (makers and models) and using "c" the boot animation playback time can be independent of the length of the boot process on the given device ... it'll be guaranteed that the boot animation is played back to it's full length (at least once) and not interrupted whenever the boot process finishes. This is true for infinitely looping parts too (ie. where the repeat count for the part is specified as zero) and means that the given part will be played back one time for sure and after that it'll be played till the boot process finishes ... and when this happens, the given part will play to it's end (it's not going to be interrupted in the middle) and the playback will advance to the next part (if there's any).

In case of the Jelly Bean boot animation the desc.txt looks like this:

The first line sets width and height to 640, and the FPS to 24.

The first animation part is in the "part0" directory (it consists of 20 PNG images, starts with a fully black frame and shows a colored "X" appearing), so it'll take 0.83s to be played back. The repeat count is 1 and the animation type ("pathType") is set to "p", meaning that it can be interrupted by a finished boot process ... but most probably there're no devices yet that'd boot Jelly Bean under 1s.

The second animation part is in the "part1" directory, it's type is "c" and is set to repeat infinitely. It consists of 80 PNG images showing the colored "X" animated (each "leg" of the "X" is brighting up for a moment in the animation and the sequence is made to be a perfect loop). Now this segment is repeated (due to the "c" animation type) until the boot process finishes. When this happens, the playback of the segment is finished to the last frame and processing advances to the next segment.

The third (and last) animation part is in the "part2" directory, consists of 10 PNG images, it's type is "c" and is set to repeat infinitely. But actually the repeat count could have been anything since at the time we get here, the boot process is already finished, so the playback of the part will stop after the first time anyway. This animation shows the "X" disappearing, the last frame is fully black (just as the first in the first segment).

So as you can see, the new "c" part type (or "pathType") makes it possible to create "full" animations that are not just interrupted whenever the boot process finishes, but allow for a nice fadeout (finished ending) for the animation.

Btw. the "s" (~sound) lines are not supported by the stock bootanimation code. If your device does interpret these lines, then it's a custom extension made by the manufacturer of your device. Imho portable boot animations do not use any sounds (but actually if you put an "s" line in your desc.txt, the stock Android bootanimation will simply ignore it ... so no worries. ).

Moreover since the image decoding is done by SkImageDecoder, it's entirely possible that besides JPG and PNG files other formats (like BMP, ICO, GIF) are supported as well. It depends on which version of SkImageDecoder was used in Jelly Bean.

Update (2013.03.10): the new Jelly Bean (4.2.*) did not bring any new features, only minor API compatibility changes were made.

Attachment	Size
BootAnimation-v1.6_r1.cpp	7.76 KB
BootAnimation-v2.0_r1.cpp	15.57 KB
BootAnimation-v2.2_r1.cpp	16.28 KB
BootAnimation-v2.3_r1.cpp	16.28 KB
BootAnimation-v3.2.4_r1.cpp	17.08 KB
BootAnimation-v4.0.1_r1.cpp	17.12 KB
BootAnimation-v4.1.1_r1.cpp	18.73 KB
BootAnimation-v4.2_r1.cpp	18.91 KB