The process of porting Android-based firmware is a complex but exciting procedure for transferring the operating system from one device to another. This allows you to revive old gadgets by installing the latest version of software on them, or transfer a custom shell from a popular flagship to a more affordable device. The essence of the method is to replace the donor system files with recipient files, while maintaining compatibility of the kernel and drivers.
The success of the operation directly depends on the processor architecture and the version of the Linux kernel used in both devices. If MediaTek encounters Qualcomm or the Android versions differ too much (for example, Android 10 and Android 14), the probability of a successful download tends to zero. Therefore, before starting work, it is necessary to thoroughly study the technical specifications of both smartphones.
In this guide, we will analyze the key stages of preparation, tools for working with images, and the nuances of setting up system libraries. You will learn how to avoid a cyclic reboot (bootloop) and restore the device to functionality in case of failure. Porting requires care, knowledge of the Linux file system and the ability to work with the command line.
Preparing equipment and selecting a donor
The first and most critical step is selecting a pair of devices: a donor (where we get the firmware from) and a recipient (where we install it). The ideal scenario is devices on the same platform, for example, both on a chipset Snapdragon 660. In this case, the kernel and hardware drivers will most likely be compatible, which will simplify the process significantly.
You will need a computer with an operating system Linux (preferably Ubuntu or Debian) or a virtual machine with sufficient RAM. Working in a Windows environment is possible, but using tools like cygwin often leads to permissions and file encoding errors. You also need an unlocked Bootloader on the recipient device and installed TWRP Recovery.
⚠️ Attention: Before starting any manipulations, be sure to create a full backup copy (Nandroid Backup) of the current working firmware through recovery. This is the only way to return the phone to its original state without using programmers.
Download stock firmware for the recipient and custom firmware (or stock from another device) for the donor. The files must be in the format .zip or unpacked in the form of images .img. Make sure that there is enough free space on your hard drive, as unpacked system images can take up several gigabytes.
Tools and unpacking images
For working with firmware files, you will need a set of utilities capable of extracting content from images system.img, vendor.img i boot.img. The standard set includes simg2img for converting sparse images into raw images, as well as utilities ext2simg and make_ext4fs for working with the ext4 file system.
Unpacking begins with converting the image of the donor system. If the file has an extension .new.dat.br or .new.dat, it must first be converted into a standard img file using scripts lpunpack or sdat2img. After receiving a clean one system.img the mount command or use the utility unpackimg.sh is used to extract the file structure.
./simg2img system.img system_raw.imgmkdir out_system
sudo mount -o loop system_raw.img out_system
A similar procedure must be done with the image vendor.imgif it is present in the donor firmware and is required for the recipient. Often it is the incompatibility of libraries in the vendor section that causes the camera or sensors to stop working after porting. The folder structure must be clearly transferred to the project's working directory.
Use the Tree utility to visualize the folder structure after unpacking. The `tree -L 2 out_system` command will show the nesting of directories and help you quickly find the necessary configuration files.
Replacing system files and libraries
The most important stage is replacing the contents of the system. You need to copy the folders and files from the unzipped donor system to the recipient system folder. However, you cannot do this blindly. It is critically important to save the files responsible for communication with the hardware of a particular device.
First of all, replace the folder /system/app i /system/priv-appto transfer the interface and system applications of the donor. Then replace the files in /system/frameworkthat contain the base Android classes. But be careful: some files in /system/lib and /system/lib64 should remain from the recipient, since they contain specific drivers.
- 📂 Be sure to save the folder
/system/etc/firmwarefrom the recipient if it contains specific binaries for the modem or Wi-Fi module. - 📂 Do not replace files
build.propentirely; it is better to manually edit the parameters in the donor file, substituting the model and brand of your device. - 📂 Check the permissions to the files after copying using a script
fixPermissions.sh, otherwise the system will not boot.
Pay special attention to the file fstab.qcom (or fstab.mt67xx for MediaTek). This file describes the file system's partition table. If the paths to the partitions on the donor and recipient are different, the smartphone will not be able to mount the system partition at boot. Compare the contents of this file in the boot images of both devices.
☑️ Controlling file replacement
Working with the kernel and Boot image
The Kernel is the link between the hardware and the operating system. When porting firmware, it is strongly recommended to use the kernel from the recipient device (system donor, kernel recipient). An attempt to boot a system with a kernel from another device most often results in an immediate hang on the logo.
To extract and modify the image boot.img use the utility AJK (Android Image Kitchen) or magiskboot. After unpacking you will receive a kernel file (zImage or Image.gz-dtb) and ramdisk. Ramdisk contains initialization scripts init.rcwhich may also require editing to mount partitions correctly.
⚠️ Warning: Never try to compile the kernel yourself unless you have deep knowledge of C and the ARM architecture. Use the ready-made kernel from the stock firmware of your device, this is the most stable option.
If you transfer firmware with a newer version of Android to an older kernel, API version conflicts may occur. In such cases, sometimes replacing only the ramdisk from the donor into the recipient kernel helps, but this only works if the Android versions match (for example, a port from Android 11 to Android 11).
What to do if there is a Kernel Panic error?
If you see the Kernel Panic message in the log, this means a fatal kernel error. Most often the reason is an incompatible dtb (Device Tree). Try replacing the dtb file in the boot image with a file from the recipient's stock firmware.
Building firmware and flash via Recovery
After all the files have been replaced and checked, you need to pack the images back. For the system partition, a utility make_ext4fsis used, which creates a new img file taking into account the size of the partition. It is important to specify the correct size, otherwise during installation the error “Not enough space” will appear.
make_ext4fs -l 4G -a system -S file_contexts system_new.img out_systemNext, all prepared images (system_new.img, boot.img, vendor.img) are packaged into a ZIP archive, ready for installation via Recovery. The archive structure must contain a folder META-INF with the installation script updater-script. This script contains commands for formatting partitions and copying images to the phone's memory.
Copy the resulting ZIP file to a memory card or internal storage of the smartphone. Boot into TWRP Recoverymode. Before installation, be sure to format the Data, System, Vendor and Cache (Wipe) partitions. This will prevent conflicts between old files and the new system.
Diagnosing and solving boot problems
The first boot after porting may take from 5 to 15 minutes. If the device is stuck in the power-on animation for more than 20 minutes, a bootloop has most likely occurred. In this case, you need to boot into Recovery and look at the installation logs or use adb logcat to analyze the boot process.
A common problem is an error Status 7 during installation. It occurs if the script updater-script checks a device model that your phone does not match. The solution is simple: open the script in a text editor and delete the lines with the function assert.
| Symptom | Probable cause | Solution method |
|---|---|---|
| Cyclic reboot | Kernel conflict or SELinux | Replace the kernel with a stock one, check the context |
| Black screen with backlight | Incorrect path to framebuffer | Edit init.rc or replace vendor.img |
| Status 7 error | Model mismatch in the script | Remove assert from updater-script |
| No connection and Wi-Fi | Missing firmware files | Return the /firmware folder from stock |
Another common problem is the lack of superuser rights or a broken sensor. To treat the sensor, sometimes it is necessary to replace the files .idc in the folder /system/usr/idc with files from the stock firmware. If the sound does not work, check the audio policy files in /system/etc.
The golden rule of porting: the fewer changes you make to the structure of the kernel and vendor section, the higher the chance for stable operation of the system.
Is it possible to port firmware from Android 13 to a device with Android 10?
Technically this is possible, but extremely difficult. The kernel will need to be replaced with a newer version, which is often impossible without source codes from the manufacturer. Most likely, you will encounter incompatibility between drivers and HAL libraries, which will lead to camera and communication inoperability.
What is GSI and how is the port different from it?
GSI (Generic System Image) is a generic system image created by Google for Project Treble-enabled devices. A port is a manual adaptation of specific firmware for specific hardware. GSI is easier to install, but the port usually works more stable and has the full functionality of a specific device.
Do you need a computer for porting?
Yes, in 99% of cases a computer is required. Unpacking, modifying and packing images require significant computing resources and specific software that is inconvenient or impossible to run directly on a smartphone.
How to find out if devices are compatible for the port?
Compare kernel versions (must be the same or close), processor architecture (arm64-v8a) and partition type (A/B or A-only). It is also useful to read the forums (4PDA, XDA), where enthusiasts may have already tried to make a similar port.
Is porting safe for data on the phone?
No, the process of installing custom firmware always involves completely clearing the data (Wipe Data). All photos, contacts and applications will be deleted, so creating a backup copy before starting work is a mandatory requirement.