Modification of the operating system Android opens up unlimited possibilities for customizing the device for advanced users. Often, standard menu-based configuration methods do not allow you to remove pre-installed software, change system fonts, or optimize power consumption at the kernel level. It is in such situations that there is a need to rebuild system image manually, introducing your own patches and configurations into it.
The process of creating a custom build requires a deep understanding of the file system and the structure of boot images. Mistakes at any stage can lead to the device turning into a “brick,” so the approach should be as balanced and technically competent as possible. In this article we will look in detail at the algorithm of actions from unpacking the source code to the final packaging of the image for installation via Fastboot or custom recovery.
⚠️ Attention: You perform all actions with system partitions at your own peril and risk. The author is not responsible for lost data or non-functioning devices. Before starting work, be sure to create a full backup copy (Nandroid backup).
Preparing the working environment and tools
To successfully build the firmware, it is not enough just to have the source image file; It is critical to prepare the correct software environment. Most imaging tools are written for Linux, so using a virtual machine or native system is the most preferable option. On Windows, the process can be complicated by problems with access rights and file paths. Android written for Linux, so using a virtual machine or native system based Ubuntu is the most preferred option. On Windows, the process can be complicated by problems with access rights and file paths.
You will need to install a specialized set of utilities, including Android SDK Platform-tools to interact with the device via ADB and Fastboot. Also an indispensable tool is Android Studio, which provides emulators and debuggers necessary to test changes before the final build. Don't forget about USB drivers so that the computer correctly detects the smartphone in bootloader mode.
Special attention should be paid to disk space and RAM. The process of unpacking and repacking images, especially the super.img or system_ext.imgformat, can consume significant resources. It is recommended to have at least 15-20 GB of free space on the SSD for temporary files and compiler cache.
- 🛠️ Install a Linux distribution (Ubuntu 20.04 or higher) for maximum script compatibility.
- 💻 Download the latest version Android SDK Platform-tools from the official developer website.
- 📦 Prepare the original firmware (Stock ROM) that matches the exact model of your device.
- 🔌 Make sure the USB cable is working and supports data transfer, not just charging.
Analysis of the structure of the factory firmware
Before you begin modification, you need to understand what components the firmware file you received consists of. Typically, stock images are distributed as a single archive .zip or a set of files .img, each of which is responsible for a specific memory section. The key elements are boot.img (kernel and ramdisk), system.img (main OS) and recovery.img (recovery environment).
Modern processor-based devices Snapdragon or MediaTek dynamic partitions combined into an image are often used super.img. To work with it, special utilities are required, such as lpunpack, which allow you to extract internal logical volumes. Ignoring this nuance will make it impossible to edit the contents of the system.
It is also important to check the security version and build number to make sure the patches are compatible. A mismatch between the kernel versions and system libraries can cause a cyclic reboot (bootloop). Use the utility getprop via ADB on a running device or analyze the file build.prop inside the unpacked image to obtain this information.
| Image file name | Description of contents | Ability to edit |
|---|---|---|
boot.img |
Linux kernel and initial RAM disk | High (kernel replacement, patches) |
system.img |
User interface and applications | Medium (bloatware removal, themes) |
vendor.img |
Hardware drivers and specific libraries | Low (risk of hardware failure) |
recovery.img |
Environment for installing updates and resetting | High (installing TWRP/OrangeFox) |
Unpacking images and extracting data
The first practical step is to convert the image files into an editable format. For files, the de facto standard is a utility that converts the format (used in Android to save space) into a .raw image. The command is executed in the terminal and requires specifying the input and output files. .img the de facto standard is the utility simg2img, which converts the format sparse (used in Android to save space) into a .raw image. The command is executed in the terminal and requires specifying the input and output files.
simg2img system.img system_raw.imgAfter conversion, you need to mount the resulting raw image into the file system in order to access its contents. In Linux, this is done through a command mount indicating the file system type, usually ext4. It is important to mount the image with write permissions if you plan to make changes directly, although the method of unpacking through scripts is more often used.
To work with boot.img use the tool MagiskBoot or abootimg. These utilities allow you to divide the image into components: the kernel (kernel), ramdisk (ramdisk.cpio) and the second stage of the bootloader. It is in the ramdisk that initialization scripts are stored, which are often modified to obtain root access or change partition mounting parameters.
⚠️ Attention: When mounting images, make sure that the mount point is empty. An attempt to mount an image in a folder with existing files may lead to their hiding or loss of data after unmounting.
Use the `file system_raw.img` command before mounting to accurately determine the file system (ext4, erofs, f2fs), since the wrong choice of file type will lead to an access error.
Modifying system files and kernels
At the editing stage, you can remove unnecessary system applications, replace fonts or modify configuration files. To safely remove system software, it is not enough to simply erase .apk the file; it is also necessary to remove the corresponding entries from configuration files, such as packages.xml in the folder /system/etc/permissions/. Ignoring this rule will result in verification errors when loading.
If your goal is to modify the kernel, the process becomes much more difficult. You will need the kernel source code (Kernel Source) corresponding to the version installed on the device. Compiling the kernel requires setting up a cross-compiler (cross-compiler toolchain) and correctly configuring .config file taking into account the processor architecture (ARM64 or ARM).
Often users want to change parameters build.prop to improve performance or change identifying the device on the network. Be careful: an incorrect screen density value (ro.sf.lcd_density) can make the interface unusable, and changing the network properties can block access to the mobile data.
- 🗑️ Delete system applications only after creating a backup copy of them in a separate folder.
- ⚙️ Edit text configs encoded UTF-8 without BOMto avoid parsing errors.
- 🔒 Disable Signature Verification in the kernel if you plan to install unsigned modules.
- 📝 Keep a log of all changes so that in case of an error you can quickly roll back the changes.
What is Selux (SELinux) and how does it affect the build?
SELinux is a security mechanism of the Linux kernel. In Enforcing mode, it blocks many modifications for custom ones. Firmware often switches the mode to Permissive, which reduces protection, but allows rooted applications and tweaks to work.
Reverse packaging and image creation
After making all the necessary changes, the stage of reverse file conversion begins. If you mounted the image directly, you must unmount it correctly with the command umount, making sure that. all data is written to disk. To create an image from a folder with files, use the utility make_ext4fs or mke2fs depending on the required file system.
When assembling boot.img it is critical to respect the original size and structure of the utility. data-i="127">automatically pulls up the parameters from the original image, which minimizes the risk of errors. The build command usually looks like MagiskBoot automatically pulls up parameters from the original image, which minimizes the risk of error. The build command usually looks like magiskboot repack, after which you receive a file ready for flashing.
If you worked with dynamic partitions, after modifying individual volumes, you need to pack them again into super.img using the utility lpmake. This process requires precise indication of the size of each partition, since the final image size should not exceed the physical size of the super partition on the device.
⚠️ Attention: The size of the final image system.img should not exceed the size of the corresponding partition on the phone. Exceeding even 1 megabyte will result in a flashes error and the inability to write data.
☑️ Control before packaging
Testing and debugging the assembled firmware
The final stage is checking the functionality of the assembled firmware. Never install an unverified image on a primary device without a quick recovery option. The ideal option is to use an emulator Android Studio with your image loaded, however, emulation of hardware features (camera, modem) is limited there.
A more reliable method is installation via custom recovery on a test smartphone. When you boot for the first time, carefully monitor the logs via adb logcat. If the device is stuck on the logo, connect it to the PC and read the log dump to determine the cause of the failure (mounting error, missing library, service failure).
A common problem is Bootloopcaused by the incompatibility of the modified kernel with the hardware. In this case, you need to boot into recovery mode and restore the backup. Analysis of files last_kmsg or pstore will help you understand at what stage of initialization a critical kernel error occurred.
Successfully booting the system is only half the battle. Be sure to test the operation of calls, Wi-Fi, Bluetooth and the fingerprint sensor, since modification of system libraries often disrupts the operation of drivers.
Frequent errors and methods for eliminating them
During the rebuilding process, beginners often encounter common problems that are easily solved if they have an understanding of the Android architecture. One of the most common mistakes is violation of file access rights. On Linux systems, each file has an owner and a group; if these attributes are lost during unpacking, system services will not be able to start.
Another common problem is related to the signature of images. Modern versions of Android require system partitions to be signed with cryptographic keys. During manual assembly, signature verification may block loading. The solution is to disable verification in the bootloader (unlock the bootloader) or use a patched kernel with verification disabled dm-verity.
It is also worth mentioning the problem of lack of space in the partition. When adding heavy applications or resources to system.img you may exceed the partition limit. In such cases, it is necessary to either compress resources or transfer applications to the partition data, changing the installation scripts.
Why does Root not work after rebuilding?
Most often the problem is that during packaging boot.img the Magisk patch was not implemented or the size was changed ramdisk, which confused the addresses in memory. It is necessary to use the "Patch" function in the Magisk application directly on the file boot.img.
Is it possible to rebuild the firmware without unlocking the bootloader?
No, this is not possible. Writing modified images to memory partitions is blocked at the bootloader level. An attempt to flash an unsigned image on a locked device will result in a verification error.
What to do if the phone goes into an endless reboot?
Hold down the combination of the power and volume buttons (depending on the model) to enter Recovery Mode. Perform wipe data/factory reset. If it doesn’t help, flash the stock firmware via Download/EDL mode.
Which tool is better for working with boot.img?
Currently, the gold standard is MagiskBoot, included in Magisk. It automatically detects the kernel compression format (gz, lz4, xz) and correctly assembles the image back.
Is it safe to remove system applications through rebuilding?
Yes, if you remove only user applications (bloatware) and do not touch critical Google services or system frameworks. Removing key components will lead to system inoperability.