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!
[Tutorial][Tool]Custom boot animations & cross platform tool to create boot animation
Changing the boot animation on your Android device is fairly trivial if you have root, and there are not many mods you can make to your device that have the same level of impact on how "custom" it feels.
There are a handful of apps on the play store you can use to change the bootanimation, if you can find one that you like. But if you can't find something that satisfies your tastes, you're stuck looking for someone else to do it for you, or using the same one from the app store that 15 other people you know have. If what you're really looking for is that completely custom look, or perhaps just the satisfaction of doing it yourself, this is the tutorial you've been looking for.
Google actually has a writeup in the AOSP repository about the format and construction of the boot animations, and it's one of the few things that actually hasn't changed much over the lifetime of Android. So this process should apply to most of the devices out there, but as I'm working on a Chinese head unit right now that's the device we'll be taking through this tutorial.
To make a boot animation essentially requires only two things. You need a series of images that represent the frames of your animation, and a short text file that tells the system how to process them. All these things go into a zip file named bootanimation.zip, stored in system/media on most devices, and there's where the system reads the boot animation from. One side note worth mentioning is that if a bootanimation.zip is present in oem/media (or presumably vendor/media on treble devices, though the Google docs haven't been updated) that takes precedence over the one in system/media. So if you've placed an animation in system/media and you're still seeing the stock one, check those locations for another bootanimation.zip and replace that one instead.
It sounds fairly straightfoward, but there are a few caveats that can be a bit frustrating when you're just getting started with making your own bootanimations, and previous tutorials I've seen either don't mention them or just aren't very clear on those steps. This is my attempt at making a more comprehensive write-up.
The text file you'll need has to be named desc.txt and lays out the structure of your animation. It's not diffiacult to create once you understand how it works, but people have been known to struggle with it. The first line is really simple; it just lays out the resolution of your animation, and the framerate you want it to play at. In the following format: width height framerate where width is the width of your images, height is the height of your images. The width and height should match the display resolution of your device for best results. You can go smaller, but you'll have to tell the system what to do with the extra space (more on this later) Setting this larger than your display resolution or using images larger than your display resolution with generally give you unpleasant results. Your animation will be either cropped (cut off) or squished to fit the device resolution. If you don't know your the resolution of your device for sure, Aida64 or any of the other system info apps from the play store can reveal it to you. Framerate is an integer (whole) number describing how many frames per second should be displayed. The higher this number is, the smoother than animation can be. However, that means more frames you will need to create, and some devices can lag at higher framerates. It's tempting to go for something like 60 frames per second, but a lot of devices can't keep up with this framerate (remember it's still trying to load all of its drivers and get the operating system started at this point too). I have found that the most satisfactory results at around 10-15 frames per second. My display resolution is 1024x600 and I'm going to shoot for 15 frames per second. So with those details in place, the first line of my desc.txt looks like this:
Code:
1024 600 15
The remaining lines in desc.txt may vary depending on how you want your animation to play. The animation can be divided into "parts" with separate rules for how many times each part plays, whether or not to repeat it, how many times to repeat it, etc. Each remaining line has 4 required and 3 optional columns and describes one of these "parts." The four columns are the "type" - containing a single character, either p or c, determining what type this particular part is. A "p" type can be interrupted when the system is finished booting and ready to display the home screen. A "c" type will play to completion no matter what. So if a "c" type is still playing when the boot process is finished, you'll have to wait for that part of the animation to be through before you can see your home screen. The next column must be an integer number that represents how many times to loop through that particular part of the animation. If you set it to 0, it will loop repeatedly until the boot process is completed. The third column is another integer number indicating that the system should pause the animation for this number of *frames* (not seconds) before looping again or going on to the next part, whatever it's doing next. This entry can be 0 for no pause, or represent any number of frames. So if your animation is playing at 15 frames per second, and you want it to be paused for 1 second at this point, you'll want to set this to 15. If you wanted to pause for half of a second, well you're out of luck because the number has to be an integer, but you can set it to either 7 frames for slightly less than half a second pause or 8 frames for a slightly more than half a second pause. Still with me? If your target framerate is some other value, this value must change accordingly. The fourth column represents a folder name where the images for this part of the animation are stored. If your animation is just a loop that you want to play continuously until the system boots, you will only need this one line and it could look like this:
Code:
p 0 0 part0
This line simply directs the system to play this "part" repeatedly until the system boots up, with no pauses between the loops, to interrupt the animation as soon as it's ready to load up the home screen, and to look for the images to play in a folder named "part0." Earlier I mentioned using images of a lower resolution than your display and also three optional columns in these lines for desc.txt. The fifth column is optional, and it contains a background color to be displayed in the case that your image doesn't cover the entire screen, and its value, if present, must be a color code in hex format with a leading # ex. #FFFFFF for a white background. You might use this for example to put a colored border around your animation if your frames are slightly smaller than the screen resolution. Or if your images are mostly in the center of the screen, and have a solid background color (let's say black to keep it simple) you can actually save some rendering time and get a bit smoother playback by making your images only as big as they need to be to account for what will change from frame to frame, and set this to #000000 to fill in a black background around it. So if your animation was just a spinning globe centered in the screen, and 2/3 of the screen stayed black the whole time, you might size the image at 300x300 pixels and set the background color. This can produce smoother animations in lower end devices, because the system isn't wasting it's time overwriting all the black pixels with a new set of black pixels 15 times per second, and you can achieve higher framerates with more fluid results using this method. The final two optional columns are used mostly for Android smartwatches and contain x y coordinates telling the system where on screen to display the time. The values are integer amounts, in pixels, or "c" for center. The rules for using them are a bit complex. We'll call these columns CLOCK1 and CLOCK2. If CLOCK1 is set and CLOCK2 is not, then CLOCK1 sets the y coordinate, and x is defaulted to "c" for centered. If both CLOCK1 and CLOCK2 are set, then CLOCK1 represents the *x* coordinate and CLOCK2 is *y*. Positive values for x will position the time x pixels from the left, and negative values will position the time x pixels from the right. For y, positive values position the time y pixels up from the bottom of the screen, and negative values position the time y pixels down from the top of the screen. Clear as mud? Good, let's move on.
So after that lengthy explanation, we can move on to adding more lines to desc.txt and why we might want to. I find it helpful to visualize how I want each animation to look from start to finish and then consider what that's going to look like if it happens to repeat, in order to decide if my animation needs more than one part. So let's return to the spinning globe example to illustrate an example of when we might want to do this. To make the overall effect more interesting, let's say that our globe is going to come into the screen from the left side and travel until it gets to the center at the start of our animation, after which it will remain in the center and continue to spin. If my animation has 100 frames in total, I could shove them all into a part0 folder and use the p 0 0 part0 line from above and call it good. But after the first 100 frames play, something like 6 and a half seconds will have elapsed, and if the device isn't ready to boot by then, the animation will loop, and we'll watch the globe entering from the left side of the screen again, which would be kind of a jarring effect. It would be a much nicer visual if it simply stayed in the middle and continued to spin until the system interrupted the animation. To achieve that effect, I'd need to use separate parts, and some slightly more complex rules. Looking through my frames, I might determine that it takes 50 frames of the animation for the globe to reach the center of the screen, where I want it to remain for the whole time. So I would take those 50 frames and put them in the part0 folder, and add a line to desc.txt like this:
Code:
c 1 0 part0
This tells the system to play these 50 frames through only 1 time, and not to interrupt the animation at this point if it's ready to boot, and not to pause before moving on to the next part. To complete the effect, my second line should look something like this.
Code:
p 0 0 part1
Now we're telling the system that it's ok to interrupt at this point any time it's ready to start up, but until that point, just keep playing this part of the animation (the spinning part) over and over, without returning all the way to the beginning where we entered the screen from the left. Nifty, huh? With some clever application of this technique you can create some very interesting effects.
To add audio to the animation, each part folder can contain a .wav file that will play when that part starts. If that part of the animation loops, the audio will also loop.
Gotchas:
If you've followed everything up to this point, you're almost ready to get started. There are a couple more details you need to know to be successful making your sweet custom boot animation.
First, the zip file that you put all of this stuff in has to be constructed in a particular way. The archive must be assembled in "storage only" mode, meaning no compression. So whatever utility you use to construct the zip file must support this method. This may lead you to question why use a zip archive if nothing is supposed to be compressed? Why not just use a folder? The answer to this is what ends up frustrating most people who set out to make a boot animation and end up giving up on it. The binary that controls this process expects all these files to be in a certain order, and Linux (and by extension, Android) can do some unexpected things with the order of files inside a directory. The images used in your animation can be named anything you want as long as they all have the same naming convention, which must include sequential numbers. For example, image01.png, image02.png, image03.png etc. The same rule applies to your part folders. They don't necessarily have to be named "part" but they must include sequential numbers, so folder00, folder01, folder02, etc. In either case, if you skip a number, the process hangs and you end up with a soft brick. So if you have image01.png, image02.png and then image04.png with no image03.png, your animation will hang, and you'll have to fix it from recovery mode, because the device will never manage to boot. Not only must all these files be present, they must be *stored in order*. So if I have 01.png, 02.png, 03.png but they're store as 01.png, 03.png, 02.png, I'll get a soft brick, because the process isn't smart enough to organize the files on its own, it just expects the next one out of the archive to be the right one. This can screw you up in various ways if you're not careful. To keep things simple, I normally just name my images with numbers, so 000.png, 001.png, 002.png, etc. If I have 10 of these images in a folder on my Linux machine, and within that folder I do an "ls" command to list what files are there, Linux sorts them for me before outputting them to the screen, so I see them all in numerical order. But if I do "ls -U" which tells the shell to skip the sorting step, they are almost never anywhere close to being in numerical order. That's because in Linux, everything is a file, so in reality there is no such thing as a folder. A folder is just another file, containing pointers to all the files that are "stored in it." These files may be stored all over the disk, in whatever spot the system decided was the most efficient place to put them at the time. And they can get rearranged over time, as disk operations happen. So the purpose of the zip archive is to keep all of the files neatly in numerical order so the "dumb" bootanimation process doesn't get confused. We have to be aware of this behavior when we create the archive! If you just stuff all the files into the archive at once, the system is going to place them in there in the order it fetches them, not necessarily in the order that it's displaying them to you in. So what may appear to be a neatly sorted group of files before the archiving process can end up being a random mess inside the zip file that's going to soft brick your phone. I don't know off hand if Windows behaves the same way, but I discovered the hard way that this issue can be quite troublesome to work around on a Linux system. One way around it is to manually add files to the zip archive one at a time so you can force them to be in the right order, but this proves to be really tricky to do from the command line, not to mention tedious. It's similarly tedious and easy to mess up doing it in a gui. To that end, I have another utility to share that will automate this process and ensure that everything goes in the archive in the correct order!
You can get the tool from my https://github.com/threadreaper/abatools.git
Once you've cloned the git repository, from the top level directory (the one with the setup.py file):
Code:
pip3 install .
Alternatively, it's availble on PyPi. If you have Python installed, you should be able to execute:
Code:
pip3 install abatools
Once the tool is installed, it should be available to you from your command line. Execute:
Code:
abatools -a bootanimation.zip
from within a folder containing ONLY your desc.txt and your directories of image files, and the tool will properly package up the zip file for you.
BONUS! The tool can also auto-magically produce a boot animation from a .gif animation. To use this function, use the -g switch and point the tool to your gif file as follows:
Code:
abatools -g mygif.gif bootanimation.zip
That's it! You're already to go create some sweet custom boot animations!
I have a doubt code for adding sound is audio.wav or .wav???
Why the heck did moderator deleted my previous post ????
I asking how to add sound in bootanimation??
Tamil009 said:
I have a doubt code for adding sound is audio.wav or .wav???
Click to expand...
Click to collapse
Tamil009 said:
Why the heck did moderator deleted my previous post ????
I asking how to add sound in bootanimation??
Click to expand...
Click to collapse
I've restored your post. I apologise that I didn't read that you asked how to add sound in bootanimation.
Oswald Boelcke said:
I've restored your post. I apologise that I didn't read that you asked how to add sound in bootanimation.
Click to expand...
Click to collapse
Moderator if you the know the answer please tell me
My device lenovo tab x505x how to add bootanimation with sound i have custom bootanimatiion created by me
So i am not a noob the audio.wav said in official android website is not working??
I am on android 10
Tamil009 said:
Moderator if you the know the answer please tell me
Click to expand...
Click to collapse
Negative, I don't know besides the fact that I don't own the device.