WO2024131151A1 - 一种操作系统的升级方法及电子设备 - Google Patents

一种操作系统的升级方法及电子设备 Download PDF

Info

Publication number
WO2024131151A1
WO2024131151A1 PCT/CN2023/117785 CN2023117785W WO2024131151A1 WO 2024131151 A1 WO2024131151 A1 WO 2024131151A1 CN 2023117785 W CN2023117785 W CN 2023117785W WO 2024131151 A1 WO2024131151 A1 WO 2024131151A1
Authority
WO
WIPO (PCT)
Prior art keywords
partition
version
electronic device
operating system
data
Prior art date
Application number
PCT/CN2023/117785
Other languages
English (en)
French (fr)
Inventor
李亚茹
Original Assignee
荣耀终端有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 荣耀终端有限公司 filed Critical 荣耀终端有限公司
Publication of WO2024131151A1 publication Critical patent/WO2024131151A1/zh

Links

Definitions

  • the present application relates to the field of computer technology, and in particular to an operating system upgrade method and electronic equipment.
  • OTA Over-the-Air Technology
  • V1.0 low version
  • V2.0 high version
  • OTA is a technology that remotely upgrades the operating system version through the wireless network interface of the electronic device.
  • users may not have a good experience with the upgraded higher version of the operating system.
  • the user is used to using a lower version of the operating system and does not find the upgraded higher version of the operating system easy to use. Then, the user may want to roll back from the higher version of the operating system to the lower version of the operating system.
  • the inventors found in the process of implementing 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 of the operating system, the user can only take the electronic device to a fixed outlet, and then the staff of the outlet will perform the rollback operation to roll back the operating system to the lower version.
  • the present application provides an operating system upgrade method and electronic device, which can obtain a rollback package for rolling back a high version to a low version, and automatically complete the process of rolling back to the low version of the operating system without having to take it to a network point for the rollback.
  • 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.
  • the basic partition, the first static partition, and the dynamic partition are loaded, and the first version of the operating system is run.
  • 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
  • the first installation package includes the first system data and the second system data of the second version of the operating system.
  • 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.
  • the electronic device when rolling back from a higher version of the operating system to a lower version of the operating system, the electronic device writes the lower version of the system data to the static partition and the user data partition in the standby state, 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 low-version system data can be successfully loaded, and the user data partition that does not need to be decrypted can be successfully loaded, so that the low-version operating system can be successfully run.
  • the method 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.
  • the system will restart and enter the repair mode only when it is determined that a rollback is necessary, thereby avoiding the situation where the system mistakenly enters the repair mode when a rollback is not necessary.
  • 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.
  • 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, it is a scenario of rolling back to a lower version.
  • the method further includes: recording a preset identifier in a preset sub-partition, the preset sub-partition being a sub-partition accessible in the repair mode.
  • the repair mode writing the second system data in the user data partition to the dynamic partition, formatting the user data partition, including: in the repair mode, if the preset identifier is read from the preset sub-partition, writing the second system data in the user data partition to the dynamic partition, formatting the user data partition.
  • the method before obtaining the first installation package, further includes: displaying a first interface, wherein the first interface includes a first control.
  • sending a package search request to a server In response to a first operation of the user on the first control, sending a package search request to a server.
  • obtaining the first installation package includes: downloading the first installation package based on the download address.
  • the user can actively trigger the acquisition of the first installation package on the electronic device.
  • the first installation package can be acquired and rolled back, accurately meeting the user's needs.
  • 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 the 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: in response to a second operation of the user on the second control, writing the first system data to the second static partition and writing the first system data to the user data partition.
  • 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.
  • the method further includes: synchronizing the first system data in the second static partition to the first static partition.
  • the first static partition can also store low-version system data. Then, when booting from the first static partition thereafter, the low-version operating system can also be run.
  • the method when writing the first system data to the second static partition, During the process of writing the user data partition into the first system data, the method further includes: displaying a third interface, where the third interface is an interface of the electronic device in a standby state.
  • 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.
  • 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 placement and formatting; wherein, the electronic device will not respond to the user's operations on the fourth interface.
  • restarting and entering the repair mode includes: restarting and starting a repair process.
  • writing the second system data in the user data partition to the dynamic partition 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 userdata partition.
  • the second system data in the user data partition can be written to the dynamic partition by pulling up the disk drop service.
  • the second version satisfies at least one of the following conditions:
  • the second version is a preset version. In this way, it can be ensured that the version to which the device is rolled back is not too old or has a lot of vulnerabilities.
  • the second version is higher than the version of the operating system installed when the electronic device leaves the factory. In this way, it can be ensured that the device will not roll back to a version that has not been installed on the electronic device, that is, a version that the user has not used.
  • the second version is a version that is allowed to be installed in the area where the electronic device is used. In this way, it can be guaranteed to roll back to the version that is allowed to be installed in the electronic device.
  • the method 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 the third version of the operating system, the third version being 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.
  • Loading the basic partition, the first static partition and the dynamic partition, and running the first version of the operating system includes: loading the basic partition, the first static partition, the dynamic partition, and the fourth system data in the user data partition, and running the first version of the operating system.
  • the first version of the operating system in the electronic device is upgraded from the third version of the operating system.
  • the higher version of the operating system can be run by a normal restart.
  • the method further includes: writing the fourth system data in the user data partition into the dynamic partition.
  • the method 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.
  • the method further includes: in response to a preset event, restarting and re-entering the repair mode; wherein, if it is determined that re-entering the repair mode is not for installing an operating system of a version lower than the first version, then the data in the user data partition will not be written into the dynamic partition. In this way, the corresponding processing can be accurately performed based on the purpose of entering the repair mode.
  • the present application further provides an electronic device, the electronic device comprising a processor and a memory, the memory comprising a basic partition, a first static partition, a second static partition, a dynamic partition, and a user data partition.
  • the processor is used 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.
  • 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.
  • an embodiment of the present application further provides a computer storage medium, which includes computer instructions.
  • the 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 thereof.
  • 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.
  • FIG1 is a schematic diagram of a rollback scenario applicable to an embodiment of the present application.
  • FIG2 is a schematic diagram of a data storage structure provided in an embodiment of the present application.
  • FIG3 is a flowchart of an operating system upgrade
  • FIG4 is a flowchart of another operating system upgrade
  • FIG5 is a schematic diagram of an operating system upgrade process
  • FIG6 is one of the principle diagrams of the upgrade process of the operating system provided in an embodiment of the present application.
  • FIG. 7 is a second schematic diagram of the upgrade process of the operating system provided in an embodiment of the present application.
  • FIG8 is a hardware structure diagram of an electronic device provided in an embodiment of the present application.
  • FIG9 is a software structure diagram of an electronic device provided in an embodiment of the present application.
  • FIG10 is one of the upgrade flow charts of the operating system provided in an embodiment of the present application.
  • FIG11 is a schematic diagram of a mobile phone interface according to an embodiment of the present application.
  • FIG12 is a second schematic diagram of a mobile phone interface provided in an embodiment of the present application.
  • FIG13 is a second flowchart of an operating system upgrade provided in an embodiment of the present application.
  • FIG14 is a third schematic diagram of the operating system upgrade process provided in an embodiment of the present application.
  • FIG15 is a third schematic diagram of a mobile phone interface provided in an embodiment of the present application.
  • FIG16 is an interactive diagram of an operating system upgrade process provided in an embodiment of the present application.
  • FIG17 is a third flowchart of an operating system upgrade provided in an embodiment of the present application.
  • FIG18 is a structural diagram of a chip system provided in an embodiment of the present application.
  • An embodiment of the present application provides an operating system upgrade method, which can be applied to a scenario in which the operating system in an electronic device needs to be rolled back from a higher version to a lower version.
  • the operating system of the mobile phone can be upgraded from version V1.0 to version V2.0.
  • the operating system can be rolled back from version V2.0 to version V1.0.
  • the operating system of the mobile phone can also continue to be upgraded from version V2.0 to version V3.0.
  • the operating system can be rolled back from version V3.0 to version V2.0, or from version V3.0 to version V1.0.
  • the system data of the operating system is stored in the memory of the electronic device.
  • the memory usually includes read-only memory (ROM) and random access memory (RAM).
  • ROM read-only memory
  • RAM random access memory
  • main memory It can be read and written at any time, and the speed is very fast. It is usually used as a temporary data storage medium for operating systems or other running programs. When the power is turned off, RAM cannot retain data. That is, RAM usually stores temporary data when the electronic device is running.
  • ROM can also be called “non-volatile memory”.
  • the data stored in it is generally written in advance before loading into the whole machine, as well as user data generated when the user uses the electronic device. It can only be read out during the operation of the whole machine, and cannot be quickly and conveniently rewritten like RAM. Therefore, the data stored in ROM is stable and the stored data will not change after power failure.
  • the system data of the operating system is usually stored in ROM to ensure the stability of the system data.
  • 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.
  • 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).
  • the user data partition (Userdata) is used to store the user's personal data, such as applications (APP) installed by the user, pictures, documents, and videos saved by the user.
  • the data stored in the basic partition (Common) is system data that does not participate in the operating system upgrade.
  • the structures of the static partition (A) and the static partition (B) correspond to each other, and the sub-partition names are distinguished from each other by the suffixes _a and _b.
  • the sub-partitions in the static partition (A) include bootloader_a, boot_a, and vendor_boot_a
  • the sub-partitions in the static partition (B) include bootloader_b, boot_b, and vendor_boot_b.
  • the dynamic partition (Super) contains multiple sub-partitions, such as System, system_ext, vendor, product, Cust, and Odm.
  • the data storage structure shown in FIG2 is only exemplary.
  • the basic partition (Common) in the data storage structure may further include multiple sub-partitions, such as cache sub-partitions, Misc sub-partitions, and cache sub-partitions. Sub-partitions, etc.
  • the static partition (A), static partition (B) and dynamic partition (Super) in the data storage structure may include more or fewer sub-partitions than those shown in FIG2.
  • the static partition (A) may also include sub-partitions such as Patch_a, dtbo_a, and vbmeta_a, and correspondingly, the static partition (B) may also include sub-partitions such as Patch_b, dtbo_b, and vbmeta_b.
  • the dynamic partition (Super) may also include sub-partitions such as version and preload.
  • an electronic device When an electronic device starts, it needs to start from a static partition. For example, if the electronic device starts from the static partition (A), the basic partition (Common), static partition (A) and dynamic partition (Super) are loaded in sequence. For another example, if the electronic device starts from the static partition (B), the basic partition (Common), static partition (B) and dynamic partition (Super) are loaded in sequence.
  • the electronic device when it is necessary to upgrade from a low version operating system to a high version operating system, the electronic device can use the virtual A/B upgrade solution to achieve the upgrade.
  • the virtual A/B upgrade solution is used to upgrade the operating system of the electronic device from the currently running low version (such as R version) to a high version (such as S version), including:
  • the electronic device loads the basic partition (Common), the static partition (A), and the dynamic partition (Super) in sequence, and runs under the R version of the operating system.
  • the basic partition Common
  • the static partition A
  • the dynamic partition Super
  • the upgrade package includes system data upgraded to S version.
  • 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.
  • the electronic device can load the static partition (B) to load a part of the system data required for version S. Also, the electronic device can load the system data in the dynamic partition (Super) and the system data in the user data partition (Userdata) based on the snapshot technology (snapshot) to load another part of the system data required for version S.
  • the static partition B
  • the electronic device can load the system data in the dynamic partition (Super) and the system data in the user data partition (Userdata) based on the snapshot technology (snapshot) to load another part of the system data required for version S.
  • the user's personal data such as applications, pictures, videos, etc.
  • the electronic device can run successfully.
  • 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.
  • 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 to access. Therefore, an adapted key is required to decrypt the encrypted data in the user data partition (Userdata) and successfully mount the user data partition (Userdata).
  • the key of a higher version of the operating system can decrypt the user data in a lower version of the operating system.
  • the key of the lower version of the operating system cannot decrypt the encrypted data in the user data partition (Userdata) of the higher version of the operating system.
  • the key of the high version operating system can be used to successfully decrypt the encrypted data in the user data partition (Userdata).
  • the key of the S version operating system can be used to successfully decrypt the encrypted data in the user data partition (Userdata), and the user data partition (Userdata) can be successfully mounted.
  • the user interaction interface can be entered and the system can run in version S. In this way, the system can be upgraded from a lower version to a higher version.
  • a conventional upgrade solution is adopted to roll back the operating system of the electronic device from the currently running high version (such as R version) to a low version (such as R version), including:
  • the electronic device loads the basic partition (Common), the static partition (A), and the dynamic partition (Super) in sequence, and runs under the S version of the operating system.
  • the basic partition Common
  • the static partition A
  • the dynamic partition Super
  • the rollback package is the installation package of the R version of the operating system, which includes the full system data of the R version of the operating system.
  • the electronic device can write the R version of the 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.
  • the electronic device can load the static partition (B) to load a part of the system data required for version R. Also, the electronic device can load the system data in the dynamic partition (Super) and the system data in the user data partition (Userdata) based on the snapshot technology (snapshot) to load another part of the system data required for version R.
  • the static partition B
  • the electronic device can load the system data in the dynamic partition (Super) and the system data in the user data partition (Userdata) based on the snapshot technology (snapshot) to load another part of the system data required for version R.
  • the key of the lower version operating system cannot decrypt the encrypted data in the user data partition (Userdata) of the higher version operating system. Therefore, the key of the R version operating system cannot successfully decrypt the encrypted data in the user data partition (Userdata), resulting in the failure to successfully mount the user data partition (Userdata). As a result, the system fails to start.
  • the electronic device will be triggered to roll back the operating system, that is, execute the following S406.
  • 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.
  • Common basic partition
  • A static partition
  • Super dynamic partition
  • the conventional The 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 a higher version of the operating system and unable to successfully roll back to a lower version of the operating system.
  • Userdata user data partition
  • 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 FIG5 ).
  • SD secure digital memory card
  • CI continuous integration
  • the staff of the outlet can erase the S version of the operating system in the electronic device (the version control process as shown in 502 in FIG5 ).
  • the staff of the outlet can use the SD card including the R version of the fallback package to install the R version of the operating system on the electronic device (the installation process of the R version as shown in 503 in FIG5 ).
  • the operating system in the electronic device is updated from the S version to the R version.
  • 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 called the first version) operating system to the R version (also called the second version) operating system.
  • the repair mode refers to a mode in which the data or operating system inside the electronic device can be modified. In the repair mode, the electronic device can back up or upgrade the operating system, or restore the factory settings.
  • the repair mode can be the recovery mode in the Android system.
  • the repair mode can be the preinstallation environment (Preinstallation Environment, PE) or the disk operating system (Disk Operating System, DOS) in the Windows system.
  • PE Preinstallation Environment
  • DOS disk Operating System
  • the electronic device can download the rollback package (also referred to as the first installation package) of the R version of the operating system.
  • the electronic device writes the R version of the system data in the rollback package to the static partition and the user data partition (Userdata) in the ROM.
  • the electronic device is currently booted from the static partition (A), the S version is V3.0, and the R version is V2.0. See Figure 6.
  • the system data of V2.0 is written, and the static partition (A), the static partition (B) and the user data partition (Userdata) all store the system data of V3.0, and the user data partition stores the user's personal data (as shown before writing in Figure 6).
  • the electronic device is currently booted from the static partition (A), it is running in the V3.0 operating system composed of the basic partition (Common), the static partition (A) and the dynamic partition (Super).
  • 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).
  • the data in the static partition (A) and the dynamic partition (Super) will not be changed, and thus the current V3.0 version will not be affected.
  • the operation of the operating system is 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 electronic device can restart and enter the recovery mode.
  • recovery mode the electronic device writes the system data in the user data partition (Userdata) to the dynamic partition (Super).
  • the process of writing the system data in the user data partition (Userdata) to the dynamic partition (Super) can also be called the disk drop process.
  • 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.
  • the electronic device may 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).
  • the electronic device formats the user data partition (Userdata), so that no data that needs to be decrypted before access is stored in the user data partition (Userdata).
  • 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.
  • the electronic device restarts, and the static partition and dynamic partition (Super) storing the R version of the system data can be successfully loaded, and the user data partition (Userdata) that does not need to be decrypted can be successfully loaded, so that it can successfully run under the operating system of version R.
  • the electronic device can be started 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 the user data partition (Userdata) can also be successfully loaded.
  • the electronic devices in the embodiments of the present application include but are not limited to mobile phones, headphones, tablet computers, smart refrigerators, smart speakers and other devices that can install operating systems.
  • the electronic device may also refer to a control panel in which an operating system can be installed.
  • the operating system includes but is not limited to iOS, Android, Harmony, Windows, Linux or other operating systems.
  • 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.
  • SIM subscriber identification module
  • the structure illustrated in this embodiment does not constitute a specific limitation on the electronic device.
  • the electronic device may include more or fewer components than shown in the figure, or combine some components, or split some components, or arrange the components differently.
  • the components shown in the figure may be implemented in hardware, software, or a combination of software and hardware.
  • the processor 310 may include one or more processing units, for example: the processor 310 may include an application processor (application processor, AP), a modem processor, a graphics processor (graphics processing unit, GPU), an image signal processor (image signal processor, ISP), a controller, a memory, a video codec, a digital signal processor (digital signal processor, DSP), a baseband processor, and/or a neural network A neural-network processing unit (NPU), etc.
  • different processing units can be independent devices or integrated into one or more processors.
  • the interface connection relationship between the modules illustrated in this embodiment is only a schematic illustration and does not constitute a structural limitation of the electronic device.
  • the electronic device may also adopt different interface connection methods in the above embodiments, or a combination of multiple interface connection methods.
  • the charging management module 340 is used to receive charging input from a charger.
  • the charger may be a wireless charger or a wired charger.
  • the charging management module 340 may receive charging input from a wired charger through the USB interface 330.
  • the charging management module 340 may receive wireless charging input through a wireless charging coil of the electronic device. While the charging management module 340 is charging the battery 342, it may also power the electronic device through the power management module 341.
  • 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 supplies power to the processor 310, the internal memory 321, the external memory, the display screen 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 number, battery health status (leakage, impedance), etc.
  • the power management module 341 can also be set in the processor 310.
  • the power management module 341 and the charging management module 340 can also be set in the same device.
  • 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.
  • 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.
  • WLAN wireless local area networks
  • BT Bluetooth
  • GNSS global navigation satellite system
  • FM frequency modulation
  • NFC near field communication
  • IR infrared
  • the wireless communication module 360 can be one or more devices integrating at least one communication processing module.
  • the wireless communication module 360 receives electromagnetic waves via the antenna 2, modulates the electromagnetic wave signal and performs filtering, and sends the processed signal to the processor 310.
  • the wireless communication module 360 can also receive the signal to be sent from the processor 310, modulate the frequency, amplify it, and convert it into electromagnetic waves for radiation through the antenna 2.
  • the electronic device implements the display function through a GPU, a display screen 394, and an application processor.
  • the GPU is a microprocessor for image processing, connecting the display screen 394 and the application processor.
  • the GPU is used to perform mathematical and geometric calculations for graphics rendering.
  • the processor 310 may include one or more GPUs that execute program instructions to generate or change display information.
  • the electronic device can realize the shooting function through ISP, camera 393, video codec, GPU, display screen 394 and application processor.
  • ISP is used to process the data fed back by camera 393.
  • Camera 393 is used to capture static images or videos.
  • the object generates an optical image through the lens and projects it onto the photosensitive element.
  • the electronic device may include 1 or N cameras 393, where N is a positive integer greater than 1.
  • the 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 the processor 310 through the external memory interface 320 to implement a data storage function. For example, files such as music and videos can be saved in the external memory card.
  • the internal memory 321 can be used to store computer executable program codes, and the executable program codes include 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 execute 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 may 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 may store data created during the use of the electronic device (such as audio data, a phone book, etc.), etc.
  • 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 may be arranged inside the processor 310, or the internal memory 321 may be independently arranged outside the processor 310.
  • 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 may be arranged inside the processor 310, or the internal memory 321 may be independently arranged outside the processor 310.
  • the internal memory 321 may include ROM and RAM.
  • the ROM may adopt a virtual A/B data storage structure.
  • the electronic device can implement audio functions such as music playing and recording through the audio module 370, the speaker 370A, the receiver 370B, the microphone 370C, the headphone jack 370D, and the application processor.
  • the key 390 includes a power key, a volume key, etc.
  • the key 390 can be a mechanical key. It can also be a touch key.
  • the electronic device can receive key input and generate key signal input related to the user settings and function control of the electronic device.
  • the motor 391 can generate a vibration prompt.
  • the motor 391 can be used for incoming call vibration prompts, and can also be used 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.
  • FIG. 9 is a schematic diagram of the software composition of the electronic device provided in this application.
  • an operating system update program for upgrading the operating system is installed in the electronic device.
  • 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 rollback package) of the operating system.
  • Update engine is used to execute the upgrade process of the operating system, such as for writing system data into ROM.
  • the electronic device also includes a recovery process and a merge service.
  • the recovery process can be used to pull up the merge service to complete the dynamic partition (Super) being dropped to disk.
  • the recovery process can also trigger a factory reset to format the user data partition (Userdata).
  • the ouc apk can download the rollback package of the R version of the operating system.
  • the update engine writes the system data in the rollback package to the static partition and the user data partition (Userdata) in the ROM.
  • the electronic device can be restarted to enter the recovery mode, that is, the recovery process is started.
  • the recovery process can pull up the merge service, and the merge service will drop the system data in the user data partition (Userdata) to the dynamic partition (Super).
  • the recovery process can format the user data partition (Userdata) so that there is no longer data in the user data partition (Userdata) that needs to be decrypted to access.
  • the electronic device restarts, and the static partition and dynamic partition (Super) storing the R version of the system data can be successfully loaded, and the user data partition (Userdata) that does not need to be decrypted can be successfully loaded, so that it can be successfully run under the R version of the operating system.
  • the operating system upgrade method provided in the present application can be applied to electronic devices having the above-mentioned software and hardware structures. The following will describe the operating system rollback solution provided in the present application in conjunction with actual upgrade scenarios.
  • Scenario 1 Roll back from the S version (i.e., the first version) operating system to the R version (i.e., the second version) operating system, where the R version is lower than the S version. That is, rolling back from a higher version operating system to a lower version operating system can also be called a rollback scenario.
  • the electronic device writes the R version of the system data in standby mode; in recovery mode, the dynamic partition (Super) is written to the disk and the user data partition (Userdata) is formatted. Then, the electronic device restarts and can successfully run the R version of the operating system.
  • the process of rolling back from the S version operating system to the R version operating system includes the following steps:
  • 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 S version of the operating system.
  • the basic partition Common
  • the static partition A
  • the dynamic partition Super
  • 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.
  • the user can perform a rollback request operation on the electronic device.
  • the electronic device can send a package search request to the server to request the R version rollback package (i.e., the first installation package), that is, to request the installation package of the R version operating system.
  • the electronic device may display a first interface including a rollback control (also referred to as a first control), and the rollback control is used to trigger the electronic device to request a rollback package of version R from the server.
  • a rollback control also referred to as a first control
  • the electronic device may request a rollback package of version R from the server. That is, the operation of requesting rollback is a preset operation of the rollback control.
  • the mobile phone is installed with preset applications (such as mobile assistant applications, setting applications), and the preset applications can be used to manage the operating system installed in the mobile phone, such as the upgrade and rollback of the operating system.
  • the mobile phone can display the interface 1101 shown in Figure 11, and the interface 1101 is the application interface of the mobile assistant application.
  • the interface 1101 includes two options, "Geek Version” and "Earlier Version”. The user selects "Geek Version", and the mobile phone can request the upgrade package of the Geek Version (which can also be understood as the public beta version) from the server. The user selects "Earlier Version", and the mobile phone can request the R version rollback package from the server.
  • the rollback control is "Earlier Version”
  • the preset operation of the rollback control is the selection operation of "Earlier Version” in the interface 1101.
  • the mobile phone can send a package search request to the server to request the R version rollback package.
  • the server can determine the R version based on the request information carried in the 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 identification and/or the area information. The following will explain the specific implementation of the electronic device determining the R version based on the version number, device identification, and area information of the S version.
  • Method 1 The server determines the R version based on the version number of the S version.
  • 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, V2.0 may be determined as the R version.
  • the server 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 correspondence between the version number before the rollback and the version number to which it can roll back.
  • 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 (it can also be called the version number of the preset version).
  • the server records the corresponding relationship shown in Table 1 below:
  • V1.1 can be rolled back to V1.0
  • V2.3 can be rolled back to V2.2
  • V3.2 can be rolled back to V3.1.
  • the server queries the version number carried in the search request for the version number that can be rolled back, so as to determine the rollback version. For example, if the version number carried in the search request is V2.3, the above table 1 is queried to determine that the rollback version number is V2.2, that is, the R version is V2.2.
  • a version lower than the S version can be determined as the R version.
  • Method 2 The server determines the R version based on the version number of the S version and the device identifier.
  • the device identification includes information such as the device name, device model or product serial number (Serial Number, SN).
  • the server can determine a version that is lower than the S version and higher than the version installed when the electronic device leaves the factory as the R version based on the version number and device identification of the S version.
  • the server can query the version installed when the electronic device leaves the factory based on the device identification, 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.
  • 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.
  • mobile phone A should not have installed operating systems V1.1 and V1.0.
  • the S version currently running on the electronic device is V3.2, and V3.2 is higher than V2.0, V1.1, and V1.0.
  • the server can determine versions lower than V3.2 but higher than V2.0 as R versions, such as V2.1, V3.0, etc. as R versions, and will not determine V1.1 and V1.0 as R versions.
  • a version lower than the S version and used by the user can be determined as the R version.
  • Method 3 The server determines the target R version based on the version number S and the zone identifier.
  • the area information may be information indicating the use area of the electronic device, such as area name, longitude and latitude information, and mobile network code (MCCMNC).
  • the area information may be city C, city D, etc.
  • the use area may be obtained by positioning the electronic device or may be input by the user, and the embodiments of the present application do not specifically limit this.
  • the operating system provider may provide different versions of the operating system for electronic devices used in different regions. For example, domestic version, overseas version, etc. Based on this, in order to avoid rolling back to a version that cannot be used in the area where the electronic device is used, the server can determine the version that is lower than the S version and can be used in the area where the electronic device is used as the R version based on the version number and area information of the S version. Among them, the server can determine the R version based on the area information. Check the version available for the region where your electronic device is used.
  • the versions of the operating system that can be installed on mobile phones used in China include V3.1 and V3.2
  • the versions of the operating system that can be installed on mobile phones used overseas include V3.3.
  • the area information of the electronic device shows that the electronic device is used in China, and the currently running S version is V4.0, which is higher than V3.1, V3.2, and V3.3.
  • the server can determine the version that is lower than V4.0 and can be used in China 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.
  • 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.
  • 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 use area of the electronic device as the R version.
  • 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, select 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 from. This embodiment of the present application does not specifically limit this. The following will mainly be explained by taking the determination of an R version as an example.
  • 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.
  • the rollback package also includes version information of version R.
  • the electronic device can display a second interface including version information of version R.
  • the version information includes information such as version name, version size, version features, and update precautions. In this way, it is convenient for users to understand the R version and confirm whether rollback is required.
  • the mobile phone in response to the user's selection of "earlier version" in interface 1101, the mobile phone sends a package search request to the server, and after obtaining the rollback package, the interface 1102 shown in FIG11 may be displayed, which is also the application interface of the mobile assistant application.
  • Interface 1102 includes version information of the R version, such as version name "YYYYYYYYY (official version)", version size "4.53GB”, version features "improve system stability, make your phone run more stably” and other information.
  • the second interface includes a recovery control (also referred to as a second control), and the recovery control 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 of version R.
  • the recovery control In response to the user's preset operation (such as a click operation, a long press operation, etc., which may also be referred to as a second operation) on the recovery control, the electronic device may start to execute the operation of rolling back to version R, such as executing S1003 and subsequent steps below.
  • the restore control is the “Restore” button in the interface 1102 shown in FIG11 .
  • the mobile phone can start to execute the operation of rolling back to the R version. That is, the preset operation of the restore control is the click operation of the “Restore” button in the interface 1102.
  • the electronic device may also directly start the operation of rolling back to the R version.
  • 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).
  • the rollback package includes the full system data of the R version of the operating system, and further includes the system data that needs to be stored in the static partition (also called the first system data) and the system data that needs to be stored in the dynamic partition (Super). data (also called second system data).
  • 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 part of the system data required by the R version.
  • the static partition (B) since the electronic device is currently started from the static partition (A), writing the system data to the static partition (B) will not affect the operation of the current S version.
  • the electronic device writes the system data of the dynamic partition (Super) into the user data partition (Userdata) according to the rollback package.
  • 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 another part of the system data required by the R version. Furthermore, the electronic device writes the system data to the user data partition (Userdata) instead of the dynamic partition (Super), which will not affect the operation of the current S version.
  • 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.
  • Userdata user data partition
  • Super dynamic partition
  • the electronic device can use a copy-on-write (cow) file to save system data.
  • cow copy-on-write
  • multiple cow files can be saved, and each cow file corresponds to a sub-partition of the dynamic partition (Super). That is, a cow file stores the system data that needs to be stored in a sub-partition of the dynamic partition (Super).
  • cow file is named according to the sub-partition of the dynamic partition (Super) to which it corresponds.
  • the cow file of the system data of the dynamic partition (Super) is compressed and saved in the form of binary code, and each cow file is named according to the sub-partition of the dynamic partition (Super) to which it corresponds.
  • the cow file corresponding to the system sub-partition is named system-cow-img.img.0000.
  • the electronic device parses the rollback package to obtain all cow files and attaches an A/B partition mark to each cow file.
  • the electronic device is currently started from a static partition (A)
  • the dynamic partition (Super) loaded by the operating system currently running the electronic device is the dynamic partition (A).
  • the system data stored in the virtual dynamic partition is for the dynamic partition (B). Therefore, the name mark _b corresponding to the dynamic partition (B) is attached to the cow file.
  • _b is attached to system-cow-img.img.0000 to generate system_b-cow-img.img.0000.
  • the electronic device After writing the cow file to the virtual dynamic partition, the electronic device changes the disk placement status information in the metadata (metadata) subpartition 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).
  • the disk placement status information includes an overall identifier for the dynamic partition (Super) and a subpartition identifier for each subpartition of the dynamic partition (Super).
  • the overall identifier When the overall identifier is "merged”, it means that all subpartitions 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 subpartitions of the dynamic partition (Super) need to be placed on the disk; when the subpartition identifier is "merged”, it means that the subpartition does not need to be placed on the disk; when the subpartition identifier is "wait for merge”, it means that the subpartition needs to be placed on the disk.
  • 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 on disk”, and changing the sub-partition identifier of each sub-partition to "not yet placed on disk”.
  • the electronic device may also create an index of the cow file.
  • the index of the cow file 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 index of the cow file can be used by the electronic device to read the cow file from the virtual dynamic partition later.
  • the electronic device may create an index of the cow file in the metadata subpartition, and subsequently, the electronic device may read the cow file based on the index of the cow file in the metadata subpartition.
  • the electronic device changes the boot sequence from booting from the static partition (A) to booting from the static partition (B).
  • the electronic device currently starts from the static partition (A), that is, the boot sequence is to start from the static partition (A). After changing the boot sequence from starting from the static partition (A) to starting from the static partition (B), the electronic device can start from the static partition (B) the next time it starts. Thus, it can run under the R version of the operating system.
  • the device boot sequence description is saved.
  • the boot sequence flag is A, indicating booting from the static partition (A);
  • the boot sequence flag is B, indicating booting from the static partition (B).
  • 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.
  • the execution timing of S1005 is not limited to that shown in FIG. 10 .
  • the startup sequence can be changed before the electronic device is started next time (such as before restarting in S1006 ).
  • the electronic device is in a standby state, that is, the electronic device can display a third interface for normal use by the user.
  • the electronic device can normally display the interface 1201 shown in FIG. 12, which is a video playback interface, and the user can watch the video normally.
  • the electronic device may issue a prompt message to prompt that the electronic device needs to be restarted to roll back to version R.
  • the mobile phone may display the interface 1202 shown in FIG. 12, and the interface 1202 includes a prompt message 1203, and the prompt message 1203 is specifically "The mobile phone needs to be restarted to restore to YYYYYYYYY (official version), do you want to restart immediately!, thereby prompting the user that the mobile phone needs to be restarted to roll back to the YYYYYYYYY (official version) version.
  • the electronic device can execute the following S1006 to continue to complete the operation of rolling back to the R version.
  • the prompt information is the prompt information 1203 in the interface 1202 shown in Figure 12, and the prompt information 1203 also includes two options of "Yes" and "No, restart at another time".
  • the operation of confirming the restart can be the user's selection operation of the "Yes” option.
  • the mobile phone can start to execute the following S1006.
  • the operation of confirming the restart can also be the user's selection of the restart time.
  • the mobile phone in response to the user's selection operation of the "No, restart at another time” option in the prompt information 1203 in the interface 1202, the mobile phone can display the interface 1204 shown in Figure 12.
  • the interface 1204 includes a time selection pop-up window 1205, and the time selection pop-up window 1205 includes multiple time options, such as 1 minute, 2 minutes, 3 minutes...
  • the operation of selecting the restart time can be the user's selection of any time in the time selection pop-up window 1205
  • the electronic device responds to the user's operation of selecting a restart time and can start executing the following S1006 after the selected time arrives.
  • 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.
  • the electronic device restarts and enters recovery mode.
  • 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 entering recovery mode.
  • the electronic device can use the following restart command to control the electronic device to restart and enter recovery mode:
  • the electronic device since the boot sequence has been changed from booting from static partition (A) to booting from static partition (B), when the electronic device restarts, it will boot from static partition (B) and enter recovery mode.
  • the electronic device In order to ensure the normal operation of recovery mode, the electronic device needs to load the sub-partitions required to maintain the normal operation of recovery mode in the basic partition (Common) and static partition (B), such as recovery sub-partition, boot sub-partition, etc.
  • the electronic device after executing the above S1001-S1005, the electronic device needs to determine whether the currently acquired package is a rollback package, and only after determining that it is a rollback package, execute S1006 to merge the system data in the user data partition (Userdata) into the dynamic partition (Super) in recovery mode.
  • 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, wherein 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.
  • the version number carried in the installation package is the R version (also called the first version number)
  • 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
  • the R version is lower than the S version
  • 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 version number of the installation package is S version
  • the version number of the operating system currently running on the electronic device is R version
  • S version is higher than R version
  • S version is The version number of the installation package is higher than the version number of the R version. That is to say, 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.
  • the electronic device can determine that the installation package is a rollback 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.
  • 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 the processing of the installation package is stopped.
  • the server can add a rollback mark in the rollback package.
  • the electronic device can determine whether the installation package is a rollback package by identifying whether the installation package includes a rollback mark.
  • S1301 The electronic device determines that the currently acquired package is a rollback package.
  • a rollback package that is, it is determined to be scenario 1 of rolling back from version S to version R.
  • the system will restart and enter the recovery mode only when 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.
  • the electronic device stores the system data in the user data partition (Userdata) into the dynamic partition (Super).
  • the disk drop 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.
  • the electronic device can read the disk-falling status information and the index of the cow file, and complete the disk-falling processing based on the disk-falling status information and the index of the cow file.
  • 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.
  • 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).
  • 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).
  • the electronic device writes the cow file retrieved from the user data partition (Userdata) into the corresponding sub-partition of the dynamic partition (Super), completing the disk write process of the dynamic partition (Super).
  • 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 is stored in the dynamic partition (Super), ensuring that the R version of the operating system can be successfully run later.
  • entering the recovery mode can complete various processing of the data or operating system inside the electronic device. For example, modify the format of the electronic device and change the demonstration format to the commercial format. For another example, use the recovery mode to adjust the partition table. For another example, the recovery mode is used in this application to complete the process of rolling back from version S to version R.
  • the electronic device after entering the recovery mode, the electronic device first needs to determine the purpose of entering the recovery mode, so as to accurately perform the corresponding processing to achieve the purpose. Then, 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 the S version to the R version.
  • subpartition A is a partition that can be accessed in recovery mode.
  • subpartition A is a Misc subpartition of the basic partition (Common).
  • 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 a fallback scene. If the preset identifier is not read, it is determined that the current scene is not a fallback scene.
  • the electronic device may write a preset identifier in sub-partition A. Accordingly, after S1006, the electronic device reads the preset identifier from sub-partition A and may determine that the current scenario is a fallback scenario.
  • the electronic device may 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.
  • the process further includes S1302 :
  • S1302 The electronic device recognizes that the current scene is a fallback scene.
  • the electronic device synchronizes the system data in the static partition (B) to the static partition (A).
  • the electronic device can also synchronize the system data stored in each sub-partition in the static partition (B) to the corresponding sub-partition in the static partition (A), so that the static partition (A) also stores the system data of version R. Then, when starting from the static partition (A), the R version of the operating system can also be run.
  • the static partition (A) stores the system data of version V3.0
  • the static partition (B) stores the system data of version V2.0.
  • the system data of version V2.0 in the static partition (B) can be synchronized to the static partition (A), so that the system data of version V2.0 is also stored in the static partition (A).
  • both the static partition (A) and the static partition (B) include the system data of version V2.0.
  • restoring the factory settings includes formatting the user data partition (Userdata) and the basic partition (common) Cache sub-partitions, metadata sub-partitions, etc.
  • the electronic device is restored to factory settings and the user data partition (Userdata) can be formatted so that there is no data in the user data partition (Userdata) that needs to be decrypted for access.
  • the mobile phone can display interface 1501 (also referred to as the fourth interface) shown in Figure 15, and 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.
  • the progress displayed in interface 1501 is 0%.
  • the progress reaches 100% in interface 1502 shown in Figure 15 it indicates that S1007-S1009 has been executed.
  • both interface 1501 and interface 1502 are inoperable and users cannot use them normally.
  • the electronic device can execute the following S1010, so that the electronic device can run under the R version of the operating system.
  • the electronic device may use the following restart instruction to control the electronic device to restart:
  • the restart is a normal restart, so after the restart, the electronic device will enter a normal use state instead of entering a recovery mode.
  • 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).
  • the electronic device successfully mounts the user data partition (Userdata), enters the user interaction interface, and runs under the R version of the operating system.
  • the static partition (B) and the dynamic partition (Super) both store the R version of the system data, so loading the static partition (B) and the dynamic partition (Super) is equivalent to loading the R version of the operating system.
  • the electronic device can successfully run under the R version of the operating system.
  • the electronic device can display the interface 1503 shown in Figure 15, and the interface 1503 is the mobile phone desktop.
  • scenario 1 includes:
  • the rollback package includes the version number of version R.
  • the rollback package includes the version number of version R.
  • update engine performs data writing operation on static partition (B) according to the rollback package to update static partition (B).
  • static partition B
  • rollback package B
  • update static partition B
  • the update engine writes the dynamic partition in the user data partition (Userdata) according to the rollback package (Super) system data.
  • Userdata user data partition
  • Super rollback package
  • update engine changes the boot order from booting from static partition (A) to booting from static partition (B).
  • A booting from static partition
  • B booting from static partition
  • Update engine compares the version number of R 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.
  • Update engine writes a preset identifier in subpartition A to indicate that the current scenario is a fallback scenario.
  • the update engine writes a preset identifier in the Misc subpartition of the base partition (Common), that is, subpartition A is the Misc subpartition of the base partition (Common).
  • subpartition A is the Misc subpartition of the base partition (Common).
  • S1608 update engine triggers restart and enters recovery mode. For details, please refer to the description of S1006 above.
  • the system will restart into recovery mode only when it is determined that the currently acquired package is a rollback package.
  • 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 description of S1302 and its context above.
  • the recovery process triggers the start of the merge service.
  • the merge service stores the data of the virtual dynamic partition into the dynamic partition (Super).
  • the merge service completes the disk processing.
  • the merge service completes the disk processing.
  • the recovery process formats the user data partition (Userdata). For details, please refer to the description of S1009 above.
  • version R in scenario 2 can be referred to as the third version
  • version S can be referred to as the first version.
  • version R in scenario 2 can be the same as version R in scenario 1, or it can be different. The embodiments of the present application do not specifically limit this.
  • the electronic device can write the system data of the S version operating system in standby mode. Moreover, since it is upgraded from a lower version operating system to a higher version operating system, the encrypted data in the user data partition (Userdata) can be decrypted using the key of the higher version operating system. 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 start the electronic device to run the S version operating system.
  • the process of upgrading from the R version operating system to the S version operating system includes the following steps:
  • 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.
  • the basic partition Common
  • the static partition A
  • the dynamic partition Super
  • the static partition (A) in scenario 2 may be referred to as the second static partition.
  • (B) is called the first static partition.
  • the electronic device obtains the S version upgrade package.
  • the upgrade package of version S 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).
  • system data that needs to be stored in the static partition
  • Super system data that needs to be stored in the dynamic partition
  • the electronic device may periodically initiate a package search request to the server, and 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 whether there is an installation package of an updated operating system (for example, an installation package of an operating system of version 2.0, which may also be referred to as an upgrade package) based on the version number in the package search request.
  • 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.
  • 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).
  • the third system data is written to the static partition (B).
  • the electronic device writes the system data of the dynamic partition (Super) into the user data partition (Userdata) according to the upgrade package.
  • the fourth system data is written to the user data partition (Userdata).
  • 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.
  • S1706 The electronic device determines that the currently acquired packet is not a rollback packet. For details, please refer to the description of S1301 and its context above.
  • the installation package carries the version number of version S
  • the version number of the operating system currently running in the electronic device is the version number of version R (also referred to 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 in the electronic device.
  • the electronic device can determine that the currently acquired package is not a fallback package, that is, the installation package is not used to install an operating system of a lower version than version R.
  • the restart in S1707 is usually a hardware restart.
  • the user long presses the power button to trigger the restart.
  • the electronic device can be triggered to restart when the user does not need to use the electronic device.
  • the electronic device sequentially loads the basic partition (Common) and the static partition (B), and boots from the static partition (B).
  • the electronic device loads the dynamic partition (Super) and the user data partition (Userdata).
  • 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).
  • the electronic device successfully mounts the user data partition (Userdata), enters the user interaction interface, and runs Under the R version of the operating system.
  • Userdata user data partition
  • enters the user interaction interface runs Under the R version of the operating system.
  • the keys are compatible, so the user data partition can be mounted successfully.
  • the electronic device stores the system data in the user data partition (Userdata) to the dynamic partition (Super).
  • the fourth system data in the user data partition is written into the dynamic partition (Super).
  • S1712 The electronic device synchronizes the data in the static partition (B) to the static partition (A).
  • B static partition
  • A static partition
  • Scenario 3 The electronic device currently runs on the R version operating system and enters the recovery mode in a non-scenario 1 situation.
  • the R version in scenario 3 may be referred to as the second version.
  • situations other than scenario 1 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 there is a need to change the format (from demonstration format to commercial format) and the recovery mode is entered to implement the change; and situations where the data storage structure needs to be modified and the recovery mode is entered to change the data storage structure.
  • 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 entering the repair mode this time is not for the purpose of installing an operating system lower than the first version.
  • 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 the recovery mode, the dynamic partition (Super) will not be dropped to disk and the user data partition (Userdata) will not be formatted. Instead, the corresponding processing will be completed based on other identified purposes.
  • the electronic device can perform the operation of modifying the data storage structure in recovery mode. For another example, if the scenario of modification is identified, the electronic device can perform the operation of changing the demonstration format to the commercial format in recovery mode.
  • the embodiment of the present application also provides an electronic device, which may include: a memory and one or more processors.
  • the memory is coupled to the processor.
  • the memory is used to store computer program code, and the computer program code includes computer instructions.
  • the processor executes the computer instructions, the electronic device can perform each step in the above embodiment.
  • the electronic device includes but is not limited to the above memory and one or more processors.
  • the embodiment of the present application also provides a chip system, which can be applied to the electronic devices in the aforementioned embodiments.
  • 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.
  • the electronic device can execute the various steps in the above-mentioned embodiments.
  • the chip system can also include other discrete devices, which is not specifically limited in the embodiment of the present application.
  • Each functional unit in each embodiment of the present application can be integrated into a processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.
  • the above integrated unit can be implemented in the form of hardware or in the form of software functional units.
  • 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.
  • 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 to enable 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, disk or optical disk.

Landscapes

  • Stored Programmes (AREA)

Abstract

一种操作系统的升级方法及电子设备，涉及计算机技术领域。其中，方法包括：加载基础分区、第一静态分区和动态分区，运行第一版本的操作系统。获取第一安装包，第一安装包为第二版本的操作系统的安装包，第二版本低于第一版本，第一安装包中包括第二版本的操作系统的第一系统数据和第二系统数据。向第二静态分区写入第一系统数据，向用户数据分区写入第一系统数据。重启并进入修复模式。在修复模式下，将用户数据分区中的第二系统数据写入到动态分区，格式化用户数据分区。重启，加载基础分区、第二静态分区和动态分区，运行第二版本的操作系统。如此，电子设备可以自动完成回退到低版本的操作系统的处理，无需拿到网点由网点进行回退。

Description

一种操作系统的升级方法及电子设备
本申请要求于2022年12月22日提交国家知识产权局、申请号为202211658830.4、发明名称为“一种操作系统的升级方法及电子设备”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。
技术领域
本申请涉及计算机技术领域，尤其涉及一种操作系统的升级方法及电子设备。
背景技术
在电子设备出厂前，可以将操作系统烧录到电子设备中，从而实现在电子设备出厂前安装操作系统。此后，为了提升用户体验，可能需要对电子设备中的操作系统进行升级。此时，可采用空中下载技术(Over-the-Air Technology，OTA)来实现操作系统升级，从低版本(如V1.0)的操作系统升级到高版本(如V2.0)的操作系统。其中，OTA是通过电子设备的无线网络接口实现远程升级操作系统版本的技术。
但是，实际中，用户可能对升级后高版本的操作系统的使用体验不好。例如，用户习惯了使用某低版本的操作系统，对升级后高版本的操作系统用起来不顺手。那么，用户就可能希望从高版本的操作系统回退到低版本的操作系统。
然而，发明人在实施本申请实施例的过程中发现：在现有技术中，当面对从高版本的操作系统回退到低版本的操作系统的需求时，用户只能将电子设备拿到固定网点。然后，由网点的工作人员进行回退操作，将操作系统回退到低版本。
发明内容
有鉴于此，本申请提供了一种操作系统的升级方法及电子设备，电子设备可以获取高版本回退到低版本的回退包，并自动完成回退到低版本的操作系统的处理，无需拿到网点由网点进行回退。
第一方面，本申请提供了一种操作系统的升级方法，应用于电子设备，电子设备包括存储器，存储器包括基础分区、第一静态分区、第二静态分区、动态分区以及用户数据分区。其中，加载基础分区、第一静态分区和动态分区，运行第一版本的操作系统。获取第一安装包，第一安装包为第二版本的操作系统的安装包，第二版本低于第一版本，第一安装包中包括第二版本的操作系统的第一系统数据和第二系统数据。向第二静态分区写入第一系统数据，向用户数据分区写入第一系统数据。重启并进入修复模式。在修复模式下，将用户数据分区中的第二系统数据写入到动态分区，格式化用户数据分区。重启，加载基础分区、第二静态分区和动态分区，运行第二版本的操作系统。
综上所述，本申请中，在从高版本的操作系统回退到低版本的操作系统时，电子设备在待机状态下将低版本的系统数据写入到静态分区和用户数据分区后，进入修复模式将用户数据分区中的系统数据写入到动态分区，使用户数据分区中支持低版本的操作系统运行的系统数据被读出。然后，在修复模式下对用户数据分区格式化，从而 可以清除掉用户数据分区中的数据。最后，电子设备重启，则可以成功加载存储有低版本的系统数据的静态分区和动态分区，以及可以成功加载无需解密的用户数据分区，从而可以成功运行在低版本的操作系统下。
在第一方面一种可能的设计方式中，在重启并进入修复模式之前，上述方法还包括：确定第一安装包用于安装比第一版本更低版本的操作系统。
也就是说，只有在确定需要回退的情况下，才重启进入修复模式。从而避免在不需要回退的情况下，错误的进入到修复模式。
在第一方面一种可能的设计方式中，第一安装包中包括第一版本号，第一版本号是第二版本的版本号，确定第一安装包用于安装比第一版本更低版本的操作系统的安装包，包括：确定第一版本号低于第二版本号，第二版本号是第一版本的版本号。
其中，第一版本号低于第二版本号，则表明安装包中携带的版本号比电子设备当前运行的操作系统的版本号更低，即为回退到低版本的场景。
在第一方面一种可能的设计方式中，在确定第一安装包用于安装比第一版本更低版本的操作系统之后，上述方法还包括：在预设子分区中记录预设标识，预设子分区为修复模式下可访问的子分区。在修复模式下，将用户数据分区中的第二系统数据写入到动态分区，格式化用户数据分区，包括：在修复模式下，如果从预设子分区中读取到预设标识，则将用户数据分区中的第二系统数据写入到动态分区，格式化用户数据分区。
也就是说，只有在回退到低版本的情况下，才进一步执行落盘(merge)及其后续处理。从而避免在不需要回退的场景中，在修复模式下错误的执行落盘等处理，最终影响系统运行。
在第一方面一种可能的设计方式中，在获取第一安装包之前，上述方法还包括：显示第一界面，第一界面中包括第一控件。响应于用户对第一控件的第一操作，向服务器发送搜包请求。接收服务器基于搜包请求反馈的下载地址。相应的，获取第一安装包，包括：基于下载地址下载第一安装包。
也就是说，可以由用户在电子设备上主动触发获取第一安装包。如此，可以在用户有回退到低版本的需求的情况下，获取第一安装包并回退，准确满足用户的需求。
在第一方面一种可能的设计方式中，在获取第一安装包之后，上述方法还包括：显示第二界面，第二界面中包括第二版本的操作系统的版本信息和第二控件，第二控件用于触发安装第二版本的操作系统。向第二静态分区写入第一系统数据，向用户数据分区写入第一系统数据，包括：响应于用户对第二控件的第二操作，向第二静态分区写入第一系统数据，向用户数据分区写入第一系统数据。
也就是说，在获取到第一安装包之后，电子设备可以在用户确认回退到低版本的操作系统时，才执行回退操作。如此，可以准确满足用户的需求
在第一方面一种可能的设计方式中，在将用户数据分区中的第二系统数据写入动态分区之后，上述方法还包括：将第二静态分区中的第一系统数据同步给第一静态分区。如此，可以使第一静态分区中也存储低版本的系统数据。那么，此后从第一静态分区启动时，也可以运行低版本的操作系统。
在第一方面一种可能的设计方式中，在向第二静态分区写入第一系统数据，向用 户数据分区写入第一系统数据的过程中，上述方法还包括：显示第三界面，第三界面是电子设备待机状态下的界面。
也就是说，在待机状态下完成低版本的系统数据的写入，则在写入系统数据的过程中，用户可以正常使用电子设备。
在第一方面一种可能的设计方式中，在修复模式下，将用户数据分区中的第二系统数据写入动态分区，格式化用户数据分区的过程中，上述方法还包括：显示第四界面，第四界面中包括进度提示信息，进度提示信息用于提示落盘以及格式化的进度；其中，电子设备不会响应用户在第四界面的操作。
也就是说，在修复模式下，用户是无法正常操作电子设备的。
在第一方面一种可能的设计方式中，重启并进入修复模式，包括：重启并启动修复进程。在修复模式下，将用户数据分区中的第二系统数据落盘到动态分区，包括：修复进程触发启动落盘服务，落盘服务将用户数据分区中的第二系统数据落盘写入到动态分区；
修复进程格式化用户数据分区。
也就是说，在修复模式下，可以通过拉起落盘服务，实现将用户数据分区中的第二系统数据写入到动态分区。
在第一方面一种可能的设计方式中，第二版本满足以下至少一个条件：
第二版本是预设版本。如此，可以保证回退到的不是太久远的、或者漏洞大的版本。第二版本高于电子设备出厂时安装的操作系统的版本。如此，可以保证不会回退到电子设备未安装过的版本，即用户未使用过的版本。
第二版本是电子设备的使用地区允许安装的版本。如此，可以保证回退到电子设备允许安装的版本。
在第一方面一种可能的设计方式中，在加载基础分区、第一静态分区和动态分区，运行第一版本的操作系统之前，上述方法还包括：加载基础分区、第二静态分区和动态分区，运行第三版本的操作系统，第三版本低于第一版本。获取第二安装包，第二安装包用于升级到第一版本的操作系统，第二安装包中包括第一版本的操作系统的第三系统数据和第四系统数据。向第一静态分区写入第三系统数据，向用户数据分区写入第四系统数据。重启。加载基础分区、第一静态分区和动态分区，运行第一版本的操作系统，包括：加载基础分区、第一静态分区、动态分区以及用户数据分区中的第四系统数据，运行第一版本的操作系统。
也就是说，电子设备中第一版本的操作系统是从第三版本的操作系统升级来的。并且，在从低版本的操作系统升级到高版本的操作系统时，在完成系统数据的写入后，通过正常重启，即可运行在高版本的操作系统下。
在第一方面一种可能的设计方式中，在加载基础分区、第一静态分区、动态分区以及用户数据分区，运行第一版本的操作系统之后，上述方法还包括：将用户数据分区中的第四系统数据写入动态分区。
在第一方面一种可能的设计方式中，在重启，加载基础分区、第一静态分区、动态分区以及用户数据分区之前，上述方法还包括：确定第二安装包不用于安装比第三版本更低版本的操作系统。
在第一方面一种可能的设计方式中，第二安装包中包括第二版本号，第二版本号是第一版本的版本号，确定第二安装包不用于安装比第三版本更低版本的操作系统，包括：确定第三版本号低于第二版本号，第三版本号是第三版本的版本号。
在第一方面一种可能的设计方式中，在加载基础分区、第二静态分区和动态分区，运行第二版本的操作系统之后，上述方法还包括：响应于预设事件，重启再次进入修复模式；其中，如果确定再次进入修复模式不是为了安装比第一版本更低版本的操作系统的，则不会将用户数据分区中的数据写入动态分区的处理。如此，可以基于进入修复模式的目的，准确的执行相应的处理。
第二方面，本申请还提供一种电子设备，所述电子设备包括处理器以及存储器，存储器包括基础分区、第一静态分区、第二静态分区、动态分区以及用户数据分区。所述处理器用于执行所述存储器上存储的软件代码，以使得所述电子设备执行上述第一方面及其任一种可能的设计方式的方法。
第三方面，本申请实施例提供一种芯片系统，该芯片系统应用于包括显示屏和存储器的电子设备；所述芯片系统包括一个或多个接口电路和一个或多个处理器；所述接口电路和所述处理器通过线路互联；所述接口电路用于从所述电子设备的存储器接收信号，并向所述处理器发送所述信号，所述信号包括所述存储器中存储的计算机指令；当所述处理器执行所述计算机指令时，所述电子设备执行如第一方面及其任一种可能的设计方式所述的方法。
第四方面，本申请实施例还提供一种计算机存储介质，该计算机存储介质包括计算机指令，当所述计算机指令在电子设备上运行时，使得电子设备执行如第一方面及其任一种可能的设计方式所述的方法。
第五方面，本申请提供一种计算机程序产品，当所述计算机程序产品在计算机上运行时，使得所述计算机执行如第一方面及其任一种可能的设计方式所述的方法。
可以理解地，上述提供的第二方面所述的电子设备，第三方面所述的芯片系统，第四方面所述的计算机存储介质，第五方面所述的计算机程序产品所能达到的有益效果，可参考第一方面及其任一种可能的设计方式中的有益效果，此处不再赘述。
附图说明
图1为本申请实施例适用的回退场景的示意图；
图2为本申请实施例提供的一种数据存储结构的示意图；
图3为一种操作系统的升级流程图；
图4为另一种操作系统的升级流程图；
图5为一种操作系统的升级过程的示意图；
图6为本申请实施例提供的操作系统的升级流程的原理图之一；
图7为本申请实施例提供的操作系统的升级流程的原理图之二；
图8为本申请实施例提供的电子设备的硬件结构图；
图9为本申请实施例提供的电子设备的软件结构图；
图10为本申请实施例提供的操作系统的升级流程图之一；
图11为本申请实施例提供的手机界面的示意图之一；
图12为本申请实施例提供的手机界面的示意图之二；
图13为本申请实施例提供的操作系统的升级流程图之二；
图14为本申请实施例提供的操作系统的升级流程的原理图之三；
图15为本申请实施例提供的手机界面的示意图之三；
图16为本申请实施例提供的操作系统的升级流程的交互图；
图17为本申请实施例提供的操作系统的升级流程图之三；
图18为本申请实施例提供的芯片系统的结构图。
具体实施方式
应当明确，本文所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其它实施例，都属于本申请保护的范围。
本申请实施例提供了一种操作系统的升级方法，可以应用于需要将电子设备中的操作系统由高版本回退到低版本的场景中。参见图1，以电子设备是手机为例，手机的操作系统可以从V1.0版本升级到V2.0版本。采用本申请实施例，可以将操作系统从V2.0版本回退到V1.0版本。继续参见图1，手机的操作系统还可以继续从V2.0版本升级到V3.0版本。采用本申请实施例，可以将操作系统从V3.0版本回退到V2.0版本，或者从V3.0版本回退到V1.0版本。
在电子设备中，操作系统的系统数据存储在电子设备的存储器中。存储器通常包括只读存储器(Read-Only Memory，ROM)和随机存取存储器(Random Access Memory，RAM)。在实际应用中，RAM又可以称作“主存”，它可随时读写，而且速度很快，通常作为操作系统或其他正在运行中的程序的临时数据存储媒介，当电源关闭时，RAM不能保留数据。即，RAM中通常存储的是电子设备运行时的临时数据。ROM又可以称作“非易失性存储器”，其所存数据一般是装入整机前事先写好的，以及用户使用电子设备时产生的用户数据，整机工作过程中只能读出，而不能像RAM那样能够快速地、方便地加以改写，因此ROM所存数据稳定，断电后所存数据也不会改变。基于上述特性，通常会将操作系统的系统数据通常存储在ROM中，以保证系统数据的稳定性。
与此同时，ROM可以采用虚拟A/B(也可以称为Virtual A/B)的数据存储结构，来存储系统数据。图2所示为一种虚拟A/B的数据存储结构的示意图，如图2所示，以安卓(Android)操作系统为例，虚拟A/B的数据存储结构包含基础分区(Common)、静态分区(A)、静态分区(B)、动态分区(Super)以及用户数据分区(Userdata)。
用户数据分区(Userdata)用于保存用户的个人数据，例如，用户个人安装的应用程序(application，APP)、用户个人保存的图片、文档以及视频等个人数据。基础分区(Common)中保存的数据为不参与操作系统升级的系统数据。静态分区(A)与静态分区(B)的结构相互对应，子分区命名通过后缀_a以及_b相互区分。例如，静态分区(A)中的子分区包括bootloader_a、boot_a、vendor_boot_a；静态分区(B)中的子分区包括bootloader_b、boot_b、vendor_boot_b。动态分区(Super)包含多个子分区，如System、system_ext、vendor、product、Cust、Odm。
需要说明的是，图2所示的数据存储结构仅为示例性的。实际中，数据存储结构中的基础分区(Common)中也可以进一步包括多个子分区，如cache子分区、Misc 子分区等。以及，数据存储结构中的静态分区(A)、静态分区(B)以及动态分区(Super)可以包括比图2所示更多或者更少的子分区。例如，静态分区(A)中还可以包括Patch_a、dtbo_a、vbmeta_a等子分区，相应的，静态分区(B)中还可以包括Patch_b、dtbo_b、vbmeta_b等子分区。又如，动态分区(Super)中还可以包括version、preload等子分区。
在电子设备启动时，需要从一个静态分区启动。例如，电子设备从静态分区(A)启动，则依次加载基础分区(Common)、静态分区(A)以及动态分区(Super)。又如，电子设备从静态分区(B)启动，则依次加载基础分区(Common)、静态分区(B)以及动态分区(Super)。
针对图2所示的数据存储结构，当需要从低版本的操作系统升级到高版本的操作系统时，电子设备可以使用虚拟A/B的升级方案来实现升级。参见图3，采用虚拟A/B的升级方案，将电子设备的操作系统由当前运行的低版本(如R版本)升级到高版本(如S版本)，包括：
S300、从静态分区(A)启动，运行在R版本下。
即，电子设备依次加载基础分区(Common)、静态分区(A)以及动态分区(Super)，运行在R版本的操作系统下。
S301、获取S版本的升级包。
其中，升级包中包括升级到S版本的系统数据。
S302、向ROM中写入S版本的系数数据。
电子设备可以向静态分区(B)和用户数据分区(Userdata)中写入升级包中S版本的系统数据，从而避免影响当前R版本的运行。
S303、重启。
即，退出当前S版本的操作系统，切断电子设备的电源，并再次开启电子设备的电源。
S304、从静态分区(B)加载S版本的操作系统。
电子设备可以加载静态分区(B)，从而加载得到版本S所需的一部分系统数据。以及，电子设备可以基于快照技术(snapshot)合并加载动态分区(Super)中的系统数据和用户数据分区(Userdata)中的系统数据，从而加载得到版本S所需的另一部分系统数据。
S305、加载用户数据分区(Userdata)。
通过加载用户数据分区(Userdata)，可以获取到用户的个人数据，如应用、图片、视频等数据。在成功加载用户数据分区(Userdata)后，电子设备才能成功运行。
需要在此说明的是，S302中向用户数据分区(Userdata)写入的S版本的系统数据是明文数据。因此，在S304中，在不解密的情况下，电子设备就可以成功加载用户数据分区(Userdata)中的系统数据。但是，用户数据分区(Userdata)中除S302中写入的S版本的系统数据之外，其余数据都是R版本的操作系统运行过程中产生的个人数据，如图片、文档等，都是需要解密才能访问的。因此，需要有适配的密钥，才能解密用户数据分区(Userdata)中加密的数据，实现成功挂载用户数据分区(Userdata)。
与此同时，通常高版本的操作系统的密钥，可以解密低版本的操作系统中用户数 据分区(Userdata)中加密的数据。但是，低版本的操作系统的密钥，无法解密高版本的操作系统中用户数据分区(Userdata)中加密的数据。
也就是说，在从低版本升级到高版本的过程中，可以使用高版本的操作系统的密钥，成功解密用户数据分区(Userdata)中加密的数据。那么，在S305中，则可以使用S版本的操作系统的密钥成功解密用户数据分区(Userdata)中加密的数据，实现成功挂载用户数据分区(Userdata)。
在重启后，经过上述S304和S305，则可以进入用户交互界面，运行在S版本。如此，则实现了从低版本升级到高版本。
然而，如果将图3所示的虚拟A/B的升级方案(可以称为常规升级方案)，应用于从高版本(如S版本)的操作系统回退到低版本(如R版本)的操作系统的场景中，则可能出现回退失败的问题。具体的，参见图4，采用常规升级方案，将电子设备的操作系统由当前运行的高版本(如R版本)回退到低版本(如R版本)，包括：
S400、从静态分区(A)启动，运行在S版本下。
即，电子设备依次加载基础分区(Common)、静态分区(A)以及动态分区(Super)，运行在S版本的操作系统下。
S401、获取R版本的回退包。
其中，回退包即为R版本的操作系统的安装包，其包括R版本的操作系统的全量系统数据。
S402、向ROM中写入R版本的系数数据。
电子设备可以向静态分区(B)和用户数据分区(Userdata)中写入回退包中R版本的系统数据，从而避免影响当前S版本的运行。
S403、重启。
即，退出当前R版本的操作系统，切断电子设备的电源，并再次开启电子设备的电源。
S404、从静态分区(B)加载R版本的操作系统。
电子设备可以加载静态分区(B)，从而加载得到版本R所需的一部分系统数据。以及，电子设备可以基于快照技术(snapshot)合并加载动态分区(Super)中的系统数据和用户数据分区(Userdata)中的系统数据，从而加载得到版本R所需的另一部分系统数据。
S405、加载用户数据分区(Userdata)失败，启动失败。
由于是从高版本回退到低版本，而低版本的操作系统的密钥，无法解密高版本的操作系统中用户数据分区(Userdata)中加密的数据。那么，使用R版本的操作系统的密钥，无法成功解密用户数据分区(Userdata)中加密的数据，导致无法成功挂载用户数据分区(Userdata)。从而启动失败。
并且，在启动失败后，则会触发电子设备将操作系统回滚，即执行下述S406。
S406、回滚到S版本，继续运行在S版本下。
电子设备可以再次加载基础分区(Common)、静态分区(A)以及动态分区(Super)，从而继续运行在S版本的操作系统下。
也就是说，在从高版本的操作系统回滚到低版本的操作系统的场景中，采用常规 升级方案，可能会因为重启后挂载用户数据分区(Userdata)失败，触发回滚，导致电子设备继续运行在高版本的操作系统下，无法成功回退到低版本的操作系统。
因此，在常规技术中，当用户有从高版本的操作系统回退到低版本的操作系统的需求时，用户只能将手机拿到网点。然后，由网点的工作人员进行回退操作，完成操作系统回退。
具体的，参见图5，操作系统的供应商可以构建回退包，将构建的回退包可以存入安全数码卡(Secure Digital Memory Card，SD)中(如图5中501所示的构建回退包过程)。其中，可以采用持续集成(continuous integratuin，CI)系统制作回退包。然后，网点的工作人员可以擦除掉电子设备中S版本的操作系统(如图5中502所示的擦版本控制过程)。最后，网点的工作人员可以使用包括R版本的回退包的SD卡，给电子设备安装R版本的操作系统(如图5中503所示的R版本的安装过程)。从而将电子设备中的操作系统，由S版本更新为R版本。
也就是说，常规技术中，采用常规升级方案，无法从S版本的操作系统回退到R版本的操作系统，而只能拿到网点，由网点的工作人员通过刷机装入R版本的操作系统，从而实现操作系统的回退。
基于上述问题，本申请实施例提供了一种操作系统的升级方法，可以应用于需要将S版本(也可以称为第一版本)的操作系统回退到R版本(也可以称为第二版本)的操作系统的电子设备中。在介绍本申请实施例之前，先在此介绍本申请中需要用到的修复模式，修复模式是指可以对电子设备内部的数据或操作系统进行修改的模式。在修复模式下，电子设备可以对操作系统进行备份或升级，也可以恢复出厂设置。例如，修复模式可以是Android系统中的恢复(recovery)模式。又例如，修复模式可以是Windows系统中的预安装环境(Preinstallation Environment，PE)或者磁盘操作系统(Disk Operating System，DOS)。下文主要以Android系统中的recovery模式为例来说明。
下面说明本申请方案：
在需要从S版本的操作系统回退到R版本的操作系统的情况下，电子设备可以下载R版本的操作系统的回退包(也可以称为第一安装包)。在待机状态下，电子设备将回退包中R版本的系统数据写入到ROM中的静态分区和用户数据分区(Userdata)。
示例性的，以电子设备当前从静态分区(A)启动，S版本是V3.0，R版本是V2.0为例，参见图6，在待机状态下，写入V2.0的系统数据，静态分区(A)、静态分区(B)和用户数据分区(Userdata)中存储的都是V3.0的系统数据，用户数据分区中存储的是用户个人数据(如图6中的写入前所示)。由于电子设备当前从静态分区(A)启动，即运行在基础分区(Common)、静态分区(A)以及动态分区(Super)构成的V3.0的操作系统中。那么，电子设备可以向静态分区(B)写入V2.0中需要存储在静态分区的系统数据，使得静态分区(B)中可以存储V2.0的一部分系统数据(如图6中写入后的静态分区(B)所示)；以及，向用户数据分区(Userdata)中写入V2.0中需要存储在动态分区的系统数据，使得用户数据分区(Userdata)中可以存储V2.0的另一部分系统数据(如图6中写入后的用户数据分区(Userdata)所示)。如此，不会改变静态分区(A)以及动态分区(Super)中的数据，从而不会影响当前V3.0版本 的操作系统的运行。
在系统数据写入完成后，电子设备可以重启进入recovery模式。在recovery模式下，电子设备将用户数据分区(Userdata)中的系统数据写入到动态分区(Super)中。其中，将用户数据分区(Userdata)中的系统数据写入到动态分区(Super)中的过程，也可以称为落盘过程。这样，可以使动态分区(Super)中存储有R版本的系统数据，使得后续通过加载动态分区(Super)，可以加载得到R版本的系统数据。
示例性的，在向静态分区(B)写入V2.0的一部分系统数据，向用户数据分区(Userdata)中写入V2.0的另一部分系统数据后，在recovery模式下，参见图7，电子设备可以先将用户数据分区(Userdata)中“V2.0的系统数据”落盘到动态分区(Super)中，使动态分区(Super)中存储V2.0的系统数据。
并且，在完成落盘后，电子设备格式化用户数据分区(Userdata)。这样，可以使用户数据分区(Userdata)中不再存有需要解密才能访问的数据。
继续参见图7，在recovery模式下，在完成落盘后，电子设备对用户数据分区(Userdata)格式化，从而可以清除掉用户数据分区中的数据，包括V2.0的系统数据以及用户个人数据。
最后，电子设备重启，则可以成功加载存储有R版本的系统数据的静态分区和动态分区(Super)，以及可以成功加载无需解密的用户数据分区(Userdata)，从而可以成功运行在R版本的操作系统下。继续参见图7，在格式化完成后，电子设备可以从静态分区(B)启动，即运行在基础分区(Common)、静态分区(B)以及动态分区(Super)构成的V2.0的操作系统中，并且还能成功加载用户数据分区(Userdata)。
示例性的，本申请实施例的电子设备包括但不限于可以安装操作系统的手机、耳机、平板电脑、智能冰箱、智能音箱等设备。或者，电子设备也可以是指电子设备内部可以安装操作系统的控制板。并且，本申请实施例中，操作系统包括但不限于iOS、Android、Harmony、Windows、Linux或者其它操作系统。
参见图8，为本申请实施例提供的一种电子设备的硬件结构图。如图8所示，以电子设备是手机为例，电子设备可以包括处理器310，外部存储器接口320，内部存储器321，通用串行总线(universal serial bus，USB)接口330，充电管理模块340，电源管理模块341，电池342，天线1，天线2，移动通信模块350，无线通信模块360，音频模块370，扬声器370A，受话器370B，麦克风370C，耳机接口370D，传感器模块380、按键390，马达391，指示器392，摄像头393，显示屏394，以及用户标识模块(subscriber identification module，SIM)卡接口395等。
可以理解的是，本实施例示意的结构并不构成对电子设备的具体限定。在另一些实施例中，电子设备可以包括比图示更多或更少的部件，或者组合某些部件，或者拆分某些部件，或者不同的部件布置。图示的部件可以以硬件，软件或软件和硬件的组合实现。
处理器310可以包括一个或多个处理单元，例如：处理器310可以包括应用处理器(application processor，AP)，调制解调处理器，图形处理器(graphics processing unit，GPU)，图像信号处理器(image signal processor，ISP)，控制器，存储器，视频编解码器，数字信号处理器(digital signal processor，DSP)，基带处理器，和/或神经网 络处理器(neural-network processing unit，NPU)等。其中，不同的处理单元可以是独立的器件，也可以集成在一个或多个处理器中。
可以理解的是，本实施例示意的各模块间的接口连接关系，只是示意性说明，并不构成对电子设备的结构限定。在另一些实施例中，电子设备也可以采用上述实施例中不同的接口连接方式，或多种接口连接方式的组合。
充电管理模块340用于从充电器接收充电输入。其中，充电器可以是无线充电器，也可以是有线充电器。在一些有线充电的实施例中，充电管理模块340可以通过USB接口330接收有线充电器的充电输入。在一些无线充电的实施例中，充电管理模块340可以通过电子设备的无线充电线圈接收无线充电输入。充电管理模块340为电池342充电的同时，还可以通过电源管理模块341为电子设备供电。
电源管理模块341用于连接电池342，充电管理模块340与处理器310。电源管理模块341接收电池342和/或充电管理模块340的输入，为处理器310，内部存储器321，外部存储器，显示屏394，摄像头393，和无线通信模块360等供电。电源管理模块341还可以用于监测电池容量，电池循环次数，电池健康状态(漏电，阻抗)等参数。在其他一些实施例中，电源管理模块341也可以设置于处理器310中。在另一些实施例中，电源管理模块341和充电管理模块340也可以设置于同一个器件中。
电子设备的无线通信功能可以通过天线1，天线2，移动通信模块350，无线通信模块360，调制解调处理器以及基带处理器等实现。
无线通信模块360可以提供应用在电子设备上的包括无线局域网(wireless local area networks，WLAN)(如无线保真(wireless fidelity，Wi-Fi)网络)，蓝牙(bluetooth，BT)，全球导航卫星系统(global navigation satellite system，GNSS)，调频(frequency modulation，FM)，近距离无线通信技术(near field communication，NFC)，红外技术(infrared，IR)等无线通信的解决方案。无线通信模块360可以是集成至少一个通信处理模块的一个或多个器件。无线通信模块360经由天线2接收电磁波，将电磁波信号调频以及滤波处理，将处理后的信号发送到处理器310。无线通信模块360还可以从处理器310接收待发送的信号，对其进行调频，放大，经天线2转为电磁波辐射出去。
电子设备通过GPU，显示屏394，以及应用处理器等实现显示功能。GPU为图像处理的微处理器，连接显示屏394和应用处理器。GPU用于执行数学和几何计算，用于图形渲染。处理器310可包括一个或多个GPU，其执行程序指令以生成或改变显示信息。
电子设备可以通过ISP，摄像头393，视频编解码器，GPU，显示屏394以及应用处理器等实现拍摄功能。ISP用于处理摄像头393反馈的数据。摄像头393用于捕获静态图像或视频。物体通过镜头生成光学图像投射到感光元件。在一些实施例中，电子设备可以包括1个或N个摄像头393，N为大于1的正整数。
外部存储器接口320可以用于连接外部存储卡，例如Micro SD卡，实现扩展电子设备的存储能力。外部存储卡通过外部存储器接口320与处理器310通信，实现数据存储功能。例如将音乐，视频等文件保存在外部存储卡中。
内部存储器321可以用于存储计算机可执行程序代码，所述可执行程序代码包括 指令。处理器310通过运行存储在内部存储器321的指令，从而执行电子设备的各种功能应用以及数据处理。例如，处理器310可以通过执行存储在内部存储器321中的指令，执行操作系统的回退操作。内部存储器321可以包括存储程序区和存储数据区。其中，存储程序区可存储操作系统，至少一个功能所需的应用程序(比如声音播放功能，图像播放功能等)等。存储数据区可存储电子设备使用过程中所创建的数据(比如音频数据，电话本等)等。此外，内部存储器321可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件，闪存器件，通用闪存存储器(universal flash storage，UFS)等。应理解，内部存储器321可以设置于处理器310内部，或者内部存储器321可以独立设置于处理器310外。
在具体实现中，内部存储器321可以包括ROM和RAM。本申请中，ROM可以采用虚拟A/B的数据存储结构。
电子设备可以通过音频模块370，扬声器370A，受话器370B，麦克风370C，耳机接口370D，以及应用处理器等实现音频功能。例如音乐播放，录音等。
按键390包括开机键，音量键等。按键390可以是机械按键。也可以是触摸式按键。电子设备可以接收按键输入，产生与电子设备的用户设置以及功能控制有关的键信号输入。马达391可以产生振动提示。马达391可以用于来电振动提示，也可以用于触摸振动反馈。指示器392可以是指示灯，可以用于指示充电状态，电量变化，也可以用于指示消息，未接来电，通知等。SIM卡接口395用于连接SIM卡。SIM卡可以通过插入SIM卡接口395，或从SIM卡接口395拔出，实现和电子设备的接触和分离。电子设备可以支持1个或N个SIM卡接口，N为大于1的正整数。
参见图9，为本申请提供的电子设备的软件组成的示意图。如图9所示，电子设备中安装有用于操作系统升级的操作系统更新程序。进一步的，操作系统更新程序包括在线更新客户端工具(online update client apk，ouc apk)以及升级引擎(update engine)两个功能模块。ouc apk用于获取操作系统的升级安装包(包括回退包)。update engine用于执行操作系统的升级流程，如用于向ROM中写入系统数据。
继续参见图9，电子设备中还包括恢复(recovery)进程和落盘(merge)服务。本申请中，recovery进程可用于拉起merge服务，完成动态分区(Super)的落盘。并且，recovery进程还可以触发恢复出厂设置，实现格式化用户数据分区(Userdata)。
下面先结合图9所示的软件组成，对本申请提供的操作系统的升级方法做简单介绍：在需要从S版本的操作系统回退到R版本的操作系统的情况下，ouc apk可以下载R版本的操作系统的回退包。在待机状态下，update engine将回退包中的系统数据写入到ROM中的静态分区和用户数据分区(Userdata)。在系统数据写入完成后，电子设备可以重启进入recovery模式，即启动recovery进程。recovery进程可以拉起merge服务，由merge服务将用户数据分区(Userdata)中的系统数据落盘到动态分区(Super)中。并且，在完成落盘后，recovery进程可以格式化用户数据分区(Userdata)，使用户数据分区(Userdata)中不再存有需要解密才能访问的数据。最后，电子设备重启，则可以成功加载存储有R版本的系统数据的静态分区和动态分区(Super)，以及可以成功加载无需解密的用户数据分区(Userdata)，从而可以成功运行在R版本的操作系统下。
本申请提供的操作系统的升级方法，可以应用于具有上述软硬件结构的电子设备中。下面将结合实际中的升级场景来说明本申请提供的操作系统的回退方案。
场景1，从S版本(即第一版本)的操作系统，回退到R版本(即第二版本)的操作系统，R版本低于S版本。即，从高版本的操作系统回退到低版本的操作系统，也可以称为回退场景。
在场景1中，如前文图6所示，电子设备在待机状态下写入R版本的系统数据；在recovery模式下完成动态分区(Super)的落盘以及用户数据分区(Userdata)的格式化。然后，电子设备重启，则可以成功运行在R版本的操作系统下。
参见图10，以电子设备当前从静态分区(A)启动为例，在场景1中，从S版本的操作系统，回退到R版本的操作系统的过程包括以下步骤：
S1001、电子设备依次加载基础分区(Common)、静态分区(A)以及动态分区(Super)，从静态分区(A)启动，运行在S版本的操作系统下。
其中，为了方便说明，可以将场景1中的静态分区(A)称为第一静态分区，将静态分区(B)称为第二静态分区。
S1002、在需要从S版本的操作系统回退到R版本的操作系统的情况下，电子设备获取R版本的回退包。
当用户需要将电子设备中当前运行的S版本的操作系统回退到R版本的操作系统时，用户可以对电子设备执行请求回退的操作。电子设备响应于请求回退的操作，可以向服务器发送搜包请求，请求获取R版本的回退包(即第一安装包)，即请求获取R版本的操作系统的安装包。
电子设备可以显示包括回退控件(也可以称为第一控件)的第一界面，回退控件用于触发电子设备向服务器请求R版本的回退包。电子设备响应于用户对回退控件的预设操作(如点击操作、长按操作等，也可以称为第一操作)，可以向服务器请求R版本的回退包。即，请求回退的操作是对回退控件的预设操作。
以电子设备是手机为例，手机上安装有预设应用程序(如手机助手应用、设置应用)，预设应用程序可用于管理手机中安装的操作系统，如操作系统的升级、回退等管理。手机可以显示图11所示的界面1101，界面1101是手机助手应用的应用界面。界面1101中包括“极客版”和“更早版本”两个选项。用户选择“极客版”，手机则可向服务器请求极客版本(也可以理解为公测版本)的升级包。用户选择“更早版本”，手机则可向服务器请求R版本的回退包。即，回退控件为“更早版本”，对回退控件的预设操作为对界面1101中“更早版本”的选择操作。手机响应于用户对界面1101中“更早版本”的选择操作，可以向服务器发送搜包请求，请求R版本的回退包。
服务器在接收到搜包请求后，可以基于搜包请求中携带的请求信息确定R版本。其中，请求信息包括S版本(即电子设备当前运行的版本)的版本号；还可以包括设备标识和/或片区信息。下面将说明电子设备基于S版本的版本号、设备标识、片区信息确定R版本的具体实现。
方式一，服务器基于S版本的版本号确定R版本。
服务器可以基于S版本的版本号将低于S版本的版本确定为R版本。例如，S版本为V3.0，V2.0比V3.0低，则可以将V2.0确定为R版本。
在一种具体的实现方式中，为了避免回退到过于久远的操作系统，或者为了避免回退到有漏洞的操作系统等，服务器中可以记录回退前的版本号及其可以回退的版本号之前的对应关系。其中，可以回退的版本号是回退前的版本号之前、与回退前的版本号距离较近、且漏洞较小的操作系统的版本号(也可以称为预设版本的版本号)。示例性的，服务器中记录有如下表1所示的对应关系：
表1
上表1反映出，V1.1可以回退到V1.0，V2.3可以回退到V2.2，V3.2可以回退到V3.1。
因此，服务器在接收到搜包请求后，查询搜包请求中携带的版本号对应的可以回退的版本号，从而可以确定回退版本。例如，搜包请求中携带的版本号为V2.3，查询上表1，确定可以回退的版本号为V2.2，即R版本为V2.2。
采用上述方式一，可以将比S版本更低的版本确定为R版本。
方式二，服务器基于S版本的版本号和设备标识确定R版本。
其中，设备标识包括设备名称、设备型号或者产品序列号(Serial Number，SN)等信息。
具体地，为了避免回退到用户从未使用过的版本，服务器可以基于S版本的版本号和设备标识，将比S版本低、且比电子设备出厂时安装的版本高的版本确定为R版本。其中，服务器基于设备标识可以查询电子设备出厂时安装的版本，比电子设备出厂时安装的版本低的版本被认为是用户未使用过的版本。
示例性的，手机A出厂时安装的操作系统为V2.0，V1.1和V1.0低于V2.0。也就是说，手机A中应该没有安装过V1.1和V1.0的操作系统。并且，电子设备当前运行的S版本为V3.2，V3.2高于V2.0、V1.1、V1.0。那么，服务器可以将低于V3.2，但是高于V2.0的版本确定为R版本，如V2.1、V3.0等版本确定为R版本，而不会将V1.1和V1.0确定为R版本。采用上述方式二，可以将比S版本更低、且用户使用过的版本确定为R版本。
方式三，服务器基于版本号S和片区标识确定目标R版本。
其中，片区信息可以是地区名称、经纬度信息、移动网络代码(MCCMNC)等指示电子设备的使用地区的信息。例如，片区信息可以是C城市、D城市等。其中，使用地区可以是电子设备定位得到的，也可以是用户输入的，本申请实施例对此不作具体限定。
实际中，操作系统的提供方，可能会为不同地区使用的电子设备，提供不同版本的操作系统。例如，国内版、海外版等。基于此，为了避免回退到电子设备的使用地区不能使用的版本，服务器可以基于S版本的版本号和片区信息，将比S版本低、且电子设备的使用地区可以使用的版本确定为R版本。其中，服务器基于片区信息可以 查询电子设备的使用地区可以使用的版本。
示例性的，在国内使用的手机可以安装的操作系统的版本包括V3.1和V3.2，在海外使用的手机可以安装的操作系统的版本包括V3.3。也就是说，国内使用的手机不能安装V3.3版本的操作系统，海外使用的手机不能安装V3.1和V3.2的操作系统。并且，电子设备的片区信息显示电子设备在国内使用，且当前运行的S版本为V4.0，V4.0高于V3.1、V3.2、V3.3。那么，服务器可以将低于V4.0，且可以在国内使用的版本确定为R版本，如将V3.1、V3.2等版本确定为R版本，而不会将V13.3确定为R版本。
采用方式三，可以将比S版本更低、且电子设备的使用地区允许安装的版本确定为R版本。
当然，服务器也可以将上述方式二和方式三结合，从而将比S版本更低、用户使用过的、且电子设备的使用地区允许安装的版本确定为R版本。
需要在此说明的是，服务器确定出的R版本可能为一个或多个。如果R版本有多个，服务器可以从中筛选出一个，例如，从多个R版本中选择出最新的版本；或者，服务器可以将多个R版本发送给电子设备，供用户从中选择一个。本申请实施例对此不作具体限定。下文将主要以确定出一个R版本为例来说明。
在确定出R版本之后，服务器可以向电子设备反馈R版本的安装包(即回退包)的下载地址。电子设备根据下载地址可以下载得到回退包，从而获得回退包。
在一些实施例中，回退包中还包括R版本的版本信息。电子设备在获取到回退包之后，可以显示包括R版本的版本信息的第二界面。其中，版本信息包括版本名称、版本大小、版本特色、更新注意事项等信息。如此，方便用户了解R版本，确认是否需要回退。
继续参见图11，手机响应于用户对界面1101中“更早版本”的选择操作，向服务器发送搜包请求，并获取到回退包之后，可以显示图11所示的界面1102，界面1102也是手机助手应用的应用界面。界面1102中包括R版本的版本信息，如版本名称“YYYYYYYYY(正式版)”、版本大小“4.53GB”、版本特色“提升系统稳定性，让您的手机运行更稳定”等信息。
以及，第二界面中包括恢复控件(也可以称为第二控件)，恢复控件用于触发电子设备将操作系统回退到R版本，即用于触发电子设备安装R版本的操作系统。电子设备响应于用户对恢复控件的预设操作(如点击操作、长按操作等，也可以称为第二操作)，可以开始执行回退到R版本的操作，如执行下文S1003及其后续步骤。
继续参见图11，恢复控件是图11所示界面1102中的“恢复”按钮。手机响应于用户对界面1102中“恢复”按钮的点击操作，可以开始执行回退到R版本的操作。即，对恢复控件的预设操作是对界面1102中“恢复”按钮的点击操作。
当然，在另一些实施例中，电子设备在获取到回退包之后，也可以直接开始执行回退到R版本的操作。
S1003、电子设备根据回退包针对静态分区(B)进行数据写入操作以更新静态分区(B)。
回退包中包括R版本的操作系统的全量系统数据，进一步包括需要存储在静态分区的系统数据(也可以称为第一系统数据)和需要存储在动态分区(Super)的系统数 据(也可以称为第二系统数据)。
在S1003中，电子设备可以将回退包中，需要存储在静态分区的系统数据写入到静态分区(B)中，使静态分区(B)中存储R版本所需的一部分系统数据。并且，由于电子设备当前从静态分区(A)启动，则向静态分区(B)写入系统数据，不会影响当前S版本的运行。
S1004、电子设备根据回退包在用户数据分区(Userdata)中写入动态分区(Super)的系统数据。
在S1004中，电子设备可以将回退包中，需要存储在动态分区(Super)的系统数据写入到用户数据分区(Userdata)中，使用户数据分区(Userdata)中存储R版本所需的另一部分系统数据。并且，电子设备向用户数据分区(Userdata)，而非动态分区(Super)写入系统数据，不会影响当前S版本的运行。
在一些实施例中，电子设备可以在用户数据分区(Userdata)中创建虚拟动态分区，在虚拟动态分区写入动态分区(Super)的系统数据。
在用户数据分区(Userdata)的虚拟动态分区中，电子设备可以采用写时拷贝(Copy-On-Write，cow)文件保存系统数据。其中，在虚拟动态分区中，可以保存多个cow文件，每个cow文件对应动态分区(Super)的一个子分区。即，一个cow文件中存储动态分区(Super)的一个子分区中需要存储的系统数据。
并且，cow文件的命名与其所对应的动态分区(Super)的子分区相对应。在回退包中，动态分区(Super)的系统数据的cow文件以二进制代码形式压缩保存，每个cow文件根据其所对应的动态分区(Super)的子分区所命名。例如，对应system子分区的cow文件被命名为system-cow-img.img.0000。
在S1004中，电子设备解析回退包以获取所有的cow文件，为每个cow文件附加A/B分区标记。具体的，当电子设备当前从静态分区(A)启动时，可以理解为电子设备当前运行操作系统所加载的动态分区(Super)为动态分区(A)。那么，虚拟动态分区中存储的系统数据是针对动态分区(B)的。因此，为cow文件附加对应动态分区(B)的名称标记_b。例如，为system-cow-img.img.0000附加_b生成system_b-cow-img.img.0000。
在将cow文件写入虚拟动态分区之后，电子设备将基础分区(Common)的元数据(metadata)子分区中的落盘状态信息由“已落盘(merged)”改为“未落盘(wait for merge)”。落盘状态信息用于表示当前是否存在需要落盘到动态分区(Super)的cow文件。具体的，落盘状态信息包含针对动态分区(Super)的整体标识以及针对动态分区(Super)的各个子分区的子分区标识。当整体标识为“已落盘(merged)”时，代表动态分区(Super)的所有子分区均不需要进行落盘操作；当整体标识为“未落盘(wait for merge)”时，代表动态分区(Super)的一个或多个子分区需要进行落盘操作；当子分区标识为“已落盘(merged)”时，代表该子分区不需要进行落盘操作；当子分区标识为“未落盘(wait for merge)”时，代表该子分区需要进行落盘操作。也就是说，电子设备将基础分区(Common)的元数据(metadata)子分区中的落盘状态信息由“已落盘(merged)”改为“未落盘(wait for merge)”，包括：将整体标识改为“未落盘”，以及将各个子分区的子分区标识也改为“未落盘”。
在将cow文件写入虚拟动态分区之后，电子设备还可以创建cow文件的索引。其中，cow文件的索引用于指示cow文件的名称和/或cow文件在虚拟动态分区中的存储位置。该cow文件的索引可用于电子设备后续从虚拟动态分区中读取cow文件。示例性的，电子设备可以在metadata子分区中创建cow文件的索引，后续，电子设备可以基于metadata子分区中cow文件的索引来读取cow文件。
S1005、电子设备将启动顺序由从静态分区(A)启动变更为从静态分区(B)启动。
电子设备当前从静态分区(A)启动，即启动顺序为从静态分区(A)启动。在将启动顺序由从静态分区(A)启动变更为从静态分区(B)启动后，可以使电子设备下次启动时，从静态分区(B)启动。从而可以运行在R版本的操作系统下。
以采用主引导记录(Master Boot Record，MBR)格式的通用闪存(Universal Flash Storage，UFS)为例。在UFS的MBR(主引导扇区，UFS的第一个扇区，即C/H/S地址的0柱面0磁头1扇区)中，保存有设备启动顺序描述。例如，启动顺序标志为A，指示从静态分区(A)启动；启动顺序标志为B，指示从静态分区(B)启动。设备启动后首先从UFS的MBR中读取设备启动顺序，从而确定需要从静态分区(A)还是静态分区(B)启动。因此，电子设备可以将MBR中启动顺序标志从A改写为B。
应理解，将启动顺序由从静态分区(A)启动变更为从静态分区(B)启动，只是指示电子设备下次从静态分区(B)启动，而不会立即生效。只有在下次启动(如重启)时，才会生效。
另外，S1005的执行时机并不以图10所示为限，实际实施时，只要在下一次启动电子设备前(如S1006中重启前)，变更启动顺序即可。
需要在此说明的是，在执行上述S1003-S1005的过程中，电子设备处于待机状态，即电子设备可以显示供用户正常使用的第三界面。示例性的，在执行上述S1003-S1005的过程中，电子设备可以正常显示图12所示的界面1201，界面1201为视频播放界面，用户可以正常观看视频。
在一些实施例中，在上述S1003-S1005执行完成后，电子设备可以发出提示信息，以提示需要重启电子设备才能回退到R版本。示例性的，在S1003-S1005执行完成后，手机可以显示图12所示的界面1202，界面1202中包括提示信息1203，提示信息1203具体为“手机需要重启才能恢复到YYYYYYYYY(正式版)，是否立即重启！”，从而提示用户需要重启手机才能回退到YYYYYYYYY(正式版)版本。
然后，电子设备在检测到确认重启的操作后，才可以执行下述S1006，以继续完成回退到R版本的操作。示例性的，提示信息为图12所示界面1202中的提示信息1203，提示信息1203中还包括“是”和“否，另选时间重启”两个选项。确认重启的操作可以是用户对“是”选项的选择操作。手机响应于用户对界面1202中提示信息1203中的“是”选项的选择操作，则可以开始执行下述S1006。或者，确认重启的操作也可以是用户选择重启时间的操作。例如，手机响应于用户对界面1202中提示信息1203中的“否，另选时间重启”选项的选择操作，可以显示图12所示的界面1204。界面1204中包括时间选择弹窗1205，时间选择弹窗1205中包括多个时间选项，如1分钟、2分钟、3分钟……。选择重启时间的操作可以是用户对时间选择弹窗1205中任一时 间选项(如4分钟)的选择并点击“确认”的操作。电子设备响应于用户选择重启时间的操作，可以在选择的时间到达后，开始执行下述S1006。
采用本实施例，电子设备可以仅在用户确认重启后，才会重启电子设备并继续完成回退到R版本的操作。
当然，在另一些实施例中，电子设备在上述S1003-S1005执行完成后，可以无需用户确认，紧接着执行S1006。本申请实施例对此不作具体限定。
S1006、电子设备重启并进入recovery模式。
本申请中，电子设备需要在recovery模式下将用户数据分区(Userdata)中的系统数据落盘(merge)到动态分区(Super)中。因此，此次重启还需要触发进入recovery模式。示例性的，电子设备可以使用如下重启指令控制电子设备重启并进入recovery模式：
property_set(ANDROID_RB_PROPERTY，“reboot，recovery”)。
并且，由于已经将启动顺序由从静态分区(A)启动变更为从静态分区(B)启动，则电子设备重启时，会从静态分区(B)启动并进入recovery模式。其中，为了保证recovery模式正常运行，电子设备需要加载基础分区(Common)和静态分区(B)中维持recovery模式正常运行所需的子分区，如recovery子分区、boot子分区等。
需要说明的是，电子设备无论是获取到从S版本回退到R版本的回退包，还是获取到从R版本升级到S版本的升级包之后，并不会区分回退包还是升级包，而都会按照前述S1001-S1005的处理流程来处理。
但是，在常规从R版本的操作系统升级到S版本的操作系统的过程中，正常重启后，就可以将用户数据分区(Userdata)中的系统数据落盘(merge)到动态分区(Super)中。而在从R版本的操作系统升级到S版本的操作系统时，则需要重启进入recovery模式，并在recovery模式下，将用户数据分区(Userdata)中的系统数据落盘(merge)到动态分区(Super)中。也就是说，从S版本(S)回退到R版本(R)的场景1中需要重启进入recovery模式。
基于此，在一些实施例中，在执行完上述S1001-S1005之后，电子设备需要确定当前获取到的是否为回退包，并在确定为回退包之后，才执行S1006，以在recovery模式下，将用户数据分区(Userdata)中的系统数据落盘(merge)到动态分区(Super)中。
在一种具体的实现方式中，电子设备可以将安装包中携带的版本号和电子设备当前运行的操作系统的版本号比较。其中，安装包包括从S版本回退到R版本的回退包或者从R版本升级到S版本的升级包。
如果安装包是回退包，则安装包中携带的为R版本的版本号(也可以称为第一版本号)，电子设备当前运行的操作系统的版本号为S版本的版本号(即第二版本号)，R版本低于S版本，相应的，R版本的版本号低于S版本的版本号。也就是说，如果是回退包，则其应该用于安装比电子设备当前运行的版本(即S版本)更低版本的操作系统，则安装包中携带的版本号低于电子设备当前运行的操作系统的版本号。
如果安装包是升级包，则安装包中携带的为S版本的版本号，电子设备当前运行的操作系统的版本号为R版本的版本号，S版本高于R版本，相应的，S版本的版本 号高于R版本的版本号。也就是说，如果是升级包，则安装包中携带的版本号高于电子设备当前运行的操作系统的版本号。
因此，在本实现方式中，如果安装包中携带的版本号低于电子设备当前运行的操作系统的版本号，电子设备可以确定安装包为回退包。如果安装包中携带的版本号高于电子设备当前运行的操作系统的版本号，电子设备可以确定安装包为升级包。
另外，如果安装包中携带的版本号等于电子设备当前运行的操作系统的版本号，表明安装包有误，则停止针对该安装包的处理。
当然，实际实施时，并不以上述通过版本号的比较来确定回退包的实现方式为例。本领域技术人员可根据实际需求来区别回退包和升级包。示例性的，服务器可以在回退包中添加回退标记。电子设备可以通过识别安装包中是否包括回退标记来确定安装包是否为回退包。
相应的，参见图13，在S1006之前，还包括S1301：
S1301、电子设备确定当前获取的是回退包。
其中，确定为回退包，即确定为从S版本回退到R版本的场景1。
也就是说，在本实施例中，只有在确定获取的为回退包的情况下，才重启进入recovery模式。从而避免在获取的为升级包的情况下，错误的进入到recovery模式。
在场景1中，电子设备在进入recovery模式后，可以在recovery模式下执行下述S1007-S1009，以继续完成回退到R版本的处理。
S1007、电子设备将用户数据分区(Userdata)中的系统数据落盘到动态分区(Super)。
在本申请实施例的描述中，落盘操作指的是，将用户数据分区(Userdata)中保存的动态分区(Super)的系统数据(cow文件)写入到动态分区(Super)中，使得动态分区(Super)的文件完成数据更新，以便电子设备在下次启动时，通过加载动态分区(Super)就可以完成电子设备启动。
在一些实施例中，在进入recovery模式后，电子设备可以读取落盘状态信息和cow文件的索引，基于落盘状态信息和cow文件的索引来完成落盘处理。
通过读取落盘状态信息，电子设备可以确定是否需要从用户数据分区(Userdata)中检索相应子分区对应的cow文件。具体的，读取到落盘状态信息的整体标识为“已落盘”时，则确定无需从用户数据分区(Userdata)中检索所有子分区对应的cow文件。读取到落盘状态信息的整体标识为“未落盘”时，则可以进一步读取落盘状态信息中针对各个子分区的子分区标识。若子分区标识为“已落盘”，则确定无需从用户数据分区(Userdata)中检索相应子分区对应的cow文件。若子分区标识为“未落盘”，则确定需要从用户数据分区(Userdata)中检索相应子分区对应的cow文件。
然后，通过读取cow文件的索引，电子设备可以获取cow文件的文件名称和/或存储位置，从而从用户数据分区(Userdata)中检索到相应的cow文件。
最后，电子设备将从用户数据分区(Userdata)中检索到的cow文件写入到动态分区(Super)的相应子分区中，完成动态分区(Super)的落盘处理。
采用S1007，可以将用户数据分区(Userdata)中存储的系统数据落盘(merge)到动态分区(Super)，使动态分区(Super)中存储R版本的系统数据，确保后续可以成功运行R版本的操作系统。
实际中，进入recovery模式，可以完成对电子设备内部的数据或操作系统的多种处理。例如，修改电子设备的制式，将演示制式修改为商用制式。又例如，使用recovery模式调分区表。再例如，本申请中使用recovery模式完成S版本回退到R版本的处理。
基于此，在一些实施例中，在进入recovery模式后，电子设备首先需要确定此次进入recovery模式的目的，从而便于准确执行相应的处理来达到目的。那么，在本申请，需要确定当前是否为回退场景，从而便于准确执行S版本回退到R版本的处理。
在一种具体的实现方式中，电子设备在前述S1301中确定出为回退包之后，则可以在子分区A(也可以称为预设子分区)中写入用于指示当前为回退场景的预设标识。其中，子分区A是recovery模式下可以访问的分区。例如，子分区A是基础分区(Common)的Misc子分区。
那么，在进入recovery模式后，电子设备可以从子分区A中读取预设标识。如果读取到预设标识，则确定当前为回退场景。如果没有读取到预设标识，则确定当前不是回退场景。
示例性的，在场景1中，S1301中确定出为回退包后，电子设备可以在子分区A中写入预设标识。相应的，在S1006之后，电子设备从子分区A中读取到预设标识，则可以确定当前是回退场景。
当然，实际实施时，也并不以从子分区A中读取预设标识，确定当前是否为回退场景的方式为限。本领域技术人员可根据实际需求来采用相应的技术识别回退场景。示例性的，电子设备也可以在重启进入recovery模式之前，将安装包存储到recovery模式可以访问的预设目录下。在进入recovery模式之后，可以从预设目录中解析安装包。如果安装包中包括回退表示，则确定当前是回退场景。如果安装包中不包括回退标识，则确定当前不是回退场景。
相应的，继续参见图13，在进入recovery模式后，在S1007之前，还包括S1302：
S1302、电子设备识别到当前为回退场景。
也就是说，在本实施例中，只有在识别到为回退场景的情况下，才进一步执行落盘(merge)及其后续处理。从而避免在不需要回退的场景中，在recovery模式下错误的执行落盘等处理，最终影响系统运行。
S1008、电子设备将静态分区(B)中的系统数据同步给静态分区(A)。
在一些实施例中，在完成落盘(merge)后，电子设备还可以将静态分区(B)中各个子分区存储的系统数据同步给静态分区(A)中的相应子分区，使静态分区(A)中也存储R版本的系统数据。那么，此后从静态分区(A)启动时，也可以运行R版本的操作系统。
示例性的，参见图14，在同步前，静态分区(A)中存储的是V3.0版本的系统数据，静态分区(B)中存储的是V2.0版本的系统数据。通过同步，可以将静态分区(B)中V2.0版本的系统数据，同步到静态分区(A)中，使得静态分区(A)中也存储V2.0版本的系统数据。继续参见图14，在同步后，静态分区(A)和静态分区(B)中都包括v2.0版本的系统数据。
S1009、电子设备恢复出厂设置。
其中，恢复出厂设置包括格式化用户数据分区(Userdata)、基础分区(common) 中cache子分区、metadata子分区等。
在完成落盘(merge)处理之后，电子设备恢复出厂设置，可以格式化用户数据分区(Userdata)，从而使用户数据分区(Userdata)中不再存有需要解密才能访问的数据。
至此，需要说明的是，与待机状态不同的是：在recovery模式下，电子设备是无法正常使用的。示例性的，在重启并进入recovery模式之后，手机可以显示图15所示的界面1501(也可以称为第四界面)，界面1501中包括在recovery模式下，回退到R版本的进度(也可以称为进度提示信息)，即S1007-S1009的执行进度。例如，界面1501中显示的进度为0％。并且，当进度达到图15所示界面1502中的100％时，则表明S1007-S1009执行完成。其中，界面1501和界面1502都是不可操作的，用户无法正常使用。
在recovery模式中，当上述S1007-S1009执行完成后，电子设备可以执行下述S1010，使电子设备可以运行在R版本的操作系统下。
S1010、电子设备重启。
示例性的，电子设备可以使用如下重启指令控制电子设备重启：
property_set(ANDROID_RB_PROPERTY，“reboot”)。
需要说明的是，与S1006中的重启不同的是：在S1010中，重启是正常重启，因此重启后电子设备会进入到正常使用的状态，而不会进入到recovery模式。
S1011、电子设备依次加载基础分区(Common)、静态分区(B)以及动态分区(Super)，从静态分区(B)启动。
由于启动顺序已经变更为从静态分区(B)启动，则电子设备会从静态分区(B)启动。
S1012、电子设备成功挂载用户数据分区(Userdata)，进入用户交互界面，运行在R版本的操作系统下。
静态分区(B)和动态分区(Super)中都是存储的R版本的系统数据，则加载静态分区(B)以及动态分区(Super)，相当于可以加载R版本的操作系统。同时，用户数据分区(Userdata)中不再存有需要解密才能访问的数据，不会出现无法加载的问题，从而电子设备可以成功启动。最终，电子设备可以成功运行在R版本的操作系统下。示例性的，从静态分区(B)启动后，电子设备可以显示图15所示的界面1503，界面1503为手机桌面。
下面结合电子设备的软件组成，对场景1中下载回退包(如图10和图13中的S1002)至完成回退(如图10和图13中的S1010)的一种具体实现做进一步的说明。
具体的，参见图16，场景1的具体实现包括：
S1601、ouc apk下载回退包，回退包中包括R版本的版本号。具体可参见前文S1002的说明。
S1602、ouc apk向update engine发送回退包。
S1603、update engine根据回退包针对静态分区(B)进行数据写入操作以更新静态分区(B)。具体可参见前文S1003的说明。
S1604、update engine根据回退包在用户数据分区(Userdata)中写入动态分区 (Super)的系统数据。具体可参见前文S1004的说明。
S1605、update engine将启动顺序变更由从静态分区(A)启动变更为从静态分区(B)启动。具体可参见前文S1005的说明。
S1606、update engine将R版本的版本号与当前运行的S版本的版本号比较，确定当前获取的是回退包。具体可参见前文S1301及其上下文的说明。
S1607、update engine在子分区A中写入用于指示当前为回退场景的预设标识。
示例性的，update engine在基础分区(Common)的Misc子分区中写入预设标识，即子分区A是基础分区(Common)的Misc子分区。具体可参见前文S1302及其上下文的说明。
S1608、update engine触发重启并进入recovery模式。具体可参见前文S1006的说明。
也就是说，在确定当前获取到的是回退包的情况下，才重启进入recovery模式。
S1609、recovery进程从子分区A中读取到预设标识。
其中，从子分区A中读取到预设标识，则表示当前为回退场景。具体可参见前文S1302及其上下文的说明。
S1610、recovery进程触发启动落盘(merge)服务。
S1611、merge服务将虚拟动态分区的数据落盘到动态分区(Super)。
也就是说，由merge服务来完成落盘处理。具体可参见前文S1007的说明。
S1612、recovery进程将静态分区(B)中的数据同步给静态分区(A)。具体可参加前文S1008的说明。
S1613、recovery进程格式化用户数据分区(Userdata)。具体可参见前文S1009的说明。
S1614、recovery进程触发重启。具体可参见前文S1010的说明。
场景2，从R版本的操作系统，升级到S版本的操作系统，R版本低于S版本。即，从低版本的操作系统升级到高版本的操作系统的场景，也可以称为升级场景。为了便于说明，可以将场景2中的R版本称为第三版本，S版本称为第一版本。应理解，场景2中的R版本可与场景1中的R版本相同，也可以不同。本申请实施例对此不做具体限定。
在场景2中，电子设备可以在待机状态下写入S版本的操作系统的系统数据。并且，由于是从低版本的操作系统升级到高版本的操作系统，使用高版本的操作系统的密钥可以解密用户数据分区(Userdata)中加密的数据，则在写入S版本的操作系统的系统数据后，可以直接重启电子设备，运行在S版本的操作系统下。而无需在recovery模式下完成落盘处理并格式化用户数据分区(Userdata)后，再启动电子设备运行S版本的操作系统。
参见图17，以电子设备当前从静态分区(A)启动为例，在场景2中，从R版本的操作系统，升级到S版本的操作系统的过程包括以下步骤：
S1701、电子设备依次加载基础分区(Common)、静态分区(A)以及动态分区(Super)，从静态分区(A)启动，运行在R版本的操作系统下。
为了便于说明，可以将场景2中的静态分区(A)称为第二静态分区，静态分区 (B)称为第一静态分区。
S1702、电子设备获取S版本的升级包。
其中，S版本的升级包也可以称为第二安装包。与前文回退包类似的，升级包中也包括需要存储在静态分区的系统数据(也可以称为第三系统数据)和需要存储在动态分区(Super)的系统数据(也可以称为第四系统数据)。
示例性的，电子设备可以定期向服务器发起搜包请求，搜包请求包含电子设备当前运行的操作系统的版本号，如版本号V1.0。服务器根据搜包请求中的版本号，检索当前是否存在更新的操作系统的安装包(例如版本2.0的操作系统的安装包，也可以称为升级包)。当存在升级包时，服务器向电子设备反馈升级包的下载地址。电子设备根据下载地址下载安装包。
S1703、电子设备根据升级包针对静态分区(B)进行数据写入操作以升级静态分区(B)。
示例性的，向静态分区(B)写入第三系统数据。
S1704、电子设备根据升级包在用户数据分区(Userdata)中写入动态分区(Super)的系统数据。
示例性的，向用户数据分区(Userdata)写入第四系统数据。
S1703-S1704的具体实现，可参见前文S1003-S1004的说明，此处不再赘述。主要存在区别在于：回退包和升级包中的数据是不同的。
S1705、电子设备将启动顺序由从静态分区(B)启动变更为从静态分区(B)启动。具体可参见前文S1005的说明。
S1706、电子设备确定当前获取到的不是回退包。具体可参见前文S1301及其上下文的说明。
示例性的，安装包中携带的是S版本的版本号，电子设备中当前运行的操作系统的版本号是R版本的版本号(也可以称为第三版本号)，S版本的版本号高于R版本的版本号。即安装包中携带的版本号高于电子设备当前运行的操作系统的版本号。那么，电子设备可以确定当前获取到的不是回退包，即安装包不是用于安装比R版本更低版本的操作系统的。
S1707、电子设备重启。
在场景2中，确定出获取到的不是回退包，因此无需重启并进入recovery模式，而只是正常重启即可。
另外，与前文S1006不同的是：S1707中的重启通常是通过硬件重启。例如，用户长按电源键，触发重启。如此，可以在用户无需使用电子设备时，触发电子设备重启。
S1708、电子设备依次加载基础分区(Common)、静态分区(B)，从静态分区(B)启动。
S1709、电子设备加载动态分区(Super)以及用户数据分区(Userdata)。
示例性的，电子设备采用snapshot合并加载动态分区(Super)以及从用户数据分区(Userdata)中检索到的cow文件(即第四系统数据)。
S1710、电子设备成功挂载用户数据分区(Userdata)，进入用户交互界面，运行 在R版本的操作系统下。
由于是从R版本升级到S版本，密钥是兼容的，因此可以成功挂载用户数据分区。
S1711、电子设备将用户数据分区(Userdata)中的系统数据落盘到动态分区(Super)。
示例性的，将用户数据分区中的第四系统数据写入动态分区(Super)。
关于上述S1708-S1711的具体实现，可参见虚拟A/B升级的相关现有技术的说明，此处不再赘述。
S1712、电子设备将静态分区(B)中的数据同步给静态分区(A)。具体可参见前文S1008的说明。
场景3，电子设备当前运行在R版本的操作系统下，并且在非场景1的情况下进入到recovery模式。
为了便于说明，可以将场景3中的R版本称为第二版本。
其中，非场景1的情况(也可以称为预设事件)是指除场景1之外，需要在recovery模式下完成相应处理的情况，其包括但不限于以下任一种情况：用户手动操作进入recovery模式进行刷机、恢复出厂设置等处理的情况；在有改制(从演示制式改为商用制式)需求时进入recovery模式实现改制的情况；以及，在需要修改数据存储结构时进入recovery模式改数据存储结构的情况。
场景3中，电子设备在重启进入recovery模式后，会确定出当前不是回退场景，即确定此次进入修复模式不是为了安装比所述第一版本更低版本的操作系统的。示例性的，由于并不是在获取到回退包之后进入到recovery模式，则子分区A中不会记录预设标识，相应的，在recovery模式下，电子设备从子分区A中不会读取到预设标识，从而确定不是回退场景。那么，在进入recovery模式后，不会执行动态分区(Super)的落盘以及用户数据分区(Userdata)的格式化等处理。而是会基于识别到的其他目的，来完成相应的处理。例如，识别到为修改数据存储结构的场景，则在recovery模式下，电子设备可以执行修改数据存储结构的操作。又例如，识别到为改制场景，则在recovery模式下，电子设备可以执行将演示制式改为商用制式的操作。
本申请实施例还提供一种电子设备，该电子设备可以包括：存储器和一个或多个处理器。该存储器和处理器耦合。该存储器用于存储计算机程序代码，该计算机程序代码包括计算机指令。当处理器执行计算机指令时，可使得电子设备执行上述实施例中的各个步骤。当然，该电子设备包括但不限于上述存储器和一个或多个处理器。
本申请实施例还提供一种芯片系统，该芯片系统可以应用于前述实施例中的电子设备。如图18所示，该芯片系统包括至少一个处理器1801和至少一个接口电路1802。该处理器1801可以是上述电子设备中的处理器。处理器1801和接口电路1802可通过线路互联。该处理器1801可以通过接口电路1802从上述电子设备的存储器接收并执行计算机指令。当计算机指令被处理器1801执行时，可使得电子设备执行上述实施例中的各个步骤。当然，该芯片系统还可以包含其他分立器件，本申请实施例对此不作具体限定。
在一些实施例中，通过以上的实施方式的描述，所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将装置的内部结构划 分成不同的功能模块，以完成以上描述的全部或者部分功能。上述描述的系统，装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。
在本申请实施例各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。
所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请实施例的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)或处理器执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：快闪存储器、移动硬盘、只读存储器、随机存取存储器、磁碟或者光盘等各种可以存储程序代码的介质。
以上所述，仅为本申请实施例的具体实施方式，但本申请实施例的保护范围并不局限于此，任何在本申请实施例揭露的技术范围内的变化或替换，都应涵盖在本申请实施例的保护范围之内。因此，本申请实施例的保护范围应以所述权利要求的保护范围为准。

Claims (19)

  1. 一种操作系统的升级方法，其特征在于，应用于电子设备，所述电子设备包括存储器，所述存储器包括基础分区、第一静态分区、第二静态分区、动态分区以及用户数据分区，所述方法包括：
    加载所述基础分区、所述第一静态分区和所述动态分区，运行第一版本的操作系统；
    获取第一安装包，所述第一安装包为第二版本的操作系统的安装包，所述第二版本低于所述第一版本，所述第一安装包中包括所述第二版本的操作系统的第一系统数据和第二系统数据；
    向所述第二静态分区写入所述第一系统数据，向所述用户数据分区写入所述第一系统数据；
    重启并进入修复模式；
    在所述修复模式下，将所述用户数据分区中的所述第二系统数据写入到所述动态分区，格式化所述用户数据分区；
    重启，加载所述基础分区、所述第二静态分区和所述动态分区，运行所述第二版本的操作系统。
  2. 根据权利要求1所述的方法，其特征在于，所述重启并进入修复模式之前，所述方法还包括：
    确定所述第一安装包用于安装比所述第一版本更低版本的操作系统。
  3. 根据权利要求2所述的方法，其特征在于，所述第一安装包中包括第一版本号，所述第一版本号是所述第二版本的版本号，所述确定所述第一安装包用于安装比所述第一版本更低版本的操作系统的安装包，包括：
    确定所述第一版本号低于第二版本号，所述第二版本号是所述第一版本的版本号。
  4. 根据权利要求2或3所述的方法，其特征在于，在所述确定所述第一安装包用于安装比所述第一版本更低版本的操作系统之后，所述方法还包括：
    在预设子分区中记录预设标识，所述预设子分区为所述修复模式下可访问的子分区；
    所述在所述修复模式下，将所述用户数据分区中的所述第二系统数据写入到所述动态分区，格式化所述用户数据分区，包括：
    在所述修复模式下，如果从所述预设子分区中读取到所述预设标识，则将所述用户数据分区中的所述第二系统数据写入到所述动态分区，格式化所述用户数据分区。
  5. 根据权利要求1-4中任一项所述的方法，其特征在于，在所述获取第一安装包之前，所述方法还包括：
    显示第一界面，所述第一界面中包括第一控件；
    响应于用户对所述第一控件的第一操作，向服务器发送搜包请求；
    接收所述服务器基于所述搜包请求反馈的下载地址；
    所述获取第一安装包，包括：
    基于所述下载地址下载所述第一安装包。
  6. 根据权利要求1-5中任一项所述的方法，其特征在于，在所述获取第一安装包之 后，所述方法还包括：
    显示第二界面，所述第二界面中包括所述第二版本的操作系统的版本信息和第二控件，所述第二控件用于触发安装所述第二版本的操作系统；
    所述向所述第二静态分区写入所述第一系统数据，向所述用户数据分区写入所述第一系统数据，包括：
    响应于用户对所述第二控件的第二操作，向所述第二静态分区写入所述第一系统数据，向所述用户数据分区写入所述第一系统数据。
  7. 根据权利要求1-6中任一项所述的方法，其特征在于，在所述将所述用户数据分区中的所述第二系统数据写入所述动态分区之后，所述方法还包括：
    将所述第二静态分区中的所述第一系统数据同步给所述第一静态分区。
  8. 根据权利要求1-7中任一项所述的方法，其特征在于，在所述向所述第二静态分区写入所述第一系统数据，向所述用户数据分区写入所述第一系统数据的过程中，所述方法还包括：
    显示第三界面，所述第三界面是所述电子设备待机状态下的界面。
  9. 根据权利要求1-8中任一项所述的方法，其特征在于，在所述修复模式下，将所述用户数据分区中的所述第二系统数据写入所述动态分区，格式化所述用户数据分区的过程中，所述方法还包括：
    显示第四界面，所述第四界面中包括进度提示信息，所述进度提示信息用于提示落盘以及格式化的进度；其中，电子设备不会响应用户在所述第四界面的操作。
  10. 根据权利要求1-9中任一项所述的方法，其特征在于，所述重启并进入修复模式，包括：
    重启并启动修复进程；
    所述在所述修复模式下，将所述用户数据分区中的所述第二系统数据写入所述动态分区，包括：
    所述修复进程触发启动落盘服务，所述落盘服务将所述用户数据分区中的所述第二系统数据写入到所述动态分区；
    所述修复进程格式化所述用户数据分区。
  11. 根据权利要求1-10中任一项所述的方法，其特征在于，所述第二版本满足以下至少一个条件：
    所述第二版本是预设版本；
    所述第二版本高于所述电子设备出厂时安装的操作系统的版本；
    所述第二版本是所述电子设备的使用地区允许安装的版本。
  12. 根据权利要求1-11中任一项所述的方法，其特征在于，在所述加载所述基础分区、所述第一静态分区和所述动态分区，运行第一版本的操作系统之前，所述方法还包括：
    加载所述基础分区、所述第二静态分区和所述动态分区，运行第三版本的操作系统，所述第三版本低于所述第一版本；
    获取第二安装包，所述第二安装包用于升级到所述第一版本的操作系统，所述第二安装包中包括所述第一版本的操作系统的第三系统数据和第四系统数据；
    向所述第一静态分区写入所述第三系统数据，向所述用户数据分区写入所述第四系统数据；
    重启；
    所述加载所述基础分区、所述第一静态分区和所述动态分区，运行第一版本的操作系统，包括：
    加载所述基础分区、所述第一静态分区、所述动态分区以及所述用户数据分区中的第四系统数据，运行所述第一版本的操作系统。
  13. 根据权利要求12所述的方法，其特征在于，在所述加载所述基础分区、所述第一静态分区、所述动态分区以及所述用户数据分区，运行所述第一版本的操作系统之后，所述方法还包括：
    将所述用户数据分区中的所述第四系统数据写入所述动态分区。
  14. 根据权利要求12或13所述的方法，其特征在于，在所述重启，加载所述基础分区、所述第一静态分区、动态分区以及用户数据分区之前，所述方法还包括：
    确定所述第二安装包不用于安装比所述第三版本更低版本的操作系统。
  15. 根据权利要求14所述的方法，其特征在于，所述第二安装包中包括第二版本号，所述第二版本号是所述第一版本的版本号，所述确定所述第二安装包不用于安装比所述第三版本更低版本的操作系统，包括：
    确定第三版本号低于所述第二版本号，所述第三版本号是所述第三版本的版本号。
  16. 根据权利要求1-15中任一项所述的方法，其特征在于，在所述加载所述基础分区、所述第二静态分区和所述动态分区，运行所述第二版本的操作系统之后，所述方法还包括：
    响应于预设事件，重启再次进入所述修复模式；其中，如果确定再次进入所述修复模式不是为了安装比所述第一版本更低版本的操作系统的，则不会将所述用户数据分区中的数据写入所述动态分区的处理。
  17. 一种电子设备，其特征在于，所述电子设备包括处理器以及存储器，所述存储器包括基础分区、第一静态分区、第二静态分区、动态分区以及用户数据分区，所述处理器用于执行所述存储器上存储的软件代码，以使得所述电子设备执行如权利要求1-16中任一项所述的方法。
  18. 一种计算机可读存储介质，其特征在于，所述计算机可读存储介质中存储有计算机程序，当其在电子设备上运行时，使得所述电子设备执行如权利要求1-16中任一项所述的方法。
  19. 一种芯片系统，其特征在于，所述芯片系统应用于包括处理器和存储器的电子设备，所述芯片系统包括一个或多个接口电路和一个或多个处理器，所述接口电路和所述处理器通过线路互联，所述接口电路用于从所述电子设备的存储器接收信号，并向所述处理器发送所述信号，所述信号包括所述存储器中存储的计算机指令，当所述处理器执行所述计算机指令时，使得所述电子设备执行如权利要求1-16中任一项所述的方法。
PCT/CN2023/117785 2022-12-22 2023-09-08 一种操作系统的升级方法及电子设备 WO2024131151A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202211658830.4 2022-12-22
CN202211658830.4A CN118245075A (zh) 2022-12-22 2022-12-22 一种操作系统的升级方法及电子设备

Publications (1)

Publication Number Publication Date
WO2024131151A1 true WO2024131151A1 (zh) 2024-06-27

Family

ID=91561122

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2023/117785 WO2024131151A1 (zh) 2022-12-22 2023-09-08 一种操作系统的升级方法及电子设备

Country Status (2)

Country Link
CN (1) CN118245075A (zh)
WO (1) WO2024131151A1 (zh)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080307215A1 (en) * 2007-06-05 2008-12-11 Hewlett-Packard Development Company, L.P. Remote computer operating system upgrade
US20120079474A1 (en) * 2010-09-24 2012-03-29 Stephen Gold Reimaging a multi-node storage system
CN109753299A (zh) * 2019-01-16 2019-05-14 Oppo广东移动通信有限公司 一种系统升级方法、装置以及计算机存储介质
CN112416406A (zh) * 2020-11-30 2021-02-26 腾讯科技（深圳）有限公司 终端设备升级方法、装置、终端设备和介质
CN113805914A (zh) * 2021-06-15 2021-12-17 荣耀终端有限公司 操作系统升级方法、设备、存储介质及计算机程序产品

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080307215A1 (en) * 2007-06-05 2008-12-11 Hewlett-Packard Development Company, L.P. Remote computer operating system upgrade
US20120079474A1 (en) * 2010-09-24 2012-03-29 Stephen Gold Reimaging a multi-node storage system
CN109753299A (zh) * 2019-01-16 2019-05-14 Oppo广东移动通信有限公司 一种系统升级方法、装置以及计算机存储介质
CN112416406A (zh) * 2020-11-30 2021-02-26 腾讯科技（深圳）有限公司 终端设备升级方法、装置、终端设备和介质
CN113805914A (zh) * 2021-06-15 2021-12-17 荣耀终端有限公司 操作系统升级方法、设备、存储介质及计算机程序产品

Also Published As

Publication number Publication date
CN118245075A (zh) 2024-06-25

Similar Documents

Publication Publication Date Title
JP7346606B2 (ja) 画面共有処理方法、装置、機器及び記憶媒体
US20120102477A1 (en) Firmware update method and apparatus for a mobile device
JP4671198B2 (ja) 情報処理装置
US8930424B2 (en) Data storage system and method for protecting the system in case of power-failure
US20120179730A1 (en) Data Storage System and Method
JP2007323670A (ja) 情報処理装置、プログラムおよび情報処理装置の制御方法
CN105446768B (zh) 系统升级方法及装置
CA2710416C (en) Method and device for application archiving
JP2003303028A (ja) ナビゲーション装置のバージョンアップシステム
WO2015074435A1 (zh) 移动终端固件更新方法及装置
CN116048644B (zh) 一种系统迁移方法、装置和可读存储介质
KR101606373B1 (ko) 데이터 운용 방법과, 이를 지원하는 단말기 및 시스템
CN115328563B (zh) 系统启动方法及电子设备
WO2023169035A1 (zh) 操作系统的升级方法、电子设备及存储介质
WO2023130946A1 (zh) 操作系统升级方法、电子设备、存储介质及芯片系统
CN115543368A (zh) 一种操作系统升级方法及电子设备
RU2630371C2 (ru) Способ и устройство для обновления микропрограммного обеспечения
CN1327649C (zh) 移动通信系统和移动终端设备
WO2024131151A1 (zh) 一种操作系统的升级方法及电子设备
CN114489814B (zh) 一种终端设备的开机方法及终端设备
CN111158735A (zh) 一种热补丁文件处理方法及通信终端
US7308461B2 (en) Information processing method, apparatus, program and recording medium
WO2018028321A1 (zh) 一种虚拟外置存储设备的管理方法、装置及终端
CN115562732A (zh) 一种开机方法、电子设备及计算机存储介质
KR20190098516A (ko) 어플리케이션과 관련된 데이터를 관리하기 위한 방법 및 그 전자 장치