Your phone’s startup sequence is more than a logo. Between the moment you press power and the lock screen appears, Android can play a short animation pulled from a package stored on the system. That animation is replaceable, packable, and surprisingly structured. This guide covers the files that make it work, the formats that keep it smooth, where the package lives, and how to install a custom version without turning a quick tweak into a boot loop.
The following sections break down the full scope: the anatomy of a boot animation package, the formats that matter, common storage locations, installation routes, and troubleshooting fixes.
- What an Android boot animation includes
- How desc.txt controls playback
- Which image and archive formats work best
- Where the package lives on the device
- How to install and test a custom animation
- How to fix black screens, choppy playback, and boot loops
What counts as an Android boot animation
The boot animation is the animated sequence that plays after the firmware splash screen and before the lock screen or home screen. It is not the static boot logo baked into firmware, and it is not a live wallpaper. It is a frame-based sequence played by a system service at startup.
The most common package is bootanimation.zip. Not every device uses that exact format. Some builds use packed animation formats or built-in theme engines. If a device ignores a correctly built ZIP, it likely expects a different format or a signed theme package. Check how your specific build handles startup visuals before you spend time building frames.
Inside bootanimation.zip: folders, frames, and desc.txt
A valid package has a desc.txt file at the root and one or more part folders. The ZIP must not wrap everything inside an extra folder. When the system opens the archive, it should see desc.txt and the part folders immediately.
- desc.txt describes the canvas size, frame rate, and playback order.
- Part folders hold numbered image frames, such as part0 and part1.
- Frame names should be sequential, such as 00000.png, 00001.png, and so on.
- Frame dimensions should match the declared canvas or use the same aspect ratio.
Example desc.txt:
1080 1920 30
p 1 0 part0
p 0 10 part1
The first line sets width, height, and frames per second. Each p line starts a playback block. The first number after p is the loop count, where 0 usually means loop forever. The next value sets a pause between cycles, and the final value names the folder. Keep the syntax simple and avoid extra spaces or unsupported characters.
Frames are usually PNG or JPG images. PNG is safer when you need transparency or crisp edges. JPG can reduce file size for full-frame backgrounds, but it may introduce compression artifacts. Use one consistent format per part unless you have tested mixed formats on your device.
Formats that matter: resolution, frame rate, and compression
Boot animations are short, but they can still become heavy. A high-resolution sequence with hundreds of frames can slow startup, stutter, or fail to load. Match the animation to the display, then optimize for smooth playback.
- Resolution: Match the native screen resolution when possible. Scaling a mismatched canvas costs processing time.
- Frame rate: 24 to 30 frames per second is a practical range. Higher rates increase file size and may not look better on a short startup sequence.
- Frame count: Fewer frames with clean timing often beat a long, heavy sequence.
- Compression: Most devices expect the ZIP to be stored without compression. A compressed archive can break playback.
- Audio: Sound support varies widely. Skip audio for better compatibility.
- File size: Keep the package lean. Large archives can slow boot or hit memory limits.
Where Android looks for boot animations
Common locations include the system media directory, product media directory, and OEM media directory. The exact path and search order differ by build. Some devices also read a test package from a local data path, while others ignore it completely.
Before replacing anything, back up the original package. Note the file permissions and ownership of the existing file. A boot animation usually needs to be readable by the system service that plays it. If permissions are too restrictive, the device may show a black screen instead of your animation.
Installation options
There are three practical routes. Choose the one that matches your device access and comfort level.
- Theme engine route: Some devices include a built-in customization tool that accepts boot animations or downloadable themes. This is the least invasive option and usually needs no root access.
- Systemless module route: A systemless package can place the animation in the correct path without permanently modifying the system partition. This is easier to reverse and is a good fit for rooted devices.
- Manual replacement route: Use a root-capable file manager or a custom recovery to replace the existing package. Back up first, copy the new ZIP to the correct media folder, set read permissions, and reboot.
Manual installation steps usually look like this: back up the original file, copy the new bootanimation.zip into the media folder your build uses, set permissions so the system can read it, then reboot. If you use recovery, mount the system partition read-write, copy the file, fix permissions, and reboot. Keep a recovery backup or a known-good package ready in case the first attempt fails.
Build your own animation
Start with a simple two-part sequence. Design frames at the target resolution, export them as a numbered PNG sequence, and keep the visual language bold enough to read during a short startup. Thin text and tiny details disappear quickly on a phone screen.
- Create a folder for the first part and another for the second part if needed.
- Export frames with sequential names, starting at 00000.png.
- Write desc.txt with the canvas size, frame rate, loop counts, pauses, and folder names.
- Place desc.txt and the part folders at the root of the ZIP.
- Use store mode, not compression, when creating the archive.
- Name the package bootanimation.zip and test it on the device.
Do not include parent folders, hidden files, or extra metadata in the archive. A clean root structure prevents many avoidable failures.
Troubleshooting common boot animation issues
- Black screen after install: Check the file path, ZIP structure, desc.txt syntax, and read permissions.
- Boot loop: A corrupt archive or invalid desc.txt can stop startup. Restore the original package through recovery or a backup.
- Animation cuts off early: The package may be too large, the frame count too high, or the resolution mismatched. Reduce size and complexity.
- Animation does not loop: Set the loop count to 0 on the part that should repeat.
- Choppy playback: Lower the frame rate, reduce resolution, remove compression from the ZIP, or simplify frames.
- ZIP is ignored: The device may use a proprietary format or theme engine. Use the supported route instead of forcing a ZIP.
Custom boot animations are one of the few visual tweaks you feel every time you power on. Keep the package clean, match the display, store the ZIP properly, and back up the original. Start with a short, simple sequence, test it, then refine the timing and artwork. For more straight talk on device customization and emerging tech, keep exploring TechBlazing.