Android Dual System implementation

1. Preface:

Brush machine, seems to be a patent for Android mobile phone users, but, will be the user of the brush machine is generally the role of hate.

A system has been used for a long time. Just want to change to have a system. Or think that there is no original good, or think to change back. It's going to have to be brushed again.

But brush to brush to all the trouble ah, and every time the machine is not without risk, accidentally can cause the loss of critical data.

Is there no way to solve it?

Yes. Dual System!

Even three systems, four systems!

！

This article is to solve the problem, and use the method in this article, fully able to achieve one-click installation, one-click Unloading system functions. Installing and uninstalling the system becomes as easy as installing and uninstalling the APK.

(for example, the following methods are based on the Samsung I93XX series phones)

2. Introduction to the startup process of the Android system:

When the phone is power on, the first run of a piece of ROM integrated into the CPU chip on the program

This program is responsible for loading the NAND flash or SD card boot program, the boot program is generally uboot

Uboot will be finished initializing some devices, the very important part here is NAND flash, in order to load the Linux kernel into the memory and execute.

The kernel that is loaded may be the kernel in the boot partition, depending on the situation. It is also possible that the kernel in the recovery partition.

After the kernel runs, it will first mount the RAMDisk to the "/" root folder and then run/init to create the first process.

Init reads the/init.rc for further initialization. Complete such as creating a folder. Set permissions to mount the Data,system,cache partition. Start a series of service. Contains important zygote processes

The zygote process also creates the System_server process to complete further initialization and loads a series of apk processes.

3. Next look at the required partitions for an Android system:

A uboot partition that is responsible for booting the kernel

A kernel partition

A system partition that holds Android programs and files

A data partition. Used to store the system data, APK program. and the APK program data and so on.

A cache partition. Typically used for upgrades, to save OTA upgrade packs, upgrade logs, and more.

4. Then press to see the implementation of the dual system:

4.1 Boot issues for the kernel

This is a more headache problem. The above mentioned. The kernel is loaded by uboot through the boot partition or the recovery partition.

Suppose you want to load another partition's kernel as well. Consider changing the configuration parameters or the code of the Uboot.

Uboot's code, we're definitely not.

Although generally speaking, uboot configuration parameters are often stored in a partition. But it's usually encrypted, so it's not going to change.

So we can only consider using our own partitions.

The simplest way is to overwrite the boot partition and write the second Android boot.img to the boot partition,

Then write an apk that writes the boot.img of which system to the boot partition when the system is to be started.

The disadvantage of such a way is to switch the trouble, each switch must first start one of the system, and then run the APK to switch.

Then we aimed our greedy eyes at the recovery partition.

As you know, recovery partitions are usually used when the system is upgraded or factory reset. So we're thinking about the recovery division.

The simplest approach is to put the second Android system boot.img into the recovery partition, which enables triggering of the recovery to boot the second Android system.

Of course. It is also possible to put a custom uboot in the recovery partition for a more flexible loading mode. such as the ability to display the boot menu and so on, such as from the SD card loaded into the kernel and so on.

However, it is necessary to have Uboot source code.

Of course, before using the recovery partition, make a backup of the recovery partition.

The advantage of using the recovery partition as the Linux boot partition for the second system is that the general mobile phone has a shortcut key to the recovery.

If Samsung's mobile phone is usually at the same time when the power is pressed: Volume Plus, home,power three keys to be able to enter the recovery.

This allows for a convenient system switchover.

4.2 The creation of the System,data partition:

Overcome the problem of guidance. Then look at the creation of the system and data partitions.

Because the cache partition is only used when upgrading, the two systems can be pooled and no longer created.

1) Another partitioning method:

That is, for each system to create a different partition, such a method requires storage space to be divided again. Obviously more troublesome, the risk is also higher. The feasibility is relatively low.

2) Scenarios for using virtual disks

You must be very impressed with how Ubuntu can be installed directly under Windows.

In fact, Ubuntu can be implemented without partitioning the virtual disk that the installation is really using.

Relative to the first scenario. Avoid the hassle of partitioning again.

Virtual disk is a very early kernel of Linux has been supported, is a very mature technology.

So the virtual disk here is the best choice, and the use of virtual disk. We are not only able to implement dual systems, but also to implement three systems. The four systems, which depend entirely on the storage space.

5. The theory is clear, next, look at the detailed how to do it.

First, we're going to create a system virtual disk, and here are two ways to do it:

One is to generate virtual disks directly from IMG, and another way is to write the system partition in an OTA upgrade package to the virtual disk.

The first method is relatively simple, just to run a command can be:

Simg2img system.img System.disk

Simg2img can be found under the compiled out/host/linux-x86/bin/folder

6.5 Suppose you get the OTA upgrade package in a ZIP format, similar to what you see in the figure:

Then making the system virtual disk is a bit of a hassle, see how to make:

Need to change the Update-script script under the Meta-inf\com\google\android folder of the compressed package

1) Removing scripts for format and Mount/system partitions

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 careful here, be sure to get rid of Boot.img's writing operations.

Anyway. Removes a system partition-independent operation and removes formatting and mount operations from the/system partition

Here must be careful + careful.

3) Next, unpack the OTA upgrade package again into a zip file

4) then enter recovery for further operation (here recovery preferably a third-party recovery. such as CM's recovery, command richer, better operation)

5) connect the phone with USB, after entering recovery, the ADB will actively connect to the recovery, then run for example the following command:

Make sure your phone is able to get system permissions in the shell before running the following script

Upload the upgrade script runner to your phone's/data/local/tmp folder, update-binary the Meta-inf\com\google\android folder in the upgrade package, and updater-script the same folder.

ADB push update-binary/data/local/tmp

Upload an OTA upgrade package that has changed update-script to the corresponding folder on your phone

ADB push ota.zip/data/local/tmp

Switch to root permissions

ADB SHELLSU

Create a 800M-size 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

To format a virtual disk

BusyBox MKFS.EXT2/DEV/BLOCK/LOOP7

Mount the virtual disk to the/system folder

BusyBox Mount-o loop-t Ext4/dev/block/loop7/system

Change Update-binary to be operational

chmod 777 Update-binary

Start running the Update-script script to install the OTA upgrade package to the/system folder

./update-binary 2 0 Ota.zip

Uninstalling the System virtual disk

Umount/systembusybox losetup-d/DEV/BLOCK/LOOP7

Exit system Permissions

Exit

Exit adb shell

Exit

Upload System.disk from your phone to your PC:

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

In this way, a pancake--system virtual disk is done:).

7. Next look at how to create a data virtual disk in EXT4 format

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 look at how to mount the virtual disk

1) first to operate on boot.img. To unzip it first, the network should have the tools to unzip. But I generally like to write some small tools to complete some simple tasks, to deepen understanding. Secondly, it also facilitates the expansion of functions.

So, here's a program that uses Python to write an extract:

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 is 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 = 16BO Ot_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_magi c_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 is 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) Subproc Ess.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 the boot.img. And the default is to extract the zip format ramdisk.img to the RAMDisk folder

2) Change 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 this do specify MF_CHECK/DEV/BLOCK/MMCBLK0P9/ System Ext4 Ro,errors=panic WAIT/DEV/BL Ock/mmcblk0p3/efs Ext4 Nosuid,nodev,noatime,noauto_da_alloc,discard,journal_async_commit,errors=pa Nic Wait,check/dev/block/mmcblk0p8/cache Ext4 Nosuid,nodev,noatime,noauto_da_alloc,discard,journa L_async_commit,errors=panic wait,check# Data partition must be located on the bottom for supporting device encryption/d Ev/block/mmcblk0p12/data Ext4 Nosuid,nodev,noatime,noauto_da_alloc,discard,journal_async_commit,erro Rs=panic wait,check,encryptable=footer# vold/devices/platform/s3c-sdhci.2/mmc_host/mmc1//storage/extsdcard vfat default VOLDMA Naged=sdcard:auto/devices/platform/s5p-ehci/usb1/storage/usbdrivea VFAT Default Voldmanag ED=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/device S/platform/s5p-ehci/usb1/storage/usbdrivee VFAT Default Voldmanaged=sde:auto/devices/plat FORM/S5P-EHCI/USB1/STORAGE/USBDRIVEF VFAT Default Voldmanaged=sdf:auto

What's changed:

# 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 this 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,err Ors=panic wait,check# Data partition must be located on the bottom for supporting device ENCRYPTION/DEV/BLOCK/MMCBLK0P1 2/dat Ext4 Nosuid,nodev,noatime,noauto_da_alloc,discard,journal_async_commit,errors=panic Wait,ch eck,encryptable=footer# vold/devices/platform/s3c-sdhci.2/mmc_host/mmc1//storage/extsdcard vfat Default V Oldmanaged=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/PLATF Orm/s5p-ehci/usb1/storage/usbdrivec VFAT Default Voldmanaged=sdc:auto/devices/platform/s5 p-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

This is mainly the removal of the system partition mount, and the data partition from the original mount to dat to mount to the/dat folder

Because here we're actually going to mount the virtual disk

3) in Init.rc:

Change on init:

In

Mkdir/system

Add the following:

Mkdir/dat

4) in init.smdk4x12.rc, change on FS

In

mount_all/fstab.smdk4x12

Add the following:

Mount Ext4 [email protected]/dat/system.disk/system rw wait noatime mount Ext4 [email protected]/dat/data.disk/data wait Nosuid Nodev Noatime

Summarize:

1) here. Mount the partition that should mount to the/data folder to the/dat folder first

2) The next two lines of script will mount the virtual disks to/system and/data respectively.

3) Yes, so easy! , but when the function has not been realized, the kind from the brewing to the attempt, and then to the success of the process there is a turn, although the key virtual partition of the mount is in the case of half-hearted (while watching CCTV documentary, Haha, never learn).

9. Pack kernel and ramdisk into boot.img again

Change the good ramdisk, next to it to be packaged into boot.img again, here will use three commands: Mkbootfs,minigzip and mkbootimg. Mkbootfs Pack all the files in the RAMDisk into a cpio format file

Minigzip then compresses it, Mkbootimg generates boot.img from kernel and ramdisk.img, using the following example:

Mkbootfs RAMDisk | Minigzip > Ramdisk.img

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

10. Next, it's the last step. How do I install a second Android operating system?

The installation work is actually really easy, write boot.img to recovery partition, put System.disk. Data.disk copied to the/data partition.

Of course. It is also possible to put System.disk and data.disk on an external SD card. This involves changes to the RAMDisk

11. Finally. Summary of the full text bar:

The implementation of dual systems on mobile phones is no longer a new technology, after the use of virtual disk in the way of implementing dual systems. Later Baidu, see 11 wrote an article, is on the SD card partition to achieve dual system, operation is more troublesome,

Switch also to boot into one of the system through the brush boot partition to achieve system switching, not as this article directly brush recovery partition of the way to the convenience.

The two-system implementations in this paper are actually relatively simple:

1) Convert system.img through simg2img to a format that can be mounted directly via loop System.disk

2) Create data partition virtual Disk Data.disk

3) Change the startup-related script in boot.img, implement Mount Virtual disk, and package again

4) will be system.disk. Data.disk on the original data partition

5) Brush Another packaged boot.img to the recovery partition.

Are this the end or just the beginning?

Assuming that the network set-top box, above is enough, but we are on the phone to create a dual system, so there is still a way to go. Here are the questions to consider:

1) How to keep the synchronization problem of the communication record in the dual system

2) How to synchronize the data of frequently used tools in dual system, such as chat record and so on.

3) How to deal with the incompatibility of the Android system baseband with different version numbers.

4) How to deal with EFS partition in different version number of Android system incompatibility problem.

5) How to implement ANDROID+WP dual system

6) How to achieve the three systems, four systems?

7) ...

Finish

Android Dual System implementation