System upgrading information acquisition method, electronic device, and storage medium

Abstract

A system upgrading information acquisition method, an electronic device, and a storage medium. In this method, after failing to execute one merge operation, an electronic device executes the merge operation once again, such that an OUC in the electronic device can acquire upgrading event tracking data during a merge process, the upgrading event tracking data comprising newly-added event tracking data. In addition, there are no file format configuration requirements for the upgrading event tracking data, such as the newly-added event tracking data, and there is no need to parse a format file to obtain the upgrading event tracking data in subsequent process. Using this solution can efficiently and conveniently acquire system upgrading information, and can extend the system upgrading information.

Description

System upgrade information acquisition method, electronic device and storage medium

[0001] This application claims priority to the Chinese patent application filed with the State Intellectual Property Office on August 9, 2023, with application number 202310996701.4 and application name “System Upgrade Information Acquisition Method, Electronic Device and Storage Medium”, the entire contents of which are incorporated by reference into this application. 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 an electronic device leaves the factory, the electronic device supplier will burn the operating system into the electronic device, thereby achieving the installation of the operating system before the electronic device leaves the factory. Afterwards, the electronic device supplier may need to upgrade the operating system in the electronic device to improve the user experience.

[0004] Typically, during an operating system upgrade, an 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 may send the system upgrade information to a 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 may be displayed to the user so that the user can perceive the operating system upgrade process of the electronic device and perform certain operations.

[0005] Currently, during operating system upgrades, electronic devices record system upgrade information in a file format. Recording system upgrade information in a file format requires certain file format configurations and requires parsing the file format for subsequent use, which is complex and tedious.

[0006] Summary of the Invention

[0007] 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.

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

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

[0010] The electronic device runs a first operating system. Next, the electronic device runs an upgrade installation package for a second operating system. The electronic device is then shut down and then 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. 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 launches 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 for a third operating system. The electronic device is then shut down and then 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 fails; the fifth time point is later than the fourth time point. At a sixth time point, the OUC is successfully launched; 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. The upgrade dotting data may be generated by the electronic device based on the dotting bits during the merge operation. Furthermore, the above-mentioned merge operation (eg, 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.

[0011] 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 the 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, the OUC can directly obtain the complete system upgrade information (such as upgrade dot data) during the execution of the merge, without having to parse the file format and then obtain the system upgrade information from the file. It can be seen that this method can obtain system upgrade information conveniently, efficiently and directly.

[0012] Compared to some solutions that use files (e.g., system upgrade log files) as a medium to obtain newly added system upgrade information, the newly added system upgrade information needs to be formatted to meet the configuration requirements of the file format. In addition, when the newly added system upgrade information is subsequently used, it is also necessary to parse the newly added system upgrade information from the file format. In the first aspect, there is no need to write the newly added system upgrade information into the system upgrade log file, nor is there any need to parse the file subsequently. The electronic device can directly obtain the newly added system upgrade information.

[0013] As can be seen, in the first aspect, by performing a second merge operation on the electronic device after the second merge operation fails, the OUC can obtain the newly added system upgrade information during the merge process. Furthermore, there are no file format configuration requirements for the newly added system upgrade information, and there is no need to subsequently parse the format file to obtain the newly added system upgrade information. This solution allows for more efficient and convenient expansion of system upgrade information.

[0014] 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.

[0015] 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 new dotting position is run during the merge process, the new dotting data is generated, the OUC can directly obtain the new upgraded dotting data from the cache. In other words, the OUC obtains the upgrade dotting data through the cache as a medium. Compared with some solutions, the new dotting data is passed to the OUC using a file (such as a system upgrade record file) as a medium, and the new dotting data needs to be formatted to meet the configuration requirements of the file format; and, when the upgraded dotting data is subsequently used, the upgraded dotting data needs to be parsed from the file format. In this design, by using the cache as a medium, the upgraded dotting data does not need to be formatted, nor does it need to meet the configuration requirements of the file format; and, what the OUC obtains from the cache is relatively original data; the new dotting data does not need to be formatted, and the new dotting data can be passed to the OUC. At the same time, when the upgrade RBI data is used subsequently, there is no need to parse the upgrade RBI data from the file format, and the upgrade RBI data obtained by OUC from the cache can be used directly. At the same time, considering that OUC may be started during the merge process; and, during the merge process, the upgrade RBI data generated later will overwrite the upgrade RBI data generated earlier in the cache; that is, the upgrade RBI data in the cache will change; it can be seen that when OUC is started during the merge process, OUC may not obtain complete RBI data. Therefore, after OUC is started, performing the second merge operation can enable OUC to obtain the upgrade RBI data in the complete merge process; then OUC can obtain complete upgrade RBI data.

[0016] As can be seen, in this design approach, the OUC of the electronic device can easily add RBI bits and expand the upgrade RBI data by obtaining the upgrade RBI data from the cache. In addition, because the upgrade RBI data obtained by the OUC from the cache is relatively raw, there are no file format requirements and no need to parse the format file to obtain the upgrade RBI data, which will facilitate the subsequent use of the upgrade RBI data.

[0017] In a possible design of the first aspect, the above-mentioned 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 the merge operation.

[0018] In one 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) indicates a successful upgrade and does not include upgrade RBI data. In this design, since the upgrade result file does not include upgrade RBI data, the upgrade result and upgrade RBI data are separate and not in the same file. This makes the system upgrade information in the upgrade result file more concise and more convenient for subsequent use. When the electronic device only needs the upgrade results, it can directly obtain the upgrade results by searching the upgrade result file. Compared to some solutions, the system upgrade record file generated by the mobile phone contains both upgrade result information and upgrade RBI data, and the mobile phone needs to parse the upgrade record file and filter out the upgrade RBI data from the parsed system upgrade record file to extract the upgrade results. In this solution, there is no need to parse the upgrade record file containing both upgrade result information and upgrade RBI data. Only the upgrade result file needs to be parsed to directly obtain the upgrade results in the upgrade result file. In other words, the process of the mobile phone obtaining the upgrade result will not be interfered with by the upgrade dotting 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 dotting data, the electronic device can directly, accurately and efficiently obtain the system upgrade result, making it easier to use the system upgrade information.

[0019] 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, and the upgrade result file is used to indicate that the upgrade is successful, and the upgrade result file does not include upgrade dot data.

[0020] In one possible design of the first aspect, the method further includes: if the second merge operation is successful, then 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. Furthermore, the electronic device performing a third merge operation may include: if the OUC does not obtain the upgrade result file and the second merge operation fails, then the OUC instructs the upgrade engine in the electronic device to perform the third merge operation.

[0021] 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 above method also includes: if the electronic device fails to load the second operating system in the first static partition, then load the first operating system in the second static partition. 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 the system rollback file). The upgrade result file (system rollback file) is used to indicate that the operating system has been rolled back, and the upgrade result file does not include upgrade dotting data.

[0022] In this design, if a system rollback occurs on the electronic device, the electronic device will generate an upgrade result file when running with the first static partition. In this way, the upgrade result file can be used to obtain the fact that the system upgrade on the electronic device failed and a system rollback occurred.

[0023] In another possible design of the first aspect, the above-mentioned 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.

[0024] 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 completes starting the OUC, 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.

[0025] In this design, whether a merge operation is in progress is determined by dot data, merge data, or a preset interface, etc. It is very convenient to determine whether the electronic device is performing a merge operation.

[0026] In another possible design of the first aspect, the electronic device may further 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 obtained based on the upgrade result file.

[0027] 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. The electronic device can be, for example, a mobile phone, a personal computer, a tablet computer, or the like, an electronic device with an operating system. The method includes: the electronic device runs a fourth operating system. Next, the electronic device runs an upgrade installation package for a fifth operating system. Afterwards, the electronic device is shut down. 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 management data from the cache.

[0028] The method described in the second aspect takes into account that the OUC may be started during the merge process; and during the merge process, the later-generated upgrade RBI data will overwrite the earlier-generated upgrade RBI data in the cache; that is, the upgrade RBI data in the cache will change; thus, if the OUC is started during the merge process, the OUC may not obtain the complete RBI data. Therefore, after the OUC is started, the merge operation is performed, so that the OUC can obtain the upgrade RBI data during the complete merge process; thus, the OUC can obtain the complete upgrade RBI data.

[0029] In a third aspect, another method for obtaining system upgrade information is provided. This method can be applied to an electronic device with an operating system, and includes: the electronic device runs a first operating system. Next, the electronic device runs an upgrade installation package for a second operating system. Thereafter, the electronic device is powered off and then powered on. The electronic device then runs the second operating system. Thereafter, the electronic device performs a fourth merge operation; next, the electronic device launches an online upgrade client (OUC). If the fourth merge operation fails, the electronic device performs a fifth merge operation. During the fifth merge operation, the OUC of the electronic device retrieves upgrade management data from a cache.

[0030] In a possible design of the third aspect, the above 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 (such as an 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 RBI data. Alternatively, if the fifth merge operation fails, the electronic device saves the upgrade RBI 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 RBI data.

[0031] In another possible design of the third aspect, the OUC of the electronic device obtaining the upgrade RBI data from the cache may include: the OUC of the electronic device monitoring a target storage area in the cache, and if data changes (e.g., data modification, data addition, etc.) occur in the target storage area, then the OCU of the electronic device obtaining the upgrade RBI data from the target storage area. The target storage area is a storage area in the cache to which the upgrade RBI data is written by the electronic device during a merge operation.

[0032] In another possible design of the third aspect, after the electronic device completes the online upgrade client (OUC), if the electronic device determines that the fourth merge operation is being executed, the electronic device waits for the fourth merge operation to complete. Thereafter, if the fifth merge operation fails, the electronic device performs the fifth merge operation. The electronic device can determine that the fourth merge operation is being executed based on upgrade dot data, merge data, or a preset interface.

[0033] In another possible design of the third aspect, the electronic device may further 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 obtained based on the upgrade result file.

[0034] In a fourth aspect, an electronic device is provided, which includes a processor and a memory, the memory including 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 on 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.

[0035] 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 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.

[0036] In the sixth aspect, a computer program product containing instructions is provided. When the computer program product is run on an electronic device, it enables the electronic device to execute the method provided by the above-mentioned first aspect and any possible design of the first aspect; or, enables the electronic device to execute the method provided by the above-mentioned second aspect and any possible design of the second aspect; or, enables the electronic device to execute the method provided by the above-mentioned third aspect and any possible design of the third aspect.

[0037] 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

[0038] FIG1 is a schematic diagram of a usage scenario provided by an embodiment of the present application;

[0039] FIG2 is a schematic structural diagram of an electronic device provided in an embodiment of the present application;

[0040] FIG3 is a schematic diagram of a software structure of an electronic device provided in an embodiment of the present application;

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

[0042] FIG5 is a flow chart of a method for obtaining system upgrade information provided in an embodiment of the present application;

[0043] FIG6 is a schematic diagram of a process for upgrading an operating system according to an embodiment of the present application;

[0044] FIG7 is another schematic diagram of a process for upgrading an operating system according to an embodiment of the present application;

[0045] FIG8 is another schematic diagram of a process for upgrading an operating system according to an embodiment of the present application;

[0046] FIG9 is another schematic diagram of a process for upgrading an operating system according to an embodiment of the present application;

[0047] FIG10 is a schematic diagram of a process flow of a disk placement operation according to an embodiment of the present application;

[0048] FIG11 is another flowchart of a method for obtaining system upgrade information according to an embodiment of the present application;

[0049] FIG12 is another flowchart of a method for obtaining system upgrade information provided in an embodiment of the present application;

[0050] FIG13 is another structural diagram of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0051] 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 description of the association relationship of 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. In addition, 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 similar expressions refers to any combination of these items, including any combination of single 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, to facilitate the clear description of the technical solutions of the embodiments of the present application, in the embodiments of the present application, the words "first" and "second" are used to distinguish between identical or similar items with substantially the same functions and effects. Those skilled in the art will understand that the words "first" and "second" do not limit the quantity or execution order, and the words "first" and "second" do not necessarily mean different.

[0052] At the same time, in the embodiments of this 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 this application should not be interpreted as being more preferred or more advantageous than other embodiments or designs. Rather, the use of words such as "exemplary" or "for example" is intended to present the relevant concepts in a concrete manner to facilitate understanding.

[0053] 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, the electronic device is a mobile phone, which needs to be installed with a mobile phone operating system, such as the Apple Mobile Device Operating System (iOS). TM ), Android TM ) system, etc. before it can be used by users.

[0054] Before an electronic device leaves the factory, the electronic device supplier will burn the operating system into the electronic device, thereby achieving the installation of the operating system before the electronic device leaves the factory. Afterwards, the electronic device supplier may need to upgrade the operating system in the electronic device to improve the user experience.

[0055] Typically, during an operating system upgrade, an 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 dotting 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, the system upgrade information may be displayed 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 may diagnose and repair the operating system upgrade process of the electronic device based on the system upgrade information.

[0056] In some solutions, during an operating system upgrade, an electronic device can record system upgrade information in a file format; for example, in a system upgrade log file. Understandably, recording upgrade information in a file format involves certain file format configuration requirements, which can be complex. Furthermore, subsequent use requires parsing the file format, such as parsing the system upgrade log file, to retrieve the system upgrade information contained in the file.

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

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

[0059] 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 and 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 first parse the file format of the upgrade record file; then, from the parsed system upgrade record file, filter out the upgrade dotting data 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, 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 into the system upgrade record file will cause the process of the electronic device obtaining the upgrade results to be more cumbersome and time-consuming.

[0060] 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.

[0061] 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 a medium, that is, there is no file format parsing requirement for the upgrade management data, and the upgrade management data can be easily expanded.

[0062] 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.

[0063] For example, referring to FIG. 1 , electronic device 100 can receive a system upgrade package (hereinafter referred to as the upgrade package) sent to it by its supplier via Over-the-Air (OTA) technology. Subsequently, electronic device 100 upgrades the operating system on electronic device 100 based on the upgrade package. For example, electronic device 100 downloads a new version of the upgrade package via OTA technology; thereafter, electronic device 100 upgrades the old operating system to the new version. During the operating system upgrade process, electronic device 100 can obtain the breakpoint data generated during the operating system upgrade process based on pre-configured breakpoints. Furthermore, the electronic device can also obtain the upgrade results of electronic device 100 after the system upgrade is complete. In other words, electronic device 100 can obtain system upgrade information during the operating system upgrade process. Electronic device 100 can then send this system upgrade information to a server (e.g., the server of the supplier of electronic device 100) so that the supplier can optimize the upgrade package it releases based on this system upgrade information. Alternatively, the system upgrade information can be displayed to a user so that the user can understand the upgrade process of electronic device 100 and take appropriate actions (e.g., restarting electronic device 100).

[0064] It should be noted that in the scenario shown in FIG1 , the electronic device 100 may also obtain the upgrade package released by the electronic device supplier through a universal serial bus (USB) interface or a mobile storage device (e.g., 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.

[0065] 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 this application do not impose any restrictions on the specific types of electronic devices. Among them, the above-mentioned operating systems include but are not limited to Or other operating systems.

[0066] FIG2 shows a schematic diagram of the hardware structure of the electronic device 100 .

[0067] As shown in FIG2 , 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.

[0068] It should be understood that the structure illustrated in the embodiments 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, or may combine or separate certain components, or arrange the components differently. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

[0069] 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 processing unit (GPU), an image signal processor (ISP), a controller, a memory, a video codec, a digital signal processor (DSP), a baseband processor, and / or a neural-network processing unit (NPU). The different processing units may be independent devices or integrated into one or more processors.

[0070] 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.

[0071] Processor 110 may also include a memory for storing instructions and data. In some embodiments, the memory in processor 110 is a cache memory. This memory can store instructions or data that have just been used or are being recycled by processor 110. If processor 110 needs to use the same instruction or data again, it can directly access the memory. This avoids duplicate accesses, reduces processor 110 latency, and thus improves system efficiency.

[0072] The wireless communication module 150 can provide wireless communication solutions for application on 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.

[0073] Display screen 140 is used to display images, videos, etc. 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 (AMOLED), a flexible light-emitting diode (FLED), a MiniLED, a MicroLED, a Micro-oLed, or a quantum dot light-emitting diode (QLED).

[0074] 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 via the external memory interface 120 to implement data storage functions. For example, files such as music and videos can be stored on the external memory card.

[0075] 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.

[0076] The USB interface 130 is an interface that complies with USB standards and may be a Mini USB interface, a Micro USB interface, a USB Type-C interface, or the like. The USB interface 130 can be used to connect a charger to power the electronic device 100 and to transfer data between the electronic device 100 and peripheral devices. It can also be used to connect headphones to play audio. This interface can also be used to connect other electronic devices, such as augmented reality devices.

[0077] For example, the electronic device 100 can obtain the upgrade package through the wireless communication module 150 and the antenna, and write the upgrade package into the internal memory 121 or the external memory connected to the external memory interface 120. For another example, 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.

[0078] For example, the electronic device 100 can execute an 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 electronic device 100 supplier via the wireless communication module 150 and antenna, or via the USB interface 130. Alternatively, the electronic device can also display the system upgrade information to the user through the display screen 140.

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

[0080] It is understood that the software structure shown in FIG3 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 can also be divided into other layers, for example, into an application layer (which can be referred to as the application layer), an application framework layer, a system library layer, a kernel layer, etc. Different operating systems can also have different layer division methods. Technicians can specifically divide the operating system into different layers based on actual usage.

[0081] The application layer may include a series of application packages. As shown in Figure 3, the application package may include camera, gallery, calendar, call, map, navigation, WLAN, Bluetooth, music, video and other applications.

[0082] The application layer may further include a system upgrade application, such as an online update client (OUC).

[0083] For example, the electronic device can obtain the upgrade package through the OUC. Subsequently, the electronic device can also display the upgrade result to the user through the OUC.

[0084] The application framework layer provides an application programming interface (API) and programming framework for 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.

[0085] The system server is a process that provides many subsystem services. Each subsystem service runs as a thread, waiting for requests from applications, processing them, and returning the results to the applications. These subsystem services include, for example, the Window Manager Service (WMS), the Notification Manager Service (NMS), the Activity Manager Service (AMS), and the Input Manager Service (IMS).

[0086] 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 library (such as OpenGL ES), 2D graphics engine (such as SGL) and Android TM Runtime (Android TM runtime, ART).

[0087] The surface manager manages the display subsystem and provides fusion of 2D and 3D layers for multiple applications. The media library supports playback and recording of various common audio and video formats, as well as static image files. The media library supports a variety of audio and video encoding formats, such as MPEG4, H.264, MP3, AAC, AMR, JPG, and PNG. The 3D graphics processing library implements 3D graphics drawing, image rendering, compositing, and layer processing. The 2D graphics engine is the drawing engine for 2D drawing.

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

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

[0090] The application layer and application framework layer run in a virtual machine. The virtual machine executes Java files in the application layer and application framework layer as binary files. The virtual machine manages object lifecycles, stack management, thread management, security and exception management, and garbage collection.

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

[0092] The kernel driver layer, also known as the core layer, is the layer between hardware and software. The kernel layer includes at least display drivers, camera drivers, audio drivers, and sensor drivers.

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

[0094] Android TM Taking the system as an example, Figure 4 shows a schematic diagram of a data storage structure provided according to an embodiment of the present application. As shown in Figure 4, 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).

[0095] The user data partition (userdata) is used to store the user's personal data, such as apps installed by the user, and personal photos, documents, and videos saved by the user. The data stored in the basic partition is system data that is not included in operating system upgrades. The structures of the static partition (A) and the static partition (B) correspond to each other, and the subpartition names are distinguished by the suffixes _a and _b. For example, the static partition (A) includes: boot_a, vendor_boot_a, dtbo_a, and vbmeta_a; the static partition (B) includes: boot_b, vendor_boot_b, dtbo_b, and vbmeta_b. The dynamic partition (Super) contains multiple subpartitions. For example, the S1 partition records A1 data, the S2 partition records B1 data, the S3 partition records C1 data, the S4 partition records D1 data, the S5 partition records E1 data, and the S6 partition records F1 data. It is understood that when an electronic device upgrades its operating system, the files (data) in the static and dynamic partitions need to be upgraded, while the files in the basic partition and user data partition do not need to be upgraded.

[0096] When an electronic device boots up, it starts from a static partition. For example, if an electronic device boots from static partition (A), it will load the base partition (common), static partition (A), and dynamic partition (super) in sequence. Another example is if an electronic device boots from static partition (B), it will load the base partition (common), static partition (B), and dynamic partition (super) in sequence.

[0097] 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, that is, cylinder 0, head 0, sector 1 of the C / H / S address), a description of the device boot sequence (for example, the mobile phone boot sequence) is stored. 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 the UFS. And each data partition is started (loaded) in sequence according to the read device boot sequence. The MBR is usually recorded in the base partition (common). Of course, in different platforms, the MBR can also be recorded in different locations, and the embodiments of the present application do not specifically limit this.

[0098] It is understood that the data partition division method shown in FIG4 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 specific division method of the data storage partitions of the electronic device 100 can be designed according to actual usage, and the embodiments of the present application do not impose any limitations on this.

[0099] Below, the technical solution provided in the embodiment of the present application will be introduced by taking the usage scenario shown in Figure 1 where the electronic device 100 is a mobile phone as an example.

[0100] Assuming that the mobile phone is currently running an old version of the operating system (e.g., version 1.1) and needs to be upgraded to a new version of the operating system (e.g., version 1.2), the mobile phone can upgrade the operating system according to the process shown in Figure 5 and obtain system upgrade information.

[0101] For example, referring to FIG. 5 , the method for obtaining system upgrade information provided in an embodiment of the present application may include steps S500 - S512 .

[0102] 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.

[0103] For example, referring to Figure 6, the mobile phone can sequentially load the basic partition (common), static partition (A), dynamic partition, and user data partition to boot from the static partition (A). In other words, the mobile phone starts running with the old version of the operating system, that is, version 1.1 of the operating system.

[0104] Understandably, since the phone hasn't yet received the upgrade package, the phone's static partition (A), static partition (B), and dynamic partition should store an older version of the operating system, such as version 1.1. Since both static partition (A) and static partition (B) contain older versions of the operating system, the phone can also boot version 1.1 using static partition (B). For ease of description, the following example uses a phone booting and running version 1.1 using static partition (A) as an example.

[0105] S501.OUC obtains the upgrade package.

[0106] 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 for 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 an upgrade package for a new version of the operating system exists, 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.

[0107] 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 that contains the full data of version 1.2. The differential system upgrade package can be understood as a system upgrade package that contains 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 can refer to a system upgrade package that includes A2, B1, C1, D2, E1 and F1. The differential system upgrade package can refer to a system upgrade package that includes 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.

[0108] 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 specific method for the OUC to obtain the upgrade package can be designed according to actual usage needs, and the embodiments of the present application do not impose any restrictions on this.

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

[0110] Understandably, since the phone is currently running, it cannot modify files in use in the data partition. That is, if the phone is booted from static partition (A), the upgrade engine can write the upgrade package containing version 1.2 of the static partition data to static partition (B). If the phone is booted from static partition (B), the upgrade engine can write the upgrade package containing version 1.2 of the static partition data to static partition (A).

[0111] 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.

[0112] Afterwards, the upgrade engine modifies the phone's boot sequence. It is understood that the phone's boot sequence refers to the order in which the phone boots (loads) data partitions.

[0113] For example, the OUC can instruct the upgrade engine (update_engine) to perform the virtual A / B installation by calling the mutipayloads interface. After the virtual A / B installation is completed, the update_engine calls back the virtual A / B installation result (e.g., virtual A / B installation success, or virtual A / B installation success failure) to the OUC through the mutipayloads interface.

[0114] In some embodiments, referring to FIG. 7 , the above step S502 may include steps S5021 - S5023 .

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

[0116] For example, referring to FIG8 , 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 overwrites 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.

[0117] 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 limit this.

[0118] 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.

[0119] 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.

[0120] In some embodiments, when the upgrade engine performs a virtual A / B installation, if a differential upgrade 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 files of the upgraded dynamic partition (super), but rather the updated data of the old dynamic partition (super) that needs to be upgraded. In other words, the virtual dynamic partition of the user data partition (userdata) stores the upgraded data of the dynamic partition (super).

[0121] In some embodiments, during the virtual A / B installation performed by the upgrade engine, 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 (userdata), 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 files in the dynamic partition through the snapshot to load the virtual dynamic partition.

[0122] For example, refer again to Figure 8. Assume that, compared to version 1.1, version 1.2 only updates data A1 in the dynamic partition (super) S1 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 the dynamic partition S1 is A1, and the data in the dynamic partition S4 is D1; ​​whereas in version 1.2, the data in the dynamic partition S1 is A2, and the data in the dynamic partition S4 is D2.

[0123] Based on this, when the upgrade engine creates virtual dynamic partitions in the user data partition, to save space in the user data partition, it can only create virtual dynamic partitions for dynamic partitions S1 and S4 in the user data partition. It also sets the address of data A2 to S1-1, which corresponds to address S1 of A1; and sets the address of data D2 to S4-1, which corresponds to address S4 of D1. Later, when using version 1.2, it loads A2, B1, C1, D2, E1, and F1 from the snapshot to run the version 1.2 operating system.

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

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

[0126] In some embodiments, the above step S5023 may further include: an update engine modifying a card slot.

[0127] 8 , the basic partition or static partition may include slot 0 corresponding to static partition (A) and slot 1 corresponding to static partition (B). Slot 0 and slot 1 are used to store the partition table of the super partition.

[0128] 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, it chooses to obtain the partition information of the super partition from one of slot0 or slot1. Taking the phone currently booting 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, loading the dynamic partition in the manner of loading S1, S2, S3, S4, S5, and S6). When the phone is booted from the 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, loading the dynamic partition in the manner of loading S1-1, S2, S3, S4-1, S5, and S6).

[0129] S503. The phone restarts.

[0130] In some embodiments, after the upgrade engine completes the virtual A / B installation in step S510 (e.g., after the phone's boot sequence is modified), the system server on the phone can instruct the phone to power off and exit the current operating system. The phone can then be powered on again.

[0131] In some embodiments, at step S520, the phone does not need to be restarted immediately; the user can select the restart time. This allows the operating system upgrade process to not affect the user's normal phone operations, thereby significantly improving the user experience. For example, the phone can notify the user via a pop-up window or notification message that the virtual A / B installation on the phone has been completed. Subsequently, the phone will restart in response to the user's restart operation.

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

[0133] In some embodiments, a bootloader on a mobile phone can load the basic partition and the static partition (B). 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 a snapshot based on slot 1 for loading.

[0134] Among them, loading a bootloader can be a code program solidified on the mobile phone processor, through which the data partition can be loaded, and the functional modules in different software architecture layers of the mobile phone can be loaded in sequence; so as to realize the startup of the mobile phone and enable the mobile phone to 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 operating system kernel) loads the functional modules in the local layer (such as upgrade engine, display manager, etc.). Next, the kernel layer (such as 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 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 the OUC.

[0135] For example, referring to Figure 9, it is assumed that the slot is in the basic partition of the mobile phone. The bootloader reads the boot sequence identifier in the MBR. For example, it is read that the mobile phone starts from the static partition (B). After that, the bootloader loads the basic partition and reads slot1 from the loaded basic 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.

[0136] For example, after the bootloader loads the data partition and loads and starts the functional modules in the software architecture layer, the phone will enter the user interface. At this time, the phone's boot flag is "boot successful." For example, the value of boot_complete is 1.

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

[0138] In some embodiments, the bootloader can record the number of times the phone boots from the static partition (B). If the bootloader finds that the number of times the phone boots from the static partition (B) is greater than or equal to a preset threshold (e.g., 3 or 5 times), and that the boot from the static partition (B) is unsuccessful, the bootloader will perform a system rollback and boot from the static partition (A). In other words, the bootloader sequentially loads the following: base partition, static partition (A), dynamic partition (super), and user data partition. This way, the phone boots from the operating system corresponding to the static partition (A) (e.g., version 1.1 of the operating system).

[0139] It is understandable that when the mobile phone starts with the static partition (B), it may fail to start with the static partition (B) due to various reasons, which means that the mobile phone cannot run the version 1.2 operating system. Therefore, after the mobile phone tries to start with the static partition (B) 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 was not 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.

[0140] 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.

[0141] Exemplarily, the bootloader can be completed after the mobile phone is started with the 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 failed (the virtual A / B installation failed) and the operating system rolled back. In addition, since the virtual A / B installation of the mobile phone failed, 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.

[0142] 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 "50" on the upgrade result flag may indicate that a system rollback has occurred on the mobile phone operating system. That is, in some embodiments, if a system rollback occurs on the mobile phone, the bootloader will set the value of the upgrade result flag to "50" to indicate that a system rollback has occurred on the mobile phone.

[0143] In some embodiments, after being started, the update engine may 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.

[0144] Understandably, if a system rollback occurs on a phone running in static partition (A), the boot loader will generate an upgrade result file (which includes the system rollback information). Since the phone runs the update engine in static partition (A), it will not perform a merge and will not generate upgrade management data. Therefore, the OUC can subsequently obtain information from the upgrade result file that the virtual A / B upgrade on the phone was unsuccessful and a system rollback occurred.

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

[0146] In some embodiments, after the system server is loaded and successfully started, the system server may search for the phone's startup flag. If the search indicates that the phone's startup flag indicates successful startup, the system server instructs the update engine and OUC to start, causing the update engine to perform a merge operation.

[0147] Breakpoints, also known as tracking points, are defined as adding breakpoints during program execution, pausing the program and then outputting the data generated when the program reached the breakpoint. For example, when the update engine is merging, if it reaches a preset breakpoint, it will pause the merge and output the upgrade breakpoint data.

[0148] In this embodiment, after the update engine is started, the update engine will check 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 perform a merge operation.

[0149] For example, the metadata partition ( / metadata) of the base partition (common) can record the flush status information. This flush status information can include "flush (merged)" or "not flushed (waiting for merge)". The flush status information is used to indicate whether there are COW files in the current user data partition that need to be flushed to the dynamic partition (super).

[0150] Specifically, the flush status information includes the overall identifier for the dynamic partition (super) and the subpartition identifier for each subpartition. When the overall identifier is "merged," all subpartitions of the dynamic partition (super) do not need to be flushed. When the overall identifier is "wait for merge," one or more subpartitions of the dynamic partition (super) need to be flushed. When the subpartition identifier is "merged," no flush is required. When the subpartition identifier is "wait for merge," flush is required.

[0151] If the update engine determines through the above disk flushing 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.

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

[0153] It is understood that the update engine can trigger the merge operation when the update engine successfully starts. That is, after the update engine successfully starts, the update engine will check the disk status information and perform the merge operation based on the disk status information. It is understood that the update engine can actively perform the merge operation after the update engine successfully starts.

[0154] In some embodiments, the above-mentioned disk write operation refers to 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) during the operating system upgrade process, 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 complete the startup by loading the dynamic partition (super).

[0155] Exemplarily, the update engine writes the upgraded data in the COW file in the userdata partition to the corresponding address in the dynamic partition (super), so that all data in the dynamic partition (super) is the upgraded version of the data. Subsequently, after the merge operation is successful, the update engine deletes the COW file in the userdata partition and returns the storage space to the userdata partition; and changes the flush status information in the metadata ( / metadata) of the base partition (common) from "not flushed to disk (wait for merge)" to "flushed to disk (merged)".

[0156] For example, see Figure 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 to 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 to D1 in address S4, that is, modify D1 in the dynamic partition (super) to D2.

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

[0158] For example, during the merge process, if the upgrade engine reaches a preset checkpoint, the upgrade engine will pause the merge process. After the merge process is paused, the upgrade engine reads the merge data (e.g., variable values, upgrade file location, upgrade file integrity, file checksum, upgrade file status, etc.) from the merge process, generates upgrade checkpoint data based on the merge data, and stores the upgrade checkpoint data in a cache. The OUC can then retrieve the upgrade checkpoint data from the cache.

[0159] In some embodiments, during the update engine's merge process, later-generated update RBI data will overwrite earlier-generated update RBI data. For example, if a piece of update RBI data is a file checksum, the update engine will overwrite the later-generated checksum over the earlier-generated checksum. This means that the earlier-generated checksum is deleted from the cache.

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

[0161] 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 "0" for the upgrade result flag may indicate that the mobile phone operating system upgrade is successful. 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.

[0162] It's important to note that if the update engine successfully executes a merge, the update result file generated by the update engine only includes the upgrade success information and does not include the upgrade RBI data. Furthermore, since the OUC obtains the upgrade RBI data from the cache, while the upgrade result file is obtained as a file, the upgrade RBI data and the upgrade result information are separate.

[0163] 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 upgrade management data included in the upgrade result file are separated and will not be mixed together.

[0164] Compared to 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, which requires parsing the system upgrade file and extracting it 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 upgrade success 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 later; when the mobile phone only needs the upgrade result, it can directly obtain the upgrade result by searching the upgrade result file, without being affected by the upgrade dotting data. In addition, compared to 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, which requires parsing the upgrade record file and filtering 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 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.

[0165] It can be seen that in the method provided in the embodiment of the present application, by separating the upgrade results and the upgrade record 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.

[0166] In some embodiments, the mobile phone can further separate the upgrade result file containing the upgrade success information from the upgrade result file containing the system rollback information. For example, the upgrade result file and the system rollback file can be separated, with the upgrade success file recording the upgrade success information and the system rollback file recording the system rollback information. This can also streamline the information in the upgrade result file.

[0167] 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).

[0168] In some embodiments, after the update engine successfully executes the merge operation, the update engine can clear the installed files, for example, by deleting the virtual dynamic partition in the user data partition. This allows the phone to run with the updated, complete operating system (e.g., version 1.2).

[0169] For example, after the update engine successfully executes the merge operation, the update engine will delete the COW file in the user data partition. It should be noted that after the update engine fails to execute the merge operation, the update engine does not clear the installation files. Since the merge fails at this time, the mobile phone's super does not have the 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, making it impossible for the mobile phone to run the version 1.2 operating system normally.

[0170] S507. After the OUC is successfully started, the OUC obtains the upgrade result file. If the OUC does not obtain the upgrade result file, the process proceeds to S508; if the OUC obtains the upgrade result file, the process proceeds to S512.

[0171] In some embodiments, the OUC may attempt to obtain an upgrade result file. If the OUC obtains the upgrade result file, the OUC may know that the update engine on the phone has completed the merge and the merge was successful, and the system upgrade is successful. In other words, the update engine on the phone is not in the process of merging.

[0172] In this way, after the OUC obtains the upgrade result file, the OUC can prompt the mobile phone's operating system upgrade success based on the upgrade result file; or send the upgrade result file to the server, etc.

[0173] 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 but failed. Next, the OUC can determine whether the update engine is merging or has completed the merge.

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

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

[0176] For example, the process of OUC obtaining the RBI data generated by the update engine during the merge process through the cleanupsuccful interface can be understood as follows: OUC monitors the location in the cache where the update engine writes the upgraded RBI 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 changes; then OUC obtains the upgraded RBI data from that location in the cache.

[0177] Based on the above analysis, if the update engine is merging, it will output RBI data to the cache. This means that the update RBI data will be stored in the cache. If the update engine completes the merge, it will exit, releasing the memory used by the update engine. This means that the update RBI data will no longer be stored in the cache. Based on this, the OUC can determine whether the update engine is merging by obtaining the update RBI data.

[0178] 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.

[0179] 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 merges and ends the merge, these data will be deleted by the update engine. Based on this, the 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 obtained through the search, the OUC determines that the update engine is merging; if the file verification data is not obtained through the search, the OUC determines that the update engine has ended the merge.

[0180] In some embodiments, the OUC can also determine whether the update engine is merging by using data returned by a preset interface (e.g., a running interface). In this way, it is also possible to more conveniently determine whether the electronic device is performing a merge operation.

[0181] 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.

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

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

[0184] Table 1

[0185] S509. The upgrade engine is performing a merge operation, and the OUC waits 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. The OUC instructs the update engine to perform a merge operation.

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

[0188] Exemplarily, the OUC may send a write-to-disk 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. In response to receiving the merge start message, the system server may send a merge instruction to the update 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, a system service may instruct 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, the update engine is at a lower level compared to OUC. In other words, the startup of OUC is more complicated than that of the update engine, and requires more resources (such as processes and services that OUC depends on). Therefore, the startup time of OUC will be later than the startup time of the update engine. In other words, after the mobile phone successfully starts with the static partition (B), the update engine on the mobile phone will start before OUC. In addition, 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 starts successfully, the update engine may be merging or the merge may have been completed (such as the merge is successful or the merge fails).

[0192] In addition, since the update engine writes the upgrade RBI data into the cache, that is, the cache will be requested by the update engine. Based on this, when the update engine's merge process ends, the data in the cache will be cleared. It can be seen that if the update engine's merge process ends, OUC cannot obtain the upgrade RBI data. In addition, since the cache space on the mobile phone is relatively valuable, 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 update engine's merge, 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 in S509 fails), 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 beginning 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] As can be seen from this, since the OUC will not be started before the update engine performs a merge; and during the process of the update engine performing a merge, the update engine will update the upgrade RBI data in the cache. Based on this, when the update engine performs a merge for the first time (such as in the above step S506b), the OUC may not be able to obtain the complete upgrade RBI data from the cache. Therefore, the 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, the OUC can obtain the complete upgrade RBI data generated by the update engine from the cache.

[0195] S511. During the process of performing the merge operation on the update engine, the OUC obtains the update 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 step S509.

[0198] During the merge operation, the update engine can generate and output the updated RBI data through the cache based on the RBI bits, which can include preset RBI bits and expandable RBI bits.

[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] As shown in Figure 11, the update engine can first read A2 from the COW file and calculate its hash value (e.g., hash_A2). After calculating the hash value of A2, the update engine executes to the cache bit 1. The update engine uses the hash value of A2 as the update data and writes it to the cache. Afterwards, the update engine overwrites A2 from the COW file to the corresponding location of A2 in the super file (e.g., S1).

[0201] Next, referring again to Figure 11, after the update engine completes overwriting A2, it reads D2 from the COW file and calculates D2's hash value (e.g., hash_D2). After calculating D2's hash value, the update engine executes to RBI bit 2 and writes D2's hash value into the cache as the updated RBI data. The update engine then overwrites D2 from the COW file to the corresponding location in super (e.g., S4).

[0202] Afterwards, as shown in Figure 11, after D2 is overwritten, the update engine calculates the hash value of the updated file in super. After the hash value calculation is completed, the update engine executes to the cache bit 3. The update engine reads the hash value of the updated file in super (e.g., hash_super) and writes the hash value of the updated file in super as the upgrade cache data.

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

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

[0205] In this embodiment of the present application, the upgrade RBI data obtained by the OUC is directly obtained from the cache. If the mobile phone needs to add a new RBI location during the merge process, the update engine generates the new RBI data when it encounters the new RBI location during the merge process. The update engine can directly pass the new upgrade RBI 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 the OUC. The update engine needs to format 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, the cache is used as a medium, and there is no need to format the upgraded RBI data or meet the configuration requirements of the file format; OUC obtains relatively original data from the cache; the update engine does not need to format the newly added RBI data and can pass the newly added RBI data to the 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] As can be seen, the system upgrade information acquisition method provided in the embodiment of the present application, which obtains upgrade RBI data from the cache through the OUC, can easily add RBI bits and conveniently expand the system upgrade information (e.g., the upgrade RBI data). In addition, since the upgrade RBI data obtained by the OUC from the cache is relatively original upgrade RBI data, there are no file format requirements and no need to parse a format file to obtain the upgrade RBI data, which will facilitate the subsequent use of the upgrade RBI data.

[0208] S512.OUC saves the upgrade result file or 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. In this way, the server may be informed of 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, users using the mobile phone can know the upgrade status of the mobile phone operating system, which can improve the user experience.

[0211] For example, after obtaining the upgrade result file, the OUC can parse the contents of the file. If the file contains information indicating a successful upgrade, the OUC can notify the user that the operating system upgrade was successful. If the file contains information indicating a system rollback, the OUC can notify the user that the operating system upgrade failed and a system rollback occurred. This allows the user to be aware of the upgrade results of the operating system on their phone, thereby improving the user experience. The OUC can notify the user in ways that include, but are not limited to, displaying a notification message, displaying a pop-up window, playing a prompt tone, and so on.

[0212] In some embodiments, the OUC can repair the merge process of the update engine based on the upgrade RBI data. Assume that the upgrade RBI 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 search package server to request the search package 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 can send an upgrade result file to a server (e.g., the aforementioned search server, or the server of the mobile phone vendor). The server can then obtain the operating system upgrade results on the mobile phone and subsequently optimize the upgrade package based on the operating system upgrade results.

[0216] In some embodiments, the OUC can send upgrade RBI data to the server; in this way, the server can analyze the reason for the mobile phone merge failure 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 RBI data, the OUC may also delete the upgrade RBI data or the upgrade result file, thereby saving 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 embodiments 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.

[0220] In addition, the expandable marking bits (new marking bits) may include one or more of the following: read status marking bit, get merge table marking bit, unknown table marking bit, unknown target type marking bit, unmerged sectors after completion marking bit, unexpected merge state marking bit, etc.

[0221] 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, no upgrade dotting data is generated. Exemplarily, the update engine is 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 is stored in the cache as upgrade dotting data.

[0222] This can reduce the amount of update data generated by the update engine. Furthermore, since, in the embodiment of the present application, the update data generated by the update engine is stored in the mobile phone's cache, reducing the amount of update data generated by the update engine can reduce the cache usage on the mobile phone.

[0223] In other embodiments, when the update engine reaches a dot position and determines that the merged data belongs to an abnormal branch and generates updated dot data, it also generates a result corresponding to the dot position (e.g., an abnormal result) and stores the abnormal result in a cache.

[0224] 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, the update engine determines that the merge data (the COW file is read) belongs to the normal branch of the mark position, then 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, the update engine determines that the merge data (the COW file is not read) belongs to the abnormal branch of the mark position, then 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.).

[0225] As another example, assume that during the merge process, the update engine determines whether the COW file in the user data partition is flushed to the corresponding position in the dynamic partition; thereafter, 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., comparing the files in S1 and S1-1 in FIG10 ; or, comparing the files in S4 and S4-1 in FIG10 ). If 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 an abnormal branch of the flush position, then the update engine generates upgrade flush 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 a normal branch of the flush position, then the update engine does not generate upgrade flush data, and continues to execute the subsequent merge process.

[0226] In the embodiment corresponding to FIG5 , the upgrade engine searches for disk-flush status information after successful startup and performs a merge operation based on the disk-flush status information. However, in some scenarios, the upgrade engine's merge operation may not be triggered by successful startup; instead, the merge operation may be triggered by receiving a disk-flush instruction. In other words, in these scenarios, after successful startup, the upgrade engine may not actively perform a merge operation, but may passively perform the merge operation (e.g., in response to receiving a disk-flush instruction).

[0227] In this way, when the update engine performs a merge, the OUC can obtain the upgrade result file or upgrade management data, which can also make the upgrade process of the operating system on the mobile phone more concise.

[0228] Specifically, referring to FIG. 12 , in this scenario, the system upgrade information acquisition method provided in the embodiment of the present application may include steps S1200 - S1211 .

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

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

[0231] Next, if the phone fails to run with version 1.2, that is, if the phone fails to boot with the new system, the bootloader will execute step S1205a to implement a system rollback. After the system rollback occurs, that is, after the phone successfully boots with the old version (e.g., version 1.1), the update engine can execute S1206a to generate an upgrade result file that includes the system rollback information. Specifically, steps S1205a and S1206a can refer to steps S505a and S506a above.

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

[0233] If the phone successfully runs version 1.2, that is, the phone successfully starts with the new system; the system server can start the update engine and OUC.

[0234] In this scenario, after the update engine successfully starts, it waits for the instruction to write to disk before performing the merge operation. This allows the update engine to perform a complete merge operation after the OUC is started. In this way, even if the OUC starts later than the update engine, the update engine can still perform the complete merge process after the OUC starts, so that the OUC can obtain the complete dot data generated by the update engine during the merge process.

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

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

[0237] Among them, the disk drop instruction can also be called a disk drop instruction, a merge instruction, etc.; in some embodiments, the disk drop instruction can be a preset string, and the OUC can send the disk drop instruction to the update engine through a preset communication interface between the update engine and the update engine.

[0238] 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. In response to receiving the merge start message, the system server may send a merge instruction to the update engine to trigger the update engine to perform a merge operation.

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

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

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

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

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

[0244] 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.

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

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

[0247] In some scenarios, an electronic device may also upgrade its operating system multiple times. For example, upgrading from version 1.1 to version 1.2, and then upgrading from version 1.2 to version 1.3. It is understood that the process of upgrading from version 1.2 to version 1.3 is similar to the process of upgrading from version 1.1 to version 1.2, as described above. This will not be repeated here.

[0248] Below, 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.

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

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

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

[0252] 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.

[0253] 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.

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

[0255] Afterwards, the electronic device is powered off and then powered on. Next, the electronic device runs the third operating system. For example, this process can refer to the description of steps S503 and S504 above. The third operating system can be version 1.3.

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

[0257] 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.

[0258] 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 be generated based on the dotting bits during the electronic device's execution of the merge operation. Furthermore, the merge operation (e.g., the first merge operation, the second merge operation, or the third merge operation) may include writing the upgrade file stored in the virtual dynamic partition (in the user data partition) of the electronic device to the dynamic partition of the electronic device.

[0259] In this embodiment, the 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 the 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 another merge operation, that is, performs a third merge operation. In this way, after the OUC is started, the electronic device can perform the complete merge operation process. Then, the OUC can obtain complete system upgrade information during the merge process without having to parse the file format and then obtain the system upgrade information from the file. It can be seen that this method can obtain system upgrade information conveniently, efficiently, and directly.

[0260] In other embodiments, the present application further provides a method for obtaining system upgrade information. In this method, an electronic device runs a fourth operating system. Next, the electronic device runs an upgrade installation package for a fifth operating system. Thereafter, the electronic device is shut down. Next, the electronic device is turned on. Then, the electronic device runs the fifth operating system. For example, this process can be described in the relevant description of steps S1200-S1204 above.

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

[0262] 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.

[0263] During the process of the electronic device executing the merge operation, the OUC obtains the upgrade management data from the cache. This process can be seen in the description of step S1208 above.

[0264] 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 this application.

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

[0266] An embodiment of the present application further provides an electronic device, as shown in FIG13 , which may include one or more processors 1001 , a memory 1002 , and a communication interface 1003 .

[0267] 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.

[0268] The communication interface 1003 is used to transmit data 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.

[0269] The processor 1001 may be a processor or a controller, such as a central processing unit (CPU), a general-purpose 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 may implement or execute the various exemplary logic blocks, modules, and circuits described in conjunction with the present disclosure. The processor may also be a combination that implements computing functions, such as a combination of one or more microprocessors, a combination of a DSP and a microprocessor, and the like.

[0270] 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 illustration, FIG13 shows only one thick line, but this does not mean that there is only one bus or only one type of bus.

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

[0272] An embodiment of the present application further provides a computer program product, which, when executed on a computer, enables the computer to execute the relevant method steps in the above method embodiment.

[0273] 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.

[0274] 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.

[0275] In the several embodiments provided in this 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 merely schematic. For example, the division of the modules or units is merely a logical function division. In actual implementation, there may be other division methods, 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.

[0276] The units described as separate components may or may not be physically separate, 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 places. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

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

[0278] 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 contributing part 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 and includes several instructions for enabling a device (which can be a single-chip microcomputer, chip, etc.) or a processor to execute all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes various media that can store program codes, such as a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk.

[0279] The above content is only a specific embodiment of this application, but the scope of protection of this application is not limited to this. Any changes or replacements within the technical scope disclosed in this application should be included in the scope of protection of this application. Therefore, the scope of protection of this application should be based on the scope of protection 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