System upgrading method and device, electronic equipment and storage medium

Abstract

The invention relates to a system upgrading method and device, electronic equipment and a storage medium. The system upgrading method comprises the steps that in response to power failure and power-on restart of the electronic equipment in the system upgrading process, whether a boot loader meets a first verification condition or not is checked, and the boot loader is stored in a first partition and a first partition backup partition; in response to the fact that the boot loader meets a first verification condition, whether target data meets a second verification condition or not is checked, the target data is stored in a second partition and a second partition backup partition, and the second partition backup partition is generated when a system upgrading instruction is received; and executing system upgrading in response to the condition that the target data meets the second verification condition. Through the method and the device, the boot loading operation can be performed based on the backup partition of the first partition, and partition verification can be performed based on the backup partition of the second partition, so that the risk that the system cannot be started is reduced.

Description

Technical Field

[0001] This disclosure relates to the field of software updates, and in particular to system upgrade methods, apparatus, electronic devices, and storage media. Background Technology

[0002] Over-the-Air (OTA) technology is a standard software upgrade method provided by the Android system. Currently, there are two OTA upgrade methods for Android: Recovery system upgrade and A / B (A / B) system upgrade.

[0003] A Recovery system upgrade refers to a device having both an Android main system and a Recovery system. The Android main system checks if an upgrade is needed. If so, it downloads the upgrade data package and stores it in the data partition. After rebooting, the Recovery system updates the Android main system with the data downloaded to the data partition. Once the update is complete, the device reboots back into the Android main system.

[0004] If the device is powered off during the Recovery system upgrade process, the data in a specific partition may be corrupted, causing the device's system to fail to boot. Summary of the Invention

[0005] To overcome the problems existing in related technologies, this disclosure provides a system upgrade method, apparatus, electronic device, and storage medium.

[0006] According to a first aspect of the present disclosure, a system upgrade method is provided, comprising: in response to a power outage and power-on restart of an electronic device during a system upgrade process, checking whether a bootloader meets a first verification condition, wherein the bootloader is stored in a first partition and a first partition backup partition; in response to the bootloader meeting the first verification condition, checking whether target data meets a second verification condition, wherein the target data is stored in a second partition and a second partition backup partition, wherein the second partition backup partition is generated upon receiving a system upgrade instruction; and in response to the target data meeting the second verification condition, performing a system upgrade.

[0007] In one embodiment, checking that the bootloader meets the first verification condition includes: in response to the completeness of the bootloader's content, performing a boot loading operation using the bootloader in the first partition to determine that the bootloader meets the first verification condition; or in response to the incompleteness of the bootloader's content, performing a boot loading operation using the bootloader in the backup partition of the first partition to determine that the bootloader meets the first verification condition.

[0008] In one embodiment, checking that the target data meets the second verification condition includes: determining that the target data meets the second verification condition in response to a successful partition verification based on the target data in the second partition; and determining that the target data meets the second verification condition in response to a failed partition verification based on the target data in the backup partition of the second partition.

[0009] In one embodiment, the method further includes: in response to the electronic device receiving a system upgrade instruction, backing up the target data in the second partition to the backup partition of the second partition.

[0010] In one embodiment, the first partition backup partition is a newly added partition in the system partition; the second partition backup partition is set in the data cache partition in the system partition.

[0011] In one embodiment, the second partition includes at least one of the following: a boot partition; a device tree overlay partition; and a system verification metadata partition.

[0012] According to a second aspect of the present disclosure, a system upgrade apparatus is provided, including a processing unit configured to, in response to a power outage and power-on restart of an electronic device during a system upgrade process, check whether a bootloader meets a first verification condition, the bootloader being stored in a first partition and a first partition backup partition; in response to the bootloader meeting the first verification condition, check whether target data meets a second verification condition, the target data being stored in a second partition and a second partition backup partition, the second partition backup partition being generated upon receiving a system upgrade instruction; and an execution unit configured to, in response to the target data meeting the second verification condition, execute a system upgrade.

[0013] In one embodiment, the processing unit checks whether the bootloader meets the first verification condition in the following manner: in response to the completeness of the bootloader content, it performs a boot loading operation using the bootloader in the first partition to determine that the bootloader meets the first verification condition; or in response to the incompleteness of the bootloader content, it performs a boot loading operation using the bootloader in the backup partition of the first partition to determine that the bootloader meets the first verification condition.

[0014] In one embodiment, the processing unit checks whether the target data meets the second verification condition in the following manner: in response to the successful partition verification based on the target data in the second partition, it determines that the target data meets the second verification condition; in response to the failed partition verification based on the target data in the second partition, it performs a partition verification based on the target data in the backup partition of the second partition, and if the verification passes, it determines that the target data meets the second verification condition.

[0015] In one embodiment, the processing unit is further configured to: in response to the electronic device receiving a system upgrade instruction, back up the target data in the second partition to the backup partition of the second partition.

[0016] In one embodiment, the first partition backup partition is a newly added partition in the system partition; the second partition backup partition is set in the data cache partition in the system partition.

[0017] In one embodiment, the second partition includes at least one of the following: a boot partition; a device tree overlay partition; and a system verification metadata partition.

[0018] According to a third aspect of the present disclosure, an electronic device is provided, comprising: a processor; a memory for storing processor-executable instructions; wherein the processor is configured to: execute the system upgrade method described in the first aspect or any embodiment of the first aspect.

[0019] According to a fourth aspect of the present disclosure, a storage medium is provided, the storage medium storing instructions that, when executed by a processor, enable the processor to perform the system upgrade method described in the first aspect or any embodiment of the first aspect.

[0020] The technical solutions provided by the embodiments of this disclosure can include the following beneficial effects: In response to a power outage during a system upgrade of an electronic device, and after the system is powered on and restarted, the system checks whether the bootloader meets the first verification condition. The bootloader is stored in the first partition or a backup partition of the first partition; using the bootloader from one of these partitions ensures the integrity and correctness of the bootloader, effectively preventing system boot failures due to bootloader corruption. In response to the bootloader meeting the first verification condition, the system checks whether the target data meets the second verification condition. The target data is stored in the second partition or a backup partition of the second partition; using the target data from one of these partitions for partition verification improves the security of the target data. In response to meeting the second verification condition, the system upgrade is performed, preventing system boot failures and improving the user experience.

[0021] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit this disclosure. Attached Figure Description

[0022] The accompanying drawings, which are incorporated in and form a part of this specification, illustrate embodiments consistent with this disclosure and, together with the description, serve to explain the principles of this disclosure.

[0023] Figure 1 This is a flowchart illustrating a system upgrade method according to an exemplary embodiment.

[0024] Figure 2 This is a flowchart illustrating a system upgrade method according to an exemplary embodiment.

[0025] Figure 3 This is a flowchart illustrating a boot partition loading method according to an exemplary embodiment.

[0026] Figure 4 This is a flowchart illustrating a partition verification method according to an exemplary embodiment.

[0027] Figure 5 This is a flowchart illustrating a system upgrade method according to an exemplary embodiment.

[0028] Figure 6 This is a block diagram illustrating a system upgrade apparatus according to an exemplary embodiment.

[0029] Figure 7 This is a block diagram illustrating a system upgrade apparatus according to an exemplary embodiment.

[0030] Figure 8 This is a block diagram illustrating a system upgrade apparatus according to an exemplary embodiment. Detailed Implementation

[0031] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this disclosure.

[0032] Because some Android smart TVs have been in use for a long time, they still use the Android 9.0 system. When the Android system is upgraded, the upgrade method is still the Recovery system upgrade method.

[0033] Verified Boot is a crucial security feature in the Android system, primarily designed to prevent boot image tampering and enhance system resilience. Android employs a unified Verified Boot framework (AndroidVerifiedBoot 2.0, AVB 2.0). AVB 2.0 introduces a separate system verification metadata partition (vbmeta) and a system verification metadata image file (vbmeta.img). Since vbmeta contains verification information for other partitions, it is calculated and packaged into this partition during compilation. If the vbmeta partition is secure, the information for other partitions contained within it is also sufficiently secure. Therefore, during the boot process, the BootLoader only needs to verify vbmeta.img to confirm the trustworthiness of the data within vbmeta before using that data to verify other partitions. Furthermore, AVB 2.0 performs two verifications during system boot: one in the BootLoader phase and the first stage of the early (Init) phase. The Bootloader stage verifies the vbmeta partition, the boot partition, and the device tree overwrite partition. In the first stage of Init, the system partition and the vendor partition are verified.

[0034] However, a power outage during system restart can corrupt data in the first partition, resulting in incomplete data, or corrupt data in the AVB protected partitions (boot partition, dtbo partition, and vbmeta partition), preventing the system from booting or functioning properly and severely impacting the user's television experience. For example, ... Figure 1 As shown, Figure 1 This is a flowchart illustrating a system upgrade method according to an exemplary embodiment. In a Recovery system upgrade, it is typically necessary to first boot into the Recovery system. During the boot process, it is determined whether the current system is powered off. If no power outage has occurred, the system can enter the Recovery system and complete the upgrade within it until successful. If a power outage has occurred, the system is powered on and restarted, and the partition corresponding to the power outage is determined. If it is the first partition, it is determined whether the uboot in the first partition is complete. If complete, the system enters the AVB verification stage, where AVB verification can be understood as partition verification. In the following embodiments of this disclosure, AVB verification and partition verification can be used interchangeably. If incomplete, the system cannot boot. uboot is a common boot loader program for devices, responsible for booting the system. As shown in Table 1, the system partitions can be laid out as follows. When the uboot in the first partition of the system partition is corrupted, the system will be unable to boot.

[0035] Table 1

[0036]

[0037]

[0038] In this embodiment, if no power outage occurs during AVB verification, the system successfully enters Recovery mode and proceeds to the upgrade. If no power outage occurs during the system upgrade, the upgrade is successful. However, if a power outage occurs during AVB verification, resulting in incomplete data in the second partition and inability to perform verification, the AVB verification fails, and the system cannot boot. Currently, when manufacturers encounter system upgrade failures, they typically require after-sales personnel to perform on-site flashing at the user's home, leading to a poor user experience. Therefore, the problem of data corruption in partitions due to power outages during system upgrades still needs to be addressed.

[0039] In view of this, the present disclosure provides a system upgrade method that backs up a first partition and a second partition, so that when the data in the first partition or the second partition is incomplete, the data in the backup partition can be used to continue the system upgrade.

[0040] Figure 2 This is a flowchart illustrating a system upgrade method according to an exemplary embodiment. For example... Figure 2 As shown, the method includes steps S11 to S13.

[0041] In step S11, in response to a power outage and subsequent power-on restart of the electronic device during a system upgrade, the system checks whether the bootloader meets the first verification condition.

[0042] In this embodiment of the disclosure, a power outage may occur during system upgrades, resulting in an incomplete bootloader. Therefore, it is necessary to check whether the bootloader meets the first verification condition. Understandably, the first verification condition is to confirm whether the bootloader is complete.

[0043] In this embodiment, the bootloader is stored in a first partition and a backup partition of the first partition. The bootloader in the first partition can determine the location and attributes of each partition by reading the partition table, and read the new kernel from the electronic device, loading it into memory so that the system can boot using the new kernel, i.e., loading the program in the boot system. The backup partition of the first partition is a backup partition of the first partition, and the backup partition corresponds one-to-one with the data in the first partition. Because the first partition contains a large amount of data, it is backed up before system upgrades to obtain the backup partition. This avoids the situation where the first partition cannot be backed up in time during a power outage during system upgrades, thus preventing the system from failing to boot.

[0044] In step S12, in response to the bootloader satisfying the first verification condition, the target data is checked to see if it satisfies the second verification condition.

[0045] In this embodiment, the target data is stored in the second partition and its backup partition. The second partition is backed up to obtain the second partition backup partition. It is understood that there is a one-to-one correspondence between the second partition backup partition and the target data in the second partition, and the target data therein can be used for partition verification during system upgrades.

[0046] In this embodiment, the second verification condition is whether the target data in the second partition is complete. If a power outage occurs during the system upgrade process, it is determined whether the target data in the second partition has been corrupted. If corrupted, partition verification can continue based on the target data in the backup partition of the second partition. This partition verification focuses on the integrity and authenticity of the boot system partition, which may be, for example, a vbmeta partition or a dtbo partition. The content of the system partition can be verified using the signature and hash value in the vbmeta partition.

[0047] In this embodiment of the disclosure, the second partition may include at least one partition. Therefore, if one of the partitions of the second partition is damaged, partition verification can be performed using the partition corresponding to the damaged partition in the backup partition of the second partition and the undamaged partitions of the second partition. Alternatively, if all partitions in the second partition are damaged, partition verification can be performed based on the backup partition of the second partition corresponding to the second partition. Or, if the second partition is not damaged, partition verification can be performed based on the second partition.

[0048] In this embodiment, since the second partition contains less data, the backup time is shorter. Therefore, the second partition can be backed up upon receiving a system upgrade command, resulting in a backup partition.

[0049] In step S13, in response to the target data meeting the second verification condition, a system upgrade is performed.

[0050] In this embodiment of the disclosure, in response to the successful partition verification based on the second partition and / or the backup partition of the second partition, the system is restarted and enters the Recovery system for system upgrade.

[0051] In this embodiment, in response to a power outage and subsequent restart of the electronic device during a system upgrade, a bootloader is loaded based on the first partition or its backup partition to prevent system failure due to corruption of the bootloader in the first partition. For the second partition, upon receiving a system upgrade command, a backup partition is created. This backup partition facilitates partition verification based on the target data in the second partition and / or its backup partition should the target data in the second partition be corrupted, thus preventing system failure due to power outage. This simultaneously ensures the boot security of the electronic device and the stability of the system.

[0052] In this embodiment of the disclosure, the boot loading operation can be performed based on the bootloader in the first partition or the backup partition of the first partition in the following manner. Figure 3 This is a flowchart illustrating a boot partition loading method according to an exemplary embodiment. For example... Figure 3 As shown, the method includes steps S21 to S22b.

[0053] In step S21, the bootloader is checked to ensure it meets the first verification condition.

[0054] In this embodiment of the disclosure, if a power outage occurs during system upgrade, and the system is in the first partition at the time of the power outage, then it is determined whether the contents of the first partition are complete.

[0055] In step S22a, in response to the integrity of the bootloader's contents, the bootloader in the first partition is used to perform a boot loading operation, and it is determined that the bootloader meets the first verification condition.

[0056] In this embodiment of the disclosure, the requirement that the bootloader content is complete can be achieved either by the electronic device not experiencing a power outage during a system upgrade, or by a power outage but the bootloader content in the first partition remaining intact. The bootloader in the first partition is then used for the boot loading operation.

[0057] In this embodiment of the disclosure, in response to the completeness of the bootloader content, the bootloader in the first partition is used to determine that the bootloader meets the first verification condition.

[0058] In step S22b, in response to the incomplete content of the bootloader, the bootloader in the backup partition of the first partition is used to perform the bootloader operation, and it is determined that the bootloader meets the first verification condition.

[0059] In this embodiment, in response to incomplete bootloader content, to avoid a situation where the system cannot boot due to incomplete first partition content after a power outage, a bootloader from the first partition backup partition is used for boot loading. Based on the bootloader from the first partition backup partition, the system enters the second partition for partition verification.

[0060] In this embodiment, the bootloader can be uboot. uboot is used to complete hardware device initialization, and can download data via an interface and burn it into the electronic device to provide device drivers. A first partition backup is created, and the bootloader in the first partition backup partition can be ubootbak. If the content in uboot is incomplete, the boot loading operation is performed based on ubootbak.

[0061] In this embodiment of the disclosure, the first partition backup partition is described in conjunction with Table 2. As shown in Table 2, the first partition includes the bootloader uboot, and the first partition backup partition includes the bootloader ubootbak. If the uboot content is incomplete, the boot loading operation is performed based on ubootbak to avoid the system failing to boot.

[0062] Table 2

[0063]

[0064]

[0065] In this embodiment, a first partition backup is obtained. This first partition backup partition is used to load the system when the bootloader content is incomplete. This avoids the situation where the system cannot start due to the bootloader in the first partition being damaged, thus improving the user experience.

[0066] In this embodiment of the disclosure, the target data in the second partition may include at least one of the following partitions: a boot partition, a device tree overlay partition, and a system verification metadata partition. The boot partition stores boot files, the device tree overlay partition stores device tree overlay files, and the system verification metadata partition stores information such as the system's structure and status. During the AVB verification phase, the boot partition, device tree overlay partition, and system verification metadata partition can be verified by comparing the hash values ​​of these partitions with expected hash values ​​to confirm the reliability of the data within the partitions.

[0067] In this embodiment of the disclosure, partition verification is performed on the second partition to ensure that trusted code and data are loaded into the system, facilitating system upgrades.

[0068] In this embodiment of the disclosure, partition verification can be performed in the following manner. Figure 4 This is a flowchart illustrating a partition verification method according to an exemplary embodiment. Figure 4 As shown, the method includes steps S31 to S32b.

[0069] In step S31, the target data is checked to ensure it meets the second verification condition.

[0070] In this embodiment of the disclosure, in response to the bootloader satisfying the first verification condition, the target data is checked to satisfy the second verification condition.

[0071] In step S32a, in response to the successful partition verification based on the target data in the second partition, it is determined that the target data meets the second verification condition.

[0072] In this embodiment of the disclosure, in response to the completeness of the target data in the second partition, partition verification can be performed based on the target data in the second partition. If the partition verification based on the target data in the second partition passes, it can be determined that the target data in the second partition meets the second verification condition.

[0073] In step S32b, in response to the failure of partition verification based on the target data in the second partition, partition verification is performed based on the target data in the backup partition of the second partition, and the verification passes, thus determining that the target data meets the second verification condition.

[0074] In this embodiment of the disclosure, the failure of partition verification for the target data in the second partition may include the following situations: A power outage occurs during system upgrade of the boot partition, causing the target data in the second partition to be corrupted and unable to pass partition verification, thus preventing the system from booting. Alternatively, a power outage occurs during system upgrade of the device tree overlay partition, causing the target data in the second partition to be corrupted and unable to pass partition verification, thus preventing the system from booting. Alternatively, a power outage occurs during system upgrade of the system verification metadata partition, causing the second partition to be corrupted and unable to pass partition verification, thus preventing the system from booting. Or, all target data in the second partition is corrupted, failing partition verification, thus preventing the system from booting.

[0075] In this embodiment of the disclosure, a second partition backup partition is obtained for the second partition backup. For example, if the second partition includes a boot partition, a device tree overlay partition, and a system verification metadata partition, then the second partition backup partition also includes the boot partition, the device tree overlay partition, and the system verification metadata partition.

[0076] In this embodiment of the disclosure, if a power outage occurs during the system's boot partition upgrade, partition verification can be performed based on the device tree overlay partition, the system verification metadata partition, and the boot partition in the second partition's backup partition. If a power outage occurs during the system's boot partition upgrade, partition verification can be performed based on the device tree overlay partition, the system verification metadata partition, and the device tree overlay partition in the second partition's backup partition. If a power outage occurs during the system verification metadata partition upgrade, partition verification can be performed based on the boot partition, the device tree overlay partition, and the system verification metadata partition in the second partition's backup partition. If the boot partition, the device tree overlay partition, and the system verification metadata partition are all corrupted, partition verification can be performed based on the boot partition, the device tree overlay partition, and the system verification metadata partition in the second partition's backup partition.

[0077] In this embodiment of the disclosure, partition verification is performed based on the target data in the second partition backup partition, and if the verification passes, it is determined that the target data meets the second verification condition.

[0078] In this embodiment of the disclosure, partition verification is performed based on the target data in the second partition, or partition verification is performed based on the target data in the backup partition of the second partition, and the verification is successful. This ensures that the system can complete partition verification even when the power is off, so that the system can start successfully and reduce the probability of after-sales repair of electronic devices, such as smart TVs.

[0079] In this embodiment, since the target data in the second partition is small, backing up the target data in the second partition takes less time. Therefore, when the electronic device receives a system upgrade command, the target data in the second partition can be backed up to the backup partition of the second partition. This ensures that even if the system experiences a power outage, the partition verification will not be affected.

[0080] In this embodiment of the disclosure, setting a backup partition for the first partition can be done by creating a partition at the same level as the other partitions on the disk, allocating memory for the backup partition, and facilitating the storage of the backup partition corresponding to the first partition. In other words, it can be understood as adding a new partition to the existing partitions and allocating it to the backup partition.

[0081] In this embodiment, a backup partition is set up for the second partition. All partitions related to the second partition can be placed in a data cache partition, i.e., the cache partition in Table 2. If the AVB check fails, the relevant data can be read from the cache partition, and the AVB check can be performed again until the AVB check passes.

[0082] In this embodiment of the disclosure, when reading relevant data in the cache partition, image files of the boot partition, device tree overlay partition, and system verification metadata partition can be obtained, and the above files can be written into the corresponding boot partition, device tree overlay partition, and system verification metadata partition. AVB verification is then performed again until the AVB verification passes.

[0083] In this embodiment of the disclosure, the second partition backup partition may also be stored in another partition in the system partition under the same directory as the data cache partition.

[0084] In this embodiment, the first partition backup partition is set in a newly added partition in the system partition, and the second partition backup partition is set in the data cache partition, which enables flexible use of the partitions.

[0085] The embodiments disclosed herein are described below in conjunction with Figure 5 The system upgrade method is explained. Figure 5 This is a flowchart illustrating a system upgrade method according to an exemplary embodiment. For example... Figure 5 As shown, during a recovery system upgrade, it's typically necessary to boot into the Recovery system first. During boot, it checks if the system has experienced a power outage. If not, it enters the Recovery system and completes the upgrade within it until successful. If a power outage occurs, the system restarts and checks the partition corresponding to the power outage. If it's the first partition, it checks if uboot is complete. If complete, it enters the AVB verification stage. If incomplete, it loads the bootloader from the backup partition of the first partition (ubootbak), and continues the boot process, then enters the AVB verification stage. For the backup partition of the first partition, a second backup partition can be created by adding another backup partition to the existing partition. If the uboot content is incomplete during the upgrade, the system will fail to boot. With ubootbak, if the uboot content is incomplete and the upgrade fails, ubootbak is used to perform the boot loading operation to successfully boot the system.

[0086] In this embodiment, if no power outage occurs during AVB verification, the system successfully enters Recovery mode and proceeds to the Recovery upgrade. If no power outage occurs during the system upgrade, the system upgrade is successful. If a power outage occurs during AVB verification, the dtbo partition, boot partition, or vbmeta partition is loaded from the cache partition. Essentially, the partition where the power outage occurred is the partition loaded from the cache. When loading the backup partition, the system needs to return to the initial stage of AVB verification and perform verification based on the data in the backup partition. After successful verification, the system enters Recovery mode for the upgrade. If no power outage occurs during the system upgrade, the system upgrade is successful.

[0087] In this embodiment of the disclosure, if a power outage occurs during the startup process, the above process is executed until the system is no longer powered down and the system is successfully upgraded.

[0088] In this embodiment of the disclosure, when a power outage occurs during system upgrade, resulting in partition corruption, the data in the backup partition can be used to continue booting the Recovery system, facilitating subsequent upgrade operations, thereby reducing the risk of the device failing to boot after the upgrade, lowering the probability of after-sales repair, and improving the user experience.

[0089] Based on the same concept, this disclosure also provides a system upgrade device 100.

[0090] It is understood that the system upgrade apparatus 100 provided in this disclosure includes hardware structures and / or software modules corresponding to each function in order to achieve the above-mentioned functions. In conjunction with the units and algorithm steps of the various examples disclosed in this disclosure, this disclosure can be implemented in hardware or a combination of hardware and computer software. Whether a function is executed by hardware or by 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, but such implementation should not be considered beyond the scope of the technical solutions of this disclosure.

[0091] Figure 6 This is a block diagram illustrating a system upgrade apparatus 100 according to an exemplary embodiment. (Refer to...) Figure 6 The device includes a processing unit 101 and an execution unit 102.

[0092] The processing unit 101 is configured to, in response to a power outage and power-on restart of an electronic device during a system upgrade, check whether the bootloader meets a first verification condition, wherein the bootloader is stored in a first partition and a first partition backup partition; and in response to the bootloader meeting the first verification condition, check whether the target data meets a second verification condition, wherein the target data is stored in a second partition and a second partition backup partition, wherein the second partition backup partition is generated upon receiving a system upgrade instruction.

[0093] The execution unit 102 is used to perform a system upgrade in response to the target data meeting the second verification condition.

[0094] In one embodiment, the processing unit 101 checks whether the bootloader meets the first verification condition in the following manner: in response to the completeness of the bootloader content, it performs a boot loading operation using the bootloader in the first partition to determine that the bootloader meets the first verification condition; or in response to the incompleteness of the bootloader content, it performs a boot loading operation using the bootloader in the backup partition of the first partition to determine that the bootloader meets the first verification condition.

[0095] In one embodiment, the processing unit 101 checks whether the target data meets the second verification condition in the following manner: in response to the successful partition verification based on the target data in the second partition, it determines that the target data meets the second verification condition; in response to the failed partition verification based on the target data in the second partition, it performs a partition verification based on the target data in the backup partition of the second partition, and if the verification is successful, it determines that the target data meets the second verification condition.

[0096] In one embodiment, the processing unit 101 is further configured to: in response to the electronic device receiving a system upgrade instruction, back up the target data in the second partition to the backup partition of the second partition.

[0097] In one implementation, the first partition backup partition is a newly added partition in the system partition; the second partition backup partition is set in the data cache partition in the system partition.

[0098] In one implementation, the second partition includes at least one of the following: a boot partition; a device tree overlay partition; and a system verification metadata partition.

[0099] Regarding the apparatus in the above embodiments, the specific manner in which each module performs its operation has been described in detail in the embodiments related to the method, and will not be elaborated upon here.

[0100] Figure 7This is a block diagram illustrating a system upgrade device 200 according to an exemplary embodiment. Device 200 can be provided as a terminal. For example, device 200 can be a mobile phone, computer, digital broadcasting terminal, messaging device, game console, tablet device, medical device, fitness equipment, personal digital assistant, etc.

[0101] Reference Figure 7 The device 200 may include one or more of the following components: processing component 202, memory 204, power component 206, multimedia component 208, audio component 210, input / output (I / O) interface 212, sensor component 214, and communication component 216.

[0102] Processing component 202 typically controls the overall operation of device 200, such as operations associated with display, telephone calls, data communication, camera operation, and recording. Processing component 202 may include one or more processors 220 to execute instructions to perform all or part of the steps of the methods described above. Furthermore, processing component 202 may include one or more modules to facilitate interaction between processing component 202 and other components. For example, processing component 202 may include a multimedia module to facilitate interaction between multimedia component 208 and processing component 202.

[0103] Memory 204 is configured to store various types of data to support the operation of device 200. Examples of such data include instructions for any application or method operating on device 200, contact data, phonebook data, messages, pictures, videos, etc. Memory 204 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk.

[0104] The power supply component 206 provides power to the various components of the device 200. The power supply component 206 may include a power management system, one or more power sources, and other components associated with generating, managing, and distributing power to the device 200.

[0105] Multimedia component 208 includes a screen that provides an output interface between the device 200 and the user. In some embodiments, the screen may include a liquid crystal display (LCD) and a touch panel (TP). If the screen includes a touch panel, the screen may be implemented as a touchscreen to receive input signals from the user. The touch panel includes one or more touch sensors to sense touches, swipes, and gestures on the touch panel. The touch sensors may sense not only the boundaries of the touch or swipe action but also the duration and pressure associated with the touch or swipe operation. In some embodiments, multimedia component 208 includes a front-facing camera and / or a rear-facing camera. When the device 200 is in an operating mode, such as a shooting mode or a video mode, the front-facing camera and / or the rear-facing camera may receive external multimedia data. Each front-facing camera and rear-facing camera may be a fixed optical lens system or have focal length and optical zoom capabilities.

[0106] Audio component 210 is configured to output and / or input audio signals. For example, audio component 210 includes a microphone (MIC) configured to receive external audio signals when device 200 is in an operating mode, such as call mode, recording mode, and voice recognition mode. The received audio signals may be further stored in memory 204 or transmitted via communication component 216. In some embodiments, audio component 210 also includes a speaker for outputting audio signals.

[0107] I / O interface 212 provides an interface between processing component 202 and peripheral interface modules, such as keyboards, click wheels, buttons, etc. These buttons may include, but are not limited to, home buttons, volume buttons, power buttons, and lock buttons.

[0108] Sensor assembly 214 includes one or more sensors for providing status assessments of various aspects of device 200. For example, sensor assembly 214 may detect the on / off state of device 200, the relative positioning of components such as the display and keypad of device 200, changes in the position of device 200 or a component of device 200, the presence or absence of user contact with device 200, the orientation or acceleration / deceleration of device 200, and temperature changes of device 200. Sensor assembly 214 may include a proximity sensor configured to detect the presence of nearby objects without any physical contact. Sensor assembly 214 may also include a light sensor, such as a CMOS or CCD image sensor, for use in imaging applications. In some embodiments, sensor assembly 214 may also include an accelerometer, a gyroscope, a magnetometer, a pressure sensor, or a temperature sensor.

[0109] Communication component 216 is configured to facilitate wired or wireless communication between device 200 and other devices. Device 200 can access wireless networks based on communication standards, such as WiFi, 2G, or 3G, or combinations thereof. In one exemplary embodiment, communication component 216 receives broadcast signals or broadcast-related information from an external broadcast management system via a broadcast channel. In one exemplary embodiment, communication component 216 also includes a near-field communication (NFC) module to facilitate short-range communication. For example, the NFC module may be implemented based on radio frequency identification (RFID) technology, Infrared Data Association (IrDA) technology, ultra-wideband (UWB) technology, Bluetooth (BT) technology, and other technologies.

[0110] In an exemplary embodiment, the apparatus 200 may be implemented by one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), controllers, microcontrollers, microprocessors, or other electronic components to perform the methods described above.

[0111] In an exemplary embodiment, a non-transitory computer-readable storage medium including instructions is also provided, such as a memory 204 including instructions, which can be executed by a processor 220 of the device 200 to perform the above-described method. For example, the non-transitory computer-readable storage medium may be a ROM, random access memory (RAM), CD-ROM, magnetic tape, floppy disk, and optical data storage device, etc.

[0112] Figure 8 This is a block diagram illustrating a system upgrade apparatus 300 according to an exemplary embodiment. For example, apparatus 300 may be provided as a server. (Refer to...) Figure 8 The device 300 includes a processing component 322, which further includes one or more processors, and memory resources represented by memory 332 for storing instructions, such as application programs, that can be executed by the processing component 322. The application programs stored in memory 332 may include one or more modules, each corresponding to a set of instructions. Furthermore, the processing component 322 is configured to execute instructions to perform the methods described above.

[0113] Device 300 may also include a power supply component 326 configured to perform power management of device 300, a wired or wireless network interface 350 configured to connect device 300 to a network, and an input / output (I / O) interface 358. Device 300 may operate on an operating system stored in memory 332, such as Windows Server™, Mac OS X™, Unix™, Linux™, FreeBSD™, or similar.

[0114] It is understood that in this disclosure, "multiple" refers to two or more, and other quantifiers are similar. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, and B alone. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. The singular forms "a," "the," and "the" are also intended to include the plural forms unless the context clearly indicates otherwise.

[0115] It is further understood that the terms "first," "second," etc., are used to describe various types of information, but this information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another, and do not indicate a specific order or degree of importance. In fact, the expressions "first," "second," etc., are completely interchangeable. For example, without departing from the scope of this disclosure, first information can also be referred to as second information, and similarly, second information can also be referred to as first information.

[0116] It is further understood that the terms “center,” “longitudinal,” “lateral,” “front,” “rear,” “up,” “down,” “left,” “right,” “vertical,” “horizontal,” “top,” “bottom,” “inner,” and “outer,” etc., indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings. They are only for the convenience of describing this embodiment and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation.

[0117] It can be further understood that, unless otherwise specified, "connection" includes both direct connections where no other components exist between the two parties and indirect connections where other components exist between them.

[0118] It is further understood that although operations are described in a specific order in the accompanying drawings in the embodiments of this disclosure, this should not be construed as requiring these operations to be performed in the specific order or serial order shown, or requiring all of the shown operations to be performed to obtain the desired result. In certain environments, multitasking and parallel processing may be advantageous.

[0119] Other embodiments of this disclosure will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This disclosure is intended to cover any variations, uses, or adaptations of the invention that follow the general principles of this disclosure and include common knowledge or customary techniques in the art not disclosed herein.

[0120] It should be understood that this disclosure is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this disclosure is limited only by the appended claims.

Claims

1. A system upgrade method, characterized in that, include: In response to a power outage and subsequent power-on restart during a system upgrade of an electronic device, the system checks whether the bootloader meets the first verification condition. The bootloader is stored in the first partition and the first partition backup partition. In response to the bootloader satisfying the first verification condition, the target data is checked to see if it satisfies the second verification condition. The target data is stored in the second partition and the second partition backup partition, which is generated upon receiving a system upgrade instruction. In response to the target data meeting the second verification condition, a system upgrade is performed.

2. The method according to claim 1, characterized in that, The check that the bootloader meets the first verification condition includes: In response to the completeness of the bootloader content, a bootloader operation is performed using the bootloader in the first partition, and it is determined that the bootloader meets the first verification condition; or In response to the incomplete content of the bootloader, the bootloader in the backup partition of the first partition is used to perform a boot loading operation, and it is determined that the bootloader meets the first verification condition.

3. The method according to claim 1 or 2, characterized in that, The target data to be inspected satisfies the second verification condition, including: In response to the successful partition verification based on the target data in the second partition, it is determined that the target data meets the second verification condition; In response to the failure of partition verification based on the target data in the second partition, partition verification is performed based on the target data in the backup partition of the second partition, and the verification passes, thus determining that the target data meets the second verification condition.

4. The method according to claim 3, characterized in that, The method further includes: In response to the electronic device receiving a system upgrade command, the target data in the second partition is backed up to the backup partition of the second partition.

5. The method according to claim 1, characterized in that, The first backup partition is a newly added partition within the system partition; The second partition backup partition is set in the data cache partition of the system partition.

6. The method according to claim 1, characterized in that, The second partition includes at least one of the following: Boot partition; Device tree coverage partition; The system verifies the metadata partition.

7. A system upgrade device, characterized in that, include: The processing unit is configured to, in response to a power outage and power-on restart of an electronic device during a system upgrade, check whether the bootloader meets the first verification condition, wherein the bootloader is stored in the first partition and the first partition backup partition; In response to the bootloader satisfying the first verification condition, the target data is checked to see if it satisfies the second verification condition. The target data is stored in the second partition and the second partition backup partition, which is generated upon receiving a system upgrade instruction. The execution unit is used to perform a system upgrade in response to the target data meeting the second verification condition.

8. The apparatus according to claim 7, characterized in that, The processing unit checks whether the bootloader meets the first verification condition in the following manner: In response to the completeness of the bootloader content, a bootloader operation is performed using the bootloader in the first partition, and it is determined that the bootloader meets the first verification condition; or In response to the incomplete content of the bootloader, the bootloader in the backup partition of the first partition is used to perform a boot loading operation, and it is determined that the bootloader meets the first verification condition.

9. The apparatus according to claim 7 or 8, characterized in that, The processing unit checks whether the target data meets the second verification condition in the following manner: In response to the successful partition verification based on the target data in the second partition, it is determined that the target data meets the second verification condition; In response to the failure of partition verification based on the target data in the second partition, partition verification is performed based on the target data in the backup partition of the second partition, and the verification passes, thus determining that the target data meets the second verification condition.

10. The apparatus according to claim 9, characterized in that, The processing unit is also used for: In response to the electronic device receiving a system upgrade command, the target data in the second partition is backed up to the backup partition of the second partition.

11. The apparatus according to claim 7, characterized in that, The first backup partition is a newly added partition within the system partition; The second partition backup partition is set in the data cache partition of the system partition.

12. The apparatus according to claim 7, characterized in that, The second partition includes at least one of the following: Boot partition; Device tree coverage partition; The system verifies the metadata partition.

13. An electronic device, characterized in that, include: processor: Memory used to store processor-executable instructions; The processor is configured to execute the system upgrade method according to any one of claims 1 to 6.

14. A storage medium, characterized in that, The storage medium stores instructions that, when executed by a processor, enable the processor to perform the system upgrade method according to any one of claims 1 to 6.

Images