World The number of modified firmware for Android is huge and offers users features that are not available in stock versions of the operating system. However, when there are no ready-made assemblies for your device, the only option is to create a custom image yourself. This process, called porting, allows you to adapt the firmware from one smartphone to the hardware of another, opening access to new functions and versions of the OS.
The procedure for porting requires a deep understanding of the Android architecture, the structure of file systems and the principles of the bootloader. Mistakes at any stage can result in the device becoming a brick, so it is critical to maintain consistency and carefully check each step. In this article, we will analyze in detail the process of preparing, modifying and assembling the image.
To get started, you will need a powerful computer with the Linux or macOS operating system, although there are tools for Windows. Basic command line knowledge and ability to work with archives and binary files are also required. Do not try to repeat the steps blindly - understanding the essence of each stage will save your device from fatal failures.
Preparation of tools and source files
The first step is choosing a donor and recipient. Donor is a smartphone, the firmware of which will be used as a basis, and Recipient —the device on which it will be installed. It is critical that the processors of both devices belong to the same platform, for example, MediaTek or Qualcomm, and have a similar core architecture. An attempt to transfer firmware from Snapdragon to MediaTek is doomed to failure due to fundamental differences in drivers.
You will need a set of specialized utilities, without which the process is impossible. The main tool will be Android Image Kitchen or its analogues for unpacking and packing images boot.img i recovery.img. You will also need tools for working with the file system, such as simg2img to convert .sparse images to .raw and vice versa.
⚠️ Attention: Make sure that the Android versions on the donor and recipient are as close as possible. Trying to port Android 13 to a device released with Android 8 may result in incompatible modem and camera drivers.
Download the stock firmware for the recipient device. It is needed not for installation, but for extracting specific files, such as fstab, init.rc and drivers unique to your hardware. These files will be embedded in the donor image to ensure correct operation of the equipment.
Use a virtual machine with Ubuntu to work with porting tools - this will ensure maximum script compatibility and eliminate problems with file paths that often arise in Windows.
Unpacking images and analyzing the structure
After To download all the necessary files, you need to unpack the system images. Typically, the firmware consists of several sections: system, boot, recovery, vendor and others. For porting, we are primarily interested in the system and bootsections. Use the command simg2img system.img system_raw.img to convert the image to a readable format.
Next, you should mount the resulting raw images into a directory to gain access to the file system. In Linux, this is done through the command mount. You will see the familiar Android folder structure: /system/app, /system/framework, /system/lib. This is where all system applications and libraries are stored.
- 📂 Unzip
boot.imgdonor and recipient to compare kernel configuration. - 💾 Extract the contents of
system.imgboth devices into different folders for clarity. - 🔍 Check the presence of the file
build.prop—it contains key build parameters.
Pay special attention to the file fstabthat describes the file system table. It is located either at the root of the image bootor at /system/etc. Incorrect configuration fstab will lead to the fact that the phone will not be able to mount data partitions and will simply freeze on the logo when loading.
Replacing system files and libraries
The most important stage is replacing the files in the donor image with files from the recipient image. You need to copy the hardware specific files from the recipient system folder to the donor system folder. First of all, files from folders /lib, /lib64, /vendor and /etc.
are replaced. The key point is to work with the file build.prop. It specifies the properties of the device, such as model, manufacturer, screen density (DPI). You need to edit this file in the donor image, introducing data from build.prop recipient there. This will trick the system into thinking it is running on the native device.
ro.product.model=Recipient_Model
ro.product.brand=Recipient_Brand
ro.product.device=Recipient_Device
You will also need to replace the hardware key and display configuration files. Usually they are located in /system/usr/keylayout i /system/etc. If you do not replace the file hwcomposer.mt67xx.so (for MediaTek) or similar for Qualcomm, you will encounter a black screen or incorrect display of graphics.
⚠️ Warning: Never replace the entire partition
/systementirely. Only replace specific driver and configuration files. A complete replacement will result in the loss of functions unique to the donor firmware.
What to do with .odex and .vdex files?
In modern versions of Android, many applications are optimized in advance. When ported to another version of Android, these files may cause a conflict. It is recommended to remove folders /system/framework/oat and /system/app/*/oat from the donor image before building, so that the system will generate them again at the first boot.
Modification of the kernel and boot image
The image boot.img contains the Linux kernel and ramdisk is a temporary file system loaded into RAM. For successful porting, it is often necessary to take the kernel from the recipient's stock firmware and implement it into the donor image, or carefully edit the parameters of the existing kernel.
Inside the ramdisk there are initialization scripts init.rc and init.device.rc. They determine which services to start at startup and how to mount partitions. You need to open these files in a text editor and make sure that the device paths (for example /dev/block/platform/...) match those used in your device.
| File | Destination | Source for replacement |
|---|---|---|
init.rc |
Main script initialization | Recipient (stock firmware) |
fstab.mt67xx |
File system table | Recipient (required) |
ueventd.rc |
Device access rights | Recipient |
default.prop |
Kernel system properties | Manual editing |
If you are using a donor kernel, make sure it supports the specific drivers for your screen and touchscreen. Sometimes you have to compile the kernel manually, adding the necessary drivers from the manufacturer's source code, but this requires qualifications at the Kernel Developer level.
The kernel is a bridge between software and hardware. If the kernel doesn't know how to manage your processor or memory, no system files will help run Android.
Building the image and checking integrity
After making all the changes, you need to pack the files back into the image system.img. To do this, use the utility make_ext4fs or mke2fs, depending on the file system (ext4 or erofs). It is important to correctly specify the parameters, such as the partition size and label, otherwise the bootloader will refuse to accept the image.
Next, the image is assembled boot.img using the utility mkbootimg. You will need to specify the paths to the kernel, ramdisk, cmdline and base address. The parameters for mkbootimg can be found by unpacking the original boot.img recipient and looking at the arguments in the unpacking log.
- 🛠 Use the script
pack.shfrom Android Image Kitchen for automatic assembly. - ⚖️ Check the size of the received
system.img—it should not exceed the size of the system partition on the device. - ✅ Check the checksums if required for signed images (rarely for custom ports).
At this stage it is useful to conduct a preliminary check of the image on an emulator or in the QEMU environment, although for Android this does not always give an accurate result due to the specifics of the drivers. Most often, testing occurs by trial and error on a real device.
⚠️ Attention: The size of the image
system.imgis critical. If you create a file of 4 GB in size, and the partition on the phone is 3.8 GB in size, the firmware will be interrupted in the middle and the device will go into a reboot cycle.
☑️ Final check before flashing
Installing and debugging errors
Ready images are copied to the device via Fastboot mode or specialized tools like SP Flash Tool (for MediaTek). The commands for flashing look like fastboot flash system system.img and fastboot flash boot boot.img. After recording the partitions, the command is executed fastboot reboot.
The first boot may take up to 10-15 minutes, as the system performs application optimization (ART compilation). If the device freezes at the logo, you need to enter Recovery mode and clear the Data and Cachepartitions. This is a standard procedure after installing any custom firmware.
If the download does not occur, connect the phone to the PC and remove the log via ADB. The command adb logcat will show the flow of system events. Look for lines with the tag FATAL or ERROR, which will indicate the cause of the failure: lack of a library, mounting error or service failure.
What to do if the phone goes into an endless reboot (Bootloop)?
Q 90% of cases the problem lies in an incorrect file fstab or an incompatible kernel. Try replacing the core with a stock one from the recipient. Also check the file permissions in the system image - they must match the original ones (usually 644 for files and 755 for folders).
Why does the camera or sound not work after porting?
This is a classic problem of missing proprietary blob files. You need to take the folder /vendor/lib/hw i /system/lib/hw from the recipient's stock firmware and completely replace the corresponding folders in the ported firmware with them. Camera and sound drivers are unique for each module.
Is it possible to port firmware from Android 14 to a device with Android 10?
Theoretically yes, but in practice it is extremely difficult. It will be necessary to replace a huge number of libraries and, possibly, recompile the kernel to support new security functions. It is recommended to look for a donor with an Android version that differs by no more than 1-2 major versions.
How to fix the "Status 7" error when installing via Recovery?
This error occurs due to checking the Android version or device model in the Updater-binary installation script. Open the firmware archive, find the file META-INF/com/google/android/updater-script and delete the lines containing functions assertor replace updater-binary with a universal one.
Why do you need to delete oat folders when porting?
Files The folders oat contain compiled bytecode for a specific ART version and processor architecture. When transferred to another device or OS version, they become invalid. Removing them forces the system to rebuild them upon first boot, which prevents application crashes.