Upgrading method of operating system and electronic equipment

Abstract

The invention discloses an operating system upgrading method and electronic equipment, and relates to the technical field of computers. The method comprises the following steps: loading a basic partition, a first static partition and a dynamic partition, and running an operating system of a first version. A first installation package is obtained, the first installation package is an installation package of an operating system of a second version, the second version is lower than the first version, and the first installation package comprises first system data and second system data of the operating system of the second version. And writing the first system data into the second static partition, and writing the first system data into the user data partition. And restarting and entering a repair mode. And in the repair mode, writing the second system data in the user data partition into the dynamic partition, and formatting the user data partition. And restarting and loading the basic partition, the second static partition and the dynamic partition, and running the operating system of the second version. Therefore, the electronic equipment can automatically finish the processing of backspacing to the low-version operating system, and does not need to get to a network point for backspacing by the network point.

Description

Operating system upgrade method and electronic device

[0001] This application claims priority to the Chinese patent application filed with the State Intellectual Property Office on December 22, 2022, with application number 202211658830.4 and invention name “A method for upgrading an operating system and an electronic device”, the entire contents of which are incorporated by reference into this application. Technical Field

[0002] The present application relates to the field of computer technology, and in particular to an operating system upgrade method and electronic equipment. Background Art

[0003] Before an electronic device leaves the factory, the operating system can be burned into the electronic device, thereby achieving the installation of the operating system before the electronic device leaves the factory. Afterwards, in order to improve the user experience, the operating system in the electronic device may need to be upgraded. In this case, Over-the-Air Technology (OTA) can be used to upgrade the operating system from a lower version (such as V1.0) to a higher version (such as V2.0). OTA is a technology that remotely upgrades the operating system version through the wireless network interface of the electronic device.

[0004] However, in practice, users may not have a good experience with the upgraded operating system. For example, a user may be accustomed to using an older operating system and find the upgraded version difficult to use. In this case, the user may wish to roll back from the older operating system to the older version.

[0005] However, the inventors discovered during the implementation of the embodiments of the present application that, in the prior art, when faced with the need to roll back from a higher version of the operating system to a lower version, the user can only take the electronic device to a fixed outlet, where the outlet staff will then perform the rollback operation to roll back the operating system to the lower version.

[0006] Summary of the Invention

[0007] In view of this, the present application provides an operating system upgrade method and electronic device, which can obtain a rollback package for rolling back a higher version to a lower version, and automatically complete the process of rolling back to the lower version of the operating system without having to take it to a network point for the network point to perform the rollback.

[0008] In the first aspect, the present application provides an operating system upgrade method, which is applied to an electronic device, wherein the electronic device includes a memory, and the memory includes a basic partition, a first static partition, a second static partition, a dynamic partition, and a user data partition. Among them, the basic partition, the first static partition, and the dynamic partition are loaded, and the first version of the operating system is run. Obtain a first installation package, the first installation package is an installation package for the second version of the operating system, the second version is lower than the first version, and the first installation package includes the first system data and the second system data of the second version of the operating system. Write the first system data to the second static partition, and write the first system data to the user data partition. Restart and enter repair mode. In repair mode, write the second system data in the user data partition to the dynamic partition, and format the user data partition. Restart, load the basic partition, the second static partition, and the dynamic partition, and run the second version of the operating system.

[0009] In summary, in this application, when rolling back from a higher version of an operating system to a lower version of an operating system, the electronic device writes the lower version of the system data to the static partition and the user data partition in standby mode, then enters the repair mode to write the system data in the user data partition to the dynamic partition, so that the system data in the user data partition that supports the operation of the lower version of the operating system is read out. Then, the user data partition is formatted in the repair mode, so that the data in the user data partition can be cleared. Finally, the electronic device is restarted, and the static partition and dynamic partition storing the lower version of the system data can be successfully loaded, as well as the user data partition that does not need to be decrypted can be successfully loaded, so that it can successfully run under the lower version of the operating system.

[0010] In a possible design of the first aspect, before restarting and entering the repair mode, the method further includes: determining that the first installation package is used to install an operating system of a version lower than the first version.

[0011] In other words, you should only restart and enter the repair mode if you are sure that a rollback is necessary, thus avoiding mistakenly entering the repair mode when a rollback is not necessary.

[0012] In a possible design method of the first aspect, the first installation package includes a first version number, and the first version number is the version number of the second version. Determining that the first installation package is used to install an installation package of an operating system of a lower version than the first version includes: determining that the first version number is lower than the second version number, and the second version number is the version number of the first version.

[0013] Among them, if the first version number is lower than the second version number, it means that the version number carried in the installation package is lower than the version number of the operating system currently running on the electronic device, that is, the scenario of rolling back to a lower version.

[0014] In one possible design of the first aspect, after determining that the first installation package is used to install an operating system of a version lower than the first version, the method further includes: recording a preset identifier in a preset subpartition, where the preset subpartition is a subpartition accessible in repair mode. In repair mode, writing the second system data in the user data partition to the dynamic partition and formatting the user data partition includes: in repair mode, if the preset identifier is read from the preset subpartition, writing the second system data in the user data partition to the dynamic partition and formatting the user data partition.

[0015] In other words, only when rolling back to a lower version will the merge and subsequent processing be performed. This avoids incorrectly executing the merge and other processing in repair mode when rolling back is not necessary, which will eventually affect system operation.

[0016] In a possible design of the first aspect, before obtaining the first installation package, the method further includes: displaying a first interface, the first interface including a first control; sending a package search request to a server in response to a first user operation on the first control; and receiving a download address provided by the server based on the package search request. Accordingly, obtaining the first installation package includes: downloading the first installation package based on the download address.

[0017] That is, the user can actively trigger the acquisition of the first installation package on the electronic device. In this way, when the user needs to roll back to a lower version, the first installation package can be acquired and rolled back, accurately meeting the user's needs.

[0018] In one possible design of the first aspect, after obtaining the first installation package, the method further includes: displaying a second interface, the second interface including version information of the second version of the operating system and a second control, the second control being used to trigger installation of the second version of the operating system. Writing the first system data to the second static partition and writing the first system data to the user data partition includes: writing the first system data to the second static partition and writing the first system data to the user data partition in response to a second user operation on the second control.

[0019] That is to say, after obtaining the first installation package, the electronic device can perform the rollback operation only when the user confirms to roll back to the lower version of the operating system. In this way, the user's needs can be accurately met.

[0020] In one possible design of the first aspect, after writing the second system data in the user data partition to the dynamic partition, the method further includes synchronizing the first system data in the second static partition to the first static partition. This allows the first static partition to also store lower-version system data. Subsequently, when booting from the first static partition, the lower-version operating system can also be run.

[0021] In a possible design of the first aspect, in the process of writing the first system data to the second static partition and writing the first system data to the user data partition, the above method also includes: displaying a third interface, which is an interface of the electronic device in standby mode.

[0022] That is to say, the writing of the low-version system data is completed in the standby state, and the user can use the electronic device normally during the process of writing the system data.

[0023] In a possible design of the first aspect, in the repair mode, the second system data in the user data partition is written to the dynamic partition, and during the process of formatting the user data partition, the above method also includes: displaying a fourth interface, the fourth interface including progress prompt information, and the progress prompt information is used to prompt the progress of disk writing and formatting; wherein, the electronic device will not respond to the user's operations on the fourth interface.

[0024] That is to say, in repair mode, users cannot operate electronic devices normally.

[0025] In one possible design of the first aspect, restarting and entering the repair mode includes: restarting and starting a repair process. In the repair mode, writing the second system data in the user data partition to the dynamic partition includes: the repair process triggering the start of a write-to-disk service, and the write-to-disk service writing the second system data in the user data partition to the dynamic partition;

[0026] The repair process formats the userdata partition.

[0027] That is, in the repair mode, the second system data in the user data partition can be written to the dynamic partition by launching the write-to-disk service.

[0028] In one possible design of the first aspect, the second version satisfies at least one of the following conditions:

[0029] The second version is a preset version. This ensures that the rollback to a version that is too old or has major vulnerabilities is not possible. The second version is higher than the version of the operating system installed when the electronic device leaves the factory. This ensures that the device will not be rolled back to a version that was not installed on the electronic device, that is, a version that the user has not used.

[0030] The second version is the version that is allowed to be installed in the area where the electronic device is used. In this way, it is guaranteed that the device can be rolled back to the version that is allowed to be installed in the electronic device.

[0031] In a possible design of the first aspect, before loading the basic partition, the first static partition, and the dynamic partition, and running the first version of the operating system, the above method also includes: loading the basic partition, the second static partition, and the dynamic partition, and running the third version of the operating system, where the third version is lower than the first version. Obtain a second installation package, the second installation package is used to upgrade to the first version of the operating system, and the second installation package includes the third system data and the fourth system data of the first version of the operating system. Write the third system data to the first static partition, and write the fourth system data to the user data partition. Restart. Loading the basic partition, the first static partition, and the dynamic partition, and running the first version of the operating system, includes: loading the fourth system data in the basic partition, the first static partition, the dynamic partition, and the user data partition, and running the first version of the operating system.

[0032] That is, the first version of the operating system in the electronic device is upgraded from the third version of the operating system. Moreover, when upgrading from a lower version of the operating system to a higher version of the operating system, after completing the writing of the system data, the electronic device can be run under the higher version of the operating system by restarting normally.

[0033] In a possible design of the first aspect, after loading the basic partition, the first static partition, the dynamic partition and the user data partition and running the first version of the operating system, the above method also includes: writing the fourth system data in the user data partition into the dynamic partition.

[0034] In a possible design of the first aspect, before restarting and loading the basic partition, the first static partition, the dynamic partition, and the user data partition, the method further includes: determining that the second installation package is not used to install an operating system of a version lower than the third version.

[0035] In a possible design method of the first aspect, the second installation package includes a second version number, which is the version number of the first version. Determining that the second installation package is not used to install an operating system version lower than the third version includes: determining that the third version number is lower than the second version number, and the third version number is the version number of the third version.

[0036] In one possible design of the first aspect, after loading the base partition, the second static partition, and the dynamic partition and running the second version of the operating system, the method further includes: in response to a preset event, restarting and re-entering the repair mode; wherein, if it is determined that the purpose of re-entering the repair mode is not to install an operating system of a lower version than the first version, the data in the user data partition is not written to the dynamic partition. In this way, the corresponding processing can be accurately executed based on the purpose of entering the repair mode.

[0037] In a second aspect, the present application further provides an electronic device, comprising a processor and a memory, wherein the memory comprises a basic partition, a first static partition, a second static partition, a dynamic partition, and a user data partition. The processor is configured to execute software code stored in the memory, so that the electronic device performs the method of the first aspect and any possible design thereof.

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

[0039] In a fourth aspect, an embodiment of the present application further provides a computer storage medium, which includes computer instructions. When the computer instructions are executed on an electronic device, the electronic device executes the method described in the first aspect and any possible design method thereof.

[0040] In a fifth aspect, the present application provides a computer program product, which, when executed on a computer, enables the computer to execute the method described in the first aspect and any possible design thereof.

[0041] It can be understood that the beneficial effects that can be achieved by the electronic device described in the second aspect, the chip system described in the third aspect, the computer storage medium described in the fourth aspect, and the computer program product described in the fifth aspect provided above can refer to the beneficial effects in the first aspect and any possible design method thereof, and will not be repeated here. BRIEF DESCRIPTION OF THE DRAWINGS

[0042] FIG1 is a schematic diagram of a rollback scenario applicable to an embodiment of the present application;

[0043] FIG2 is a schematic diagram of a data storage structure provided in an embodiment of the present application;

[0044] FIG3 is a flowchart of an operating system upgrade;

[0045] FIG4 is a flowchart of an upgrade of another operating system;

[0046] FIG5 is a schematic diagram of an operating system upgrade process;

[0047] FIG6 is a schematic diagram of an operating system upgrade process according to an embodiment of the present application;

[0048] FIG7 is a second schematic diagram of the operating system upgrade process provided in an embodiment of the present application;

[0049] FIG8 is a hardware structure diagram of an electronic device provided in an embodiment of the present application;

[0050] FIG9 is a software structure diagram of an electronic device provided in an embodiment of the present application;

[0051] FIG10 is one of the upgrade flow charts of the operating system provided in an embodiment of the present application;

[0052] FIG11 is a schematic diagram of a mobile phone interface according to an embodiment of the present application;

[0053] FIG12 is a second schematic diagram of a mobile phone interface provided in an embodiment of the present application;

[0054] FIG13 is a second flowchart of an operating system upgrade according to an embodiment of the present application;

[0055] FIG14 is a third schematic diagram of the operating system upgrade process provided in an embodiment of the present application;

[0056] FIG15 is a third schematic diagram of a mobile phone interface provided in an embodiment of the present application;

[0057] FIG16 is an interactive diagram of an operating system upgrade process provided by an embodiment of the present application;

[0058] FIG17 is a third flowchart of an operating system upgrade according to an embodiment of the present application;

[0059] FIG18 is a structural diagram of the chip system provided in an embodiment of the present application. DETAILED DESCRIPTION

[0060] It should be understood that the embodiments described herein are only a portion of the embodiments of this application, not all of the embodiments. Based on the embodiments in this application, all other embodiments obtained by persons of ordinary skill in the art without creative work are within the scope of protection of this application.

[0061] An embodiment of the present application provides an operating system upgrade method, which can be applied to scenarios where the operating system in an electronic device needs to be rolled back from a higher version to a lower version. Referring to Figure 1, taking the electronic device as a mobile phone as an example, the operating system of the mobile phone can be upgraded from version V1.0 to version V2.0. Using the embodiment of the present application, the operating system can be rolled back from version V2.0 to version V1.0. Continuing to refer to Figure 1, the operating system of the mobile phone can also continue to be upgraded from version V2.0 to version V3.0. Using the embodiment of the present application, the operating system can be rolled back from version V3.0 to version V2.0, or from version V3.0 to version V1.0.

[0062] In electronic devices, the operating system's system data is stored in the device's memory. Memory typically includes read-only memory (ROM) and random access memory (RAM). In practical applications, RAM, also known as "main memory," is highly readable and writable at all times. It typically serves as a temporary data storage medium for the operating system or other running programs. However, RAM does not retain data when the power is turned off. In other words, RAM typically stores temporary data used during the operation of the electronic device. ROM, also known as "non-volatile memory," stores data that is typically pre-written before the device is installed, as well as user data generated during the user's use of the electronic device. It can only be read during operation and cannot be quickly and easily rewritten like RAM. Therefore, the data stored in ROM is stable and does not change even after a power outage. Due to these characteristics, operating system system data is typically stored in ROM to ensure system data stability.

[0063] At the same time, the ROM can use a virtual A / B (also called Virtual A / B) data storage structure to store system data. Figure 2 shows a schematic diagram of a virtual A / B data storage structure. As shown in Figure 2, taking the Android operating system as an example, the virtual A / B data storage structure includes a basic partition (Common), a static partition (A), a static partition (B), a dynamic partition (Super), and a user data partition (Userdata).

[0064] The user data partition (Userdata) is used to store the user's personal data, such as applications (APPs) installed by the user, and personal data such as pictures, documents, and videos saved by the user. The data stored in the basic partition (Common) is system data that does not participate in operating system upgrades. The structures of the static partition (A) and the static partition (B) correspond to each other, and the subpartition names are distinguished by the suffixes _a and _b. For example, the subpartitions in the static partition (A) include bootloader_a, boot_a, and vendor_boot_a; the subpartitions in the static partition (B) include bootloader_b, boot_b, and vendor_boot_b. The dynamic partition (Super) contains multiple subpartitions, such as System, system_ext, vendor, product, Cust, and Odm.

[0065] It should be noted that the data storage structure shown in Figure 2 is only exemplary. In practice, the basic partition (Common) in the data storage structure may further include multiple sub-partitions, such as cache sub-partitions, Misc sub-partitions, etc. In addition, the static partition (A), static partition (B), and dynamic partition (Super) in the data storage structure may include more or fewer sub-partitions than shown in Figure 2. For example, the static partition (A) may also include sub-partitions such as Patch_a, dtbo_a, and vbmeta_a. Correspondingly, the static partition (B) may also include sub-partitions such as Patch_b, dtbo_b, and vbmeta_b. For another example, the dynamic partition (Super) may also include sub-partitions such as version and preload.

[0066] When an electronic device boots up, it needs to boot from a static partition. For example, if the electronic device boots up from static partition (A), it will load the basic partition (Common), static partition (A), and dynamic partition (Super) in sequence. For another example, if the electronic device boots up from static partition (B), it will load the basic partition (Common), static partition (B), and dynamic partition (Super) in sequence.

[0067] Regarding the data storage structure shown in Figure 2, when an electronic device needs to upgrade from a lower version of the operating system to a higher version, the electronic device can use a virtual A / B upgrade solution to achieve the upgrade. Referring to Figure 3, using the virtual A / B upgrade solution to upgrade the electronic device's operating system from the currently running lower version (such as version R) to a higher version (such as version S) includes:

[0068] S300, boot from the static partition (A) and run under the R version.

[0069] That is, the electronic device sequentially loads the basic partition (Common), the static partition (A), and the dynamic partition (Super), and runs under the R version of the operating system.

[0070] S301. Obtain the S version upgrade package.

[0071] The upgrade package includes system data upgraded to the S version.

[0072] S302 : Write the coefficient data of version S into the ROM.

[0073] The electronic device can write the S version system data in the upgrade package to the static partition (B) and the user data partition (Userdata), thereby avoiding affecting the operation of the current R version.

[0074] S303. Restart.

[0075] That is, exit the current S version of the operating system, cut off the power of the electronic device, and then turn on the power of the electronic device again.

[0076] S304: Load the S version operating system from the static partition (B).

[0077] The electronic device can load the static partition (B) to obtain a portion of the system data required for version S. Furthermore, the electronic device can merge and load the system data in the dynamic partition (Super) and the system data in the user data partition (Userdata) based on snapshot technology to obtain another portion of the system data required for version S.

[0078] S305: Load the user data partition (Userdata).

[0079] By loading the user data partition (Userdata), you can obtain the user's personal data, such as applications, pictures, videos, etc. After successfully loading the user data partition (Userdata), the electronic device can run successfully.

[0080] It should be noted that the S version of the system data written to the user data partition (Userdata) in S302 is plain text data. Therefore, in S304, the electronic device can successfully load the system data in the user data partition (Userdata) without decryption. However, in the user data partition (Userdata), except for the S version of the system data written in S302, the rest of the data is personal data generated during the operation of the R version of the operating system, such as pictures, documents, etc., which need to be decrypted before they can be accessed. Therefore, an adaptive key is required to decrypt the encrypted data in the user data partition (Userdata) and successfully mount the user data partition (Userdata).

[0081] At the same time, usually the key of a higher version of the operating system can decrypt the data encrypted in the user data partition (Userdata) of the lower version of the operating system. However, the key of the lower version of the operating system cannot decrypt the data encrypted in the user data partition (Userdata) of the higher version of the operating system.

[0082] That is, during the upgrade from a lower version to a higher version, the key of the higher version operating system can be used to successfully decrypt the encrypted data in the user data partition (Userdata). Then, in S305, the key of the S version operating system can be used to successfully decrypt the encrypted data in the user data partition (Userdata), thereby successfully mounting the user data partition (Userdata).

[0083] After the restart, after the above S304 and S305, the user interface can be entered and the system will be running in version S. In this way, the system can be upgraded from a lower version to a higher version.

[0084] However, if the virtual A / B upgrade solution shown in Figure 3 (which can be called a conventional upgrade solution) is applied to the scenario of rolling back from a higher version (such as version S) of the operating system to a lower version (such as version R), the rollback failure problem may occur. Specifically, referring to Figure 4, a conventional upgrade solution is used to roll back the operating system of an electronic device from the currently running higher version (such as version R) to a lower version (such as version R), including:

[0085] S400, boot from the static partition (A) and run under the S version.

[0086] That is, the electronic device sequentially loads the basic partition (Common), the static partition (A), and the dynamic partition (Super), and runs under the S version of the operating system.

[0087] S401. Obtain the fallback package of the R version.

[0088] The fallback package is the installation package of the R version operating system, which includes the full system data of the R version operating system.

[0089] S402 , write the coefficient data of the R version into the ROM.

[0090] The electronic device can write the R version system data in the fallback package to the static partition (B) and the user data partition (Userdata), thereby avoiding affecting the operation of the current S version.

[0091] S403. Restart.

[0092] That is, exit the current R version of the operating system, cut off the power of the electronic device, and then turn on the power of the electronic device again.

[0093] S404. Load the R version operating system from the static partition (B).

[0094] The electronic device can load the static partition (B) to obtain a portion of the system data required for version R. Furthermore, the electronic device can merge and load the system data in the dynamic partition (Super) and the system data in the user data partition (Userdata) based on snapshot technology to obtain another portion of the system data required for version R.

[0095] S405: Loading the user data partition (Userdata) fails, and startup fails.

[0096] Since the system is rolling back from a higher version to a lower version, the lower version's operating system key cannot decrypt the encrypted data in the higher version's user data partition. Therefore, the R version's operating system key cannot successfully decrypt the encrypted data in the user data partition, resulting in an inability to successfully mount the user data partition. Consequently, the system fails to boot.

[0097] Furthermore, after the startup fails, the electronic device will be triggered to roll back the operating system, ie, execute the following S406.

[0098] S406: Roll back to the S version and continue running under the S version.

[0099] The electronic device can reload the basic partition (Common), static partition (A) and dynamic partition (Super) to continue running under the S version of the operating system.

[0100] That is to say, in the scenario of rolling back from a higher version of the operating system to a lower version of the operating system, using the conventional upgrade solution may trigger a rollback due to a failure to mount the user data partition (Userdata) after restarting, causing the electronic device to continue running under the higher version of the operating system and unable to successfully roll back to the lower version of the operating system.

[0101] Therefore, in conventional technology, when a user needs to roll back from a higher version of an operating system to a lower version of an operating system, the user can only take the mobile phone to a branch, where the branch staff will perform the rollback operation to complete the operating system rollback.

[0102] Specifically, referring to Figure 5, the supplier of the operating system can build a fallback package, and the built fallback package can be stored in a secure digital memory card (SD) (the process of building a fallback package as shown in 501 in Figure 5). Among them, a continuous integration (CI) system can be used to create the fallback package. Then, the staff of the branch can erase the S version of the operating system in the electronic device (the version control process as shown in 502 in Figure 5). Finally, the staff of the branch can use the SD card including the R version of the fallback package to install the R version of the operating system to the electronic device (the installation process of the R version as shown in 503 in Figure 5). Thereby, the operating system in the electronic device is updated from the S version to the R version.

[0103] That is to say, with conventional technology, using conventional upgrade solutions, it is impossible to roll back from the S version of the operating system to the R version of the operating system. Instead, it can only be taken to a branch, where the staff of the branch will flash the machine and install the R version of the operating system to achieve the rollback of the operating system.

[0104] Based on the above problems, an embodiment of the present application provides an operating system upgrade method, which can be applied to an electronic device that needs to roll back the S version (also referred to as the first version) operating system to the R version (also referred to as the second version) operating system. Before introducing the embodiment of the present application, the repair mode required in this application is first introduced. The repair mode refers to a mode in which the data or operating system inside the electronic device can be modified. In repair mode, the electronic device can back up or upgrade the operating system, or restore the factory settings. For example, the repair mode can be the recovery mode in the Android system. For another example, the repair mode can be the preinstallation environment (PE) or disk operating system (DOS) in the Windows system. The following mainly takes the recovery mode in the Android system as an example to illustrate.

[0105] The following describes the application plan:

[0106] When it is necessary to roll back from the S version operating system to the R version operating system, the electronic device can download the rollback package (also called the first installation package) of the R version operating system. In the standby state, the electronic device writes the R version system data in the rollback package to the static partition and user data partition (Userdata) in the ROM.

[0107] For example, let's assume that the electronic device is currently booting from the static partition (A), the S version is V3.0, and the R version is V2.0. (See Figure 6.) In standby mode, the V2.0 system data is written. The static partition (A), static partition (B), and user data partition (Userdata) all store V3.0 system data, with the user's personal data stored in the user data partition (as shown before writing in Figure 6). Since the electronic device is currently booting from the static partition (A), it is running on the V3.0 operating system composed of the basic partition (Common), static partition (A), and dynamic partition (Super). Then, the electronic device can write the system data that needs to be stored in the static partition in V2.0 to the static partition (B), so that the static partition (B) can store part of the system data of V2.0 (as shown in the static partition (B) after writing in Figure 6); and write the system data that needs to be stored in the dynamic partition in V2.0 to the user data partition (Userdata), so that the user data partition (Userdata) can store another part of the system data of V2.0 (as shown in the user data partition (Userdata) after writing in Figure 6). In this way, the data in the static partition (A) and the dynamic partition (Super) will not be changed, and thus the operation of the current V3.0 version of the operating system will not be affected.

[0108] After the system data is written, the electronic device can restart and enter recovery mode. In recovery mode, the electronic device writes the system data in the user data partition (Userdata) to the dynamic partition (Super). Among them, the process of writing the system data in the user data partition (Userdata) to the dynamic partition (Super) can also be called the disk write process. In this way, the dynamic partition (Super) can store the R version of the system data, so that the R version of the system data can be loaded by loading the dynamic partition (Super) later.

[0109] For example, after writing part of the system data of V2.0 to the static partition (B) and writing another part of the system data of V2.0 to the user data partition (Userdata), in recovery mode, see Figure 7, the electronic device can first write the "system data of V2.0" in the user data partition (Userdata) to the dynamic partition (Super), so that the system data of V2.0 is stored in the dynamic partition (Super).

[0110] Furthermore, after the data is written to the disk, the electronic device formats the user data partition (Userdata), so that no data that needs to be decrypted before being accessed is stored in the user data partition (Userdata).

[0111] Continuing to refer to FIG7 , in the recovery mode, after completing the write to disk, the electronic device formats the user data partition (Userdata), thereby clearing the data in the user data partition, including the V2.0 system data and the user's personal data.

[0112] Finally, the electronic device restarts, and the static partition and dynamic partition (Super) storing the R version system data can be successfully loaded, as well as the user data partition (Userdata) that does not require decryption, thereby successfully running under the R version operating system. Continuing with Figure 7, after formatting is complete, the electronic device can boot from the static partition (B), that is, run in the V2.0 operating system composed of the basic partition (Common), the static partition (B), and the dynamic partition (Super), and can also successfully load the user data partition (Userdata).

[0113] For example, electronic devices in embodiments of the present application include, but are not limited to, mobile phones, headphones, tablets, smart refrigerators, smart speakers, and other devices that can be installed with an operating system. Alternatively, an electronic device may also refer to a control board within the electronic device that can be installed with an operating system. Furthermore, in embodiments of the present application, an operating system includes, but is not limited to, iOS, Android, Harmony, Windows, Linux, or other operating systems.

[0114] Referring to Figure 8, a hardware structure diagram of an electronic device provided in an embodiment of the present application is shown. As shown in Figure 8, taking the electronic device as a mobile phone as an example, the electronic device may include a processor 310, an external memory interface 320, an internal memory 321, a universal serial bus (USB) interface 330, a charging management module 340, a power management module 341, a battery 342, an antenna 1, an antenna 2, a mobile communication module 350, a wireless communication module 360, an audio module 370, a speaker 370A, a receiver 370B, a microphone 370C, an earphone interface 370D, a sensor module 380, a button 390, a motor 391, an indicator 392, a camera 393, a display screen 394, and a subscriber identification module (SIM) card interface 395, etc.

[0115] It should be understood that the structure illustrated in this embodiment does not constitute a specific limitation on the electronic device. In other embodiments, the electronic device may include more or fewer components than shown, or may combine or separate certain components, or have different component arrangements. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

[0116] The processor 310 may include one or more processing units. For example, the processor 310 may include an application processor (AP), a modem processor, a graphics processing unit (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). The different processing units may be independent devices or integrated into one or more processors.

[0117] It is understood that the interface connection relationship between the modules illustrated in this embodiment is only for illustrative purposes and does not constitute a structural limitation on the electronic device. In other embodiments, the electronic device may also adopt different interface connection methods from the above embodiments, or a combination of multiple interface connection methods.

[0118] The charging management module 340 is configured to receive charging input from a charger. The charger can be either a wireless charger or a wired charger. In some wired charging embodiments, the charging management module 340 can receive charging input from the wired charger via the USB interface 330. In some wireless charging embodiments, the charging management module 340 can receive wireless charging input via the electronic device's wireless charging coil. While charging the battery 342, the charging management module 340 can also provide power to the electronic device via the power management module 341.

[0119] The power management module 341 is used to connect the battery 342, the charging management module 340, and the processor 310. The power management module 341 receives input from the battery 342 and / or the charging management module 340 and provides power to the processor 310, the internal memory 321, the external memory, the display 394, the camera 393, and the wireless communication module 360. The power management module 341 can also be used to monitor parameters such as battery capacity, battery cycle count, and battery health status (leakage, impedance). In some other embodiments, the power management module 341 can also be set in the processor 310. In other embodiments, the power management module 341 and the charging management module 340 can also be set in the same device.

[0120] The wireless communication function of the electronic device can be implemented through antenna 1, antenna 2, mobile communication module 350, wireless communication module 360, modem processor and baseband processor.

[0121] The wireless communication module 360 ​​can provide wireless communication solutions for electronic devices, including wireless local area networks (WLAN) (such as wireless fidelity (Wi-Fi) networks), Bluetooth (BT), global navigation satellite system (GNSS), frequency modulation (FM), near field communication (NFC), infrared (IR), etc. The wireless communication module 360 ​​can be one or more devices that integrate at least one communication processing module. The wireless communication module 360 ​​receives electromagnetic waves via the antenna 2, frequency modulates and filters the electromagnetic wave signals, and sends the processed signals to the processor 310. The wireless communication module 360 ​​can also receive the signal to be sent from the processor 310, frequency modulate it, amplify it, and convert it into electromagnetic waves for radiation through the antenna 2.

[0122] The electronic device implements display functionality through a GPU, display screen 394, and an application processor. A GPU is a microprocessor for image processing that connects display screen 394 and the application processor. The GPU is used to perform mathematical and geometric calculations for graphics rendering. Processor 310 may include one or more GPUs that execute program instructions to generate or modify display information.

[0123] The electronic device can implement a camera function using an ISP, a camera 393, a video codec, a GPU, a display 394, and an application processor. The ISP processes data fed back by the camera 393. The camera 393 is used to capture still images or videos. The object is projected onto a photosensitive element through the lens to generate an optical image. In some embodiments, the electronic device may include one or N cameras 393, where N is a positive integer greater than one.

[0124] External memory interface 320 can be used to connect an external memory card, such as a Micro SD card, to expand the storage capacity of the electronic device. The external memory card communicates with processor 310 via external memory interface 320 to implement data storage functions. For example, files such as music and videos can be stored on the external memory card.

[0125] The internal memory 321 can be used to store computer executable program code, which includes instructions. The processor 310 executes various functional applications and data processing of the electronic device by running the instructions stored in the internal memory 321. For example, the processor 310 can perform the rollback operation of the operating system by executing the instructions stored in the internal memory 321. The internal memory 321 may include a program storage area and a data storage area. Among them, the program storage area can store the operating system, at least one application required for a function (such as a sound playback function, an image playback function, etc.), etc. The data storage area can store data created during the use of the electronic device (such as audio data, a phone book, etc.), etc. In addition, the internal memory 321 may include a high-speed random access memory, and may also include a non-volatile memory, such as at least one disk storage device, a flash memory device, a universal flash storage (UFS), etc. It should be understood that the internal memory 321 can be set inside the processor 310, or the internal memory 321 can be independently set outside the processor 310.

[0126] In a specific implementation, the internal memory 321 may include ROM and RAM. In this application, the ROM may adopt a virtual A / B data storage structure.

[0127] The electronic device can implement audio functions such as music playback and recording through the audio module 370, the speaker 370A, the receiver 370B, the microphone 370C, the headphone jack 370D, and the application processor.

[0128] The buttons 390 include a power button, a volume button, etc. The buttons 390 can be mechanical buttons. They can also be touch buttons. The electronic device can receive button inputs and generate key signal inputs related to the user settings and function controls of the electronic device. The motor 391 can generate vibration prompts. The motor 391 can be used for incoming call vibration prompts, or for touch vibration feedback. The indicator 392 can be an indicator light, which can be used to indicate the charging status, power changes, messages, missed calls, notifications, etc. The SIM card interface 395 is used to connect the SIM card. The SIM card can be inserted into the SIM card interface 395, or pulled out from the SIM card interface 395 to achieve contact and separation with the electronic device. The electronic device can support 1 or N SIM card interfaces, where N is a positive integer greater than 1.

[0129] See Figure 9, which is a schematic diagram of the software composition of the electronic device provided in this application. As shown in Figure 9, an operating system update program for upgrading the operating system is installed in the electronic device. Furthermore, the operating system update program includes two functional modules: an online update client tool (online update client apk, ouc apk) and an update engine (update engine). Ouc apk is used to obtain the upgrade installation package (including the rollback package) of the operating system. The update engine is used to execute the upgrade process of the operating system, such as for writing system data to the ROM.

[0130] Continuing with Figure 9, the electronic device also includes a recovery process and a merge service. In this application, the recovery process can be used to launch the merge service to complete the merge of the dynamic partition (Super). In addition, the recovery process can also trigger a factory reset to format the user data partition (Userdata).

[0131] The following is a brief introduction to the operating system upgrade method provided by this application, combined with the software components shown in Figure 9: When it is necessary to roll back from the S version operating system to the R version operating system, the ouc apk can download the rollback package of the R version operating system. In standby mode, the update engine writes the system data in the rollback package to the static partition and user data partition (Userdata) in the ROM. After the system data is written, the electronic device can restart and enter recovery mode, that is, start the recovery process. The recovery process can launch the merge service, which will write the system data in the user data partition (Userdata) to the dynamic partition (Super). Moreover, after the disk is written, the recovery process can format the user data partition (Userdata) so that the user data partition (Userdata) no longer contains data that requires decryption to access. Finally, the electronic device restarts, and the static partition and dynamic partition (Super) storing the R version system data can be successfully loaded, as well as the user data partition (Userdata) that does not require decryption, so that it can successfully run under the R version operating system.

[0132] The operating system upgrade method provided in this application can be applied to electronic devices having the above-mentioned hardware and software structures. The following will illustrate the operating system rollback solution provided in this application in conjunction with actual upgrade scenarios.

[0133] Scenario 1: Rolling back from version S (the first version) of the operating system to version R (the second version), where version R is lower than version S. This is also called a rollback scenario, where the operating system is rolled back from a higher version to a lower version.

[0134] In Scenario 1, as shown in Figure 6 above, the electronic device writes version R system data in standby mode, writes the dynamic partition (Super) to disk, and formats the user data partition (Userdata) in recovery mode. The electronic device then restarts and successfully runs the version R operating system.

[0135] Referring to FIG10 , taking the electronic device currently booting from the static partition (A) as an example, in scenario 1, the process of rolling back from the S version operating system to the R version operating system includes the following steps:

[0136] S1001. The electronic device sequentially loads the basic partition (Common), the static partition (A), and the dynamic partition (Super), boots from the static partition (A), and runs under the S version operating system.

[0137] For the sake of convenience, the static partition (A) in scenario 1 may be referred to as the first static partition, and the static partition (B) may be referred to as the second static partition.

[0138] S1002: When it is necessary to roll back from the S version operating system to the R version operating system, the electronic device obtains the R version rollback package.

[0139] When a user needs to roll back the S version operating system currently running on an electronic device to the R version operating system, the user can perform a rollback request operation on the electronic device. In response to the rollback request operation, the electronic device can send a package search request to the server, requesting to obtain the R version rollback package (i.e., the first installation package), that is, requesting to obtain the installation package of the R version operating system.

[0140] The electronic device may display a first interface including a rollback control (also referred to as a first control). The rollback control is used to trigger the electronic device to request a rollback package for version R from the server. In response to a user's preset operation on the rollback control (such as a click operation, a long press operation, etc., also referred to as a first operation), the electronic device may request a rollback package for version R from the server. That is, the rollback request operation is a preset operation for the rollback control.

[0141] Taking a mobile phone as an example, the mobile phone has pre-set applications installed (such as a mobile assistant application and a settings application). These pre-set applications can be used to manage the operating system installed on the phone, such as operating system upgrades and rollbacks. The mobile phone may display interface 1101 shown in Figure 11. Interface 1101 is the application interface of the mobile assistant application. Interface 1101 includes two options: "Geek Edition" and "Earlier Version." If the user selects "Geek Edition," the phone can request an upgrade package for the Geek Edition (also understood as a public beta version) from the server. If the user selects "Earlier Version," the phone can request a rollback package for version R from the server. That is, the rollback control is "Earlier Version," and the pre-set operation for the rollback control is selecting "Earlier Version" in interface 1101. In response to the user selecting "Earlier Version" in interface 1101, the mobile phone can send a package search request to the server, requesting a rollback package for version R.

[0142] After receiving a packet search request, the server can determine the R version based on the request information carried in the packet search request. The request information includes the version number of the S version (i.e., the version currently running on the electronic device); it can also include the device identifier and / or region information. The following describes how the electronic device determines the R version based on the S version number, device identifier, and region information.

[0143] Method 1: The server determines the R version based on the version number of the S version.

[0144] The server may determine a version lower than the S version as the R version based on the version number of the S version. For example, if the S version is V3.0 and V2.0 is lower than V3.0, then V2.0 may be determined as the R version.

[0145] In a specific implementation, in order to avoid rolling back to an operating system that is too old, or to avoid rolling back to an operating system with vulnerabilities, etc., the server can record the corresponding relationship between the version number before the rollback and the version number before the rollback. Among them, the version number that can be rolled back is the version number of the operating system that is before the version number before the rollback, is closer to the version number before the rollback, and has fewer vulnerabilities (also called the version number of the preset version). Exemplarily, the server records the corresponding relationship shown in Table 1 below:

[0146] Table 1

[0147] Table 1 above shows that V1.1 can be rolled back to V1.0, V2.3 can be rolled back to V2.2, and V3.2 can be rolled back to V3.1.

[0148] Therefore, after receiving the search request, the server queries the version number carried in the search request for the version number that can be rolled back, thereby determining the rollback version. For example, if the version number carried in the search request is V2.3, querying Table 1 above determines that the rollback version number is V2.2, that is, the R version is V2.2.

[0149] By adopting the above-mentioned method 1, a version lower than the S version can be determined as the R version.

[0150] Method 2: The server determines the R version based on the version number of the S version and the device identifier.

[0151] The device identification includes information such as the device name, device model, or product serial number (SN).

[0152] Specifically, to avoid rolling back to a version that the user has never used, the server can, based on the version number of version S and the device identifier, determine a version that is lower than version S and higher than the version installed when the electronic device leaves the factory as version R. The server can query the version installed when the electronic device leaves the factory based on the device identifier, and a version lower than the version installed when the electronic device leaves the factory is considered to be a version that the user has not used.

[0153] For example, the operating system installed on mobile phone A when it leaves the factory is V2.0, and V1.1 and V1.0 are lower than V2.0. In other words, mobile phone A should not have ever installed operating systems V1.1 and V1.0. In addition, the electronic device is currently running S version V3.2, which is higher than V2.0, V1.1, and V1.0. In this case, the server can determine versions lower than V3.2 but higher than V2.0 as R versions, such as V2.1 and V3.0, but not V1.1 and V1.0. Using the above method 2, versions lower than S version and used by the user can be determined as R versions.

[0154] Method 3: The server determines the target R version based on the version number S and the region identifier.

[0155] The area information may include information such as a region name, longitude and latitude information, and a mobile network code (MCCMNC) indicating the area where the electronic device is used. For example, the area information may include City C, City D, etc. The area of ​​use may be obtained by positioning the electronic device or may be input by the user, and this embodiment of the application does not specifically limit this.

[0156] In practice, the operating system provider may provide different versions of the operating system for electronic devices used in different regions. For example, there may be a domestic version and an overseas version. Based on this, to avoid falling back to a version that is not available in the region where the electronic device is used, the server can, based on the version number and region information of the S version, determine the version that is lower than the S version and available in the region where the electronic device is used as the R version. The server can query the available version in the region where the electronic device is used based on the region information.

[0157] Exemplarily, the versions of the operating system that can be installed on mobile phones used domestically include V3.1 and V3.2, and the versions of the operating system that can be installed on mobile phones used overseas include V3.3. That is to say, mobile phones used domestically cannot install the V3.3 version of the operating system, and mobile phones used overseas cannot install the V3.1 and V3.2 operating systems. In addition, the area information of the electronic device shows that the electronic device is used domestically and the currently running S version is V4.0, which is higher than V3.1, V3.2, and V3.3. Then, the server can determine the version that is lower than V4.0 and can be used domestically as the R version, such as determining versions such as V3.1, V3.2 as the R version, but will not determine V13.3 as the R version.

[0158] By adopting the third method, a version lower than the S version and allowed to be installed in the area where the electronic device is used can be determined as the R version.

[0159] Of course, the server may also combine the above-mentioned method 2 and method 3, thereby determining a version that is lower than the S version, has been used by the user, and is allowed to be installed in the area where the electronic device is used as the R version.

[0160] It should be noted that the R version determined by the server may be one or more. If there are multiple R versions, the server can filter out one, for example, selecting the latest version from multiple R versions; or the server can send multiple R versions to the electronic device for the user to select one. This embodiment of the present application is not specifically limited to this. The following will mainly illustrate the determination of one R version as an example.

[0161] After determining the R version, the server can feed back the download address of the installation package (ie, the rollback package) of the R version to the electronic device. The electronic device can download the rollback package according to the download address, thereby obtaining the rollback package.

[0162] In some embodiments, the rollback package also includes version information for the R version. After receiving the rollback package, the electronic device can display a second interface including the R version information. The version information includes information such as the version name, version size, version features, and update notes. This makes it easier for users to understand the R version and confirm whether a rollback is necessary.

[0163] Continuing with Figure 11 , in response to the user selecting "Earlier Version" in interface 1101, the phone sends a package search request to the server. After obtaining the rollback package, it may display interface 1102 shown in Figure 11 , which is also the application interface of the mobile assistant application. Interface 1102 includes version information of the R version, such as the version name "YYYYYYYYY (Official Version)", the version size "4.53GB", and the version feature "Improves system stability, making your phone run more stably".

[0164] Furthermore, the second interface includes a restore control (also referred to as a second control), which is used to trigger the electronic device to roll back the operating system to version R, that is, to trigger the electronic device to install the operating system version R. In response to a user's preset operation on the restore control (such as a click operation, a long press operation, etc., also referred to as a second operation), the electronic device can start executing the operation of rolling back to version R, such as executing S1003 and subsequent steps below.

[0165] Continuing with FIG11 , the restore control is the "Restore" button in interface 1102 shown in FIG11 . In response to a user clicking the "Restore" button in interface 1102, the mobile phone can initiate an operation to roll back to version R. In other words, the default operation for the restore control is to click the "Restore" button in interface 1102.

[0166] Of course, in other embodiments, after obtaining the rollback package, the electronic device may also directly start the operation of rolling back to the R version.

[0167] S1003: The electronic device performs a data writing operation on the static partition (B) according to the rollback package to update the static partition (B).

[0168] The rollback package includes the full system data of the R version of the operating system, and further includes system data that needs to be stored in the static partition (also called the first system data) and system data that needs to be stored in the dynamic partition (Super) (also called the second system data).

[0169] In S1003, the electronic device can write the system data in the rollback package that needs to be stored in the static partition into the static partition (B), so that the static partition (B) stores a portion of the system data required by the R version. Furthermore, since the electronic device is currently booted from the static partition (A), writing the system data to the static partition (B) will not affect the current operation of the S version.

[0170] S1004. The electronic device writes the system data of the dynamic partition (Super) into the user data partition (Userdata) according to the rollback package.

[0171] In S1004, the electronic device may write the system data in the rollback package that needs to be stored in the dynamic partition (Super) into the user data partition (Userdata), so that the user data partition (Userdata) stores the other system data required by version R. Furthermore, writing system data to the user data partition (Userdata) rather than the dynamic partition (Super) will not affect the operation of the current version S.

[0172] In some embodiments, the electronic device may create a virtual dynamic partition in the user data partition (Userdata), and write system data of the dynamic partition (Super) into the virtual dynamic partition.

[0173] In the virtual dynamic partition of the user data partition (Userdata), electronic devices can use Copy-On-Write (cow) files to store system data. Multiple cow files can be stored in the virtual dynamic partition, each corresponding to a sub-partition of the dynamic partition (Super). In other words, a cow file stores the system data required to be stored in a sub-partition of the dynamic partition (Super).

[0174] The cow file is named according to the subpartition of the dynamic partition (Super) to which it corresponds. In the rollback package, the cow files for the system data of the dynamic partition (Super) are compressed and stored in binary format. Each cow file is named according to the subpartition of the dynamic partition (Super) to which it corresponds. For example, the cow file corresponding to the system subpartition is named system-cow-img.img.0000.

[0175] In S1004, the electronic device parses the rollback package to obtain all cow files and appends an A / B partition tag to each cow file. Specifically, when the electronic device is currently booted from the static partition (A), it can be understood that the dynamic partition (Super) loaded by the electronic device's current operating system is the dynamic partition (A). Then, the system data stored in the virtual dynamic partition is for the dynamic partition (B). Therefore, the name tag _b corresponding to the dynamic partition (B) is appended to the cow file. For example, appending _b to system-cow-img.img.0000 generates system_b-cow-img.img.0000.

[0176] After writing the cow file to the virtual dynamic partition, the electronic device changes the disk placement status information in the metadata sub-partition of the basic partition (Common) from "merged" to "wait for merge". The disk placement status information is used to indicate whether there is a cow file that needs to be placed on the disk of the dynamic partition (Super). Specifically, the disk placement status information includes an overall identifier for the dynamic partition (Super) and a sub-partition identifier for each sub-partition of the dynamic partition (Super). When the overall identifier is "merged", it means that all sub-partitions of the dynamic partition (Super) do not need to be placed on the disk; when the overall identifier is "wait for merge", it means that one or more sub-partitions of the dynamic partition (Super) need to be placed on the disk; when the sub-partition identifier is "merged", it means that the sub-partition does not need to be placed on the disk; when the sub-partition identifier is "wait for merge", it means that the sub-partition needs to be placed on the disk. That is, the electronic device changes the disk placement status information in the metadata sub-partition of the basic partition (Common) from "merged" to "wait for merge", including: changing the overall identifier to "not yet placed" and changing the sub-partition identifier of each sub-partition to "not yet placed".

[0177] After writing the cow file to the virtual dynamic partition, the electronic device may also create an index for the cow file. The cow file index is used to indicate the name of the cow file and / or the storage location of the cow file in the virtual dynamic partition. The cow file index can be used by the electronic device to subsequently read the cow file from the virtual dynamic partition. For example, the electronic device may create an index for the cow file in the metadata subpartition. Subsequently, the electronic device may read the cow file based on the index for the cow file in the metadata subpartition.

[0178] S1005: The electronic device changes the boot sequence from booting from the static partition (A) to booting from the static partition (B).

[0179] The electronic device currently boots from static partition (A), meaning the boot order is from static partition (A). By changing the boot order from static partition (A) to static partition (B), the electronic device will boot from static partition (B) the next time it boots. This allows it to run under the R version of the operating system.

[0180] Take the Universal Flash Storage (UFS) that uses the Master Boot Record (MBR) format as an example. In the MBR of UFS (Master Boot Sector, the first sector of UFS, that is, the 0th cylinder, 0th head, 1st sector of the C / H / S address), the device boot sequence description is stored. For example, the boot sequence flag is A, indicating that it is booted from the static partition (A); the boot sequence flag is B, indicating that it is booted from the static partition (B). After the device is started, the device boot sequence is first read from the MBR of UFS to determine whether it needs to be booted from the static partition (A) or the static partition (B). Therefore, the electronic device can rewrite the boot sequence flag in the MBR from A to B.

[0181] It should be understood that changing the boot order from static partition (A) to static partition (B) only instructs the electronic device to boot from static partition (B) next time and does not take effect immediately. It will only take effect at the next boot (such as a restart).

[0182] In addition, the execution timing of S1005 is not limited to that shown in FIG. 10 . In actual implementation, the startup sequence can be changed before the electronic device is started next time (such as before the restart in S1006 ).

[0183] It should be noted that during the execution of S1003-S1005, the electronic device is in a standby state, that is, the electronic device can display the third interface for normal use by the user. For example, during the execution of S1003-S1005, the electronic device can normally display interface 1201 shown in Figure 12, which is a video playback interface, and the user can watch the video normally.

[0184] In some embodiments, after the above S1003-S1005 are executed, the electronic device may issue a prompt message to prompt that the electronic device needs to be restarted to roll back to version R. Exemplarily, after the execution of S1003-S1005 is completed, the mobile phone may display the interface 1202 shown in Figure 12, and the interface 1202 includes a prompt message 1203, and the prompt message 1203 specifically reads "The phone needs to be restarted to restore to YYYYYYYYY (official version), do you want to restart immediately!", thereby prompting the user that the phone needs to be restarted to roll back to YYYYYYYYY (official version) version.

[0185] After detecting the reboot confirmation operation, the electronic device can then proceed to S1006, described below, to complete the rollback to version R. Exemplarily, the prompt information is prompt information 1203 in interface 1202 shown in FIG. Prompt information 1203 also includes two options: "Yes" and "No, select another time to reboot." The reboot confirmation operation can be the user selecting the "Yes" option. In response to the user selecting the "Yes" option in prompt information 1203 in interface 1202, the mobile phone can begin executing S1006, described below. Alternatively, the reboot confirmation operation can be the user selecting a reboot time. For example, in response to the user selecting the "No, select another time to reboot" option in prompt information 1203 in interface 1202, the mobile phone can display interface 1204, shown in FIG. Interface 1204 includes a time selection pop-up window 1205, which includes multiple time options, such as 1 minute, 2 minutes, 3 minutes, etc. The operation of selecting the restart time can be an operation in which the user selects any time option (such as 4 minutes) in the time selection pop-up window 1205 and clicks "Confirm". In response to the user's operation of selecting the restart time, the electronic device can start executing the following S1006 after the selected time arrives.

[0186] With this embodiment, the electronic device can restart the electronic device and continue to complete the operation of rolling back to the R version only after the user confirms the restart.

[0187] Of course, in other embodiments, after the electronic device completes the above steps S1003 to S1005, it may proceed to S1006 without user confirmation. This embodiment of the present application does not specifically limit this.

[0188] S1006. The electronic device restarts and enters recovery mode.

[0189] In this application, the electronic device needs to merge the system data in the user data partition (Userdata) into the dynamic partition (Super) in recovery mode. Therefore, this restart also needs to trigger the entry into recovery mode. For example, the electronic device can use the following restart command to control the electronic device to restart and enter recovery mode:

[0190] property_set(ANDROID_RB_PROPERTY, "reboot, recovery").

[0191] Furthermore, since the boot order has been changed from static partition (A) to static partition (B), when the electronic device restarts, it will boot from static partition (B) and enter recovery mode. To ensure normal operation of recovery mode, the electronic device needs to load subpartitions in the base partition (Common) and static partition (B) required to maintain normal operation of recovery mode, such as the recovery subpartition and boot subpartition.

[0192] It should be noted that no matter whether the electronic device obtains a rollback package for rolling back from version S to version R, or obtains an upgrade package for upgrading from version R to version S, it will not distinguish between the rollback package and the upgrade package, but will process them according to the aforementioned processing flow of S1001-S1005.

[0193] However, during a standard upgrade from an R-version operating system to an S-version operating system, after a normal reboot, the system data in the Userdata partition (Userdata) can be written to disk (merged) into the dynamic partition (Super). However, when upgrading from an R-version operating system to an S-version operating system, you need to reboot into recovery mode and, in recovery mode, write the system data in the Userdata partition (Userdata) to disk (merged) into the dynamic partition (Super). In other words, in scenario 1, when rolling back from S-version (S) to R-version (R), you need to reboot into recovery mode.

[0194] Based on this, in some embodiments, after executing the above S1001-S1005, the electronic device needs to determine whether the currently obtained package is a fallback package, and only after determining that it is a fallback package, execute S1006 to merge the system data in the user data partition (Userdata) into the dynamic partition (Super) in recovery mode.

[0195] In a specific implementation, the electronic device may compare the version number carried in the installation package with the version number of the operating system currently running on the electronic device. The installation package includes a rollback package for rolling back from version S to version R or an upgrade package for upgrading from version R to version S.

[0196] If the installation package is a fallback package, the version number carried in the installation package is the R version (also called the first version number), and the version number of the operating system currently running on the electronic device is the S version (i.e., the second version number). The R version is lower than the S version, and accordingly, the R version number is lower than the S version. In other words, if it is a fallback package, it should be used to install an operating system that is a lower version than the version currently running on the electronic device (i.e., the S version), and the version number carried in the installation package is lower than the version number of the operating system currently running on the electronic device.

[0197] If the installation package is an upgrade package, the version number carried in the installation package is version S, and the version number of the operating system currently running on the electronic device is version R. Version S is higher than version R, so accordingly, the version number of version S is higher than the version number of version R. In other words, if it is an upgrade package, the version number carried in the installation package is higher than the version number of the operating system currently running on the electronic device.

[0198] Therefore, in this implementation, if the version number carried in the installation package is lower than the version number of the operating system currently running on the electronic device, the electronic device can determine that the installation package is a fallback package. If the version number carried in the installation package is higher than the version number of the operating system currently running on the electronic device, the electronic device can determine that the installation package is an upgrade package.

[0199] In addition, if the version number carried in the installation package is equal to the version number of the operating system currently running on the electronic device, it indicates that the installation package is incorrect, and processing of the installation package is stopped.

[0200] Of course, in actual implementation, the above-mentioned method of determining a fallback package by comparing version numbers is not used as an example. Those skilled in the art can distinguish between fallback packages and upgrade packages based on actual needs. For example, the server can add a fallback mark to the fallback package. The electronic device can determine whether the installation package is a fallback package by identifying whether the fallback mark is included in the installation package.

[0201] Accordingly, referring to FIG. 13 , before S1006 , the following steps are further included: S1301 :

[0202] S1301: The electronic device determines that the currently obtained package is a fallback package.

[0203] Among them, it is determined to be a rollback package, that is, it is determined to be scenario 1 of rolling back from version S to version R.

[0204] That is, in this embodiment, the system will only restart and enter the recovery mode if it is determined that the package obtained is a rollback package, thereby avoiding mistakenly entering the recovery mode when the package obtained is an upgrade package.

[0205] In scenario 1, after the electronic device enters the recovery mode, it can execute the following S1007-S1009 in the recovery mode to continue to complete the process of rolling back to the R version.

[0206] S1007: The electronic device writes the system data in the user data partition (Userdata) to the dynamic partition (Super).

[0207] In the description of the embodiments of the present application, the disk write operation refers to writing the system data (cow file) of the dynamic partition (Super) saved in the user data partition (Userdata) into the dynamic partition (Super), so that the file of the dynamic partition (Super) completes the data update, so that the electronic device can complete the startup of the electronic device by loading the dynamic partition (Super) when it is started next time.

[0208] In some embodiments, after entering the recovery mode, the electronic device can read the disk write status information and the index of the cow file, and complete the disk write process based on the disk write status information and the index of the cow file.

[0209] By reading the disk-falling status information, the electronic device can determine whether it is necessary to retrieve the cow file corresponding to the corresponding sub-partition from the user data partition (Userdata). Specifically, when the overall identification of the disk-falling status information is read as "fallen to disk", it is determined that there is no need to retrieve the cow files corresponding to all sub-partitions from the user data partition (Userdata). When the overall identification of the disk-falling status information is read as "not fallen to disk", the sub-partition identification for each sub-partition in the disk-falling status information can be further read. If the sub-partition identification is "fallen to disk", it is determined that there is no need to retrieve the cow file corresponding to the corresponding sub-partition from the user data partition (Userdata). If the sub-partition identification is "not fallen to disk", it is determined that the cow file corresponding to the corresponding sub-partition needs to be retrieved from the user data partition (Userdata).

[0210] Then, by reading the index of the cow file, the electronic device can obtain the file name and / or storage location of the cow file, thereby retrieving the corresponding cow file from the user data partition (Userdata).

[0211] Finally, the electronic device writes the cow file retrieved from the user data partition (Userdata) to the corresponding sub-partition of the dynamic partition (Super), completing the disk write process of the dynamic partition (Super).

[0212] By using S1007, the system data stored in the user data partition (Userdata) can be merged to the dynamic partition (Super), so that the R version of the system data can be stored in the dynamic partition (Super), ensuring that the R version of the operating system can be successfully run subsequently.

[0213] In practice, entering recovery mode can perform various operations on the data or operating system within an electronic device. For example, you can modify the electronic device's standard, changing the demonstration standard to a commercial standard. For another example, you can use recovery mode to adjust the partition table. For another example, in this application, recovery mode is used to roll back from version S to version R.

[0214] Based on this, in some embodiments, after entering recovery mode, the electronic device first needs to determine the purpose of entering recovery mode, so as to accurately perform the corresponding processing to achieve the purpose. Therefore, in this application, it is necessary to determine whether the current scene is a rollback scenario, so as to accurately perform the process of rolling back from version S to version R.

[0215] In a specific implementation, after the electronic device determines that it is a fallback package in the aforementioned S1301, it can write a preset identifier in subpartition A (also referred to as a preset subpartition) to indicate that the current scenario is a fallback scenario. Wherein, subpartition A is a partition that can be accessed in recovery mode. For example, subpartition A is the Misc subpartition of the basic partition (Common).

[0216] Then, after entering the recovery mode, the electronic device can read a preset identifier from sub-partition A. If the preset identifier is read, it is determined that the current scene is the fallback scene. If the preset identifier is not read, it is determined that the current scene is not the fallback scene.

[0217] For example, in scenario 1, after determining that it is a fallback package in S1301, the electronic device can write a preset identifier in subpartition A. Accordingly, after S1006, the electronic device reads the preset identifier from subpartition A and can determine that the current scenario is a fallback scenario.

[0218] Of course, in actual implementation, it is not limited to the method of reading the preset identifier from subpartition A to determine whether the current scene is a fallback scene. Those skilled in the art can adopt corresponding technologies to identify the fallback scene according to actual needs. Exemplarily, the electronic device can also store the installation package in a preset directory accessible to the recovery mode before restarting to enter the recovery mode. After entering the recovery mode, the installation package can be parsed from the preset directory. If the installation package includes a fallback indication, it is determined that the current scene is a fallback scene. If the installation package does not include a fallback identifier, it is determined that the current scene is not a fallback scene.

[0219] Accordingly, referring to FIG. 13 , after entering the recovery mode, before S1007 , the process further includes S1302 :

[0220] S1302: The electronic device recognizes that the current scene is a fallback scene.

[0221] That is, in this embodiment, only when a rollback scenario is identified, the merge and subsequent processing are further executed, thereby avoiding the erroneous execution of the merge and other processing in the recovery mode in a scenario where a rollback is not required, which ultimately affects the system operation.

[0222] S1008. The electronic device synchronizes the system data in the static partition (B) to the static partition (A).

[0223] In some embodiments, after completing the merge, the electronic device can also synchronize the system data stored in each sub-partition in the static partition (B) with the corresponding sub-partition in the static partition (A), so that the static partition (A) also stores the R version of the system data. Then, when the static partition (A) is booted from there, the R version of the operating system can also be run.

[0224] For example, referring to FIG14 , before synchronization, the static partition (A) stores system data of version V3.0, and the static partition (B) stores system data of version V2.0. Through synchronization, the system data of version V2.0 in the static partition (B) can be synchronized to the static partition (A), so that the static partition (A) also stores system data of version V2.0. Continuing to refer to FIG14 , after synchronization, both the static partition (A) and the static partition (B) contain system data of version V2.0.

[0225] S1009. Restore the electronic device to factory settings.

[0226] Restoring the factory settings includes formatting the user data partition (Userdata), the cache subpartition in the basic partition (common), and the metadata subpartition.

[0227] After the merge process is completed, the electronic device is restored to factory settings and the user data partition (Userdata) can be formatted so that no data that needs to be decrypted before being accessed is stored in the user data partition (Userdata).

[0228] At this point, it should be noted that, unlike the standby state, electronic devices cannot be used normally in recovery mode. Exemplarily, after restarting and entering recovery mode, the mobile phone can display interface 1501 (also referred to as the fourth interface) shown in Figure 15. Interface 1501 includes the progress of rolling back to version R in recovery mode (also referred to as progress prompt information), that is, the execution progress of S1007-S1009. For example, the progress displayed in interface 1501 is 0%. And, when the progress reaches 100% in interface 1502 shown in Figure 15, it indicates that S1007-S1009 has been executed. Among them, interface 1501 and interface 1502 are both inoperable and cannot be used normally by users.

[0229] In the recovery mode, after the above S1007-S1009 are completed, the electronic device can execute the following S1010, so that the electronic device can run under the R version operating system.

[0230] S1010. Restart the electronic device.

[0231] For example, the electronic device may use the following restart instruction to control the electronic device to restart:

[0232] property_set(ANDROID_RB_PROPERTY, "reboot").

[0233] It should be noted that, unlike the restart in S1006 , the restart in S1010 is a normal restart, so after the restart, the electronic device will enter a normal use state instead of entering a recovery mode.

[0234] S1011. The electronic device sequentially loads the basic partition (Common), the static partition (B), and the dynamic partition (Super), and boots from the static partition (B).

[0235] Since the boot sequence has been changed to boot from the static partition (B), the electronic device will boot from the static partition (B).

[0236] S1012. The electronic device successfully mounts the user data partition (Userdata), enters the user interaction interface, and runs under the R version operating system.

[0237] The static partition (B) and the dynamic partition (Super) both store the R version of the system data. Loading the static partition (B) and the dynamic partition (Super) is equivalent to loading the R version of the operating system. At the same time, there is no longer any data in the user data partition (Userdata) that needs to be decrypted to access, and there will be no problem of being unable to load, so that the electronic device can be successfully started. Ultimately, the electronic device can successfully run under the R version of the operating system. Exemplarily, after starting from the static partition (B), the electronic device can display the interface 1503 shown in Figure 15, and the interface 1503 is the mobile phone desktop.

[0238] The following further describes a specific implementation of downloading the rollback package (such as S1002 in Figures 10 and 13) to completing the rollback (such as S1010 in Figures 10 and 13) in Scenario 1 in combination with the software composition of the electronic device.

[0239] Specifically, referring to FIG16 , the specific implementation of scenario 1 includes:

[0240] S1601. ouc apk downloads the rollback package, which includes the version number of version R. For details, please refer to the description of S1002 above.

[0241] S1602. ouc apk sends a rollback package to the update engine.

[0242] S1603: The update engine writes data to the static partition (B) according to the rollback package to update the static partition (B). For details, please refer to the description of S1003 above.

[0243] S1604: The update engine writes the system data of the dynamic partition (Super) into the user data partition (Userdata) according to the rollback package. For details, please refer to the description of S1004 above.

[0244] S1605: The update engine changes the boot sequence from static partition (A) to static partition (B). For details, please refer to the description of S1005 above.

[0245] S1606: The update engine compares the version number of the R version with the version number of the currently running S version to determine that the currently acquired package is a fallback package. For details, please refer to the description of S1301 and its context above.

[0246] S1607: The update engine writes a preset identifier in sub-partition A to indicate that the current scenario is a fallback scenario.

[0247] For example, the update engine writes a preset identifier in the Misc sub-partition of the base partition (Common), that is, sub-partition A is the Misc sub-partition of the base partition (Common). For details, please refer to the above description of S1302 and its context.

[0248] S1608: The update engine triggers a restart and enters recovery mode. For details, see the description of S1006 above.

[0249] That is to say, only when it is determined that the current package obtained is a fallback package, will it restart and enter the recovery mode.

[0250] S1609: The recovery process reads a preset identifier from subpartition A.

[0251] If a preset flag is read from sub-partition A, it indicates that the current scenario is a fallback scenario. For details, please refer to the above description of S1302 and its context.

[0252] S1610: The recovery process triggers the start of the merge service.

[0253] S1611. The merge service writes the data of the virtual dynamic partition to the dynamic partition (Super).

[0254] In other words, the merge service completes the disk write process. For details, please refer to the description of S1007 above.

[0255] S1612: The recovery process synchronizes the data in the static partition (B) to the static partition (A). For details, please refer to the description of S1008 above.

[0256] S1613: The recovery process formats the user data partition (Userdata). For details, please refer to the description of S1009 above.

[0257] S1614: The recovery process triggers a restart. For details, see the description of S1010 above.

[0258] Scenario 2: Upgrading from version R of the operating system to version S of the operating system, where version R is lower than version S. That is, the scenario of upgrading from a lower version of the operating system to a higher version of the operating system can also be referred to as an upgrade scenario. For ease of explanation, version R in scenario 2 can be referred to as the third version, and version S can be referred to as the first version. It should be understood that version R in scenario 2 can be the same as or different from version R in scenario 1. This embodiment of the present application does not specifically limit this.

[0259] In scenario 2, the electronic device can write the system data of the S version operating system in standby mode. Moreover, since it is an upgrade from a lower version operating system to a higher version operating system, the key of the higher version operating system can be used to decrypt the encrypted data in the user data partition (Userdata). Therefore, after writing the system data of the S version operating system, the electronic device can be directly restarted and run under the S version operating system. There is no need to complete the disk processing and format the user data partition (Userdata) in recovery mode, and then restart the electronic device to run the S version operating system.

[0260] Referring to FIG. 17 , taking the electronic device currently booting from the static partition (A) as an example, in scenario 2, the process of upgrading from the R version operating system to the S version operating system includes the following steps:

[0261] S1701. The electronic device sequentially loads the basic partition (Common), the static partition (A), and the dynamic partition (Super), starts from the static partition (A), and runs under the R version of the operating system.

[0262] For ease of explanation, the static partition (A) in scenario 2 may be referred to as the second static partition, and the static partition (B) may be referred to as the first static partition.

[0263] S1702: The electronic device obtains the S version upgrade package.

[0264] The S version upgrade package can also be called the second installation package. Similar to the rollback package mentioned above, the upgrade package also includes system data that needs to be stored in the static partition (also called the third system data) and system data that needs to be stored in the dynamic partition (Super) (also called the fourth system data).

[0265] For example, the electronic device may periodically initiate a package search request to the server, where the package search request includes the version number of the operating system currently running on the electronic device, such as version number V1.0. The server searches for an installation package for an updated operating system (e.g., an installation package for an operating system version 2.0, also referred to as an upgrade package) based on the version number in the package search request. If an upgrade package exists, the server feeds back the download address of the upgrade package to the electronic device. The electronic device downloads the installation package based on the download address.

[0266] S1703: The electronic device performs a data writing operation on the static partition (B) according to the upgrade package to upgrade the static partition (B).

[0267] Exemplarily, the third system data is written to the static partition (B).

[0268] S1704: The electronic device writes the system data of the dynamic partition (Super) into the user data partition (Userdata) according to the upgrade package.

[0269] Exemplarily, the fourth system data is written to the user data partition (Userdata).

[0270] The specific implementation of S1703-S1704 can be found in the description of S1003-S1004 above, which will not be repeated here. The main difference is that the data in the rollback package and the upgrade package are different.

[0271] S1705: The electronic device changes the boot sequence from booting from static partition (B) to booting from static partition (B). For details, please refer to the description of S1005 above.

[0272] S1706: The electronic device determines that the currently acquired packet is not a rollback packet. For details, please refer to the above description of S1301 and its context.

[0273] For example, the installation package carries the version number of version S, and the version number of the operating system currently running on the electronic device is the version number of version R (also known as the third version number). The version number of version S is higher than the version number of version R. That is, the version number carried in the installation package is higher than the version number of the operating system currently running on the electronic device. Then, the electronic device can determine that the currently obtained package is not a fallback package, that is, the installation package is not used to install an operating system version lower than version R.

[0274] S1707. Restart the electronic device.

[0275] In scenario 2, it is determined that the obtained package is not a fallback package, so there is no need to restart and enter recovery mode, but just restart normally.

[0276] In addition, unlike S1006 above, the restart in S1707 is usually a hardware restart. For example, the user long presses the power button to trigger the restart. In this way, the electronic device can be triggered to restart when the user does not need to use the electronic device.

[0277] S1708. The electronic device sequentially loads the basic partition (Common) and the static partition (B), and boots from the static partition (B).

[0278] S1709: The electronic device loads the dynamic partition (Super) and the user data partition (Userdata).

[0279] Exemplarily, the electronic device uses snapshot to merge and load the dynamic partition (Super) and the cow file (ie, the fourth system data) retrieved from the user data partition (Userdata).

[0280] S1710: The electronic device successfully mounts the user data partition (Userdata), enters the user interface, and runs under the R version operating system.

[0281] Since the upgrade is from R version to S version, the keys are compatible, so the user data partition can be mounted successfully.

[0282] S1711. The electronic device writes the system data in the user data partition (Userdata) to the dynamic partition (Super).

[0283] Exemplarily, the fourth system data in the user data partition is written into the dynamic partition (Super).

[0284] For the specific implementation of the above S1708-S1711, please refer to the description of the relevant existing technologies of virtual A / B upgrade, which will not be repeated here.

[0285] S1712: The electronic device synchronizes the data in the static partition (B) to the static partition (A). For details, please refer to the description of S1008 above.

[0286] In scenario 3, the electronic device is currently running the R version operating system and enters recovery mode in a different situation than scenario 1.

[0287] For ease of explanation, the R version in scenario 3 may be referred to as the second version.

[0288] Among them, situations other than scenario 1 (also called preset events) refer to situations other than scenario 1 where corresponding processing needs to be completed in recovery mode, including but not limited to any of the following situations: situations where the user manually enters recovery mode to flash the device, restore factory settings, etc.; situations where recovery mode is entered to implement the change when there is a need for change (from demonstration format to commercial format); and situations where recovery mode is entered to change the data storage structure when the data storage structure needs to be modified.

[0289] In scenario 3, after the electronic device restarts and enters recovery mode, it will determine that the current scenario is not a fallback scenario, that is, it determines that the purpose of entering the repair mode this time is not to install an operating system version lower than the first version. For example, since the recovery mode is not entered after the fallback package is obtained, the preset identifier will not be recorded in subpartition A. Accordingly, in recovery mode, the electronic device will not read the preset identifier from subpartition A, thereby determining that it is not a fallback scenario. Then, after entering recovery mode, the dynamic partition (Super) will not be written to the disk and the user data partition (Userdata) will not be formatted. Instead, the corresponding processing will be completed based on other identified purposes. For example, if the scenario is identified as modifying the data storage structure, then in recovery mode, the electronic device can perform the operation of modifying the data storage structure. For another example, if the scenario is identified as a reformatting scenario, then in recovery mode, the electronic device can perform the operation of changing the demonstration format to the commercial format.

[0290] An embodiment of the present application further provides an electronic device, which may include a memory and one or more processors. The memory and processor are coupled. The memory is used to store computer program code, which includes computer instructions. When the processor executes the computer instructions, the electronic device performs each step of the above embodiment. Of course, the electronic device includes but is not limited to the above memory and one or more processors.

[0291] The embodiment of the present application also provides a chip system, which can be applied to the electronic devices in the aforementioned embodiments. As shown in Figure 18, the chip system includes at least one processor 1801 and at least one interface circuit 1802. The processor 1801 can be the processor in the above-mentioned electronic device. The processor 1801 and the interface circuit 1802 can be interconnected via a line. The processor 1801 can receive and execute computer instructions from the memory of the above-mentioned electronic device through the interface circuit 1802. When the computer instructions are executed by the processor 1801, the electronic device can execute the various steps in the above-mentioned embodiments. Of course, the chip system can also include other discrete devices, which is not specifically limited in the embodiment of the present application.

[0292] In some embodiments, through the description of the above embodiments, those skilled in the art can clearly understand that for the convenience and brevity of description, only the division of the above functional modules is used as an example. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. The specific working process of the system, device and unit described above can refer to the corresponding process in the aforementioned method embodiment and will not be repeated here.

[0293] The functional units in the various embodiments of the present application may be integrated into a single processing unit, or each unit may exist physically separately, or two or more units may be integrated into a single unit. The aforementioned integrated units may be implemented in the form of hardware or software functional units.

[0294] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the embodiment of the present application is essentially or the part that contributes to the prior art or all or part of the technical solution can be embodied in the form of a software product, and the computer software product is stored in a storage medium, including a number of instructions for enabling a computer device (which can be a personal computer, a server, or a network device, etc.) or a processor to perform all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes: various media that can store program codes, such as flash memory, mobile hard disk, read-only memory, random access memory, magnetic disk or optical disk.

[0295] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any changes or substitutions within the technical scope disclosed in the present invention should be included in the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be based on the scope of protection of the claims.

Claims

1. A method for upgrading an operating system, characterized in that: Applied to an electronic device, the electronic device includes a memory, the memory includes a basic partition, a first static partition, a second static partition, a dynamic partition, and a user data partition, the method comprising: Loading the basic partition, the first static partition, and the dynamic partition, and running a first version of an operating system; Obtaining a first installation package, where the first installation package is an installation package of a second version of an operating system, the second version being lower than the first version, and the first installation package includes first system data and second system data of the second version of the operating system; Writing the first system data into the second static partition and writing the first system data into the user data partition; Restart and enter repair mode; In the repair mode, writing the second system data in the user data partition to the dynamic partition, and formatting the user data partition; Restart, load the basic partition, the second static partition, and the dynamic partition, and run the second version of the operating system.

2. The method according to claim 1, characterized in that Before restarting and entering the repair mode, the method further includes: It is determined that the first installation package is used to install an operating system of a version lower than the first version.

3. The method according to claim 2, characterized in that The first installation package includes a first version number, where the first version number is the version number of the second version. Determining that the first installation package is used to install an installation package of an operating system of a version lower than the first version includes: It is determined that the first version number is lower than a second version number, and the second version number is the version number of the first version.

4. The method according to claim 2 or 3, characterized in that After determining that the first installation package is used to install an operating system of a version lower than the first version, the method further includes: Recording a preset identifier in a preset subpartition, where the preset subpartition is a subpartition accessible in the repair mode; Writing the second system data in the user data partition to the dynamic partition and formatting the user data partition in the repair mode includes: In the repair mode, if the preset identifier is read from the preset sub-partition, the second system data in the user data partition is written to the dynamic partition to format the user data partition.

5. The method according to any one of claims 1 to 4, characterized in that Before obtaining the first installation package, the method further includes: Displaying a first interface, wherein the first interface includes a first control; In response to a first operation of the user on the first control, sending a packet search request to a server; Receiving a download address fed back by the server based on the packet search request; The obtaining of the first installation package includes: The first installation package is downloaded based on the download address.

6. The method according to any one of claims 1 to 5, characterized in that After obtaining the first installation package, the method further includes: Displaying a second interface, the second interface including version information of the second version of the operating system and a second control, the second control being used to trigger installation of the second version of the operating system; Writing the first system data into the second static partition and writing the first system data into the user data partition includes: In response to a second operation of the user on the second control, the first system data is written to the second static partition, and the first system data is written to the user data partition.

7. The method according to any one of claims 1 to 6, characterized in that After writing the second system data in the user data partition into the dynamic partition, the method further includes: Synchronize the first system data in the second static partition to the first static partition.

8. The method according to any one of claims 1 to 7, characterized in that During the process of writing the first system data into the second static partition and writing the first system data into the user data partition, the method further includes: A third interface is displayed, where the third interface is an interface of the electronic device in a standby state.

9. The method according to any one of claims 1 to 8, characterized in that In the repair mode, writing the second system data in the user data partition into the dynamic partition, and formatting the user data partition, the method further includes: A fourth interface is displayed, wherein the fourth interface includes progress prompt information, wherein the progress prompt information is used to prompt the progress of disk downloading and formatting; wherein the electronic device will not respond to the user's operation on the fourth interface.

10. The method according to any one of claims 1 to 9, characterized in that The restart and entering the repair mode includes: Reboot and start the repair process; Writing the second system data in the user data partition into the dynamic partition in the repair mode includes: The repair process triggers the start of a write-to-disk service, and the write-to-disk service writes the second system data in the user data partition to the dynamic partition; The repair process formats the user data partition.

11. The method according to any one of claims 1 to 10, characterized in that The second version satisfies at least one of the following conditions: The second version is a preset version; The second version is higher than the version of the operating system installed on the electronic device when it leaves the factory; The second version is a version that is allowed to be installed in the region where the electronic device is used.

12. The method according to any one of claims 1 to 11, characterized in that Before loading the basic partition, the first static partition, and the dynamic partition and running the first version of the operating system, the method further includes: Loading the basic partition, the second static partition, and the dynamic partition, and running a third version of an operating system, where the third version is lower than the first version; Obtaining a second installation package, where the second installation package is used to upgrade to the first version of the operating system, and the second installation package includes third system data and fourth system data of the first version of the operating system; Writing the third system data into the first static partition and writing the fourth system data into the user data partition; Restart; The step of loading the basic partition, the first static partition, and the dynamic partition, and running the first version of the operating system includes: The fourth system data in the basic partition, the first static partition, the dynamic partition, and the user data partition is loaded, and the first version of the operating system is run.

13. The method according to claim 12, characterized in that After loading the basic partition, the first static partition, the dynamic partition, and the user data partition, and running the first version of the operating system, the method further includes: The fourth system data in the user data partition is written into the dynamic partition.

14. The method according to claim 12 or 13, characterized in that Before the restart and loading of the basic partition, the first static partition, the dynamic partition, and the user data partition, the method further includes: It is determined that the second installation package is not used to install an operating system of a version lower than the third version.

15. The method according to claim 14, characterized in that The second installation package includes a second version number, where the second version number is the version number of the first version. Determining that the second installation package is not used to install an operating system of a version lower than the third version includes: It is determined that a third version number is lower than the second version number, and the third version number is the version number of the third version.

16. The method according to any one of claims 1 to 15, characterized in that After loading the basic partition, the second static partition, and the dynamic partition, and running the second version of the operating system, the method further includes: In response to a preset event, the system restarts and re-enters the repair mode; wherein, if it is determined that the repair mode is not entered again for the purpose of installing an operating system of a version lower than the first version, the data in the user data partition will not be written into the dynamic partition.

17. An electronic device, characterized in that: The electronic device includes a processor and a memory, the memory includes a basic partition, a first static partition, a second static partition, a dynamic partition and a user data partition, and the processor is used to execute the software code stored on the memory so that the electronic device executes the method described in any one of claims 1-16.

18. A computer-readable storage medium, characterized in that The computer-readable storage medium stores a computer program, which, when executed on an electronic device, enables the electronic device to execute the method according to any one of claims 1 to 16.

19. A chip system, characterized in that: The chip system is applied to an electronic device including a processor and a memory. The chip system includes one or more interface circuits and one or more processors. The interface circuit and the processor are interconnected through lines. The interface circuit is used to receive a signal from the memory of the electronic device and send the signal to the processor. The signal includes a computer instruction stored in the memory. When the processor executes the computer instruction, the electronic device executes the method as described in any one of claims 1 to 16.

Images