First my Bona Fides. I make Boot Logo's and Animations for a couple of Oneplus devices. Unless you own these devices you've probably never seen any of the work. (Don't worry, i doubt if you're missing anything). Here's one of the threads: https://forum.xda-developers.com/oneplus-5/themes/mod-custom-boot-logos-animation-op5-t3924397 (It's mostly Boot Logos to begin with so start at the end for the Animations)
Over time i've added a few guides to share what i've learned from making Boot Animations. Obviously the guides, like the work, aren't reaching as many users as they would if they were posted here. So i thought i'd post what i have all in one place where they may be more useful to a larger audience. (I'm almost certain the guides themselves are better than the work!)
Anatomy of a Boot Animation
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:
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
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.
desc.txt
Basically the config file needed to specify how the animation runs. let's take a look at the crDroid file:
Code:
1080 1920 40
c 1 0 part0 #121411
c 0 0 part1 #121411
c 1 0 part2 #121411
Line 1) 1080 1920 40 - Resolution (Width) x (Height) and framerate (fps) More on this later...
Line 2) 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.
Line 3) 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'.
Line 4) 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!
An Oddity
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!
Good luck.
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.
Here's a little more on how the resolution part of the desc.txt affects the image. In this example i'm using the Marshmallow Bootanimation found in this thread. (You've probably visited this thread yourselves at some point): https://forum.xda-developers.com/android/themes/bootanimation-android-marshmallow-t3180984
I'm comparing the 1080p version to the 1440p version. In both all the .png images are 814x214. For example:
The differences lay in the desc.txt:
1080p:
Code:
814 214 60
c 1 30 part0
c 1 0 part1
c 0 0 part2
c 1 64 part3
c 1 15 part4
So, in the 1080p version the resolution in the desc.txt matches the actual image size. The image will be centered on a Black background.
1440p:
Code:
1085 285 60
c 1 30 part0
c 1 0 part1
c 0 0 part2
c 1 64 part3
c 1 15 part4
In the 1440p version the resolution in the desc.txt is larger than the image size. This means the image will be stretched to that size, and then centered on a Black background. The reason it has to be stretched is so it appears the same size, (or the same proportion compared to the screen), as the 1080p version.
Of course, stretching the image isn't ideal as you lose quality. Better instead to use images that are natively larger for the 1440p version, if you have the original assets at the larger resolution.
Useful Freeware Tools
Paint.net:
Most Image editing.
IrfanView:
Batch covert .PDN to .PNG.
GIMP:
More advanced Image editing.
Apply some filters to all Layers with script.
Export all Layers as individual .PNG.
FastStone Photo Resizer :
Batch Resize.
Batch Crop.
Batch Canvas Size.
Batch Overlay/Watermark.
TinyTask :
Macro automation. Incredibly useful time saver!
Bulk Rename Utility:
As name suggests.
GIF Creation:
https://ezgif.com/
http://gifmaker.org/
Image Hosting:
https://postimages.org/
https://imgur.com/upload
I've updated my freeware tools list recently to add the essential Macro tool, TinyTask. This thing is incredible. As the name suggests, it's TINY. At 20KB for the portable .zip, it is after many years, still the smallest automation tool anyone has created. What you get is an equally tiny floating window with all the functions easily accessible. The only one that matters is the 'Record' button though. Hit that and then run through your sequence of key strokes, mouse clicks and keyboard combinations as needed. It even remembers the cursor coordinates, so if you move the mouse to click on something it can repeat that.
Of course, the whole point is to save the time consuming and repetitive parts of creating each frame. Here's an example. The Animation i'm currently working on in paint.net, frame by frame, needs moving two layers each time and at different increments before saving the image as another frame. Here's what it looks like from the beginning without automation:
Click on layer1
Left Arrow x5
Click on Layer2
Left Arrow x2
Ctr+Shift+S (Opens Save Dialogue)
001 (Sequential numbering)
ENTER
Click on layer1
Left Arrow x5
Click on Layer2
Left Arrow x2
Ctr+Shift+S (Opens Save Dialogue)
002 (Sequential numbering)
ENTER
Repeat 1000 times.
OR, with TinyTask:
F12, 01, Enter
F12, 02, Enter
F12, 03, Enter
F12, 04, Enter
(F12 is the key i assigned to play back the Macro)
Not only am i recording all the mouse movements and keystrokes, but even adding the first '0' in the Save Dialogue, so instead of having to type '001,002,003,004...' it's the easier '01,02,03,04'. It becomes a one handed operation where my hand is barely moving from the number-pad. I don't even have to look at the screen. Just focus on inputting numbers until it's done. :good:
The best thing about it is it helps avoid mistakes. Imagine in one or two of the frames done manually where, instead of moving Layer 1 five times, and Layer 2 two times, you accidentally get it the wrong way round. After 1000 frames it's bound to happen at least once. Something like that is really evident when you play the completed animation back....and then you have to fix it. Which can take longer than creating the whole thing in the first place!
Math time...
Here's some more insight into the calculations needed for some of these Animations. We'll use one of the left-to-right traversing animations in my own thread as an example. (Like one of the Enterprise ones.) We begin with an image thats 2560px wide and it's got to cross the 1080px 'window' of our screen. That doesn't mean it has to move 2560px, but 3640px, as it will be 2560px for the 'tip' of the image to emerge on the left until the 'tail' crosses the same point. The tail still has another 1080px to go before it disappears off the Right side of the 'Window'.
So if we move the image 10px to the Right per frame it will be 364 frames total. Problem is 10px at a time for images like these moving across the screen, either horizontally or vertically, is not smooth. Take a close look at the NASA (Space Shuttle) animation. It begins at 1px increments and ends at 9px increments, increasing by 1px every second. You can see the 'acceleration'. It begins smooth, but after five seconds the smoothness deteriorates and by the end is pretty janky. So for traversing images i don't like to go above 5px increments per frame.
So, 3640/5 = 728 frames. This is where we begin to think of framerate. FPS is not a factor in smoothness but of total duration. At 30fps the 728 frames will take 24 seconds. Too long. At 60fps it will take half that. (12 seconds). You can of course use anything in between. 45fps is a good compromise in this case. (16 seconds).
Sometimes with big images setting a higher fps does nothing to speed up the animation beyond a certain point. I assume in these cases it's because it's just all too much for the system to handle. It's not what people expect, but keeping the fps low is easier for the system to handle and results in less jank. The smoothness will actually improve, providing your frame-by-frame movement is no more than 5px.
Of course, one option is to resize that image before beginning to reduce the total number of frames needed to complete the animation. Take that 2560px image and make it 1080px wide and now you only have 2160px total movement. At 5px increments per frame you'll end up with 432 frames. At 30fps it's a reasonable 14 seconds. With the image 1080px wide there will be a point on it's journey across the screen where the whole image is visible at the same time, but of course it will be smaller and more distant too. I personally like the larger image. You don't ever see the whole Enterprise at once, but it's a more cinematic effect...and of course the image is bigger so therefore 'closer' and more impactful.
Smaller images do of course mean less number bashing on the keyboard. It's probably five minutes for 100 frames if you have everything set up right and are using a macro to reduce the inputs needed.
For the animations where the image zooms in and out, like the Enterprise coming and going, it's surprisingly easy for the system to handle. Much easier than the transistioning images. For these i resize the image 10px at a time and that seems perfectly smooth at any framerate. Again, the fps you choose will have more to do with the total duration of the animation than it does the smoothness.
For quality i prefer to keep images as .PNG, but the option exists to use .JPG at 90% or even 80% quality if you need something big to run better and be smaller. How much smaller? I made one yesterday that was 380MB as .PNG images. Using .JPG at 90% quality reduced it to around 90MB. (Roughly 1/4th) .JPG at 80% quality reduces it further to about 40MB, or roughly 1/9th it's original size. At 90% the difference in quality is almost unnoticeable, unless you're comparing two still frames side-by-side and looking hard.
If you made it this far, well done!
I think a mentality exists that Boot Animations should always be small and simple. I say nuts to that. Go BIG or go HOME! My ageing OP3T has 1GB free space on /system. How much free space do you have? What are you saving that space for? A rainy day...? My OP5 has more than that even. (1.5GB i believe). Just wasted space!
How big is TOO big? I haven't reached that limit yet. I've run an animation that was 700MB, that was smooth as silk. I've made one that was over 1000 frames, each frame 1080x500, at 60fps that was smooth as silk. This is on devices that by todays standards are way underpowered. Imagine what is possible with newer devices!
Of course, not every animation has to be big and complex. I've made one that is 7 frames @10 fps. Or 24 frames at 1fps. The range of what you can do is enormous. I bet most of you have better image editing/creative talent than i have. If you unshackle yourselves from the imaginary limitations and just make what makes you happy, your creations will far exceed my own.
I hope to see what you can come up with. The purpose of this thread is to inspire, and where possible to help. With that in mind, if you have questions or need help don't hesitate to ask. Bear in mind, my experience is extensive but not limitless. There are official Android documentation that covers more advanced features like 'Sound' or 'Anchoring' that i've not even used myself yet.
Ran out of guides for now, so how about some example of my own Boot Animations?
I don't claim credit for most of the original artwork. That requires talent. Mostly what i do is keyboard bashing. That said, every image i work with needs touching up and editing to make it work. Setting up the images and layers usually takes longer than creating the frames. You can think of that as part 1 and part 2 of the creation process. Part 3 is cropping, renaming, resizing, fixing, creating your zips, creating your GIF preview for posting....
Addendum
Any of the Boot Animations i've made can be used on any phone with a resolution of 1080x1920. That's what they were designed for. Some of the flashable zips as posted in my threads include Boot Logos that are designed to work with two phones only. The OP3T and OP5. If you flash these on any other phone you will Brick it. If you are unsure which is which, extract the bootanimation.zip from the flashable zip and install it manually.
The flashable zips in my thread install Boot Animations to the path /system/media/bootanimation.zip. Your install path may be different. Flashable zips can always be adapted. If you want help with that, or with flashable zips in general, i will help with that too.
If you want to use one on a phone with a different resolution, let me know. (That itself will become a useful guide). How to adapt it, and the drawbacks entailed, will become evident. If you've read the guides above you'll already have a good idea what is possible though.
Attached is a flashable zip template. Adapt it as needed for your own use.
Awesomeness.
Thanks, very useful. And if i didn't understand wrong, boot animation compatibility depends on resolution, right?
My rom has qmg bootanimation files. Can u help me please?
Verstuurd vanaf mijn SM-G965F met Tapatalk
Dirk said:
An Oddity
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!
Click to expand...
Click to collapse
THANK YOU! It took me a whole day - when I was about to upload my bootanimation.zip somewhere and ask why it simply was not working I found you post - it finally solved my problem. THANK YOU!
PS: If anyone fancies a rotating tesseract, please find it attached. (For oneplus 7pro or any other device with 1440 x 3120 px resolution...)
BoomYourDead said:
Thanks, very useful. And if i didn't understand wrong, boot animation compatibility depends on resolution, right?
Click to expand...
Click to collapse
Sorry, didn't see these replies before now. Resolution is the main thing providing everything else is equal. i.e your phone actually works with a traditional bootanimation.zip. Even if the resolution doesn't match the Boot Animation will still work, but it will be too big/too small/cut off at the sides or top and bottom, etc.
Bottom line: You want the correct resolution for your device.
wackowizzard said:
My rom has qmg bootanimation files. Can u help me please?
Verstuurd vanaf mijn SM-G965F met Tapatalk
Click to expand...
Click to collapse
Don't know anything about those my friend. Sorry i can't help.
ID# said:
THANK YOU! It took me a whole day - when I was about to upload my bootanimation.zip somewhere and ask why it simply was not working I found you post - it finally solved my problem. THANK YOU!
Click to expand...
Click to collapse
Yeah, it's a sticky problem that had me banging my head in frustration when i first encountered it. Useful information to have at hand! Glad it helped you.
Edit: Btw your Boot Animation looks great! I''ve unpacked the zip and it looks like you've got a smooth, continuous loop. Well done, that can be a challenge!
You have "p 0 0 part0 0001" in your desc.txt. Exactly correct using 'p 0 0...' Just loops that part0 folder perfectly. I've not encountered the "0001" part at the end before. You've probably learned something i didn't even know. What does it do?
Keep up the good work!
I've change the boot animation of a custom a12 ROM, just paste it in the location. It is booting fine but the animation has no color, any ideas why?
Dirk said:
First my Bona Fides. I make Boot Logo's and Animations for a couple of Oneplus devices. Unless you own these devices you've probably never seen any of the work. (Don't worry, i doubt if you're missing anything). Here's one of the threads: https://forum.xda-developers.com/oneplus-5/themes/mod-custom-boot-logos-animation-op5-t3924397 (It's mostly Boot Logos to begin with so start at the end for the Animations)
Over time i've added a few guides to share what i've learned from making Boot Animations. Obviously the guides, like the work, aren't reaching as many users as they would if they were posted here. So i thought i'd post what i have all in one place where they may be more useful to a larger audience. (I'm almost certain the guides themselves are better than the work!)
Click to expand...
Click to collapse
My Animation ( bootsamsung.qmg and bootsamsungloop.qmg file here...)
I've change the boot animation of a custom a12 ROM, just paste it in the location. It is booting fine but the animation has no color. https://forum.xda-developers.com/oneplus-5/themes/mod-custom-boot-logos-animation-op5-t3924397 mediterranean market near me tech beast
rickymartinp said:
I've change the boot animation of a custom a12 ROM, just paste it in the location. It is booting fine but the animation has no color. https://forum.xda-developers.com/oneplus-5/themes/mod-custom-boot-logos-animation-op5-t3924397 mediterranean market near me
Click to expand...
Click to collapse
I ran into this when I was "optimizing" my PNGs, the colored ones ended up being grayscaled. The images look fine when viewing on the computer screen, using GIMPs animation filter or an online gif maker. Yet they displayed on the device as black and white...
Dirk said:
Anatomy of a Boot Animation
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.
desc.txt
Basically the config file needed to specify how the animation runs. let's take a look at the crDroid file:
Code:
1080 1920 40
c 1 0 part0 #121411
c 0 0 part1 #121411
c 1 0 part2 #121411
Line 1) 1080 1920 40 - Resolution (Width) x (Height) and framerate (fps) More on this later...
Line 2) 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.
Line 3) 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'.
Line 4) 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!
An Oddity
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!
Good luck.
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.
Click to expand...
Click to collapse
I was lurking here on xda for a while now, but created an account just to like your post! Awesome work!