Run start.bat if you are using windows, run the start script if you are a llinux or mac user and extract the bootloader.imgdata.img file from the stock folder, follow the instructions on the screen.
You will find the editable images in the "images" folder after the extraction.
Use any tool to modfy the images or to create new ones.
Make sure the image format is a 24 bit uncompressed windows bitmap bmp file and the dimension is not higher than 1080x1920;
Edit pos.txt in the "images" folder for positioning your images.
Build your new imgdata.img and flash the flash-me.zip in recovery.
About pos.txt file strucure:
First column: image name in imgdata.img
Second column: X_posisitonxY_position from the top left corner of your screen. X_position means how many pixels right form the left of the screen. Y_position means how many pixel down from the top of the screen.
See the picture:
Do not delete the images, preview and custom folders.
If you want to make sure everything is okay, then extract the recently build imgdata.img (new-imgdata.img). If you see the same pictures then it is okay. Dont use md5 or crc checks on the images for checking are they the same, because some infos missing from the header of the extracted images (like pixel/meter, number of colors end etc...) and some editors likes to put random datas in the gap bytes between the lines.
I am not responsible if you brick your device.
If the building or extracting fails at some point or the program ends up in endless loop, then please report me and send me the images and pos.txt file for fixing.
To remove an image just replace it with a same sized only black image.
Save bmp files to 16bit then save them again to 24 bit to make imgdata smaller at a little cost of quality loss.
Windows XP users have to install .net framework 3.5 to make the bat file work.
Linux and mac support.
Start.bat now adds C:\Windows\System32 and C:\Windows\SysWOW64 to the path environment variable if they are missing.
For imgdata binary: 16bit switch now checks the input file to determine is it a valid bmp file.
16 bit conversion: does in one step when you open an image with gimp then save it as 16 bit then reopen and save it as 24 bit.
the original image will get "o-" tag to the begining of its name
Option for flash with adb or fastboot.
Added more-space.img to the custom folder. I removed padlock, fastboot background, downloadmode screen and I minimalized fastboot screen and oem unlock screen to gain more space for custom boot logos.
When you enter download mode a kernel gets loaded it is at the laf partition, during the boot process the google logo is skipped. I flashed a twrp recovery to laf partition just for fun. I booted up twrp from laf and I was surprised that I still see the booting picture of the download mode. I started looking for where that image is stored. It turned out it is not in the aboot partition. There is a partition called imgdata. It looks like the images needed by bootloader are stored there. I managed to understand the structure of the imgdata partition. There are 12 images in raw format on imgdata.
DATA1: 8 byte string. It says IMGDATA!. It is similar to the begining of boot.img and recovery.img that says ANDROID!
DATA2: I don't know.
DATA3: Number of images. It is 12.
8 bytes of 0: I dont know the purpose of that
DATA4: 16 byte string. Tells the name of the image.
DATA5: image width in pixel
DATA6: image height in pixel
DATA7: X position of the image in pixel
DATA8: Y position of the image in pixel
DATA9: it tells where is the begining of the picture on imgdata
DATA10: size of the image
This pattern goes on, from DATA4 to DATA10.
The origin is the top left corner of the screen. Look at the picture.
The first image is at 0x0400, and after that point there are only images.
Currently I have no idea how these images formated. I tried to use ffmpeg to convert these images into png, but the output was just a mess.
If we find out how to edit these pictures then we could customize our beloved "Google" boot logo.
I have made an excell chart about the image headers and extracted all the 12 images. There is a little gap between images to fit the 512byte of block size on the partition. You will find image files with that additional gap and without of it and my chart in this link. The imgdata.img I used is from the KRT16M to KOT49E ota update.
I managed to decode the structure of the images. It consist of 4 bytes of chunks.
First byte: countnumber
Second byte: R value
Third byte: G value
Fourth byte: B value
05 00 00 00 02 FF FF FF
05: countnumber = 5
00 00 00: RGB value = black
FF FF FF: RGB value = white
So from the top left corner of your screen you would see 5 black pixels then 2 white pixels.
I wrote a C program which converts these raw images to bmp images. So my guessing was right about the Image headers in the first post.
I will later post that program with an option to convert bmp files to raw files.
If you want to write your own program then here are a few hint:
BMP stores pixel values in BGR order while the pixels stored in RGB order in the raw file.
BMP picture starts from bottom left corner while the raw file starts from top left corner.
In a BMP file the size of a pixel row in bytes has to be multiple of 4. Lets say you have 2x1 bmp picture. (width x height, column x row) . You have 2 pixels.
Each pixel stored on 3 bytes (BGR). 2*3=6.
6%4 = 2 so you have to add two more bytes to the row, then 8%4 will be = 0.
XDA Developers was founded by developers, for developers. It is now a valuable resource for people who want to make the most of their mobile devices, from customizing the look and feel to adding new functionality. Are you a developer?