Hair 

Porting firmware to qualcomm snapdragon 615. Porting Android firmware. What you need to port firmware

The topic of how to port Android firmware is rather hackneyed, but does not lose its relevance. On the contrary, more and more people are beginning to take an interest in it. In this article, we will only consider porting devices with the same cores. If you want a super interesting firmware for yourself, then it's time to start dealing with the "kitchen" of this process.

Step-by-step instruction

What will be required:

  • computer with any OS;
  • WinRAR or similar archiver;
  • notepad++;
  • two ROMs: portable (hereinafter PROM - from which we will take "tsatski") and basic (hereinafter BROM - on which we will assemble).

* BROM - as a rule, native firmware.

**Since this is an ARM device, you first need to know what processor you have.

Act one

Create a backup from the system/app directory to any folder on your desktop. Copying the files, you will understand what's the matter, because if you started porting, it means that you have probably flashed your MID more than once.

Action two

Delete the directories shown in the picture from BROM and, accordingly, paste the folders from PROM instead.

Act Three

Now we throw the files from the first action back into BROM.

act four

We go into the system / lib BROM folder and copy and replace all the libraries into the corresponding PROM storage (don't be surprised, it's easier this way). We do the same along the paths /system/etc/init.d and /system/etc/permissions. The above three directories can now be destroyed (in BROM), and everything from PROM can be copied in their place.

Important: open the build.prop files in both ROMs with Notepad++. This improved notepad shows tabs well. The latter must be one opposite the other, and the ro.build.description = entry must absolutely match, otherwise you will not be able to flash the device at all. If the post is wrong, edit it. Do the same with the updater-script located on the path META-INFcomgoogleandroid. Naturally, the entry must be identical to the PROM entry.

Very important: you absolutely cannot change symlinks. You can change or fix it, or add ui_prints, run_programs, asserts and of course the kernel.

The most important: in Updater-script BROM Format values ​​should be for your device. Sometimes you need to fix the init.rc BOOTCLASSPATH or just copy it from RBOOT. Then, of course, repack the kernel.

Well, everything! Porting ARM-based Android firmware is done like this. Good luck!

Qualcomm Smartphone Software Update Tool- a flasher for Android devices (smartphones and tablets) that have a Qualcomm processor under the hood. Multi-port, by the way, supports up to 16 devices under simultaneous firmware. Thus, you can reflash up to sixteen, for example, smartphones at once! And the process of flashing each of them takes about four minutes. Instructions with all the details are available in the archive, or you can read a little more below. Also in the archive you will find the necessary drivers for Quilcom.


  • Genre: flashing
  • Platform: Windows


  • firmware_filename.bin (maybe .7z) - archive with firmware

  • Qualcomm Smartphone Software Update Tool - flash driver

  • Uniscope_Qualcomm driver_V1.0.1.zip - Qualcomm drivers (when installing on a 64-bit OS, it is necessary to disable driver digital signature verification)

  • Flashing_Procedure_Instruction for flashing.pdf - instructions for flashing (all logins, passwords from the flasher are in this manual)


We turn off the phone if you had it turned on before and holding the Volume + and Volume - buttons, hold the power button until the phone turns on. We connect the phone to the PC with a cable and open the device manager.


If done correctly, you will see the QHSUSB_BULK device in Device Manager with the following VID and PID: USB\VID_05C6&PID_9008&REV_0000


We right-click on it and select the item "Update drivers ...", then select the search for drivers on this computer and specify the Uniscope_Qualcomm driver_V1.0.1 folder, which we got when unpacking the archive, as the path to the drivers:



Launch Qualcomm Smartphone Multi-Port Software Upgrade Tool. In the dialog that appears, click on the exclamation mark so that your username Operator changes to Administrator and enter the password ustest, then click Ok.


In the program window, press the Load Soft Folder button and select the folder with the MMX_Q415_SW_V2.8_HW_V0.2__V25112015B1661_LCS4.bin firmware from the archive we unpacked. Next, in any of the windows, select the COM port on which we have the phone in Download Mode (in my case it is COM3) and press the Start button. This is how the window of the Qualcomm Smartphone Multi-Port Software Upgrade Tool looks like before clicking the Start button:


The firmware process has begun


A successful sign of its completion is the appearance of the inscription Download finish! in the status window:


The phone should reboot automatically after the firmware is completed, but not a fact

Firmware porting is of interest to many advanced users who want to adapt their device to a different environment while maintaining its useful properties. Usually the main goal of this process is to make the firmware on your gadget "more interesting" and. Let's look at how all this happens on the Android technology with the ARM platform.

Each of the users would like to add something original to their gadget

What do you need to port firmware?

This process requires the following components:

  • Notepad application or other text editor (however, this program is considered the most convenient and thoughtful among the rest).
  • WinRar archiver.
  • The computer through which the whole process is carried out.
  • Two ROMs - one is the source for transferring the firmware data, on the other we will collect them for the software.

How is the firmware ported?

First of all, we create a backup folder on the computer by copying the following files with the .apk extension from the system / app directory on the PC:

  • vpnservices.
  • camera.
  • bluetooth.

Then, on the device where we will build the firmware (its other name is BROM), we delete these files, and instead of them, which is also called PROM, the following directories:

  • /data.
  • /system/app.
  • /system/framework.
  • /system/fonts.
  • /system/media.

We also copy the libandroid_runtime.so library to the /system/lib folder on the base ROM. Now we are moving back to BROM the previously deleted files from the first step.

Subsequently, we make a copy of such libraries from the base ROM to PROM, such as:

  • system/lib.
  • /system/etc/init.d.
  • /system/etc/permissions.

Please note that copying is done with the replacement of data existing on other equipment, and not as an addition to them. Now we delete these three directories on BROM and copy everything from PROM in their place.

We proceed to work with the Notepad editor and perform the following steps:

  • Open the build.prop file on each ROM and place both windows opposite each other.
  • We verify that the ro.build.description= entry matches on both devices, otherwise the firmware will not be able to be completed. If necessary, so that the entries in PROM and BROM are identical.
  • We go along the path /META-INF/com/google/android and now open files called updater-script for verification. If they are not identical, then you need to correct them so that the BROM matches the value that is specified in the ported ROM.

Note. You can edit or add options such as kernel or permissions, asserts, ui_prints, run_programs, but never change the value of symlinks.

The last thing to do is to check the updater script for the Format values ​​parameter on the base ROM (the specified data should be suitable for ). If the two kernels are from different manufacturers, be sure to unpack the kernel and copy the BOOTCLASSPATH data from the portable ROM to the BROM at init.rc.

After all the actions performed, the firmware will be in the base ROM, and you can supplement it at your discretion. As you can see, the whole process takes a little time and does not require special knowledge. Therefore, you can easily handle the porting of firmware yourself.

This article, which is devoted to porting firmware to officially unsupported Android devices, will be useful for those who want to update the software of their "robot", but for whom the "standard" set of official and custom firmware is not enough. We note right away that certain errors or minor bugs may occur in the process of creating such ports, however, the guide will only touch on general issues, without delving into fixing glitches.

For porting, you will need programs such as Notepad ++ (or any other high-quality text editor), WinRar (or other archiver program), a personal computer (with Windows operating system or another), as well as at least a basic level of knowledge in the structure of the Android operating system and common sense (for example, it makes no sense to port HDPI-ROM directly to MDPI and so on).

You will also need two ROMs - a portable one and a CM7 / GB / Stock as a base for the port being created. You should also be identified by which revision of the ARM platform your device is based on (ARMv5, ARMv6 or ARMv7), since the ROM base and ROM port must be for the same type of processor.

In fact, the work is carried out with three main folders - a portable ROM, from which we extract everything we need; base ROM - that is, where porting is done, and where we are already building a new version of ROM; backups created along the way.

First, let's create a backup from the base ROM folder, namely the files that are in the directory /system/app:

stk.apk
vpnservices.apk
camera.apk
bluetooth.apk

Backup can be placed anywhere you like, even on your desktop.

Remove the following folders from the base ROM and replace them with the portable one:

/data
/system/app
/system/framework
/system/fonts
/system/media

Don't forget to copy from the portable ROM to the base library libandroid_runtime.so to a folder /system/lib, because without it, the new ROM will most likely not start at all. However, if, under the condition of replacement, the device goes into a cyclic reboot, that is, it reboots non-stop and to no avail, it’s worth trying to use libandroid_runtime.so from the base ROM.

We copy the files that we backed up to the base ROM. Next, copy all the libraries and folders located in system/lib base ROM, to the appropriate directory of the portable one. We replace all files in case of a match in names. Delete directory in database lib completely, we move the same folder from the ported to the base ROM.

Go to folder /system/etc base ROM, open the folder init.d. Copy all its contents to the same ( /system/etc/init.d) directory of the portable ROM. Then we delete the folder in the "base". Copy init.d to the "base" from the "port", to /system/etc.

Reopening the directory /system/etc base ROM, where we open the folder permissions. Copy all its contents to the same folder ( /system/etc/permissions) of a portable ROM. Again, delete the folder permissions in the "base", after which we copy from the portable ROM permissions in /system/etc base ROM. Such simple actions can fix permission and gapps problems before they actually appear.

Open the file with a text editor (we recommend using Notepad++) build.prop portable ROM and "base". Place two Notepad++ windows next to each other and edit build.prop portable ROM according to the base one, so that they match. It is very important that the parameters:

ro.build.description=
ro.build.fingerprint=

AT build.prop of the portable ROM were the same as in the base ROM, otherwise the created firmware will not work at all. We save build.prop and close Notepad++, then copy Build.prop from portable ROM to base.

Now you need to edit updater-script. Go to folder META-INFcomgoogleandroid base ROM and open this file with Notepad++. We also open updater-script and portable ROM. Place two Notepad++ windows side by side and change updater-script"bases" for similarity with updater-script"port". It is strongly not recommended to change symlinks. Just need to fix or add any permissions, asserts, ui_prints, run_programs and the firmware kernel to be installed. AT updater-script"bases" are carefully checked to Formatvalues were set for the desired model of the mobile device. We double-check, or we have chosen the desired kernel. If the device is not from the same manufacturer from which the kernel is taken, then you definitely need to unpack it, and then fix it BOOTCLASSPATH in init.rc. BOOTCLASSPATH from the "port" we copy to the base ROM, after which we pack the kernel again.

That's basically it. The final firmware turned out in the base ROM folder. You can also add different applications, patches, scripts, and so on to your taste.

Have questions?

Report a typo

Text to be sent to our editors:

Send