CN115543368B

CN115543368B - Operating system upgrading method and electronic equipment

Info

Publication number: CN115543368B
Application number: CN202210143150.2A
Authority: CN
Inventors: 张赠辉; 黄九林; 王艳召; 陈超
Original assignee: Honor Device Co Ltd
Current assignee: Honor Device Co Ltd
Priority date: 2022-01-10
Filing date: 2022-02-16
Publication date: 2023-05-23
Anticipated expiration: 2042-02-16
Also published as: CN116610339A; CN115543368A

Abstract

The application provides an operating system upgrading method and electronic equipment, and relates to the technical field of terminals. The problem of the modification of the electronic equipment of demonstration mode is solved. The specific scheme is as follows: acquiring a system upgrade package; updating the system data in the second static partition to the first upgrade data; modifying a starting sequence identifier of the electronic device, wherein the modified starting sequence identifier indicates starting from the second static partition; after the electronic equipment completes the first restart, updating the system data in the dynamic partition into second upgrade data; modifying the first system information into second system information; after the electronic equipment is restarted for the second time, entering a recovery mode; in a recovery mode, migrating a starting physical address of the first data from the first address to the second address; the first partition table is modified to a second partition table. Therefore, remote upgrading can be supported, switching from demonstration to business is realized, recovery and delivery of a prototype are avoided, and labor cost of brushing is saved.

Description

Operating system upgrading method and electronic equipment

The present application claims priority from the national intellectual property agency, application number 202210023826.4, application name "an operating system upgrade method and electronic device" filed on 10/2022, 01, the entire contents of which are incorporated herein by reference.

Technical Field

The present disclosure relates to the field of terminal devices, and in particular, to an operating system upgrading method and an electronic device.

Background

In the application scenario of the prior art, the user terminal needs to install an operating system to be usable by the user. For example, a mobile phone operating system (e.g., IOS system, android system) needs to be installed on the mobile phone to be used by the user.

However, operating systems have different systems, and there are differences in system partitions under different systems. For example, the model corresponding to the demonstration model machine is the demo cn, the model corresponding to the commercial machine is the all cn, and the customizing (version) sub-partition of the demonstration model machine is far greater than the version customizing sub-partition of the commercial machine, and the difference is up to 8G. After the mobile phone is marketed, the demonstration model machine needs to be sold for users, and obviously, the demonstration model machine is very important to be converted into a commercial machine.

Disclosure of Invention

The embodiment of the application provides an operating system upgrading method and electronic equipment, which are used for improving the robot brushing efficiency of system changing of the electronic equipment.

In a first aspect, an operating system upgrading method provided in an embodiment of the present application is applied to an electronic device, where the electronic device includes a memory, and the memory includes a base partition, a first static partition, a second static partition, a dynamic partition, and a user data partition; the dynamic partition comprises a first sub-partition, a first partition table is stored in the dynamic partition, the first partition table comprises a first address, and the first address indicates a starting physical address of the first sub-partition in the memory; the method comprises the steps that a first standard file is stored in a basic partition, the first standard file comprises first standard information, a starting sequence identifier is configured in electronic equipment, the electronic equipment comprises a first operating system and a second operating system, and when the starting sequence identifier indicates starting from a first static partition, the electronic equipment loads data of the basic partition, the first static partition and a dynamic partition after running so as to start the first operating system; after the first operating system is started, the method comprises the following steps: acquiring a system upgrade package, wherein the system upgrade package is used for upgrading an operating system; the system upgrade package comprises first upgrade data, second upgrade data, a second partition table and a second standard file, wherein the second standard file comprises second standard information, and the second standard information is different from the first standard information; the second partition table comprises a second address, and the second address indicates a starting physical address of the first sub-partition in the memory after the upgrade is completed; updating the system data in the second static partition to the first upgrade data; modifying a starting sequence identifier of the electronic device, wherein the modified starting sequence identifier indicates starting from the second static partition; after the electronic equipment completes the first restart, updating the system data in the dynamic partition into second upgrade data; modifying the first system information into second system information; after the electronic equipment is restarted for the second time, entering a recovery mode; in a recovery mode, migrating a starting physical address of the first data from the first address to the second address; wherein the first data comprises data stored in the first sub-partition; the first partition table is modified to a second partition table.

In addition, the electronic device comprises two sets of operating systems which are backed up with each other, namely a first operating system and a second operating system, and the electronic device realizes running of different operating systems by loading different static partitions.

In the above embodiment, taking a scenario in which the electronic device runs the first operating system as an example, when the received system upgrade package includes the second standard file, and the second standard file is different from the first standard file, the electronic device may use the system upgrade package to change the standard type of the electronic device in the upgrade process, and such upgrade may be referred to as a modification upgrade.

Illustratively, the first sub-partition may refer to a system sub-partition that initiates a physical address change after remanufacturing. Taking the example of retrofitting an electronic device to a commercial version, the first sub-partition may be a pre-installed sub-partition that is located after the specifying sub-partition. It will be appreciated that the custom sub-partitions of the presentation prototype are of a different size than the custom sub-partitions of the commercial prototype. Thus, the pre-loaded sub-partitions of the presentation prototype are also located differently than the custom sub-partitions of the commercial prototype.

In the process that the electronic equipment performs virtual AB upgrading based on the system upgrading package, the first system information can be replaced by the second system information, and in addition, after the merge, namely, the dynamic partition is updated by using the second upgrading data, the electronic equipment migrates the first data to the storage position. The first data includes data in a first sub-region after merge. After the storage location of the first data is migrated, the starting physical address of the first data is the same as a second address in the second partition table, where the second address is a starting physical address of the first sub-partition in the commercial electronic device. Then, the partition table indicating the starting physical address of the first sub-partition is changed, i.e., the first partition table is modified to the second partition table. Therefore, in the automatic upgrading process, the system change can be completed without returning to a factory to brush the machine, and the system change efficiency of the electronic equipment is improved.

In some possible embodiments, the first data further includes second data in the dynamic partition, the second data being stored in the base partition after the first sub-partition, a third partition table being stored in the base partition, the third partition table including a third address, the third address being used to indicate an ending physical address of the current dynamic partition in the memory; migrating the starting physical address of the first data from the first address to the second address, comprising: reading first data from between the first address and the third address; writing the read first data into a blank storage area of the user data partition; after the writing is completed, the first data in the user data partition is written into the dynamic partition by taking the second address as a starting physical address.

In the embodiment, in the process of migrating the first data, the safety of the system data is ensured, and the system data is prevented from being damaged due to accidents.

In some possible embodiments, the second address is located after the first address.

In some possible embodiments, a third partition table is stored in the base partition, the third partition table including a fourth address, the fourth address being used to indicate a starting physical address of the user data partition in the memory; the system upgrade package further comprises a fourth partition table, the fourth partition table further comprises a fifth address, the fifth address is used for indicating a starting physical address of the user data partition in the memory after the upgrade is completed, and the fifth address is located before the fourth address; after migrating the starting physical address of the first data from the first address to the second address, the method further comprises: the third partition table is updated with the fourth partition table.

In the above embodiment, the size of the user data partition may be increased, and the storage space utilization of the electronic device may be improved.

In some possible embodiments, after updating the first partition table with the second partition table, the method further comprises: determining that the first system file already comprises second system information; user data partitions are formatted.

In some possible embodiments, after updating the first partition table with the second partition table, the method further comprises: determining that the first system file does not contain the second system information; and reading the second system information again, and writing the second system information into the first system file to replace the first system information in the first system file.

In the above embodiment, by detecting the system information, the success rate of the modification can be improved.

In some possible embodiments, before the first reboot of the electronic device, the method further comprises: after the system upgrade package is analyzed, determining that the system upgrade package contains a remanufactured small package; wherein the second partition table is compressed in the retrofit packet; storing the second standard file in the form of a temporary file in the basic partition; decompressing the reform packet in the first storage area; the first storage area is a storage area accessible by the electronic equipment in a recovery mode; before migrating the starting physical address of the first data from the first address to the second address, the method further comprises: the second address is obtained from a second partition table in the first storage area.

In some possible embodiments, after entering the recovery mode, the method further comprises: writing first indication information in a second storage area in the case of storing the retrofit packet in the first storage area; migrating the starting physical address of the first data from the first address to the second address, comprising: after the first indication information is detected, the starting physical address of the first data is migrated from the first address to the second address.

In some possible embodiments, after updating the system data in the second static partition to the first upgrade data, the method further comprises: creating a virtual partition in the user data partition; writing the second upgrade data into the virtual partition; updating the system data in the dynamic partition to second upgrade data, comprising: and merging the second upgrade data in the virtual partition into the dynamic partition.

In some possible embodiments, after modifying the start-up sequence identification of the electronic device, the method further comprises: in the process of restarting for the first time, loading data in the basic partition, the second static partition, the dynamic partition and the virtual partition; after the first reboot is completed, the data in the second static partition is mirrored to the first static partition.

In a second aspect, an electronic device provided in an embodiment of the present application includes one or more processors and a memory; the memory is coupled to the processor, the memory for storing computer program code comprising computer instructions that, when executed by the one or more processors, operate to: acquiring a system upgrade package, wherein the system upgrade package is used for upgrading an operating system; the system upgrade package comprises first upgrade data, second upgrade data, a second partition table and a second standard file, wherein the second standard file comprises second standard information, and the second standard information is different from the first standard information; the second partition table comprises a second address, and the second address indicates a starting physical address of the first sub-partition in the memory after the upgrade is completed; updating the system data in the second static partition to the first upgrade data; modifying a starting sequence identifier of the electronic device, wherein the modified starting sequence identifier indicates starting from the second static partition; after the electronic equipment completes the first restart, updating the system data in the dynamic partition into second upgrade data; modifying the first system information into second system information; after the electronic equipment is restarted for the second time, entering a recovery mode; in a recovery mode, migrating a starting physical address of the first data from the first address to the second address; wherein the first data comprises data stored in the first sub-partition; the first partition table is modified to a second partition table.

In some possible embodiments, the first data further includes second data in the dynamic partition, the second data being stored in the base partition after the first sub-partition, a third partition table being stored in the base partition, the third partition table including a third address, the third address being used to indicate an ending physical address of the current dynamic partition in the memory; one or more processors further configured to: reading first data from between the first address and the third address; writing the read first data into a blank storage area of the user data partition; after the writing is completed, the first data in the user data partition is written into the dynamic partition by taking the second address as a starting physical address.

In some possible embodiments, a third partition table is stored in the base partition, the third partition table including a fourth address, the fourth address indicating a starting physical address of the user data partition in memory; the system upgrade package further comprises a fourth partition table, the fourth partition table further comprises a fifth address, the fifth address is used for indicating a starting physical address of the user data partition in the memory after the upgrade is completed, and the fifth address is located before the fourth address; after migrating the starting physical address of the first data from the first address to the second address, the one or more processors are further configured to: the third partition table is updated with the fourth partition table.

In some possible embodiments, after updating the first partition table with the second partition table, the one or more processors are further to: determining that the first system file already comprises second system information; user data partitions are formatted.

In some possible embodiments, after updating the first partition table with the second partition table, the one or more processors are further to: determining that the first system file does not contain the second system information; and reading the second system information again, and writing the second system information into the first system file to replace the first system information in the first system file.

In some possible embodiments, the one or more processors are further configured to, prior to a first reboot of the electronic device: after the system upgrade package is analyzed, determining that the system upgrade package contains a remanufactured small package; wherein the second partition table is compressed in the retrofit packet; storing the second standard file in the form of a temporary file in the basic partition; decompressing the reform packet in the first storage area; the first storage area is a storage area accessible by the electronic equipment in a recovery mode; the second address is obtained from a second partition table in the first storage area.

In some possible embodiments, after entering the recovery mode, the one or more processors are further to: writing first indication information in a second storage area in the case of storing the retrofit packet in the first storage area; migrating the starting physical address of the first data from the first address to the second address, comprising: after the first indication information is detected, the starting physical address of the first data is migrated from the first address to the second address.

In some possible embodiments, after updating the system data in the second static partition to the first upgrade data, the one or more processors are further configured to: creating a virtual partition in the user data partition; writing the second upgrade data into the virtual partition; and merging the second upgrade data in the virtual partition into the dynamic partition.

In some possible embodiments, after modifying the start-up sequence identification of the electronic device, the one or more processors are further to: in the process of restarting for the first time, loading data in the basic partition, the second static partition, the dynamic partition and the virtual partition; after the first reboot is completed, the data in the second static partition is mirrored to the first static partition.

In a third aspect, embodiments of the present application provide a computer storage medium including computer instructions that, when executed on an electronic device, cause the electronic device to perform the method described in the first aspect and possible embodiments thereof.

In a fourth aspect, the present application provides a computer program product for, when run on an electronic device as described above, causing the electronic device to perform the method as described in the first aspect and possible embodiments thereof.

It will be appreciated that the electronic device, the computer-readable storage medium and the computer program product provided in the above aspects are applied to the corresponding methods provided above, and thus, the advantages achieved by the electronic device, the computer-readable storage medium and the computer program product may refer to the advantages in the corresponding methods provided above, and are not repeated herein.

Drawings

Fig. 1 is one example diagram of a data storage structure of an operating system in an electronic device according to an embodiment of the present application;

FIG. 2 is an exemplary diagram illustrating system partitions of a prototype and business machine provided in an embodiment of the present application;

fig. 3A is a structural example diagram of an electronic device according to an embodiment of the present application;

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

FIG. 4 is a flowchart of a process for performing a virtual A/B upgrade provided in an embodiment of the present application;

FIG. 5 is a flowchart of a flow for performing merge according to an embodiment of the present application;

FIG. 6 is a second exemplary diagram of a data storage structure of an operating system according to an embodiment of the present disclosure;

FIG. 7 is an exemplary diagram of data migration provided by embodiments of the present application;

FIG. 8 is a flow chart of data migration provided in an embodiment of the present application;

FIG. 9 is an example diagram of a change user data partition (Userdata) provided by an embodiment of the present application;

FIG. 10 is a third exemplary diagram of a data storage structure of an operating system according to an embodiment of the present disclosure;

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

fig. 12 is a schematic diagram of a system on chip according to an embodiment of the present application.

Detailed Description

The terms "first" and "second" are used below for descriptive purposes only and are not to be construed as indicating or implying relative importance or implicitly indicating the number of technical features indicated. Thus, a feature defining "a first" or "a second" may explicitly or implicitly include one or more such feature. In the description of the present embodiment, unless otherwise specified, the meaning of "plurality" is two or more.

The implementation of the present embodiment will be described in detail below with reference to the accompanying drawings.

The embodiment of the application provides an operating system upgrading method which can be applied to electronic equipment. It will be appreciated that the electronic device requires the installation of an operating system in order to be usable by the user. For example, a mobile phone operating system (e.g., IOS system, android system) needs to be installed on the mobile phone to be used by the user.

Illustratively, the electronic device includes, but is not limited to, a smart phone, a smart headset, a tablet computer, a smart refrigerator, a smart speaker, etc., in which an operating system may be installed. Exemplary embodiments of an operating system include, but are not limited to

Or other operating system.

Taking an android system using a virtual a/B operating system as an example, a data storage structure of the operating system in the electronic device is shown in fig. 1, where the data storage structure of the operating system includes a Common partition, a system partition, and a user data partition (Userdata).

The Common partition is a basic partition, and stores system data which does not participate in the upgrade of the operating system. In some embodiments, at least one sub-partition may be included within the Common partition, e.g., an oemiinfo sub-partition or an nv sub-partition. The oemiinfo sub-partition may be used to store format (VC) information of the operating system, for example, all cn, demo cn, cmcc cn, etc. The All cn is used for indicating that a general Chinese system is configured, the cmcc cn is used for indicating a Chinese mobile Chinese system, and the demo cn is used for indicating a demonstration machine system.

It can be appreciated that the electronic device needs to configure corresponding VC information in the operating system according to the location and the access operator. Such as configuring all cn or configuring cmcc cn, etc. In addition, the electronic device may configure corresponding VC information in the operating system according to different uses. For example, a demonstration model placed in a sales floor may be configured with demo cn, and for example, an electronic device for sale to a user may be configured with All cn.

Thus, during the operation of the electronic device, the operating system needs to be started. During the process of starting the operating system, the electronic device reads and loads the VC information in the Common partition, and the VC information may be written into custom information (custom. Bin file) of the user data partition (Userdata) to be invoked during the running of the operating system.

The user data partition (Userdata) is used to store personal data of the user, such as APP installed by the user, pictures, documents, and videos stored by the user.

The system partition is used for storing operating system data. Illustratively, the system partitions are further divided into static partitions and dynamic partitions (Super). The static partition comprises a static partition (A) and a static partition (B). The static partition (a) and the static partition (B) are backup to each other, that is, the structures of the static partition (a) and the static partition (B) correspond to each other, and the sub-partition naming is distinguished from each other by suffixes_a and_b, which may also be referred to as a first static partition and a second static partition, respectively. For example, the static partition (a) includes bootloader_a, boot_a, vendor_boot_a, dtbo_a, vbmeta_a; the static partition (B) includes bootloader_b, boot_b, vendor_boot_b, dtbo_b, vbmeta_b.

With two static partitions, two sets of operating systems, referred to as an A operating system and a B operating system, may be virtualized within the electronic device. When the electronic equipment is started, the electronic equipment needs to run based on any one operating system. For example, in the case where the electronic device needs to run based on the operating system a, the electronic device starts from the static partition (a): sequentially loading a basic partition (Common), a static partition (A) and a dynamic partition (Super); also illustratively, in the case where the electronic device is to run based on the B operating system, the electronic device boots from the static partition (B): the base partition (Common), the static partition (B), and the dynamic partition (Super) are loaded in sequence.

Take the general flash (Universal Flash Storage, UFS) in the format of a master boot record (Master Boot Record, MBR) as an example. In the MBR of the UFS (master boot sector, first sector of the UFS, i.e. 0 cylinder 0 head 1 sector of the C/H/S address), there is stored an electronic device start-up sequence description, e.g. start-up from static partition (a) (start-up sequence flag a) or start-up from static partition (B) (start-up sequence flag a). After the electronic equipment is started, firstly, the starting sequence of the electronic equipment is read from the MBR of the UFS. Then, depending on the read boot sequence, the electronic device may load data in the system partition, such as the sequential loading of the base partition (Common), the static partition (A), and the dynamic partition (Super) as described in the previous examples, or the sequential loading of the base partition (Common), the static partition (B), and the dynamic partition (Super).

In addition, the dynamic partition (Super) may also contain multiple sub-partitions, e.g., preas, preavs, system, system _ ext, vendor, product, cust, odm, version, preload.

It should be noted that the dynamic partition (Super) of the same electronic device includes the same sub-section type, but the sizes of the sub-partitions in the dynamic partition (Super) are different when different standards are adopted for the same electronic device. For example, for a presentation prototype (a device whose VC information is demo cn), a version sub-partition, which may also be referred to as a version-defining sub-partition, is required to store a large number of operational presentation dailies, but version in a commercial machine (a device whose VC information is All cn or cmcc cn) is not required. Thus, the version sub-partition and the reload sub-partition of the demonstration model machine and the commercial machine are different. For example, as shown in fig. 2, the version sub-partitions of the prototype and the commercial machines are different in size, and the starting addresses of the reload sub-partitions are different. This preload sub-partition is also referred to as a first sub-partition. In addition, the starting address may also be referred to as a starting physical address in memory.

Often, presentation prototypes of the previous generation electronic devices also need to be marketed to users after the new generation electronic devices are marketed. Because of the difference in dynamic partition structure, even if sold to users, the presentation prototypes still need a system upgrade package for the presentation prototypes. Therefore, after upgrading, the demonstration sample still exists in the version sub-partition of the demonstration model machine, however, the sold demonstration model machine does not need to store and operate the demonstration sample any more, but the space occupied by the corresponding version sub-region is still large, and the storage space utilization rate is obviously affected by unreasonable storage region division.

In order to improve the problems, the embodiment of the application provides an operating system upgrading method, which aims at a demonstration model machine to be sold, and adjusts an operating system partition when the system of the demonstration model machine is changed through one-time operating system upgrading, so that the demonstration model machine is not different from a commercial machine after being upgraded, the storage space utilization rate of equipment is improved, and the efficiency of upgrading an operating system is also improved.

In the following embodiments, a demonstration model machine that needs to be sold may be collectively referred to as an electronic device. In a Common partition of the electronic device, VC information indicating a first standard (demo cn) is included in an oemiinfo sub-partition.

Fig. 3A is a schematic structural diagram of an electronic device 100 according to an embodiment of the present application. As shown in fig. 3A, the electronic device 100 may include: processor 110, external memory interface 120, internal memory 121, universal serial bus (universal serial bus, USB) interface 130, charge management module 140, power management module 141, battery 142, antenna 1, antenna 2, mobile communication module 150, wireless communication module 160, audio module 170, speaker 170A, receiver 170B, microphone 170C, headset interface 170D, sensor module 180, keys 190, motor 191, indicator 192, camera 193, display 194, and subscriber identity module (subscriber identification module, SIM) card interface 195, etc.

The sensor module 180 may include a pressure sensor, a gyroscope sensor, a barometric sensor, a magnetic sensor, an acceleration sensor, a distance sensor, a proximity sensor, a fingerprint sensor, a temperature sensor, a touch sensor, an ambient light sensor, a bone conduction sensor, and the like.

It is to be understood that the structure illustrated in the present embodiment does not constitute a specific limitation on the electronic apparatus 100. In other embodiments, electronic device 100 may include more or fewer components than shown, or certain components may be combined, or certain components may be split, or different arrangements of components. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

The processor 110 may include one or more processing units, such as: the processor 110 may include an application processor (application processor, AP), a modem processor, a graphics processor (graphics processing unit, GPU), an image signal processor (image signal processor, ISP), a controller, a memory, a video codec, a digital signal processor (digital signal processor, DSP), a baseband processor, and/or a neural network processor (neural-network processing unit, NPU), etc. Wherein the different processing units may be separate devices or may be integrated in one or more processors.

The controller may be a neural hub and command center of the electronic device 100. The controller can generate operation control signals according to the instruction operation codes and the time sequence signals to finish the control of instruction fetching and instruction execution.

A memory may also be provided in the processor 110 for storing instructions and data. In some embodiments, the memory in the processor 110 is a cache memory. The memory may hold instructions or data that the processor 110 has just used or recycled. If the processor 110 needs to reuse the instruction or data, it may be called directly from memory. Repeated accesses are avoided and the latency of the processor 110 is reduced, thereby improving the efficiency of the system.

In some embodiments, the processor 110 may include one or more interfaces. The interfaces may include an integrated circuit (inter-integrated circuit, I2C) interface, an integrated circuit built-in audio (inter-integrated circuit sound, I2S) interface, a pulse code modulation (pulse code modulation, PCM) interface, a universal asynchronous receiver transmitter (universal asynchronous receiver/transmitter, UART) interface, a mobile industry processor interface (mobile industry processor interface, MIPI), a general-purpose input/output (GPIO) interface, a subscriber identity module (subscriber identity module, SIM) interface, and/or a universal serial bus (universal serial bus, USB) interface, among others.

It should be understood that the connection relationship between the modules illustrated in this embodiment is only illustrative, and does not limit the structure of the electronic device 100. In other embodiments, the electronic device 100 may also employ different interfaces in the above embodiments, or a combination of interfaces.

The wireless communication function of the electronic device may be implemented by the antenna 1, the antenna 2, the mobile communication module 250, the wireless communication module 260, a modem processor, a baseband processor, and the like. In some embodiments, antenna 1 and mobile communication module 250 of the electronic device are coupled, and antenna 2 and wireless communication module 260 are coupled, such that the electronic device may communicate with a network and other devices, such as with a wearable device, through wireless communication techniques.

The antennas 1 and 2 are used for transmitting and receiving electromagnetic wave signals. Each antenna in the electronic device may be used to cover a single or multiple communication bands. Different antennas may also be multiplexed to improve the utilization of the antennas. For example: the antenna 1 may be multiplexed into a diversity antenna of a wireless local area network. In other embodiments, the antenna may be used in conjunction with a tuning switch.

The mobile communication module 250 may provide a solution for wireless communication including 2G/3G/4G/5G, etc. applied on an electronic device. The mobile communication module 250 may include at least one filter, switch, power amplifier, low noise amplifier (low noise amplifier, LNA), etc. The mobile communication module 250 may receive electromagnetic waves from the antenna 1, perform processes such as filtering, amplifying, and the like on the received electromagnetic waves, and transmit the processed electromagnetic waves to the modem processor for demodulation.

The mobile communication module 250 can amplify the signal modulated by the modem processor, and convert the signal into electromagnetic waves through the antenna 1 to radiate. In some embodiments, at least some of the functional modules of the mobile communication module 250 may be disposed in the processor 210. In some embodiments, at least some of the functional modules of the mobile communication module 250 may be provided in the same device as at least some of the modules of the processor 210.

The wireless communication module 260 may provide solutions for wireless communication including WLAN (e.g., (wireless fidelity, wi-Fi) network), bluetooth (BT), global navigation satellite system (global navigation satellite system, GNSS), frequency modulation (frequency modulation, FM), near field wireless communication technology (near field communication, NFC), infrared technology (IR), etc. for application on an electronic device.

Among other things, the GNSS may include a Beidou satellite navigation system (beidou navigation satellite system, BDS), a global positioning system (global positioning system, GPS), a global navigation satellite system (global navigation satellite system, GLONASS), a quasi zenith satellite system (quasi-zenith satellite system, QZSS) and/or a satellite-based augmentation system (satellite based augmentation systems, SBAS).

The wireless communication module 260 may be one or more devices that integrate at least one communication processing module. The wireless communication module 260 receives electromagnetic waves via the antenna 2, modulates the electromagnetic wave signals, filters the electromagnetic wave signals, and transmits the processed signals to the processor 210. The wireless communication module 260 may also receive a signal to be transmitted from the processor 210, frequency modulate it, amplify it, and convert it to electromagnetic waves for radiation via the antenna 2.

The electronic device 100 implements display functions through a GPU, a display screen 194, an application processor, and the like. The GPU is a microprocessor for image processing, and is connected to the display 194 and the application processor. The GPU is used to perform mathematical and geometric calculations for graphics rendering. Processor 110 may include one or more GPUs that execute program instructions to generate or change display information.

The display screen 194 is used to display images, videos, and the like. The display 194 includes a display panel. The display panel may employ a liquid crystal display (liquid crystal display, LCD), an organic light-emitting diode (OLED), an active-matrix organic light emitting diode (AMOLED), a flexible light-emitting diode (flex), a mini, a Micro-OLED, a quantum dot light-emitting diode (quantum dot light emitting diodes, QLED), or the like.

The NPU is a neural-network (NN) computing processor, and can rapidly process input information by referencing a biological neural network structure, for example, referencing a transmission mode between human brain neurons, and can also continuously perform self-learning. Applications such as intelligent awareness of the electronic device 100 may be implemented through the NPU, for example: image recognition, face recognition, speech recognition, text understanding, etc.

The audio module 170 is used to convert digital audio information into an analog audio signal output and also to convert an analog audio input into a digital audio signal. The audio module 170 may also be used to encode and decode audio signals. In some embodiments, the audio module 170 may be disposed in the processor 110, or a portion of the functional modules of the audio module 170 may be disposed in the processor 110. The speaker 170A, also referred to as a "horn," is used to convert audio electrical signals into sound signals. In this way, the electronic device 100 may play audio data, such as video music, and the like.

The pressure sensor is used for sensing a pressure signal and can convert the pressure signal into an electric signal. In some embodiments, the pressure sensor may be provided on the display screen 194. The gyroscopic sensor may be used to determine a motion pose of the electronic device 100. The magnitude and direction of gravity may be detected when the electronic device 100 is stationary. The method can also be used for identifying the gesture of the electronic equipment 100 and is applied to applications such as horizontal and vertical screen switching. Touch sensors, also known as "touch panels". The touch sensor may be disposed on the display screen 194, and the touch sensor 180K and the display screen 194 form a touch screen, which is also called a "touch screen". The touch sensor is used to detect a touch operation acting on or near it. The touch sensor may communicate the detected touch operation to the application processor to determine the touch event type.

The method for upgrading the operating system provided in the embodiment of the application is described below by taking the electronic device as an example using the virtual a/B operating system in combination with the accompanying drawings.

In some embodiments, the operating system upgrades described above may be performed by an operating system update program installed on the electronic device. Illustratively, the online update client tool (online update client apk, ouc apk) and the update engine (update engine) are two modules in the operating system update program. online update client apk is used to obtain an upgrade installation package of the operating system, and an upgrade engine (upgrade engine) is used to drive the upgrade of the operating system.

FIG. 3B is a flow chart illustrating an operating system upgrade performed with respect to the data storage structure of the operating system of FIG. 1. In the scenario where the electronic device is booted from the static partition (a), i.e., when operating system based on a, the electronic device implements an upgrade of the operating system according to the flow shown in fig. 3B.

S101, the upgrade server issues a system upgrade package.

In some embodiments, the system upgrade package is data for indicating that the operating system is upgraded to the target version. The target version is different from the version of the system running in the current electronic device. In some embodiments, the system upgrade package is a full volume upgrade package, while the system upgrade package is also data indicating an upgrade to a node version.

In addition, the system upgrade package includes a retrofit package. The retrofit package is used to instruct an operating system of the electronic device to be updated from a first format to a second format (all cn or cmcc cn). The retrofit package is used in the event that the electronic device enters a Recovery mode.

Illustratively, the data structure of the system upgrade package is as follows:

demochange.tag；

META-INF；

payload.bin；

payload_properties.txt；

SOFTWARE_VER.mbn；

update_base_demochange.zip；

vendor_country.mbn；

VERSION.mbn；

the remochange tag is a remodel tag, and is used for indicating that the system upgrade package can be used for remodelling a demonstration model machine into a commercial machine. The META-INF is signature information and is used for carrying out signature verification on the system upgrade package. The payload. Bin includes data that enables the operating system to be upgraded to the target version. The payload_properties. Txt is a FILE carrying parameters such as file_hash and file_ SIZE, METADATA _hash. The SOFTWARE version file is the SOFTWARE version file. The VC information (e.g., all cn) of the target version is stored in the root directory of the system upgrade package in the form of a vendor_count.mbn file. The update_base_remochange. Zip is a modified packet.

The data structure of the retrofit packet, i.e., update_base_remochange. Zip, is illustratively as follows:

Ptable；

Image；

super_metadata.img；

META-INF；

OTA_update.tag；

PTABLE_SUPER.mbn；

skipauth_pkg.tag；

vendor_country.mbn；

wherein Ptable is a total partition table of the target version for describing the partition deployment of the memory device (ROM) after upgrade to the target version. The starting address and size of each partition are defined. Illustratively, ptable includes a start address and an end address in a memory space for a Common partition, a System partition, and a user data partition (Userdata). As shown in table 1 below:

TABLE 1

In addition, the Image includes super_metadata. Img, where the super_metadata. Img is a super sub-partition table corresponding to the target version, and is used to describe a start address and an end address of each sub-partition in the super after upgrading to the target version. META-INF is also included in the retrofit packet and can be used for signature verification as well. The VC information (e.g., all cn) of the target version may also be stored under the root directory of the retrofit package in the form of a vendor_count.

In addition, empty mirror images such as userdata. Img, metadata. Img, etc. can also be included in the retrofit packet.

In some embodiments, the electronic device loads the base partition (Common), the static partition (a), and the dynamic partition (Super) in sequence, starting from the static partition (a). S101 may be executed after the electronic device is started, or may be executed before the electronic device is started. The electronic apparatus executes S102 in a state of being started from the static partition (a), online update client apk.

S102, online update client apk obtains a system upgrade package, wherein the system upgrade package comprises a remanufacturing small package and VC information of a target version.

Illustratively, in one possible implementation, the electronic device periodically initiates a search request to the upgrade server, the search request containing a version number (e.g., version 1.1) of the operating system currently running by the electronic device; the upgrade server searches whether a system upgrade package (for example, version 1.2) with an update version number exists currently according to the version number of the operating system in the package search request; when the system upgrade package of the updated version exists, the upgrade server feeds back the download address of the system upgrade package (for example, the full system upgrade package of version 1.2) to the electronic device; and the electronic equipment downloads according to the download address of the system upgrade package.

Also by way of example, in another possible implementation, the upgrade server may also actively push to the electronic device after obtaining a new version of the system upgrade file.

In the embodiment of the present application, the system upgrade package obtained by online update client apk may indicate that the electronic device is changed from the demonstration version to the commercial version, that is, the system upgrade package includes VC information (e.g., all cn) of the changed package and the target version.

In some embodiments, after S102, online update client apk can download and save the system upgrade package to a user data partition (Userdata). For example, online update client apk periodically initiates a packet search request to the upgrade server, where the packet search request includes information about the current operating system version number of the device (e.g., version 1.1), the SN number of the device, the product model number, the system, etc. (e.g., version 1.1); the upgrade server searches whether a system upgrade package (for example, version 1.2) with an update version number exists on the installation package server according to the version number of the operating system in the package search request; when the system upgrade package of the updated version exists, the upgrade server feeds back a download address (for example, a URL address) of the system upgrade package (for example, the system upgrade package of the version 1.1 to the version 1.2) and a filelist file corresponding to the system upgrade installation package to online update client apk; online update client apk downloads the system upgrade package from the installation package server according to the download address of the system upgrade package.

When online update client apk obtains the system upgrade package, it starts the upgrade engine (upgrade engine), and the upgrade engine (upgrade engine) upgrades the operating system according to the system upgrade package.

That is, online update client apk performs S103 to trigger the update engine to enter the upgrade process.

As one example, after online update client apk obtains the system upgrade package, online update client apk sets the startup attribute of the upgrade engine (update engine), and sets the startup attribute to true. The service servicemanger residing in the background of the operating system monitors the startup attribute of the upgrade engine (update engine), and when the servicemanger detects that the startup attribute of the upgrade engine (update engine) is true, the servicemanger starts the upgrade engine (update engine).

online update client apk obtains the state of the upgrade engine (update engine) through the binder communication, and when online update client apk confirms that the upgrade engine (update engine) is successfully started, online update client apk transmits upgrade parameters (for example, whether the current upgrade operation is a file update operation or a file drop operation) to the upgrade engine (update engine), and triggers the upgrade engine (update engine) to enter an upgrade procedure.

In the upgrade process, the update engine executes S104 to check the operating system upgrade package.

Illustratively, it may be to check whether META-INF (i.e., digital signature) in the system upgrade package is legal, and confirm whether the system upgrade package is a legal upgrade package. For specific implementation details, reference may be made to the related art, and details are not repeated here.

And under the condition that the verification is successful, the update engine executes S105, and under the condition that the system A is operated, the upgrade for the system B is started based on the system upgrade package.

In some embodiments, the B system (also referred to as the second operating system) of the upgrade electronic device is part of the virtual A/B upgrade process. In other words, in the case where the electronic device runs the a system (also referred to as the first operating system), S105 described above may also be to start executing the virtual a/B upgrade procedure.

Illustratively, the flow of performing a virtual A/B upgrade is shown in FIG. 4. As shown in fig. 4, it includes the steps of:

s401, the electronic device reads the saved system upgrade package from the user data partition (Userdata), and performs data writing operation on the static partition (B) according to the system upgrade package to upgrade the static partition.

For example, the system upgrade package includes data of the static partition of version 1.2, also referred to as first upgrade data, and the update engine overwrites the data of the static partition of version 1.2 into the static partition (B).

S402, the electronic equipment creates a virtual dynamic partition in a user data partition (Userdata) according to the system upgrade package, and writes upgrade data of the dynamic partition (Super) in the virtual dynamic partition.

For example, the system upgrade package contains data of the dynamic partition of version 1.2, also referred to as second upgrade data, and the device writes data of the dynamic partition (Super) of version 1.2 in the virtual dynamic partition. In other possible embodiments, in a virtual A/B upgrade scheme, an incremental upgrade approach is employed for dynamic partitions (Super). In the upgrading process, all files of the dynamic partition (Super) of the new version after upgrading are not saved in the virtual dynamic partition of the user data partition (Userdata), but the upgrading result of the data to be upgraded in the dynamic partition (Super) of the old version after upgrading is obtained. That is, the update data of the dynamic partition is stored in the virtual dynamic partition of the user data partition (Userdata).

Taking the system sub-partition as an example, assume that in version 1.1, the data in the system sub-partition can be divided into two parts, system1 and system 2. The data system2 is updated from version 1.1 to version 1.2, and the data system1 is updated to system3. Then, in S402, the device creates a virtual dynamic partition in a user data partition (Userdata), and writes data system3 in the virtual dynamic partition.

For example, the system delta upgrade installation package for version 1.1 to version 1.2 contains the dynamic partition (Super) update data for version 1.1 to version 1.2, which contains data system3.

Further, in the virtual A/B upgrade scheme, incremental upgrades of dynamic partitions (Super) are implemented based on snapshot technology (snapshot). Specifically, in a virtual dynamic partition of a user data partition (Userdata), upgrade data of the dynamic partition (Super) is saved by using Copy-On-Write (COW) files.

Specifically, the upgrade data of the dynamic partition (Super) stored in the user data partition (Userdata) includes a plurality of COW files, each COW file corresponds to a sub-partition of the dynamic partition (Super), and the name of the COW file corresponds to the sub-partition of the dynamic partition (Super) to which the COW file is directed.

In the system upgrade package, the COW file of the upgrade data of the dynamic partition (Super) is compressed and stored in a binary code form. In the system upgrade package, each COW file is named according to the dynamic partition (Super) sub-partition for which it is intended. For example, a COW file for a system sub-partition is named system-COW-img.img.0000.

In S402, the electronic device unpacks the system upgrade package to obtain all the COW files, and attaches an a/B partition flag to each COW file. Specifically, when the electronic 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 by the electronic device is the dynamic partition (a). When the operating system is upgraded, the virtual dynamic partition created in the user data partition (Userdata) is for the dynamic partition (B). Therefore, the name tag_b of the corresponding dynamic partition (B) is attached to the COW file. For example, system_b-cow-img.img.0000 is generated for system-cow-img.img.0000 with the addition of_b.

Further, in S402, an Update folder is created in the user data partition (Userdata), and the renamed COW file is saved under the Update folder. For example, in an application scenario, after writing a COW file to a 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 a file map of a child partition of a dynamic partition (Super) for which the COW file is directed. The file map of the sub-partition of the dynamic partition (Super) is used to describe all files in the sub-partition of the dynamic partition (Super) and the save addresses of the respective files of the operating system of the current version (version before the current upgrade, e.g., version 1.1).

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

Based on the file map of the sub-partition of the dynamic partition (Super) and the COW file map in the COW file, the corresponding file in the sub-partition of the dynamic partition (Super) can be replaced by the upgrade data in the COW file, so that the upgrade of the dynamic partition (Super) data is realized. Specifically, when the file map of the sub-partition of the dynamic partition (Super) needs to be acquired, 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). When the system upgrade package is manufactured, a file map of a sub-partition of a dynamic partition (Super) may be generated in advance, and the file map may be added to the COW file.

Taking the system sub-partition as an example, assume that data is saved in the system sub-partition according to the following path:

/system/app/A0.XXX；

/system/app/A1.XXX；

/system/app/A2.XXX；

/system/B0.XXX；

/system/B1.XXX；

/system/user/C0.XXX；

/system/user/C1.XXX；

/system/user/C2.XXX；

/system/user/C3.XXX。

the file map for the system sub-partition may be:

/system/app/A0.XXX：024010～024013；

/system/app/A1.XXX：024014～024017；

/system/app/A2.XXX：024018～024020；

/system/B0.XXX：024021～024026；

/system/B1.XXX：024027～024028；

/system/user/C0.XXX：024029～024032；

/system/user/C1.XXX：024033～024035；

/system/user/C2.XXX：024036～024040；

/system/user/C3.XXX：024041～024044。

the value after the file name (e.g., 024010 ～ 024013 in "/system/app/A0.XXX:024010 ～ 024013") is the physical save address (block address) of the file in the system sub-partition of the dynamic partition (Super).

Suppose that a current operating system upgrade requires update data/system/app/a 2.Xxx and/system/user/c 2.Xxx.

It can be considered that:

System/app/A2.XXX and/system/user/C2. XXX are the system1 portion of the system sub-partition data;

System/app/A0.XXX,/system/app/A1. XXX,/system/B0. XXX,/system/B1. XXX,/system/user/C0. XXX,/system/user/C1. XXX, and/system/user/C3. XXX are part of system2 of the system sub-partition data.

Then the COW file for the system sub-partition (system_b-COW-img. 0000) contains the latest version of/system/app/a 2.Xxx and/system/user/c 2.Xxx.

It can be seen that the latest version of/system/app/a 2.Xxx and/system/user/c 2.Xxx is system3. The goal of the upgrade is to update system1 using system3.

When the size of the update data in the COW file is consistent with the size of the original data to be updated, and the storage position of the update data in the COW file in the sub-partition after the data is updated is consistent with the storage position of the original data to be updated in the sub-partition, the COW file map of the COW file (system_b-COW-img.img.0000) itself may be:

/system/app/A2.XXX：

Map1 (address of data to be updated in original super partition): the starting address start:024018 (offset from system start address); offset size:2 (i.e. 024018 ～ 024020 address field data)

Map2 (address of update data stored in cow file): the starting address start:045033 (offset from the start address of the cow file store); offset size:2 (i.e., 045033 ～ 045035 address field data);

/system/user/C2.XXX：

map1 (address of data to be updated in original super partition): the starting address start:024036 (offset from system start address); offset size:4 (i.e. 024036 ～ 024040 address field data)

Map2 (address of update data stored in cow file): the starting address start:045036 (offset from the start address of the cow file store); offset size:4 (i.e., 045036 ～ 045040 address field data).

When the size of the update data in the COW file is inconsistent with the size of the original data to be updated, the COW file map of the COW file (system_b-COW-img.img.0000) itself may be:

/system/app/A2.XXX：

map1.1 (address of data to be updated in original super partition): the starting address start:024018 (offset from system start address); offset size:2 (i.e. 024018 ～ 024020 address field data)

Map2.1 (address of update data stored in the cow file, which needs to be overlaid with map1.1 address): the starting address start:045033 (offset from the start address of the cow file store); offset size:2 (i.e., 045033 ～ 045035 address field data);

map1.2 (address to be written in the original super partition for the portion of the cow file where the update data exceeds the size of the data to be updated): the starting address start:025018 (offset from system start address); offset size:1 (i.e. 025018 ～ 025020 address field data)

Map2.2 (address of update data stored in the cow file, which needs to be overlaid with map1.2 address): the starting address start:046033 (offset from the start address of the cow file store); offset size:2 (i.e., 046033 ～ 046035 address field data).

In the following description of the specification, for convenience of description, only an application scenario in which the size of update data in a COW file is consistent with the size of original data to be updated thereof, and the save position of update data in the COW file in a child partition after data update is consistent with the save position of original data to be updated thereof in the child partition is illustrated.

In the above example, the address fields (045033 ～ 045035 and 045036 ～ 045040) are the physical save addresses (block addresses) of the latest version of the system/app/a2.Xxx and the system/user/c2.Xxx in the COW file (system_b-COW-img. 0000), respectively.

Thus, if A2.XXX at address 045033 ～ 045035 is used to replace A2.XXX at address 024018 ～ 024020 and C2.XXX at address 024036 ～ 024040 is used to replace C2.XXX at address 045036 ～ 045040, a data upgrade of the system sub-partition of the dynamic partition (Super) may be accomplished.

Further, in S402, after writing the COW file into the user data partition (Userdata), it is further necessary to perform overall verification on the dynamic partition (Super) +cow file, verify the validity of the dynamic partition (Super) +cow file, and verify whether the result of synthesizing the dynamic partition (Super) data of the current version and the COW file is the dynamic partition (Super) data of the new version.

In some examples, taking upgrading from version 1.1 to version 1.2 as an example, calculating a hash value of a synthesized result of data (unchanged data from version 1.1 to version 1.2) which does not need to be upgraded in the dynamic partition (Super) and upgrading data (data which needs to be upgraded from version 1.1 to version 1.2) in the COW file, judging whether the hash value is consistent with the hash value of the complete data of the dynamic partition (Super) in version 1.2, and if so, indicating that the COW file is valid; if the update files are inconsistent, the COW files are invalid, the update fails, the process corresponding to the update engine is interrupted, and an error is reported; wherein, the hash value of the complete data of the dynamic partition (Super) in version 1.2 is stored in the system upgrade package.

Specifically, during the verification process, dynamic partition (Super) +cow files are merged based on snapshot. In the implementation process of the snapshot, the combination of the dynamic partition (Super) and the COW file is not combination in a physical sense, but the whole file map of the sub-partition in the COW file is combined with the own COW file map of the COW file, so that the file map of the new version of sub-partition data is generated.

For example, a file map that partitions a system sub-partition:

/system/app/A0.XXX：024010～024013；

/system/app/A1.XXX：024014～024017；

/system/app/A2.XXX：024018～024020；

/system/B0.XXX：024021～024026；

/system/B1.XXX：024027～024028；

/system/user/C0.XXX：024029～024032；

/system/user/C1.XXX：024033～024035；

/system/user/C2.XXX：024036～024040；

/system/user/C3.XXX：024041～024044。

and (3) map with the COW file:

/system/app/A2.XXX：

map1: address start:024018; size:2 (i.e. 024018 ～ 024020 address field data)

Map2: address start:045033; size:2 (i.e., 045033 ～ 045035 address field data);

/system/user/C2.XXX：

map1: address start:024036; size:4 (i.e. 024036 ～ 024040 address field data)

Map2: address start:045036; size:4 (i.e., 045036 ～ 045040 address field data).

And (5) merging. A new version of the file map for the system child partition is obtained:

/system/app/A0.XXX：024010～024013；

(A0.XXX pointing to dynamic partition (Super)/system/app)

/system/app/A1.XXX：024014～024017；

(A1. XXX pointing to dynamic partitioning (Super)/system/app)

/system/app/A2.XXX：045033～045035；

(A2.XXX in user data partition (Userdata)/Update/system_b-cow-img. 0000)

/system/B0.XXX：024021～024026；

(B0.XXX in dynamic partition (Super)/under system)

/system/B1.XXX：024027～024028；

(directed to B1.XXX in dynamic partitioning (Super)/under system)

/system/user/C0.XXX：024029～024032；

(C0.XXX pointing to dynamic partitioning (Super)/system/user)

/system/user/C1.XXX：024033～024035；

(C1.XXX pointing to dynamic partitioning (Super)/system/user)

/system/user/C2.XXX：045036～045040；

(directed to C2.XXX in user data partition (Userdata)/Update/system_b-cow-img.img.0000)

/system/user/C3.XXX：024041～024044。

(C3.XXX pointing to dynamic partitioning (Super)/system/user)

In the new version of the system sub-partition's file map,/system/app/A2. XXX's save address is not directed to/system/app/A2. XXX on the dynamic partition (Super) on memory, but to A2.XXX in system_b-cow-img.img.0000 in the user data partition (Userdata) on memory; the save address of/system/user/C2. XXX is not directed to/system/user/C2. XXX on a dynamic partition (Super) on memory, but to C2.XXX in a system_b-cow-img.img.0000 in a user data partition (Userdata) on memory.

In the verification process, according to the above synthesis method, a new version of the file map of all the sub-partitions of the dynamic partition (Super) is obtained (if the corresponding COW file of a certain sub-partition is not written in the user data partition (Userdata), the file map of the sub-partition is directly used as the new version of the file map). Combining the file maps of the new versions of all the sub-partitions generates a file system of the new version of the dynamic partition (Super).

Based on the file system read data of the new version of the dynamic partition (Super), all files contained in the file system of the new version of the dynamic partition (Super) are read and hash values are calculated.

When the COW file is valid, the disk-drop status information in the metadata partition (/ metadata) of the base partition (Common) is changed from "dropped (merge)" to "not dropped (wait for merge)". The landing status information is used to indicate whether there is a COW file currently that needs landing to a dynamic partition (Super). Specifically, the drop status information includes an overall identification for a dynamic partition (Super) and a sub-partition identification for each sub-partition. When the whole mark is 'dropped', all sub-partitions representing the dynamic partition (Super) do not need to be dropped; when the overall identifier is "no disk for merge", one or more sub-partitions representing dynamic partitions (Super) need to perform a disk-drop operation; when the sub-partition is identified as "dropped (merge)", it is representative that the sub-partition does not need to perform a drop operation; when a child partition is identified as "not dropped (wait for merge)", it represents that the child partition needs to be dropped.

In some embodiments, after S402, the electronic device may perform a card slot switching. The card slot switching operation does not change the currently running operating system immediately, that is, the electronic device does not switch the running A system into the B system immediately, and when the electronic device is started next time, system data corresponding to the B system is loaded, so that the electronic device runs in the B system.

Illustratively, the Common partition of the electronic device includes an MBR with a boot sequence identification configured therein. When the electronic device starts the operating system, the start sequence identifier may be read from the MBR, and according to the dynamic sequence identifier, the static partition (static partition a or static partition B) to be loaded is determined, that is, it is determined whether to start the system a or the system B. The card slot switching may be that the electronic device may rewrite the start sequence identifier of the MBR, for example, rewrite the start sequence identifier from a to B, so that after the electronic device is restarted, the electronic device may load the data of the static partition (B) and may switch to running the B system. In addition, in other possible embodiments, the MBR may also be stored in other partitions, for example, the MBR is configured in both the static partition (a) and the static partition (B), and the boot sequence identifiers configured in the MBR in both static partitions are the same.

S403, restarting the electronic equipment.

In some embodiments, the current operating system is exited, the device power is turned off, and the device power is turned on again.

S404, the electronic equipment sequentially loads a basic partition (Common) and a static partition (B).

In some embodiments, during the reboot, the electronic device recognizes that the boot sequence is identified as B, and then the electronic device boot sequence is changed from booting from static partition (a) to booting from static partition (B).

For example, before restarting the electronic device, the boot sequence identification of the master boot record (Master Boot Record, MBR) is rewritten, and the boot sequence identification is rewritten from a to B. After the electronic equipment is electrified, when the electronic equipment reads that the starting sequence identifier is A, the electronic equipment is started from the static partition (A), and the static partition (A) is loaded in the starting process; when the electronic equipment reads the starting sequence identifier as B, the electronic equipment starts from the static partition (B), and the static partition (B) is loaded in the starting process.

For example, the electronic device first loads a base partition (Common). During the process of loading the basic partition (Common), the electronic equipment reads a starting mark in the basic partition (Common); when the start-up flag in the base partition (Common) is (A), the electronic device loads the static partition (A) after loading the base partition (Common), thereby starting from the static partition (A); when the boot flag in the base partition (Common) is (B), the electronic device will load the static partition (B) after loading the base partition (Common), thereby booting from the static partition (B).

In S404, the electronic device reads a start-up flag in a base partition (Common). The boot-up in the base partition (Common) is labeled (B), and the electronic device loads the static partition (B) after loading the base partition (Common), and boots from the static partition (B).

S405, the electronic device loads a dynamic partition (Super) and a virtual dynamic partition of a user data partition (Userdata).

Specifically, the electronic device reads the disc-drop status information in the metadata (/ metadata), determines whether the COW file needs to be retrieved from a specified path of the user data partition (Userdata) based on the disc-drop status information, and loads the dynamic partition (Super) and the COW file by adopting snapshot merging.

Further, in S405, the electronic device does not load all the COW files in the dynamic partition (Super) and the user data partition (Userdata), but loads the corresponding files according to the operating system running requirement. Specifically, in S405, the electronic device determines a file to be loaded according to an operating system running requirement, and extracts a corresponding file from a COW file in a dynamic partition (Super) or a virtual dynamic partition based on snapshot, and loads the file.

Specifically, in S405, when the corresponding COW file exists at the first of the sub-partitions of the dynamic partition (Super), a new version of the file map of each sub-partition of the dynamic partition (Super) is generated based on the snapshot. The process of generating the new version of the file map may refer to S402. And the electronic equipment determines files to be loaded according to the operation requirement of an operating system, and loads the files based on the file map of the new version of the dynamic partition (Super) sub-partition.

For example, operating system running requirements load all data in a directory user (/ system/user) under a system sub-partition. The electronic device reads the disk-drop status information in the metadata (/ metadata), and the sub-partition of the system sub-partition in the disk-drop status information is identified as "no disk for merge", so that the electronic device searches the COW file in the user data partition (Userdata) under Update, and after searching the COW file system_b-COW-img.0000 under Update, based on the snapshot, generates a new version of the file map of the system sub-partition according to the file map of the COW file in the system_b-COW-img.img.0000. Data loading is performed according to the storage addresses of all files in the file map of the new version of the system sub-partition/under the system/user, for example, according to the file map of the new version of the system sub-partition:

/system/user/C0.XXX：024029～024032；

/system/user/C1.XXX：024033～024035；

/system/user/C2.XXX：045036～045040；

/system/user/C3.XXX：024041～024044。

c0.xxx at address 024029 ～ 024032, c1.xxx at address 024033 ～ 024035, c2.xxx at address 045036 ～ 045040, and c3.xxx at address 024041 ～ 024044 are loaded.

In some examples, when all data in the directory user (/ system/user) under the system sub-partition is loaded, and the sub-partition of the system sub-partition in the drop state information is identified as "dropped" (the electronic device does not search the COW file in the user data partition (Userdata)/under Update), but directly loads all data in the directory user (/ system/user) under the system sub-partition.

In other examples, when all data in the directory user (/ system/user) under the system sub-partition is loaded, when the sub-partition of the system sub-partition in the drop state information is identified as "no drop (wait for merge)", if the electronic device does not search for the COW file of the corresponding system sub-partition in the user data partition (Userdata) or under the Update, a data writing error (COW file writing error or drop state information writing error) in the upgrading process is illustrated, and the electronic device rolls back the system and reports the error.

Further, in S405, before loading the file, the electronic device further needs to verify the loaded file. Unlike S402, in S405, the dynamic partition (Super) +cow file is not authenticated as a whole, but only the file to be loaded. For example, checking is performed based on dm-quality (dm-quality is a target of dm (device mapper), which is a virtual block device, specifically used for checking of the file system). And if the verification is successful, loading the file, and if the verification is failed, restarting the device, rolling back the system or attempting to load the file again.

S401 to S405 are part of the a/B upgrade scheme. In the process of the electronic device performing the a/B upgrade, the electronic device may further perform S106 to S109.

For example, after the electronic device has executed S402, the flow may proceed to S106. After the electronic apparatus has executed S107 to S109, the flow proceeds to S403 (i.e., S110), and the restart is performed. After the restart is successful, the electronic device performs S404 and S405, and then the flow proceeds to S111, triggering the merge flow, i.e., entering another part of the a/B upgrade scheme.

For another example, when the electronic device executes S401, S106 to S109 may be executed asynchronously, and of course, S109 needs to be executed before S403 (i.e., S110). Thus, after the electronic device is restarted, the electronic device executes S404 and S405, and then the flow proceeds to S111, triggering the merge flow.

For another example, after the electronic device performs S402 and performs the card slot switching, S106 may be performed, so that after S109 is performed, the electronic device may be triggered to restart, that is, perform S403 (or referred to as S110).

S106, detecting that a reform small packet exists in the system upgrade packet by the update engine.

In some embodiments, the update engine detecting the package name of the retrofit package, such as update_base_remochange. Zip, from the system upgrade package may determine that the retrofit package is detected. In other embodiments, the update engine detects a retrofit tag, e.g., a remochange. Tag, from the system upgrade package, and may determine that a retrofit package exists in the system upgrade package.

S107, the update engine reads the VC information of the target version from the system upgrade package.

In some embodiments, the system upgrade package includes a file written with VC information, such as a vendor_count.mbn file, which is also referred to as a second standard file, and in this scenario, after parsing the system upgrade package, the VC information of the target version may be obtained from the vendor_count.mbn file, which is also referred to as the second standard information.

S108, the update engine writes the read VC information into oemiinfo_vc_tmp.

In some embodiments, the oemifo_vc_tmp is a temporary file in the oemifo sub-partition, and occupies a temporary storage space in the oemifo sub-partition. The oemifo_vc_tmp is different from the oemifo_vc file in the oemifo child partition. The oemiinfo_vc file includes VC information before system upgrade (e.g., VC information of version 1.1). It will be appreciated that the oemifo_vc_tmp differs from the oemifo_vc file in the physical address actually occupied in the oemifo sub-partition. In addition, the storage address corresponding to the oemiinfo_vc file is an address where the electronic device loads VC information. Thus, when the electronic device loads system data, the oemifo_vc file is loaded, but the oemifo_vc_tmp file is not loaded.

In addition, it will be appreciated that S108 is only an exemplary manner of temporarily storing the VC information of the target version in the system upgrade package, and other implementations may exist, for example, writing the VC information of the target version to another temporary storage area that may be read, and so on. The embodiments of the present application are not limited in this regard.

S109, the update engine decompresses the modified packet to the cache/update directory, wherein the modified packet comprises a pt able and super_metadata. Img.

In some embodiments, the above-mentioned cache/update directory is a directory under a cache sub-partition, also referred to as a first storage area, which belongs to a Common partition. In addition, the cache sub-partition is capable of accessing the storage partition in Recovery mode. After decompressing the remodelling packet to the cache/update directory, the cache/update directory includes the pt able and super_metadata. Img.

S110, the update engine triggers the electronic equipment to restart.

In some embodiments, the current operating system is exited, the power of the device is turned off, and the power of the device is turned on again, and the step S110 is the same as the step S403, which is also called the first restart. In the case that the restart is successful, the electronic device executes S404 and S405. After S405 is performed, in the case where it is determined that the current state is the non-dropped state, the flow then proceeds to S111.

S111, triggering a merge flow by the update engine.

In some embodiments, the merge flow is initiated after a restart, i.e., when the new system is in effect, i.e., the updated B system is in effect. As shown in fig. 5, the merge flow includes:

s501, the electronic equipment is successfully started and enters a user interaction interface.

S502, the electronic device merges the data of the virtual dynamic partition into the dynamic partition (Super) in the background.

That is, the electronic device drops the virtual dynamic partition's data in the background to a dynamic partition (Super). In this embodiment of the present application, the disc-dropping operation refers to writing, in an operating system upgrade process, a dynamic partition (Super) upgrade file (COW file) stored in a virtual dynamic partition on a user data partition (Userdata) into the dynamic partition (Super), so that the file of the dynamic partition (Super) completes data upgrade, so that the electronic device does not need to load the dynamic partition (Super) and the virtual dynamic partition when being started next time, and only needs to load the dynamic partition (Super) to complete the startup of the electronic device.

In some examples, the electronic device performs a boot broadcast after the boot is successful, and starts a process corresponding to the update engine after the boot broadcast. The process corresponding to the update engine reads the disk-dropping state information in the metadata (/ metadata) of the basic partition (Common), and if the disk-dropping state information is "dropped (merge)", the device enters a normal running mode.

And if the landing status information is "no landing for merge", the corresponding process of the update engine drops the COW file in the user data partition (Userdata) into the dynamic partition (Super).

In some embodiments, the process corresponding to the update engine 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) is the data of the new version after the upgrade.

For example, in a system sub-partition based file map/system/app/a 2.Xxx:024018 ～ 024020/system/app/a 2.Xxx in COW file map: 045033 ～ 045035 writing the data at address 045033 ～ 045035 to address 024014 ～ 024017; system/user/c2.Xxx in system sub-partition based file map: 024036 ～ 024040/system/user/c 2.Xxx in COW file map: 045036 ～ 045040, the data at address 045036 ～ 045040 is written to address 024036 ～ 024040.

After that, deleting the COW file in the user data partition (Userdata) by the process corresponding to the update engine, and returning the storage space to the user data partition (Userdata); and, the disk-drop state information in the metadata (/ metadata) of the base partition (Common) is changed from "no disk for merge" to "dropped disk (merge)".

In S401, the data operation of the static partition upgrade is for the operating system data in the static partition (B), which does not affect the operating system data of the currently started static partition (a); also, in S402, the data operation of the dynamic partition upgrade is completed on the virtual dynamic partition created in the user data partition (Userdata), which does not affect the currently mounted dynamic partition (Super). Therefore, in the whole operating system upgrading process, the user can normally use the equipment; after S402 is completed, the device does not need to be restarted immediately, and the user can select the restart time by himself; therefore, the upgrading process of the operating system does not influence the normal mobile phone operation of the user, so that the user experience is greatly improved. Therefore, for the dynamic partition (Super), the virtual dynamic partition is created on the user data partition (Userdata) only when the upgrade is needed, so that the data storage space utilization rate is effectively improved.

In some embodiments, after the merge process ends, the space occupied by the data in the version-defining sub-partition of the super partition becomes smaller, and at the same time, the location of the pre-load sub-partition is unchanged, so that a free space (storage space that cannot be actually used) is formed between the version and the pre-load, and the merge ends, and the data structure of the operating system is as shown in fig. 6, the start address of the version sub-partition is unchanged, and the end address becomes smaller, so that the physical storage space occupied by the version sub-partition is reduced. The start address and end address of the Preload sub-partition are unchanged, so that an idle physical memory area (i.e., free space) will occur between the version sub-partition and the Preload sub-partition.

S112, the update engine copies the static partition of the B system into the static partition of the A system.

In some embodiments, S112 is merely an example of a manner of updating the static partition (a), and in embodiments of the present application, other possible implementations may also exist, for example, an update engine may update data in the static partition (a) with a system upgrade package, which is not specifically limited in embodiments of the present application.

S113, the update engine writes the VC information in the oemifo_vc_tmp into the oemifo_vc file in the oemifo sub-partition.

In some embodiments, the VC information stored in oemiinfo_vc_tmp is a target version of VC information (e.g., all cn) read from the system upgrade package, where the VC information is different from the original VC information in the electronic device (i.e., demo cn, also referred to as first standard information), i.e., the VC information in oemiinfo_vc_tmp is different from the VC information recorded in the oemiinfo_vc file. The oemiinfo_vc file may be referred to as a first standard file. Thus, after the VC information (e.g., all cn) of the target version is written into the oemiinfo_vc file, the original VC information (i.e., demo cn) in the oemiinfo_vc file may be covered, thereby implementing the change of the system information. The above procedure is also called modifying the first system information to the second system information.

In addition, the oemifo sub-partition belongs to a Common partition, and in the process of starting an operating system, VC information needs to be read from an oemifo_vc file of the oemifo sub-partition. It can be seen that the system change of the electronic device can be realized by changing the VC information in the oemiinfo_vc file.

After the electronic device finishes the system change, the problem of low storage space utilization needs to be further improved.

In this embodiment of the present application, as shown in fig. 3B, further includes:

And S114, writing data indicating the reform upgrade into the cache/recovery/command file under the condition that the update engine detects that the cache/update directory comprises the reform small packet.

For example, the data indicating the update upgrade may be information indicating a modified packet storage path, e.g., in case that the modified packet is stored in a cache/update directory, the information indicating the modified packet storage path may be "update_package=/cache/update/update_base_remote. Thus, after the electronic device enters the Recovery mode, the reform packet can be searched according to the storage path.

In other embodiments, after entering the Recovery mode, the modified packet may be obtained, for example, in the case that the modified packet is detected to be included in the cache/update directory, the data indicating the modification upgrade may also be the modified packet itself, that is, after the modified packet is detected to be included in the cache/update directory, the modified packet is moved to the cache/Recovery directory.

S115, the update engine triggers a restart and indicates to enter a Recovery mode.

In some embodiments, the above-mentioned restart is also referred to as a second restart, and in addition, after the entry into the Recovery mode is instructed, the Recovery process is enabled, and the flow proceeds to S116.

S116, checking the integrity of the system upgrade package by the Recovery process.

In some embodiments, S116 may refer to an implementation manner of verifying the integrity of the upgrade package in the related art, which is not described herein.

S117, the Recovery process determines that the global variable vcdefmo is configured when the current scene is a modified upgrade scene according to the cache/Recovery/command file.

In some embodiments, the Recovery process may parse the command file in the cache/Recovery/directory to obtain a storage path, and at this time, the Recovery process accesses the corresponding storage space according to the storage path. In the case that the data packet exists in the storage space, if the packet name of the data packet is determined to be the same as the packet name of the predefined modification small packet, the current modification upgrading scene is determined. For another example, if it is determined that an identification indicating remanufacturing exists in the data packet, a current remanufacturing upgrade scenario may also be determined.

In some embodiments, when it is determined that the upgrade scenario is currently being remanufactured, the Recovery process writes a global variable vcdefmo (also referred to as first indication information) in a designated storage location (e.g., in a cache accessible by the Recovery process, such as referred to as a second storage area).

It can be appreciated that configuring the global variable vccdemo indicates that the upgrade is a retrofit upgrade, which is only one implementation. In other embodiments, the Recovery process may be prompted to execute the subsequent flow of the reform upgrade in other manners, for example, the electronic device actively queries whether the reform packet exists in the cache/update directory, or the like.

S118, if the variable vcdefmo is identified, the Recovery process executes preload data migration.

In some embodiments, the preload data is data stored in the preload sub-partition after the merge process is completed. The principle of the above-mentioned preload data migration is shown in fig. 7: the electronic device copies the data in the preload sub-partition and the tail data of the super partition to the tail of the userdata partition. The tail data of the super partition refers to data stored after the reload sub-partition, for example, 3M tail data as shown in fig. 7. And then, the data in the preload sub-partition in the userdata partition and the tail data of the super partition are written into the super partition again. Illustratively, super_metadata. Img, also referred to as a second partition table, in the retrofit packet may be obtained first. The start address (also called the second address) of the indicated reload sub-partition is then obtained from the super_metadata. Img. It will be appreciated that the start address of the pre sub-partition in super_metadata. Img is the same as the start address of the free space, i.e. adjacent to the end address of the version-defined sub-partition after merge, so that the free space in the super partition can be utilized.

As one implementation, the process of performing a reload data migration is shown in fig. 8, and includes:

s801, the Recovery process reads the super header information from the super partition.

In some embodiments, the above-described super header information may be stored in the storage space of the top 1M of the super partition. The super header information includes data describing the start address and size of each sub-partition in the current super partition. In other words, the super header information includes a first partition table, which includes a first address indicating a starting physical address of the first sub-partition in the memory. For example, before merge, the super header information indicates the start address and size data of the version sub-partition and the reload sub-partition as follows:

Super：17295360..34072576：version_b(16777216sectors)；

Super：34072576..37152768：preload_b(3080192sectors)；

that is, before merge, the version sub-partition has a start address of "physical address 17295360" and an end address of "physical address 34072576", and the version sub-partition has a size of 16777216sectors, that is, the version sub-partition occupies approximately 8-9G of memory space. The beginning address of the forward sub-partition is "physical address 34072576", the ending address is "physical address 37152768", and the size of the version sub-partition is 3080192sectors.

In addition, after merge, the super header information indicates the start address and data of the size of the version sub-partition and the reload sub-partition as follows:

Super：17295360..17360896：version_b(65536sectors)；

Super：34072576..37152768：preload_b(3080192sectors)；

it can be seen that after merge, the version sub-partition has a start address of "physical address 17295360", an end address of "physical address 17360896", and a size of 65536sectors. The beginning address of the forward sub-partition is "physical address 34072576", the ending address is "physical address 37152768", and the size of the version sub-partition is 3080192sectors.

Clearly, between the version sub-partition and the reload sub-partition, there is free space, i.e., memory space between physical address 17360896 and physical address 34072576. The free space cannot be practically utilized.

S802, the Recovery process analyzes the size (size) of the preload data and the current position attribute (currentpos) from the super header information.

For example, the size (size) of the preload data may be 3080192sectors, and the current location attribute (current) may be a physical address 34072576. That is, the reload data is data read to a size of 3080192sectors starting from the physical address 34072576.

S803, the Recovery process reads the preload data from the super partition according to the size and the current of the preload data.

Illustratively, starting with the physical address indicated by currentpos (e.g., physical address 34072576), data of a specified size (e.g., 3080192 sectors) is read from the super partition as preload data.

S804, the Recovery process writes the preload data into a blank area in the userdata partition.

In some embodiments, the preload data may be written to memory space at the end of the userdata partition.

S805, the Recovery process reads the target location (dstpos) from the super_metadata. Img of the retrofit packet.

In some examples, the target location (dstpos) is the start address of the preload partition to which the target version corresponds. It can be understood that after version modification is recorded in the super_metadata. Img, information such as the start address and the size of each partition is recorded.

For example, the data of the start addresses and sizes of the version sub-partition and the reload sub-partition in the super_metadata. Img are as follows:

Super：17295360..17360896：version(65536sectors)；

Super：17360896..20441088：preload(3080192sectors)；

thus, the target location (dstpos) read from the super_metadata. Img may be the physical address 17360896.

S806, the Recovery process writes the reload data in the userdata partition into the super partition again according to the target position (dstpos).

In some embodiments, the reload data is written to the super partition by overwriting with the memory address indicated by the target location (dstpos) as the starting address. For example, the reload data is written again to the super partition with the physical address 17360896 as the starting address.

In addition, in addition to requiring migration of the reload data, as shown in FIG. 7, the tail data (e.g., referred to as the second data) of the super partition also requires synchronous migration. It will be appreciated that the tail data of the above-described super partition is the data stored after the reload data in the super partition. For purposes of this aspect description, the preload data and the tail data of the super partition may be referred to as data 1 or first data. For example, when the Recovery process determines that the tail space after the preload sub-partition further includes 3M size data in the super partition, after reading the preload data, the Recovery process continues to read the 3M size data with the end address of the preload sub-partition as the starting point, so that data 1 can be read. Then, the read data 1 is written into the blank area in the userdata partition, and then the target position (dstpos) is used as a starting address, and the data 1 in the userdata partition is written into the super partition again.

Alternatively, after resolving the location attribute (currentpos) of the reload sub-partition, such as address a or the first address, the ending address (also referred to as ending physical address) of the super partition, such as address b or the third address, is resolved from the partition table (also referred to as the third partition table) of the Common partition. Then, all data written between the address a and the address b is read as data 1. Then, the read data 1 is written into the blank area in the userdata partition, and then the data 1 in the userdata partition is written into the super partition again with the target position (dstpos) as the starting point. S119, updating the partition table in the Common by the Recovery process by using the pt in the adaptation packet.

In some embodiments, the above-mentioned pt can includes a start address and an end address of a Common partition, a system partition, and a user data partition (Userdata) in a storage space under a target version, and the pt can is also called a fourth partition table, where the fourth partition table further includes a fifth address, where the fifth address is used to indicate a start physical address of the user data partition in the memory after the upgrade is completed.

Of course, the Common partition originally also includes a partition table, such as a partition table a or a third partition table, where the partition table a may be used to indicate a start address (also referred to as a fourth address) and an end address of a Common partition, a system partition, and a user data partition (Userdata) of the electronic device in the storage space after the merge. Wherein the above-mentioned pt is smaller than the partition table a, i.e. the fifth address precedes the fourth address.

It will be appreciated that after S111 above, that is, after the electronic device passes through the merge, a free space will appear between the version sub-partition and the reload sub-partition, and then after migrating the reload data and the tail data of the super partition, an idle space will appear at the tail of the super partition. At this time, by using the possibility, instead of the partition table a in the Common, the space left unused at the tail of the super partition may be divided into user data partitions (Userdata), as shown in fig. 9. Before the method, the storage positions of the preload data are moved forward, the electronic equipment can normally load the system data according to the updated partition table in the Common, namely, under the condition that the system data is not influenced, the user data partition (Userdata) which is subjected to user domination is increased, and the use experience of the user is improved.

S120, the Recovery process updates the super_metadata. Img in the adaptation packet to the super header information.

In some embodiments, the head storage area of the super partition (the storage space indicated by 1MB in fig. 9, also referred to as super_metadata partition) stores therein head information, also referred to as super head information. The super header information includes a sub-partition table. The sub-partition table records the starting address and the size of each sub-partition of the original super partition of the electronic equipment. In the embodiment of the present application, the actual position of the preload data has been shifted forward, and the super_metadata. Img is referred to in the shifting-up process. This means that since the version custom child partition is scaled down after the upgrade to the target version, the starting position of the reload partition is also shifted up. It can be understood that the version custom sub-partition size recorded in the super_metadata. Img is a reduced size, and the starting position of the reload partition is also an up-shifted address, so that after the electronic device writes the super_metadata. Img into the super header information instead of the atomic partition table, the electronic device can normally load the data in the reload partition after starting the operating system.

In the previous example, before the super_metadata. Img is updated to the super header information, recording in the super header information: the version sub-partition has a start address of "physical address 17295360" and an end address of "physical address 17360896"; the preload sub-partition starts at physical address 34072576 and ends at physical address 37152768.

After the super_metadata. Img is updated to the super header information, recording in the super header information: the version sub-partition has a start address of "physical address 17295360" and an end address of "physical address 17360896"; the preload sub-partition starts at physical address 17360896 and ends at physical address 20441088. Thus, after the preload data is advanced, the electronic device can accurately read the data.

As an example, in the android system adopting the virtual a/B upgrade mode, as shown in fig. 10, since only the static partition adopts the a/B scheme, the dynamic partition adopts the scheme of constructing the virtual dynamic partition at the time of upgrade. Therefore, for matching the static partition and the dynamic partition, in the Super header information, metadata (/ Super metadata) of the header of the dynamic partition (Super), slot0 (Slot one data) corresponding to the static partition (a) and Slot1 (Slot two data) of the static partition (B) are included. Slot0 and Slot1 are used to store the partition table for the Super partition.

For example, in the MBR of UFS, in the device boot sequence description, configuration Slot0 corresponds to boot from static partition (A) and configuration Slot1 corresponds to boot from static partition (B). When the equipment is started, according to the different static partitions started, selecting to acquire partition information of the Super partition from one of Slot0 or Slot 1. For example, when the device is started by the static partition a, when loading the Super partition, the device first reads Slot0 to obtain the sub-partition address of the Super partition; when the device is started by the static partition B, the device first reads Slot1 to obtain the child partition address of the Super partition when loading the Super partition.

Specifically, slot0 and Slot1 include a plurality of sub-partition description groups, each of which corresponds to a sub-partition of the Super partition. Each sub-partition description group contains:

a Name (Name) item whose value is the Name of the child partition;

a Group (Group) entry whose value is a child partition type;

an attribute (Attributes) item whose value is a partition read-write attribute, for example, a read-only attribute (read only);

an address (extensions) entry whose value is the address of the child partition (e.g., partition size, offset).

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

When the Super partition is loaded, starting with static partition A, slot0 is read first. When the Slot0 is read, because the suffix is that the_a corresponds to the static partition (A), the device reads the value of the names item in the Slot0 and/or the values of the extensions item in the partition description Group of which the Group item suffix is that the_a so as to acquire the sub-partition address of the Super partition.

When the Super partition is loaded, starting with static partition B, slot1 is read first. When the Slot1 is read, because the suffix is_b, the device reads the value of the Name item in the Slot0 and/or the value of the extensions item in the partition description Group of which the suffix is_b, so as to obtain the sub-partition address of the Super partition.

The adaptation packet contains partition information of a dynamic partition (Super) of a target version, that is, super_metadata. Img, and the electronic device may refresh partition information in Slot1 corresponding to the static partition (B) by using the super_metadata. Img. For example, refer to S120.

Taking the example of the preload sub-partition, the Slot1 of the dynamic partition (Super) and/or the Super metadata includes the following:

Metadata version:10.2；

Metadata size:1300bytes；

Metadata max size:65536bytes；

Metadata slot count:3；

Header flags:virtual_abdevice；

Partition table:------------------------；

Name:preload_b；

Group:ry_dynamic_partitions_b；

Attributes:readonly,updated；

extensions 34072576. 37152768; the super_metadata. Img in the adaptation packet contains the following:

Name:preload；

Group:ry_dynamic_partitions；

extensions 17360896. 20441088; the device uses super_metadata. Img to refresh the content in Slot1 by locating the static partition (B) that is currently in need of upgrade to Slot1 of the dynamic partition (Super) of the corresponding static partition (B) for the static partition (B). Slot1 of dynamic partition (Super) and/or supermetadata contains the following:

Metadata version:10.2；

Metadata size:1300bytes；

Metadata max size:65536bytes；

Metadata slot count:3；

Header flags:virtual_ab_device；

Partition table:------------------------；

Name:preload_b；

Group:ry_dynamic_partitions_b；

Attributes:readonly,updated；

Extents:17360896..20441088；

s121, the Recovery process determines that the VC information in the oemiinfo sub-partition has been changed.

In some embodiments, the Recovery process detects whether the VC information in the oemiinfo sub-partition is changed, i.e., no longer is demo cn. In the case where it is determined that the change has been made, the flow advances to S122. And executing the VC information changing flow again under the condition that the VC information is not changed. For example, the vendor_count.mbn in the adaptation packet is written into the oemiinfo_vc file in the oemiinfo sub-partition to replace the original VC information.

S122, formatting the Userdata partition and restarting.

In some embodiments, the userdata partition needs to be reset, metadata partition and data partition formatting.

Therefore, the electronic equipment can support a remote hota upgrading mode, the switching from demonstration to business is realized, the recovery and delivery of a prototype are avoided, and the labor cost of brushing is saved.

As an implementation manner, taking an example of operating system upgrade of an electronic device running in the a system, the implementation process of the operating system upgrade method is as shown in fig. 11:

a1, the upgrade server issues a system upgrade package.

In some embodiments, the implementation details of the foregoing A1 may refer to S101, which is not described herein.

A2, the ouc apk acquires a system upgrade package, wherein the system upgrade package comprises a modified small package and VC information of a target version.

In some embodiments, the implementation details of the foregoing A2 may refer to S102, which is not described herein.

A3, the ouc apk triggers the update engine to enter the upgrading process.

In some embodiments, the implementation details of the foregoing A3 may refer to S103, which is not described herein.

And A4, updating the system upgrade package.

In some embodiments, the implementation details of the foregoing A4 may refer to S104, which is not described herein.

And A5, under the condition of running the A system, performing data writing operation on the static partition of the B system according to the system upgrading packet.

In some embodiments, the implementation details of the foregoing A4 may refer to S401, which is not described herein. In addition, under the scene of operating system upgrading aiming at the electronic equipment running in the B system, the update engine carries out data writing operation aiming at the static partition of the B system according to the system upgrading packet.

A6, creating a virtual dynamic partition in the user partition by the update engine.

And A7, writing the data for upgrading the dynamic partition in the system upgrade package into the virtual dynamic partition by the update engine.

In some embodiments, the implementation details of the foregoing A6 and A7 may refer to S402, which is not described herein.

A8, the update engine changes the identification indicating the static partition start of the system A into the identification indicating the static partition start of the system B.

In some embodiments, the update engine may rewrite the boot sequence identifier of the master boot record (Master Boot Record, MBR), e.g., rewrite the boot sequence identifier from a to B, so that after the electronic device is restarted, the data of the static partition (B) may be loaded, thereby switching to running the B system.

A9, the update engine determines that the system upgrade package comprises a remanufacturing small package.

In some embodiments, the implementation details of the foregoing A9 may refer to S106, which is not described herein.

A10, reading VC information of the target version from the system upgrade package by the update engine.

In some embodiments, the implementation details of the foregoing a10 may refer to S107, which is not described herein.

A11, the update engine writes the read VC information into oemiinfo_vc_tmp.

In some embodiments, the implementation details of the foregoing a11 may refer to S108, which is not described herein.

A12, the update engine decompresses the modified packet to the cache/update directory, wherein the modified packet comprises a pt able and super_metadata. Img.

In some embodiments, the implementation details of the foregoing a12 may refer to S109, which is not described herein.

A13, the update engine triggers the electronic equipment to restart.

In some embodiments, the implementation details of the foregoing a13 may refer to S110, which is not described herein. In addition, the electronic device may load the static partition of the B system after the restart is successful, and the flow goes to a14.

A14, triggering a merge flow by the update engine.

In some embodiments, the implementation details of the foregoing a14 may refer to S111, which is not described herein.

And A15, copying the static partition of the B system into the static partition of the A system by the update engine.

In some embodiments, the implementation details of the foregoing a15 may refer to S112, which is not described herein.

And A16, writing VC information in the oemifo_vc_tmp into the oemifo_vc file in the oemifo sub-partition by the update engine.

In some embodiments, the implementation details of the foregoing a16 may refer to S113, which is not described herein.

And A17, writing the storage address of the modified packet in the cache/recovery/command file under the condition that the update engine detects that the cache/update directory contains the modified packet.

In some embodiments, the implementation details of the foregoing a17 may refer to S114, which is not described herein.

A18, the update engine triggers a restart and indicates to enter a Recovery mode.

In some embodiments, the implementation details of the foregoing a18 may refer to S115, which is not described herein. In addition, the electronic device may start the Recovery process according to the information indicating to enter the Recovery mode, so the flow goes to a19.

A19, checking the integrity of the system upgrade package by the Recovery process.

In some embodiments, the implementation details of the foregoing a19 may refer to S116, which is not described herein.

A20, when the Recovery process inquires about the reform packet according to the cache/Recovery/command file, configuring a global variable vccdemo.

In some embodiments, the implementation details of the foregoing a20 may refer to S117, which is not described herein.

A21, under the condition that the variable vcdefmo is identified, the Recovery process migrates the preload data according to super_metadata. Img.

In some embodiments, the implementation details of the foregoing a21 may refer to S801 to S806, which are not described herein.

A22, updating the pt in the reform packet to the partition table in the Common by the Recovery process.

In some embodiments, the implementation details of the foregoing a22 may refer to S119, which is not described herein.

A23, the Recovery process updates the super_metadata. Img in the adaptation packet to the super header information.

In some embodiments, the implementation details of the foregoing a23 may refer to S120, which is not described herein.

A24, the Recovery process determines that the VC information in the oemiinfo sub-partition has been changed.

In some embodiments, the implementation details of the foregoing a24 may refer to S121, which is not described herein.

A25, formatting the Userdata partition by the Recovery process, and restarting.

In some embodiments, the implementation details of the foregoing a25 may refer to S122, which is not described herein.

The embodiment of the application also provides an electronic device, which may include: a memory and one or more processors. The memory is coupled to the processor. The memory is for storing computer program code, the computer program code comprising computer instructions. The computer instructions, when executed by a processor, cause the electronic device to perform the various steps of the embodiments described above. Of course, the electronic device includes, but is not limited to, the memory and one or more processors described above, such as shown in FIG. 3A.

The embodiment of the application also provides a chip system, which can be applied to the electronic equipment in the previous embodiment. As shown in fig. 12, the system-on-chip includes at least one processor 2201 and at least one interface circuit 2202. The processor 2201 may be a processor in an electronic device as described above. The processor 2201 and the interface circuit 2202 may be interconnected by wires. The processor 2201 may receive and execute computer instructions from the memory of the electronic device described above through the interface circuit 2202. The computer instructions, when executed by the processor 2201, may cause the electronic device to perform the various steps described in the embodiments above. Of course, the chip system may also include other discrete devices, which are not specifically limited in this embodiment of the present application.

In some embodiments, it will be clearly understood by those skilled in the art from the foregoing description of the embodiments, for convenience and brevity of description, only the division of the above functional modules is illustrated, and in practical application, the above functional allocation may be implemented by different functional modules, that is, the internal structure of the apparatus is divided into different functional modules to implement all or part of the functions described above. The specific working processes of the above-described systems, devices and units may refer to the corresponding processes in the foregoing method embodiments, which are not described herein.

The functional units in the embodiments of the present application may be integrated in one processing unit, or each unit may exist alone physically, or two or more units may be integrated in one unit. The integrated units may be implemented in hardware or in software functional units.

The integrated units, if implemented in the form of software functional units and sold or used as stand-alone products, may be stored in a computer readable storage medium. Based on such understanding, the technical solution of the embodiments of the present application may be essentially or a part contributing to the prior art or all or part of the technical solution may be embodied in the form of a software product stored in a storage medium, including several instructions to cause a computer device (which may be a personal computer, a server, or a network device, etc.) or a processor to perform all or part of the steps of the methods described in the embodiments of the present application. And the aforementioned storage medium includes: flash memory, removable hard disk, read-only memory, random access memory, magnetic or optical disk, and the like.

The foregoing is merely a specific implementation of the embodiments of the present application, but the protection scope of the embodiments of the present application is not limited thereto, and any changes or substitutions within the technical scope disclosed in the embodiments of the present application should be covered by the protection scope of the embodiments of the present application. Therefore, the protection scope of the embodiments of the present application shall be subject to the protection scope of the claims.

Claims

1. An operating system upgrading method is characterized by being applied to electronic equipment, wherein the electronic equipment comprises a memory, and the memory comprises a basic partition, a first static partition, a second static partition, a dynamic partition and a user data partition; the dynamic partition comprises a first sub-partition, a first partition table is stored in the dynamic partition, the first partition table comprises a first address, and the first address indicates a starting physical address of the first sub-partition in the memory; the electronic equipment comprises a first operating system and a second operating system, wherein the electronic equipment is provided with a starting sequence identifier, and after the electronic equipment operates, the data of the basic partition, the first static partition and the dynamic partition are loaded to start the first operating system; after the first operating system is started, the method comprises the following steps:

Acquiring a system upgrade package, wherein the system upgrade package is used for upgrading an operating system; the system upgrade package comprises first upgrade data, second upgrade data, a second partition table and a second standard file, wherein the second standard file comprises second standard information, and the second standard information is different from the first standard information; the second partition table comprises a second address, and the second address indicates a starting physical address of the first sub-partition in the memory after the upgrade is completed;

updating the system data in the second static partition to the first upgrade data;

modifying a start-up sequence identifier of the electronic device, wherein the modified start-up sequence identifier indicates start-up from the second static partition;

after the electronic equipment completes the first restart, updating the system data in the dynamic partition to the second upgrade data;

modifying the first system information into the second system information;

after the electronic equipment is restarted for the second time, entering a recovery mode;

in a recovery mode, migrating a starting physical address of first data from the first address to the second address; wherein the first data comprises data stored in the first sub-partition;

Modifying the first partition table to the second partition table.

2. The method of claim 1, wherein the first data further comprises second data in the dynamic partition, the second data being stored after the first sub-partition, a third partition table being stored in the base partition, the third partition table including a third address therein, the third address being used to indicate an ending physical address of the dynamic partition in the memory; the migrating the starting physical address of the first data from the first address to the second address includes:

reading the first data from between the first address and the third address;

writing the read first data into a blank storage area of the user data partition;

and after the writing is completed, writing the first data in the user data partition into the dynamic partition by taking the second address as a starting physical address.

3. The method of claim 1, wherein the second address is located after the first address.

4. A method according to claim 3, wherein a third partition table is stored in the base partition, the third partition table including a fourth address, the fourth address being used to indicate a starting physical address of the user data partition in the memory; the system upgrade package further comprises a fourth partition table, wherein the fourth partition table further comprises a fifth address, the fifth address is used for indicating a starting physical address of the user data partition in the memory after the upgrade is completed, and the fifth address is located before the fourth address; after migrating the starting physical address of the first data from the first address to the second address, the method further comprises:

And updating the third partition table by using the fourth partition table.

5. The method of any of claims 1-4, wherein after updating the first partition table with the second partition table, the method further comprises:

determining that the first system file already comprises the second system information;

formatting the user data partition.

6. The method of any of claims 1-4, wherein after updating the first partition table with the second partition table, the method further comprises:

determining that the first system file does not contain the second system information;

and reading the second system information again, and writing the second system information into the first system file to replace the first system information in the first system file.

7. The method of any of claims 1-4, wherein prior to the first reboot of the electronic device, the method further comprises:

after analyzing the system upgrade package, determining that the system upgrade package contains a remanufacturing small package; wherein the second partition table is compressed to the retrofit packet;

storing the second standard file in the basic partition in the form of a temporary file;

Decompressing the remodelled packet in a first storage area; the first storage area is a storage area accessible to the electronic equipment in the recovery mode;

before said migrating the starting physical address of the first data from the first address to the second address, the method further comprises:

and acquiring the second address from the second partition table in the first storage area.

8. The method of claim 7, wherein after entering the recovery mode, the method further comprises:

writing first indication information in a second storage area in a case where the retrofit packet is stored in the first storage area;

the migrating the starting physical address of the first data from the first address to the second address includes: after the first indication information is detected, the initial physical address of the first data is migrated from a first address to the second address.

9. The method of any of claims 1-4, wherein after updating the system data in the second static partition to the first upgrade data, the method further comprises:

creating a virtual partition in the user data partition; writing the second upgrade data into the virtual partition;

The updating the system data in the dynamic partition to the second upgrade data includes: and merging the second upgrade data in the virtual partition into the dynamic partition.

10. The method of any of claims 1-4, wherein after modifying the start-up sequence identification of the electronic device, the method further comprises:

loading data in the basic partition, the second static partition, the dynamic partition and the virtual partition in the first restarting process;

after the first reboot is completed, the data in the second static partition is mirrored to the first static partition.

11. An electronic device comprising one or more processors and memory; the memory being coupled to a processor, the memory being for storing computer program code comprising computer instructions which, when executed by one or more processors, are for performing the method of any of claims 1-10.

12. A computer storage medium comprising computer instructions which, when run on an electronic device, cause the electronic device to perform the method of any of claims 1-10.