Custom Android: we make our own firmware from stock, without digging into the sources. Android firmware using FastBoot utility Installing boot img

MTwinTools is a utility that allows you to work with firmware files and images boot.img, recovery.img and system.img. The author of the utility is vin2809 from the w3bsit3-dns.com forum. MTwinTool will come in handy for owners Huawei smartphones based on MTK processors.

MTwinTools User Guide

1. Introduction.

1.1. Appointment.

MTwinTools tool is designed to disassemble / assemble device images based on MT chips.

It is built for use in command line based on the RKwinTools tool designed to work with devices on RK29xx-RK31xx chips, and some free software.

Works only under Windows 7 and higher without installing CYGWIN, and also does not require any additional registration of paths in OS environment variables.

The tool allows you to:

• unpack and pack the Boot.img image;
• unpack and pack the Recovery.img image;
• unpack and pack the Kernel.img image;
• unpack and compress the System.img image, both yaffs type and ext2-ext4;
• convert a sparse file to an ext4 image;
• calculate the checksum of the file in md5 format;
• initiate SuperUser.

1.2. Installing MTwinTools.
The tool is installed by unpacking the archive in any place convenient for you. This will create an MTwinTools folder containing:

• _In /, App / and Cygwin / folders;
• as well as the Readme.txt and menu.bat files.

The _In folder is empty and is intended to contain the source images for processing. The App / folder contains the set batch files processing images. The Cygwin / folder contains free service libraries and files. The Readme.txt file contains the user's manual, i.e. the text you are currently reading. The menu.bat file is used to create the MTwinTools menu.

ATTENTION. No prescribing paths to service files in Windows OS environment variables is REQUIRED.

During work, other necessary folders will appear:

• Pack, which will contain the Boot, Recovery and System files after
  packing, md5 folder containing files with checksum, as well as folder
  Firmware, in the Image subfolder of which the collected Boot files will be located,
  Recovery and System;
• Unpack, in which FULLY unpacked Boot, Recovery and System files
  will be located in the Firmware folder, in the Image subfolder.

1.3. Uninstalling MTwinTools.

The tool is uninstalled by deleting the root folder of the tool, i.e. the MTwinTools folders.

2. Basic rules of work.

2.1. To get started, you need to run the menu.bat file, this will launch the tool menu.

2.2. The images intended for unpacking must be placed in the _In folder of the tool. Input file names MUST contain keywords and may have names of the following form:

• * boot * .img;
• * recovery * .img;
• * kernel * .img;
• * system * .img.

2.3 At the first start, initialize the tool. When the tool is initialized, ALL files located in the _In folder will be copied to the working input folder Unpack / Firmware / Image. This is done in order to preserve the original files.

2.4 After disassembling the image, its contents will be placed in the Unpack folder, in which the following folder structure will be created:

Boot (Recovery) / cfg /
kernel /
ramdisk /

The cfg / folder will contain the image settings, in the kernel folder you will find the kernel, i.e. the zImage binary, and the ramdisk folder will contain everything else. To complete the assembly of the image, its constituent parts, i.e. ramdisk, kernel, and possibly settings, place in the appropriate folders in Unpack. The generated image will be in the Pack output folder.

3. Description of the tool.

3.1. Main menu of commands.

The main command menu of the tool looks like this:

**************************
* MTwinTools_V_0.6 *
**************************
* Image commands: *
* ————— *
* 1-Boot *
* 2-Recovery *
* 3-Kernel *
* 4-System *
* 5-Other commands *
* *
**************************
* Tools commands: *
* ————— *
* 6-Init Tools *
* 7-Clean *
* *
**************************
* 8-Exit *
**************************
Please, choose command:

The choice of a command is made by entering the number indicated in front of it. In the current version, you can run the following actions:

- go to the Boot image processing menu by typing the number "1";
- go to the image processing menu Recovery - "2";
- go to the Kernel image processing menu - "3";
- go to the image processing menu System - "4";
- go to the menu of other commands - "5";
- carry out initialization work area funds - "6";
- to clean the working area of ​​the tool - "7";
- to complete the work, i.e. get out of the facility - "8".

3.2. Boot menu.

To proceed to processing the Boot image, execute the "1-Boot" command. This will take you to the "Boot commands" menu.

The Boot imaging menu looks like this:

**************************
* Boot commands: *
* ————— *
* 1-Boot unpack *
* 2-Boot pack *
* *
**************************
* 3-Return *
**************************
Please, choose command:

Command "1" unpacks Boot images, command "2" compresses Boot images. By command "3" you will return to the main menu of the tool.

2.2.1. Disassembling the boot.img image.

2.2.2. Build the boot.img image.

When building the boot image, the data source selection menu will appear.

**************************
* Choice source image: *
* 1. Unpack dir *
* 2. Pack dir *
* 3. Return *
**************************
Please, choose source:

You have the opportunity to build an image from the unpacked image located in the Unpack / Boot folder, for this select the menu item “1. Unpack dir ". If you select the menu item “2. Pack dir ”, the image will be created from the data located in the Pack / boot folder. To cancel the operation, select the menu item “3. Return ". In this case, you
return to the Boot commands menu.

3.3. Recovery menu.

To proceed to processing the Recovery image, run the "2-Recovery" command. This will take you to the "Recovery commands" menu. The Recovery image processing menu looks like this:

**************************
* Recovery commands: *
* —————— *
* 1-Recovery unpack *
* 2-Recovery pack *
* *
**************************
* 3-Return *
**************************
Please, choose command:

Command "1" unpacks Recovery images, command "2" compresses Recovery images. By command "3" you will return to the main menu of the tool.
2.3.1. Disassembling the recovery.img image.

All actions are performed automatically, i.e. without your participation there is nothing to describe here.

2.3.2. Build the recovery.img image.

When building a recovery image, a data source selection menu will appear.

**************************
* Choice source image: *
* 1. Unpack dir *
* 2. Pack dir *
* 3. Return *
**************************
Please, choose source:

You have the opportunity to build an image from the unpacked image located in the Unpack / recovery folder, for this select the menu item “1. Unpack dir ". If you select the menu item “2. Pack dir ”, the image will be created from the data located in the Pack / recovery folder.

To cancel the operation, select the menu item “3. Return ". This will return you to the "Recovery commands" menu.

3.4. Kernel menu.

To proceed to processing the Kernel image, run the "3-Kernel" command. This will take you to the "Kernel commands" menu.

The Kernel image processing menu looks like this:

**************************
* Kernel commands: *
* —————— *
* 1-Kernel unpack *
* 2-Kernel pack *
* *
**************************
* 3-Return *
**************************
Please, choose command:

Command "1" unpacks Kernel images, command "2" compresses Kernel images. By command "3" you will return to the main menu of the tool.

3.4.1. Disassembling the kernel.img image.

All actions are performed automatically, i.e. without your participation there is nothing to describe here.

3.4.2. Building the kernel.img image.

When building the kernel image, a data source selection menu will appear.

**************************
* Choice source image: *
* 1. Unpack dir *
* 2. Pack dir *
* 3. Return *
**************************
Please, choose source:

You have the opportunity to build an image from the unpacked image located in the Unpack / Kernel folder, for this select the menu item “1. Unpack dir ". If you select the menu item “2. Pack dir ”, the image will be created from the data located in the Pack / Kernel folder.

To cancel the operation, select the menu item “3. Return ". This will return you to the Kernel commands menu.

3.5. System menu.

To go to the processing of the System image, run the command "3-System". This will take you to the "System commands" menu.

The System imaging menu looks like this:

* System commands: *
* ——————————————— *
* 1-unpack yaffs * 2-pack yaffs *
* 3-unpack ext3 * 4-pack ext3 *
* 5-unpack ext4 * 6-pack ext4 *
* 7-sparse to ext4 * *
* * *
***************************************************
* 8-Return *
***************************************************
Please, choose command:

3.5.1. Disassembling a system image of the yaffs type.

The command "1" unpacks System images of the yaffs type into the Unpack / System folder.

3.5.2. Build a system image of type yaffs.

The command "2" compresses the System images of the yaffs type. The menu for selecting a data source will appear.

**************************
* Choice source image: *
* 1. Unpack dir *
* 2. Pack dir *
* 3. Return *
**************************
Please, choose source:

You have the opportunity to build an image from the unpacked image located in the Unpack / system folder, for this select the menu item “1. Unpack dir ". If you select the menu item “2. Pack dir ”, the image will be created from the data located in the Pack / system folder.

To cancel the operation, select the menu item “3. Return ”and you will return to the previous menu“ System commands ”.

3.5.3. Disassembling a system image of type ext3.

Command "3" unpacks System images of type ext2-ext3 into the Unpack / System folder.

3.5.4. Building a system image of type ext3.

Command "4" builds an ext2-ext3 System image. Packing is performed in the same way as in clause 3.5.2. only the output image will be of type ext3.

3.5.5. Disassembling an ext4 type system image.

Command "5" unpacks System images of type ext4 into the Unpack / System folder.

3.5.6. Building a system image of type ext4.

The command "6" builds an ext4 type System image. Packing is carried out in the same way as in clause 3.5.2. only the output image will be of type ext4.

3.5.7. Convert compressed sparse image to ext4.

Command "7" converts (converts or transcodes) compressed sparse images into ext4 images (analogue of the simg2img operation).

3.5.8 Return to the main menu.

By command "8" you will return to the main menu of the tool.

3.6. Other commands menu.

To move on to the execution of other commands, execute the command "5-Other commands". This will take you to the "Others commands" menu. The menu for executing other commands looks like this:

**************************
* Others commands: *
* —————- *
* 1-Init SuperUser *
* 2-Calculate md5 *
* *
**************************
* 3-Return *
**************************
Please, choose command:

Command "1" initializes SuperUser in the System image, command "2" calculates the checksum of the files. By command "3" you will return to the main menu of the tool.

3.6.1. Initializing SuperUser.

During SuperUser initialization, the source selection menu will appear:

**************************
* Choice source init: *
* 1. Unpack dir *
* 2. Pack dir *
* 3. Return *
**************************
Please, choose source:

You have the opportunity to initialize the unpacked image located in the Unpack / system folder, for this select the menu item “1. Unpack dir ". If you select the menu item “2. Pack dir ”, the image located in the Pack / system folder will be initialized. To cancel the operation, select the menu item “3. Return ".
Initialization is done by copying the required files (su and SuperSU.apk) into the parsed System.img image. To get Root access, you need:

- unpack the System image using the command "3" of the main menu
tools or place the unpacked image in the Unpack (or Pack) / System / folder;
- execute the command "1-init SuperUser" of the "Others commands" menu.

After flashing the System.img image, you will have Root access on your device. If files of a different version are used to obtain Root access on your device, then you just need to update (replace) the su and SuperSU.apk files in the App / folder.

3.6.2. Checksum calculation.

To calculate the checksum of a file or files, place them in the Pack / md5 / folder. After executing the command "2-Calculate md5", all files in the Pack / md5 folder will be appended with check sum calculated using the md5 algorithm. Only files without extension or with extension .img, .tar, .zip are processed.

3.7. Initialization.

To carry out initialization, execute the command "6-init Tools". This will create all the folder structures necessary for the MTwinTools to work and copy the input images to the Unpack / Firmware / Image working folder.

3.8. Cleaning the product.

Type 7-CLEAN to clear the work area. In this case, ALL additional folders along with the content will be deleted, the MTwinTools tool will exit and return to what it looked like immediately after installation.

3.9. Output.

Dial "8-Exit" to exit. This will ONLY exit the product without any cleaning.

Mega utility Android IMG Repack Tools for all beginners and advanced romodels, developers, for editing Android images.

Android IMG Repack Tools what is it and why?

Android IMG Repack Tools utility from the user under the nickname A.S._id(xda, w3bsit3-dns.com), designed to edit Android images:

• unpack Android image (img, ext4)
• editing files (manually)
• collect the image

As well as working with kernels (boot.img) and recovery (recovery). The utility is designed to work from both Linux and Windows (you need to install Cygwin).

Android IMG Repack Tools will be useful for absolutely all Android romodels to create new custom firmwares, as well as for software developers.

Where can I find and download Android IMG Repack Tools?

You can also download the latest version of the Android IMG Repack Tools from the official project page on XDA.

Installing Android IMG Repack Tools on your computer

Since Android OS is based on Linux kernel, then the Android IMG Repack Tools utility from a Linux-based operating system will work more correctly.

OS Presetting for Android IMG Repack Tools

If you have Ubuntu version 14.04 or older (and Mint based on it), then you will need to install GCC 5 from the repository (open a terminal and type the following commands):

sudo add-apt-repository ppa: ubuntu-toolchain-r / test

sudo apt-get update

sudo apt-get install gcc-5 g ++ - 5

sudo update-alternatives --install / usr / bin / gcc gcc / usr / bin / gcc-5 60 --slave / usr / bin / g ++ g ++ / usr / bin / g ++ - 5

For Ubuntu 16.04 users (and Mint based on it), you need to install first:

1. GNU Automake 1.14 (download and unpack)

2. Go to the folder with Gnu Automake, open a terminal and execute the commands one by one: ./configure make sudo make install

3. Install packages: sudo apt-get install git-core gnupg flex bison gperf libsdl-dev libesd0-dev build-essential zip curl libncurses5-dev zlib1g-dev valgrind libreadline6-dev gcc-multilib g ++ - multilib libc6-dev x11proto-core -dev libx11-dev libz-dev gawk texinfo automake libtool cvs libsdl-dev

Setting up Android IMG Repack Tools

1. After you have downloaded Android IMG Repack Tools, unpack, go, open a terminal

2. Type the command to run the utility. / Main_menu

If you have Mint installed, then click on the main_menu file

3. Go to the utility section “ 0 - Configure & clean tools menu»

4. Select " 1 - Build android_img_repack_tools“To download and configure the tools that work with Android images.

Working with Android IMG Repack Tools

Expect an update of the article with instructions on how to use the utility soon!

Need to flash Android using FastBoot, but don't know how? This article gives detailed instructions on using the FastBoot utility and how to use it to flash an Android device.

This manual will tell you how to use FastBoot in full! If you do not know how to install archived updates, then you need an article - Clockwordmod - what is it. Instructions for CWM recovery with pictures

Download and install FastBoot

Before flashing Android using FastBoot, you need to download and install it on the required computer.

1. You can download the FastBoot utility with the official program Android SDK(heavy weight)

why ADB RUN is better

Launch

If downloaded Separately Fastboot

After you have downloaded and installed FastBoot, open the program “ Command line »

and vve Give commands to go to the folder with the Fastboot utility (if you have installedseparately FastBoot )

cd /
cd adb

If you downloaded ADB RUN

If your choice fell on the ADB RUN program, then run it and select Manual -> ADB in the menu

The files that need to be flashed must be located in the same folder with the Fastboot utility

Instructions for commands how to flash Android using FastBoot

It is very important to write commands and firmware files as they are specified!

If you have a command specified

fastboot flash cache NazvaniAFiLe.img

then you need to write exactly that way, but not otherwise. In other words, the case of letters is important, otherwise you will get an error cannot load ‘image’ - there is no such file.

Reboot commands into firmware mode (bootloader)

fastboot reboot-bootloader

The command "sees" your Android PC

Get in the habit of checking before doing anything in Fastboot if the connection between your computer and Android:

Checking if the PC sees your Android

fastboot devices

Execute this command when the device is already in the firmware mode (bootloader)

Nexus Bootloader Unlock and Lock Commands

Unlock bootloader for Nexus

fastboot oem unlock

Load bootloader for Nexus

fastboot oem lock

Command find out the bootloader version

Shows the bootloader version installed on Android

fastboot getvar version-bootloader

Section formatting commands

Before flashing any section in Android, you first need to format it so that there are no problems in the work

fastboot erase Imya_razdela - erase the partition: boot, radio, recovery, system, userdata and others

Erases the Cache section

fastboot erase cache

Erases the Data section

fastboot erase userdata

Erases the System section

fastboot erase system

Erases the Recovery partition

fastboot erase recovery

Commands for firmware section

After you have formatted the partition or partitions, you can start flashing

fastboot flash Imya_razdela imya_file.img - firmware of the selected partition: boot, radio, recovery, system, userdata and others

Flash the system partition (System)

fastboot flash system imya.img

Flash the cache partition (Cache)

fastboot flash cache imya.img

Flash section date (Data)

fastboot flash userdata imya.img

Flash Recovery partition

fastboot flash recovery imya.img

Setting the turn-on animation (firmware section with animation)

fastboot flash splash1 splash.img

Flash all partitions (boot, recovery and system)

fastboot flashall

Instead of imya.img- you need to write the name of the file that you are going to flash

Command to install update.zip

Flashes an update archive on Android in the update.zip format or ZIP archive with IMG images of various sections

fastboot update filename.zip

For Sony devices

Sony device connection check, if the answer is 0.3 device then connected

fastboot.exe -i 0x0fce getvar version

Unlock bootloader

fastboot.exe -i 0x0fce oem unlock 0x Received_Key

More detailed information on unlock Bootloader Sony - How to Unlock Bootloader Sony

Waiting for Device error

If for a long time in the command window the inscription is lit waiting for device- means:

• Driver not installed or incorrectly installed - reinstall or install
• Android device not in Bootloader mode - translate
• Incorrect connection to the USB port - use the rear USB 2.0 ports of the computer, do not use USB hubs

Let's start with the fact that you need Linux. In Windows, you can only disassemble the firmware, but you won't be able to put it back together for purely technical reasons. Now about the firmware. They are usually distributed in the form of ZIP archives flashed through custom recovery. It is one of them that we need for experiments. I recommend starting the path of a romodel with some custom firmware as close as possible to AOSP, because it is often easier to figure it out than stock.

1. We unpack the archive with the firmware into any folder.
2. Download the script from the link and unzip it to any folder.
3. Run the ext file (if you complain about the lack of Java, just skip it by pressing y; Java is needed only for packing).
4. Now we select unpacking by pressing button 1 and then Enter.
5. A new folder named extract_ * will appear next to the ext file and the tools folder. Copy the files system.new.dat and system.transfer.list into it.
6. After copying the files, press Enter and wait. After a while, you will need to press Enter again, enter the administrator password and tap Enter again.
7. Ready. System content in extract _ * / output folder.

Manual way

We unpack the archive with the firmware into any folder (for example, in rom):

$ mkdir ~ / rom $ unzip path_to_archive -d ~ / rom /

Download the tools we need to this folder:

$ cd ~ / rom $ wget https://github.com/xpirt/sdat2img/raw/master/sdat2img.py

Run the script:

$ chmod + x sdat2img.py $ ./sdat2img.py system.transfer.list system.new.dat system.img

It converts the system.new.dat file into a raw image named system.img. Mount the image to the mnt subfolder:

$ mkdir mnt $ sudo mount -t ext4 -o loop system.img ~ / rom / mnt

Android directory structure

After unpacking system, the following directory structure appears:

• app- preinstalled applications with standard privileges;
• priv-app- preinstalled applications with elevated privileges, including some system components;
• bin- binary files of the ELF format, an analogue of the / bin and / usr / bin directories in Linux. Contains various system components used by higher-level system components;
• etc- settings files. A complete analogue of / etc in Linux, used, however, only by the very same system components. Android applications store individual settings in the / data / data / directories;
• fonts- fonts. By default contains only Roboto branded fonts;
• framework- libraries of Java classes used by the system and applications. There is also a framework-res.apk file containing a complete description of the operating system interface, including all graphic files;
• lib and lib64- Linux libraries used by low-level components of the system. Analogue of the / lib and / usr / lib directories in Linux, including such standard libraries as libc, libz, libssl. On devices with ARMv7 architecture and below, the lib64 directory will not be present;
• media- media files: ringtones, notification sounds, interface sounds and OS boot animations;
• tts- files required by the speech synthesizer;
• usr- a directory that usually contains the files required for the operation of applications from the bin directory. Essentially analogous to / usr / share;
• vendor- files supplied by the device manufacturer. Usually contains binary firmware for various hardware components, for example, a Wi-Fi module;
• xbin- optional directory; custom firmware uses it to store things like bash interpreter, SSH, PowerTOP, BusyBox, and other useful tools;
• build.prop- a file containing information about the assembly, as well as various low-level settings;
• addon.d- contains scripts that are run after installing the firmware. GApps also register their script here, thanks to which they are revived after reinstalling the firmware.

After reviewing basic structure Android, let's start making changes.

Remove and add applications

Everything preinstalled programs can be found in two folders:

• / system / app /;
• / system / priv-app /.

They differ from each other in access privileges. If programs from app have the same permissions as third party programs(for example, installed from Play Store), then applications from priv-app can use the privileged API (privileged rights). You can learn more about this from.

To preinstall the application into the firmware, just drop its APK file into / system / app /. You can, of course, create separate folder, but in our case it makes no sense, because the folder is used to store libraries and odex-files, which we simply do not have. To delete, just delete the folder with it.

You can go ahead and swap stock apps for analogs. For example, to replace the calendar, delete the folder Calendar and copy our favorite com.rpagyc.simplecalendar.apk to / system / app. Or you may not copy. Then the firmware will be without a calendar.

The main thing to remember is that stock programs can be linked. Therefore, deleting one program may well lead to the complete inoperability of another (for example, CalendarProvider and Calendar: by deleting the first one, you will disable not only the stock calendar, but also any other calendar). Fortunately, there are not many interconnections in pure AOSP firmware.

Changing the loading animation

The animation is stored in the form of PNG images packed in the archive /system/media/bootanimation.zip without compression. Inside the archive are:

• desc.txt- a file describing the animation;
• part0- folder with animation files that are played first;
• part1- folder with animation files that are played second;
• part?- extreme folder, images from which are played at the end.

The desc.txt file might contain something like

1920 1080 60 p 1 0 part0 p 0 0 part1

The purpose of these lines is intuitive: 1920 × 1080 is the picture resolution, 60 is the number of frames per second. Part0 and part1 indicate the folders from which the animation will be played and the playback sequence. In general, there can be either one part or several (three or more).

The images in the part folders are numbered with five numbers in the playback order: 00000.png, 00001.png, 00002.png ... These images can be changed to your own, thereby creating an original animation. Alternatively, you can simply delete the bootanimation.zip file. Then the device will show animation from standard Android... Or use a ready-made collection of animations on w3bsit3-dns.com.

Changing the sound design

In fact, all the sounds that the system plays are stored in the / system / media / audio folder. Inside it you will find the following folders:

• alarms- alarm ringtones;
• notifications- notification sounds;
• ringtones- ringtones;
• ui- system sounds, such as low battery, camera focus, selection of interface elements.

In alarms, notifications, ringtones, you can add as many melodies as you like. You can take them, for example, here:

• standard melodies from various Nokia phones and smartphones;

And a little life hack: deleting files from the ui folder will lead not to crashes and errors, but to disappear system sounds... Therefore, you can easily turn off the sound of taking a picture from the camera, taking a screenshot, simply by rubbing the files containing these sounds (their names are intuitive).

Adding fonts

Fonts are stored in fonts. You can find archives with font files on w3bsit3-dns.com and XDA. To install, just copy and replace the ttf files from the archive into the fonts folder.

Change system settings (build.prop)

The system image contains an interesting build.prop file containing a lot of useful information about the device hardware and the default settings for various stock applications. In fairness, I note that this is not always the case. For example, in Gigaset ME and ME, Pro build.prop is split into two parts. One part contains the settings for the Gigaset ME, and for the ME Pro, some lines are duplicated, but the keys (the name of the smartphone, etc.) are different in them. This was done to ensure more or less correct operation of the same firmware on different devices.

Build.prop contains (or may contain) a huge amount of settings. Some of them don't change anything, some improve one by degrading the other, but there are some that are really useful:

• ro.product.model and ro.product.manufacturer- smartphone model and manufacturer's name. By replacing these lines, you can make the Play Store think that you have a different smartphone, which will open up access to more software. For all sorts of little-known Chinese smartphones these lines can be life-saving;
• hw.qemu.mainkeys- takes only two values: 0 - show on-screen navigation keys, 1 - do not show buttons. The absence of a line corresponds to 0;
• debug.sf.nobootanimation- value 1 disables loading animation, which slightly increases its speed. Setting it to 0 or removing the line returns the animation to its place;
• ro.telephony.default_network- tells the system which mode to switch to mobile network while loading;
• ro.sf.lcd_density- DPI of the display, the most accurate value for the display can be calculated through a convenient website. But no one forbids putting a greater or lesser value to your liking: higher values ​​make interface elements larger, lower ones - smaller;
• ro.config.vc_call_vol_steps- the number of volume steps during a call (8 by default);
• ro.config.media_vol_steps- number of steps of multimedia volume (15 by default).

Implementing Google Apps into the firmware

Almost always custom firmwares come without Google services and app store. The developers suggest that we install them separately using the GApps package. However, it can be integrated directly into the firmware.

First you need to download the GApps package. I recommend taking the Open GApps archives. You choose Android version, processor architecture and configuration (Pico, Nano, Stock ...), which determines how many different Google applications contains an archive. I recommend downloading the Pico version. It contains only the Play Store and a set of libraries required for its operation.

Integration of GApps into the firmware is done as follows:

1. Unpack the GApps ZIP archive using any archiver.
2. Go to the Core folder.
3. We see a lot of archives with the .tar.lz extension. We extract with lzip.
4. After unpacking, copy the files from the folders to the corresponding folders in system. It is easy to guess what to throw where from the directory structure in the archive. For example, configupdater (from the screenshot) needs to be thrown into the priv-app folder.
5. Go to the GApps folder (located next to Core) and do steps 3 and 4 for the files in it.
6. That's it, we have integrated GApps into our firmware!

Free place

It is necessary to understand that the place for installing firmware is limited. You cannot install firmware that is larger than the size of the device's system partition. You can view its value using:

$ adb shell df / system

The second option: put a terminal on the device and type the command

$ df / system

The size of the section in bytes can be found by installing BusyBox on your smartphone and running the command in the terminal

$ busybox df -B 1 / system

Or the same with using ADB:

$ adb shell busybox df -B 1 / system

The space occupied by the firmware will be approximately equal to the unpacked system size. In general, when creating a firmware, it must be borne in mind that the user can also flash various modifications on top of it (SuperSU, Xposed) or transfer applications to the system section. For example, Google's minimal app suite (Pico) requires a minimum of 150MB of additional installation space.

If necessary, the size of the firmware file can be reduced by removing not only unnecessary programs from / system / app (/ system / priv-app) and call sounds from system / media / audio and bootanimation.zip, but also:

• / system / tts / lang_pico- languages ​​of the primitive voice engine Pico TTS, Google voice engine will not be affected;
• / system / usr / srec / config /- offline languages. You can download it online later if needed.

Assembly

After making the changes, you need to put everything back together. First, let's pack the system partition into system.new.dat. Download the tools we need:

$ wget https://github.com/xpirt/img2sdat/raw/master/img2sdat.py $ wget https://github.com/xpirt/img2sdat/raw/master/blockimgdiff.py $ wget https: // github. com / xpirt / img2sdat / raw / master / common.py $ wget https://github.com/xpirt/img2sdat/raw/master/rangelib.py $ wget https://github.com/xpirt/img2sdat/raw/ master / sparse_img.py $ sudo apt-get install android-tools-fsutils

Convert our folder back to RAW image. Let's call it system_new.img:

$ sudo make_ext4fs -T 0 -S file_contexts -l 1073741824 -a system system_new.img output /

1073741824 change to the size of the system partition in bytes. It is even desirable to make it a little smaller. We make a sparse image from the RAW image:

$ img2simg system_new.img system_snew.img

We transform our image into system.transfer.list and system.new.dat, which we need to throw into the archive with the firmware, but first we delete the old files:

$ rm -rf system.transfer.list $ rm -rf system.new.dat $ rm -rf system.patch.dat $ chmod + x img2sdat.py $ ./img2sdat.py system_snew.img

Let's separate the firmware files from the extra husk (files that we downloaded for work. For this it is convenient to use the archive with the firmware). Deleted? Now you need to pack the firmware into a ZIP archive (by any archiver).

It remains to sign the archive. This can be done both on Android itself using ZipSigner, and on a PC (Java installed is required):

$ wget https://github.com/appium/sign/raw/master/dist/sign.jar $ java -jar file.zip

Underwater rocks

During the build of system.new.dat, you may encounter several problems caused by constant changes in the mechanisms for generating Android firmware. The method described above should work well in the case of firmware based on Android 5.1, newer ones may have difficulties, so you will need to use other versions of the build tools. Unfortunately, we cannot describe all the nuances of the assembly, so you may have to google it.

Installation

To install custom firmware, you need a custom TWRP recovery, which allows you to install firmwares that are unsigned or signed with a test key (this is what we created). In the magazine, we have repeatedly described the installation process, and in the forum threads dedicated to your device, there is usually enough information to do this.

TWRP

conclusions

This article describes just the tip of a huge iceberg called firmware modification. "Serious" firmware not only supplement the kernel and the firmware itself with stock applications with a variety of functions (which are often ripped out of other kernels and firmware), organizing or even changing the principles of their interaction, but can also radically change the operating principles of the OS. True, such a craft is no longer Android, but a separate OS, even if Play services can be installed there (by the way, such actions, to put it mildly, are not encouraged by Google). Well, do not forget: all the shells from manufacturers - TouchWiz, ZenUI, HTC Sense and so on - are just ordinary custom, maximally tied to the hardware of the device and to each other.