CN115543368A - Operating system upgrading method and electronic equipment - Google Patents

Abstract

The application provides an operating system upgrading method and electronic equipment, and relates to the technical field of terminals. The problem of the reformation of the electronic equipment of the demonstration system is solved. The specific scheme is as follows: acquiring a system upgrade package; updating system data in the second static partition into first upgrading data; modifying a start sequence identifier of the electronic device, wherein the modified start 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 upgrading data; modifying the first system information into second system information; after the electronic equipment is restarted for the second time, entering a recovery mode; migrating a starting physical address of first data from a first address to a second address in a recovery mode; and modifying the first partition table into a second partition table. Therefore, remote upgrading can be supported, the switching from demonstration to commercial use is realized, sample machine recycling and delivery are avoided, and the labor cost for swiping the machine is saved.

Description

Operating system upgrading method and electronic equipment

The present application claims priority of chinese patent application entitled "a method for upgrading an operating system and an electronic device" filed by the national intellectual property office on 10/01/2022, with application number 202210023826.4, the entire contents of which are incorporated herein by reference.

Technical Field

The present application 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 the operating system to be available to the user. For example, a mobile phone operating system (e.g., an IOS system, an android system) needs to be installed on the mobile phone to be used by the user.

However, operating systems have different systems, and system partitions in different systems are different. For example, the model corresponding to the demonstration prototype is demo cn, the model corresponding to the commercial machine is all cn, the customized (version) sub-partition of the demonstration prototype is far larger than that of the commercial machine, and the difference is as high as 8G. After the mobile phone is sold, the demonstration model machine also needs to be sold for the user, and obviously, the conversion of the demonstration model machine to the commercial machine is very important.

Disclosure of Invention

The embodiment of the application provides an operating system upgrading method and electronic equipment, which are used for improving the man-machine refreshing efficiency of system change of the electronic equipment.

In a first aspect, an operating system upgrade 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, wherein a first partition table is stored in the dynamic partition, and the first partition table comprises a first address which indicates the initial physical address of the first sub-partition in the memory; the method comprises the steps that a first system file is stored in a basic partition, the first system file comprises first system 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 that the electronic equipment is started from a first static partition, and after the electronic equipment runs, data of the basic partition, the first static partition and a dynamic partition are loaded 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, 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 the initial physical address of the first sub-partition in the memory after the upgrade is finished; updating system data in the second static partition into first upgrading data; modifying a start sequence identifier of the electronic device, wherein the modified start 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 upgrading data; modifying the first system information into second system information; after the electronic equipment is restarted for the second time, entering a recovery mode; migrating a starting physical address of first data from a first address to a second address in a recovery mode; wherein the first data comprises data stored in the first sub-partition; and modifying the first partition table into a second partition table.

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

In the foregoing 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 system file, and the second system file is different from the first system file, the electronic device may change the system type of the electronic device by using the system upgrade package in an upgrade process, where such upgrade may be referred to as a re-system upgrade.

Illustratively, the first sub-partition may refer to a system sub-partition that is modified to initiate a physical address change. Taking the example of converting an electronic device into a commercial version, the first sub-partition may be a pre-installed sub-partition, and the pre-installed sub-partition is located behind the customized sub-partition. It will be appreciated that the custom subdivision for the demonstration prototype is of a different size than the custom subdivision for the commercial prototype. Thus, the location of the pre-installed subdivision of the demonstration prototype is different from the custom subdivision of the commercial prototype.

In the process of virtual AB upgrade of the electronic device based on the system upgrade package, the first system information may be replaced with the second system information, and in addition, in merge, that is, after the dynamic partition is updated by using the second upgrade data, the electronic device migrates the first data to the storage location. The first data includes data in a first subregion after merge. After the storage position of the first data is migrated, the starting physical address of the first data is the same as the second address in the second partition table, and the second address is the starting physical address of the first sub-partition in the electronic equipment in the commercial format. And then, changing the partition table indicating the initial physical address of the first sub-partition, namely modifying the first partition table into a second partition table. Therefore, in the automatic upgrading process, system change can be completed, return to a factory for refreshing is not needed, and the refreshing efficiency of system change of the electronic equipment is improved.

In some possible embodiments, the first data further includes second data in the dynamic partition, the second data is stored in the first sub-partition, a third partition table is stored in the base partition, and the third partition table includes a third address, and the third address is used to indicate an ending physical address of the current dynamic partition in the memory; migrating a starting physical address of first data from a first address to a 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 finished, 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 security of the system data is guaranteed, 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 maintained 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 the memory; the system upgrading packet further comprises a fourth partition table, the fourth partition table further comprises a fifth address, the fifth address is used for indicating the initial physical address of the user data partition in the memory after upgrading 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.

In the embodiment, the size of the user data partition can be increased, and the utilization rate of the storage space of the electronic equipment is 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; the user data partition is 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 include 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, the success rate of the remaking can be improved by detecting the system information.

In some possible embodiments, before the electronic device is restarted for the first time, the method further includes: after analyzing the system upgrade package, determining that the system upgrade package contains a remanufactured packet; wherein, the second partition table is compressed in the modified packet; storing the second standard file in the basic partition in the form of a temporary file; decompressing the reconstituted packet into the first storage area; the first storage area is a storage area which can be accessed by the electronic equipment in a recovery mode; prior to migrating the starting physical address of the first data from the first address to the second address, the method further includes: a 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 modified small packet in the first storage area; migrating a starting physical address of first data from a first address to a second address, comprising: after detecting the first indication information, migrating a starting physical address of the first data 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 into second upgrade data, comprising: and merging the second upgrading 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: loading data in the base partition, the second static partition, the dynamic partition and the virtual partition in the first restarting process; after the first reboot is completed, 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 coupled to the processor, the memory to store computer program code, the computer program code comprising computer instructions, which, when executed by the one or more processors, cause the one or more processors 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, 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 the initial physical address of the first sub-partition in the memory after upgrading is completed; updating system data in the second static partition into first upgrading data; modifying a start sequence identifier of the electronic device, wherein the modified start 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 upgrading data; modifying the first system information into second system information; after the electronic equipment is restarted for the second time, entering a recovery mode; migrating a starting physical address of first data from a first address to a second address in a recovery mode; wherein the first data comprises data stored in the first sub-partition; and modifying the first partition table into a second partition table.

In some possible embodiments, the first data further includes second data in the dynamic partition, the second data is stored in the first sub-partition, a third partition table is stored in the base partition, and the third partition table includes a third address, and the third address is 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 finished, 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, the second address is located after the first address.

In some possible embodiments, a third partition table is stored in the base partition, and the third partition table includes a fourth address, where the fourth address is used to indicate a starting physical address of the user data partition in the memory; the system upgrading packet further comprises a fourth partition table, the fourth partition table further comprises a fifth address, the fifth address is used for indicating the initial physical address of the user data partition in the memory after upgrading 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 to: and updating the third partition table by using 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; the user data partition is 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 comprise 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, prior to a first reboot of the electronic device, the one or more processors are further configured to: after analyzing the system upgrade package, determining that the system upgrade package contains a remanufactured packet; wherein, the second partition table is compressed in the modified packet; storing the second standard file in the basic partition in the form of a temporary file; decompressing the reconstituted packet into the first storage area; the first storage area is a storage area which can be accessed by the electronic equipment in a recovery mode; a 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 modified small packet in the first storage area; migrating a starting physical address of first data from a first address to a second address, comprising: after detecting the first indication information, migrating a starting physical address of the first data 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 to: creating a virtual partition in the user data partition; writing the second upgrade data into the virtual partition; and merging the second upgrading data in the virtual partition into the dynamic partition.

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

In a third aspect, a computer storage medium provided in an embodiment of the present application includes computer instructions, which, 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, which, when run on the above-mentioned electronic device, causes the electronic device to perform the method described in the above-mentioned first aspect and its possible embodiments.

It should be understood that the electronic device, the computer-readable storage medium, and the computer program product provided in the foregoing aspects are all applied to the corresponding method provided above, and therefore, the beneficial effects achieved by the electronic device, the computer-readable storage medium, and the computer program product can refer to the beneficial effects in the corresponding method provided above, and are not described herein again.

Drawings

Fig. 1 is an exemplary 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 a commercial machine provided by an embodiment of the present application;

fig. 3A is a diagram illustrating a structure of an electronic device according to an embodiment of the present disclosure;

fig. 3B is a flowchart of an operating system upgrading method according to an embodiment of the present disclosure;

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

fig. 5 is a flowchart of a process of executing 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 application;

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

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

fig. 9 is an exemplary diagram of changing a user data partition (Userdata) according to 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 application;

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

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

Detailed Description

In the following, the terms "first", "second" are used for descriptive purposes only and are not to be understood as indicating or implying relative importance or implicitly indicating the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of the present embodiment, "a plurality" means two or more unless otherwise specified.

Embodiments 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., an IOS system, an 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, and the like, to which an operating system can be installed. Exemplary embodiments of operating systems include, but are not limited to

Or other operating system.

Taking an android system adopting a virtual a/B operating system as an example, a data storage structure of an operating system in an 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).

Wherein the Common partition is a base partition that holds system data that does not participate in operating system upgrades. In some embodiments, at least one sub-partition may be included within the Common partition, for example, an oeminfo sub-partition or an nv sub-partition. The oeminfo sub-partition may be used to store system _ count (VC) information of an operating system, such as All cn, demo cn, cmcc cn, and the like. Wherein, all cn is used for indicating that universal Chinese system is configured, cmcc cn is used for indicating Chinese mobile Chinese system, demo cn is used for indicating demonstration machine system.

It can be understood that the electronic device needs to configure the corresponding VC information in the operating system according to the location and the difference of the accessed operators. For example, all cn is configured or cmcc cn is configured. In addition, the electronic device can configure corresponding VC information in the operating system according to different purposes. For example, demo cn can be configured for a demonstration prototype placed in a store, and All cn can be configured for an electronic device sold by a user.

Thus, during the operation of the electronic device, the operating system needs to be started. In the process of starting the operating system, the electronic equipment reads and loads the VC information in the Common partition, and the VC information can be written into the custom information (custom. Bin file) of the user data partition (user data) so as to be called in the process of running the operating system.

The user data partition (Userdata) is used for storing personal data of the user, such as personal data of APPs installed by the user, pictures, documents, videos and the like stored by the user.

The system partition is used for storing operating system data. Illustratively, 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 static partition (a) and the static partition (B) have structures corresponding to each other, and the child partition names are 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.

In the case of two static partitions, two operating systems, namely, an operating system a and an operating system B, can be virtualized in the electronic device. When the electronic device is started, the electronic device needs to run based on any operating system. Exemplarily, in the case that the electronic device needs to run based on the a operating system, the electronic device is started from the static partition (a): sequentially loading a basic partition (Common), a static partition (A) and a dynamic partition (Super); further illustratively, in a case where the electronic device needs to run based on the B operating system, the electronic device is started from the static partition (B): the basic partition (Common), the static partition (B) and the dynamic partition (Super) are loaded in sequence.

Take Universal Flash Storage (UFS) in Master Boot Record (MBR) format as an example. In the MBR of the UFS (main boot sector, first sector of the UFS, i.e. 0 cylinder 0 head 1 sector of the C/H/S address), an electronic device boot sequence description is saved, e.g. booted from the static partition (a) (boot sequence flag is a) or booted from the static partition (B) (boot sequence flag is a). After the electronic device is started, the electronic device starting sequence 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 sequentially loading the basic partition (Common), the static partition (a), and the dynamic partition (Super) or sequentially loading the basic partition (Common), the static partition (B), and the dynamic partition (Super) as described in the foregoing examples.

In addition, the dynamic partition (Super) may also include a plurality of sub-partitions, such as preas, preavs, systems, system _ ext, vendor, product, cut, ofdm, version, and preload.

It should be noted that the dynamic partition (Super) of the electronic device of the same type includes the same type of sub-sections, but in the case of the electronic device of the same type, the sizes of the sub-sections in the dynamic partition (Super) are different in different systems. For example, for a demonstration prototype (a device with VC information of demo cn), a version sub-partition, also called a version custom sub-partition, is needed for storing a large number of operation demonstration pieces, but a version in a commercial machine (a device with VC information of All cn or cmcc cn) is not needed. Thus, the version sub-partition and the preload sub-partition of the demonstration prototype and the commercial machine are different. For example, as shown in fig. 2, the version sub-partitions of the demonstration prototype and the commercial machine are different in size, and the start addresses of the preload sub-partitions are different. The preload subpartition is also referred to as the first subpartition. Additionally, the starting address may also be referred to as a starting physical address in memory.

Typically, after the new generation of electronic devices are marketed, demonstration prototypes for the previous generation of electronic devices also need to be sold to users. Due to the difference in dynamic partition structure, even if sold to users, the demonstration prototypes still need a system upgrade package for the demonstration prototypes. Therefore, after upgrading, the demonstration sample still exists in the version subarea of the demonstration prototype, however, the sold demonstration prototype does not need to store and operate the demonstration sample actually any more, but the space occupied by the corresponding version subarea is still large, and the utilization rate of the storage space is obviously influenced by unreasonable division of the storage area.

In order to solve the above problem, an embodiment of the present application provides an operating system upgrading method, which changes a format of a demonstration prototype and adjusts an operating system partition at the same time through one-time operating system upgrading for the demonstration prototype to be sold, so that the upgraded demonstration prototype has no difference from a commercial machine, the storage space utilization rate of equipment is improved, and the efficiency of upgrading the operating system is also increased.

In the following embodiments, demonstration prototypes to be sold may be collectively referred to as electronic devices. In a Common partition of an electronic device, VC information indicating a first system (demo cn) is included in an oeminfo sub-partition.

Please refer to fig. 3A, which is a schematic structural diagram of an electronic device 100 according to an embodiment of the present disclosure. As shown in fig. 3A, the electronic device 100 may include: the mobile terminal includes a processor 110, an external memory interface 120, an internal memory 121, a Universal Serial Bus (USB) interface 130, a charging management module 140, a power management module 141, a battery 142, an antenna 1, an antenna 2, a mobile communication module 150, a wireless communication module 160, an audio module 170, a speaker 170A, a receiver 170B, a microphone 170C, an earphone interface 170D, a sensor module 180, a button 190, a motor 191, an indicator 192, a camera 193, a display screen 194, a Subscriber Identity Module (SIM) card interface 195, and the like.

The sensor module 180 may include a pressure sensor, a gyroscope sensor, an air pressure sensor, a magnetic sensor, an acceleration sensor, a distance sensor, a proximity light 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 illustrated structure of the present embodiment does not constitute a specific limitation to the electronic apparatus 100. In other embodiments, electronic device 100 may include more or fewer components than shown, or combine certain components, or split certain components, or a different arrangement of components. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

Processor 110 may include one or more processing units, such as: the processor 110 may include an Application Processor (AP), a modem processor, a Graphics Processor (GPU), an Image Signal Processor (ISP), a controller, a memory, a video codec, a Digital Signal Processor (DSP), a baseband processor, and/or a neural-Network Processing Unit (NPU), among others. The different processing units may be separate devices or may be integrated into one or more processors.

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

A memory may also be provided in 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 have just been used or recycled by the processor 110. If the processor 110 needs to reuse the instruction or data, it can be called directly from memory. Avoiding repeated accesses reduces the latency of the processor 110, thereby increasing the efficiency of the system.

In some embodiments, processor 110 may include one or more interfaces. The interface may include an integrated circuit (I2C) interface, an integrated circuit built-in audio (I2S) interface, a Pulse Code Modulation (PCM) interface, a universal asynchronous receiver/transmitter (UART) interface, a Mobile Industry Processor Interface (MIPI), a general-purpose input/output (GPIO) interface, a Subscriber Identity Module (SIM) interface, and/or a Universal Serial Bus (USB) interface, etc.

It should be understood that the connection relationship between the modules illustrated in this embodiment is only an exemplary illustration, and does not limit the structure of the electronic device 100. In other embodiments, the electronic device 100 may also adopt different interface connection manners or a combination of multiple interface connection manners in the above embodiments.

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, the modem processor, the baseband processor, and the like. In some embodiments, antenna 1 of the electronic device is coupled with the mobile communication module 250 and antenna 2 is coupled with the wireless communication module 260, such that the electronic device can communicate with a network and other devices, such as a wearable device, through wireless communication techniques.

The antennas 1 and 2 are used for transmitting and receiving electromagnetic wave signals. Each antenna in an electronic device may be used to cover a single or multiple communication bands. Different antennas can also be multiplexed to improve the utilization of the antennas. For example: the antenna 1 may be multiplexed as 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 including 2G/3G/4G/5G wireless communication applied on the electronic device. The mobile communication module 250 may include at least one filter, a switch, a power amplifier, a Low Noise Amplifier (LNA), and the like. The mobile communication module 250 may receive the electromagnetic wave from the antenna 1, filter, amplify, etc. the received electromagnetic wave, and transmit the electromagnetic wave to the modem processor for demodulation.

The mobile communication module 250 may also amplify the signal modulated by the modem processor, and convert the signal into electromagnetic wave through the antenna 1 to radiate the electromagnetic wave. 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 disposed in the same device as at least some of the modules of the processor 210.

The wireless communication module 260 may provide a solution for wireless communication applied to an electronic device, including WLAN (e.g., wireless fidelity, wi-Fi) network, bluetooth (BT), global Navigation Satellite System (GNSS), frequency Modulation (FM), near Field Communication (NFC), infrared (IR), and the like.

The GNSS may include a beidou satellite navigation system (BDS), a Global Positioning System (GPS), a global navigation satellite system (GLONASS), a quasi-zenith satellite system (QZSS), and/or a Satellite Based Augmentation System (SBAS).

The wireless communication module 260 may be one or more devices integrating at least one communication processing module. The wireless communication module 260 receives electromagnetic waves via the antenna 2, performs frequency modulation and filtering processing on 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 and amplify the signal, and convert the signal into electromagnetic waves via the antenna 2 to radiate the electromagnetic waves.

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

The display screen 194 is used to display images, video, and the like. The display screen 194 includes a display panel. The display panel may adopt a Liquid Crystal Display (LCD), an organic light-emitting diode (OLED), an active-matrix organic light-emitting diode (active-matrix organic light-emitting diode, AMOLED), a flexible light-emitting diode (FLED), a miniature, a Micro-oeld, a quantum dot light-emitting diode (QLED), and the like.

The NPU is a neural-network (NN) computing processor, which processes input information quickly by referring to a biological neural network structure, for example, by referring to a transfer mode between neurons of a human brain, and can also learn by itself continuously. Applications such as intelligent recognition of the electronic device 100 can be realized through the NPU, for example: image recognition, face recognition, speech recognition, text understanding, and the like.

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 some functional modules of the audio module 170 may be disposed in the processor 110. The speaker 170A, also called a "horn", is used to convert the audio electrical signal into an acoustic signal. 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 converting the pressure signal into an electric signal. In some embodiments, the pressure sensor may be disposed on the display screen 194. The gyro sensor may be used to determine the motion pose of the electronic device 100. The magnitude and direction of gravity can be detected when the electronic device 100 is stationary. The method can also be used for recognizing the posture of the electronic equipment 100 and applied to horizontal and vertical screen switching and other applications. 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 applied thereto or nearby. The touch sensor may communicate the detected touch operation to the application processor to determine the touch event type.

With reference to the drawings, an operating system upgrade method provided by the embodiment of the present application is described below by taking the example that the electronic device adopts a virtual a/B operating system.

In some embodiments, the operating system upgrade 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) and the upgrade engine (update engine) are two modules in the operating system update program. The online update client apk is used for acquiring an upgrade installation package of the operating system, and the upgrade engine (update engine) is used for driving and executing the upgrade of the operating system.

FIG. 3B is a flowchart illustrating an operating system upgrade for the data storage structure of the operating system shown in FIG. 1. In a scenario that the electronic device is started from the static partition (a), that is, based on the a operating system running, the electronic device implements the upgrade of the operating system according to the flow shown in fig. 3B.

S101, the upgrading server issues a system upgrading package.

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

In addition, the system upgrade package comprises a remanufacturing small package. The modified packet is used for instructing to update the operating system of the electronic equipment from a first standard to a second standard (all cn or cmcc cn). The modified packet is used when the electronic device enters a Recovery (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；

tag is a remanufacturing label used for indicating that the system upgrade package can be used for remanufacturing a demonstration prototype into a commercial machine. The META-INF is signature information used for signature verification of the system upgrade package. Bin includes data that can upgrade an operating system to a target version. Txt is a FILE carrying parameters such as FILE _ HASH, FILE _ SIZE, and METADATA _ HASH. Mbn is a SOFTWARE version file. The VC information (e.g., all cn) of the target version is saved in the root directory of the system upgrade package in the form of a vendor _ count. Zip is a modified packet.

Illustratively, the data structure of the modified packet, i.e., update _ base _ removal.

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, and is used for describing partition deployment of a storage device (ROM) after upgrading to the target version. The starting address and size of each partition is defined. Illustratively, ptable includes a start address and an end address in memory space for a Common partition, a system partition, and a user data partition (Userdata). For example as shown in table 1 below:

TABLE 1

The Image includes a super _ metadata.img, which is a super sub-partition table corresponding to the target version and is used for describing the start address and the end address of each sub-partition in the super after the upgrade to the target version. The modified packet also includes META-INF, which is also used for signature verification. The VC information (e.g., all cn) of the target version may also be saved in the root directory of the modified packet in the form of a vendor _ count.

In addition, the modified packet can also comprise empty mirror images such as user data.

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 before the electronic device is started. In the state where the electronic device is started from the static partition (a), the online update client apk executes S102.

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

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

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

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

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

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

That is, the online update client apk executes S103, and triggers the update engine to enter the upgrade process.

As an example, after the online update client apk acquires the system upgrade package, the online update client apk sets a start attribute of an upgrade engine (update engine), and sets the start attribute to true. The service servicemanager resident in the operating system background monitors the start attribute of the upgrade engine (update engine), and starts the upgrade engine (update engine) when the servicemanager detects that the start attribute of the upgrade engine (update engine) is true.

The online update client apk acquires the state of an upgrade engine (update engine) through binder communication, and when the online update client apk confirms that the upgrade engine (update engine) is successfully started, the online update client apk transmits an upgrade parameter (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 process.

In the upgrading process, update engine executes S104 to check the operating system upgrading packet.

Illustratively, the META-INF (i.e., the digital signature) in the system upgrade package may be checked to determine whether the system upgrade package is legal. For details of implementation, reference may be made to related technologies, which are not described herein again.

If the verification is successful, update engine executes S105, and if the system a is running, based on the system upgrade package, upgrade for the system B is started.

In some embodiments, upgrading the B-system (also referred to as a second operating system) of the electronic device is part of a virtual A/B upgrade process. In other words, when the electronic device runs the a system (also referred to as the first operating system), the step S105 may also start the virtual a/B upgrade process.

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 equipment reads the stored system upgrading packet from the user data partition (Userdata), and performs data writing operation on the static partition (B) according to the system upgrading packet to upgrade the static partition.

For example, the data of the static partition of version 1.2, also called the first upgrade data, is included in the system upgrade package, 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 upgrading packet, and writes upgrading data of a dynamic partition (Super) into the virtual dynamic partition.

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

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

For example, a system incremental upgrade installation package with version 1.1 upgraded to version 1.2 contains dynamic partition (Super) update data with version 1.1 upgraded to version 1.2, which contains data system3.

Further, in the virtual a/B upgrade scheme, incremental upgrade of dynamic partitions (Super) is implemented based on snapshot technology (snapshot). Specifically, in a virtual dynamic partition of a user data partition (Userdata), a Copy-On-Write (COW) file is used to store upgrade data of a dynamic partition (Super).

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).

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) child partition to which it is directed. For example, the COW file for a system child 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 a/B partition flags 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 on 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 flag _ 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.0000 to attach _ 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 into a user data partition (Userdata), an 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 sub-partition of the dynamic partition (Super) to which the COW file is directed. The file map of the sub-partition of the dynamic partition (Super) is used for describing all files in the sub-partition of the dynamic partition (Super) and saving addresses of the files of the operating system of the current version (the version before the upgrade, for example, version 1.1).

Updating data in the COW file into a file updated in the sub-partition data of the new version compared with the sub-partition data of the current version; and the COW map of the COW file is used for describing the corresponding relation between the updated file and the file 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 upgrade data in the COW file can be used for replacing the corresponding file in the sub-partition of the dynamic partition (Super), so that the upgrade of the data of the dynamic partition (Super) is realized. Specifically, when the file map of the sub-partition of the dynamic partition (Super) needs to be obtained, 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). Or 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 a system sub-partition as an example, suppose that the system sub-partition stores data 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 a 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 following the file name (e.g., "/system/app/A0.XXX: 024010-024013") is the physical storage address (block address) of the file in the system sub-partition of the dynamic partition (Super).

Assume that the current operating system upgrade requires updating data/system/app/A2. XXX and/system/user/C2. XXX.

Can be regarded as:

system/app/A2.XXX and system/user/C2.XXX are system1 parts of 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 the system2 portions of system sub-partition data.

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

It can be seen that the latest version/system/app/A2. XXX and/system/user/C2. XXX is system3. The upgrade target is to update system1 with 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 location of the update data in the COW file in the child partition after the data update is consistent with the storage location of the original data to be updated in the child 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): start address start:024018 (offset from system start address); offset size:2 (namely the data of 024018-024020 address field)

Map2 (address of update data stored in cow file): start address start:045033 (offset from the start address of the cow file storage); offset size:2 (i.e., data for address fields 045033 to 045035);

/system/user/C2.XXX：

map1 (address of data to be updated in original super partition): start address start:024036 (offset from system start address); offset size:4 (namely the data of 024036-024040 address segment)

Map2 (address of update data stored in cow file): start address start:045036 (offset from the start address of the cow file storage); offset size:4 (i.e., data in the 045036 to 045040 address fields).

When the size of the update data in the COW file is not consistent 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): start address start:024018 (offset from system start address); offset size:2 (namely the data of 024018-024020 address field)

Map2.1 (the address of the update data stored in the cow file that needs to cover the Map1.1 address): start address start:045033 (offset from the start address of the cow file storage); offset size:2 (i.e., data for address fields 045033 to 045035);

map1.2 (address to be written in the original super partition of the part of the update data in the cow file exceeding the size of the data to be updated): start address start:025018 (offset from system start address); offset size:1 (i.e. data of 025018-025020 address field)

Map2.2 (the address of the update data stored in the cow file that needs to cover the Map1.2 address): start address start:046033 (offset from the start address of the cow file storage); offset size:2 (i.e., data in address fields 046033-046035).

In the description of the specification that follows, for convenience of description, an application scenario will be illustrated only when the size of the update data in the COW file coincides with the size of the original data to be updated, and the storage location of the update data in the COW file after data update in the sub-partition coincides with the storage location of the original data to be updated in the sub-partition.

In the above example, the address fields (045033 to 045035 and 045036 to 045040) are the physical storage addresses (block addresses) of the latest version of/system/app/a 2.Xxx and/system/user/c 2.Xxx in the user data partition (Userdata), respectively, in the COW file (system _ b-COW-img.img.0000).

Thus, if A2.XXX at addresses 024018-024020 is replaced by A2.XXX at addresses 045033-045035, and C2.XXX at addresses 024036-024040 is replaced by C2.XXX at addresses 045036-045040, the data upgrade of the system sub-partition of dynamic partition (Super) can be completed.

Further, in S402, after the COW file is written into the user data partition (Userdata), the dynamic partition (Super) + COW file needs to be integrally checked, the validity of the dynamic partition (Super) + COW file is checked, and whether the synthesis result of the current version of the dynamic partition (Super) data + the COW file is the new version of the dynamic partition (Super) data is verified.

In some examples, taking upgrading from version 1.1 to version 1.2 as an example, calculating a hash value of a composite result of data (data which is unchanged 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 a hash value of complete data of the dynamic partition (Super) in version 1.2, and if so, indicating that the COW file is valid; if the COW file is inconsistent with the update file, indicating that the COW file is invalid and upgrading fails, and interrupting the process corresponding to the update engine and reporting an error; wherein, the hash value of the complete data of the dynamic partition (Super) in the 1.2 version is stored in the system upgrade package.

Specifically, in the checking process, dynamic partitions (Super) + COW files are merged based on snapshot. In the realization process of snapshot, the combination of the dynamic partition (Super) and the COW file is not the combination in the physical sense, but the whole file map of the sub-partition in the COW file and the COW file map of the COW file are combined to generate the file map of the new version of the sub-partition data.

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

/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 COW file map:

/system/app/A2.XXX：

map1: address start:024018; size:2 (namely the data of 024018-024020 address field)

Map2: address start:045033; size:2 (i.e., data for address fields 045033 to 045035);

/system/user/C2.XXX：

map1: address start:024036; size:4 (namely the data of 024036-024040 address segment)

Map2: address start:045036; size:4 (i.e., data in the address fields 045036-045040).

And (6) merging. Then get the new version of the file map for the system sub-partition:

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

(Direction to dynamic partitioning (Super) in/under System/app A0.XXX)

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

(Direction to dynamic partitioning (Super) in/under System/app A1.XXX)

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

(points to A2.XXX in user data partition (Userdata)/Update/system _ b-cow-img.img.0000)

/system/B0.XXX：024021～024026；

(Direction dynamic partitioning (Super) Medium/under system B0.XXX)

/system/B1.XXX：024027～024028；

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

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

(C0.XXX in directed dynamic partitioning (Super) in/under system/user)

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

(Direction dynamic partitioning (Super) Medium/System/user under C1.XXX)

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

(pointing to C2.XXX in user data partition (Userdata)/Update/system _ b-cow-img.img.0000)

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

(C3.XXX under Directional dynamic partitioning (Super) Medium/System/user)

In the file map of the new version of the system sub-partition, the save address of/system/app/A2. XXX points not to/system/app/A2. XXX on the dynamic partition on memory (Super), but to A2.XXX in system _ b-cow-img.img.0000 in the user data partition on memory (Userdata); the save address of/system/user/C2. XXX does not point to/system/user/C2. XXX on the dynamic partition (Super) on memory, but to C2.XXX in system _ b-cow-img.img.0000 in the user data partition (Userdata) on memory.

In the verification process, according to the synthesis mode, obtaining new version file maps of all sub-partitions of the dynamic partition (Super) (if the corresponding COW file of a certain sub-partition is not written in the user data partition (user data), directly taking the file map of the sub-partition as the new version file map). And combining the new versions of the file maps of all the sub partitions to generate a new version of a file system of a dynamic partition (Super).

And reading data based on the file system of the new version of the dynamic partition (Super), reading all files contained in the file system of the new version of the dynamic partition (Super) and calculating a hash value.

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

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

Illustratively, an MBR is included in the Common partition of the electronic device, and the MBR is configured with a boot order identifier. When the electronic device starts the operating system, the starting sequence identifier may be read from the MBR, and the static partition (static partition a or static partition B) to be loaded is determined according to the moving sequence identifier, that is, whether the system a is started or the system B is started is determined. The above 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 data of the static partition (B) may be loaded, and the electronic device may be switched to run the system B. 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 MBRs in the two static partitions are the same.

And S403, restarting the electronic equipment.

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

S404, the electronic device loads the basic partition (Common) and the static partition (B) in sequence.

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

For example, before the electronic device is restarted, the Boot sequence identifier of a Master Boot Record (MBR) is rewritten, and the Boot sequence identifier is rewritten from a to B. After the electronic equipment is powered on, 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; and when the electronic equipment reads that the starting sequence identifier is 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 the base partition (Common). During loading of the base partition (Common), the electronic device reads the start-up flag in the base partition (Common); when the boot flag (a) in the base partition (Common) is set to (a), the electronic device loads the static partition (a) after loading the base partition (Common) and thus boots from the static partition (a); when the boot flag in the base partition (Common) is (B), the electronic device loads the static partition (B) after loading the base partition (Common) and thus boots from the static partition (B).

In S404, the electronic device reads the start flag in the base partition (Common). The boot flag in the base partition (Common) is (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 equipment loads the dynamic partition (Super) and the virtual dynamic partition of the user data partition (Userdata).

Specifically, the electronic device reads the landing state information in the metadata (/ metadata), determines whether a COW file needs to be retrieved from a specified path of a user data partition (Userdata) or not based on the landing state information, and loads a dynamic partition (Super) and the COW file by using snapshot merging.

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

Specifically, in S405, when the corresponding COW file first exists in the sub-partition 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 a new version of the file map may refer to S402. The electronic equipment determines files needing to be loaded according to the operation requirements of an operating system, and loads the files based on a new version file map of a dynamic partition (Super) sub-partition.

For example, an operating system runtime requirement loads all data in a directory user (/ system/user) under a system sub-partition. The electronic device reads the disk-dropping status information in the metadata (/ metadata), wherein the sub-partition of the system sub-partition is identified as 'not-dropped for merge' in the disk-dropping status information, so that the electronic device searches the COW file in the user data partition (Userdata)/Update under the Update, searches the COW file system _ b-COW-img.img.0000 under the Update, and 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 based on the snapshot. And loading data according to the storage addresses of all files in the new version file map of the system sub-partition/under the system/user, for example, according to the storage addresses of all files in the new version file map 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 the addresses 024029-024032, C1.XXX at the addresses 024033-024035, C2.XXX at the addresses 045036-045040, and C3.XXX at the addresses 024041-024044 are loaded.

In some 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 is identified as "landed" in the landing status information, the electronic device does not search for 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 user (/ system/user) under the system sub-partition is loaded, when the sub-partition of the system sub-partition in the landing state information is identified as "not landing for mean", if the electronic device does not search the COW file of the corresponding system sub-partition in the user data partition (user data)/under Update, it indicates that a data write error (a COW file write error or a landing state information write error) occurs during the upgrade process, and the electronic device rolls back the system and reports an 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 files are not verified in their entirety, but only files that need to be loaded are verified. For example, the verification is performed based on dmverity (dm-verity is a target (target) of dm (device map), which is a virtual block device, dedicated to the verification of the file system). And if the verification is successful, loading the file, and if the verification is failed, restarting the equipment, rolling back the system or trying to load the file again.

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

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

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

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

S106, the update engine detects that the system upgrade package contains the modified small package.

In some embodiments, update engine detects a package name of a modified package from a system upgrade package, such as update base remove zip, and may determine that a modified package is detected. In other embodiments, the update engine detects a modified tag, such as demochange tag, from the system upgrade package and may determine that a modified packet 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.

S108, update engine writes the read VC information into oeminfo _ VC _ tmp.

In some embodiments, the oeminfo _ vc _ tmp is a temporary file in the oeminfo sub-partition, occupying temporary storage space in the oeminfo sub-partition. oeminfo _ vc _ tmp is different from the oeminfo _ vc file in the oeminfo sub-partition. The oeminfo _ VC file includes VC information (e.g., VC information of version 1.1) before system upgrade. It will be appreciated that the oeminfo _ vc _ tmp differs from the oeminfo _ vc file in the physical address actually occupied in the oeminfo sub-partition. In addition, the storage address corresponding to the oeminfo _ VC file is an address for the electronic device to load VC information. Thus, when the electronic device loads system data, the oeminfo _ vc file is loaded, but the oeminfo _ vc _ tmp is not loaded.

In addition, it is understood that the above S108 is only an example way of temporarily storing the VC information of the target version in the system upgrade package, and other implementations may also exist, for example, writing the VC information of the target version into another temporary storage area that can be read, and the like. The embodiments of the present application do not limit this.

S109, the update engine decompresses the modified packet to the cache/update directory, and the modified packet comprises ptable and super _ metadata.

In some embodiments, the cache/update directory is a directory under a cache sub-partition, also referred to as a first storage area, the cache sub-partition belonging to a Common partition. In addition, the cache sub-partition is a storage partition which can be accessed in Recovery mode. After decompressing the modified packet into the cache/update directory, the cache/update directory includes the ptable and super _ metadata.

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

In some embodiments, exiting the current operating system, turning off the device power, and turning on the device power again, S110 is the same step as S403, which is also called a first reboot. In the case where the restart is successful, the electronic device performs S404 and S405. After S405 is executed, in the case where it is determined that the tray is currently in the not-dropped-tray state, the flow then proceeds to S111.

S111, the update engine triggers merge process.

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

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

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

That is, the electronic device drops the data of the virtual dynamic partition to the dynamic partition (Super) in the background. In this embodiment of the present application, the disk-dropping operation refers to writing 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) in an upgrade process of an operating system, 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 the electronic device can be started only by loading the dynamic partition (Super).

In some examples, the electronic device performs a power-on broadcast after the start is successful, and starts a process corresponding to the update engine after the power-on broadcast. The process corresponding to the update engine reads the disk-down status information in the metadata (/ metadata) of the base partition (Common), and if the disk-down status information is "logged down", the device enters a normal operation mode.

If the disk-dropping status information is "not dropped for merge", the process corresponding to 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 upgraded new version of data.

For example,/system/app/a 2.xxx in a file map based on system sub-partitions: 024018 to 024020, and/system/app/A2.XXX in COW file map: 045033 to 045035, writing the data at 045033 to 045035 to 024017; system/user/c2.Xxx in system sub-partition based file map: 024036-024040, and/system/user/C2.XXX in COW file map: 045036 to 045040, the data at the addresses 045036 to 045040 are written into the addresses 024036 to 024040.

After that, the process corresponding to the update engine deletes the COW file in the user data partition (Userdata), and returns the storage space to the user data partition (Userdata); and, the disk-drop status information in the metadata (/ metadata) of the base partition (Common) is changed from "not disk-dropped (wait for merge)" to "dropped (merged)".

In S401, the data operation of the static partition upgrade is directed to the operating system data in the static partition (B), which does not affect the operating system data of the currently started static partition (a); in S402, the data operation of the dynamic partition upgrade is performed 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 process of upgrading the operating system, the user can normally use the equipment; moreover, after S402 is completed, the device does not need to be restarted immediately, and a restart time may be selected by the user; therefore, the upgrading process of the operating system does not influence the normal mobile phone operation of the user, and the user experience is greatly improved. Therefore, aiming at the dynamic partition (Super), the virtual dynamic partition is created on the user data partition (Userdata) only when the dynamic partition needs to be upgraded, and therefore the utilization rate of the data storage space is effectively improved.

In some embodiments, after the merge process is finished, the space occupied by the data in the version customization sub-partition of the super partition is reduced, and at the same time, the location of the preload sub-partition is unchanged, at this time, a free space (a storage space that cannot be actually used) is formed between the version and the preload, the merge is finished, the data structure of the operating system is as shown in fig. 6, the start address of the version sub-partition is unchanged, the end address is reduced, and thus, the physical storage space occupied by the version sub-partition is reduced. The start and end addresses of the Preload subpartition are unchanged, so that an idle physical memory region (i.e., free space) exists between the version subpartition and the Preload subpartition.

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

In some embodiments, the above S112 is only an example of a manner of updating the static partition (a), and in this embodiment, there may be other possible implementations, for example, the update engine may update data in the static partition (a) by using a system upgrade package, which is not specifically limited in this embodiment.

S113, the update engine writes the VC information in the oeminfo _ VC _ tmp into an oeminfo _ VC file in an oeminfo sub-partition.

In some embodiments, the VC information stored in the oeminfo _ VC _ tmp is a target version of VC information (e.g., all cn) read from the system upgrade package, and the VC information is different from the original VC information (i.e., demo cn, also referred to as first-system information) in the electronic device, that is, the VC information in the oeminfo _ VC _ tmp is different from the VC information recorded in the oeminfo _ VC file. The oeminfo _ vc file may be referred to as a first-format file. In this way, after the VC information (e.g., all cn) of the target version is written into the oeminfo _ VC file, the original VC information (i.e., demo cn) in the oeminfo _ VC file may be overwritten, thereby implementing the change of the system information. The above process is also called modifying the first system information into the second system information.

In addition, the oeminfo sub-partition belongs to a Common partition, and in the process of starting the operating system, VC information needs to be read from an oeminfo _ VC file of the oeminfo sub-partition. Therefore, the system change of the electronic equipment can be realized by changing the VC information in the oeminfo _ VC file.

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

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

s114, writing data indicating the upgrading and the upgrading in the cache/recovery/command file under the condition that the update engine detects that the cache/update directory comprises the upgrading small packet.

For example, the data indicating the modified upgrade may be information indicating a modified packet storage path, e.g., in the case where the modified packet is stored in the cache/update directory, the information indicating the modified packet storage path may be "update _ packet =/cache/update/update _ base _ removal. Therefore, after the electronic equipment enters the Recovery mode, the modified packet can be searched according to the storage path.

In other embodiments, the modified packet may be obtained after entering the Recovery mode in other manners, for example, the modified packet may also be obtained when it is detected that the cache/update directory includes the modified packet, that is, after it is detected that the cache/update directory includes the modified packet, the modified packet is moved to the cache/Recovery directory.

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

In some embodiments, the restart is also referred to as a second restart, and after the Recovery mode is indicated to be entered, the Recovery process is enabled, and the process proceeds to S116.

S116, the Recovery process checks the integrity of the system upgrade package.

In some embodiments, the above S116 refers to an implementation manner of verifying the integrity of the upgrade package in the related art, and is not described herein again.

And S117, configuring a global variable vcdemo by the Recovery process when the current scene is the modified and upgraded scene according to the cache/Recovery/command file.

In some embodiments, the Recovery process may parse a 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. And under the condition 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 predefined restructuring small packet name, determining that the current restructuring upgrading scene is present. For another example, if it is determined that the identifier indicating the remanufacturing exists in the data packet, it may be determined that the upgrade scenario is currently remanufactured.

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

It can be understood that configuring the global variable vcdemo indicates that the upgrade is a remanufacturing upgrade, which is only one implementation manner. In other embodiments, the Recovery process may be prompted to execute the subsequent process of the modification and upgrade in other manners, for example, the electronic device actively queries whether there is a modified packet in the cache/update directory.

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

In some embodiments, the preload data is data stored in a preload child partition after the merge process is completed. The principle of the above-mentioned preload data migration is shown in fig. 7: the electronic equipment copies the data in the preload sub-partition and the tail data of the super partition to the tail of the userdata partition. The trailer data of the super partition refers to data stored after the preload sub-partition, for example, the 3M trailer data labeled in fig. 7. 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, the super _ metadata.img in the modified packet, also called the second partition table, may be obtained first. The indicated start address (also called second address) of the preload subpartition is obtained from the super _ metadata. It will be appreciated that the start address of the preload sub-partition in the super _ metadata.img is the same as the start address of the free space, i.e., adjacent to the end address of the version custom sub-partition after merge, so that the free space in the super partition can be utilized.

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

s801, reading super header information from the super partition by the Recovery process.

In some embodiments, the above-mentioned super header information may be stored in the memory 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, and the first partition table includes a first address indicating a starting physical address of the first sub-partition in the memory. For example, before merge, the super header indicates the start address and size data of the version and preload child partitions, as follows:

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

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

that is, before merge, the start address of the version subpartition is "physical address 17295360", the end address is "physical address 34072576", and the size of the version subpartition is 16777216sectors, that is, the version subpartition occupies about 8-9G of storage space. The start address of the preload subpartition is "physical address 34072576", the end address is "physical address 37152768", and the size of the version subpartition is 3080192sectors.

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

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

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

as can be seen, after merge, the start address of the version subpartition is "physical address 17295360", the end address is "physical address 17360896", and the size of the version subpartition is 65536sectors. The start address of the preload subpartition is "physical address 34072576", the end address is "physical address 37152768", and the size of the version subpartition is 3080192sectors.

Obviously, between the version sub-partition and the preload sub-partition, there is free space, i.e., storage space between physical address 17360896 and physical address 34072576. This free space cannot be used practically.

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

In the above example, the size (size) of the preload data may be 3080192sectors, and the current location attribute (currentpos) may be 34072576. That is, the preload data is read from the physical address 34072576 to the size 3080192sectors.

S803, the Recovery process reads the preload data from the super partition according to the size and currentpos 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, it may be memory space that writes the preload data to the end of the userdata partition.

S805, the Recovery process reads the target location (dstpos) from the super _ metadata.

In some examples, the target location (dstpos) is a starting address of a preload partition to which the target version corresponds. It is understood that the above-mentioned super _ metadata.img records information such as the start address and size of each partition after the version modification.

For example, the data of the start address and size of the version sub-partition and the preload sub-partition in super _ metadata.

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

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

Thus, the target location (dstpos) read from super _ metadata.img may be physical address 17360896.

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

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

In addition, in addition to requiring migration of the preload 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 is to be understood that the tail data of the super partition is data stored in the super partition after the preload data. For the purpose of aspect description, the preload data and the trailer data of the super partition may be referred to as data 1 or first data. Illustratively, when the Recovery process determines that the tail space located after the preload sub-partition in the super partition further includes data of 3M size, after reading the preload data, the reading of the data of 3M size is continued with the end address of the preload sub-partition as a starting point, so that data 1 can be read. Then, the read data 1 is written into a blank area in the userdata partition, and then the data 1 in the userdata partition is written into the super partition again by taking the target position (dstpos) as a starting address.

Alternatively, after the location attribute (currentpos) of the preload sub-partition is resolved, such as called address a or the first address, the ending address (also called ending physical address) of the super partition is resolved from the partition table (also called the third partition table) of the Common partition, such as called address b or the third address. 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 a starting point. S119, the Recovery process updates the partition table in Common by using ptable in the modified small packet.

In some embodiments, the above ptable includes a start address and an end address of a Common partition, a system partition and a user data partition (Userdata) in the storage space in the target version, and is also referred to as a fourth partition table, and 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 includes a partition table, such as referred to as partition table a or referred to as a third partition table, where the partition table a can be used to indicate the starting address (also referred to as a fourth address) and the ending address of the Common partition, the system partition, and the user data partition (Userdata) of the electronic device in the storage space after merge. Wherein, the above ptable indicates a smaller system partition compared to the partition table a, i.e. the fifth address precedes the fourth address.

Understandably, after S111, that is, after the electronic device passes through merge, a free space may occur between the version sub-partition and the preload sub-partition, and then, after migrating the preload data and the tail data of the super-partition, a free space may occur at the tail of the super-partition. At this time, the space left free at the tail of the super partition can be divided into user data partitions (Userdata) by ptable instead of the partition table a in Common, as shown in fig. 9. Before that, the storage positions of the preload data all move forward, and the electronic device can normally load the system data according to the partition table updated in Common, that is, under the condition that the system data is not influenced, user data partitions (Userdata) which can be dominated by a user are increased, and the use experience of the user is improved.

At least one of the first and second electrodes is S120, the Recovery process updates the super _ metadata.img in the modified small packet to the super header information.

In some embodiments, header information, also referred to as super header information, is stored in the header storage area (the storage space indicated by 1MB in fig. 9, also referred to as a super _ metadata partition) of the super partition. 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 is moved forward, and the super _ metadata. This means that the start of the preload partition moves up as the version custom child partition needs to shrink after upgrading to the target version. It is understood that the version custom sub-partition size recorded in the super _ metadata.img is a reduced size, and the start position of the preload partition is also an address shifted up, so that the electronic device writes the super _ metadata.img into the super header information, and after replacing the atomic partition table, the electronic device can normally load the data in the preload partition after starting the operating system.

In the previous example, before the super _ metadata.img is updated to the super header information, the super header information records: the start address of the version subpartition is 'physical address 17295360', and the end address is 'physical address 17360896'; the starting address of the preload subpartition is "physical address 34072576" and the ending address is "physical address 37152768".

After super _ metadata.img is updated to the super header information, the super header information records therein: the start address of the version subpartition is 'physical address 17295360', and the end address is 'physical address 17360896'; the starting address of the preload subpartition is "physical address 17360896" and the ending address is "physical address 20441088". In this way, the electronic device can also accurately read the data after the preload data is advanced.

As an example, as shown in fig. 10, in an android system adopting a virtual a/B upgrade mode, only a static partition adopts an a/B scheme, and a dynamic partition adopts a scheme of constructing a virtual dynamic partition when upgrading. Therefore, for matching the static partition and the dynamic partition, the Super header information, also called metadata (/ Super data) of the header of the dynamic partition (Super), includes Slot0 (Slot one data) of the corresponding static partition (a) and Slot1 (Slot two data) of the static partition (B). Slot0 and Slot1 are used for storing the partition table of the Super partition.

For example, in the MBR of UFS, the device boot sequence is described in which 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 different static partitions started, selecting to obtain the partition information of the Super partition from one of the Slot0 or the Slot1. For example, when the device is started by the static partition a, when the Super partition is loaded, the device first reads Slot0 to obtain the sub-partition address of the Super partition; when a device is started by the static partition B, when the Super partition is loaded, the device first reads Slot1 to obtain the sub-partition address of the Super partition.

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

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

a Group (Group) entry, the value of which is a sub-partition type;

attribute (Attributes) entries whose values are partition read-write Attributes, e.g., read-only attribute (readonly);

address (extensions) entries, 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 static partition (A) is corresponded; the suffix of the value is B, which corresponds to the static partition (B).

When the Super partition is loaded, initiated by static partition A, slot0 is first read. When the Slot0 is read, the device reads the value of an extensions item in a partition description Group with the suffix of _ a in the Name item and/or the Group item in the Slot0 to obtain the sub-partition address of the Super partition, because the suffix of _ a corresponds to the static partition (a).

When the Super partition is loaded, initiated by static partition B, slot1 is first read. When the Slot1 is read, the device reads the value of an extensions item in a partition description Group with the suffix of _ B in the Name item and/or the Group item in the Slot0 to obtain the sub-partition address of the Super partition, because the suffix of _ B corresponds to the static partition (B).

The customized packet includes partition information of a dynamic partition (Super) of the target version, that is, super _ metadata. For example, refer to S120.

Taking the preload sub-partition as an example, slot1 of the dynamic partition (Super)/supermetadata comprises the following contents:

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; super _ metadata.img in the modified packet contains the following:

Name:preload；

Group:ry_dynamic_partitions；

extensions 17360896..20441088; the device locates the static partition (B) to the Slot1 of the dynamic partition (Super)/Super metadata of the dynamic partition (Super) corresponding to the static partition (B) through the static partition which needs upgrading currently, and refreshes the content in the Slot1 by using Super _ metadata. Slot1 of dynamic partition (Super)/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 VC information in the oeminfo sub-partition is changed.

In some embodiments, the Recovery process detects whether the VC information in the oeminfo sub-partition has changed, i.e., is no longer demo cn. In the case where it is determined that the change has been made, the flow proceeds to S122. When the VC is determined not to be changed, the VC information change flow is executed again. For example, the vector _ count. Mbn in the modified packet is written into the oeminfo _ VC file in the oeminfo sub-partition, instead of the original VC information.

And S122, formatting the Userdata partition and restarting.

In some embodiments, the userdata partition requires a reset, the metadata partition and the data partition formatting.

Therefore, the electronic equipment can support a remote hota upgrading mode, the switching from demonstration to commercial use is realized, sample machine recycling and delivery are avoided, and the labor cost for swiping a machine is saved.

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

a1, the upgrade server issues a system upgrade package.

In some embodiments, reference may be made to S101 for details of implementing the above-mentioned A1, which are not described herein again.

A2, obtaining a system upgrade package by the ouc apk, wherein the system upgrade package comprises a remodeled small package and VC information of a target version.

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

A3, triggering update engine to enter an upgrading process by the ouc apk.

In some embodiments, reference may be made to S103 for details of implementing A3 described above, which are not described herein again.

And A4, verifying the system upgrading package by the update engine.

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

And A5, under the condition that the update engine runs the system A, performing data writing operation on the static partition of the system B according to the system upgrade package.

In some embodiments, reference may be made to S401 for details of implementing the above-mentioned A4, which are not described herein again. In addition, in a scenario of performing operating system upgrade on electronic equipment running in the B system, similarly, the update engine performs data write operation on the static partition of the B system according to the system upgrade package.

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

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

In some embodiments, reference may be made to S402 for details of implementation of A6 and A7, which are not described herein again.

And A8, changing the identifier indicating the starting of the static partition of the system A into the identifier indicating the starting of the static partition of the system B.

In some embodiments, the update engine may rewrite a Boot sequence identifier of a Master Boot Record (MBR), for example, rewrite the Boot sequence identifier from a to B, so that after the electronic device is restarted, data of the static partition (B) may be loaded, and thus, the electronic device may be switched to run a system B.

And A9, determining that the system upgrade package comprises a modified small package.

In some embodiments, reference may be made to S106 for details of implementation of A9 described above, which are not described herein again.

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

In some embodiments, reference may be made to S107 for details of implementing a10 described above, which are not described herein again.

A11, update engine writes the read VC information into oeminfo _ VC _ tmp.

In some embodiments, reference may be made to S108 for details of implementation of a11 described above, which are not described herein again.

And A12, decompressing the modified packet to a cache/update directory by the update engine, wherein the modified packet comprises ptable and super _ metadata.

In some embodiments, reference may be made to S109 for details of implementation of a12 described above, which are not described herein again.

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

In some embodiments, reference may be made to S110 for details of implementing the above-mentioned a13, which is not described herein again. In addition, the electronic device can load the static partition of the system B after the restart is successful, and the process flow enters a14.

And A14, triggering merge flow by update engine.

In some embodiments, reference may be made to S111 for details of implementing a14 described above, which are not described herein again.

A15, update engine copies the static partition of the B system to the static partition of the A system.

In some embodiments, reference may be made to S112 for details of implementing a15 described above, which are not described herein again.

A16, update engine writes VC information in the oeminfo _ VC _ tmp into an oeminfo _ VC file in an oeminfo sub-partition.

In some embodiments, reference may be made to S113 for details of implementing the above-mentioned a16, which is not described herein again.

And A17, writing the storage address of the modified packet into the cache/recovery/command file when the update engine detects that the cache/update directory comprises the modified packet.

In some embodiments, reference may be made to S114 for details of implementation of a17 described above, which are not described herein again.

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

In some embodiments, reference may be made to S115 for details of implementing a18 described above, which are not described herein again. In addition, the electronic device may start the Recovery process according to the information indicating to enter the Recovery mode, so that the process proceeds to a19.

A19, the Recovery process checks the integrity of the system upgrade package.

In some embodiments, reference may be made to S116 for details of implementation of a19 described above, which are not described herein again.

And A20, configuring a global variable vcdemo when the Recovery process queries the modified packet according to the cache/Recovery/command file.

In some embodiments, reference may be made to S117 for details of implementing the above-mentioned a20, which are not described herein again.

A21, in the case that the variable vcdemo is recognized, the Recovery process migrates the preload data according to super _ metadata.

In some embodiments, reference may be made to S801 to S806 for details of the implementation of a21 described above, which are not described herein again.

A22, the Recovery process updates the ptable in the remodeled small packet to the partition table in Common.

In some embodiments, reference may be made to S119 for details of implementation of a22 described above, which are not described herein again.

A23, the Recovery process updates the super _ metadata.img in the modified small packet to the super header information.

In some embodiments, reference may be made to S120 for details of implementing the above-mentioned a23, which is not described herein again.

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

In some embodiments, reference may be made to S121 for details of implementing a24 described above, which are not described herein again.

A25, the Recovery process formats the Userdata partition and restarts.

In some embodiments, reference may be made to S122 for details of implementing the above-mentioned a25, which is not described herein again.

An embodiment of the present application further 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 comprising computer instructions. The computer instructions, when executed by the processor, may cause the electronic device to perform the various steps in the embodiments described above. Of course, the electronic device includes, but is not limited to, the above-described memory and one or more processors, such as shown in FIG. 3A.

The embodiment of the present application further provides a chip system, which can be applied to the electronic device in the foregoing embodiments. 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 the electronic device 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 via the interface circuit 2202. The computer instructions, when executed by the processor 2201, may cause the electronic device to perform the various steps in the embodiments described above. Of course, the chip system may further include other discrete devices, which is not specifically limited in this embodiment of the present application.

In some embodiments, as will be apparent to those skilled in the art from the foregoing description of the embodiments, for convenience and simplicity of description, only the above division of each functional module is used for illustration, and in practical applications, the above function allocation may be performed by different functional modules as needed, that is, the internal structure of the apparatus may be divided into different functional modules to perform all or part of the above described functions. For the specific working processes of the system, the apparatus and the unit described above, reference may be made to the corresponding processes in the foregoing method embodiments, and details are not described here again.

Each functional unit in the embodiments of the present application may be integrated into one processing unit, or each unit may exist alone physically, or two or more units are integrated into one unit. The integrated unit can be realized in a form of hardware, and can also be realized in a form of a software functional unit.

The integrated unit, if implemented in the form of a software functional unit and sold or used as a stand-alone product, may be stored in a computer readable storage medium. Based on such understanding, the technical solutions of the embodiments of the present application may be essentially implemented or make a contribution to the prior art, or all or part of the technical solutions may be implemented in the form of a software product stored in a storage medium and including several instructions for causing a computer device (which may be a personal computer, a server, or a network device) or a processor to execute 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 drive, read only memory, random access memory, magnetic or optical disk, and the like.

The above description is only a specific implementation of the embodiments of the present application, but the 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 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 (13)

1. The method for upgrading the operating system is applied to electronic equipment, wherein the electronic equipment comprises a memory, and the memory comprises 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 system file is stored in a basic partition, the first system file comprises first system 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, and the electronic equipment runs, data of the basic partition, the first static partition and a dynamic partition are loaded 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 includes a second address indicating 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 boot sequence identifier of the electronic device, wherein the modified boot sequence identifier indicates booting from the second static partition;

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

modifying the first system information into the second system information;

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

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

and modifying the first partition table into the second partition table.

2. The method of claim 1, wherein the first data further includes second data in the dynamic partition, the second data is stored in the first sub-partition, a third partition table is stored in the base partition, and the third partition table includes a third address, the third address is used to indicate an ending physical address of the dynamic partition in the memory; the migrating a starting physical address of 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;

after the writing is finished, the first data in the user data partition is written 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. The method of claim 3, wherein a third partition table is maintained in the base partition, the third partition table including a fourth address indicating 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 a starting physical address of first data from the first address to the second address, the method further comprises:

updating the third partition table with 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 standard file already comprises the second standard 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 include 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-6, 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 remanufactured small package; wherein the second partition table is compressed in the modified packet;

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

decompressing the reconstituted packet into a first storage area; wherein the first storage area is a storage area accessible to the electronic device in the recovery mode;

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

obtaining the second address from the second partition table in the first storage area.

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

writing first indication information in a second storage area under the condition that the modified 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: migrating a starting physical address of the first data from a first address to the second address after detecting the first indication information.

9. The method of any of claims 1-8, wherein after updating 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 upgrading data in the virtual partition into the dynamic partition.

10. The method of any of claims 1-9, wherein after modifying the boot sequence identifier of the electronic device, the method further comprises:

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

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

11. An electronic device, characterized in that the electronic device comprises one or more processors and memory; the memory is coupled to the processor, the memory for storing computer program code, the computer program code comprising computer instructions, which when executed by the one or more processors, cause the one or more processors to perform the method of any of claims 1-10.

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

13. A computer program product, characterized in that, when run on an electronic device, it causes the electronic device to perform the method of any of claims 1-10.

Images