Still flashing? Try dual systems!

1. Preface:

 

Flash flash seems to be a patent for Android mobile phone users, but the users who will flash are generally new and old roles,

 

After a system has been used for a long time, you want to switch to another system, or feel that it is not as good as it is, or you want to change it back, so you have to refresh it.

 

But it is troublesome to brush and brush, and it is not risky to brush each time. Accidentally, it may cause loss of important data.

 

Is there any solution? Yes! Dual System! Three or even four !!

 

This article solves this problem, and uses the method described in this article to fully implement one-click installation and one-click Uninstall of the system. It is as easy as installing and uninstalling the system into APK.

 

(Note: The following method takes Samsung i93xx series mobile phones as an example)

 

2. Let's briefly introduce the Startup Process of Android:

 

When the phone is powered on, the first program integrated into a ROM on the CPU chip

 

This program is responsible for loading the boot program on the NAND Flash or SD card. Generally, the boot program is uboot.

 

Uboot will initialize some devices. The important part here is NAND Flash, so that the Linux kernel can be loaded into the memory and run.

 

The loaded kernel may be the kernel in the boot partition or the kernel in the recovery partition.

 

After the kernel runs, it first mounts ramdisk to the "/" root directory, and then runs/init to create the first process.

 

Init reads/init. RC and performs further initialization, such as creating directories, setting permissions, mounting data, system, and cache partitions, and starting a series of services, including important zygote processes.

 

The zygote process creates a system_server process to complete further initialization and load a series of APK processes.

 

3. Next, let's take a look at the partitions required by an Android system:

 

A uboot partition to guide the kernel

 

One kernel Partition

 

A system partition used to store Android system programs and files

 

A Data Partition is used to store system data, APK program, and APK program data.

 

A cache partition is generally used for upgrades. It is used to store OTA update packages and update logs.

 

4. Next, let's look at the implementation solution of the dual-system:

 

4.1 kernel boot Problems

This is a headache. As mentioned above, the kernel is loaded by uboot through the boot partition or recovery partition.

If you want to load the kernel of another partition, you must consider modifying the uboot configuration parameters or code.

We certainly do not have uboot code,

Although the uboot configuration parameters are usually stored in a partition, they are generally encrypted and cannot be changed.

Therefore, we can only consider using our own partitions.

The simplest method is to overwrite the boot partition and write the boot. img of the second Android server to the boot partition,

Then write an APK and write the boot. IMG of the system to the boot partition when the system is to be started.

The disadvantage of this method is that switching is troublesome. You must first start one of the systems for each switching, and then run the APK to switch.

Then, we looked greedy at the rediscovery partition.

As you know, the recovery partition is generally used only when the system is upgraded or the factory settings are restored. Therefore, we want to start with the recovery partition.

The simplest way is to put the second Android system boot. IMG in the rediscovery partition, which triggers the recovery to guide the second Android system.

Of course, you can also add a custom uboot in the recovery partition to achieve more flexible loading methods, such as displaying the boot menu and loading the kernel from the SD card.

However, the source code of uboot is required.

Of course, before using the recovery partition, back up the recovery partition.

Another advantage of using the recovery partition as the Linux boot partition of the second system is that the mobile phone usually has a shortcut key to boot into the recovery,

For example, a Samsung mobile phone usually presses the volume plus, home, and power buttons at the same time when it is turned on.

This facilitates system switching.

 

4.2 system, Data Partition creation problems:

 

Solve the boot problem. Let's take a look at the problem of system and Data Partition creation.

 

Because cache partitions are only used during upgrade, the two systems can be shared and no longer need to be created.

 

1) re-partitioning:

That is, to create different partitions for each system, This method requires re-partitioning the storage space, which is obviously troublesome, risky, and feasible.

2) solutions for Using Virtual Disks

You must be very impressed with how Ubuntu can be directly installed in windows.

In fact, UBUNTU can achieve installation without re-partitioning by using a virtual disk.

Compared with the first scheme, this avoids the trouble of re-partitioning.

The virtual disk is already supported by the kernel in Linux and is a mature technology.

Therefore, the virtual disk is the best choice here. With the help of Virtual Disks, we can not only implement dual systems, but also implement three or four systems, depending on the storage space.

 

5. The theory is clear. Next, let's take a look at how to do it.

First, we need to create a system virtual disk. There are two methods:

 

One is to directly generate a virtual disk from IMG, and the other is to write the system partition in an OTA update package to the virtual disk.

 

The first method is relatively simple. You only need to execute a command:

 

Simg2img system. IMG system. Disk

 

Simg2img can be found in the out/host/linux-x86/bin/directory after compilation

 

6.5 if you get a zip-format OTA update package, the content is similar to the figure below:

 

It is a little difficult to create a system virtual disk. Let's take a look at how to make it:

Update-Script script under the META-INF \ com \ google \ Android directory of the compressed package needs to be modified

1) Remove the format and mount/system partition scripts.

format("ext4", "EMMC", "/dev/block/mmcblk0p9", "0", "/system");mount("ext4", "EMMC", "/dev/block/mmcblk0p9", "/system");

2) Remove scripts for writing boot. IMG and data partitions.

 

package_extract_file("boot.img", "/dev/block/mmcblk0p5");

 

Be sure to remove the write operation for boot. IMG.

 

In short, remove one operation that is irrelevant to the system partition, and remove the formatting and mounting operations of the/system partition.

 

Be careful and be careful.

 

3) Next, package the extracted OTA update package into a zip file.

 

4) then go to the recovery for further operations (here, the recovery is preferably a third-party recovery, such as CM recovery, which has a wide range of commands and is relatively good for operations)

 

5) connect to your phone via USB. after entering the recovery, ADB will automatically connect to the recovery, and then execute the following commands in sequence:

 

Before executing the following script, make sure that your mobile phone can obtain system permissions in shell.

 

Upload the upgrade script execution program to the/data/local/tmp directory of the phone, update-binary in the upgrade package's META-INF \ com \ google \ Android directory, and Updater-script in the same directory.

adb push update-binary /data/local/tmp

 

Upload the updated Update-script OTA update package to the corresponding directory on your mobile phone.

adb push ota.zip /data/local/tmp

Switch to root permission

adb shellsu

Create a MB Virtual Disk

cd /data/local/tmpdd if=/dev/zero of=system.disk bs=1024 count=819200

Loop Virtual Disk System. Disk

busybox losetup /dev/block/loop7 system.disk

Format a Virtual Disk

busybox mkfs.ext2 /dev/block/loop7

Mount a virtual disk to the/system directory

busybox mount -o loop -t ext4 /dev/block/loop7 /system

Modify Update-binary to execute

chmod 777 update-binary

Run the update-Script script to install the OTA update package to the/system directory.

./update-binary 2 0 ota.zip

Detach a System Virtual Disk

umount /systembusybox losetup -d /dev/block/loop7

Exit System permission

Exit

 

Exit ADB Shell

Exit

Upload system. disk to PC from mobile phone:

ADB pull/data/local/tmp/system. Disk

In this way, the system virtual disk is ready for a biscuit :).

 

7. Next, let's take a look at how to create an ext4 data virtual disk.

 

dd if=/dev/zero of=data.disk bs=1024 count=30720 busybox losetup /dev/loop0 data.disk mkfs.ext4 -m 1 -v /dev/block/loop7

 

8. Next, let's take a look at how to mount a virtual disk.

 

1) first, you need. IMG needs to be decompressed before performing an operation. There should be decompression tools on the network, but I generally like to write some gadgets to complete some simple tasks, so as to deepen my understanding, second, it facilitates function expansion.

 

So here we use python to write a program for decompression:

 

unpack.py"""    unsigned char magic[BOOT_MAGIC_SIZE];    unsigned kernel_size;  /* size in bytes */    unsigned kernel_addr;  /* physical load addr */    unsigned ramdisk_size; /* size in bytes */    unsigned ramdisk_addr; /* physical load addr */    unsigned second_size;  /* size in bytes */    unsigned second_addr;  /* physical load addr */    unsigned tags_addr;    /* physical addr for kernel tags */    unsigned page_size;    /* flash page size we assume */    unsigned unused[2];    /* future expansion: should be 0 */    unsigned char name[BOOT_NAME_SIZE]; /* asciiz product name */    unsigned char cmdline[BOOT_ARGS_SIZE];    unsigned id[8]; /* timestamp / checksum / sha1 / etc */"""import sysimport structimport subprocessBOOT_MAGIC_SIZE = 8BOOT_NAME_SIZE = 16BOOT_ARGS_SIZE = 512boot_img = Nonekernel_img = Noneramdisk_img = Noneramdisk_cpio = Noneramdisk_out = Noneif len(sys.argv) >= 2:    boot_img = sys.argv[1]else:    boot_img = 'boot.img'if len(sys.argv) >= 3:    kernel_img = sys.argv[2]else:    kernel_img = 'kernel.img'if len(sys.argv) >= 4:    ramdisk_img = sys.argv[3]else:    ramdisk_img = 'ramdisk.img'if len(sys.argv) >= 5:    ramdisk_cpio = sys.argv[4]else:    ramdisk_cpio = 'ramdisk-m.cpio'if len(sys.argv) >= 6:    ramdisk_out = sys.argv[5]else:    ramdisk_out = 'ramdisk'f = open(boot_img,'rb')magic = f.read(BOOT_MAGIC_SIZE)kernel_size = f.read(4)kernel_size = struct.unpack('I',kernel_size)[0]print kernel_sizekernel_addr = f.read(4)kernel_addr = struct.unpack('I',kernel_addr)[0]print "0x%x"%(kernel_addr,)ramdisk_size = f.read(4)ramdisk_size = struct.unpack('I',ramdisk_size)[0]print ramdisk_sizeramdisk_addr = f.read(4)ramdisk_addr = struct.unpack('I',ramdisk_addr)[0]print "0x%x"%(ramdisk_addr,)second_size = f.read(4)second_size = struct.unpack('I',second_size)[0]print second_sizesecond_addr = f.read(4)second_addr = struct.unpack('I',second_addr)[0]print "0x%x"%(second_addr,)"""    unsigned tags_addr;    /* physical addr for kernel tags */    unsigned page_size;    /* flash page size we assume */    unsigned unused[2];    /* future expansion: should be 0 */"""f.seek(BOOT_MAGIC_SIZE + 3*2*4 + 4+4+4*2)"""    unsigned char name[BOOT_NAME_SIZE]; /* asciiz product name */    unsigned char cmdline[BOOT_ARGS_SIZE];"""    name = f.read(BOOT_NAME_SIZE)print namecmdline = f.read(BOOT_ARGS_SIZE)print cmdlinepage_size = 2048f.seek(2048)data = f.read(kernel_size)with open(kernel_img,'wb') as ff:    ff.write(data)           ramdisk_offset = 2048 + (kernel_size+page_size-1)/page_size*page_sizeprint 'ramdisk_offset:',ramdisk_offsetf.seek(ramdisk_offset)data = f.read(ramdisk_size)with open(ramdisk_img,'wb') as ff:    ff.write(data)cmd = 'gzip -d -r  < %s  >%s'%(ramdisk_img,ramdisk_cpio)subprocess.check_output(cmd,shell=True)cmd = 'mkdir %(ramdisk)s;cd %(ramdisk)s;cpio -i < ../ramdisk-m.cpio'%{'ramdisk':ramdisk_out}subprocess.check_output(cmd,shell=True)

This program extracts kernel. IMG and ramdisk. IMG from boot. IMG, and decompress ramdisk. IMG in ZIP format to the ramdisk directory by default.

 

2) Modify fstab. smdk4x12

 

Original content:

 

# Android fstab file.#<src>                  <mnt_point>         <type>    <mnt_flags and options>                               <fs_mgr_flags># The filesystem that contains the filesystem checker binary (typically /system) cannot# specify MF_CHECK, and must come before any filesystems that do specify MF_CHECK/dev/block/mmcblk0p9    /system             ext4      ro,errors=panic                                                                   wait/dev/block/mmcblk0p3    /efs                ext4      nosuid,nodev,noatime,noauto_da_alloc,discard,journal_async_commit,errors=panic    wait,check/dev/block/mmcblk0p8    /cache              ext4      nosuid,nodev,noatime,noauto_da_alloc,discard,journal_async_commit,errors=panic    wait,check# data partition must be located at the bottom for supporting device encryption/dev/block/mmcblk0p12   /data               ext4      nosuid,nodev,noatime,noauto_da_alloc,discard,journal_async_commit,errors=panic    wait,check,encryptable=footer# VOLD/devices/platform/s3c-sdhci.2/mmc_host/mmc1/ /storage/extSdCard      vfat        default     voldmanaged=sdcard:auto/devices/platform/s5p-ehci/usb1                 /storage/UsbDriveA      vfat        default     voldmanaged=sda:auto/devices/platform/s5p-ehci/usb1                 /storage/UsbDriveB      vfat        default     voldmanaged=sdb:auto/devices/platform/s5p-ehci/usb1                 /storage/UsbDriveC      vfat        default     voldmanaged=sdc:auto/devices/platform/s5p-ehci/usb1                 /storage/UsbDriveD      vfat        default     voldmanaged=sdd:auto/devices/platform/s5p-ehci/usb1                 /storage/UsbDriveE      vfat        default     voldmanaged=sde:auto/devices/platform/s5p-ehci/usb1                 /storage/UsbDriveF      vfat        default     voldmanaged=sdf:auto

 

Modified content:

# Android fstab file.#<src>                  <mnt_point>         <type>    <mnt_flags and options>                               <fs_mgr_flags># The filesystem that contains the filesystem checker binary (typically /system) cannot# specify MF_CHECK, and must come before any filesystems that do specify MF_CHECK/dev/block/mmcblk0p3    /efs                ext4      nosuid,nodev,noatime,noauto_da_alloc,discard,journal_async_commit,errors=panic    wait,check/dev/block/mmcblk0p8    /cache              ext4      nosuid,nodev,noatime,noauto_da_alloc,discard,journal_async_commit,errors=panic    wait,check# data partition must be located at the bottom for supporting device encryption/dev/block/mmcblk0p12   /dat               ext4      nosuid,nodev,noatime,noauto_da_alloc,discard,journal_async_commit,errors=panic    wait,check,encryptable=footer# VOLD/devices/platform/s3c-sdhci.2/mmc_host/mmc1/ /storage/extSdCard      vfat        default     voldmanaged=sdcard:auto/devices/platform/s5p-ehci/usb1                 /storage/UsbDriveA      vfat        default     voldmanaged=sda:auto/devices/platform/s5p-ehci/usb1                 /storage/UsbDriveB      vfat        default     voldmanaged=sdb:auto/devices/platform/s5p-ehci/usb1                 /storage/UsbDriveC      vfat        default     voldmanaged=sdc:auto/devices/platform/s5p-ehci/usb1                 /storage/UsbDriveD      vfat        default     voldmanaged=sdd:auto/devices/platform/s5p-ehci/usb1                 /storage/UsbDriveE      vfat        default     voldmanaged=sde:auto/devices/platform/s5p-ehci/usb1                 /storage/UsbDriveF      vfat        default     voldmanaged=sdf:auto

Here, the system partition is deleted, and the Data Partition is changed from the original mounted to dat to the/DAT directory.

 

Because here we actually want to mount a Virtual Disk

 

3) In init. RC:

 

Modify on init:

In

Mkdir/System

Add:

Mkdir/dat

4) In init. smdk4x12. RC, modify on FS

In

Mount_all/fstab. smdk4x12

Add:

Mount ext4 [email protected]/DAT/system. Disk/system RW wait noatime Mount ext4 [email protected]/DAT/data. Disk/Data wait nosuid nodev noatime

 

Summary:

 

1) First, mount the partition that should be mounted to the/data directory to the/DAT directory.

 

2) The next two lines of scripts mount the virtual disk to/System and/data respectively.

 

3) Yes, so easy !, However, when the function has not yet been implemented, there is still some experience in the process from brewing to trying, to success, although the key virtual partition mounting is completed with two intentions (watching the CCTV record, haha, never learn ).

 

9. Re-package the kernel and ramdisk into boot. IMG.

 

After the ramdisk is modified, We need to repackage it into boot. IMG. Three commands are used: mkbootfs, minigzip, and mkbootimg. Mkbootfs packs all the files in ramdisk into cpio files.

 

Minigzip is compressed. mkbootimg generates boot. IMG from the kernel and ramdisk. IMG. The usage is as follows:

 

Mkbootfs ramdisk | minigzip> ramdisk. img

 

Mkbootimg -- kernel. IMG -- ramdisk. IMG -- output boot. img

 

10. Next, the last step is to install the second Android operating system?

 

The installation is really simple. Write boot. IMG to the recovery partition and copy system. Disk and data. disk to the/Data Partition.

 

Of course, you can also put system. Disk and data. disk in the external SD card, which involves modifying ramdisk

 

11. Finally, let's summarize the full text:

 

It is no longer a new technology to implement dual systems on mobile phones. After using virtual disks to implement dual systems, Baidu later saw an article written in the past 11 years, dual systems are implemented by partitioning on the SD card, which is troublesome to operate,

 

The switch should also be started to one of the systems by flushing the boot partition to achieve the system switching. It is not as convenient as directly refreshing the recovery partition in this article.

 

The dual-system implementation in this article is actually relatively simple:

 

1) convert system. IMG to a system. Disk format that can be directly mounted through loop through simg2img

2) create a Data Partition Virtual Disk Data. Disk

3) modify the boot script in Boot. IMG to mount the virtual disk and repackage it.

4) place system. Disk and data. disk in the original data partition.

5) refresh the re-packaged boot. IMG to the recovery partition.

 

12. Is this the end or just the beginning?

 

If it is a network set-top box, the above is enough, but we are creating a dual system on the mobile phone, so there is still a way to go, the following are the questions to consider:

 

1) How to synchronize the communication records in the two systems

 

2) How to synchronize the data of commonly used tools in the two systems, such as chat records.

 

3) how to deal with the incompatibility of the baseband of different Android versions.

 

4) how to deal with the incompatibility of EFS partitions in different versions of Android systems.

 

5) How to Implement the android + WP Dual System

 

6) how to implement three or four systems?

 

7 )...

 

(End)

 

 

Still flashing? Try dual systems!