WO2023130946A1

WO2023130946A1 - Operating system upgrade method, electronic device, storage medium, and chip system

Info

Publication number: WO2023130946A1
Application number: PCT/CN2022/140016
Authority: WO
Inventors: 张赠辉; 王艳召; 陈超; 黄九林
Original assignee: 荣耀终端有限公司
Priority date: 2022-01-10
Filing date: 2022-12-19
Publication date: 2023-07-13
Also published as: EP4242835A1

Abstract

Embodiments of the present application relate to the technical field of computers, and provide an operating system upgrade method, an electronic device, a storage medium, and a chip system. Multiple sub-partitions in an operating system can be combined and upgraded to flexibly meet various upgrade requirements. The method comprises: acquiring a first upgrade installation package and a second upgrade installation package, the first upgrade installation package comprising first data, the first data comprising partition information of a first sub-partition, the second upgrade installation package comprising second data, and the second data comprising partition information of a second sub-partition; obtaining a plurality of third description groups according to third data and a plurality of second description groups, the third data comprising the partition information of the first sub-partition and the second sub-partition, and the plurality of third description groups comprising description groups respectively corresponding to the first sub-partition, the second sub-partition and a third sub-partition; and restarting an electronic device, reading values of address items in the plurality of third description groups, and loading data of dynamic partitions on the basis of the values of the address items in the plurality of third description groups.

Description

Operating system upgrade method, electronic equipment, storage medium and chip system

This application requires submission of a Chinese patent application with the State Intellectual Property Office on January 10, 2022, with the application number 202210023196.0, and the title of the invention is "Operating System Upgrade Method, Equipment, Storage Medium, and Computer Program Product", and requires filing on February 2022. The priority of a Chinese patent application filed with the State Intellectual Property Office on April 14, with the application number 202210135613.0, and the title of the invention is "operating system upgrade method, electronic equipment, storage medium and chip system", the entire contents of which are incorporated in this application by reference .

technical field

The present application relates to the field of computer technology, in particular to an operating system upgrade method, electronic equipment, storage media and a chip system.

Background technique

In terminal equipment such as mobile phones and notebook computers, the operating system is the most basic and most important basic system software. A terminal device can only be used by a user when an operating system is installed. Taking the terminal device as a mobile phone as an example, the mobile phone operating system needs to be installed on the mobile phone, such as the Apple mobile device operating system (iPhone Operation System, IOS), Android (Android) system, etc., before it can be used by the user.

Usually, the operating system is provided by the operating system provider (for example, the provider of Android system is Google). Moreover, the operating system provided by the operating system supplier is a basic operating system, which only includes the most basic functions, and cannot fully meet the application requirements of users. In order to meet the application needs of users and improve user experience, terminal equipment suppliers will optimize the basic operating system according to different customer needs and application scenarios, add customized content on the basis of the basic operating system, and build a customized operating system. After the customized operating system is installed on the terminal device, the terminal device can provide optimized system functions. Taking the mobile phone with the Android system installed as the terminal device as an example, before the mobile phone leaves the factory, the customer service system of the designated network operator is added to the Android system, so that after the mobile phone is turned on, the user can log in to the user account under the network operator to realize the calculation. Fee recharge and other functions.

After the customized operating system is installed on the terminal device, when a version upgrade occurs, the customized operating system installed on the terminal device needs to be upgraded. Moreover, in the customized operating system, a large number of upgrade requirements only need to upgrade the data in some storage areas in the customized operating system.

However, currently the OS upgrade solution is provided by the OS vendor. The upgrade solution provided by the operating system supplier is usually aimed at upgrading the entire operating system. If this upgrade plan is used for the upgrade requirements of the customized operating system, when the data in any part of the storage area in the customized operating system needs to be upgraded, the new version of the part that needs to be upgraded and the current version of the part that does not need to be upgraded After being combined into a new version, it is released as a combined upgrade package. Then, upgrade the entire customized operating system according to the combined upgrade package. In this way, as the upgrade demand of the customized operating system increases, a large number of large-version upgrade packages will be obtained, which is not conducive to flexible management of the customized operating system version by the terminal equipment supplier.

Contents of the invention

Embodiments of the present application provide an operating system upgrade method, electronic equipment, storage media, and a chip system, which can be combined and upgraded for multiple sub-partitions in the operating system to flexibly meet various upgrade requirements.

In a first aspect, the embodiment of the present application provides a method for upgrading an operating system, and the method can be applied to an electronic device. The electronic device includes a processor and a memory, the memory includes a basic partition, a first static partition, a second static partition, a dynamic partition and a user data partition, the dynamic partition includes first slot data and second slot data, and the dynamic partition includes multiple sub For a partition, the first slot data includes a plurality of first description groups corresponding to a plurality of sub-partitions, and the second slot data includes a plurality of second description groups corresponding to a plurality of sub-partitions. Loading the data of the basic partition, the first static partition and the dynamic partition to run the first operating system, during the process of loading the data of the dynamic partition, reading multiple first description groups, based on the address items in the multiple first description groups value to load data for dynamic partitions. Obtain the first upgrade installation package and the second upgrade installation package, the first upgrade installation package is used to upgrade the first sub-partition, the second upgrade installation package is used to upgrade the second sub-partition, the first sub-partition and the second sub-partition are dynamic The sub-partition of the partition, the first upgrade installation package includes first data (manifest), the first data includes partition information of the first sub-partition, the second upgrade installation package includes second data, and the second data includes the partition of the second sub-partition information. Multiple third description groups are obtained according to the third data and multiple second description groups, the third data includes the partition information of the first sub-partition and the partition information of the second sub-partition, and the multiple third description groups include information related to the first sub-partition. A description group corresponding to a sub-partition, a description group corresponding to a second sub-partition, and a description group corresponding to a third sub-partition, the third sub-partition is a dynamic partition other than the first sub-partition and the second sub-partition subpartition. Restart the electronic device, load the data of the basic partition, the second static partition and the dynamic partition to run the second operating system, and read the values of the address items in multiple third description groups during the process of loading the data of the dynamic partition, based on The values of the address items in the plurality of third description groups load the data of the dynamic partition.

To sum up, using the method of the embodiment of the present application, after obtaining multiple (for example, two) upgrade installation packages, the electronic device merges the manifests parsed from the multiple upgrade installation packages to obtain all the updates including dynamic partitions that need to be upgraded. The manifest of the subpartitions (such as the first subpartition and the second subpartition). Then, in the process of obtaining multiple third description groups based on the merged manifest, sub-partitions (such as the third sub-partition) not involved in the partition information of the manifest will not be included in the second slot data its deleted. In this way, the description group of the sub-partition not to be upgraded still remains in the second slot data, and when the second operating system is run subsequently, the data of the sub-partition not to be upgraded can be loaded according to the second slot data. In this way, there will be no incomplete loading, and finally the dynamic partition can be successfully loaded.

In a possible design of the first aspect, after obtaining the first upgrade installation package and the second upgrade installation package, the above further includes: writing a plurality of second description groups into the target file, and deleting them in the target file A description group corresponding to the third sub-partition generates a first index.

That is to say, when the electronic device creates the first index, it will delete the description group corresponding to the non-upgraded sub-partition in the multiple second description groups, so that the created first index can only indicate that the electronic device obtains the updated sub-partition. Upgrade data. Therefore, the electronic device can be accurately instructed to obtain the upgrade data.

In a possible design manner of the first aspect, the above-mentioned target files are located in the basic partition.

In a possible design of the first aspect, after loading the data of the basic partition, the first static partition and the dynamic partition, the above further includes: obtaining the third upgrade installation package, the third upgrade installation package is used to upgrade the fourth The sub-partition, the fourth sub-partition is a sub-partition of the dynamic partition, the third upgrade installation package includes third data, and the third data includes partition information of the fourth sub-partition. Multiple third description groups are obtained according to the third data and multiple second description groups. The third data also includes the partition information of the fourth sub-partition. Partition and subpartitions other than the fourth subpartition.

That is to say, using the method of this embodiment, it is also possible to use three upgrade installation packages to upgrade more sub-partitions. It should be understood that four upgrade installation packages, five upgrade installation packages, etc. can also be used to flexibly meet various combined upgrade requirements. This embodiment of the present application does not specifically limit it.

In a possible design of the first aspect, the first upgrade installation package includes first upgrade data, the first upgrade data is used to upgrade the first sub-partition, the second upgrade installation package includes second upgrade data, and the second upgrade The data is used to upgrade the second child partition. The above method further includes: saving the first upgrade data and the second upgrade data in the user data partition. During the process of loading the data of the dynamic partition, the target file is read, and the first upgrade data and the second upgrade data in the user data partition are loaded based on the first index in the target file.

That is to say, using the method of this embodiment, in the scenario where multiple upgrade installation packages are combined and upgraded, the electronic device implements writing the upgrade data in each upgrade installation package into the in the user data partition. Rather than just saving data for one upgrade installation package, omissions can be avoided and complete upgrades of various combinations can be realized. Then, when loading the dynamic partition, it is necessary to obtain all the upgrade data from the user data partition, so as to realize the full loading of the dynamic partition.

In a possible design of the first aspect, the above-mentioned deletion of the description group corresponding to the second sub-partition in the target file and generating the first index includes: deleting the description group corresponding to the third sub-partition in the target file , get the description group corresponding to the first sub-partition and the description group corresponding to the second sub-partition, the description group corresponding to the first sub-partition includes the name of the first sub-partition, and the description group corresponding to the second sub-partition includes The name of the second subpartition. The first file name corresponding to the first sub-partition is generated based on the name of the first sub-partition, and the second file name corresponding to the second sub-partition is generated based on the name of the second sub-partition. The first index includes the first file name and the second file name.

That is to say, by using the method of this embodiment, the electronic device can generate the first index including the first file name and the second file name, so as to accurately indicate the file where the electronic device needs to find the upgrade data when loading the dynamic partition.

In another possible design of the first aspect, the first file name corresponding to the first sub-partition is generated based on the name of the first sub-partition, and the file name corresponding to the second sub-partition is generated based on the name of the second sub-partition. After the second file name, it also includes: creating a first initial cow file with the first file name in the user data partition, and creating a second initial cow file with the second file name, the first initial cow No upgrade data is stored in the file and the second initial cow file. The aforementioned saving of the first upgrade data and the second upgrade data in the user data partition includes: saving the first upgrade data in the first initial cow file, and saving the second upgrade data in the second initial cow file.

That is to say, by using the method of this embodiment, the electronic device can create an initial cow file in the user data partition that is consistent with the file name in the first index, and save the upgrade data in the initial cow file. Subsequently, when the electronic device reads the upgrade data, it can accurately obtain the upgrade data by retrieving the file name.

In another possible design of the first aspect, the second static partition includes a plurality of sub-partitions, the first upgrade installation package further includes third upgrade data, the third upgrade data is used to upgrade the fifth sub-partition, and the second The upgrade installation package also includes fourth upgrade data, the fourth upgrade data is used to upgrade the sixth sub-partition, and the fifth sub-partition and the sixth sub-partition are sub-partitions of the second static partition. After obtaining the first upgrade installation package and the second upgrade installation package, the above method further includes: writing the third upgrade data into the fifth sub-partition, and writing the fourth upgrade data into the sixth sub-partition.

That is to say, by using the method of this embodiment, the electronic device can upgrade the dynamic partition and some sub-partitions of the static partition. In order to flexibly meet the needs of various partial upgrades.

In another possible design manner of the first aspect, the first static partition includes multiple sub-partitions, and the multiple sub-partitions of the first static partition correspond one-to-one to the multiple sub-partitions of the second static partition. Before writing the third upgrade data into the fifth sub-partition and writing the fourth upgrade data into the sixth sub-partition, the method further includes: if the second static partition includes the seventh sub-partition, detecting the fifth sub-partition and the sixth sub-partition Whether the partition includes a preset sub-partition, and the seventh sub-partition is a sub-partition other than the fifth sub-partition and the sixth sub-partition in the second static partition. If the fifth sub-partition and the sixth sub-partition include the preset sub-partition, the data of the seventh sub-partition of the first static partition is synchronized to the seventh sub-partition of the second static partition.

That is to say, when the data that needs to be upgraded this time is a large amount of data, the electronic device can only synchronize the data of the sub-partition (ie, the seventh sub-partition) that does not need to be upgraded in the first static partition to the second static partition, so as to It is ensured that the data of the sub-partition that does not need to be upgraded (that is, the seventh sub-partition) in the second static partition is up-to-date. Therefore, the synchronization of sub-partition data that does not need to be upgraded currently can be realized through the synchronization of a small part of data.

If the fifth sub-partition and the sixth sub-partition do not include the preset sub-partition, the data of all sub-partitions in the first static partition are synchronized to the corresponding sub-partitions of the second static partition.

In this way, when most of the data does not need to be updated, the device does not need to remove data that does not need to be synchronized from the first static partition, but can simplify the steps of synchronization by synchronizing all.

That is to say, using the method of this embodiment, before updating the data in the second static partition, the latest data of sub-partitions that do not need to be upgraded can be synchronized between the first static partition and the second static partition. Then perform data update on the second static partition. In this way, it can be guaranteed that the data of each sub-partition in the second static partition is up-to-date.

In another possible design of the first aspect, writing the third upgrade data into the fifth sub-partition and writing the fourth upgrade data into the sixth sub-partition includes: if the second static partition does not include the seventh For the sub-partition, the third upgrade data is written into the fifth sub-partition, and the fourth upgrade data is written into the sixth sub-partition. That is to say, with the method of this embodiment, if all the data in the static partition needs to be updated, the data can be updated directly without synchronization. Thereby, the operation of system upgrade can be saved.

In another possible design of the first aspect, the above-mentioned storing the first upgrade data and the second upgrade data in the user data partition includes: traversing the first upgrade installation package and the second upgrade installation package, traversing to the first When upgrading the installation package, save the first upgrade data in the user data partition, and save the second upgrade data in the user data partition when traversing to the second upgrade installation package. The above method further includes: recording the progress of saving the upgrade data included in the currently traversed upgrade installation package, and recording the traverse sequence number of the currently traversed upgrade installation package. Calculate the update progress corresponding to the save progress and the traversal sequence number, and display the update progress.

That is to say, by using the method of this embodiment, the electronic device can calculate and display the real-time update progress by recording the saving progress and the traversal sequence number.

In another possible design of the first aspect, the above process of saving the first upgrade data and the second upgrade data in the user data partition further includes: if the electronic device is powered off and restarted, the first upgrade installation package Locating the target upgrade installation package corresponding to the traversal sequence number in the second upgrade installation package, and locating the target data corresponding to the write progress in the upgrade data of the target upgrade installation package. Starting from the target data of the target upgrade installation package, the first upgrade data and the second upgrade data are continuously stored in the user data partition.

That is to say, by adopting the method of this embodiment, the electronic device can continue to save the data accurately from the position where it was updated when the power was turned off, for the abnormal situation of restarting after power failure during the data updating process.

In another possible design of the first aspect, before obtaining the multiple third description groups according to the third data and the multiple second description groups, it further includes: combining the first data and the second data to obtain the third data.

That is to say, by adopting the method of this embodiment, a manifest including partition information of all sub-partitions to be upgraded in a dynamic partition can be obtained by merging manifests in multiple upgrade installation packages. This facilitates subsequent upgrades based on the merged manifest.

In another possible design of the first aspect, after loading the data of the basic partition, the second static partition, and the dynamic partition, the above further includes: storing multiple first upgrade data and second upgrade data in the user data partition The data is moved to the corresponding subpartition of the dynamic partition.

That is to say, by adopting the method of this embodiment, the file of the dynamic partition can be upgraded through the disk operation, so that the device does not need to load the dynamic partition and the virtual dynamic partition when the device is started next time, and only needs to load the dynamic partition to complete the device. start up.

In another possible design manner of the first aspect, the first sub-partition, the second sub-partition, the third sub-partition, ... may all include one or more sub-partitions. In this way, combined upgrades of various sub-partitions can be flexibly realized.

In the second aspect, the embodiment of the present application further provides an electronic device, the electronic device includes a processor and a memory, and the memory includes a basic partition, a first static partition, a second static partition, a dynamic partition, and a user data partition. The dynamic partition includes a plurality of sub-partitions, and the processor is configured to execute software codes stored in the memory, so that the electronic device executes the method of the above-mentioned first aspect and any possible design manner thereof.

In a third aspect, an embodiment of the present application provides a chip system, which is applied to an electronic device including a display screen and a memory; the chip system includes one or more interface circuits and one or more processors; the interface The circuit and the processor are interconnected by a line; the interface circuit is configured to receive a signal from a memory of the electronic device and send the signal to the processor, the signal including computer instructions stored in the memory; When the processor executes the computer instruction, the electronic device executes the method described in the first aspect and any possible design manner thereof.

In the fourth aspect, the embodiment of the present application further provides a computer storage medium, the computer storage medium includes computer instructions, and when the computer instructions are run on the electronic device, the electronic device is executed as described in the first aspect and any possibility thereof. The method described in the design method.

In a fifth aspect, the present application provides a computer program product. When the computer program product runs on a computer, the computer executes the method described in the first aspect and any possible design manner thereof.

It can be understood that the beneficial effects that can be achieved by the electronic device described in the second aspect, the chip system described in the third aspect, the computer storage medium described in the fourth aspect, and the computer program product described in the fifth aspect provided above , reference may be made to the beneficial effects of the first aspect and any possible design manner thereof, and details are not repeated here.

Description of drawings

In order to more clearly illustrate the technical solutions of the embodiments of the present application, the following will briefly introduce the accompanying drawings that need to be used in the embodiments. Obviously, the accompanying drawings in the following description are only some embodiments of the present application. Those of ordinary skill in the art can also obtain other drawings based on these drawings without paying creative labor.

FIG. 1 is a schematic diagram of a data storage structure according to an embodiment of the present application;

FIG. 2 is a flowchart of an operating system upgrade according to an embodiment of the present application;

FIG. 3 is a schematic diagram of a data storage structure according to an embodiment of the present application;

FIG. 4 is a schematic diagram of part of card slot data according to an embodiment of the present application;

FIG. 5A is a flow chart showing an operating system upgrade according to an embodiment of the present application;

FIG. 5B is a schematic diagram of adjusting card slot data according to an embodiment of the present application;

FIG. 6 is a schematic diagram of a data storage structure according to an embodiment of the present application;

FIG. 7 is a schematic diagram of component division in a data storage structure according to an embodiment of the present application;

FIG. 8 is a schematic diagram of upgrading an independent component according to an embodiment of the present application;

FIG. 9 is a flowchart of an operating system upgrade according to an embodiment of the present application;

FIG. 10 is a schematic diagram of the merging process of manifests according to an embodiment of the present application;

FIG. 11 is a schematic diagram of adjusting card slot data according to an embodiment of the present application;

FIG. 12 is a flow chart showing an operating system upgrade according to an embodiment of the present application;

FIG. 13 is a schematic diagram of creating an index according to an embodiment of the present application;

FIG. 14 is a flow chart showing an operating system upgrade according to an embodiment of the present application;

FIG. 15 is a schematic diagram of data update according to an embodiment of the present application;

FIG. 16 is a flow chart showing an operating system upgrade according to an embodiment of the present application;

FIG. 17 is a flowchart of an operating system upgrade according to an embodiment of the present application;

FIG. 18 is a schematic diagram of data update after power failure according to an embodiment of the present application;

FIG. 19 is a flow chart showing an operating system upgrade according to an embodiment of the present application;

FIG. 20 is a schematic structural diagram of a chip system according to an embodiment of the present application.

Detailed ways

It should be clear that the embodiments described herein are only some of the embodiments of the application, not all of the embodiments. Based on the embodiments in this application, all other embodiments obtained by persons of ordinary skill in the art without creative efforts fall within the protection scope of this application.

In order to better understand the technical solutions of the present application, the embodiments of the present application will be described in detail below in conjunction with the accompanying drawings.

Before the terminal device (referred to as the device) leaves the factory, the operating system is burned into the device, so as to realize the installation of the operating system before the device leaves the factory. Thereafter, in order to improve user experience, it may be necessary to upgrade the operating system in the device. At this point, an Over-the-Air Technology (OTA) can be used to complete the upgrade. Among them, OTA is a technology for remotely updating the operating system of the device through the wireless network interface of the device, so as to realize the purpose of remotely upgrading the operating system in the device.

It should be noted that the devices in this embodiment of the present application include, but are not limited to, smart phones, smart earphones, tablet computers, smart refrigerators, smart speakers, etc. on which an operating system can be installed. The device may also be a control panel on which an operating system can be installed inside the device. Exemplary embodiments of operating systems include, but are not limited to

Linux or other operating systems.

When using OTA to upgrade the operating system, in order to perform non-perceived upgrades when the device is running normally and improve the utilization of data storage space, a virtual A/B upgrade solution can be used to complete the upgrade of the operating system.

Taking the Android system as an example, the virtual A/B upgrade solution can be applied to the upgrade of the operating system with the data storage structure shown in FIG. 1 . As shown in Figure 1, the Android system data storage area includes a basic partition (Common), a static partition (A), a static partition (B), a dynamic partition (Super), and a user data partition (Userdata). Each partition is introduced as follows: the user data partition (Userdata) is used to save the user's personal data, for example, the APP installed by the user personally, the pictures, documents and videos saved by the user personally, and other personal data. The basic partition (Common) is used to save system data, and the data saved in the basic partition does not participate in the operating system upgrade. The structure of the static partition (A) and the static partition (B) correspond to each other. The static partition (A) and the static partition (B) can include multiple sub-partitions. The sub-partitions corresponding to the static partition (A) and the static partition (B) are named by The suffixes _a and _b distinguish each other. For example, static partition (A) includes bootloader_a, boot_a, vendor_boot_a, dtbo_a, vbmeta_a; static partition (B) includes bootloader_b, boot_b, vendor_boot_b, dtbo_b, vbmeta_b. A dynamic partition (Super) can contain multiple subpartitions, such as System, system_ext, vendor, product, Cust, Odm. For convenience of description, the static partition (A) may be called the first static partition, and the static partition (B) may be called the second static partition.

When the device is started, it starts from a static partition, that is, the operating system is started by loading the static partition. For example, if the device starts from the static partition (A), it needs to load the basic partition (Common), static partition (A) and dynamic partition (Super) in sequence; when the device starts from the static partition (B), it needs to load the basic partition (Common ), static partition (B) and dynamic partition (Super).

Take Universal Flash Storage (UFS) in Master Boot Record (MBR) format as an example. In the MBR of UFS (master boot sector, the first sector of UFS, that is, the 0 cylinder 0 head 1 sector of the C/H/S address), the device startup sequence description is stored. The device boot sequence description can be used to indicate booting from the static partition (A) (the boot sequence mark is A) or from the static partition (B) (the boot sequence mark is A). After the device is started, first read the device boot sequence description from the MBR of the UFS, so as to determine whether to start from the static partition (A) or the static partition (B) according to the device startup sequence description. MBR is usually recorded in the base partition (Common). Certainly, on different platforms, the MBR may also be recorded in different locations, which is not specifically limited in this embodiment of the present application.

Figure 2 is a flow chart of upgrading the operating system for the operating system with the data storage structure shown in Figure 1, assuming that the device is currently booted from the static partition (A), and the device is upgraded according to the virtual A/B shown in Figure 2 The process of the program implements the upgrade of the operating system.

S200, the device loads the basic partition (Common), the static partition (A) and the dynamic partition (Super) in sequence, and starts from the static partition (A).

S210, the device acquires an operating system upgrade installation package.

Exemplarily, in a feasible implementation solution, the device periodically initiates a packet search request to the packet search server, and the packet search request includes the version number (for example, version 1.1) of the operating system currently running on the device. The package search server retrieves whether there is an operating system installation package with a newer version number (for example, an operating system installation package of version 1.2) according to the version number of the operating system in the package search request. When there is a newer version of the operating system installation package, the package search server feeds back the download address of the operating system upgrade installation package (for example, the system incremental upgrade installation package upgraded from version 1.1 to version 1.2) to the device. The device downloads the OS upgrade installation package according to the download address of the OS upgrade installation package.

S220. The device performs a data writing operation on the static partition (B) according to the operating system upgrade installation package to upgrade the static partition (B).

For example, the system incremental upgrade installation package from version 1.1 to version 1.2 contains the full data of the static partition of version 1.2, and the device overwrites the data of the static partition of version 1.2 into the static partition (B).

S230. The device creates a virtual dynamic partition in the user data partition (Userdata) according to the operating system upgrade installation package, and writes upgrade data of the dynamic partition (Super) in the virtual dynamic partition.

For example, the operating system upgrade installation package contains the data of the dynamic partition (Super) of version 1.2, and the device writes the data of the dynamic partition (Super) of version 1.2 in the virtual dynamic partition.

Further, in the virtual A/B upgrade solution, an incremental upgrade method is adopted for the dynamic partition (Super). During the upgrade process, the virtual dynamic partition of the user data partition (Userdata) does not save all the files of the new version of the dynamic partition (Super) after the upgrade, but the data that needs to be upgraded in the old version of the dynamic partition (Super). The result of the upgrade after the upgrade.

Taking the System subpartition as an example, assume that in version 1.1, the data in the System subpartition can be divided into data system1 and data system2. From version 1.1 to version 1.2, the data system2 has not changed, and the data syetem1 has been upgraded to the data system3. Then, in S230, the device creates a virtual dynamic partition in the user data partition (Userdata), and writes data system3 in the virtual dynamic partition. For example, the system incremental upgrade installation package from version 1.1 to version 1.2 includes dynamic partition (Super) update data from version 1.1 to version 1.2, and the dynamic partition (Super) update data includes data system3.

Further, in the virtual A/B upgrade scheme, the incremental upgrade of the dynamic partition (Super) is realized based on the snapshot technology (snapshot). Specifically, in the virtual dynamic partition of the user data partition (Userdata), a copy-on-write (Copy-On-Write, cow) file is used to save the upgrade data of the dynamic partition (Super).

Specifically, the upgrade data of the dynamic partition (Super) stored in the user data partition (Userdata) includes multiple cow files, and each cow file corresponds to a sub-partition of the dynamic partition (Super). In the operating system upgrade installation package, the cow file of the upgrade data of the dynamic partition (Super) is compressed and stored in the form of binary code, and each cow file is named according to the sub-partition of the corresponding dynamic partition (Super). For example, the cow file for the system subpartition is named system-cow-img.img.0000.

Further, the device obtains the operating system upgrade installation package, unpacks the operating system upgrade installation package to obtain all cow files, and appends an A/B partition mark to each cow file. And further, create an Update folder in the user data partition (Userdata), and save the cow file to the Update folder.

For example, when the device is currently started from the static partition (A), it can be understood that the dynamic partition (Super) loaded by the operating system currently running on the device is the dynamic partition (A). When upgrading the operating system, the virtual dynamic partition created in the user data partition (Userdata) is for the dynamic partition (B). Therefore, in S230, the device obtains the operating system upgrade installation package, unpacks the operating system upgrade installation package to obtain all cow files, and attaches the name mark _b corresponding to the dynamic partition (B) to the cow files. For example, append_b for system-cow-img.img.0000 generates system_b-cow-img.img.0000. Further, an Update folder is created in the user data partition (Userdata), and the cow file is saved in the Update folder. For example, in an application scenario, after writing a cow file to the user data partition (Userdata), the Update folder of the user data partition (Userdata) contains the following files:

system_b-cow-img.img.0000;

system_ext_b-cow-img.img.0000;

vendor_b-cow-img.img.0000;

product_b-cow-img.img.0000;

cust_b-cow-img.img.0000;

odm_b-cow-img.img.0000.

Specifically, the cow file includes a cow file map (snapshot map) of the cow file itself and upgrade data.

The cow file map (snapshot) corresponds to the file map of the subpartition of the dynamic partition (Super) targeted by the cow file. The file map of the sub-partition of the dynamic partition (Super) is used to describe all the files in the sub-partition of the dynamic partition (Super) and the storage address of each file in the current version of the operating system (the version before this upgrade, for example, version 1.1) .

The upgrade data in the cow file is the updated data in the sub-partition data of the new version compared with the sub-partition data of the current version; the cow file map of the cow file itself is used to describe the updated file and the sub-partition of the current version The correspondence between the files in and the storage address of the updated files.

Based on the file map of the sub-partition of the dynamic partition (Super) and the cow file map in the cow file, the upgrade data in the cow file can be used to replace the corresponding files in the sub-partition of the dynamic partition (Super), so as to realize the dynamic partition (Super) ) data upgrade. Specifically, when the file map of the sub-partition of the dynamic partition (Super) needs to be obtained, a snapshot operation may be performed on the data of the sub-partition of the dynamic partition (Super) based on the snapshot to generate the file map of the sub-partition of the dynamic partition (Super). It is also possible to pre-generate the file map of the sub-partition of the dynamic partition (Super) when making the operating system upgrade installation package, and add the file map to the cow file.

Further, in S230, after the cow file is written into the user data partition (Userdata), it is also necessary to perform an overall check on the dynamic partition (Super)+cow file to verify the validity of the dynamic partition (Super)+cow file , to verify whether the synthesis result of the current version of the dynamic partition (Super) data+cow file is the new version of the dynamic partition (Super) data. If it is valid, change the merge status information in the metadata partition (/metadata) of the basic partition (Common) from "merged" to "wait for merge". The flush status information is used to indicate whether there are currently cow files that need to be flushed to the dynamic partition (Super). Specifically, the disk placement status information includes an overall identifier for the dynamic partition (Super) and a sub-partition identifier for each sub-partition. When the overall flag is "merged", it means that all sub-partitions of the dynamic partition (Super) do not need to be merged; when the overall flag is "not merged (wait for merge)", it means dynamic One or more sub-partitions of a partition (Super) need to be merged; when the sub-partition is marked as "merged", it means that the sub-partition does not need to be merged; when the sub-partition is marked as "merged Disk (wait for merge)" means that the sub-partition needs to be moved to disk. If it is invalid, the upgrade will fail, the upgrade process will be interrupted and an error will be reported.

S231. Change the boot sequence of the device from booting from the static partition (A) to booting from the static partition (B).

For example, rewrite the boot sequence identifier of the Master Boot Record (MBR), and rewrite the boot sequence identifier from A to B. After the device is powered on, when the device reads the boot sequence ID as A, the device starts from the static partition (A), and loads the static partition (A) during startup; when the device reads the boot sequence ID as B, the device starts from the static partition (A). Partition (B) starts, and static partition (B) is loaded during startup.

S232, restarting the device. Exit the current operating system, cut off the power of the device, and turn on the power of the device again.

S240, the device sequentially loads the basic partition (Common) and the static partition (B).

S241. The device loads the dynamic partition (Super) and the virtual dynamic partition of the user data partition (Userdata).

Specifically, the device reads the storage status information in the metadata (/metadata), determines whether to retrieve the cow file from the specified path of the user data partition (Userdata) based on the storage status information, and uses snapshot to merge and load the dynamic partition ( Super) and the cow file retrieved from the specified path of the user data partition (Userdata).

Further, in S241, the device does not load all the cow files in the dynamic partition (Super) and the user data partition (Userdata), but loads corresponding files according to operating requirements of the operating system. Specifically, in S241, the device determines the files to be loaded according to the operation requirements of the operating system, and extracts the corresponding files from the cow files in the virtual dynamic partition of the dynamic partition (Super) or user data partition (Userdata) based on the snapshot to load.

Further, in S241, before loading the file, the device needs to verify the loaded file. Different from S230, in S241, the dynamic partition (Super)+cow file is not verified as a whole, but only the files to be loaded are verified. For example, verify based on dmverity (dm-verity is a target of dm (device mapper), which is a virtual block device, specially used for file system verification). If the verification is successful, load the file; if the verification fails, restart the device, roll back the system or try to load the file again.

S250, the device is successfully started and enters the user interaction interface.

S251. The device puts the data of the virtual dynamic partition to the dynamic partition (Super).

In the description of this application specification, the disk operation refers to writing the dynamic partition (Super) upgrade file (cow file) stored in the virtual dynamic partition on the user data partition (Userdata) to the In the dynamic partition (Super), the files of the dynamic partition (Super) are upgraded, so that the device does not need to load the dynamic partition (Super) and the virtual dynamic partition at the next startup, and only needs to load the dynamic partition (Super) to complete the device. start up.

Specifically, after the device is successfully started, it performs a power-on broadcast, and starts an upgrade process after the power-on broadcast. The upgrade process reads the migration status information in the metadata (/metadata) of the basic partition (Common). If the migration status information is "merged", the device enters the normal operation mode.

If the transfer status information is "wait for merge", the upgrade process transfers the cow files in the user data partition (Userdata) to the dynamic partition (Super).

Specifically, the upgrade process writes the upgrade data in the cow file in the user data partition (Userdata) to the corresponding address in the dynamic partition (Super), so that all the data in the dynamic partition (Super) are updated new Version data.

For example, based on /system/app/A2.XXX: 024018-024020 in the file map of the system subpartition and /system/app/A2.XXX: 045033-045035 in the cow file map, the data at addresses 045033-045035 Write to address 024014~024017; based on /system/user/C2.XXX: 024036~024040 in the file map of the system subpartition and /system/user/C2.XXX: 045036~045040 in the cow file map, the Data at addresses 045036 to 045040 are written to addresses 024036 to 024040.

After that, the upgrade process deletes the cow file in the user data partition (Userdata), and returns the storage space to the user data partition (Userdata); and, the disk status information in the metadata (/metadata) of the basic partition (Common) Changed from "wait for merge" to "merged".

Based on Figure 2, it can be seen that in S220, the data in a static partition is independently upgraded at the granularity of the static partition, and the upgrades between static partitions do not affect each other. For example, for the operating system data in the static partition (B) upgrade, it will not affect the operating system data of the currently started static partition (A). Moreover, in S230, the data operation of the dynamic partition upgrade is completed on the virtual dynamic partition created in the user data partition (Userdata), which will not affect the currently mounted dynamic partition (Super). Therefore, during the whole process of upgrading the operating system, the user can use the device normally, such as using data in the dynamic partition. Moreover, after S231 is completed, the device does not need to be restarted immediately, and the user can choose the restarting time; in this way, the upgrade process of the operating system will not affect the user's normal mobile phone operation, thereby greatly improving the user experience. Further, for the dynamic partition (Super), a virtual dynamic partition will be created on the user data partition (Userdata) only when an upgrade is required, thus effectively improving the utilization rate of data storage space.

Further, FIG. 3 is a schematic diagram of a data storage structure according to an embodiment of the present application. As shown in FIG. 3 , the metadata (/supermetadata) of the header of the dynamic partition (Super) includes Slot0 corresponding to the static partition (A) and Slot1 of the static partition (B). Slot0 and Slot1 are used to save the partition table of the Super partition. For the convenience of explanation, Slot0 corresponding to the static partition (A) can be called the first slot, the data in Slot0 is called the first slot data, and Slot1 corresponding to the static partition (B) is called the second slot, and Slot1 The data in is called the second slot data.

For example, in the MBR of UFS, in the device boot sequence description, configuring Slot0 corresponds to booting from the static partition (A), and configuring Slot1 corresponds to booting from the static partition (B). When the device is started, it selects to obtain the partition information of the Super partition from Slot0 or Slot1 according to the static partition to be started. Take the device currently booting from the static partition (A) as an example. When loading the dynamic partition (Super), the device first reads Slot0 to obtain the sub-partition address of the dynamic partition (Super); when the device starts from the static partition B, in When loading the Super partition, the device first reads Slot1 to obtain the sub-partition address of the dynamic partition (Super).

Specifically, Slot0 and Slot1 include multiple sub-partition description groups, and one sub-partition description group corresponds to one sub-partition of the Super partition. That is to say, Slot0 includes multiple description groups corresponding to multiple subpartitions, and Slot1 also includes multiple description groups corresponding to multiple subpartitions. For convenience of description, the multiple sub-partition description groups in Slot0 may be referred to as multiple first description groups, and the multiple sub-partition description groups in Slot1 may be referred to as multiple second description groups.

The sub-partition description group includes: at least one of a name (Name), a group (Group), an attribute (Attributes), and an address (Extents). The following describes the items contained in the sub-partition description group:

Name (Name), its value is the name of the sub-partition, for example, system_b;

Group (Group) item, whose value is the subpartition type, for example, subpartition (ry_dynamic_partitions_b);

Attributes item, its value is the read-write attribute of the sub-partition, for example, the read-only attribute (readonly);

Address (Extents), its value is the address of the sub-partition, for example, 0..6995967linear super 2048.

In the Name item and the Group item, if the suffix of the value is _a, it corresponds to the static partition (A); if the suffix of the value is _b, it corresponds to the static partition (B).

When starting from static partition A and loading the Super partition, Slot0 is first read. When reading Slot0, since the suffix _a corresponds to the static partition (A), the device reads the value of the Extents item in the sub-partition description group whose Name item and/or Group item suffix _a in Slot0 to obtain the dynamic partition ( Super) sub-partition address.

When booting from static partition B and loading the Super partition, Slot1 is first read. When reading Slot1, since the suffix _b corresponds to the static partition (B), the device reads the value of the Extents item in the partition description group with the suffix _b in the Name item and/or Group item in Slot0 to obtain the dynamic partition (Super ) subpartition address.

Generally, after the system is burned before the device leaves the factory, in the initial Slot0 and Slot1, there are two sub-partition description groups for each sub-partition of the Super partition, one sub-partition description group corresponds to the static partition (A), and one sub-partition Description groups correspond to static partitions (B). When reading Slot0 or Slot1, the device selects the sub-partition description group to be read according to the suffix (_a or _b).

That is, in Slot0 and Slot1, for each sub-partition of the Super partition, there are two sub-partition description groups (for example, the first description group and the second description group). The values of the Name item and the Group item of two sub-partition description groups for the same sub-partition have the same prefix and different suffixes (_a and _b respectively). Values of address items of two sub-partition description groups for the same sub-partition may be different.

FIG. 4 shows part of the data stored in the initial Slot0 in an embodiment. As shown in FIG. 4 , in the sub-partition description group with the suffix _a in the value of the Name item and the Group item, the value of the Extents item is the real address of the sub-partition. In the partition description group with the suffix of _b in the value of the Name item and the Group item, the value of the Extents item is blank. When starting from static partition A and loading the Super partition, Slot0 is first read. When reading Slot0, since the suffix _a corresponds to the static partition (A), the device reads the value of the Extents item in the sub-partition description group whose Name item and/or Group item suffix _a in Slot0 to obtain the super partition The address of the sub-partition, so that the super partition can be loaded smoothly.

When reading Slot0, since the suffix _b corresponds to the static partition (B), the device does not need to read the sub-partition description group whose Name item and/or Group item suffix _b in Slot0, therefore, the values of the Name item and the Group item In the description group of subpartitions whose suffix is _b, setting the value of Extents to blank will not affect the loading of super partitions.

Further, in some embodiments, the data stored in the initial Slot1 is similar to the data structure shown in Figure 4, the difference is that, in order to ensure the smooth loading of the Super partition, in the data of Slot1, the suffix of the value of the Name item and the Group item In the sub-partition description group of _b, the value of the Extents item is the real address of the sub-partition. In the sub-partition description group with the suffix _a in the value of the Name item and the Group item, the value of the Extents item is blank.

It can be seen that when the system is upgraded, the device needs to update the sub-partition description group in slot0 or slot1 in time. In this way, the device can read the correct description of the sub-partitions, such as the Extents item, when switching to the static partition that starts up subsequently, so as to successfully load the dynamic partition (Super) partition.

Moreover, when loading the dynamic partition (Super) (as in S241), it is necessary to read the cow file from the virtual dynamic partition of the user data partition (Userdata). In order to accurately read the cow file from the user data partition (Userdata), the device can also create an index of the cow file in the basic partition (Common). The index of the cow file is used to instruct the device to read the cow file from the user data partition (Userdata). Then, when the device loads the dynamic partition (Super), it can read the corresponding cow file from the user data partition (Userdata) according to the index.

The flow of the virtual A/B upgrade solution will be described below on the basis of FIG. 3 , combined with the update of slot1 and the creation of the index of the cow file. Specifically, when the device is currently booted from the static partition (A), the device implements an operating system upgrade according to the process shown in FIG. 5A .

S200, the device sequentially loads the basic partition (Common), the static partition (A) and the dynamic partition (Super), and starts from the static partition (A).

S210. The device acquires an operating system upgrade installation package.

S510. The device parses the operating system upgrade installation package to obtain application manifest data (manifest).

In the operating system upgrade installation package, the mainfest records the partition information of the static partition (referred to as the static partition information) and the partition information of the dynamic partition (referred to as the dynamic partition information) in the data storage structure of the updated operating system (such as version 1.2). . Among them, the static partition information includes the name and size of each sub-partition in the static partition, the check value (such as hash value) of the upgraded data, and the upgrade data (difference or full mirror data) in the operating system upgrade installation package. Location. The dynamic partition information includes the name and size of each sub-partition in the dynamic partition, the check value (such as hash value) of the upgraded data, and the location of the upgraded data (differential or full mirrored data) in the operating system upgrade installation package.

Exemplarily, the dynamic partition of the updated operating system includes the following six subpartitions: system, system_ext, vendor, product, cust and odm. Correspondingly, the manifest includes the following dynamic partition information:

The name and size of the system partition, the verification value (such as hash value) of the upgraded data, and the location of the upgraded data in the operating system upgrade installation package;

The name and size of the system_ext partition, the check value (such as hash value) of the upgraded data, and the location of the upgraded data in the operating system upgrade installation package;

The name and size of the vendor partition, the check value (such as hash value) of the upgraded data, and the location of the upgraded data in the operating system upgrade installation package;

The name and size of the product partition, the verification value (such as hash value) of the upgraded data, and the location of the upgraded data in the operating system upgrade installation package;

The name and size of the cust partition, the check value (such as hash value) of the upgraded data, and the location of the upgraded data in the operating system upgrade installation package;

The name and size of the odm partition, the check value (such as the hash value) of the upgraded data, and the location of the upgraded data in the operating system upgrade installation package.

Further, if the number of sub-partitions included in the dynamic partition in the data storage structure of the updated operating system is reduced compared with the current operating system, the sub-partitions involved in the dynamic partition information in the manifest will not be included in the current operating system. All subpartitions in the dynamic partition.

Exemplarily, in the data storage structure of the current operating system, the dynamic partition (Super) includes 6 sub-partitions of system, system_ext, vendor, product, cust, and odm, and in the data storage structure of the upgraded operating system, the dynamic partition (Super) includes 4 sub-partitions including system, product, cust, and odm. Correspondingly, the manifest includes the following dynamic partition information:

Obviously, the dynamic partition information included in the manifest does not involve the system_ext and vendor partitions.

S520. The device adjusts the sub-partition description group of slot1 in the dynamic partition (Super) according to the dynamic partition information in the manifest, and obtains the adjusted slot1. Wherein, the sub-partitions involved in the sub-partition description group in the adjusted slot1 are in one-to-one correspondence with the sub-partitions involved in the dynamic partition information in the manifest.

Specifically, the device adjusts the address (Extents) item of the corresponding subpartition in slot1 according to the name and size of the subpartition, so that the adjusted address (Extents) item of each subpartition in slot1 matches the size of the corresponding subpartition. And, the device deletes the subpartition description group of the subpartition not involved in the dynamic partition information of the manifest from slot1. That is, the sub-partitions involved in the updated sub-partition description group of slot1 are in one-to-one correspondence with the sub-partitions involved in the dynamic partition information in the manifest.

Take the partition size of each sub-partition not changed, and the slot1 before adjustment is the initial slot1 shown in (a) in Figure 5B as an example, the initial slot1 includes system, system_ext, product, vendor, cust, odm There are 6 sub-partition description groups in total, and each sub-partition includes two sub-partition description groups, one sub-partition description group corresponds to the static partition (A), and one sub-partition description group corresponds to the static partition (B). The manifest parsed from the operating system upgrade package this time includes the dynamic partition information of 4 subpartitions including system, product, cust and odm. After adjustment, slot1 as shown in (b) in Figure 5B can be obtained. Compared with the slot1 before adjustment, the sub-partition description groups of system_ext and vendor partitions are deleted in slot1 after adjustment, and only the sub-partition description groups of four sub-partitions including system, product, cust, and odm are included.

Further, if the slot1 before the adjustment is the initial slot1 (as shown in (a) in Figure 5B), compared with the slot1 before the adjustment, the adjusted slot1 only retains the sub-partition corresponding to the static partition (B) The description group, that is, the sub-partition description group with the suffix _b, and the sub-partition description group corresponding to the static partition (A), that is, the sub-partition description group with the suffix _a is deleted.

S530. The device records the index of the cow file in the basic partition (Common) according to the adjusted slot1.

Wherein, the index of the cow file can instruct the device to search the corresponding cow file from the user data partition (Userdata) to complete the loading of the dynamic partition (Super).

The device copies the updated sub-partition description group in slot1 to the basic partition (Common), such as the /gsi/ota/lp_metadata file under the metadata (/metadate) of the basic partition (Common), and the cow file is obtained index of.

Exemplarily, still taking the adjusted slot1 shown in (b) in Figure 5B as an example, copy the sub-partition description group in the adjusted slot1 to /metadate/gsi/ota under the basic partition (Common) In the /lp_metadata file, the /metadate/gsi/ota/lp_metadata file can record the index of the cow file corresponding to the four subpartitions including system, product, cust, and odm. For example, the index of the cow file in /metadate/gsi/ota/lp_metadata looks like this:

Name: system_b

Group: ry_dynamic_partitions_b

Attributes: readonly

Extents:

0…6995967 linear super 2048

------------------------

Name: product_b

Group: ry_dynamic_partitions_b

Attributes: readonly

Extents:

0…65535 linear super 6998016

------------------------

Name: odm_b

Group: ry_dynamic_partitions_b

Attributes: readonly

Extents:

0…1949695 linear super 9431040

------------------------

Name: cust_b

Group: ry_dynamic_partitions_b

Attributes: readonly

Extents:

0…180223 linear super 16263168.

S540. The device creates a virtual dynamic partition in the user data partition (Userdata) according to the operating system upgrade installation package. In the virtual dynamic partition, a cow file is used to store the upgrade data of the dynamic partition (Super).

In a virtual dynamic partition, a cow file stores the upgrade data of a sub-partition. For example, the system_b_cow_img.img.000 file stores the upgrade data of the system partition, and the cust_b_cow_img.img.000 file stores the upgrade data of the cust partition.

S232. The device restarts.

S240. The device sequentially loads the basic partition (Common) and the static partition (B), and starts from the static partition (B).

S550. The device loads the cow file in the dynamic partition (Super) and the virtual dynamic partition of the user data partition (Userdata) according to the adjusted slot1 and the index of the cow file.

When the device loads a dynamic partition (Super), it can read the sub-partition description group from the adjusted slot1, and read the index and storage status information of the cow file. Wherein, the device reads the sub-partition description group, and can obtain the address (Extents) item of each sub-partition, that is, the offset address of each sub-partition in the dynamic partition. The device reads the storage state information, and can determine whether to retrieve the cow files corresponding to each sub-partition from the user data partition (Userdata). Specifically, when it is read that the overall flag of the disk placement status information is "displaced", it is determined that there is no need to retrieve the cow files corresponding to all sub-partitions from the user data partition (Userdata). When it is read that the overall identifier of the disk placement status information is "unloaded disk", then the sub-partition identifiers for each sub-partition in the disk placement status information can be further read. If the sub-partition is identified as "placed", it is determined that there is no need to retrieve the cow file corresponding to the corresponding sub-partition from the user data partition (Userdata). If the sub-partition is identified as "not placed on the disk", it is determined that the cow file corresponding to the corresponding sub-partition needs to be retrieved from the user data partition (Userdata). The device reads the index of the cow file, and can retrieve the corresponding cow file from the user data partition (Userdata) according to the file name indicated by the index of the cow file.

Exemplarily, the device reads the storage state information, and determines that the cow file corresponding to the system subpartition needs to be retrieved. The device then reads the index of the cow file which contains the following:

Name: system_b,

Group: ry_dynamic_partitions_b,

Attributes: readonly,

Extents: 0...6995967 linear super 2048,

The name item "system_b" corresponding to the system sub-partition can be read. Then, according to the naming rule of the cow file, the device can determine that the file name of the cow file corresponding to the name item "system_b" is system_b_cow_img. The device can retrieve the cow file named system_b_cow_img from the user data partition (Userdata). Thus, the cow file corresponding to the system partition is retrieved.

Afterwards, the device can merge and load dynamic partition (Super) and cow files by using snapshot.

Regarding the parts not described in detail in S550, for example, the contents of the dynamic partition (Super) and the cow file can be merged and loaded by using the snapshot, refer to the related description of S241 in the embodiment shown in FIG. 2 , which will not be repeated here.

S250. The device is successfully started and enters the user interaction interface.

S251. The device puts the data of the virtual dynamic partition into the dynamic partition (Super).

It should be noted here that, for steps not described in detail in FIG. 5A , reference may be made to the description of relevant steps in the embodiment shown in FIG. 2 , and details will not be repeated in the embodiment shown in FIG. 5A . For example, in S550, the contents of the dynamic partition (Super) and the cow file are merged and loaded using the snapshot, and reference may be made to the related description of S241 in the embodiment shown in FIG. 2 .

Using the upgrade scheme shown in FIG. 5A above, after the device obtains the operating system upgrade installation package, it can adjust the slot1 of the dynamic partition (Super) and create the index of the cow file. Then, the device uses the adjusted slot1 and the index of the cow file to load and obtain the data required for starting the dynamic partition (Super), thereby successfully starting the dynamic partition (Super).

However, in an actual scenario, it is very likely that only some partitions in the entire operating system need to be upgraded. In this upgrade scenario, the upgrade solution shown in FIG. 5A will have certain shortcomings. The customized operating system will be used as an example below to illustrate the requirement for upgrading some partitions, and the disadvantages of using the upgrade solution shown in FIG. 5A in the face of this requirement.

The basic operating system (the system corresponding to the data storage structure shown in FIG. 1 and FIG. 3 ) only includes the most basic functions, which cannot fully meet the application requirements of users. Therefore, in order to improve user experience, equipment suppliers will optimize the basic operating system according to different customer needs and application scenarios, add customized content on the basis of the basic operating system, and build a customized operating system. Install a customized operating system on the device so that the device can provide optimized system functions.

FIG. 6 is a schematic diagram of a data storage structure according to an embodiment of the present application. As shown in Figure 6, the Android system data storage area includes a basic partition (Common), a static partition (A), a static partition (B), a customized dynamic partition (Super), and a user data partition (Userdata). For the specific sub-partitions included in the static partition (A) and the static partition (B), reference may be made to the relevant descriptions of the foregoing embodiments. The customized dynamic partition (Super) not only includes all the subpartitions of the dynamic partition (Super) in the basic operating system data storage structure shown in FIG. 1 and FIG. 3 . In addition, custom data is added to the custom dynamic partition (Super) in the form of a sub-partition of the dynamic partition. As shown in Figure 6, the custom dynamic partition (Super) also includes custom (version) partitions, shelf (preload) partitions . Version partition and preload partition are used to save customized data.

For example, the version partition can be used to store customized data related to operators (such as China Mobile and China Unicom). The preload partition can be used to store data related to third-party applications pre-installed on the device when it leaves the factory. It should be noted here that, in the embodiment shown in FIG. 6 , customized data is stored in the version partition and the preload partition. In other embodiments of the present application, other partition structures may also be used to store customized data. For example, keep only the version partition or only the preload partition. Another example is to add an additional service partition.

In the above-mentioned customized operating system, in order to meet the increasing customization requirements of users, it may be necessary to frequently upgrade the customized data. At the same time, in order to facilitate the management of the customized operating system, the data storage structure of the customized operating system can be divided into multiple components. FIG. 7 is a schematic diagram of a data storage structure according to an embodiment of the present application. As shown in Figure 7, the version partition in the customized dynamic partition and the partition (such as the vbmeta_version partition) used to store the verification content of the version partition in the static partition can be collectively referred to as a custom (version) component, and the custom (version) component in the dynamic partition can be customized The preload partition and the partition used to store the verification content of the preload partition (such as the vbmeta_preload partition) in the static partition are collectively called the shelf (preload) component, and all sub-partitions in the dynamic partition in the basic operating system data storage structure in the customized dynamic partition Partitions, such as system, system_ext, product, vendor, etc., and the rest of the static partition are collectively called the base component. It should be noted here that, in the embodiment shown in FIG. 7 , the division of components is only exemplary. In actual implementation, it can be flexibly divided according to the relevance of each partition. For example, each partition in the custom dynamic partition and the space used to verify the partition in the static partition can be divided into a component. Hereinafter, the solution of this application will be described mainly by taking the base component, the version component and the preload component divided as shown in FIG. 7 as examples.

By dividing components, partitions with strong associations, for example, partitions with similar functions of stored data, can be divided into the same component. Moreover, when the data of any component is updated, there will be an upgrade requirement. Especially the preload component has a huge demand for upgrades.

Because the version partition and preload partition are sub-partitions of the custom dynamic partition (Super). Therefore, the entire customized operating system (basic data + customized data) can also be upgraded using the upgrade solution shown in FIG. 5A. As shown in (a) in Figure 8, when there are at least two components (such as the version component and the preload component) that need to be upgraded, the new version of the component that needs to be upgraded (such as the version component and the preload component) can be combined with the new version that does not need The current version of the upgraded components (such as the base component) is combined into a new version and released, that is, the combined upgrade package is released. Then, after the device obtains the combined upgrade package, it can use the upgrade process shown in FIG. 5A to complete the upgrade. In this upgrade method, when any number of components need to be upgraded, they need to be combined to obtain a system upgrade package of a large version before upgrading. In this way, as the upgrade requirements of each component increase, a large number of large-version upgrade packages will be obtained, which is not conducive to flexible management.

If do not adopt the above-mentioned method of publishing combined upgrade package upgrade, as shown in (b) in Figure 8, when the base component needs to be upgraded, then the upgrade installation package (also referred to as base installation package) of the base component can be released; If the version component needs to be upgraded, an upgrade installation package of the version component (also called a version upgrade package) can be released; if the preload component needs to be upgraded, an upgrade installation package of the preload component can be released (also called a preload upgrade package). That is, the version of each component can evolve independently. When multiple components need to be upgraded, the upgrade installation packages corresponding to the multiple components may be published. Afterwards, if the upgrade process shown in Figure 5A is used to complete the upgrade, the device will only adjust slot 1 and create an index of the cow file for the manifest parsed out of one of the upgrade installation packages. In this way, the adjustment to slot1 will be incomplete, and the index of the created cow file will be inaccurate, which will eventually affect the loading of the customized dynamic partition (Super).

Based on the above problems, the present application provides a method for upgrading a combination of multiple components in an operating system. With this method, at least two combinations of components in the operating system (basic operating system or customized operating system) can be upgraded and updated, so that it can be flexibly Adapt to various upgrade needs. For example, the combination upgrade requirements of base component and version component, the combination upgrade requirement of version component and preload component, etc. Specifically, when the device is currently started from the static partition (A), the device implements combined upgrade of multiple components according to the process shown in FIG. 9 .

S900, the device loads the basic partition (Common), the static partition (A) and the dynamic partition (Super) in sequence, and starts from the static partition (A).

When booting from the static partition (A), read multiple sub-partition description groups in Slot0 to load the data of the dynamic partition. At this point, the operating system before the upgrade is running, which may also be called the first operating system.

It should be understood that when the embodiment of FIG. 9 is applied to the upgrade of the basic operating system, the dynamic partition (Super) refers to the dynamic partition (Super) in the basic operating system. When the embodiment of FIG. 9 is applied to the upgrade of the customized operating system, the dynamic partition (Super) refers to the customized dynamic partition (Super) in the customized operating system. The same is true in the following, and details will not be repeated one by one.

S901. The device acquires multiple upgrade packages of multiple components.

In the embodiment of the present application, the plurality of upgrade packages includes a combination of a base upgrade package and a version upgrade package, a combination of a base upgrade package and a preload upgrade package, a combination of a version upgrade package and a preload upgrade package, a base upgrade package, a version upgrade package and a preload One of the combinations of upgrade packages. When multiple components need to be upgraded, the device can download multiple upgrade packages for multiple components at one time. Then, the multiple components are uniformly upgraded for the multiple upgrade packages.

Moreover, each upgrade package can be used to upgrade the dynamic sub-partition (ie, the sub-partition of the dynamic partition) and/or the static sub-partition (ie, the sub-partition of the static partition) involved in the corresponding component. It should be understood that each component may involve one or more dynamic subpartitions, and may also involve one or more static subpartitions. For example, multiple components include a version component. The dynamic sub-partition involved in the version component is the version partition, and the static sub-partition involved is the vbmeta_version partition. The version upgrade package can be used to upgrade the version partition and the vbmeta_version partition.

For the convenience of explanation, the upgrade package of one component can be called an upgrade installation package. When there are multiple upgrade packages of multiple components, they can be distinguished by the prefixes first, second.... Taking the combination of the base upgrade package and the version upgrade package as an example, the base upgrade package may be called the first upgrade installation package, and the version upgrade package may be called the second upgrade installation package. And, for the convenience of description, the dynamic subpartition used for upgrading by the first upgrade installation package may be called the first subpartition, and the dynamic subpartition used for upgrading by the second upgrade installation package may be called the second subpartition. The subpartition other than the dynamic subpartition used for upgrading by the first upgrade package is called the third subpartition. The static sub-partition used for upgrading by the first upgrade installation package can be called the fifth sub-partition, and the dynamic sub-partition used for upgrading by the second upgrade installation package can be called the sixth sub-partition. Subpartitions other than the static subpartition of , are called seventh subpartitions. It should be understood that in actual implementation, according to the division of components in the data storage structure, there may also be a third upgrade installation package, a fourth upgrade installation package, etc., and corresponding to these upgrade installation packages, other dynamic sub-partitions and static sub-partitions may be upgraded. Partitions, for example, the third upgrade package can be used to upgrade the fourth sub-partition of the dynamic partition. This embodiment of the present application does not specifically limit it.

In a feasible implementation scheme, the device periodically initiates a packet search request to the packet search server, and the packet search request includes the version number of each component in the operating system currently running on the device; the packet search server , to retrieve whether there is currently an upgrade package for each component with a newer version number. Exemplarily, the version numbers of the base component, version component, and preload component in the operating system currently running on the device are all version 1.1. If the latest version number of the base component retrieved by the package search server is still version 1.1, but the If the latest version number is 1.2, it indicates that there is an upgrade package for the version component and the preload component with a newer version number. When there are upgrade packages of newer versions for multiple components, the package search server feeds back the download addresses of the upgrade packages for the multiple components to the device. The device can download the upgrade package of the corresponding component according to the download address.

After the device downloads the upgrade packages of multiple components, in response to the events of the upgrade system, such as the user inputting the upgrade operation, reaching the scheduled upgrade time, etc., the online update client (OUC) in the device can update the upgrade package to The location in the device is sent to the device's update engine. Afterwards, the update engine performs specific upgrade operations, such as subsequent upgrade package parsing, data writing, and other operations, to complete the upgrade.

S902. The device parses each upgrade package to obtain multiple application manifest data (manifest) corresponding to the multiple upgrade packages.

From the metadata (/metadata) of each upgrade package, the device can read the offset position and size of the header data of payload.bin in the upgrade package. Then, the device can obtain the manifest from the upgrade package according to the offset position and size of the header data of the payload.bin in the upgrade package.

Exemplarily, part of the content recorded in the metadata (/metadata) of the upgrade package is as follows:

files=payload_metadata.bin:720:1346, payload.bin:720:285881, payload_properties.txt:286653:150, VERSION.mbn:286929:106, SOFTWARE_VER.mbn:286849:21, metadata:63:616.

In the above content, the meaning of payload_metadata.bin:720:1346 is: the offset position (such as 720, unit byte) and size (such as 1346, unit byte) of the header data (ie manifest) of payload.bin in the upgrade package . Then, according to the offset position and size, the device can obtain the original raw data of the manifest (that is, the original data recorded in the upgrade package), and then call the decoding of the original raw data to obtain the specific content of the manifest.

In this embodiment of the application, the static partition information contained in the manifest parsed from each upgrade package only involves the subpartitions of the static partitions included in the multiple components, and the dynamic partition information only involves the sub-partitions of the dynamic partitions included in the multiple components. Subpartitions without involving other components. Other components refer to components other than the plurality of components. Among them, the static partition information or dynamic partition information (which can be referred to as partition information for short) includes the name of the sub-partition (also can be understood as a partition identifier), size, check value (such as hash value) of the upgraded data, and the upgraded data The position in the upgrade package. For the convenience of description, multiple application list data parsed from multiple upgrade packages may be referred to as first data, second data..., for example, the application list data parsed from the first upgrade installation package is called For the first data, the application list data parsed from the second upgrade installation package is referred to as the second data . . . .

Exemplarily, the multiple components include a version component. Since the version component includes the vbmeta_version partition in the static partition and the version partition in the dynamic partition, correspondingly, the parsed manifest can include the following partition information:

The name and size of the vbmeta_version partition, the check value (such as hash value) information of the upgraded data, and the location of the upgraded data in the version upgrade package;

The name and size of the version partition, the check value (such as hash value) information of the upgraded data, and the location of the upgraded data in the version upgrade package.

Also exemplary, the multiple components include a preload component. Since the preload component includes the vbmeta_preload partition in the static partition and the preload partition in the dynamic partition, correspondingly, the parsed manifest can include the following partition information:

The name and size of the vbmeta_preload partition, the check value (such as hash value) information of the upgraded data, and the location of the upgraded data in the preload upgrade package;

The name and size of the preload partition, the check value (such as hash value) information of the upgraded data, and the location of the upgraded data in the preload upgrade package.

In another example, the multiple components include a base component. Since the base component includes partitions other than vbmeta_version and vbmeta_preload in the static partition, such as partitions such as boot and recovery, and subpartitions included in dynamic partitions in the basic operating system, such as partitions such as system and product, the parsed manifest is corresponding can include the following partition information:

The name and size of the boot partition, the check value (such as hash value) information of the upgraded data, and the location of the upgraded data in the operating system upgrade package;

The name and size of the recovery partition, the check value (such as hash value) information of the upgraded data, and the location of the upgraded data in the operating system upgrade package;

... (partition information of subpartitions of other static partitions)

The name and size of the system partition, the check value (such as hash value) information of the upgraded data, and the location of the upgraded data in the operating system upgrade package;

The name and size of the system_ext partition, the check value (such as hash value) information of the upgraded data, and the location of the upgraded data in the operating system upgrade package;

The name and size of the vendor partition, the check value (such as hash value) information of the upgraded data, and the location of the upgraded data in the operating system upgrade package;

...(partition information of subpartitions of other dynamic partitions).

S903. The device merges multiple manifests to obtain a merged manifest.

For convenience of description, the combined manifest may be called third data.

During merging processing, the device can splice multiple manifests end to end according to a first preset order. Exemplarily, the first preset order from front to back is the manifest parsed from the base upgrade package, the manifest parsed from the version upgrade package, and the manifest parsed from the preload upgrade package. Alternatively, the device may also splice the static partition information and dynamic partition information in multiple manifests according to a first preset order. Exemplarily, referring to FIG. 10 , taking multiple upgrade packages including a base upgrade package, a version upgrade package, and a preload upgrade package as an example, when the device merges the three manifests parsed from the three upgrade packages, it may sequentially The manifest parsed from the base upgrade package, the manifest parsed from the version upgrade package, and the static partition information in the manifest parsed from the preload upgrade package are stitched together, and the manifest parsed from the base upgrade package, from The manifest parsed from the version upgrade package is spliced with the dynamic partition information in the manifest parsed from the preload upgrade package to obtain the spliced manifest.

After S903, the device can obtain the merged manifest, and can put the merged manifest into a newly created object, such as mergedmanifest. Subsequent devices can complete the corresponding processing only according to the value of the mergedmanifest, such as adjusting slot1, creating an index of the cow file, and so on.

S904. The device adjusts the sub-partition description group in slot1 in the dynamic partition (Super) according to the dynamic partition information in the merged manifest, and obtains the adjusted slot1. Wherein, during the process of adjusting the sub-partition description group, the device does not delete the sub-partition description group of the sub-partitions included in other components from slot1, and the other components are components other than the plurality of components.

Wherein, the merged manifest includes: dynamic partition information of sub-partitions included in multiple components in the dynamic partition, and the dynamic partition information includes the name and size of the sub-partitions. When the device adjusts slot1 according to the merged manifest, the device adjusts the address (Extents) item in the corresponding subpartition description group in slot1 according to the name and size of the subpartition in the dynamic partition information. If the size of the sub-partition does not change, the address (Extents) item in the corresponding sub-partition description group in slot1 does not change. If the size of the sub-partition changes, adjust the address (Extents) item in the corresponding sub-partition description group in slot1. Therefore, the adjusted address (Extents) item of each sub-partition description group in slot1 matches the size of the corresponding sub-partition. In the following embodiments, the solution of the present application will be described mainly with the fact that the size of the sub-partition does not change.

And, if the multiple components are only two of the base component, versio component and preload component, it indicates that not all components need to be upgraded. In the embodiment of this application, during the process of adjusting slot1 according to the merged manifest, the device will not delete the subpartition description groups of subpartitions included in other components from slot1, that is, delete the subpartition description groups of subpartitions included in components that do not need to be upgraded. Partition description group. For convenience of description, the multiple sub-partition description groups included in the adjusted slot1 may be referred to as multiple third description groups.

Exemplarily, the multiple components are a version component and a preload component, that is, only the version component and the preload component need to be upgraded, but the base component does not need to be upgraded. Wherein, the subpartition included in the version component is the version partition, and the subpartition included in the preload component is the preload partition, then the merged manifest includes the dynamic partition information of the version partition and the preload partition. Assume that the size of each sub-partition of the dynamic partition has not changed before and after the upgrade, and the slot1 before adjustment includes the sub-partition description group shown in (a) in Figure 11, that is, the slot1 before adjustment includes system, system_ext, A subgroup description group of 8 subpartitions including product, vendor, cust, odm, version, and preload. After the device adjusts the slot1 according to the manifest, the adjusted slot1 includes the sub-partition description group shown in (b) in FIG. 11 . Compared with the slot1 before the adjustment, the sub-partition description groups other than the version partition and the preload partition are not deleted in the adjusted slot1. For example, before adjustment, slot1 includes sub-partition description groups of partitions such as system, system_ext, and product (belonging to the sub-partitions included in the base component), and after adjustment, slot1 also includes partitions such as system, system_ext, and product (belonging to the sub-partitions included in the base component) The sub-partitions of ) describe groups (as shown by the dotted box in (b) in Figure 11). In the above example, on the premise that the size of each sub-partition does not change, compared with each sub-partition description group in slot1 before adjustment, the corresponding sub-partition description group in slot1 after adjustment is the same. However, in practice, if the size of at least one sub-partition (such as the version partition) in multiple components is different before and after the upgrade, the address (Extents) item in the sub-partition description group of the at least one sub-partition in slot1 may be different Change accordingly.

That is to say, in the process of adjusting slot1, the description group of sub-partitions (such as the third sub-partition) not involved in the dynamic partition information in the merged manifest will not be deleted.

It should be noted that if the slot1 before adjustment is the initial slot1, then during the process of adjusting slot1 according to the manifest, the device will delete the sub-partition description group corresponding to the static partition (A), that is, the sub-partition description with the suffix _a group, and only retain the sub-partition description group corresponding to the static partition (B), that is, the sub-partition description group with the suffix _b.

S905. The device records the index of the cow file in the basic partition (Common) according to the dynamic partition information in the merged manifest. Wherein, the index is consistent with the sub-partition involved in the dynamic partition information in the manifest.

For convenience of description, the index of the cow file in S905 and its subsequent steps may be referred to as the first index.

If multiple components are only two of the base component, versio component and preload component, it indicates that not all components need to be upgraded. In this case, the adjusted slot1 not only includes sub-partition description groups corresponding to multiple components (ie, components that need to be upgraded), but also retains sub-partition description groups corresponding to other components (ie, components that do not need to be upgraded). If the device directly copies the adjusted slot1 to obtain the index of the cow file, then when the dynamic partition (Super) is subsequently loaded, the index will not only instruct the device to read multiple components from the user data partition (userdata) component) contains the cow file corresponding to the sub-partition, and also instructs the device to read the cow file corresponding to the sub-partition included in other components (that is, components that do not need to be upgraded) from the user data partition (userdata). However, there is no need to upgrade other components this time, and the device will not write cow files corresponding to subpartitions included in other components in the user data partition (userdata). Therefore, instruct the device to read from the user data partition (userdata) The cow files corresponding to subpartitions included in other components are obviously unreasonable.

Based on this, in the embodiment of the present application, the device records the index of the cow file under the basic partition (Common) according to the dynamic partition information in the merged manifest. Wherein, the index is consistent with the sub-partition involved in the dynamic partition information in the merged manifest. In this way, the index may only instruct the device to read the cow file corresponding to the sub-partition included in the component to be upgraded from the user data partition (userdata).

Still taking the example that multiple components are version components and preload components, the merged manifest includes the dynamic partition information of the version partition and the preload partition. Correspondingly, the device can only record the index of the cow file of the version partition and the index of the cow file of the preload partition in the basic partition (Common), so as to instruct the device to read the version partition and the index corresponding to the preload partition from the user data partition (userdata). cow file.

In some embodiments, after obtaining multiple upgrade packages, the device can create a /gsi/ota/lp_metadata file under the metadata (/metadate) of the basic partition (Common), and create the /gsi/ota/lp_metadata file in the /gsi/ota/lp_metadata file The index of the cow file is recorded in . Therefore, it is convenient for the device to obtain the index of the cow file from a fixed location.

In some embodiments, the index of the cow file includes the name of the cow file. Exemplarily, the device can generate the subpartitions involved in the dynamic partition information according to the merged manifest including the subpartitions involved in the dynamic partition information (such as the first subpartition and the second subpartition) and the naming rules of the cow file. The name of the cow file and use that name as an index. For example, if the subpartitions involved in the dynamic partition information are the version partition and the preload partition, and the device is currently booted from the static partition (A), the name of the cow file that can generate the version partition can be: version_b_cow_img, the name of the cow file that generates the preload partition Can be: preload_b_cow_img. Among them, the suffix _b corresponds to the static partition (B), and can be read to load the dynamic partition when restarting from the static partition (B). The device can write the name version_b_cow_img into the basic partition (Common) as the index of the cow file in the version partition; the device can write the name preload_b_cow_img into the basic partition (Common) as the index of the cow file in the preload partition. In this way, the cow file that needs to be found can be accurately indicated by the name. For convenience of explanation, the name of the cow file of the first sub-partition may be referred to as the first file name, and the name of the cow file of the second sub-partition may be referred to as the second file name.

In some embodiments, the index of the cow file also includes the storage location of the cow file. Exemplarily, the storage location may be a user data partition (userdata). Also exemplary, the storage location may be the target directory of the user data partition (userdata) (for example, the /data/gsi/ota directory), and the target directory of the user data partition (userdata) is used to store the upgrade data, if the upgrade data is in cow file storage, the cow file is also stored in the target directory. In this way, the storage location can be used to indicate exactly where to find the cow file.

Still taking the multiple components as version component and preload component as an example, the index of the obtained cow file can include the following information:

Content: version_b_cow_img, preload_b_cow_img

Location: userdata.

The above index indicates that there are cow files named version_b_cow_img and named preload_b_cow_img in the user data partition (userdata).

It should be understood that the aforementioned S904 and S905 are not in a strict sequence. In actual implementation, S905 may also be performed before S904, or S904 and S905 may be performed simultaneously, which is not specifically limited in this embodiment of the present application.

In the embodiment of this application, after obtaining the merged manifest, on the one hand, after the above S904, the device can adjust slot1 according to the merged manifest, and the adjusted slot1 still retains the subpartitions of the subpartitions included in the components that have not been upgraded this time. Partition description group. On the other hand, through S905, the device can create the index of the cow file according to the merge or manifest, so that the index of the cow file only instructs the device to read the cow file corresponding to the sub-partition included in the component that needs to be upgraded this time from the user data partition (userdata) .

S906. The device creates a virtual dynamic partition in the user data partition (Userdata) according to multiple upgrade packages, and sequentially performs data writing operations on the static partition (B) according to the multiple upgrade packages to upgrade the static partition, and write data in the virtual dynamic partition. Import the upgrade data of the dynamic partition (Super). In the virtual dynamic partition, the cow file is used to save the upgrade data of the dynamic partition (Super).

Wherein, each upgrade package includes upgrade data for upgrading the dynamic sub-partition and upgrade data for upgrading the static sub-partition. For the convenience of description, the upgrade data used by the first upgrade installation package to upgrade the dynamic sub-partition (such as the first sub-partition) can be called the first upgrade data, and the second upgrade installation package can be used to upgrade the dynamic sub-partition (such as the second sub-partition). The upgrade data of sub-partitions) is called the second upgrade data. And, the upgrade data that the first upgrade installation package is used to upgrade the static sub-partition (such as the fifth sub-partition) can be called the third upgrade data, and the second upgrade installation package is used to upgrade the static sub-partition (such as the sixth sub-partition). ) is called the fourth upgrade data.

In the embodiment of the present application, the device writes the data used to upgrade the static sub-partitions in the multiple upgrade packages into the corresponding sub-partitions (such as the fifth sub-partition and the sixth sub-partition) of the static partition (B), and writes the multiple upgrade packages The data in the package used to upgrade the dynamic sub-partition is written into the virtual dynamic partition.

Exemplarily, the multiple components are a version component and a preload component as an example. The version component includes a vbmeta_version partition (a sub-partition belonging to a static partition) and a version partition (a sub-partition belonging to a dynamic partition), and the preload component includes a vbmeta_preload partition (a sub-partition belonging to a static partition) and a preload partition (a sub-partition belonging to a dynamic partition). Correspondingly, when the data is updated, the device writes the data of the vbmeta_version partition in the version upgrade package and the data of the vbmeta_preload partition in the preload upgrade package into corresponding partitions of the static partition (B). For example, write the data of the vbmeta_version partition into the /dev/block/by-name/vbmeta_version_b directory, and write the data of the vbmeta_preload partition into the /dev/block/by-name/vbmeta_preload_b directory, where the suffix _b in the directory Corresponds to the static partition (B). And, write the data of the version partition in the version upgrade package and the data of the preload partition in the preload upgrade package to the virtual dynamic partition as a cow file. For example, write the data of the version partition to the cow file named version_b_cow_img in the virtual dynamic partition, and write the data of the preload partition to the cow file named preload_b_cow_img in the virtual dynamic partition. Similarly, the suffix in the file name _b corresponds to the static partition (B).

Further, since the upgrade of multiple components is involved, when the data is updated, the device may sequentially write the data for upgrading the static sub-partition and the data for upgrading the dynamic sub-partition in each upgrade package to corresponding locations. However, in the upgrade scheme (S220 and S540) shown in FIG. 5A, the data update cannot be completed only by writing the data of one upgrade package.

Specifically, when the device writes data to the static partition (B) and the virtual dynamic partition, it can sequentially traverse multiple upgrade packages according to the second preset order, for example, the second preset order is the base upgrade package, version upgrade package and preload upgrade package. And when each upgrade package is traversed, the upgrade data is obtained from the upgrade package and written to the corresponding position to complete the data update. Wherein, if it is the upgrade data of the static partition, it is written into the static partition (B), and if it is the upgrade data of the dynamic partition, it is written into the user data partition (Userdata) in the form of a cow file. After completing the writing of the data corresponding to an upgrade package, it is judged whether there are any upgrade packages to be updated, and if so, the traversal is continued. If not, end S906.

In a specific implementation manner, after acquiring multiple upgrade packages, the device may put the multiple upgrade packages into the target array in a second preset order, where each upgrade package is an element of the target array. In S906, the device can sequentially fetch elements from the array, and after fetching an element, write the data of the corresponding upgrade package. Moreover, after completing the data writing of an upgrade package, the device can continue to fetch elements from the target array. If the elements can be fetched, it is determined that there are upgrade packages that need to be updated, and the data writing continues. On the contrary, if the element cannot be obtained, it is determined that the data of all upgrade packages have been updated, and S906 ends.

Taking the multiple components as version component and preload component, the second preset order from front to back is base upgrade package, version upgrade package and preload upgrade package as an example. Since the base component is not included in the multiple components, the device can only Put the version upgrade package and preload upgrade package into the target array. In S906, the device can take out the version upgrade package from the target array for the first time, write the data of the vbmeta_version partition in the version upgrade package into the vbmeta_version partition of the static partition (B), and write the data of the version partition in the version upgrade package as cow The file is written into the virtual dynamic partition to complete the data update for the version upgrade package. Then, the device can take out the preload upgrade package from the target array for the second time, write the data of the vbmeta_preload partition in the preload upgrade package into the vbmeta_preload partition of the static partition (B), and write the data of the preload partition in the preload upgrade package to the cow file Write to the virtual dynamic partition to complete the data update for the preload upgrade package. So far, all the upgrade packages in the target array have been taken out, and the device can no longer obtain the upgrade packages from the target array, it can be determined that all upgrade packages have been updated, and S906 ends.

Further, after the data update is completed in S906, the device checks the updated data of each sub-partition. In the embodiment of this application, the device can complete the verification according to the merged manifest.

For each sub-partition in the static partition, the device can calculate the check value (such as hash value) of the upgraded data of the sub-partition in the operating system, and then compare the check value with the target of the corresponding sub-partition in the merged manifest. The verification value (such as the hash value) is compared, and if the two are the same, the verification is successful. Taking the vbmeta_version partition as an example, after the device finishes writing data to the vbmeta_version partition, it can calculate the sha256 value of the data in the /dev/block/by-name/vbmeta_version_b directory, and combine the sha256 value with the vbmeta_version partition in the merged manifest Compare the sha256 values of , if the two are the same, the verification is successful.

For each sub-partition in the dynamic partition, the device can calculate the check value (such as hash value) of the result of combining the data of the sub-partition and the data in the cow file of the sub-partition in the virtual dynamic partition, and then the hash value Compared with the target verification value (such as hash value) of the corresponding sub-partition in the merged manifest, if the two are the same, the verification is successful. Taking the version partition as an example, after the device writes the upgrade data of the version partition to the cow file named version_b_cow_img in the virtual dynamic partition, it can calculate the data of the version partition in the dynamic partition and the cow file named version_b_cow_img in the virtual dynamic partition. The sha256 value of the synthesis result of the data, and compare the sha256 value with the sha256 value of the version partition in the merged manifest. If the two are the same, the verification is successful.

S907. Change the boot sequence of the device from booting from the static partition (A) to booting from the static partition (B).

S908. The device restarts.

S909. The device sequentially loads the basic partition (Common) and the static partition (B), and starts from the static partition (B).

At this time, the upgraded operating system is started from the static partition (B), which may also be called the second operating system.

S910. The device loads the dynamic partition (Super) and the cow file of the virtual dynamic partition in the user data partition (Userdata) according to the adjusted slot1 and the index of the cow file.

In the embodiment of the present application, the adjusted slot1 includes sub-partition description groups corresponding to the base component, the version component, and the preload component. Therefore, when the device reads the sub-partition description group in the adjusted slot1, it can obtain address (Extents) items of all sub-partitions in the dynamic partition. And, the index of the cow file only includes the index of the cow file corresponding to the subpartitions included in multiple components (that is, the components that need to be upgraded this time). Therefore, the device reads the index of the cow file, and can only obtain the cow files corresponding to all the upgraded sub-partitions in the dynamic partition, that is, the first upgrade data and the second upgrade data.

S911. The device is successfully started and enters a user interaction interface.

S912. The device puts the data of the virtual dynamic partition into the dynamic partition (Super).

In addition, for parts not described in detail in the embodiment shown in FIG. 9 , reference may be made to the description of the embodiment shown in FIG. 5A above, and details will not be repeated here.

Using the solution of the embodiment shown in FIG. 9 , after obtaining the upgrade packages of multiple components, the device can process the multiple upgrade packages to complete the upgrade of the multiple components. In this way, the requirement that at least two components need to be upgraded can be flexibly met.

Further, the device can use the pre-adjusted subpartition description group in slot1 as the basic data for adjusting slot1 and creating the index of the cow file, and then obtain the adjusted slot1 and the index of the cow file through modification operations such as addition, deletion, modification, and query. Specifically, referring to FIG. 12, before S904 and S905 in the process shown in FIG. 9, S1200 is also included:

S1200. The device stores the subpartition description group in slot1 corresponding to the static partition (B) into the first temporary object and the first file, respectively.

Wherein, the first temporary object (such as target_metadata) is a temporary object created by the update engine process, and is used to adjust slot1. The first file (such as lp_metadata) is a file created by the update engine under the metadata (metadata) of the basic partition (common), and is used to create the index of the cow file. For convenience of description, the first file may also be referred to as a target file.

Specifically, the device may copy the sub-partition description group in the slot1 corresponding to the static partition (B) (slot1 before adjustment at this time) to the first temporary object and the first file, as the basic data and the first file for adjusting slot1, respectively. The basic data for creating the index of the cow file.

Continuing to refer to FIG. 12, S904 in FIG. 9 further includes S1201 and S1202:

S1201. The device adjusts data in the first temporary object according to the dynamic partition information in the merged manifest. Wherein, during the process of adjusting the data in the first temporary object, the device does not delete the subpartition description group of the subpartitions included in other components, and the other components are components other than the plurality of components.

For the specific implementation of adjusting the data in the first temporary object in S1201, refer to the description of adjusting slot1 in S904 above, which will not be repeated here.

S1202. The device updates the adjusted data in the first temporary object to slot1 to obtain the adjusted slot1.

Specifically, the device may write the adjusted data in the first temporary object into slot1 to overwrite the original data in slot1, so as to obtain the adjusted slot1. And, after the adjusted data in the first temporary object is written into slot1, the first temporary object is released.

After the above S1201 and S1202, the device completes the adjustment of the slot1 in the first temporary object, instead of directly adjusting the slot1. In this way, the adjustment process does not directly target slot1, thereby preventing the adjustment process from affecting the operation of the operating system.

Continuing to refer to FIG. 12, S905 in FIG. 9 further includes S1203 and S1204:

S1203. The device adjusts the data in the first file according to the dynamic partition information in the merged manifest. Wherein, during the process of adjusting the data in the first file, the device deletes the subpartition description group of the subpartitions included in other components, and the other components are components other than the multiple components.

Still taking the multiple components as the version component and the preload component as an example, the sub-partitions involved in the dynamic partition information in the merged manifest are the version partition and the preload partition, and the other components are the base components. If the basic data of the first file is shown in (a) in Figure 13, when the device adjusts the data in the first file, it will describe the sub-partitions of the sub-partitions (such as system, product, etc.) included in the base component Group deletion. After deletion, the remaining data is as shown in (b) in Figure 13, only the sub-partition description groups of the version partition and the preload partition remain.

S1204. The device generates an index of the cow file according to the adjusted data in the first file.

The device can generate the file name of the cow file according to the value of the name item in the remaining description group in the first file and the naming rule of the cow file, and use it as an index of the cow file. For details, refer to the description in S904 above. For the convenience of description, the file name of the generated cow file may be called the first file name, and the first file name corresponds to the sub-partition of the dynamic partition involved by multiple components.

After the above S1203 and S1204, the device uses the data in slot1 before adjustment as the basic data for creating the index of the cow file, and then the creation of the index can be completed through simple addition, deletion, modification and query.

Further, after the index of the cow file is created, the device may further create an empty cow file (also called an initial cow file) under the user data partition (userdata) according to the index to store the upgrade data. Among them, creating an empty cow file can be understood as creating a virtual dynamic partition in the previous article. Specifically, as shown in Figure 14, S906 in Figure 9 further includes S1400 and S1401:

S1400. The device creates an empty cow file under the user data partition (userdata) according to the index of the cow file.

The index of the cow file records the relevant information of each sub-partition that needs to be upgraded in the dynamic partition, such as the name of the sub-partition and the name of the cow file corresponding to the sub-partition. According to the relevant information, the device can generate an empty cow file corresponding to each sub-partition to be upgraded in the dynamic partition. Exemplarily, the partition name "version" is recorded in the index of the cow file, and the device can generate the name of the cow file corresponding to the version partition as: version_b_cow_img according to the naming rules of the cow file. Among them, the suffix _b corresponds to the static partition (B), and can be read to load the dynamic partition when restarting from the static partition (B). Then, the device creates an empty cow file named version_b_cow_img under the user data partition (userdata), and sets the space occupied by the cow file according to the size of the version partition to leave enough space for storing the upgrade data. Wherein, the device can obtain the size of the version partition according to the size of the version partition in the manifest.

In some embodiments, the index of the cow file includes the name of the cow file. For details, refer to the description in S905 above. In this embodiment, the device can directly create a named cow file under the user data partition (userdata), and set the space occupied by the cow file according to the size of the partition. For convenience of description, the initial cow file generated according to the first file name can be called the first initial cow file, and the initial cow file generated according to the second file name can be called the second initial cow file. It should be clear that if there are multiple first sub-partitions, then there are multiple first file names, and correspondingly, there are also multiple first initial cow files. Similarly, if there are multiple second sub-partitions, then there are multiple second file names, and correspondingly, there are also multiple second initial cow files.

It should be noted here that the timing of creating an empty cow file in S1400 is not limited to the sequence shown in FIG. 14 . In actual implementation, an empty cow file can be created at any time after the index of the cow file is created. Moreover, after the device obtains the upgrade package, it is running normally until it is restarted, and there is always running data occupying the space of the user data partition (userdata). Therefore, the sooner an empty cow file is created, the sooner it can occupy space for storing upgrade data. In this way, too much space occupied by the user data partition (userdata) due to device operation can be avoided, resulting in insufficient space for storing upgrade data.

S1401. The device sequentially performs data writing operations on the static partition (B) according to multiple upgrade packages to upgrade the static partition, and writes the upgrade data of the dynamic partition (Super) in an empty cow file. Among them, the upgrade data of a sub-partition in the dynamic partition (Super) is written in an empty cow file.

For example, the first upgrade data is written in the first initial cow file, and the second upgrade data is written in the second initial cow file.

With this embodiment, the device creates an empty cow file according to the index of the cow file, so as to occupy the space for storing the upgrade data, so as to avoid insufficient space to store the upgrade data due to the operation of the device.

As shown in Figure 15, in one scenario, after the device leaves the factory, the initial data in the static partition (A) and the static partition (B) are the same, the initial data of the vbmeta_version partition is X1, and the initial data of the vbmeta_preload partition All are Y1, and the initial data of other sub-partitions are all Z1. If the device is currently started from the static partition (A), and the version component and preload component need to be upgraded, the device will update the data of the vbmeta_version partition in the static partition (B) when updating the data of the static partition (such as in S906) , get the updated data X2, and update the data of the vbmeta_preload partition in the static partition (B), and get the updated data Y2. At this time, the data of the vbmeta_version partition in the static partition (A) and the static partition (B) are different. Afterwards, when the device is currently started from the static partition (B), and the preload component and the base component need to be upgraded, the device will update the vbmeta_preload partition in the static partition (B) when performing data update on the static partition (such as in S906) The updated data Y3 is obtained, and the data of the system and system_ext partitions (subpartitions included in the base component) are updated in the static partition (B), and the updated data Z2 is obtained. At this time, although the data update of the sub-partitions included in the preload component and the base component has been completed, the data of the vbmeta_version partition included in the version component that does not need to be upgraded is still the initial data X1, not the previously updated X2. In this way, the data in the static partition (B) will not correspond to the latest version of the data.

For this scenario, in some embodiments, if the multiple components are two of the base component, the version component and the preload component, and the device is currently started from the static partition (A), after the device obtains multiple upgrade packages, The latest data of sub-partitions included in other components in the static partition (A) (that is, components that do not need to be upgraded currently) can be synchronized to the static partition (B). Or, if the device is currently booted from the static partition (B), after the device obtains multiple upgrade packages, it can synchronize the latest data of sub-partitions included in other components in the static partition (B) (that is, components that do not need to be upgraded currently) to Static partition (A). Therefore, the latest data of the sub-partitions included in the components that do not need to be upgraded are kept synchronized between the static partition (A) and the static partition (B). Specifically, when the device is currently started from the static partition (A), as shown in Figure 16, after S902 and before S906 in Figure 9, S1600 and S1601 are also included:

S1600. The device detects whether the multiple components include a base (base) component, a custom (version) component, and a shelf (preload) component. If yes, execute S906; if not, execute S1601 or S1602.

If multiple components include base component, version component and preload component, it indicates that all components need to be upgraded. Correspondingly, all component subpartitions need to be updated. Of course, all the components involve all sub-partitions of the static partition (B), that is, all sub-partitions of the static partition (B) need to be updated, and there are no sub-partitions (such as the seventh sub-partition) that do not need to be updated. In this case, the device does not need to synchronize the latest data between the static partition (A) and the static partition (B), but can directly traverse multiple upgrade packages to update data.

If multiple components do not include all of the base component, version component, and preload component, it indicates that only some components need to be upgraded. That is, only some sub-partitions in the static partition (B) need to be updated. In other words, some sub-partitions (such as the seventh sub-partition) in the static partition (B) do not need to be updated. In this case, the device needs to synchronize the latest data between the static partition (A) and the static partition (B).

S1601. If multiple components include a base (base) component, the device synchronizes data of sub-partitions included in other components in the static partition (A) to corresponding sub-partitions in the static partition (B). Wherein, other components are components other than the plurality of components.

There are two cases where multiple components include the base component: the multiple components are the base component and the version component, or the base component and the preload component. Correspondingly, other components except the plurality of components do not include the base component.

Usually, among all the data in the static partition, the data included in the base component occupies most of the data, while the data included in the version component and the preload component is only a small part. Therefore, when multiple components include the base component, the device can synchronize the data of the sub-partition (seventh sub-partition) included in other components in the static partition (A) to the corresponding sub-partition in the static partition (B). Exemplarily, multiple components are base components and preload components, and other components are version components, and the device can synchronize data in the vbmeta_version partition (ie vbmeta_version_a) of the static partition (A) to the vbmeta_version partition ( That is vbmeta_version_b). In this way, the device can synchronize the data of sub-partitions that do not need to be upgraded currently in the static partition through the synchronization of a small part of data.

For convenience of description, a sub-partition involving a large amount of data in the static partition (B), for example, a sub-partition related to a base component in the static partition (B), may be called a preset sub-partition.

S1602. If the multiple components do not include a base (base) component, the device synchronizes data of all sub-partitions in the static partition (A) to corresponding sub-partitions in the static partition (B).

Multiple components are version components and preload components, and multiple components do not include base components. Correspondingly, other components are base components. That is, most data in static partitions does not need to be upgraded. Therefore, when multiple components do not include the base component, the device can directly synchronize the data of all sub-partitions in the static partition (A) to the corresponding sub-partitions of the static partition (B). In this way, when most of the data does not need to be updated, the device does not need to remove data that does not need to be synchronized from the static partition (A), but can simplify the steps of synchronization by synchronizing all.

It should be noted here that the execution timings of S1600-S1602 are not limited to those shown in FIG. 16 . During actual implementation, the device may execute the foregoing S1600-S1602 at any time between S902-S906, which is not specifically limited in this embodiment of the present application.

Using this embodiment, the device can synchronize the latest data of sub-partitions that do not need to be upgraded in the static partition (A) to the static partition (B), and then update the data of the static partition (B). In this way, it can be guaranteed that the data of each sub-partition in the static partition (B) is up-to-date.

Further, during the data updating process (as in S906 in FIG. 9 ), the device may display the updating progress of the data updating, for example, 50%, 80% and so on. When the update progress reaches 100%, it means that the data update of multiple components is completed. As shown in Figure 17, during the process of the device executing S906 in Figure 9, S1700 and S1701 are also included:

S1700. The device records the writing progress of the component currently targeted for data update, and records the sequence number of the component currently targeted for data update.

Wherein, the writing progress may reflect the amount of data written by the currently targeted component, and may also be referred to as saving progress. The sort number reflects the number of sort bits when the currently targeted component is updated in multiple components. In a specific implementation manner, the device may record the above-mentioned writing progress and sorting number (that is, payload_id, which may also be called the traversal sequence number) in the directory /data/misc/update_log/perfs in the user data partition (Userdata).

Taking the multiple upgrade packages as version upgrade package and preload upgrade package, and the second preset order from front to back is base upgrade package, version upgrade package and preload upgrade package as an example, then the device first performs data update for the version component. The component currently targeted by the current data update is the version component, and the version component is the first component of this data update, so the sort number is 1. Moreover, as the device continues to write data, the device can update in real time the amount of data written to the version component, that is, the writing progress of the version component. After the amount of data written for the version component reaches the total amount of data that the version component needs to write, the device starts to update the data for the preload component. At this time, the current data update is for the preload component, and the preload component is the The second component of the update, the sort count is updated to 2. Similarly, as the device continues to write data, the device can update in real time the amount of data written to the preload component, that is, the writing progress of the preload component.

S1701. The device calculates the update progress according to the write progress and the sort number, and displays the update progress.

Wherein, the update progress refers to the amount of data that has been written for multiple components, as a percentage of the total amount of data that needs to be written by multiple components. Record the amount of written data corresponding to the writing progress as p, and the sorting number as n, then the update progress q can be calculated by the following formula: q=[SUM(the data that needs to be written in the first n-1 components Amount)+p]/SUM (amount of data to be written by multiple components).

Still taking the example in S1700, assuming that the writing progress is 70 pieces of data, the sorting number is 2, the amount of data to be written by the version component is 200 pieces of data, and the amount of data to be written by the preload component is 100 pieces of data, then Update progress q=(200+70)/(200+100)=90%.

In a specific implementation manner, the device can obtain the total amount of data to be written by each component according to the merged manifest. Specifically, in the merged manifest, each piece of partition information includes the location of the upgrade data in the corresponding upgrade installation package, and the location includes the offset of the start location, the offset of the end location, and the size of the data volume. Wherein, the size of the data volume is the data volume of the corresponding sub-partition. Afterwards, the device sums the data volumes of multiple sub-partitions included in the same component to obtain the total data volume of the corresponding component.

With this embodiment, the device can accurately display the update progress during the update process of multiple component data.

Furthermore, as shown in (a) in Figure 18, in some scenarios, the device updates data in the order of the base component, version component, and preload component, and the device is powered off during the update of the version component. After the device is restarted, if the data is updated from the base component again, data may be written repeatedly, affecting the upgrade. In addition, it will also affect the extension of the upgrade time.

Based on this problem, in some embodiments, the device can continue to update from the corresponding update progress at the time of power failure according to the write progress and sorting number recorded in the embodiment shown in the foregoing Figure 17. Specifically, after the device is restarted, the device may determine whether it is a case of restarting after a power failure during the process of updating data, and if so, determine that data update needs to be continued (resume). The device can locate the component being updated when the power is off according to the sort number, and it can also be understood as locating the target upgrade package being written. As shown in (b) in Figure 18, the version component is located according to the sort number 2, that is, the data writing of the version upgrade package is in progress. Then locate the data (target data) being updated in the component being updated when the power is off according to the writing progress. As shown in (c) in FIG. 18 , according to the write progress of 80 pieces of data, locate the position where 80 pieces of data have been written in the version component when the power is turned off. Finally, the device can continue updating from where it was located. In this way, the flexibility of abnormal power-down processing can be improved.

Further, the device may delete the index of the cow file after the disk transfer (eg, S912 in FIG. 9 ) is completed. Specifically, as shown in FIG. 19, after S912 in FIG. 9, S1900 is also included:

S1900. After all the data in the virtual dynamic partition is placed to the disk, the device deletes the index of the cow file.

When the data of at least one sub-partition has not been transferred to the disk, and the device is powered off, after the device is restarted, the dynamic partition needs to be loaded again according to the index of the cow file. Therefore, in this embodiment, when the transfer status information of all sub-partitions in the metadata (/metadata) of the basic partition (Common) is changed from "wait for merge" to "merged )", it indicates that all the data has been transferred to the disk, and at this time, the index of the cow file will be deleted. In this way, the device can continue to use the index of the cow file to load the dynamic partition in the case of an abnormal power failure and restart during the disk transfer process.

An embodiment of the present application provides an electronic device, and the electronic device may include: a memory and one or more processors. The memory is coupled to the processor. The memory is used to store computer program code comprising computer instructions. When the processor executes the computer instructions, the electronic device can execute various functions or steps performed by the device in the foregoing method embodiments.

The embodiment of the present application further provides a chip system, as shown in FIG. 20 , the chip system 2000 includes at least one processor 2001 and at least one interface circuit 2002 . The processor 2001 and the interface circuit 2002 can be interconnected through lines. For example, interface circuit 2002 may be used to receive signals from other devices, such as memory of an electronic device. As another example, the interface circuit 2002 may be used to send signals to other devices (such as the processor 2001). Exemplarily, the interface circuit 2002 can read instructions stored in the memory, and send the instructions to the processor 2001 . When the instructions are executed by the processor 2001, the electronic device may be made to execute various steps in the foregoing embodiments. Of course, the chip system may also include other discrete devices, which is not specifically limited in this embodiment of the present application.

The embodiment of the present application also provides a computer storage medium, the computer storage medium includes computer instructions, and when the computer instructions are run on the electronic device, the electronic device is made to perform various functions or steps performed by the device in the above method embodiments.

The embodiments of the present application also provide a computer program product, which, when running on a computer, causes the computer to execute the various functions or steps performed by the device in the above method embodiments.

Through the description of the above embodiments, those skilled in the art can clearly understand that for the convenience and brevity of the description, only the division of the above-mentioned functional modules is used as an example for illustration. In practical applications, the above-mentioned functions can be assigned by Completion of different functional modules means that the internal structure of the device is divided into different functional modules to complete all or part of the functions described above.

In the several embodiments provided in this application, it should be understood that the disclosed devices and methods may be implemented in other ways. For example, the device embodiments described above are only illustrative. For example, the division of the modules or units is only a logical function division. In actual implementation, there may be other division methods. For example, multiple units or components can be combined Or it can be integrated into another device, or some features can be omitted, or not implemented. In another point, the mutual coupling or direct coupling or communication connection shown or discussed may be through some interfaces, and the indirect coupling or communication connection of devices or units may be in electrical, mechanical or other forms.

The unit described as a separate component may or may not be physically separated, and a component displayed as a unit may be one physical unit or multiple physical units, that is, it may be located in one place, or may be distributed to multiple different places. Part or all of the units can be selected according to actual needs to achieve the purpose of the solution of this embodiment.

In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, each unit may exist separately physically, or two or more units may be integrated into one unit. The above-mentioned integrated units can be implemented in the form of hardware or in the form of software functional units.

If the integrated unit is realized in the form of a software function unit and sold or used as an independent product, it can be stored in a readable storage medium. Based on this understanding, the technical solution of the embodiment of the present application is essentially or the part that contributes to the prior art, or all or part of the technical solution can be embodied in the form of a software product, and the software product is stored in a storage medium Among them, several instructions are included to make a device (which may be a single-chip microcomputer, a chip, etc.) or a processor (processor) execute all or part of the steps of the method in various embodiments of the present application. The aforementioned storage medium includes: various media that can store program codes such as U disk, mobile hard disk, read only memory (ROM), random access memory (random access memory, RAM), magnetic disk or optical disk.

The above content is only the specific implementation of the application, but the protection scope of the application is not limited thereto, and any changes or replacements within the technical scope disclosed in the application shall be covered within the protection scope of the application. Therefore, the protection scope of the present application should be based on the protection scope of the claims.

Claims

A method for upgrading an operating system, characterized in that it is applied to an electronic device, the electronic device includes a processor and a memory, and the memory includes a basic partition, a first static partition, a second static partition, a dynamic partition, and a user data partition, The dynamic partition includes first slot data and second slot data, the dynamic partition includes a plurality of sub-partitions, the first slot data includes a plurality of first description groups corresponding to the plurality of sub-partitions, the The second slot data includes a plurality of second description groups corresponding to the plurality of sub-partitions;

loading the data of the basic partition, the first static partition, and the dynamic partition to run a first operating system, and during the process of loading the data of the dynamic partition, reading the plurality of first description groups, loading data of the dynamic partition based on values of address items in the plurality of first description groups;

Obtain a first upgrade installation package and a second upgrade installation package, the first upgrade installation package is used to upgrade the first sub-partition, the second upgrade installation package is used to upgrade the second sub-partition, the first sub-partition and The second sub-partition is a sub-partition of the dynamic partition, the first upgrade installation package includes first data, the first data includes partition information of the first sub-partition, and the second upgrade installation package including second data, the second data including partition information of the second sub-partition;

A plurality of third description groups are obtained according to the third data and the plurality of second description groups, the third data includes the partition information of the first sub-partition and the partition information of the second sub-partition, the The multiple third description groups include a description group corresponding to the first sub-division, a description group corresponding to the second sub-division, and a description group corresponding to the third sub-division, the third sub-division being the a sub-partition other than the first sub-partition and the second sub-partition in the dynamic partition;

Restarting the electronic device, loading the data of the basic partition, the second static partition, and the dynamic partition to run the second operating system, and during the process of loading the data of the dynamic partition, reading the multiple The value of the address item in the third description group, and the data of the dynamic partition is loaded based on the value of the address item in the plurality of third description groups.
The method according to claim 1, characterized in that, after said obtaining the first upgrade installation package and the second upgrade installation package, said method further comprises:

Writing the plurality of second description groups into a target file, deleting the description group corresponding to the third sub-partition in the target file, and generating a first index.
The method according to claim 1 or 2, wherein after loading the data of the basic partition, the first static partition and the dynamic partition, the method further comprises:

Obtain a third upgrade installation package, the third upgrade installation package is used to upgrade the fourth sub-partition, the fourth sub-partition is a sub-partition of the dynamic partition, the third upgrade installation package includes third data, the The third data includes partition information of the fourth sub-partition;

The plurality of third description groups are obtained according to the third data and the plurality of second description groups, the third data further includes partition information of the fourth sub-partition, and the third sub-partition is Subpartitions in the dynamic partition other than the first subpartition, the second subpartition and the fourth subpartition.
The method according to claim 2 or 3, wherein the first upgrade installation package includes first upgrade data, the first upgrade data is used to upgrade the first sub-partition, and the second upgrade installation The package includes second upgrade data, and the second upgrade data is used to upgrade the second sub-partition;

The method also includes:

saving the first upgrade data and the second upgrade data in the user data partition;

In the process of loading the data of the dynamic partition, read the target file, load the first upgrade data and the second update data in the user data partition based on the first index in the target file Upgrade data.
The method according to claim 4, wherein the deleting the description group corresponding to the second sub-partition in the target file to generate the first index comprises:

Deleting the description group corresponding to the third subdivision in the target file, obtaining the description group corresponding to the first subdivision and the description group corresponding to the second subdivision, and the description group corresponding to the second subdivision. The description group corresponding to a partition includes the name of the first sub-partition, and the description group corresponding to the second sub-partition includes the name of the second sub-partition;

generating a first file name corresponding to the first sub-partition based on the name of the first sub-partition, generating a second file name corresponding to the second sub-partition based on the name of the second sub-partition, the The first index includes the first filename and the second filename.
The method according to claim 5, wherein the first file name corresponding to the first sub-partition is generated based on the name of the first sub-partition, and the name of the second sub-partition is generated based on the name of the second sub-partition. After the second file name corresponding to the second sub-partition, the method also includes:

Create a first initial cow file with a file name of the first file name in the user data partition, and create a second initial cow file with a file name of the second file name, the first initial cow file and No upgrade data is stored in the second initial cow file;

The saving the first upgrade data and the second upgrade data in the user data partition includes:

The first upgrade data is saved in the first initial cow file, and the second upgrade data is saved in the second initial cow file.
The method according to any one of claims 1-6, wherein the first sub-partition includes one or more sub-partitions, the second sub-partition includes one or more sub-partitions, and the third sub-partition A partition consists of one or more subpartitions.
The method according to any one of claims 4-7, wherein the second static partition includes a plurality of sub-partitions, the first upgrade installation package further includes third upgrade data, and the third upgrade data For upgrading the fifth sub-partition, the second upgrade installation package further includes fourth upgrade data, the fourth upgrade data is used for upgrading the sixth sub-partition, the fifth sub-partition and the sixth sub-partition are subpartitions of the second static partition;

After the acquisition of the first upgrade installation package and the second upgrade installation package, the method further includes:

Writing the third upgrade data into the fifth sub-partition, and writing the fourth upgrade data into the sixth sub-partition.
The method according to claim 8, wherein the first static partition comprises a plurality of sub-partitions, and the plurality of sub-partitions of the first static partition are the same as the plurality of sub-partitions of the second static partition one-to-one correspondence;

Before writing the third upgrade data into the fifth sub-partition and writing the fourth upgrade data into the sixth sub-partition, the method further includes:

If the second static partition includes a seventh sub-partition, it is detected whether a preset sub-partition is included in the fifth sub-partition and the sixth sub-partition, and the seventh sub-partition is the second static sub-partition except Subpartitions other than the fifth subpartition and the sixth subpartition;

If the fifth sub-partition and the sixth sub-partition include the preset sub-partition, synchronizing the data of the seventh sub-partition of the first static partition to the data of the second static partition In the seventh subdivision;

If the fifth sub-partition and the sixth sub-partition do not include the preset sub-partition, synchronizing the data of all sub-partitions in the first static partition to the corresponding sub-partitions of the second static partition .
The method according to claim 9, wherein writing the third upgrade data into the fifth sub-partition and writing the fourth upgrade data into the sixth sub-partition comprises:

If the second static partition does not include the seventh sub-partition, write the third upgrade data into the fifth sub-partition, and write the fourth upgrade data into the sixth sub-partition.
The method according to any one of claims 4-10, wherein storing the first upgrade data and the second upgrade data in the user data partition comprises:

Traversing the first upgrade installation package and the second upgrade installation package, when traversing to the first upgrade installation package, saving the first upgrade data in the user data partition, traversing to the second upgrade installation package When installing the package, saving the second upgrade data in the user data partition;

The method also includes:

Record the progress of saving the upgrade data included in the currently traversed upgrade installation package, and record the traversal sequence number of the currently traversed upgrade installation package;

Calculate the saving progress and the update progress corresponding to the traversal sequence number, and display the update progress.
The method according to claim 11, wherein during the process of saving the first upgrade data and the second upgrade data in the user data partition, the method further comprises:

If the electronic device is powered off and restarted, locate the target upgrade installation package corresponding to the traversal sequence number in the first upgrade installation package and the second upgrade installation package, and in the upgrade data of the target upgrade installation package Locating target data corresponding to the writing progress;

Starting from the target data of the target upgrade installation package, the first upgrade data and the second upgrade data are continuously stored in the user data partition.
The method according to any one of claims 1-12, wherein, before obtaining a plurality of third description groups according to the third data and the plurality of second description groups, the method further comprises:

combining the first data and the second data to obtain the third data.
The method according to any one of claims 4-13, wherein after loading the data of the basic partition, the second static partition and the dynamic partition, the method further comprises:

Putting the plurality of first upgrade data and the second upgrade data in the user data partition into corresponding sub-partitions of the dynamic partition.
An electronic device, characterized in that the electronic device includes a processor and a memory, the memory includes a basic partition, a first static partition, a second static partition, a dynamic partition and a user data partition, and the dynamic partition includes a plurality of sub-partitions a partition, the processor is used to execute the software code stored on the memory, so that after the electronic device is started, the data of the basic partition, the first static partition and the dynamic partition are loaded to run the first operating system ;

And, after the first operating system runs, the electronic device is made to execute the method according to any one of claims 1-14.
A computer-readable storage medium, characterized in that a computer program is stored in the computer-readable storage medium, and when it runs on an electronic device, the electronic device executes any one of claims 1-14. the method described.
A chip system, characterized in that the chip system is applied to an electronic device including a processor and a memory, the chip system includes one or more interface circuits and one or more processors, the interface circuit and the The processors are interconnected by wires, and the interface circuit is used to receive signals from the memory of the electronic device and send the signals to the processor, the signals include computer instructions stored in the memory, when the processing When the computer executes the computer instructions, the electronic device is made to execute the method according to any one of claims 1-14.