A short guide for the curious.
I'm going to use the crDroid Boot Animation as an example for this guide. It's a great example to use as the animation itself lends itself nicely to an elegant folder structure. (You'll see what i mean). The bootanimation.zip is attached to the post and i encourage you to download it and extract the contents to a folder. It'll help you follow along.
First, let's have a look at the Boot Animation in action:
You'll notice there are essentially three stages to this. 1) The static Logo and Text fading in at the beginning. 2) The Progress Bar appearing (and animating left and right). 3) The Loading animation which fills the Bar and ends in everything fading out.
Now have a look at the .zip contents you extracted earlier. For this particular Boot Animation there are three folders, (part0, part1, part2), containing all the .png images and a 'desc.txt' file. You'll notice that all the images are numbered sequentially and each folder is essentially one of the three stages of the animation. It's an elegant way to organise the files, especially when you consider that stage 2 of the animation has to loop for a while. (All the images needed to create that loop are in the 'part1' folder).
You can have as many folders as you need, and how many image files you put in each is up to you. Your structure will depend on your animation. Just remember to begin with a part0 and number them sequentially from there.
Basically the config file needed to specify how the animation runs. let's take a look at the crDroid file:
1080 1920 40
c 1 0 part0 #121411
c 0 0 part1 #121411
c 1 0 part2 #121411
1080 1920 40 - Resolution (Width) x (Height) and framerate (fps) More on this later...
c 1 0 part0 - The letter (c) means 'play this part in it's entirety even if the system is ready'. Most of the time this is all you'll use. The alternative is (p) which tells the system to cut the animation off mid-stream if necessary when it's ready to move on from the Boot Animation.
The first number (1) means 'play this part once and them move on to the next part'. You can of course make it play twice, or more if you want. Just specify the number. A zero (0) here means 'Loop this part'.
The second number (0) defines a 'Pause' on the last frame of that part. (At 40fps putting 20 here would mean a pause of 0.5 Seconds) We have a 0 here, so no pause.
I'm deliberately ignoring the Hex code for now. I'll circle back to this later.
c 0 0 part1 - So now we know what this all means. 'Don't interrupt this part, loop it, and then move on to the next part without a pause'.
c 1 0 part2 - 'Don't interrupt this part, play it once and don't pause on the final frame'.
All things being well you'd be looking at your Lockscreen at this point.
You can see that a bit of simple Math will need to be employed, particularly when deciding how many individual images (frames) you need to create and what fps you'll need to specify for playback. There's more on this in a later guide, but there are many factors to consider. How many pixels to move your image from frame to frame, how many frames you'll be generating in total, and how long you want your animation to run for. (The framerate you select is more of a determining factor in total duration than it is smoothness)
Generally speaking a complex animation will generate more frames and may need a higher framerate to complete within a reasonable duration. Of course you can have an effective animation at 1fps depending on what you are creating. As long as you've got a rough idea of what you want before you start, you can roughly guess how many frames and at what speed you'll need. The whole Boot Animation can be as quick as ten seconds these days, but you can of course make yours longer.
Some things to consider
Images cannot have Alpha (transparency) and should be saved as 24bit .PNG or as .JPG. If your animation is simple and already small there's no reason to compromise on quality. .PNG will be fine. When you have 500+ frames with a large, high quality moving image, the total size of your Boot Animation can easily exceed 300MB. There's more on this in a later guide, but .JPG @ 90% quality will reduce the overall size significantly without being noticeable.
When numbering your images, you will need to prefix your filenames with a certain number of zero's. How many depends on your total images in the animation. For example, if the total number of images is less less than 1000, (let's say 650 for example), you will need to make all
the numbers three digits. So, 001, 002, 003,... 099, 100, 101.. etc. That will work until 999. If you create a frame that is '1000', then all your images will need an extra '0' at the beginning to make them four digits.
Now, coming back to that Hex code in our desc.txt. One thing you can do to reduce the overall size of your bootanimation.zip is to not use the full 1080x1920 for each image. (You'll notice the ones in the crDroid folders are actually 960x1920). If all the eye candy in your animation is clustered in the centre surrounded by plain background, you only need to create images that are big enough to encompass all the eye candy, not the background. So you might find that your images once cropped are only 800x600, for example. That keeps the size down and makes the whole thing easier to animate.
Right now you're wondering how the system knows what to do with 800x600 images on a 1080x1920 screen. It depends on what you enter in Line 1 of the Desc.txt. If you enter '1080 1920', the 800x600 images will be stretched to fit. If you enter '800 600' the images will be centered and the missing background will be filled in automatically. (Black unless specified by Hex code in the Desc.txt, as seen above)
So the crDroid images are 960x1920 and not quite Black. They're a little lighter. If that resolution were specified in the desc.txt the images would be centered and the background would be filled as specified by the Hex codes. But, the resolution in the actual desc.txt reads 1080x1920, which means the images are being stretched a bit left and right to fill the gap. That means the Hex codes aren't needed in this case. They made a mistake. Oops!
When editing your desc.txt, make sure you hit 'Enter' after the last character of the last line, to begin a new line. For some reason that last line will be ignored unless you do this. Very strange!
Creating your bootanimation.zip
So you have your images in folders and your desc.txt edited ready to go. (If you are using Windows i suggest using Notepad++ for saving any edits you make to the desc.txt, and 'save as type' should be 'all types'.
Now all you need to do is .zip up your creation. I'm using WinRAR. No compression should be used, so in WinRAR you use the 'Store' setting. The archive is of course being named 'bootanimation.zip':
I'm sure everybody knows what to do with a completed bootanimation.zip by now. Either move it manually to System/Media and replace the existing file (Permissions rw-r—r—) or use a flashable zip to deliver the payload. All things being well you now have your very own working Boot Animation!
If anybody has any questions go ahead and ask. I hope some of you will have a go at your own creations!
PS You can learn a lot by reverse engineering. Feel free to download, extract and study any of my own creations. You'll soon see how it all works.