System upgrade information acquisition method, electronic equipment and storage medium

Abstract

The embodiment of the invention relates to the technical field of computers, in particular to a system upgrade information acquisition method, electronic equipment and a storage medium. According to the method, after one merge operation fails to be executed on the electronic equipment, one merge operation is executed again. According to the embodiment of the invention, the OUC in the electronic equipment can obtain the upgrade dotting data in the merge process; the upgrade dotting data comprises newly added dotting data. Meanwhile, for upgrading the dotting data, such as newly added dotting data, no file format configuration requirement exists; and the upgrading dotting data can be obtained without analyzing the formatted file subsequently. By means of the scheme, the system upgrading information can be obtained more efficiently and conveniently, and the system upgrading information is expanded.

Description

[0001] This case is a divisional application. The application number of the original application is 202310996701.4, and the application date of the original application is August 9, 2023. The entire content of the original application is incorporated into this application by reference. Technical Field

[0002] The embodiments of the present application relate to the field of computer technology, and in particular to a method for obtaining system upgrade information, an electronic device, and a storage medium. Background Art

[0003] Before the electronic device leaves the factory, the supplier of the electronic device will burn the operating system into the electronic device, thereby installing the operating system before the electronic device leaves the factory. Thereafter, the supplier of the electronic device may need to upgrade the operating system in the electronic device in order to improve the user experience.

[0004] Usually, during the operating system upgrade process, the electronic device will obtain some information related to the operating system upgrade (hereinafter referred to as system upgrade information). After obtaining the system upgrade information, the electronic device can send the system upgrade information to the server of the electronic device supplier, so that the electronic device supplier can optimize the system upgrade process of the electronic device based on the system upgrade information; or, the system upgrade information is displayed to the user, so that the user can perceive the operating system upgrade process of the electronic device and perform some operations.

[0005] Currently, during the operating system upgrade process, the electronic device will record the system upgrade information in a file format. Recording the system upgrade information in a file format will have some file format configuration requirements; and the file format needs to be parsed in subsequent use, which is relatively complicated and cumbersome. Summary of the invention

[0006] The embodiments of the present application provide a method for obtaining system upgrade information, an electronic device, and a storage medium, which can obtain system upgrade information more efficiently, conveniently, and directly.

[0007] To achieve the above objectives, the embodiments of the present application adopt the following technical solutions:

[0008] In a first aspect, a method for obtaining system upgrade information is provided, which can be applied to an electronic device having an operating system. The electronic device can be, for example, a mobile phone, a personal computer, a tablet computer, or the like having an operating system. The method comprises:

[0009] The electronic device runs the first operating system. Next, the electronic device runs the upgrade installation package of the second operating system. After that, the electronic device is turned off; then, the electronic device is turned on. Next, the electronic device runs the second operating system. Then, at a first time point, the electronic device performs a first merge operation on the disk. Next, at a second time point, the electronic device successfully performs the first merge operation; the second time point is later than the first time point. Then, at a third time point, the electronic device starts the online upgrade client OUC; the third time point is later than the first time point. Next, the electronic device runs the upgrade installation package of the third operating system. After that, the electronic device is turned off; then, the electronic device is turned on. Next, the electronic device runs the third operating system. Then, at a fourth time point, the electronic device performs a second merge operation. Then, at a fifth time point, the electronic device completes the second merge operation, and the second merge operation fails; the fifth time point is later than the fourth time point; at a sixth time point, the OUC is started and completed, and the sixth time point is later than the fourth time point. Next, at a seventh time point, the electronic device performs a third merge operation; the seventh time point is later than the sixth time point. Among them, the upgrade dotting data can be generated by the electronic device based on the dotting bit during the execution of the merge operation. Furthermore, the above-mentioned merge operation (such as the first merge operation, the second merge operation or the third merge operation) may include: writing the upgrade file saved in the virtual dynamic partition (in the user data partition) of the electronic device to the dynamic partition of the electronic device.

[0010] In the method described in the first aspect, OUC is started only after the second merge operation is executed. Considering that the OUC may not be started when the electronic device executes the second merge operation, it is difficult for OUC to obtain complete system upgrade information during the second merge operation. Based on this, after the OUC is started, if the second merge operation fails, the electronic device triggers the merge operation to be executed again, that is, the third merge operation is executed. In this way, after the OUC is started, the electronic device can execute the complete merge operation process. Then, OUC can directly obtain the complete system upgrade information (such as upgrade dot data) during the merge execution process, without parsing the file format and then obtaining the system upgrade information from the file. It can be seen that this method can obtain system upgrade information conveniently, efficiently and directly.

[0011] Compared to some solutions, in which the newly added system upgrade information is obtained by using a file (e.g., a system upgrade record file) as a medium, the newly added system upgrade information needs to be formatted to meet the configuration requirements of the file format. Also, when the newly added system upgrade information is subsequently used, the newly added system upgrade information needs to be parsed from the file format. In the first aspect, there is no need to write the newly added system upgrade information into the system upgrade record file, and there is no need to parse the file subsequently, and the electronic device can directly obtain the newly added system upgrade information.

[0012] It can be seen that in the first aspect, after the electronic device fails to perform the second merge operation, the merge operation is performed again. The OUC can obtain the newly added system upgrade information during the merge process. At the same time, there is no file format configuration requirement for the newly added system upgrade information; and there is no need to parse the format file in the subsequent process to obtain the newly added system upgrade information. Using this solution, the system upgrade information can be expanded more efficiently and conveniently.

[0013] In a possible design of the first aspect, the method further includes: during execution of the third merge operation, the OUC obtains the upgrade management data from the cache.

[0014] In this design, the OUC in the electronic device obtains the upgrade dotting data from the cache. If it is necessary to add a new dotting position during the merge process, so that when the merge process runs to the newly added dotting position, the newly added dotting data is generated, and the OUC can directly obtain the newly added upgrade dotting data from the cache. In other words, the OUC obtains the upgrade dotting data through the cache as a medium. Compared with some schemes, the newly added dotting data is passed to the OUC through a file (such as a system upgrade record file) as a medium, and the newly added dotting data needs to be formatted to meet the configuration requirements of the file format; and, when the upgraded dotting data is used subsequently, the upgraded dotting data needs to be parsed from the file format. In this design, by using the cache as a medium, there is no need to format the upgrade dotting data, nor is there a need to meet the configuration requirements of the file format; and, what the OUC obtains from the cache is relatively original data; there is no need to format the newly added dotting data, and the newly added dotting data can be passed to the OUC. At the same time, when the upgrade dotting data is used later, there is no need to parse the upgrade dotting data from the file format, and the upgrade dotting data obtained by OUC from the cache can be used directly. At the same time, it is taken into account that OUC may be started during the merge process; and, during the merge process, the upgrade dotting data generated later will overwrite the upgrade dotting data generated earlier in the cache; that is, the upgrade dotting data in the cache will change; it can be seen that when OUC is started during the merge process, OUC may not be able to obtain complete dotting data. Therefore, after OUC is started, executing the second merge operation can enable OUC to obtain the upgrade dotting data in the complete merge process; then OUC can obtain complete upgrade dotting data.

[0015] It can be seen that in this design, the OUC of the electronic device can easily increase the dot position by obtaining the upgrade dot data from the cache, and can easily expand the upgrade dot data. In addition, since the upgrade dot data obtained by the OUC from the cache is relatively original upgrade dot data, there is no file format requirement, and it is not necessary to parse the format file to obtain the upgrade dot data, which will be more convenient for the subsequent use of the upgrade dot data.

[0016] In a possible design of the first aspect, the OUC obtains the upgrade management data from the cache, which may include: the OUC monitors the target storage area in the cache, and if the data in the target storage area changes, the OCU obtains the upgrade management data from the target storage area; the target storage area is the storage area where the upgrade management data is written during the electronic device's execution of a merge operation.

[0017] In a possible design of the first aspect, the method further includes: if the third merge operation is successful, the upgrade engine in the electronic device generates an upgrade result file (e.g., an upgrade success file), and the OUC obtains the upgrade result file (e.g., an upgrade success file); the upgrade result file (e.g., an upgrade success file) is used to indicate that the upgrade is successful, and does not include upgrade dotting data. In this design, since the upgrade result file does not include upgrade dotting data, that is, the upgrade result and the upgrade dotting data are separated and will not be in one file. This will make the system upgrade information in the upgrade result file relatively concise and convenient to use in the future. When the electronic device only needs the upgrade result, the upgrade result can be directly obtained by searching the upgrade result file. Compared with some schemes, in the system upgrade record file generated by the mobile phone, the system upgrade record file contains both upgrade result information and upgrade dotting data, and the mobile phone needs to parse the upgrade record file, and filter out the upgrade dotting data from the parsed system upgrade record file to extract the upgrade result. In this scheme, it is not necessary to parse the upgrade record file containing the upgrade result information and the upgrade dotting data, and only the upgrade result file needs to be parsed to directly obtain the upgrade result in the upgrade result file. That is to say, the process of the mobile phone obtaining the upgrade result will not be disturbed by the upgrade dot data. It can be seen that in the method provided in the embodiment of the present application, by separating the upgrade result and the upgrade dot data, the electronic device can directly, accurately and efficiently obtain the system upgrade result, which is more convenient for the use of the system upgrade information.

[0018] In a possible design of the first aspect, the success of the above-mentioned first merge operation includes: if the first merge operation is successful, the upgrade engine in the electronic device generates an upgrade result file, the OUC obtains the upgrade result file, the upgrade result file is used to indicate that the upgrade is successful, and the upgrade result file does not include upgrade dot data.

[0019] In a possible design of the first aspect, the method further includes: if the second merge operation is successful, the upgrade engine in the electronic device generates an upgrade result file, the OUC obtains the upgrade result file, and the upgrade result file is used to indicate that the upgrade is successful. And, the electronic device performs a third merge operation, which may include: if the OUC does not obtain the upgrade result file and the second merge operation fails, the OUC instructs the upgrade engine in the electronic device to perform the third merge operation.

[0020] In a possible design of the first aspect, the electronic device performs a first merge operation, including: if the electronic device successfully loads the second operating system in the first static partition, the electronic device performs the first merge operation. The method also includes: if the electronic device fails to load the second operating system in the first static partition, the first operating system in the second static partition is loaded. The upgrade engine in the electronic device generates an upgrade result file (such as a system rollback file), and the OCU obtains the upgrade result file (such as a system rollback file), and the upgrade result file (system rollback file) is used to indicate that the operating system is rolled back, and the upgrade result file does not include upgrade dot data.

[0021] In this design, if the electronic device has a system rollback, the electronic device will generate an upgrade result file if it runs with the first static partition. In this way, it can be obtained later through the upgrade result file that the system upgrade on the electronic device has failed and a system rollback has occurred.

[0022] In another possible design of the first aspect, the electronic device generates an upgrade result file, which may include: the electronic device obtains the version number of the operating system running on the electronic device, and if the version number is the version number of the first operating system, generates an upgrade result file for indicating that the operating system is rolled back.

[0023] In another possible design of the first aspect, the method further includes: when the fifth time point is later than the fourth time point, after the electronic device starts the OUC and completes the startup, if the electronic device determines that the second merge operation is being executed, the OUC waits for the second merge operation to be completed (failed or succeeded). The electronic device can determine that the first merge operation is being executed by upgrading the dotting data, the merge data, or a preset interface.

[0024] In this design, it is determined whether a merge operation is being performed by dot data, merge data, or a preset interface, etc. It is convenient to determine whether the electronic device is performing a merge operation.

[0025] In another possible design of the first aspect, the electronic device may also send the acquired upgrade result file or upgrade management data to a server (e.g., a server of the electronic device supplier). In this way, the merge process of the electronic device may be repaired based on the upgrade management data. Alternatively, the system upgrade result of the electronic device may be known based on the upgrade result file.

[0026] On the second aspect, another method for obtaining system upgrade information is provided, which can be applied to an electronic device with an operating system. Among them, the electronic device can be, for example, a mobile phone, a personal computer, a tablet computer, and the like electronic devices with an operating system. The method includes: the electronic device runs a fourth operating system. Next, the electronic device runs an upgrade installation package of the fifth operating system. After that, the electronic device is turned off. Next, the electronic device is turned on. Then, the electronic device runs the fifth operating system. Then, at an eighth time point, the electronic device starts the online upgrade client OUC. Next, in response to the completion of the OUC startup, at a ninth time point, the electronic device performs a merge operation on the disk; the ninth time point is later than the eighth time point. In the process of the electronic device performing the merge operation, the OUC obtains the upgrade dot data from the cache.

[0027] In the method described in the second aspect, it is considered that the OUC may be started during the merge process; and in the merge process, the upgrade dotting data generated later will overwrite the upgrade dotting data generated earlier in the cache; that is, the upgrade dotting data in the cache will change; it can be seen that when the OUC is started during the merge process, the OUC may not obtain the complete dotting data. Therefore, after the OUC is started, the merge operation is performed, so that the OUC can obtain the upgrade dotting data in the complete merge process; then the OUC can obtain the complete upgrade dotting data.

[0028] In a third aspect, another method for obtaining system upgrade information is provided, which can be applied to an electronic device with an operating system, and the method includes: the electronic device runs a first operating system. Next, the electronic device runs an upgrade installation package of a second operating system. After that, the electronic device is turned off and the electronic device is turned on. Then, the electronic device runs the above-mentioned second operating system. Then, the electronic device performs a fourth merge operation; next, the electronic device starts an online upgrade client OUC. After that, if the electronic device fails to perform the fourth merge operation, a fifth merge operation is performed. Then, in the process of performing the fifth merge operation, the OUC of the electronic device obtains the upgrade dot data from the cache.

[0029] In a possible design of the third aspect, the method further includes: if the fifth merge operation is successful, the upgrade engine of the electronic device generates an upgrade result file, the OUC of the electronic device obtains the upgrade result file (e.g., upgrade success file), the upgrade result file (upgrade success file) is used to indicate that the fifth operating system of the electronic device is successfully upgraded, and the upgrade result file does not include upgrade dotting data. Alternatively, if the fifth merge operation fails, the electronic device saves the upgrade dotting data obtained by the OUC from the cache during the execution of the fifth merge operation. Alternatively, if the fifth merge operation is successful, the upgrade engine of the electronic device generates an upgrade result file, the OUC of the electronic device obtains the upgrade result file, the upgrade result file is used to indicate that the upgrade is successful, and the upgrade result file does not include upgrade dotting data.

[0030] In another possible design of the third aspect, the OUC of the electronic device obtains the upgrade RBI data from the cache, which may include: the OUC of the electronic device monitors the target storage area in the cache, and if the target storage area has data changes (such as data modification, data addition, etc.), the OCU of the electronic device obtains the upgrade RBI data from the target storage area. The target storage area is a storage area in the cache and the electronic device writes the upgrade RBI data during the merge operation.

[0031] In another possible design of the third aspect, after the electronic device starts the online upgrade client OUC and completes the startup, if the electronic device determines that the fourth merge operation is being executed, the electronic device waits for the fourth merge operation to be completed. Afterwards, if the fifth merge operation fails, the electronic device executes the fifth merge operation. The electronic device can determine that the fourth merge operation is being executed through the upgrade dot data, merge data, or a preset interface.

[0032] In another possible design of the third aspect, the electronic device may also send the acquired upgrade result file or upgrade management data to a server (e.g., a server of the electronic device supplier). In this way, the merge process of the electronic device may be repaired based on the upgrade management data. Alternatively, the system upgrade result of the electronic device may be known based on the upgrade result file.

[0033] In a fourth aspect, an electronic device is provided, the electronic device comprising a processor and a memory, the memory comprising a first static partition, a second static partition, a dynamic partition and a user data partition, the processor being used to execute computer instructions stored in the memory, so that the electronic device executes the method provided by the above-mentioned first aspect and any possible design of the first aspect; or, the electronic device executes the method provided by the above-mentioned second aspect and any possible design of the second aspect; or, the electronic device executes the method provided by the above-mentioned third aspect and any possible design of the third aspect.

[0034] In a fifth aspect, a computer-readable storage medium is provided, which stores instructions. When the computer instructions are executed on an electronic device, the electronic device executes the method provided by the first aspect and any possible design of the first aspect; or, the electronic device executes the method provided by the second aspect and any possible design of the second aspect; or, the electronic device executes the method provided by the third aspect and any possible design of the third aspect.

[0035] In a sixth aspect, a computer program product comprising instructions is provided. When the computer program product is run on an electronic device, the electronic device executes the method provided by the first aspect and any possible design of the first aspect; or, the electronic device executes the method provided by the second aspect and any possible design of the second aspect; or, the electronic device executes the method provided by the third aspect and any possible design of the third aspect.

[0036] Among them, the technical effects brought about by any design method in the third to fourth aspects can refer to the technical effects brought about by different design methods in the first and second aspects, and will not be repeated here. BRIEF DESCRIPTION OF THE DRAWINGS

[0037] Figure 1 A schematic diagram of a usage scenario provided for an embodiment of the present application;

[0038] Figure 2 A schematic diagram of the structure of an electronic device provided in an embodiment of the present application;

[0039] Figure 3 A schematic diagram of the software structure of an electronic device provided in an embodiment of the present application;

[0040] Figure 4 A schematic diagram of a data storage structure provided in an embodiment of the present application;

[0041] Figure 5 A schematic diagram of a process flow of a method for obtaining system upgrade information provided in an embodiment of the present application;

[0042] Figure 6 A schematic diagram of a process for upgrading an operating system provided in an embodiment of the present application;

[0043] Figure 7 A schematic diagram of another process of upgrading the operating system provided in an embodiment of the present application;

[0044] Figure 8 A schematic diagram of another process of upgrading the operating system provided in an embodiment of the present application;

[0045] Fig. 9 A schematic diagram of another process of upgrading the operating system provided in an embodiment of the present application;

[0046] Fig.10 A schematic diagram of a process flow of a disk placement operation is provided for an embodiment of the present application;

[0047] Fig.11 A schematic diagram of another process of the method for obtaining system upgrade information provided in an embodiment of the present application;

[0048] Fig.12 A schematic diagram of another process of the method for obtaining system upgrade information provided in an embodiment of the present application;

[0049] Fig.13 A schematic diagram of another structure of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0050] The technical solutions in the embodiments of the present application will be described below in conjunction with the drawings in the embodiments of the present application. Among them, in the description of the present application, unless otherwise specified, " / " indicates that the objects associated before and after are in an "or" relationship, for example, A / B can represent A or B; "and / or" in the present application is only a kind of association relationship describing the associated objects, indicating that there can be three relationships, for example, A and / or B can represent: A exists alone, A and B exist at the same time, and B exists alone, where A and B can be singular or plural. And, in the description of the embodiments of the present application, unless otherwise specified, "multiple" refers to two or more than two. "At least one of the following" or its similar expressions refers to any combination of these items, including any combination of single items or plural items. For example, at least one of a, b, or c can represent: a, b, c, ab, ac, bc, or abc, where a, b, c can be single or multiple. In addition, in order to clearly describe the technical solutions of the embodiments of the present application, in the embodiments of the present application, words such as "first" and "second" are used to distinguish the same items or similar items with substantially the same functions and effects. Those skilled in the art can understand that words such as "first" and "second" do not limit the quantity and execution order, and words such as "first" and "second" do not necessarily limit the difference.

[0051] Meanwhile, in the embodiments of the present application, words such as "exemplary" or "for example" are used to indicate examples, illustrations or descriptions. Any embodiment or design described as "exemplary" or "for example" in the embodiments of the present application should not be interpreted as being more preferred or more advantageous than other embodiments or designs. Specifically, the use of words such as "exemplary" or "for example" is intended to present related concepts in a concrete manner for ease of understanding.

[0052] In electronic devices, the operating system is the most basic and most important basic system software. Electronic devices can only be used by users when the operating system is installed. For example, if the electronic device is a mobile phone, the mobile phone needs to install a mobile phone operating system, such as the iPhone Operating System (IOS). TM ), Android TM ) system, etc. before it can be used by users.

[0053] Before the electronic device leaves the factory, the supplier of the electronic device will burn the operating system into the electronic device, thereby installing the operating system before the electronic device leaves the factory. Thereafter, the supplier of the electronic device may need to upgrade the operating system in the electronic device in order to improve the user experience.

[0054] Typically, during the operating system upgrade process, the electronic device will obtain some information related to the operating system upgrade (hereinafter referred to as system upgrade information). The upgrade information may include: upgrade dot data or upgrade results. After obtaining the system upgrade information, the electronic device may send the system upgrade information to the server of the electronic device supplier, so that the electronic device supplier can optimize the system upgrade package of the electronic device based on the system upgrade information; or, display the system upgrade information to the user, so that the user can perceive the operating system upgrade process or upgrade results of the electronic device; or, if the operating system upgrade of the electronic device fails, the electronic device can diagnose and repair the operating system upgrade process of the electronic device based on the system upgrade information.

[0055] In some solutions, during the operating system upgrade process, the electronic device can record the system upgrade information in a file format; for example, the system upgrade information is recorded in a system upgrade record file. It is understandable that recording the upgrade information in a file format will have some file format configuration requirements, which is relatively complicated. At the same time, in subsequent use, the file format needs to be parsed, such as parsing the system upgrade record file, and the system upgrade information in the system upgrade record file can be obtained after parsing.

[0056] If the system upgrade information needs to be expanded, such as adding (reducing) system upgrade information; or adding upgrade dot data or reducing upgrade dot data. The electronic device needs to configure additional file formats for these newly added system upgrade information and the corresponding parsing method of the file format. In other words, the electronic device needs to perform some processing on these newly added system upgrade information to meet the configuration requirements of the file format. In addition, the system upgrade information is recorded in a file format. When the system upgrade information is used subsequently, the file format needs to be parsed before the content recorded in the file format can be read, which is more complicated.

[0057] For example, the system upgrade record file is a key-value (kv) file format (hereinafter referred to as the kv format). When the electronic device records the system upgrade information in the kv format, there will be configuration requirements for the kv format; therefore, the kv format needs to be parsed in subsequent use to obtain the content recorded in the system upgrade record file. If an electronic device wants to add upgrade RBI data, the electronic device needs to declare a new key first, and then write the newly added upgrade RBI data to the value corresponding to the new key. In addition, after the server of the electronic device supplier receives the system upgrade record file, it also needs to configure the corresponding parsing method for the new key in the system upgrade record file to obtain the newly added upgrade RBI data. It can be seen that this method of recording system upgrade information in a file format is not conducive to expanding the system upgrade information.

[0058] Furthermore, the upgrade dotting data and the upgrade results will be written into the above-mentioned system upgrade record file, which will cause the upgrade dotting data and the upgrade results to be mixed together. If the electronic device only needs to obtain the upgrade results, but does not need to obtain the upgrade dotting data; then since the system upgrade record file includes both the upgrade dotting data and the upgrade results, the electronic device needs to parse the file format of the upgrade record file first; then filter out the upgrade dotting data from the parsed system upgrade record file, and extract the upgrade results. Furthermore, since the amount of upgrade dotting data may be much larger than the amount of upgrade results, that is to say, the electronic device needs to filter out the upgrade results from the upgrade dotting data with a relatively large amount of data. It can be seen that writing the upgrade dotting data and the upgrade results in the system upgrade record file will cause the process of the electronic device obtaining the upgrade results to be more cumbersome and time-consuming.

[0059] It can be seen that in the above solution, the method of obtaining the system upgrade information recorded in a file format is not conducive to expanding the system upgrade information, nor is it conducive to accurately obtaining the system upgrade information for subsequent use.

[0060] In view of this, an embodiment of the present application provides a method for obtaining system upgrade information, in which the electronic device can facilitate the subsequent use of the system upgrade information by separating the upgrade results and the upgrade management data; and in this method, the electronic device obtains the upgrade management data by using the cache as the medium, that is, there is no file format parsing requirement for the upgrade management data, and the upgrade management data can be easily expanded.

[0061] The system upgrade information acquisition method provided in the embodiment of the present application can be applied to the scenario of upgrading the operating system of the electronic device 100.

[0062] For example, see Figure 1, the electronic device 100 can receive the system upgrade package (hereinafter referred to as the upgrade package) sent to the electronic device 100 by the supplier of the electronic device 100 through the over-the-Air Technology (OTA) technology. Next, the electronic device 100 upgrades the operating system on the electronic device 100 based on the upgrade package. For example, the electronic device 100 downloads the upgrade package of the new version through the OTA technology; then, the electronic device 100 upgrades the old version of the operating system to the new version of the operating system. During the operating system upgrade process, the electronic device 100 can obtain the dotting data during the operating system upgrade process according to the pre-configured breakpoints. And the electronic device can also obtain the upgrade result of the electronic device 100 after the system upgrade is completed. That is to say, the electronic device 100 can obtain the system upgrade information during the operating system upgrade process. Afterwards, the electronic device 100 can send the system upgrade information to the server (such as the server of the supplier of the electronic device 100), so that the supplier of the electronic device 100 can optimize the upgrade package released by it based on the system upgrade information; or display the system upgrade information to the user, so that the user can perceive the upgrade process of the electronic device 100 and make corresponding operations (such as restarting the electronic device 100, etc.).

[0063] It should be pointed out that in Figure 1 In the scenario shown, the electronic device 100 can also obtain the upgrade package released by the supplier of the electronic device through a universal serial bus (USB) interface or a mobile storage device (such as a USB flash disk). The embodiment of the present application does not impose any restrictions on the manner in which the electronic device 100 obtains the upgrade package.

[0064] It is understandable that the above-mentioned electronic devices can be mobile phones, tablet computers, wearable devices, smart screens, augmented reality (AR) / virtual reality (VR) devices, laptops, ultra-mobile personal computers (UMPC), netbooks, personal digital assistants (PDA) and other electronic devices with operating systems; they can also be smart watches, smart bracelets and other IoT devices with operating systems, and they can also be vehicle-mounted devices with operating systems such as vehicle-mounted computers and vehicle-mounted controllers. The embodiments of the present application do not impose any restrictions on the specific types of electronic devices. Among them, the above-mentioned operating system includes but is not limited to Or other operating systems.

[0065] Figure 2 A schematic diagram of the hardware structure of the electronic device 100 is shown.

[0066] like Figure 2 As shown, the electronic device 100 may include a processor 110, an external memory interface 120, an internal memory 121, a universal serial bus (USB) interface 130, a power management module 141, an antenna, a wireless communication module 150, a display screen 140, and the like.

[0067] It is to be understood that the structure illustrated in the embodiment of the present invention does not constitute a specific limitation on the electronic device 100. In other embodiments of the present application, the electronic device 100 may include more or fewer components than shown in the figure, or combine some components, or separate 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.

[0068] The processor 110 may include one or more processing units, for example, the processor 110 may include an application processor (AP), a modem processor, a graphics processor (GPU), an image signal processor (ISP), a controller, a memory, a video codec, a digital signal processor (DSP), a baseband processor, and / or a neural-network processing unit (NPU), etc. Different processing units may be independent devices or integrated into one or more processors.

[0069] The controller may be the nerve center and command center of the electronic device 100. The controller may generate an operation control signal according to the instruction operation code and the timing signal to complete the control of fetching and executing instructions.

[0070] The processor 110 may also be provided with a memory for storing instructions and data. In some embodiments, the memory in the processor 110 is a cache memory. The memory may store instructions or data that the processor 110 has just used or cyclically used. If the processor 110 needs to use the instruction or data again, it may be directly called from the memory. This avoids repeated access, reduces the waiting time of the processor 110, and thus improves the efficiency of the system.

[0071] The wireless communication module 150 can provide wireless communication solutions for application in the electronic device 100, 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 technology (NFC), infrared technology (IR), etc.

[0072] The display screen 140 is used to display images, videos, etc. The display screen 140 includes a display panel. The display panel can be a liquid crystal display (LCD), an organic light-emitting diode (OLED), an active-matrix organic light-emitting diode or an active-matrix organic light-emitting diode (AMOLED), a flexible light-emitting diode (FLED), Miniled, MicroLed, Micro-oLed, a quantum dot light-emitting diode (QLED), etc.

[0073] The external memory interface 120 can be used to connect an external memory card, such as a Micro SD card, to expand the storage capacity of the electronic device 100. The external memory card communicates with the processor 110 through the external memory interface 120 to implement a data storage function, such as storing music, video and other files in the external memory card.

[0074] The internal memory 121 can be used to store computer executable program codes, which include instructions. The processor 110 executes various functional applications and data processing of the electronic device 100 by running the instructions stored in the internal memory 121. For example, in an embodiment of the present application, the processor 110 can execute instructions stored in the internal memory 121, and the internal memory 121 may include a program storage area and a data storage area. Among them, the program storage area may store an operating system, an application required for at least one function (such as a sound playback function, an image playback function, etc.), etc. In addition, the internal memory 121 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.

[0075] The USB interface 130 is an interface that complies with the USB standard specification, and specifically can be a Mini USB interface, a Micro USB interface, a USB Type C interface, etc. The USB interface 130 can be used to connect a charger to provide power to the electronic device 100, and can also be used to transmit data between the electronic device 100 and a peripheral device. It can also be used to connect headphones to play audio through the headphones. The interface can also be used to connect other electronic devices, such as AR devices, etc.

[0076] Exemplarily, the electronic device 100 can obtain the upgrade package through the wireless communication module 150 and the antenna, etc., and write the upgrade package into the internal memory 121 or the external memory connected to the external memory interface 120. Another exemplary embodiment, the electronic device 100 can obtain the upgrade package through the USB interface 130, and write the upgrade package into the internal memory 121 or the external memory connected to the external memory interface 120.

[0077] Exemplarily, the electronic device 100 can execute the operating system upgrade process based on the acquired upgrade package through the processor 110, and generate system upgrade information. Next, the electronic device 100 can send the system upgrade information to the server of the supplier of the electronic device 100 through the wireless communication module 150 and the antenna, or through the USB interface 130. Alternatively, the electronic device can also display the system upgrade information to the user through the display screen 140.

[0078] Figure 3 The schematic diagram of the software structure (architecture) of the electronic device 100 of the embodiment of the present application is shown. The layered architecture can divide the software into several (architecture) layers, and each layer has a clear role and division of labor. The layers communicate with each other through software interfaces. In some embodiments, Android TMThe system is divided into four layers, from top to bottom: application layer (can be referred to as application (APP) layer, application framework layer (framework, FWK)), native layer and kernel layer. For example, Figure 3 As shown, the electronic device 100 may include an application layer, a framework layer, a local layer and a kernel layer.

[0079] Understandably, Figure 3 The software structure shown does not constitute a specific limitation on the electronic device 100. In other embodiments of the present application, the electronic device 100 may include more or fewer architecture layers than shown in the figure, or combine some architecture layers, or split some architecture layers, etc. TM The system may also have other hierarchical division methods, for example, divided into: application layer (referred to as application layer), application framework layer, system library, kernel layer, etc. Also, different hierarchical division methods may be used for different operating systems, and technicians may divide the operating system into different hierarchical levels according to actual usage.

[0080] The application layer can include a series of application packages. Figure 3 As shown, the application package may include applications such as camera, gallery, calendar, call, map, navigation, WLAN, Bluetooth, music, video, etc.

[0081] The application layer may also include system upgrade applications, such as an online update client (OUC).

[0082] Exemplarily, the electronic device can obtain the upgrade package through OUC. Subsequently, the electronic device can also display the upgrade result to the user through OUC.

[0083] The application framework layer provides an application programming interface (API) and a programming framework for the applications in the application layer. The application framework layer includes some predefined functions. For example, the application layer may include system services and media services.

[0084] The system server is a process that provides many subsystem services. Each subsystem service runs in the form of a thread, waiting for requests from applications, processing the requests, and returning the results to the applications. The above subsystem services include, for example, window manager service (WMS), notification manager service (NMS), activity manager service (AMS), input manager service (IMS), etc.

[0085] The native layer, also known as the system runtime layer, can include multiple functional modules. For example, the surface manager, media libraries, 3D graphics processing libraries (such as OpenGL ES), 2D graphics engines (such as SGL) and Android TM Runtime (Android TM runtime, ART).

[0086] The surface manager is used to manage the display subsystem and provide fusion of 2D and 3D layers for multiple applications. The media library supports playback and recording of multiple common audio and video formats, as well as static image files. The media library can support multiple audio and video encoding formats, such as: MPEG4, H.264, MP3, AAC, AMR, JPG, PNG, etc. The 3D graphics processing library is used to implement 3D graphics drawing, image rendering, synthesis, and layer processing. The 2D graphics engine is a drawing engine for 2D drawing.

[0087] Android TM Runtime includes core libraries and virtual machines. Android TM Runtime is responsible for the scheduling and management of the Android system.

[0088] The core library consists of two parts: one part is the function that needs to be called by the Java language, and the other part is the Android core library.

[0089] The application layer and the application framework layer run in a virtual machine. The virtual machine executes the Java files of the application layer and the application framework layer as binary files. The virtual machine is used to perform functions such as object life cycle management, stack management, thread management, security and exception management, and garbage collection.

[0090] The local layer may also include an update engine (update_engine). For example, the electronic device may use the update engine to perform a virtual A / B installation or a disk write process during a system upgrade.

[0091] The kernel driver layer, also called the kernel layer, is the layer between hardware and software. The kernel layer includes at least display driver, camera driver, audio driver, and sensor driver.

[0092] Exemplarily, the electronic device can start the OUC or upgrade the engine through system services.

[0093] Android TM Take the system as an example, Figure 4 The figure shows a schematic diagram of a data storage structure provided according to an embodiment of the present application. Figure 4 As shown, the Android system data storage area includes a basic partition (common), a static partition (A), a static partition (B), a dynamic partition (super), and a user data partition (userdata).

[0094] The user data partition (userdata) is used to store the user's personal data, such as APPs installed by the user, pictures, documents and videos saved by the user. The data stored in the basic part 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. For example, the static partition (A) includes: boot_a, vendor_boot_a, dtbo_a, vbmeta_a; the static partition (B) includes: boot_b, vendor_boot_b, dtbo_b, vbmeta_b. The dynamic partition (Super) contains multiple sub-partitions. For example, the S1 partition that records A1 data, the S2 partition that records B1 data, the S3 partition that records C1 data, the S4 partition that records D1 data, the S5 partition that records E1 data, and the S6 partition that records F1 data. It can be understood that when the electronic device upgrades the operating system, the files (data) in the static partition and the dynamic partition need to be upgraded, and the files in the basic partition and the user data partition do not need to be upgraded.

[0095] When an electronic device starts, it will start from a static partition. For example, 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, the electronic device starts from the static partition (B): the basic partition (common), static partition (B) and dynamic partition (super) are loaded in sequence.

[0096] Take the universal flash storage (UFS) in the master boot record (MBR) format as an example. In the MBR of UFS (master boot sector, the first sector of UFS, i.e., the 0 cylinder 0 head 1 sector of the C / H / S address), a description of the device boot sequence (for example, the mobile phone boot sequence) is saved. The device boot sequence can be used to indicate booting from a static partition (A) (the boot sequence mark is A) or booting from a static partition (B) (the boot sequence mark is B). After the device is started, the device boot sequence is first read from the MBR of UFS. And each data partition is started (loaded) in sequence according to the read device boot sequence. MBR is usually recorded in the base partition (common). Of course, in different platforms, MBR can also be recorded in different locations, and the embodiments of the present application do not specifically limit this.

[0097] Understandably, Figure 4 The division method of the data partitions shown does not constitute a specific limitation on the data storage partitions of the electronic device 100. In other embodiments of the present application, the data storage partitions of the electronic device 100 may also be divided in different forms. The electronic device 100 may include more or fewer data partitions than shown, or combine certain data partitions, or split certain data partitions, etc. The division method of the data storage partitions of the electronic device 100 may be designed according to the actual usage, and the embodiments of the present application do not impose any limitation on this.

[0098] Next, we will Figure 1 In the usage scenario shown, the electronic device 100 is a mobile phone as an example to introduce the technical solution provided in the embodiment of the present application.

[0099] Assume that the phone is running an old version of the operating system (for example, version 1.1) and needs to be upgraded to a new version of the operating system (for example, version 1.2). The phone can Figure 5 The process shown implements the upgrade of the operating system and obtains system upgrade information.

[0100] For example, see Figure 5 The system upgrade information acquisition method provided in the embodiment of the present application may include steps S500-S512.

[0101] S500. The mobile phone loads the basic partition (common) and the static partition (A), and starts from the static partition (A), thereby starting to run with version 1.1.

[0102] For example, see Figure 6, the phone can load the basic partition (common), static partition (A), dynamic partition and user data partition in sequence to start from the static partition (A). In other words, the phone starts running with the old version of the operating system, that is, version 1.1 of the operating system.

[0103] It is understandable that, since the mobile phone has not yet obtained the upgrade package, the static partition (A), static partition (B) and dynamic partition of the mobile phone should store the old version of the operating system, such as the version 1.1 operating system. Since the static partition (A) and static partition (B) of the mobile phone at this time are both old versions of the operating system, that is to say, the mobile phone can also start the version 1.1 operating system with the static partition (B). Below, for the sake of ease of description, the example of a mobile phone starting and running the version 1.1 operating system with the static partition (A) will be used for introduction.

[0104] S501.OUC obtains the upgrade package.

[0105] In some embodiments, the OUC may periodically initiate a package search request to a package search server, where the package search request includes the version number of the operating system currently running on the mobile phone (for example, version 1.1); the package search server searches whether there is an upgrade package for a new version of the operating system (for example, version 1.2) based on the operating system version number in the package search request; when there is an upgrade package for a new version of the operating system, the package search server feeds back the download address of the upgrade package (for example, an operating system upgrade package from version 1.1 to version 1.2) to the device; the device downloads the upgrade package based on the download address of the upgrade package.

[0106] Among them, the upgrade package can be a full system upgrade package or a differential system upgrade package; the full upgrade package can be understood as a system upgrade package containing the full data of version 1.2. The differential system upgrade package can be understood as a system upgrade package containing the difference data between version 1.2 and version 1.1. Assume that the dynamic partition of version 1.2 includes: A2, B1, C1, D2, E1 and F1; the dynamic partition of version 1.1 includes: A1, B1, C1, D1, E1 and F1. Then the full system upgrade package may refer to a system upgrade package including A2, B1, C1, D2, E1 and F1. The differential system upgrade package may refer to a system upgrade package including A2 and D2. The type of upgrade package can be designed according to actual usage requirements, and the embodiments of the present application do not impose any restrictions on this.

[0107] In some embodiments, the OUC may also obtain the upgrade package through the USB interface of the mobile phone; and the OUC may also obtain the upgrade package installed on the storage medium (such as a USB flash drive) through the external memory interface, etc. The way in which the OUC obtains the upgrade package may be designed according to actual usage needs, and the embodiments of the present application do not impose any restrictions on this.

[0108] S502. The upgrade engine performs virtual A / B installation based on the upgrade package.

[0109] It is understandable that since the phone is running at this time, the phone cannot modify the files in use in the data partition. That is to say, if the phone is started from the static partition (A), the upgrade engine can write the static partition data containing version 1.2 in the upgrade package to the static partition (B). If the phone is started from the static partition (B), the upgrade engine can write the static partition data containing version 1.2 in the upgrade package to the static partition (A).

[0110] Furthermore, for the dynamic partition data of version 1.2 included in the upgrade package, the upgrade engine may create a virtual dynamic partition in the user data partition; and write the dynamic partition data of version 1.2 included in the upgrade package into the virtual dynamic partition.

[0111] Afterwards, the upgrade engine modifies the mobile phone startup sequence. It can be understood that the mobile phone startup sequence refers to the order in which the mobile phone starts (loads) the data partitions.

[0112] Exemplarily, OUC can instruct the upgrade engine (update_engine) to perform virtual A / B installation by calling the mutipayloads interface. After the virtual A / B installation is completed, update_engine calls back the virtual A / B installation result (e.g., virtual A / B installation is successful, or virtual A / B installation fails) to OUC through the mutipayloads interface.

[0113] In some embodiments, see Figure 7 , the above step S502 may include steps S5021-S5023.

[0114] S5021. The upgrade engine performs a data write operation on the static partition (B) according to the upgrade package to upgrade the static partition.

[0115] For example, see Figure 8 If the upgrade package from version 1.1 to version 1.2 contains the full data of the static partition of version 1.2, the upgrade engine will overwrite the data of the static partition of version 1.2 into the static partition (B), so that the data in the static partition (B) is upgraded to the static partition data of version 1.2.

[0116] It is understandable that if the mobile phone is running version 1.1 of the operating system in the static partition (B) at this time, the upgrade data of the static partition of version 1.2 contained in the upgrade package can also be written into the static partition (A). This embodiment of the present application does not impose any restrictions on this.

[0117] S5022. The upgrade engine creates a virtual dynamic partition in the user data partition (userdata) according to the upgrade package, and writes the upgrade data of the dynamic partition (super) into the virtual dynamic partition.

[0118] For example, if the upgrade package contains the full data of the dynamic partition (super) of version 1.2, the upgrade engine writes the full data of the dynamic partition (super) of version 1.2 in the user data partition, and creates a virtual dynamic partition of version 1.2 in the user data partition, which includes the full data of the dynamic partition of version 1.2.

[0119] In some embodiments, when the upgrade engine performs virtual A / B installation, if a differential upgrade method is used for the dynamic partition (super), during the upgrade process, the virtual dynamic partition of the user data partition (userdata) does not store all the files of the new version of the dynamic partition (super) after the upgrade, but the upgrade result of the data that needs to be upgraded in the old version of the dynamic partition (super) after the upgrade. That is, the virtual dynamic partition of the user data partition (userdata) stores the upgrade data of the dynamic partition (super).

[0120] In some embodiments, when the upgrade engine performs virtual A / B installation, the upgrade engine can also implement incremental upgrades of the dynamic partition (super) based on snapshot technology. Specifically, in the virtual dynamic partition of the user data partition (uerdata), a copy-on-write (COW) file is used to save the upgrade data of the dynamic partition (super). In this way, when the virtual dynamic partition is subsequently loaded, the mobile phone can load the COW file in the user data partition and the file in the dynamic partition through the snapshot to load the virtual dynamic partition.

[0121] For example, see again Figure 8 . Assume that compared with version 1.1, version 1.2 only updates data A1 in S1 of the dynamic partition (super) and data D1 in S4. For example, A1 is updated to A2, and D1 is updated to D2. In other words, in version 1.1, the data in S1 of the dynamic partition is A1, and the data in S4 of the dynamic partition is D1; ​​while in version 1.2, the data in S1 of the dynamic partition is A2, and the data in S4 of the dynamic partition is D2.

[0122] Based on this, when the upgrade engine creates a virtual dynamic partition in the user data partition, in order to save space in the user data partition, it can only create virtual dynamic partitions for dynamic partitions S1 and dynamic partitions S4 in the user data partition. And set the address of data A2 to S1-1 corresponding to address S1 of A1; set the address of data D2 to S4-1 corresponding to address S4 of D1. Afterwards, when using version 1.2 in the future, load A2, B1, C1, D2, E1, and F1 through snapshot to run the operating system of version 1.2.

[0123] S5023. The upgrade engine changes the mobile phone startup sequence from starting from the static partition (A) to starting from the static partition (B).

[0124] For example, the upgrade engine can rewrite the boot sequence identifier of the master boot record (MBR) from A to B. After the mobile phone is powered on, when the mobile phone reads the boot sequence identifier as A, the mobile phone starts from the static partition (A) and loads the static partition (A) during the boot process; when the mobile phone reads the boot sequence identifier as B, the mobile phone starts from the static partition (B) and loads the static partition (B) during the boot process.

[0125] In some embodiments, the above step S5023 may also include: an update engine (update engine) modifies a card slot (slot).

[0126] For example, see again Figure 8 In the basic partition or static partition, slot 0 (slot0) corresponding to static partition (A) and slot 1 (slot1) corresponding to static partition (B) can be included. Slot0 and slot1 are used to store the partition table of the super partition.

[0127] For example, in the MBR of UFS, in the device boot sequence description, configuring slot0 corresponds to booting from the static partition (A), and configuring slot1 corresponds to booting from the static partition (B). When the phone starts, depending on the static partition that is started, choose to obtain the partition information of the super partition from one of slot0 or slot1. Taking the current boot of the phone from the static partition (A) as an example, when loading the dynamic partition (super), the phone reads slot0 to obtain the sub-partition address of the dynamic partition (super) (for example, load the dynamic partition in the manner of loading S1, S2, S3, S4, S5, S6). When the phone is started by static partition B, when loading the super partition, the phone reads slot1 to obtain the sub-partition address of the dynamic partition (super). (For example, load the dynamic partition in the manner of loading S1-1, S2, S3, S4-1, S5, S6).

[0128] S503. The phone restarts.

[0129] In some embodiments, after the upgrade engine completes the virtual A / B installation in step S510 (such as after the mobile phone startup sequence is modified), the system server on the mobile phone can instruct the mobile phone to power off and exit the current operating system. Next, the mobile phone is powered on again.

[0130] In some embodiments, at step S520, the mobile phone does not need to be restarted immediately, and the user can choose the restart time by himself; in this way, the upgrade process of the operating system will not affect the normal operation of the user's mobile phone, thereby greatly improving the user experience. Exemplarily, the mobile phone can prompt the user through a pop-up window or a notification message that the virtual A / B installation on the mobile phone has been completed. Afterwards, the mobile phone responds to the user's restart operation on the mobile phone and executes the restart.

[0131] S504. The mobile phone sequentially loads the basic partition, the static partition (B), and the dynamic partition and the virtual dynamic partition in the user data partition, so that the mobile phone starts running with version 1.2. Then, the mobile phone executes S505a-S506a, or executes S505b-506b and subsequent steps.

[0132] In some embodiments, the basic partition and the static partition (B) can be loaded by a bootloader on the mobile phone. Next, the bootloader reads slot 1 corresponding to the static partition (B), and extracts the corresponding file from the COW file in the dynamic partition or virtual dynamic partition using snapshot based on slot 1 for loading.

[0133] Among them, loading a bootloader can be a code program solidified on the mobile phone processor, through which data partitions can be loaded, and functional modules in different software architecture layers of the mobile phone can be loaded in sequence; to realize the startup of the mobile phone, so that the mobile phone can enter the user interaction interface. For example, the bootloader can first load the functional modules in the kernel layer (such as display driver, audio driver, operating system kernel, etc.). After that, the kernel layer (such as the operating system kernel) loads the functional modules in the local layer (such as upgrade engine, display manager, etc.). Next, the kernel layer (such as the operating system kernel) loads the functional modules in the framework layer (such as system services, media services, etc.). After that, the kernel layer (such as the operating system kernel) loads the functional modules in the application layer (such as camera application, OUC application, etc.). It can be seen that after the mobile phone is restarted, the upgrade engine on the mobile phone may start earlier than OUC.

[0134] For example, see Fig. 9 , assuming that the slot is in the base partition of the phone. The bootloader reads the boot order identifier in the MBR. For example, it is read that the phone boots from the static partition (B). After that, the bootloader loads the base partition and reads slot1 from the loaded base partition. Next, the bootloader loads the static partition (B). Then, after the static partition (B) is loaded, the bootloader loads the COW file in the dynamic partition and the user data partition based on slot1 through the snapshot to load the virtual dynamic partition. After the virtual dynamic partition is loaded, the bootloader loads the user data partition.

[0135] For example, after the bootloader loads the data partition and loads and starts the functional modules in the software architecture layer, the mobile phone will enter the user interaction interface. At this time, the mobile phone startup flag is "startup success". For example, the value of boot_complete is 1.

[0136] S505a. If the mobile phone fails to start with the static partition (B), the bootloader is loaded to perform a system rollback and start with the static partition (A).

[0137] In some embodiments, the bootloader may record the number of times the static partition (B) is started. If the bootloader finds that the number of times the static partition (B) is started is greater than or equal to a preset threshold (e.g., 3 times, 5 times), and the startup with the static partition (B) is unsuccessful, the bootloader will perform a system rollback and start with the static partition (A). In other words, the bootloader loads the following in sequence: the basic partition, the static partition (A), the dynamic partition (super), and the user data partition. In this way, the mobile phone will start with the operating system corresponding to the static partition (A) (e.g., the operating system of version 1.1).

[0138] It is understandable that when the mobile phone is started with the static partition (B), it may fail to start with the static partition (B) due to various reasons, that is, the mobile phone cannot run the version 1.2 operating system. Therefore, after the mobile phone attempts to start with the static partition (B) for many times and still fails to start successfully, the mobile phone performs a system rollback and starts with the static partition (A); that is, the mobile phone runs the version 1.1 operating system. Since the relevant data of the version 1.1 operating system has not been changed during the above-mentioned virtual A / B installation process, the mobile phone can still start with the version 1.1 operating system. In this way, even if the operating system update of the mobile phone is unsuccessful, the mobile phone can still use the non-updated operating system (such as version 1.1) to enter the user interaction interface, and it will not affect the user's normal use of the mobile phone.

[0139] S506a. After the mobile phone is successfully started with the static partition (A), the update engine generates an upgrade result file including system rollback information.

[0140] Exemplarily, the bootloader can be completed after the mobile phone is started with a static partition (A). The bootloader will modify the mobile phone startup flag. Next, after the upgrade engine (update engine) is started, the upgrade engine (update engine) can generate an upgrade result file including system rollback information. When the upgrade result file includes system rollback information, the upgrade result file is used to indicate to the OUC that the operating system upgrade of the mobile phone has failed (the virtual A / B installation failed), and the operating system has rolled back. In addition, due to the failure of the virtual A / B installation of the mobile phone, the mobile phone runs under the operating system version 1.1, and the upgrade engine (update engine) does not need to and will not perform the merge process.

[0141] In some embodiments, the upgrade result file may include an upgrade result flag. The upgrade result flag may indicate the success or failure of the operating system upgrade through different values. For example, the value of the upgrade result flag is "50", which may indicate that a system rollback has occurred in the mobile phone operating system. That is, in some embodiments, if a system rollback occurs in the mobile phone, the bootloader will set the value of the upgrade result flag to "50" to indicate that a system rollback has occurred in the mobile phone.

[0142] In some embodiments, after the update engine is started, it can obtain the version number of the operating system currently running on the mobile phone. If it is found that the version number currently running on the mobile phone is the version number of the old operating system, an upgrade result file including system rollback information is generated.

[0143] It is understandable that if the phone has a system rollback, running in static partition (A), it will cause the boot loader to generate an upgrade result file (the upgrade result file includes the system rollback information), and because the phone runs the update engine in static partition (A), it will not perform merge and will not generate upgrade management data. In this way, the subsequent OUC can obtain through the upgrade result file that the virtual A / B upgrade on the phone was unsuccessful and a system rollback occurred.

[0144] S505b. If the mobile phone is successfully started with the static partition (B), the system service starts the update engine (updateengine) and OUC.

[0145] In some embodiments, after the system server is loaded and started successfully, the system server can search for the mobile phone startup flag. If the search shows that the mobile phone startup flag is successfully started, the system server instructs the update engine and OUC to start, so that the update engine performs a merge operation.

[0146] Among them, the point can also be called the tracking point, which means adding a breakpoint during the program running process, pausing the program running, and then outputting the data generated by the program when the program runs to the breakpoint. For example, when the update engine is merging, if the update engine runs to the preset point, the update engine will pause the merge and output the upgrade point data.

[0147] In this embodiment, after the update engine is started, the update engine checks the disk placement status of the COW files in the user data partition (that is, the disk placement status of the COW files in the user data partition to the dynamic partition (super)) and performs a merge operation.

[0148] Exemplarily, the metadata partition ( / metadata) of the basic partition (common) may record the disk status information. The disk status information includes "merged" or "wait for merge". The disk status information is used to indicate whether there is a COW file in the current user data partition that needs to be flushed to the dynamic partition (super).

[0149] Specifically, the disk-push status information includes the overall identification for the dynamic partition (super) and the sub-partition identification for each sub-partition. When the overall identification is "merged", it means that all sub-partitions of the dynamic partition (super) do not need to be flushed; when the overall identification is "not flushed (wait for merge), it means that one or more sub-partitions of the dynamic partition (super) need to be flushed; when the sub-partition identification is "merged", it means that the sub-partition does not need to be flushed; when the sub-partition identification is "not flushed (wait for merge), it means that the sub-partition needs to be flushed.

[0150] If the update engine determines through the above disk-push status information that the dynamic partition (super) needs to be flushed, the update engine can execute the merge process to flush the COW file in the user data partition to the sub-partition of the dynamic partition corresponding to the COW file.

[0151] S506b. The update engine performs a merge operation.

[0152] It is understandable that the triggering time for the update engine to perform the merge operation may include that the update engine is successfully started. That is, after the update engine is successfully started, the update engine will check the disk status information and perform the merge operation according to the disk status information. It is understandable that for the update engine, after the update engine is successfully started, the update engine can actively perform the merge operation.

[0153] In some embodiments, the above-mentioned disk write operation refers to, during the operating system upgrade process, writing the dynamic partition (super) upgrade file (such as a COW file) saved in the virtual dynamic partition on the user data partition (userdata) into the dynamic partition (super), so that the dynamic partition (super) file completes the data upgrade, so that the mobile phone does not need to load the dynamic partition (super) and the virtual dynamic partition when it starts next time, and the mobile phone can be started by loading the dynamic partition (super).

[0154] Exemplarily, the update engine writes the upgraded data in the COW file in the user data partition (userdata) to the corresponding address in the dynamic partition (super), so that all the data in the dynamic partition (super) are the upgraded new version data. And subsequently, after the merge operation of the update engine (update engine) is successful, the update engine (update engine) deletes the COW file in the user data partition (userdata) and returns the storage space to the user data partition (userdata); and changes the disk status information in the metadata ( / metadata) of the basic partition (common) from "not yet stored (wait for merge)" to "already stored (merged)".

[0155] For example, see Fig.10 ; The upgrade engine (update engine) writes the upgrade data (such as A2, D2) in the COW file in the user data partition (userdata) to the address corresponding to the dynamic partition (super). For example, the upgrade data in the COW file in the user data partition (userdata) is A2 at address S1-1; wherein address S1-1 corresponds to address S1 in the dynamic partition (super). For another example, the upgrade data in the COW file in the user data partition (userdata) is D2 at address S4-1; wherein address S4-1 corresponds to address S4 in the dynamic partition (super). The upgrade engine (update engine) will overwrite the upgrade data A2 onto A1 in address S1, that is, modify A1 in the dynamic partition (super) to A2; and, the upgrade engine (update engine) will overwrite the upgrade data D2 onto D1 in address S4, that is, modify D1 in the dynamic partition (super) to D2.

[0156] In some embodiments, during the merge process, the update engine generates and outputs the update dotting data according to the preset dotting positions.

[0157] For example, when the upgrade engine is executing the merge, if it runs to a preset dot position, the upgrade engine will pause the merge process. Next, after the merge process is paused, the upgrade engine reads the merge data in the merge process (for example, variable values, the location of the upgrade file, the integrity of the upgrade file, the file check bit, the status of the upgrade file, etc.), and generates upgrade dot data based on the merge data, and stores the upgrade dot data in the cache. Afterwards, the OUC can obtain the upgrade dot data from the cache.

[0158] In some embodiments, during the merge process of the update engine, the update engine will overwrite the update engine's earlier generated upgrade check data. Assuming that some upgrade check data is a file check digit, the update engine will overwrite the file check digit generated later with the file check digit generated earlier. In other words, the file check digit generated earlier will be deleted in the cache.

[0159] In some embodiments, the update engine generates an upgrade result (eg, generates an upgrade result file including upgrade success information) after the merge is completed and the merge is successful.

[0160] In some embodiments, the upgrade result file may include an upgrade result flag. The upgrade result flag may use different values ​​to indicate the success or failure of the operating system upgrade. For example, a value of the upgrade result flag of "0" may indicate that the mobile phone operating system has been successfully upgraded. That is, in some embodiments, if the merge of the update engine is successful, the update engine may set the value of the upgrade result flag to "0" to indicate that the merge process on the mobile phone is successful, and the files related to the system upgrade in the user data partition have been synchronized to the dynamic partition.

[0161] It should be noted that when the update engine executes merge successfully, the upgrade result file generated by the update engine only includes the upgrade success information, and does not include the upgrade RBI data. Also, since the OUC obtains the upgrade RBI data from the cache, and the upgrade result file is obtained in the form of a file, that is, the upgrade RBI data and the upgrade result information are separated.

[0162] It can be seen that in the system upgrade information acquisition method provided in the embodiment of the present application, the upgrade result information and the upgrade management data included in the upgrade result file are separated and will not be mixed together.

[0163] Compared with some solutions, in the system upgrade record file generated by the mobile phone, the system upgrade record file contains both upgrade result information and upgrade dotting data, and the system upgrade file needs to be parsed and extracted from the parsed system upgrade file. Since, in the embodiment of the present application, the upgrade result information is separated from the upgrade dotting data, if the mobile phone only cares about the upgrade result and does not care about the upgrade dotting data; the mobile phone can directly search the upgrade result file to obtain the upgrade result of the mobile phone (such as successful upgrade or system rollback), and the mobile phone does not need to obtain the upgrade dotting data. This will make the system upgrade information on the mobile phone more concise and more convenient to use in the future; when the mobile phone only needs the upgrade result, it can directly obtain the upgrade result by searching the upgrade result file, and will not be affected by the upgraded dotting data. And, compared with some solutions, in the system upgrade record file generated by the mobile phone, the system upgrade record file contains both upgrade result information and upgrade dotting data, and the mobile phone needs to parse the upgrade record file, and filter out the upgrade dotting data from the parsed system upgrade record file to extract the upgrade result. In this solution, there is no need to parse the upgrade record file containing the upgrade result information and the upgrade management data. You only need to parse the upgrade result file to directly obtain the upgrade result of the mobile phone. In other words, the process of the mobile phone obtaining the upgrade result will not be interfered by the upgrade management data.

[0164] It can be seen that in the method provided in the embodiment of the present application, by separating the upgrade results and the upgrade management data, the mobile phone can directly, accurately and efficiently obtain the system upgrade results, which is more convenient for the use of system upgrade information.

[0165] In some embodiments, the mobile phone may further separate the upgrade result file including the upgrade success information from the upgrade result file including the system rollback information. For example, the upgrade result file and the system rollback file may be separated, wherein the upgrade success file is used to record the upgrade success information and the system rollback file is used to record the system rollback information. In this way, the information in the upgrade result file may also be simplified.

[0166] In some embodiments, the update engine will also delete the upgrade file (eg, the virtual dynamic partition in the user data partition) after the merge is successful, so that the storage space can be returned to the user data partition (userdata).

[0167] In some embodiments, after the merge operation of the update engine is successfully executed, the update engine can clear the installation files, such as deleting the virtual dynamic partition in the user data partition, so that the mobile phone can run with the updated, complete operating system (such as version 1.2).

[0168] Exemplarily, after the update engine's merge operation is successfully executed, the update engine will delete the COW file in the user data partition. It should be noted that after the update engine's merge operation fails, the update engine does not clear the installation files. Since the merge fails at this time, the mobile phone's super does not have complete upgraded operating system data (such as A2 and D2 mentioned above), and the mobile phone is now running the operating system in the form of dynamic partitions and virtual dynamic partitions. If the above installation files are cleared, the mobile phone will crash, causing the mobile phone to be unable to run the version 1.2 operating system normally.

[0169] S507. After the OUC is successfully started, the OUC obtains the upgrade result file. If the OUC does not obtain the upgrade result file, execute S508; if the OUC obtains the upgrade result file, execute step S512.

[0170] In some embodiments, the OUC may try to obtain the upgrade result file. If the OUC obtains the upgrade result file, the OUC may know that the upgrade engine on the mobile phone has completed the merge and the merge is successful, and the system upgrade is successful. In other words, the upgrade engine on the mobile phone is not merging.

[0171] In this way, after the OUC obtains the upgrade result file, the OUC can prompt that the operating system of the mobile phone has been successfully upgraded based on the upgrade result file; or send the upgrade result file to the server, etc.

[0172] If the OUC does not obtain the upgrade result file, the update engine may be in the process of merging, or the merge process may have been completed and the merge failed. Next, the OUC may determine whether the update engine is merging or the merge is finished.

[0173] S508. OUC determines whether the update engine is merging; if it is merging, execute S509; if it is not merging, execute S510.

[0174] In some embodiments, OUC can obtain the upgrade dotting data generated by the update engine during the merge process through a preset interface (e.g., cleanupsuccful interface) to determine whether the update engine is merging. If the upgrade dotting data can be obtained, OUC can determine that the update engine is merging; if the upgrade dotting data cannot be obtained, OUC can determine that the update engine has ended the merge. In this way, it is relatively convenient to determine whether the electronic device is performing a merge operation.

[0175] Exemplarily, the process of OUC obtaining the upgrade dot data generated by the update engine during the merge process through the cleanupsuccful interface can be understood as OUC monitoring the location in the cache where the update engine writes the upgrade dot data during the merge process (also known as the target storage area); if there is data at that location, or the data at that location has changed; then OUC obtains the upgrade dot data from that location in the cache.

[0176] According to the above analysis, if the update engine is merging, the update engine will output the RBI data in the cache, that is, there will be upgrade RBI data in the cache, and if the update engine ends the merge, the update engine will exit, resulting in the release of the memory used by the update engine, that is, there will be no upgrade RBI data in the cache. Based on this, OUC can determine whether the update engine is merging by obtaining the upgrade RBI data.

[0177] In some embodiments, the OUC may also determine whether the update engine is merging by using data generated by the update engine during the merge process. In this way, it is also possible to more conveniently determine whether the electronic device is performing a merge operation.

[0178] It is understandable that the update engine will generate some data (such as interface call records, temporary file generation data, file verification data, etc.) during the merge process. If the update engine ends the merge, these data will be deleted by the update engine. Based on this, OUC can determine whether the update engine is merging by searching for the data generated by the update engine during the merge process (such as interface call records, temporary file generation data, file verification data, etc.). For example, if the file verification data is searched, OUC determines that the update engine is merging; if the file verification data is not searched, OUC determines that the update engine has ended the merge.

[0179] In some embodiments, the OUC can also determine whether the update engine is merging through data returned by a preset interface (such as a running interface). In this way, it is also convenient to determine whether the electronic device is performing a merge operation.

[0180] In other embodiments, the mobile phone may first determine whether the update engine is merging, and then determine whether the upgrade result is obtained; and the mobile phone may also simultaneously determine whether the update engine is merging, and determine whether the upgrade result is obtained.

[0181] Exemplarily, the OUC may obtain the upgrade management data and the upgrade result, and according to the acquisition situation (eg, whether the upgrade management data is obtained, whether the upgrade result is obtained), execute subsequent steps corresponding to the acquisition situation.

[0182] For example, the corresponding relationship between the acquisition situation and the subsequent steps may be shown in Table 1 below.

[0183] Table 1

[0184]

[0185] S509. The upgrade engine is performing a merge operation, and the OUC is waiting for the upgrade engine's merge operation to be completed; if the upgrade engine merge is successful, the OUC can obtain the upgrade result file generated by the upgrade engine and execute step S512; if the upgrade engine merge fails, execute step S510.

[0186] S510. OUC instructs the update engine to perform a merge operation.

[0187] In some embodiments, the triggering timing for the update engine to perform a merge operation may also include: receiving a disk-push instruction. For example, in response to receiving the disk-push instruction, the update engine performs a merge operation.

[0188] Exemplarily, the OUC may send a disk write instruction to the update engine to trigger the update engine to perform a merge operation.

[0189] In some embodiments, the OUC may also trigger the update engine to perform a merge operation through a system call. For example, the OUC may send a merge start message to a system server, and in response to receiving the merge start message, the system server sends a merge instruction to the upgrade engine to trigger the update engine to perform a merge operation.

[0190] In other embodiments, other modules on the mobile phone may instruct the update engine to perform the merge operation. For example, the system service instructs the update engine to perform the merge operation.

[0191] It is understandable that since the update engine is located at the local layer and OUC is located at the application layer; relative to OUC, the update engine will be more bottom-level. In other words, the startup of OUC will be more complicated than the update engine, and more resources (such as processes that OUC depends on, services that OUC depends on) will be required. Therefore, the startup time of OUC will be later than the startup time of the update engine. In other words, after the mobile phone is successfully started with static partition (B), the update engine on the mobile phone will start before OUC. And, since OUC is unlikely to start before the update engine, and the update engine will perform a merge operation based on the disk status information after startup. It can be seen that when OUC is successfully started, the update engine may be merging, or it may have completed merging (such as merge success, or merge failure).

[0192] Also, because the update engine writes the upgrade RBI data into the cache, that is to say, the cache will be requested by the update engine. Based on this, when the merge process of the update engine ends, the data in the cache will be cleared. It can be seen that if the merge process of the update engine ends, OUC cannot obtain the upgrade RBI data. In addition, since the cache space on the mobile phone is relatively precious, in order to save cache space, the update engine will overwrite the upgrade RBI data generated later with the RBI data generated previously. In other words, if OUC starts and obtains the upgrade RBI data from the cache during the merge execution of the update engine, OUC may not obtain the complete upgrade RBI data.

[0193] That is to say, if OUC obtains the upgrade RBI data during the process of the update engine performing the first merge operation. Since the startup time of OUC will be later than that of the update engine, and during the merge process of the update engine, the later generated upgrade RBI data will overwrite the earlier generated upgrade RBI data. This will cause OUC to fail to obtain the complete upgrade RBI data. Based on this, if the update engine fails to perform the merge process (such as the merge operation fails in S509), OUC needs to instruct the update engine to start again and perform the merge operation. In this way, OUC obtains the upgrade RBI data during the process from the start to the end of the merge of the update engine. So that OUC can obtain the upgrade RBI data generated by the update engine during the complete merge process. And, if the update engine successfully performs the merge operation for the second time, the update engine will generate an upgrade result file including the upgrade success information.

[0194] It can be seen that since OUC will not be started before the update engine performs merge; and, during the process of the update engine performing merge, the update engine will update the upgrade RBI data in the cache. Based on this, when the update engine performs merge for the first time (such as in the above step S506b), OUC may not be able to obtain complete upgrade RBI data from the cache. Therefore, OUC needs to instruct the update engine to perform a merge operation so that the update engine performs a second merge operation and obtains the upgrade RBI data during the process of the update engine performing the merge operation. In this way, OUC can obtain the complete upgrade RBI data generated by the update engine from the cache.

[0195] S511. During the process of the update engine executing the merge operation, the OUC obtains the upgrade management data from the cache.

[0196] In some embodiments, the merge operation performed in step S511 may be referred to as a second merge operation.

[0197] In step S511, the update engine performs a merge operation, which can be understood as the merge operation performed by the update engine in the above step S509.

[0198] During the merge operation, the update engine can generate and output the upgrade dotting data through the cache according to the dotting positions, wherein the dotting positions can include preset dotting positions and expandable dotting positions.

[0199] Exemplarily, it is assumed that the merge process of the update engine includes: overwriting the upgrade data (eg, A2, D2) in the COW file in the user data partition (userdata) to the address corresponding to the dynamic partition (super).

[0200] See also Fig.11 , the update engine can first read A2 in the COW file and calculate the hash value of A2 (e.g., hash_A2). After the hash value of A2 is calculated, the update engine executes to the dot position 1, and the update engine writes the hash value of A2 as the upgrade dot data into the cache. Afterwards, the update engine overwrites A2 in the COW file to the corresponding position of A2 in super (e.g., S1).

[0201] Next, see again Fig.11 After the update engine has overwritten A2, it reads D2 in the COW file and calculates the hash value of D2 (e.g., hash_D2). After the hash value of D2 is calculated, the update engine executes to the dot position 2 and writes the hash value of D2 into the cache as the upgrade dot data. After that, the update engine overwrites D2 in the COW file to the corresponding position of D2 in super (e.g., S4).

[0202] Afterwards, see Fig.11 After D2 is overwritten, the update engine calculates the hash value of the updated file in super. After the hash value calculation of the updated file is completed, the update engine executes to the dot position 3. The update engine reads the hash value of the updated file in super (such as hash_super) and writes the hash value of the updated file in super as the upgrade dot data into the cache.

[0203] In this way, the update engine can output the dot data during the merge process, so that the relevant technicians can repair the merge process of the update engine of the mobile phone according to the dot data output during the merge process of the update engine.

[0204] Exemplarily, OUC can obtain the upgrade dotting data through a preset interface (e.g., clean up succful interface). The process of OUC obtaining the dotting data generated by the update engine during the merge process through the clean up succful interface can be understood as OUC monitoring the location in the cache where the update engine writes the upgrade dotting data during the merge process. If there is data at this location or the data at this location changes, OUC downloads and saves the upgrade dotting data from this location in the cache.

[0205] Since in the embodiment of the present application, the upgrade dot data obtained by the OUC is directly obtained from the cache, if the mobile phone needs to add a dot position during the merge process, the update engine generates the new dot data when it runs to the new dot position during the merge process. The update engine can directly pass the new upgrade dot data to the OUC using the cache as an intermediary.

[0206] In some solutions, the update engine uses files (such as system upgrade record files) as a medium to pass the newly added RBI data to OUC. The update engine needs to perform format processing on the newly added RBI data to meet the configuration requirements of the file format; and when the upgraded RBI data is used subsequently, it is also necessary to parse the upgraded RBI data from the file format. This makes it inconvenient to expand the upgraded RBI data and to use the upgraded RBI data. However, in this solution, cache is used as a medium, and there is no need to perform format processing on the upgraded RBI data or to meet the configuration requirements of the file format; OUC obtains relatively original data from the cache; the update engine does not need to perform format processing on the newly added RBI data and can pass the newly added RBI data to OUC. At the same time, when the upgraded RBI data is used subsequently, there is no need to parse the upgraded RBI data from the file format, and the upgraded RBI data obtained by OUC from the cache can be used directly.

[0207] It can be seen that the system upgrade information acquisition method provided in the embodiment of the present application can easily add the dot position by obtaining the upgrade dot data from the cache through the OUC, and can conveniently expand the system upgrade information (such as the upgrade dot data). In addition, since the upgrade dot data obtained by the OUC from the cache is relatively original upgrade dot data, there is no file format requirement, and it is not necessary to parse the format file to obtain the upgrade dot data, which will be more convenient for the subsequent use of the upgrade dot data.

[0208] S512. OUC saves the upgrade result file or the upgrade management data.

[0209] In some embodiments, the OUC may also send an upgrade result file or upgrade management data to a server (such as the above-mentioned packet search server) that has established a communication connection with the mobile phone, so that the server can learn about the upgrade status of the mobile phone.

[0210] In some embodiments, if the OUC obtains the upgrade result file, the OUC can also display the upgrade result corresponding to the upgrade result file according to the upgrade result file. In this way, the user using the mobile phone can know the upgrade status of the mobile phone operating system, which can improve the user experience.

[0211] Exemplarily, after obtaining the upgrade result file, OUC can parse the content of the upgrade result file. If the upgrade result file includes the upgrade success information, OUC can prompt the user that the operating system upgrade is successful. If the upgrade result file includes the system rollback information, OUC can prompt the user that the operating system upgrade failed and a system rollback occurred. In this way, the user can perceive the upgrade result of the operating system on the mobile phone. The user experience can be improved. Among them, the way OUC prompts the user includes but is not limited to: displaying a notification message, displaying a pop-up window, playing a prompt sound, etc.

[0212] In some embodiments, the OUC can repair the merge process of the update engine based on the upgrade management data. Assume that the upgrade management data includes the above-mentioned hash_super, and the OUC finds that the updated super value is incorrect by analyzing hash_super. The OUC can send a modification package acquisition request to the package search server to request the package search server to send a repair package for the super partition to the OUC. Afterwards, after the OUC receives the repair package for the super partition, the OUC repairs the merge process based on the repair package for the super partition (e.g., instructs the update engine to merge again based on the repair package for the super partition).

[0213] In some embodiments, the system upgrade information acquisition method provided in the embodiments of the present application may further include step S513.

[0214] S513. OUC sends the upgrade result file or upgrade management data.

[0215] In some embodiments, the OUC may send an upgrade result file to a server (e.g., the above-mentioned search package server, or the server of the mobile phone provider), so that the server can obtain the operating system upgrade result on the mobile phone and subsequently optimize the upgrade package based on the operating system upgrade result.

[0216] In some embodiments, OUC can send upgrade RBI data to the server; in this way, the server can analyze the reason for the failure of the mobile phone merge based on the upgrade RBI data, and repair the merge process of the mobile phone. To complete the operating system upgrade of the mobile phone. For example, if the upgrade RBI data includes the above-mentioned hash_D2, the server finds through analysis of hash_D2 that hash_D2 is different from the correct hash_D2, that is, the D2 data is incorrect. The server can send a system repair package to the mobile phone again (the repair package includes the correct D2 data); thereafter, the update engine on the mobile phone executes the merge process based on the system repair package. In this way, the server can repair the merge process of the mobile phone.

[0217] In some embodiments, after the OUC sends the upgrade result file or the upgrade dotting data, the OUC may also delete the upgrade dotting data or the upgrade result file, so as to save the storage space of the OUC.

[0218] It should be pointed out that, in some embodiments, the system upgrade information acquisition method provided in the embodiments of the present application can save the system upgrade record file. In other embodiments, the system upgrade information acquisition method provided in the embodiments of the present application may not save the system upgrade record file. The embodiments of the present application do not limit whether to save the system upgrade record file in the related technology.

[0219] Exemplarily, the preset marking bits in the embodiment of the present application may include one or more of the following: partition copy fail marking bit, upgrade package does not exist marking bit, check (payload zip verify sign) marking bit, parameter does not meet the preset (invalid para) marking bit, certificate does not meet the preset (auth fail) marking bit, partition update failure (table update fail) marking bit, binary converter (binary) update failure (update by update binary fail) marking bit, upgrade small partition hash (hash) check (download block hash mismatch) marking bit. And, the expandable marking bits (new marking bits) may include one or more of the following: read status marking bit, get merge table (get table info) marking bit, unknown table (unknown table) marking bit, unknown target type (unknown trage type) marking bit, merge after unmerged (unmerged sectors after completion) marking bit, merge state is not as expected (unexpectedmerge state) marking bit, etc.

[0220] In some embodiments, during the merge process, if the update engine runs to a preset dotting position, the update engine will pause the merge process. Next, after the merge process is paused, the upgrade engine reads the merge data (such as parameter data, variable data, etc.) in the merge process, and determines whether the merge data belongs to an abnormal branch. If it belongs to an abnormal branch, it generates upgrade dotting data based on the merge data, and stores the upgrade dotting data in a cache. If it does not belong to an abnormal branch, the upgrade dotting data is not generated. Exemplarily, the update engine will be configured with merge data of non-abnormal branches (normal branches) corresponding to each dotting position; if the merge data read by the update engine is different from the merge data of the normal branch, the merge data read by the update engine will be stored in the cache as upgrade dotting data.

[0221] In this way, the amount of the upgrade RBI data generated by the update engine can be reduced. Also, since in the embodiment of the present application, the upgrade RBI data generated by the update engine will be stored in the cache of the mobile phone, reducing the amount of the upgrade RBI data generated by the update engine can reduce the occupancy of the cache on the mobile phone.

[0222] In some other embodiments, when the update engine runs to the dot position and determines that the merge data belongs to an abnormal branch and generates the upgrade dot data, it also generates a result corresponding to the dot position (eg, may be called an abnormal result) and stores the abnormal result in the cache.

[0223] For example, suppose that during the merge process, the update engine reads the COW file in the user data partition; after that, the update engine runs to the mark position where the upgrade package does not exist, and the merge process of the update engine is suspended. If the update engine reads the COW file from the user data partition, and the update engine determines that the merge data (the COW file is read) belongs to the normal branch of the mark position, the update engine does not generate the upgrade mark data and continues to execute the subsequent merge process. If the update engine does not read the COW file from the user data partition, and the update engine determines that the merge data (the COW file is not read) belongs to the abnormal branch of the mark position, the update engine generates the upgrade mark data and continues to execute the subsequent merge process (such as reading the COW file again until the COW file is read, etc.).

[0224] As another example, assume that during the merge process, the update engine determines whether the COW file in the user data partition is stored in the corresponding position in the dynamic partition; then, the update engine reaches the unexpected merge state, and the merge process of the update engine is suspended. The update engine compares the COW file in the user data partition with the file in the corresponding position (sub-partition) in the dynamic partition (e.g., compares Fig.10 or, compare the files in S1 and S1-1 in Fig.10If the comparison finds that the two files are different (e.g., the files in S1 and S1-1 are different; or, the files in S4 and S4-1 are different), the update engine determines that the merge data belongs to the abnormal branch of the dot position, then the update engine generates upgrade dot data and continues to execute the subsequent merge process. If the comparison finds that the two files are the same, the update engine determines that the merge data belongs to the normal branch of the dot position, then the update engine does not generate upgrade dot data and continues to execute the subsequent merge process.

[0225] In the above Figure 5 In the corresponding embodiment, the upgrade engine searches for the disk drop status information after being successfully started, and performs a merge operation based on the disk drop status information. However, in some scenarios, the triggering time for the upgrade engine to perform the merge operation may not include the successful startup of the upgrade engine; the triggering time for the upgrade engine to perform the merge operation includes receiving a disk drop indication. That is to say, in these scenarios, for the upgrade engine, after the upgrade engine is successfully started, the upgrade engine may not actively perform the merge operation, and the upgrade engine may passively perform the merge operation (for example, in response to receiving a disk drop indication, the upgrade engine performs the merge operation).

[0226] In this way, when the update engine executes a merge, the OUC can obtain the update result file or the update management data, and the upgrade process of the operating system on the mobile phone can be relatively simple.

[0227] For details, see Fig.12 In this scenario, the system upgrade information acquisition method provided in the embodiment of the present application may include steps S1200-S1211.

[0228] Among them, steps S1200-S1204 can refer to the above steps S500-S504, which will not be repeated here.

[0229] After step S1204, the mobile phone executes S1205a-1206a, or executes S1205b-S1206b and subsequent steps.

[0230] Next, if the mobile phone fails to run with version 1.2, that is, the mobile phone fails to start with the new system. The bootloader will execute step S1205a to implement system rollback. Afterwards, after the mobile phone has a system rollback, that is, it successfully starts with the old version (such as version 1.1), the update engine can execute S1206a to generate an upgrade result file including system rollback information. Specifically, steps S1205a and S1206a can refer to the above steps S505a and S506a.

[0231] S1205b. If the mobile phone is successfully started with the static partition (B), the system server starts the update engine and OUC.

[0232] If the mobile phone runs successfully with version 1.2, that is, the mobile phone starts successfully with the new system; the system service (systemserver) can start the update engine (update engine) and OUC.

[0233] In this scenario, after the update engine is successfully started, it waits for the indication of writing to disk before executing the merge operation. In this way, the update engine can perform a complete merge operation after the OUC is started. In this way, even if the OUC is started later than the update engine, the update engine can still perform the complete merge process after the OUC is started, so that the OUC can obtain the complete dot data generated by the update engine during the merge process.

[0234] S1206b. OUC instructs the update engine to perform a merge operation, thereby triggering the update engine to perform a disk write operation (merge).

[0235] In some embodiments, the OUC may send a write-to-disk instruction to the update engine to trigger the update engine to execute a merge.

[0236] Among them, the disk drop indication may also be called a disk drop indication, a merge indication, etc.; in some embodiments, the disk drop indication may be a preset string, and the OUC may send the disk drop indication to the update engine through a preset communication interface with the update engine.

[0237] In some embodiments, the OUC may also trigger the update engine to perform a merge operation through a system call. For example, the OUC may send a merge start message to a system server, and in response to receiving the merge start message, the system server sends a merge instruction to the upgrade engine to trigger the update engine to perform a merge operation.

[0238] In this way, OUC can obtain the complete upgrade management data of the upgrade engine (update engine) during the process of performing the disk operation (merge) of the upgrade engine (update engine).

[0239] S1207. If the update engine receives the instruction from the OUC, the update engine performs a merge operation.

[0240] For example, during the merge process, the update engine can output the updated dotting data to the OUC using the cache as an intermediary according to the dotting bit. Specifically, this step can refer to the above steps S506b and S510, which will not be described in detail here.

[0241] S1208. During the process of the update engine executing the merge operation, the OUC obtains the upgrade management data from the cache.

[0242] Specifically, this step may refer to the above step S511, which will not be described in detail here.

[0243] S1209. After the update engine merge is completed, the OUC determines whether the update result file is obtained. If the update result file is obtained, step S1210 is executed; if not, step S1211 is executed.

[0244] S1210.OCU saves the upgrade result file but does not save the upgrade management data.

[0245] S1211.OCU saves the upgrade management data.

[0246] In some scenarios, the electronic device may also upgrade the operating system multiple times. For example, the operating system of version 1.1 is upgraded to the operating system of version 1.2; then, the operating system of version 1.2 is upgraded to the operating system of version 1.3. It is understandable that the process of upgrading the operating system of version 1.2 to the operating system of version 1.3 is similar to the process of upgrading the operating system of version 1.1 to the operating system of version 1.2, which can be referred to the description above and will not be repeated here.

[0247] Next, the system upgrade information acquisition method provided by the embodiment of the present application will be introduced in the scenario of multiple operating system upgrades.

[0248] The electronic device runs a first operating system. Next, the electronic device runs an upgrade installation package of a second operating system. The first operating system is a version 1.1 operating system, and the second operating system is a version 1.2 operating system. Exemplarily, this process can refer to the relevant description of the above steps S500-S502.

[0249] Afterwards, the electronic device is turned off; then, the electronic device is turned on. Next, the electronic device runs the second operating system. Exemplarily, this process can refer to the relevant description of the above steps S503 and S504.

[0250] Then, at a first time point, the electronic device performs a first merge operation.

[0251] Next, at a second time point, the electronic device successfully executes the first merge operation; the second time point is later than the first time point.

[0252] Then, at a third time point, the electronic device starts the online upgrade client OUC; the third time point is later than the first time point.

[0253] Next, the electronic device runs the upgrade installation package of the third operating system. Exemplarily, this process can refer to the relevant description of the above steps S500-S502.

[0254] Afterwards, the electronic device is turned off; then, the electronic device is turned on. Next, the electronic device runs the third operating system. Exemplarily, this process can refer to the relevant description of the above steps S503 and S504. Among them, the third operating system can be an operating system of version 1.3.

[0255] Then, at a fourth time point, the electronic device performs a second merge operation.

[0256] Then, at the fifth time point, the electronic device completes the second merge operation, and the second merge operation fails; the fifth time point is later than the fourth time point; at the sixth time point, the OUC is started, and the sixth time point is later than the fourth time point.

[0257] Next, at a seventh time point, the electronic device performs a third merge operation; the seventh time point is later than the sixth time point. The upgrade dotting data may include data generated by the electronic device based on the dotting bits during the execution of the merge operation. Also, the above-mentioned merge operation (such as the first merge operation, the second merge operation or the third merge operation) may include: writing the upgrade file saved in the virtual dynamic partition (in the user data partition) of the electronic device to the dynamic partition of the electronic device.

[0258] In this embodiment, OUC is started after the second merge operation is executed. Considering that the OUC may not be started when the electronic device executes the second merge operation, it is difficult for OUC to obtain complete system upgrade information during the second merge operation. Based on this, after the OUC is started, if the second merge operation fails, the electronic device triggers the merge operation to be executed again, that is, the third merge operation is executed. In this way, after the OUC is started, the electronic device can execute the complete merge operation process. Then, OUC can obtain complete system upgrade information during the merge process without parsing the file format and then obtaining the system upgrade information from the file. It can be seen that this method can obtain system upgrade information conveniently, efficiently and directly.

[0259] In other embodiments, the present application further provides a method for obtaining system upgrade information, in which the electronic device runs a fourth operating system. Next, the electronic device runs an upgrade installation package of a fifth operating system. After that, the electronic device is turned off. Next, the electronic device is turned on. Then, the electronic device runs the fifth operating system. Exemplarily, this process can refer to the relevant description of the above steps S1200-S1204.

[0260] Then, at the eighth time point, the electronic device starts the online upgrade client OUC. This process can refer to the relevant description of the above step S1205b.

[0261] Next, in response to the completion of the OUC startup, at a ninth time point, the electronic device performs a merge operation; the ninth time point is later than the eighth time point. For this process, please refer to the relevant description of the above step S1206b.

[0262] In the process of the electronic device performing the merge operation, the OUC obtains the upgrade management data from the cache. This process can refer to the relevant description of the above step S1208.

[0263] It is understandable that in order to implement the above functions, the electronic device includes hardware and / or software modules corresponding to the execution of each function. In combination with the algorithm steps of each example described in the embodiments disclosed herein, the present application can be implemented in the form of hardware or a combination of hardware and computer software. Whether a function is executed in the form of hardware or computer software driving hardware depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application in combination with the embodiments, but such implementation should not be considered to be beyond the scope of the present application.

[0264] In this embodiment, the electronic device can be divided into functional modules according to the above method example. For example, each functional module can be divided according to each function, or two or more functions can be integrated into one processing module. The above integrated module can be implemented in the form of hardware. It should be noted that the division of modules in this embodiment is schematic and is only a logical function division. There may be other division methods in actual implementation.

[0265] The present application also provides an electronic device, such as Fig.13 As shown, the electronic device may include one or more processors 1001 , a memory 1002 and a communication interface 1003 .

[0266] The memory 1002 and the communication interface 1003 are coupled to the processor 1001. For example, the memory 1002, the communication interface 1003 and the processor 1001 may be coupled together via a bus 1004.

[0267] The communication interface 1003 is used for data transmission with other devices. The memory 1002 stores computer program code. The computer program code includes computer instructions. When the computer instructions are executed by the processor 1001, the electronic device performs the device authentication in the embodiment of the present application.

[0268] Among them, the processor 1001 can be a processor or a controller, for example, it can be a central processing unit (CPU), a general processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic devices, transistor logic devices, hardware components or any combination thereof. It can implement or execute various exemplary logic blocks, modules and circuits described in conjunction with the present disclosure. The processor can also be a combination that implements computing functions, such as a combination of one or more microprocessors, a combination of DSP and microprocessors, and the like.

[0269] The bus 1004 may be a peripheral component interconnect (PCI) bus or an extended industry standard architecture (EISA) bus. The bus 1004 may be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Fig.13 Only one thick line is used in the diagram, but this does not mean that there is only one bus or only one type of bus.

[0270] An embodiment of the present application further provides a computer-readable storage medium, in which a computer program code is stored. When the processor executes the computer program code, the electronic device executes the relevant method steps in the method embodiment.

[0271] The embodiment of the present application also provides a computer program product. When the computer program product is run on a computer, it enables the computer to execute the relevant method steps in the above method embodiment.

[0272] Among them, the electronic device, computer-readable storage medium or computer program product provided in this application is used to execute the corresponding method provided above. Therefore, the beneficial effects that can be achieved can refer to the beneficial effects in the corresponding method provided above, and will not be repeated here.

[0273] Through the description of the above implementation methods, technical personnel in the relevant field can clearly understand that for the convenience and simplicity of description, only the division of the above-mentioned functional modules is used as an example. In actual applications, the above-mentioned functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above.

[0274] In the several embodiments provided in the present application, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are only schematic. For example, the division of the modules or units is only a logical function division. There may be other division methods in actual implementation, such as multiple units or components can be combined or integrated into another device, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0275] The units described as separate components may or may not be physically separated, and the components shown as units may be one physical unit or multiple physical units, that is, they may be located in one place or distributed in multiple different places. Some or all of the units may be selected according to actual needs to achieve the purpose of the present embodiment.

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

[0277] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a readable storage medium. Based on this understanding, the technical solution of the embodiment of the present application is essentially or the part that contributes or all or part of the technical solution can be embodied in the form of a software product, which is stored in a storage medium, including several instructions to enable a device (which can be a single-chip microcomputer, chip, etc.) or a processor (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: U disk, mobile hard disk, read only memory (ROM), random access memory (RAM), disk or optical disk and other media that can store program code.

[0278] The above contents are only specific implementation methods of the present application, but the protection scope of the present application is not limited thereto. Any changes or substitutions within the technical scope disclosed in the present application shall be included in the protection scope of the present application. Therefore, the protection scope of the present application shall be subject to the protection scope of the claims.

Claims

1. A method for obtaining system upgrade information, characterized in that: Applied to electronic equipment, the method comprises: During the running of the first operating system, obtaining a first update package and installing the first update package; Restarting the electronic device and running a second operating system; the second operating system is different from the first operating system; At the first time point, perform the first merge operation; At a second time point, the first merge operation ends and the first merge operation fails; the second time point is later than the first time point; At a third time point, starting the software upgrade service, the third time point being later than the second time point; At a fourth time point, a second merge operation is performed; the fourth time point is later than the third time point.

2. The method according to claim 1, characterized in that The performing of the second merge operation includes: Based on the failure of the first merge operation when the software upgrade service is started at the third time point, the second merge operation is performed.

3. The method according to claim 1 or 2, characterized in that: After the fourth time point, the method further includes: Obtaining a second update package and installing the second update package; Restarting the electronic device and running a third operating system; the third operating system is different from the first operating system; At a fifth time point, performing a third merge operation; the fifth time point is later than the fourth time point; At a sixth time point, starting the software upgrade service; the sixth time point is later than the fifth time point; At the seventh time point, the third merge operation ends; the seventh time point is later than the sixth time point.

4. The method according to claim 3, characterized in that The method further comprises: Based on the fact that the third merge operation is not completed when the software upgrade service is started at the fifth time point, after the third merge operation is completed, no merge operation is performed.

5. The method according to claim 3 or 4, characterized in that: The third merge operation ends, including: If the third merge operation is completed and the third merge operation is successful, the upgrade engine in the electronic device generates an upgrade result file; the upgrade result file is used to indicate that the upgrade is successful, and the upgrade result file does not include upgrade dot data; The software upgrade service obtains the upgrade result file.

6. The method according to any one of claims 3 to 5, characterized in that: The third merge operation ends, further comprising: If the third merge operation ends and fails, the software upgrade service obtains the upgrade management data from the cache.

7. The method according to any one of claims 1 to 6, characterized in that: The method further comprises: During the execution of the second merge operation, the software upgrade service obtains the upgrade management data from the cache.

8. The method according to any one of claims 1 to 7, characterized in that: The first operating system is run based on the first static partition; and the installing the first update package includes: Based on the first update package, a second static partition is updated, where the second static partition is different from the first static partition.

9. The method according to claim 8, characterized in that The running of the second operating system includes: If the second static partition is loaded successfully, running the second operating system; The method further comprises: If loading the second static partition fails, running the first operating system; The upgrade engine generates an upgrade result file, and the software upgrade service obtains the upgrade result file; the upgrade result file is used to indicate that the operating system has been rolled back, and the upgrade result file does not include upgrade management data.

10. An electronic device, characterized in that: The electronic device comprises a processor and a memory, wherein the processor is configured to execute computer instructions stored in the memory, so that the electronic device executes the method according to any one of claims 1 to 9.

11. A computer-readable storage medium, characterized in that: The method comprises computer instructions, which, when executed on an electronic device, cause the electronic device to execute the method as claimed in any one of claims 1 to 9.

Images