WO2024078218A1 - 系统启动方法及电子设备 - Google Patents

系统启动方法及电子设备 Download PDF

Info

Publication number
WO2024078218A1
WO2024078218A1 PCT/CN2023/117642 CN2023117642W WO2024078218A1 WO 2024078218 A1 WO2024078218 A1 WO 2024078218A1 CN 2023117642 W CN2023117642 W CN 2023117642W WO 2024078218 A1 WO2024078218 A1 WO 2024078218A1
Authority
WO
WIPO (PCT)
Prior art keywords
partition
electronic device
boot partition
startup
system boot
Prior art date
Application number
PCT/CN2023/117642
Other languages
English (en)
French (fr)
Inventor
钟微
余亮
Original Assignee
荣耀终端有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 荣耀终端有限公司 filed Critical 荣耀终端有限公司
Publication of WO2024078218A1 publication Critical patent/WO2024078218A1/zh

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/4401—Bootstrapping
    • G06F9/4406—Loading of operating system
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G06F8/61—Installation
    • G06F8/63—Image based installation; Cloning; Build to order
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G06F8/65—Updates
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/70—Software maintenance or management
    • G06F8/71—Version control; Configuration management

Definitions

  • the present application relates to the technical field of intelligent terminals, and in particular to a system startup method and an electronic device.
  • the BootLoader From the overall process of terminal device startup, the first thing that runs after the terminal device is powered on is the BootLoader. That is, in an embedded operating system, the BootLoader runs before the operating system kernel runs.
  • the BootLoader can initialize hardware devices and establish a memory space mapping map, thereby bringing the system's hardware and software environment to a suitable state, so as to prepare the correct environment for the final call to the operating system kernel.
  • each system boot partition image will be verified. Once all system boot partition images fail to be verified, the terminal device will enter Fastboot mode. At this time, the user needs to ask professional maintenance personnel to solve the problem. Given that users are increasingly relying on mobile smart terminals represented by smartphones, the terminal system entering Fastboot mode will undoubtedly cause serious troubles to users' lives and work.
  • the embodiment of the present application provides a system startup method and an electronic device.
  • the method during the process of the electronic device performing system startup in one of the system startup partitions, if the image verification of the system startup partition fails, the electronic device continues to restart the system in the system startup partition, thereby solving the probabilistic problem of the image verification failure of the system startup partition, improving the self-recovery ability of the electronic device during the system startup process, and greatly reducing the probability of the electronic device crashing due to the probabilistic failure of the image verification.
  • an embodiment of the present application provides a system startup method.
  • the method is applied to an electronic device, and the electronic device includes a first system startup partition and a second system startup partition.
  • the method includes:
  • the electronic device During the process of the electronic device booting the system in the first system boot partition, if the image verification of the first system boot partition fails, the electronic device restarts the system in the first system boot partition;
  • the electronic device successfully restarts the system in the first system boot partition.
  • the cause may be level modulation or probabilistic failure of hardware components, rather than permanent damage.
  • the method further includes: during the process of the electronic device performing a system restart in the first system boot partition, if the image verification of the first system boot partition fails, the electronic device switches to the second system boot partition for system boot;
  • the electronic device successfully restarts the system in the second system boot partition.
  • the first system boot partition and the second system boot partition are backup partitions for each other.
  • the electronic device switches to the pairing area for startup.
  • the electronic device When the electronic device is started in the pairing area, if the image verification of the pairing area also fails, the electronic device continues to restart the system in the pairing area, thereby solving the probabilistic problem of the image verification failure of the system boot partition, improving the self-recovery ability of the electronic device during the system startup process, and greatly reducing the probability of the electronic device crashing due to the probabilistic failure of the image verification.
  • the electronic device switches to the second system boot partition for system startup, which may include: if the attribute of the second system boot partition is in a bootable state, the electronic device switches to the second system boot partition for system startup.
  • the electronic device successfully OTA upgrades the second system boot partition, the attributes of the first system boot partition and the second system boot partition are both in a bootable state, and the electronic device can switch between the two partitions.
  • the method further includes: if the attribute of the second system boot partition is in a non-bootable state, the electronic device enters a fast boot mode.
  • the method further includes: during the process of the electronic device performing a system restart in the second system boot partition, if the image verification of the second system boot partition fails, the electronic device performs a fast boot mode.
  • the electronic device when the electronic device confirms that both the first system boot partition and the second system boot partition are not probabilistically damaged, the electronic device enters a fast boot mode (Fastboot mode).
  • Fast boot mode a fast boot mode
  • the electronic device restarts the system in the first system boot partition, including:
  • the electronic device restarts the system in the first system boot partition
  • the electronic device switches to the second system boot partition to boot the system, including:
  • the electronic device switches to the second system boot partition for system startup; wherein the first threshold is greater than 2.
  • the second threshold is 3.
  • the electronic device continues to restart the system in the system boot partition for multiple times (for example, two to three times), thereby solving the probabilistic problem of the image verification failure of the system boot partition, improving the self-recovery ability of the electronic device during the system startup process, and preventing the electronic device from entering the Fastboot mode. If the electronic device cannot start normally after multiple system restarts in the system boot partition, it can be confirmed that the system boot partition is non-probabilistically damaged, and the electronic device switches the partition to continue starting.
  • the electronic device restarts the system in the second system boot partition, including:
  • the electronic device restarts the system in the second system boot partition; wherein the second threshold is greater than 1.
  • the second threshold is 2.
  • the electronic device performs partition switching, if the image verification of a system boot partition fails, the electronic device continues to restart the system multiple times (for example, two or three times) in the system boot partition, thereby solving the probabilistic problem of image verification failure of the system boot partition, improving the self-recovery ability of the electronic device during the system startup process, and avoiding the electronic device from entering Fastboot mode.
  • the electronic device restarts the system in the first system boot partition, including:
  • the electronic device restarts the system in the first system boot partition.
  • the normal usage scenarios of the terminal device and the OTA upgrade scenarios are partitioned, so that the terminal device executes the recovery strategy determined based on the probabilistic AVB verification failure problem, which will not affect the native OTA upgrade process and ensure that the OTA native upgrade process can be executed normally.
  • the electronic device when the electronic device performs a system restart in the first system boot partition, it also includes: recording log information corresponding to the failure of the image verification of the first system boot partition and a recovery strategy, wherein the recovery strategy is for the electronic device to perform a system restart in the first system boot partition.
  • the electronic device when the electronic device performs a system restart in the second system boot partition, it also includes: recording log information corresponding to the failure of the image verification of the second system boot partition and a recovery strategy, wherein the recovery strategy is for the electronic device to perform a system restart in the second system boot partition.
  • the electronic device when the electronic device switches to the second system boot partition for system startup, it also includes: recording log information corresponding to the failure of the image verification of the first system boot partition and a recovery strategy, wherein the recovery strategy is for the electronic device to switch to the second system boot partition for system startup.
  • the electronic device system after the electronic device system is successfully started, it also includes: uploading log information and recovery strategies to the cloud.
  • an embodiment of the present application provides an electronic device.
  • the electronic device includes: one or more processors; a memory; and one or more computer programs, wherein the one or more computer programs are stored in the memory, and when the computer programs are executed by the one or more processors, the electronic device executes the system startup method of the first aspect and any one of the first aspects.
  • the second aspect and any implementation of the second aspect correspond to the first aspect and any implementation of the first aspect respectively.
  • the technical effects corresponding to the second aspect and any implementation of the second aspect can refer to the technical effects corresponding to the first aspect and any implementation of the first aspect, which will not be repeated here.
  • an embodiment of the present application provides a computer-readable storage medium.
  • the computer-readable storage medium includes a computer program, and when the computer program is executed on an electronic device, the electronic device executes the system startup method of the first aspect and any one of the first aspects.
  • the third aspect and any implementation of the third aspect correspond to the first aspect and any implementation of the first aspect, respectively.
  • the technical effects corresponding to the third aspect and any implementation of the third aspect can refer to the technical effects corresponding to the first aspect and any implementation of the first aspect, which will not be repeated here.
  • an embodiment of the present application provides a computer program product, including a computer program, which, when executed, enables a computer to execute a system startup method as in the first aspect or any one of the first aspects.
  • the fourth aspect and any implementation of the fourth aspect correspond to the first aspect and any implementation of the first aspect, respectively.
  • the technical effects corresponding to the fourth aspect and any implementation of the fourth aspect can refer to the technical effects corresponding to the above-mentioned first aspect and any implementation of the first aspect, which will not be repeated here.
  • the present application provides a chip, the chip comprising a processing circuit and a transceiver pin, wherein the transceiver pin and the processing circuit communicate with each other through an internal connection path, and the processing circuit executes the system startup method as in the first aspect or any one of the first aspects to control the receiving pin to receive a signal, and to control the sending pin to send a signal.
  • the fifth aspect and any implementation of the fifth aspect correspond to the first aspect and any implementation of the first aspect, respectively.
  • the technical effects corresponding to the fifth aspect and any implementation of the fifth aspect can refer to the technical effects corresponding to the first aspect and any implementation of the first aspect, which will not be repeated here.
  • FIG1 is a framework diagram showing an exemplary boot process of an Android system terminal
  • FIG2 is a schematic diagram of a system startup process in the prior art
  • FIG3a is a schematic diagram showing an exemplary application scenario
  • FIG3b is a schematic diagram showing an exemplary application scenario
  • FIG4 is one of the schematic diagrams of the system startup process provided in the application embodiment.
  • FIG5 is one of the schematic diagrams of the system startup process provided in the application embodiment.
  • FIG6 is one of the schematic diagrams of the system startup process provided in the application embodiment.
  • FIG7 is a schematic diagram of an exemplary software framework when the system is started.
  • FIG8 is a schematic diagram of data in a storage partition shown as an example
  • FIG9 is a schematic diagram showing exemplary module interaction
  • FIG10 is a schematic diagram showing a hardware structure of an electronic device
  • FIG. 11 is a schematic diagram showing an exemplary software structure of an electronic device.
  • a and/or B in this article is merely a description of the association relationship of associated objects, indicating that three relationships may exist.
  • a and/or B can mean: A exists alone, A and B exist at the same time, and B exists alone.
  • first and second in the description and claims of the embodiments of the present application are used to distinguish different objects rather than to describe a specific order of objects.
  • a first target object and a second target object are used to distinguish different target objects rather than to describe a specific order of target objects.
  • words such as “exemplary” or “for example” are used to indicate examples, illustrations or descriptions. Any embodiment or design described as “exemplary” or “for example” in the embodiments of the present application should not be interpreted as being more preferred or more advantageous than other embodiments or designs. Specifically, the use of words such as “exemplary” or “for example” is intended to present related concepts in a specific way.
  • multiple refers to two or more than two.
  • multiple processing units refer to two or more processing units; multiple systems refer to two or more systems.
  • the method provided in the embodiments of the present application can be applied to various types of electronic devices.
  • the electronic devices in the embodiments of the present application can be mobile phones, tablet computers, desktop computers, laptop computers, handheld computers, notebook computers, ultra-mobile personal computers (ultra-mobile personal computers, UMPCs), netbooks, as well as cellular phones, personal digital assistants (personal digital assistants, PDAs), augmented reality (augmented reality, AR) and virtual reality (virtual reality, VR) devices and other electronic devices.
  • PDAs personal digital assistants
  • augmented reality augmented reality, AR
  • VR virtual reality
  • the electronic device may include a hardware layer and an operating system layer running on the hardware layer. and the application layer running on the operating system layer.
  • the hardware layer includes hardware such as the central processing unit (CPU), the memory management unit (MMU) and the memory (also called main memory).
  • the operating system can be any one or more computer operating systems that implement business processing through processes, such as the Android operating system, the iOS operating system or the Windows operating system.
  • the application layer includes applications such as browsers, address books, word processing software, and instant messaging software.
  • FIG. 1 is a framework diagram of the startup process of a terminal based on the Android system. As shown in Figure 1, the startup process includes:
  • Boot Rom - When the power button is pressed, the boot chip starts executing from the preset code solidified in ROM, and then loads the boot program to RAM.
  • Bootloader also known as the boot program, is a program that runs before the operating system runs. It is the first program run and is used to copy the operating system image file to RAM, and then jump to the entry of the image file to execute the file. It can also be called entering the boot loading mode.
  • Kernel After loading the kernel into memory, it first enters the kernel boot phase. At the end of the kernel boot phase, start_kernel is called to enter the kernel startup phase, which mainly completes most of the kernel initialization work. Start_kernel will eventually start the init process in the user space.
  • init process After the kernel is initialized, the init process will be started. In Linux, all processes are forked directly or indirectly from the init process.
  • the init process is responsible for creating several key core daemon processes in the system, including but not limited to zygote and service manager. Among them, zygote is the first dalvik virtual machine started by Android, which is responsible for starting the Java process.
  • the service manager is the basis of Binder communication.
  • Zygote process - This process is the parent process of all Java processes.
  • the zygote virtual machine starts the child process system_server and defines a Socket to receive the request from ActivityManagerService to start the application.
  • finishBooting() will be called to complete the boot process, and a boot broadcast will be sent to enter the home interface and display the desktop.
  • the Bootloader will perform a validity check on the operating system image file. Since the Android system is a kernel-based operating system, during the actual boot process, the boot program image, kernel image, and main system image of the boot operating system can be loaded into the memory in sequence, and the legitimacy of each image can be verified in the memory in sequence. Only after the previous image is verified to be legitimate will the next image be loaded into the memory. Only after the main system image has also passed the legitimacy verification will the main system image be expanded into the main system program that the user can actually see with the help of the kernel, thus completing the entire boot process of the Android device.
  • the Android system is a kernel-based operating system
  • the A/B partition system has two systems, one system partition and the other backup partition. These two systems are the same when they leave the factory, but may be different afterwards, one is a new version and the other is an old version.
  • Fastboot mode refers to the fast boot mode.
  • Fastboot is a simple flashing protocol defined by Android, which can be flashed through the Fastboot command line tool.
  • the data integrity, reliability and legality of the partition image file are verified in the Bootloader based on the AVB (Android verify boot) security mechanism.
  • the AVB verification function is mainly implemented by the external/avb/libavb library, which mainly completes the verification of each partition image, signature verification, and parsing of vbmeta data, including the processing of various flags and the parameter parsing required by dm-verity.
  • the terminal device normally starts the slot_a partition when it boots up. If the slot_a partition image AVB verification fails, the terminal device switches to the slot_b partition for startup. If the slot_b partition is started, the terminal boots successfully. However, if the slot_b partition image AVB verification fails, the terminal device enters Fastboot mode.
  • data corruption in the system boot partition is mostly a probabilistic problem, which may be caused by level jumps and probabilistic failures of hardware devices (such as storage media), rather than permanent damage.
  • hardware devices such as storage media
  • unpredictable factors such as environmental factors, temperature factors, and static electricity factors when using hardware storage media may cause probabilistic level jumps, which in turn lead to failure of the system boot partition image verification.
  • the study found that most terminal devices that entered Fastboot mode due to partition image verification failure can start normally after their system boot partition is restarted and activated and started again, which further confirms that there are probabilistic abnormalities in storage devices, rather than permanent abnormalities.
  • the A/B partition system update is also called seamless update (Seamless updates).
  • the OTA update runs in the system background, and the user can still use the device normally during this process. After the update is completed, it is necessary to restart once to enter the new system. If the OTA update fails (the OTA update cannot be applied or cannot be started after application), the device can be restarted and rolled back to the old partition for continued use, and try to update and upgrade again.
  • the terminal device can use a streaming upgrade method, that is, there is no need to leave enough space in the /data or /cache partition to store the downloaded upgrade package, and OTA upgrades can also be performed.
  • the terminal device ensures that a set of normally bootable systems is retained on the disk during the OTA update, reducing the possibility of flashing the machine and reducing the workload of after-sales service.
  • the terminal device performs an OTA upgrade on the slot_b partition. After the OTA upgrade fails, the system rolls back to the slot_a partition. At this time, the slot_a partition can be started normally, and the slot_b partition cannot be started (or is not bootable). The terminal device starts the slot_a partition normally when it is turned on. If the slot_a partition image AVB verification fails, Since the slot_b partition cannot be started, the terminal directly enters Fastboot mode.
  • the terminal device performs an OTA upgrade on the slot_b partition.
  • the OTA upgrade is successful, and the slot_b partition can be started normally.
  • the slot_a partition can be started normally, and the slot_b partition can also be started normally.
  • the terminal device starts the slot_b partition normally when it is turned on. If the AVB verification of the slot_b partition image fails, the terminal device switches to the slot_a partition for startup. If the slot_a partition is started, the terminal boots successfully. However, if the AVB verification of the slot_a partition image fails, the terminal device enters Fastboot mode.
  • the existing logic cannot handle the problem of probabilistic verification failure of partition images.
  • AVB verification fails, the partition is switched. If the switched partition image fails AVB verification again, the terminal enters Fastboot mode, which undoubtedly increases the probability of the terminal device entering Fastboot mode. The lack of a stable recovery mechanism reduces the user experience.
  • the embodiment of the present application provides a system startup method.
  • the problem of probabilistic failure of partition image AVB verification is fully considered, and a recovery strategy is designed to ensure that the terminal can automatically recover and start the system normally when the partition image AVB verification fails probabilistically, thereby reducing the probability of the terminal device entering Fastboot mode, thereby improving the user experience.
  • the scenarios involved in the terminal device system startup may include normal use scenarios and OTA upgrade scenarios.
  • the normal use scenario can be divided into OTA upgrade success scenario and OTA upgrade failure rollback scenario.
  • the power-on startup of the terminal device can be triggered by the user pressing the power button of the device, or it can be triggered automatically due to certain system settings, such as the scheduled startup of the terminal device, or it can be triggered automatically due to certain abnormalities of the system, which is not limited in the embodiments of the present application.
  • the Bootloader In order to determine whether a system boot partition is in a bootable state, the Bootloader needs to define corresponding attributes (states) for it. For example, the states are described as follows:
  • the attribute Active is the active partition identifier, which is exclusive and means that the partition is the boot partition. The bootloader will always select this partition for system startup.
  • the attribute bootable indicates that the partition contains a system that may be bootable
  • the attribute successful indicates that the partitioned system can start normally
  • the attribute unbootable means that the partition is damaged and cannot be started. It is always marked during the upgrade process.
  • the bootloader detects that one or two slot partitions are both bootable, and selects the slot partition with active attribute or the slot partition with success attribute to try to boot. If the partition is successfully booted, the partition attribute can be set to successful and active; if the partition fails to boot, the partition attribute can be set to unbootable, and the attribute of another partition can be set to active for the next attempt.
  • the normal scenario is the most common situation. For example, when the device leaves the factory, both the slot_a partition and the slot_b partition can be successfully started and run normally, so both partitions are set to bootable and successful. Assuming that the device is started from the slot_b partition, only the slot_b partition is set to active.
  • the slot_b partition detects the upgrade data and performs the upgrade in the slot_a partition. At this time, the slot_a partition is marked as unbootable and the success flag of the slot_a partition is cleared. The slot_b partition attributes remain active, bootable, and successful.
  • the slot_a partition After the slot_b partition successfully updates the slot_a partition, the slot_a partition is marked as bootable. In addition, since the slot_a partition needs to be started after the restart, the slot_a partition also needs to be set to active. However, since it has not been verified whether the slot_a partition can run successfully, the slot_a partition is not set to successful; the slot_b partition status becomes bootable and successful, but not active.
  • the bootloader After the device restarts, the bootloader detects that the slot_a partition is active, so it loads the slot_a partition system. If the system can run normally after entering the slot_a partition system, the slot_a partition needs to be marked as successful. Compared with the normal scenario, the slot_a partition and the slot_b partition are both set to bootable and successful, but the active is switched from the slot_b partition to the slot_a partition. At this point, the slot_b partition is successfully updated and switched to the slot_a partition, and the device re-enters the normal scenario.
  • the terminal device is in normal use, and before that, a system boot partition of the terminal device has been successfully OTA upgraded.
  • the two system boot partitions of the terminal device (such as slot_a partition and slot_b partition) are in a normal bootable state.
  • the terminal device starts the slot_a partition normally when it is turned on. If the AVB verification of the slot_a partition image fails, the terminal device restarts the slot_a partition. If the slot_a partition is successfully started when the slot_a partition is restarted, it indicates that the failure of the AVB verification of the slot_a partition image is a probabilistic problem, and the terminal device can be started normally through the restart recovery strategy. If the slot_a partition image fails the AVB verification again when the slot_a partition is restarted, the terminal device restarts the slot_a partition again.
  • slot_a partition If the slot_a partition is successfully started when the slot_a partition is restarted again, it indicates that the failure of the AVB verification of the slot_a partition image is a probabilistic problem, and the terminal device can be started normally through the restart recovery strategy. If the slot_a partition image fails the AVB verification again when the slot_a partition is restarted again, it indicates that the failure of the AVB verification of the slot_a partition image is a non-probabilistic problem, and it may be a problem that the slot_a partition image is permanently damaged. At this time, switch to the slot_b partition to continue starting.
  • the slot_a partition needs to be set to active before the terminal device restarts.
  • the terminal device when the terminal device switches to the slot_b partition for startup, if the slot_b partition fails to verify the AVB image of the slot_b partition, the terminal device restarts the slot_b partition. If the slot_b partition successfully starts when the slot_b partition is restarted, it indicates that the slot_b partition mirror AVB verification is successful. Failure is a probabilistic problem, and the terminal device can be started normally through the restart recovery strategy. If the slot_b partition image fails the AVB verification again when the slot_b partition is restarted, it means that the slot_b partition image AVB verification failure is not a probabilistic problem, and the slot_b partition image may be permanently damaged. At this time, the terminal device enters Fastboot mode.
  • the slot_b partition needs to be set to active before the terminal device restarts.
  • the terminal device selects the next recovery strategy based on the previous recovery record corresponding to the current system boot partition. Among them, if the current system boot partition fails to verify the first and second AVB verifications, in order to eliminate the problem of probabilistic AVB verification failures, restart will be used as the next recovery strategy; if the current system boot partition fails to verify the third time, it can be determined that the current system boot partition has a non-probabilistic AVB verification failure problem, which may be due to permanent damage to the partition image, and switching partitions to start will be used as the next recovery strategy. After switching partitions, the fourth AVB verification is for the partition image.
  • restart will be used as the next recovery strategy; if the partition image fails to verify the AVB twice in a row, it can be determined that the non-probabilistic AVB verification failure of the partition may be due to permanent damage to the partition image, and the terminal device enters Fastboot mode.
  • the slot_a partition is restarted twice and the slot_b partition is restarted once.
  • the number of restarts is only an exemplary description.
  • the number of restarts of the slot_a partition and/or the slot_b partition can be reasonably set according to the actual situation, for example, two to three times, etc., and the embodiments of the present application do not limit this.
  • this solution can ensure that the terminal device can achieve automatic recovery more safely, increase the reliability of the terminal device after abnormal AVB verification failure, ensure that the terminal device can self-recover under abnormal circumstances, and greatly reduce the probability of terminal device crashing due to probabilistic failure of partition mirror AVB verification.
  • the terminal device is in normal use, and before that, a system boot partition of the terminal device has failed to roll back after an OTA upgrade.
  • one of the two system boot partitions of the terminal device is in a normal bootable state, and the other is in an abnormal unbootable state.
  • the terminal device starts the slot_a partition normally when it is turned on. If the AVB verification of the slot_a partition image fails, the terminal device restarts the slot_a partition. If the slot_a partition is successfully started when the slot_a partition is restarted, it indicates that the failure of the AVB verification of the slot_a partition image is a probabilistic problem, and the terminal device can be started normally through the restart recovery strategy. If the slot_a partition image fails the AVB verification again when the slot_a partition is restarted, the terminal device restarts the slot_a partition again.
  • slot_a partition If the slot_a partition is successfully started when the slot_a partition is restarted again, it indicates that the failure of the AVB verification of the slot_a partition image is a probabilistic problem, and the terminal device can be started normally through the restart recovery strategy. If the slot_a partition image fails the AVB verification again when the slot_a partition is restarted again, it indicates that the failure of the AVB verification of the slot_a partition image is a non-probabilistic problem, and the slot_a partition image may be permanently damaged.
  • the slot_a partition needs to be set to active before the terminal device restarts.
  • the terminal device needs to switch to the slot_b partition to continue booting, it first needs to judge the attributes of the slot_b partition. If the attributes of the slot_b partition are in a normal bootable state, the terminal device switches to the slot_b partition to continue booting. The subsequent process can refer to scenario 1 and will not be repeated here. If the attributes of the slot_b partition are in an abnormal unbootable state, the terminal device directly enters Fastboot mode.
  • terminal devices can be divided into two types: one is the terminal device after the OTA upgrade is successful, and both partitions are bootable, and the other is the terminal device after the OTA upgrade fails and rolls back, at which time the other partition of the terminal device is not bootable. Therefore, when the AVB image verification fails during the use of the terminal device (non-OTA upgrade), it is necessary to determine whether the terminal device can boot the partition. Only when the partition is bootable will the partition-cutting recovery strategy be executed.
  • the images of the two system boot partitions should be consistent.
  • the image of the slot_a partition is image 1
  • the image of the slot_b partition is also image 1
  • the image of the slot_a partition does not change to image 1
  • the image of the slot_b partition is not successfully upgraded and is still image 1.
  • the terminal device OTA upgrade fails and rolls back
  • the slot_a partition has been restarted multiple times to eliminate the probabilistic AVB image verification failure problem
  • the attribute of the slot_b partition needs to be set to active before switching to the slot_b partition to start.
  • the terminal device is in the OTA upgrade state.
  • the terminal device When the terminal device is in the OTA upgrade state, if the partition image has an AVB verification failure problem, in order to ensure the normal execution of the OTA native upgrade process, the terminal device will not execute the recovery strategy determined based on the probabilistic AVB verification failure problem.
  • the terminal device detects that the partition image AVB verification fails, it first determines whether the slot_a partition is in the OTA upgrade process. If the slot_a partition is in the OTA upgrade process, it continues to boot according to the existing logic, otherwise it continues to boot according to the system boot logic provided in the embodiment of the present application, which can refer to scenario 1 and scenario 2, and will not be repeated here.
  • the slot_a partition is in the process of OTA upgrade
  • the recovery strategy determined based on the probabilistic AVB verification failure problem will not be executed, but the system will be rolled back to the slot_b partition according to the logic of OTA upgrade failure.
  • the normal usage scenarios of the terminal device and the OTA upgrade scenarios are partitioned, so that the terminal device executes the recovery strategy determined based on the probabilistic AVB verification failure problem, which will not affect the native OTA upgrade process and ensure that the OTA native upgrade process can be executed normally.
  • the terminal device may include a Bootloader boot framework, a boot fault detection (BootDetector) module, a boot fault recovery (BootRecovery) module, and a BootLoader boot framework. Modules and adapters.
  • Bootloader is used to perform no-boot fault detection, and in the embodiment of the present application is specifically used to detect whether the partition image AVB verification fails;
  • BootDetector is used to handle no-boot faults, and in the embodiment of the present application is specifically used for the partition image AVB verification failure fault;
  • BootRecovery is used to determine and record the fault recovery strategy, and in the embodiment of the present application is specifically used to determine and record the fault recovery strategy corresponding to the partition image AVB verification failure.
  • the physical resources of the terminal device include storage partitions and reserved physical memory.
  • the reserved physical memory is used to store identification information of the current startup phase of the system.
  • the system startup phase includes but is not limited to the Bootloader startup phase, the kernel startup phase, the Android startup phase, etc.
  • the storage partition can be used to store the system startup information and system recovery information of the terminal device.
  • the system startup information may at least include system startup log information, and each group of log information at least includes log header information, Bootloader log information and kernel log information.
  • the log header information is used to describe the number of bytes occupied by the Bootloader log information and the kernel log information.
  • the system recovery information may at least include the policy information adopted for system recovery, and may also include a system recovery record.
  • the format and field distribution of the storage partition are not limited in the embodiments of the present application.
  • the storage partition can be designed as a raw partition.
  • a pre-packaged adapter is also provided in the terminal device so that BootDetector and BootRecovery can access the storage partitions (raw partitions) corresponding to different chip platforms through the adapter.
  • FIG9 exemplarily shows a schematic diagram of module interaction.
  • the steps of the system startup method provided in the embodiment of the present application specifically include:
  • the Bootloader detects whether there is a failure to boot.
  • the Bootloader is used to detect whether the image of the slot partition of the startup system has an AVB verification failure problem.
  • the Bootloader When the Bootloader detects that the AVB verification of the slot partition image fails, the BootDetector is called to handle the boot failure. In this embodiment, the Bootloader calls the BootDetector to handle the AVB verification failure of the slot partition image.
  • the processing parameters set may include but are not limited to: slot partition identifier, whether the slot partition is bootable (unbootable or bootable).
  • the slot partition identifier included in the processing parameters is used to indicate the partition where the mirror AVB verification fails.
  • BootDetector After receiving the call from Bootloader, BootDetector first checks the validity of the processing parameters. If the processing parameters are valid, it continues to execute. Otherwise, it does not respond to the call from Bootloader.
  • BootDetector continues to call BootRecovery to obtain the corresponding recovery strategy.
  • the parameters when BootDetector calls BootRecovery may include but are not limited to: slot partition Identifies whether the slot partition is bootable (unbootable or bootable).
  • the slot partition identifier included in the parameter is used to indicate the partition where the mirror AVB verification fails.
  • BootRecovery can read the recovery record corresponding to the current boot in the storage partition (raw partition).
  • the recovery record may include but is not limited to: slot partition identifier, number of AVB verification failures, etc. It should be noted that the recovery record can also be stored in other partitions, which is not limited in this embodiment.
  • BootRecovery verifies the read recovery record to ensure the accuracy and legitimacy of the read recovery record. After determining that the read recovery record passes the verification, the recovery record is corrected and stored.
  • the recovery record read is: slot_a partition
  • the number of AVB verification failures is 1, then when the BootDetector call parameter indicates that the partition where the current image AVB verification failure occurs is slot_a partition, the recovery record is corrected to slot_a partition, the number of AVB verification failures is 2.
  • the recovery record read is: slot_a partition, the number of AVB verification failures is 3, then when the BootDetector call parameter indicates that the partition where the current image AVB verification failure occurs is the slot_b partition, the recovery record will be corrected to slot_a partition, the number of AVB verification failures is 3; slot_b partition, the number of AVB verification failures is 1.
  • the read recovery record is empty
  • the BootDetector call parameter indicates that the partition where the current image AVB verification failure occurs is the slot_a partition
  • the recovery record is corrected to the slot_a partition, and the number of AVB verification failures is 1.
  • BootRecovery selects the current recovery strategy based on the corrected recovery record.
  • the AVB verification failure threshold value x1 can be set to an integer greater than 2
  • the AVB verification failure threshold value x2 can be set to an integer greater than 1.
  • the AVB verification failure threshold of the slot_a partition is x1. Since the terminal device starts in the slot_b partition after the partition switch, the AVB verification failure threshold of the slot_b partition is x2.
  • the AVB verification failure number threshold x1 set by the terminal device before the partition switching can be set to 3
  • the AVB verification failure number threshold x2 set by the terminal device after the partition switching can be set to 2. It can be understood that the AVB verification failure number threshold mentioned here is only an exemplary example, and can be reasonably set according to the actual situation, which can not only solve the probabilistic problem of partition mirror AVB verification failure, but also will not affect the user experience due to too many restarts.
  • BootRecovery determines, based on the recovery record, that the number of AVB verification failures of the slot_a partition is less than the threshold x1, the current recovery strategy is to restart the system in the slot_a partition.
  • the current recovery strategy is determined to switch to the slot_b partition for system startup.
  • BootRecovery determines based on the recovery record that the number of AVB verification failures of the slot_a partition is equal to the threshold x1, and the number of AVB verification failures of the slot_b partition is less than the threshold x2, then the current recovery strategy is to Restart the system in the area.
  • BootRecovery determines, based on the recovery record, that the number of AVB verification failures of the slot_a partition is equal to the threshold x1, and the number of AVB verification failures of the slot_b partition is equal to the threshold x2, then determines the current recovery strategy to enter the Fastboot mode.
  • BootRecovery After determining the current recovery strategy, BootRecovery saves the recovery strategy to the storage partition (raw partition).
  • BootDetector After BootDetector receives the recovery strategy fed back by BootRecovery, it generates a system recovery log (Bootloader log) and writes it to the storage partition (raw partition) so that the corresponding recovery strategy can be located based on the log information for easy reading.
  • system recovery log Bootloader log
  • BootDetector adaptively updates the log meta information according to the situation of writing Bootloader log in the storage partition (raw partition).
  • the log meta information is used to describe the log information stored in the storage partition (raw partition).
  • BootDetector executes the corresponding recovery strategy according to the recovery strategy instructions fed back by BootRecovery.
  • the Bootloader When the recovery strategy instructs to restart the system in the slot_a partition, or switch to the slot_b partition to start the system, or restart the system in the slot_b partition, the Bootloader performs the corresponding restart and boot operation.
  • the Bootloader When the recovery policy instructs to enter Fastboot mode, the Bootloader performs the corresponding operation of entering Fastboot mode.
  • the recovery strategy indicates to restart the system in the slot_a partition, or switch to the slot_b partition to start the system, or restart the system in the slot_b partition.
  • the Bootloader performs the corresponding restart operation to enable the terminal device to start successfully and avoid the terminal device from entering the Fastboot mode.
  • BootCollector is a module in the Android system application layer, which is used to collect the log information of the terminal device during the startup process and the system recovery result.
  • BootCollector can read the log information and system recovery results corresponding to the last boot in the current boot process in the storage partition (raw partition), or can read all the log information and system recovery results in the current boot process. This embodiment of the application does not limit this.
  • BootCollector can generate an AVB check failure message for each slot partition.
  • the problem, the recovery strategy executed, and whether the system startup is successful are recorded accordingly, for example, in the form of a log.
  • the operation and maintenance personnel can analyze whether the current boot partition has been restarted due to the probabilistic problem of image AVB verification failure based on the corresponding log information, and whether the image AVB verification is successful and the system starts successfully after the restart.
  • the electronic device 100 may be a terminal, which may also be referred to as a terminal device, and the terminal may be a device such as a cellular phone or a tablet computer (pad), which is not limited in this application.
  • the electronic device 100 shown in FIG10 is only an example of an electronic device, and the electronic device 100 may have more or fewer components than those shown in the figure, may combine two or more components, or may have different component configurations.
  • the various components shown in FIG10 may be implemented in hardware, software, or a combination of hardware and software, including one or more signal processing and/or application-specific integrated circuits.
  • 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 charging management module 140, a power management module 141, a battery 142, an antenna 1, an antenna 2, a mobile communication module 150, a wireless communication module 160, an audio module 170, a speaker 170A, a receiver 170B, a microphone 170C, an earphone interface 170D, a sensor module 180, a button 190, a motor 191, an indicator 192, a camera 193, a display screen 194, and a subscriber identification module (SIM) card interface 195, etc.
  • SIM subscriber identification module
  • the sensor module 180 may include a pressure sensor, a gyroscope sensor, an acceleration sensor, a temperature sensor, a motion sensor, an air pressure sensor, a magnetic sensor, a distance sensor, a proximity light sensor, a fingerprint sensor, a touch sensor, an ambient light sensor, a bone conduction sensor, etc.
  • the processor 110 may include one or more processing units, for example, the processor 110 may include an application processor (AP), a modem processor, a graphics processor (GPU), an image signal processor (ISP), a controller, a memory, a video codec, a digital signal processor (DSP), a baseband processor, and/or a neural-network processing unit (NPU), etc.
  • AP application processor
  • GPU graphics processor
  • ISP image signal processor
  • controller a memory
  • video codec a digital signal processor
  • DSP digital signal processor
  • NPU neural-network processing unit
  • Different processing units may be independent devices or integrated in one or more processors.
  • 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.
  • a memory may also be provided in the processor 110 for storing instructions and data.
  • the memory in the processor 110 is a cache memory.
  • the USB interface 130 is an interface that complies with the USB standard specification, and specifically can be a Mini USB interface, a Micro USB interface, a USB Type C interface, etc.
  • the USB interface 130 can be used to connect a charger to charge the electronic device 100, and can also be used to transmit data between the electronic device 100 and a peripheral device. It can also be used to connect headphones to play audio through the headphones.
  • the interface can also be used to connect other electronic devices, such as AR devices, etc.
  • the charging management module 140 is used to receive charging input from a charger.
  • the charger may be a wireless charger or a wired charger.
  • the charging management module 140 may receive charging input from a wired charger via the USB interface 130.
  • the charging management module 140 may receive wireless charging input via a wireless charging coil of the electronic device 100.
  • the charging management module 140 may be configured to receive charging input from the battery 142. While charging, the power management module 141 can also be used to power the electronic device.
  • the power management module 141 is used to connect the battery 142, the charging management module 140 and the processor 110.
  • the power management module 141 receives input from the battery 142 and/or the charging management module 140 to power the processor 110, the internal memory 121, the external memory, the display screen 194, the camera 193, and the wireless communication module 160.
  • the wireless communication function of the electronic device 100 can be implemented through the antenna 1, the antenna 2, the mobile communication module 150, the wireless communication module 160, the modem processor and the baseband processor.
  • Antenna 1 and antenna 2 are used to transmit and receive electromagnetic wave signals.
  • Each antenna in electronic device 100 can be used to cover a single or multiple communication frequency bands. Different antennas can also be reused to improve the utilization of antennas.
  • antenna 1 can be reused as a diversity antenna for a wireless local area network.
  • the antenna can be used in combination with a tuning switch.
  • the mobile communication module 150 can provide solutions for wireless communications including 2G/3G/4G/5G, etc., applied to the electronic device 100.
  • the mobile communication module 150 may include at least one filter, a switch, a power amplifier, a low noise amplifier (LNA), etc.
  • LNA low noise amplifier
  • the wireless communication module 160 can provide wireless communication solutions for application in the electronic device 100, including wireless local area networks (WLAN) (such as wireless fidelity (Wi-Fi) network), Bluetooth (BT), global navigation satellite system (GNSS), frequency modulation (FM), near field communication technology (NFC), infrared technology (IR), etc.
  • WLAN wireless local area networks
  • Wi-Fi wireless fidelity
  • BT Bluetooth
  • GNSS global navigation satellite system
  • FM frequency modulation
  • NFC near field communication technology
  • IR infrared technology
  • antenna 1 of electronic device 100 is coupled to mobile communication module 150, and antenna 2 is coupled to wireless communication module 160, so that electronic device 100 can communicate with the network and other devices through wireless communication technology.
  • the electronic device 100 implements the display function through a GPU, a display screen 194, and an application processor.
  • the GPU is a microprocessor for image processing, which connects the display screen 194 and the application processor.
  • the GPU is used to perform mathematical and geometric calculations for graphics rendering.
  • the processor 110 may include one or more GPUs that execute program instructions to generate or change display information.
  • the display screen 194 is used to display images, videos, etc.
  • the display screen 194 includes a display panel.
  • the electronic device 100 may include 1 or N display screens 194, where N is a positive integer greater than 1.
  • the electronic device 100 can realize the shooting function through ISP, camera 193, video codec, GPU, display screen 194 and application processor.
  • the ISP is used to process the data fed back by the camera 193. For example, when taking a photo, the shutter is opened, and the light is transmitted to the camera photosensitive element through the lens. The light signal is converted into an electrical signal, and the camera photosensitive element transmits the electrical signal to the ISP for processing and converts it into an image visible to the naked eye.
  • the ISP can also perform algorithm optimization on the noise, brightness, and skin color of the image. The ISP can also optimize the exposure, color temperature and other parameters of the shooting scene. In some embodiments, the ISP can be set in the camera 193.
  • Camera 193 is used to capture still images or videos.
  • the object generates an optical image through the lens and projects it onto the photosensitive element.
  • the photosensitive element can be a charge coupled device (CCD) or a complementary metal-oxide-semiconductor (CMOS) phototransistor.
  • CMOS complementary metal-oxide-semiconductor
  • the photosensitive element converts the light signal into an electrical signal, and then passes the electrical signal to the ISP for conversion into a digital image signal.
  • the ISP outputs the digital image signal to the DSP for processing.
  • the DSP converts the digital image signal into an image signal in a standard RGB, YUV or other format.
  • the electronic device 100 may include 1 or N cameras 193 , where N is a positive integer greater than 1.
  • the external memory interface 120 can be used to connect an external memory card, such as a Micro SD card, to expand the storage capacity of the electronic device 100.
  • the external memory card communicates with the processor 110 through the external memory interface 120 to implement a data storage function.
  • 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, enabling the electronic device 100 to implement the system startup method in the embodiment of the present application.
  • the internal memory 121 may include a program storage area and a data storage area.
  • 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.
  • the data storage area may store data created during the use of the electronic device 100 (such as audio data, a phone book, etc.), etc.
  • 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.
  • UFS universal flash storage
  • the electronic device 100 can implement audio functions such as music playing and recording through the audio module 170, the speaker 170A, the receiver 170B, the microphone 170C, the headphone jack 170D, and the application processor.
  • the audio module 170 is used to convert digital audio information into analog audio signal output, and is also used to convert analog audio input into digital audio signals.
  • the audio module 170 can also be used to encode and decode audio signals.
  • the audio module 170 can be arranged in the processor 110, or some functional modules of the audio module 170 can be arranged in the processor 110.
  • the speaker 170A also called a "speaker" is used to convert an audio electrical signal into a sound signal.
  • the electronic device 100 can listen to music or listen to a hands-free call through the speaker 170A.
  • the electronic device 100 can be provided with a plurality of speakers 170A.
  • the receiver 170B also called a "earpiece" is used to convert audio electrical signals into sound signals.
  • the voice can be received by placing the receiver 170B close to the human ear.
  • Microphone 170C also called “microphone” or “microphone” is used to convert sound signals into electrical signals. When making a call or sending a voice message, the user can speak by putting their mouth close to microphone 170C to input the sound signal into microphone 170C.
  • the electronic device 100 can be provided with at least one microphone 170C. In other embodiments, the electronic device 100 can be provided with two microphones 170C, which can not only collect sound signals but also realize noise reduction function. In other embodiments, the electronic device 100 can also be provided with three, four or more microphones 170C to collect sound signals, reduce noise, identify the sound source, realize directional recording function, etc.
  • the earphone interface 170D is used to connect a wired earphone.
  • the earphone interface 170D may be the USB interface 130, or may be a 3.5 mm open mobile terminal platform (OMTP) standard interface or a cellular telecommunications industry association of the USA (CTIA) standard interface.
  • OMTP open mobile terminal platform
  • CTIA cellular telecommunications industry association of the USA
  • the pressure sensor is used to sense the pressure signal and can convert the pressure signal into an electrical signal.
  • the pressure sensor can be disposed on the display screen 194.
  • the electronic device 100 can also calculate the touch position according to the detection signal of the pressure sensor.
  • the gyro sensor may be used to determine the motion posture of the electronic device 100.
  • the angular velocity of the electronic device 100 around three axes ie, x, y, and z axes
  • the gyro sensor may be used to determine the motion posture of the electronic device 100.
  • the accelerometer can detect the magnitude of the acceleration of the electronic device 100 in all directions (generally three axes). When the electronic device 100 is stationary, the accelerometer can detect the magnitude and direction of gravity. The accelerometer can also be used to identify the posture of the electronic device, and is applied to applications such as horizontal and vertical screen switching, pedometers, etc.
  • the touch sensor is also called a "touch panel”.
  • the touch sensor can be set on the display screen 194.
  • the touch sensor and the display screen 194 form a touch screen, also called a "touch screen”.
  • the touch sensor is used to detect a touch operation on or near it.
  • the touch sensor can pass the detected touch operation to the application processor to determine the type of touch event.
  • the key 190 includes a power key (or power key), a volume key, etc.
  • the key 190 may be a mechanical key or a touch key.
  • the electronic device 100 may receive key input and generate key signal input related to user settings and function control of the electronic device 100.
  • Motor 191 can generate vibration prompts.
  • Motor 191 can be used for incoming call vibration prompts, and can also be used for touch vibration feedback.
  • touch operations acting on different applications can correspond to different vibration feedback effects.
  • the indicator 192 may be an indicator light, which may be used to indicate the charging status, power changes, messages, missed calls, notifications, etc.
  • the software system of the electronic device 100 may adopt a layered architecture, an event-driven architecture, a micro-core architecture, a micro-service architecture, or a cloud architecture.
  • the embodiment of the present application takes the Android system of the layered architecture as an example to exemplify the software structure of the electronic device 100.
  • FIG. 11 is a software structure block diagram of the electronic device 100 according to an embodiment of the present application.
  • the layered architecture of the electronic device 100 divides the software into several layers, each with a clear role and division of labor.
  • the layers communicate with each other through software interfaces.
  • the Android system is divided into four layers, from top to bottom, namely, the application layer, the application framework layer, the Android Runtime and the system library, and the kernel layer.
  • the application layer can include a series of application packages.
  • the application package may include applications such as camera, calendar, map, WLAN, music, short message, gallery, call, video, etc.
  • the application package may also include a BootCollector (boot data collection) module, wherein the BootCollector module may be used to collect log information and system recovery results of the terminal device during the boot process.
  • BootCollector boot data collection
  • the application framework layer provides application programming interface (API) and programming framework for the applications in the application layer.
  • API application programming interface
  • the application framework layer includes some predefined functions.
  • the application framework layer may include a window manager, a content provider, a view system, a telephony manager, a resource manager, a notification manager, and the like.
  • the window manager is used to manage window programs.
  • the window manager can obtain the display screen size, determine whether there is a status bar, lock the screen, capture the screen, etc.
  • Content providers are used to store and retrieve data and make it accessible to applications.
  • the data may include videos, images, audio, calls made and received, browsing history and bookmarks, phone books, etc.
  • the view system includes visual controls, such as controls for displaying text, controls for displaying images, etc.
  • the view system can be used
  • the display interface can be composed of one or more views.
  • the display interface including the SMS notification icon can include a view for displaying text and a view for displaying pictures.
  • the phone manager is used to provide communication functions of the electronic device 100, such as management of call status (including connecting, hanging up, etc.).
  • the resource manager provides various resources for applications, such as localized strings, icons, images, layout files, video files, and so on.
  • the notification manager enables applications to display notification information in the status bar, which can be used to convey notification-type messages and can disappear automatically after a short stay without user interaction.
  • notification information is used to inform the completion of downloads, message reminders, etc.
  • Notification information can also be a notification that appears in the system top status bar in the form of a chart or scroll bar text, such as a notification of an application running in the background.
  • Notification information can also be a notification that appears on the screen in the form of a dialog window.
  • Notification information can also be, for example, a text message in the status bar, a reminder sound, a vibration of an electronic device, a flashing indicator light, etc.
  • Android Runtime includes core libraries and virtual machines. Android Runtime is responsible for the scheduling and management of the Android system.
  • the core library consists of two parts: one part is the function that needs to be called by the Java language, and the other part is the Android core library.
  • the application layer and the application framework layer run in a virtual machine.
  • the virtual machine executes the Java files of the application layer and the application framework layer as binary files.
  • the virtual machine is used to perform functions such as object life cycle management, stack management, thread management, security and exception management, and garbage collection.
  • the system library can include multiple functional modules, such as surface manager, media library, 3D graphics processing library (such as OpenGL ES), 2D graphics engine (such as SGL), etc.
  • functional modules such as surface manager, media library, 3D graphics processing library (such as OpenGL ES), 2D graphics engine (such as SGL), etc.
  • the surface manager is used to manage the display subsystem and provide the fusion of 2D and 3D layers for multiple applications.
  • the media library supports playback and recording of a variety of commonly used audio and video formats, as well as static image files, etc.
  • the media library can support a variety of audio and video encoding formats, such as: MPEG4, H.264, MP3, AAC, AMR, JPG, PNG, etc.
  • the 3D graphics processing library is used to implement 3D graphics drawing, image rendering, compositing, and layer processing.
  • a 2D graphics engine is a drawing engine for 2D drawings.
  • the kernel layer is the layer between hardware and software.
  • the kernel layer includes at least display driver, audio driver, Wi-Fi driver, Bluetooth driver, sensor driver, etc.
  • the hardware includes at least processor, display, Wi-Fi module, sensor, etc.
  • the layers in the software structure shown in FIG11 and the components contained in each layer do not constitute a specific limitation on the electronic device 100.
  • the electronic device 100 may include more or fewer layers than shown in the figure, and each layer may include more or fewer components, which is not limited in the present application.
  • the electronic device includes hardware and/or software modules corresponding to executing various functions.
  • 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, However, such implementation should not be considered beyond the scope of this application.
  • This embodiment further provides a computer storage medium, in which computer instructions are stored.
  • the computer instructions When the computer instructions are executed on an electronic device, the electronic device executes the above-mentioned related method steps to implement the system startup method in the above-mentioned embodiment.
  • This embodiment further provides a computer program product.
  • the computer program product When the computer program product is run on a computer, the computer is caused to execute the above-mentioned related steps to implement the system startup method in the above-mentioned embodiment.
  • an embodiment of the present application also provides a device, which can specifically be a chip, component or module, and the device may include a connected processor and memory; wherein the memory is used to store computer execution instructions, and when the device is running, the processor can execute the computer execution instructions stored in the memory so that the chip executes the system startup method in the above-mentioned method embodiments.
  • the electronic device such as a mobile phone, etc.
  • computer storage medium, computer program product or chip provided in this embodiment 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.
  • the disclosed devices and methods can be implemented in other ways.
  • the device embodiments described above are only schematic, for example, the division of modules or units is only a logical function division, and there may be other division methods in actual implementation, such as multiple units or components can be combined or integrated into another device, or some features can be ignored or not executed.
  • Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

Abstract

本申请实施例提供了一种系统启动方法及电子设备。在该方法中，电子设备在其中一个系统启动分区中进行系统启动的过程中，如果该系统启动分区的镜像校验失败，则电子设备继续在该系统启动分区中进行系统重启；电子设备在第一系统启动分区中系统重启成功。这样能够解决系统启动分区的镜像校验失败的概率性问题，提高电子设备在系统启动过程中的自恢复能力，极大减少了电子设备由于镜像校验概率性失败而导致死机的几率。

Description

系统启动方法及电子设备
本申请要求于2022年10月09日提交中国国家知识产权局、申请号为202211229448.1、申请名称为“系统启动方法及电子设备”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。
技术领域
本申请涉及智能终端技术领域，尤其涉及一种系统启动方法及电子设备。
背景技术
从终端设备的开机总体流程上来看，终端设备上电后首先运行的是BootLoader。也即，在嵌入式操作系统中，BootLoader是在操作系统内核运行之前运行的。BootLoader可以初始化硬件设备、建立内存空间映射图，从而将系统的软硬件环境带到一个合适状态，以便为最终调用操作系统内核准备好正确的环境。
其中，在BootLoader阶段，会对各个系统启动分区镜像进行校验，一旦各个系统启动分区镜像均校验失败，终端设备就会进入Fastboot模式。此时，用户需要请专业维护人员来解决。鉴于用户越来越依赖于以智能手机为代表的移动智能终端，终端系统进入Fastboot模式无疑会给用户的生活和工作带来严重困扰。
因此，在移动智能终端在BootLoader阶段遇到开机故障时，如何降低终端进入Fastboot模式的几率是需要解决的问题。
发明内容
为了解决上述技术问题，本申请实施例提供一种系统启动方法及电子设备。在该方法中，电子设备在其中一个系统启动分区中进行系统启动的过程中，如果该系统启动分区的镜像校验失败，则电子设备继续在该系统启动分区中进行系统重启，以此解决系统启动分区的镜像校验失败的概率性问题，提高电子设备在系统启动过程中的自恢复能力，极大减少了电子设备由于镜像校验概率性失败而导致死机的几率。
第一方面，本申请实施例提供一种系统启动方法。该方法应用于电子设备中，电子设备包括第一系统启动分区和第二系统启动分区。该方法包括：包括：
电子设备在第一系统启动分区中进行系统启动的过程中，如果第一系统启动分区的镜像校验失败，则电子设备在第一系统启动分区中进行系统重启；
电子设备在第一系统启动分区中系统重启成功。
镜像校验失败大部分是概率性问题，示例性的，原因可能是由电平调变、硬件器件的概率性故障导致，并非是永久性损坏问题。
这样，如果某个系统启动分区的镜像校验失败，则电子设备继续在该系统启动分区中进行系统重启，以此解决系统启动分区的镜像校验失败的概率性问题，提高电子设备在系统启动过程中的自恢复能力，极大减少了电子设备由于镜像校验概率性失败而导致 死机的几率。
根据第一方面，该方法还包括：在电子设备在第一系统启动分区中进行系统重启的过程中，如果第一系统启动分区的镜像校验失败，则电子设备切换到第二系统启动分区中进行系统启动；
电子设备在第二系统启动分区中进行系统启动的过程中，如果第二系统启动分区的镜像校验失败，则电子设备在第二系统启动分区中进行系统重启；
电子设备在第二系统启动分区中系统重启成功。
其中，第一系统启动分区和第二系统启动分区互为备份分区。
这样，如果某个系统启动分区的镜像校验失败非概率性问题，则电子设备切换到对区进行启动。当电子设备在对区启动时，如果对区的镜像校验也失败，则电子设备继续在对区中进行系统重启，以此解决系统启动分区的镜像校验失败的概率性问题，提高电子设备在系统启动过程中的自恢复能力，极大减少了电子设备由于镜像校验概率性失败而导致死机的几率。
根据第一方面，或者以上第一方面的任意一种实现方式，电子设备切换到第二系统启动分区中进行系统启动，可以包括：如果第二系统启动分区的属性为可启动状态，则电子设备切换到第二系统启动分区中进行系统启动。
在一种应用场景下，电子设备对第二系统启动分区OTA升级成功，则第一系统启动分区和第二系统启动分区的属性均为可启动状态，电子设备可以在两个分区之间进行切换。
根据第一方面，或者以上第一方面的任意一种实现方式，该方法还包括：如果第二系统启动分区的属性为不可启动状态，则电子设备进行快速启动模式。
在一种应用场景下，电子设备对第二系统启动分区OTA时，如果升级失败发生回滚，则第二系统启动分区的属性为不可启动状态，此时电子设备不会在两个分区之间进行切换，而是在第一系统启动分区被确认为非概率性损坏问题时，电子设备进行快速启动模式(Fastboot模式)。
根据第一方面，或者以上第一方面的任意一种实现方式，该方法还包括：在电子设备在第二系统启动分区中进行系统重启的过程中，如果第二系统启动分区的镜像校验失败，则电子设备进行快速启动模式。
在一种应用场景下，电子设备确认第一系统启动分区和第二系统启动分区均非概率性损坏问题时，电子设备进行快速启动模式(Fastboot模式)。
根据第一方面，或者以上第一方面的任意一种实现方式，如果第一系统启动分区的镜像校验失败，则电子设备在第一系统启动分区中进行系统重启，包括：
如果第一系统启动分区的镜像校验失败，且第一系统启动分区的镜像校验失败次数 小于第一阈值，则电子设备在第一系统启动分区中进行系统重启；
如果第一系统启动分区的镜像校验失败，则电子设备切换到第二系统启动分区中进行系统启动，包括：
如果第一系统启动分区的镜像校验失败，且第一系统启动分区的镜像校验失败次数等于第一阈值，则电子设备切换到第二系统启动分区中进行系统启动；其中，第一阈值大于2。
示例性的，第二阈值为3。
这样，如果某个系统启动分区的镜像校验失败，则电子设备继续在该系统启动分区中多次(例如两到三次)进行系统重启，以此解决系统启动分区的镜像校验失败的概率性问题，提高电子设备在系统启动过程中的自恢复能力，避免电子设备进入Fastboot模式。若电子设备在该系统启动分区中多次进行系统重启均无法正常启动，则可以确认该系统启动分区非概率性损坏问题，此时电子设备切换分区继续启动。
根据第一方面，或者以上第一方面的任意一种实现方式，如果第二系统启动分区的镜像校验失败，则电子设备在第二系统启动分区中进行系统重启，包括：
如果第二系统启动分区的镜像校验失败，且第二系统启动分区的镜像校验失败次数小于第二阈值，则电子设备在第二系统启动分区中进行系统重启；其中，第二阈值大于1。
示例性的，第二阈值为2。
这样，在电子设备进行分区切换后，如果某个系统启动分区的镜像校验失败，则电子设备继续在该系统启动分区中多次(例如两到三次)进行系统重启，以此解决系统启动分区的镜像校验失败的概率性问题，提高电子设备在系统启动过程中的自恢复能力，避免电子设备进入Fastboot模式。
根据第一方面，或者以上第一方面的任意一种实现方式，如果第一系统启动分区的镜像校验失败，则电子设备在第一系统启动分区中进行系统重启，包括：
如果第一系统启动分区的镜像校验失败，且第一系统启动分区未处于OTA升级中，则电子设备在第一系统启动分区中进行系统重启。
这样，将终端设备的正常使用场景与OTA升级场景进行分区，使终端设备执行基于概率性AVB校验失败问题而确定的恢复策略，不会对原生的OTA升级流程产生影响，确保了OTA原生升级流程可以正常则执行。
根据第一方面，或者以上第一方面的任意一种实现方式，在电子设备在第一系统启动分区中进行系统重启时，还包括：记录与第一系统启动分区的镜像校验失败对应的日志信息以及恢复策略，恢复策略为电子设备在第一系统启动分区中进行系统重启。
根据第一方面，或者以上第一方面的任意一种实现方式，在电子设备在第二系统启动分区中进行系统重启时，还包括：记录与第二系统启动分区的镜像校验失败对应的日志信息以及恢复策略，恢复策略为电子设备在第二系统启动分区中进行系统重启。
根据第一方面，或者以上第一方面的任意一种实现方式，在电子设备切换到第二系统启动分区中进行系统启动时，还包括：记录与第一系统启动分区的镜像校验失败对应的日志信息以及恢复策略，恢复策略为电子设备切换到第二系统启动分区中进行系统启动。
根据第一方面，或者以上第一方面的任意一种实现方式，在电子设备系统启动成功后，还包括：向云端上传日志信息及恢复策略。
第二方面，本申请实施例提供一种电子设备。该电子设备包括：一个或多个处理器；存储器；以及一个或多个计算机程序，其中一个或多个计算机程序存储在存储器上，当计算机程序被一个或多个处理器执行时，使得电子设备执行第一方面以及第一方面中任意一项的系统启动方法。
第二方面以及第二方面的任意一种实现方式分别与第一方面以及第一方面的任意一种实现方式相对应。第二方面以及第二方面的任意一种实现方式所对应的技术效果可参见上述第一方面以及第一方面的任意一种实现方式所对应的技术效果，此处不再赘述。
第三方面，本申请实施例提供一种计算机可读存储介质。该计算机可读存储介质包括计算机程序，当计算机程序在电子设备上运行时，使得电子设备执行第一方面以及第一方面中任意一项的系统启动方法。
第三方面以及第三方面的任意一种实现方式分别与第一方面以及第一方面的任意一种实现方式相对应。第三方面以及第三方面的任意一种实现方式所对应的技术效果可参见上述第一方面以及第一方面的任意一种实现方式所对应的技术效果，此处不再赘述。
第四方面，本申请实施例提供一种计算机程序产品，包括计算机程序，当计算机程序被运行时，使得计算机执行如第一方面或第一方面中任意一项的系统启动方法。
第四方面以及第四方面的任意一种实现方式分别与第一方面以及第一方面的任意一种实现方式相对应。第四方面以及第四方面的任意一种实现方式所对应的技术效果可参见上述第一方面以及第一方面的任意一种实现方式所对应的技术效果，此处不再赘述。
第五方面，本申请提供了一种芯片，该芯片包括处理电路、收发管脚。其中，该收发管脚和该处理电路通过内部连接通路互相通信，该处理电路执行如第一方面或第一方面中任意一项的系统启动方法，以控制接收管脚接收信号，以控制发送管脚发送信号。
第五方面以及第五方面的任意一种实现方式分别与第一方面以及第一方面的任意一种实现方式相对应。第五方面以及第五方面的任意一种实现方式所对应的技术效果可参见上述第一方面以及第一方面的任意一种实现方式所对应的技术效果，此处不再赘述。
附图说明
图1为示例性示出的Android系统终端的开机启动流程的框架图；
图2为已有技术中的系统启动流程示意图；
图3a为示例性示出的一种应用场景示意图；
图3b为示例性示出的一种应用场景示意图；
图4为申请实施例提供的系统启动流程示意图之一；
图5为申请实施例提供的系统启动流程示意图之一；
图6为申请实施例提供的系统启动流程示意图之一；
图7为示例性是会出的系统启动时的软件框架示意；
图8为示例性示出的存储分区中的数据示意图；
图9为示例性示出的模块交互示意图；
图10为示例性示出的电子设备的硬件结构示意图；
图11为示例性示出的电子设备的软件结构示意图。
具体实施方式
下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。
本文中术语“和/或”，仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。
本申请实施例的说明书和权利要求书中的术语“第一”和“第二”等是用于区别不同的对象，而不是用于描述对象的特定顺序。例如，第一目标对象和第二目标对象等是用于区别不同的目标对象，而不是用于描述目标对象的特定顺序。
在本申请实施例中，“示例性的”或者“例如”等词用于表示作例子、例证或说明。本申请实施例中被描述为“示例性的”或者“例如”的任何实施例或设计方案不应被解释为比其它实施例或设计方案更优选或更具优势。确切而言，使用“示例性的”或者“例如”等词旨在以具体方式呈现相关概念。
在本申请实施例的描述中，除非另有说明，“多个”的含义是指两个或两个以上。例如，多个处理单元是指两个或两个以上的处理单元；多个系统是指两个或两个以上的系统。
本申请实施例所提供的方法可以应用于各种类型的电子设备。示例性的，本申请实施例中的电子设备可以是手机、平板电脑、桌面型、膝上型、手持型计算机、笔记本电脑、超级移动个人计算机(ultra-mobile personal computer，UMPC)、上网本，以及蜂窝电话、个人数字助理(personal digital assistant，PDA)、增强现实(augmented reality，AR)\虚拟现实(virtual reality，VR)设备等电子设备，本申请实施例对电子设备的具体形态不作特殊限制。
在本申请实施例中，电子设备可以包括硬件层、运行在硬件层之上的操作系统层， 以及运行在操作系统层上的应用层。该硬件层包括中央处理器(central processing unit，CPU)、内存管理单元(memory management unit，MMU)和内存(也称为主存)等硬件。该操作系统可以是任意一种或多种通过进程(process)实现业务处理的计算机操作系统，例如，Android操作系统、iOS操作系统或windows操作系统等。该应用层包含浏览器、通讯录、文字处理软件、即时通信软件等应用。
下述以Android操作系统为例简述终端的开机流程。Android操作系统的启动过程可以分为两个阶段，第一阶段是Linux的启动，第二阶段是Android的启动(可以称为上层开机流程)。图1为一种基于Android系统的终端的开机启动流程的框架图。如图1所示，开机启动流程包括：
01、Boot Rom——当按开机按键的时候，引导芯片开始从固化在ROM的预设代码开始执行，然后加载引导程序到RAM。
02、Bootloader，又称为引导程序，是在操作系统运行之前运行的一段程序，是运行的第一个程序，用于把操作系统镜像文件拷贝到RAM中去，然后跳到镜像文件的入口去执行该文件，也可以称之为进入启动加载模式。
03、Kernel——将内核加载进内存后，首先进入内核引导阶段，在内核引导阶段的最后，调用start_kernel进入内核启动阶段，主要是完成内核的大部分初始化工作。Start_kernel会最终启动用户空间的init进程。
04、init进程——当初始化内核之后，就会启动init进程，在Linux中所有的进程都是由init进程直接或间接fork出来的。init进程负责创建系统中最关键的几个核心daemon(守护)进程，包括但不限于zygote和service manager。其中，zygote是android启动的第一个dalvik虚拟机，它负责启动Java进程。service manager是Binder通信的基础。
05、Zygote进程——该进程是所有Java进程的父进程。例如，zygote虚拟机启动子进程system_server，同时定义了一个Socket，用于接收ActivityManagerService启动应用程序的请求。
06、System Server进程——在System Server进程开启的时候，会初始化ActivityManagerService。同时，会加载本地系统的服务库，调用createSystemContext()创建系统上下文，创建ActivityThread及开启各种服务等等。
07、Home Activity——在ActivityManagerService开启之后，会调用finishBooting()完成引导过程，同时发送开机广播，进入home界面，显示桌面。
在上述开机流程中，Bootloader会对操作系统镜像文件进行合法性校验。由于安卓系统是一个基于内核的操作系统，因此在实际启动的过程中，可以依次将启动操作系统的引导程序镜像、内核镜像、主系统镜像加载至内存，并在内存中依次验证每种镜像的合法性，并仅在前一种镜像经验证合法后才加载下一种镜像至内存，直至主系统镜像也通过合法性验证后，才会将主系统镜像在内核的帮助下展开为用户真正能够看到的主系统程序，至此完成安卓设备的启动全过程。
需要说明的是，此处给出的描述仅是对实际启动过程做了一个较上位的概括，实际启动过程更加复杂，但原理相同，不同版本的安卓系统可能在某些步骤的细节上做了一些调整，此处并不做具体限定。
换句话说，需要在主系统镜像展开为主系统程序前，对其是否满足合法性进行校验，并只有合法性校验通过后，才能展开为主系统程序。一旦主系统镜像合法性校验失败，则安卓系统无法正常启动。
目前，安卓系统终端大多都采用Android A/B分区系统。A/B分区系统，顾名思义是有两套系统，一套系统分区，另一套备份分区。这两套系统出厂时一样，此后可能不一样，一个新版本，另一个旧版本。
假设正常系统启动分区为slot_a，备份系统启动分区为slot_b。当slot_a分区数据发生损坏时，终端设备会自动切换到slot_b分区以重启系统，若slot_b分区不可用或者slot_b分区数据发生损坏时，终端设备会自动进Fastboot模式。其中，Fastboot模式指的是快速启动模式。Fastboot是Android定义的一种简单的刷机协议，可以通过Fastboot命令行工具进行刷机。一旦终端设备进入Fastboot模式，则用户需要请专业维护人员来解决。
在一种实现方式中，在Bootloader中基于AVB(Android verify boot)安全机制对分区镜像文件的数据完整性、可靠性和合法性进行校验。其中，AVB校验功能主要是由external/avb/libavb库实现的，该库主要完成的工作包括各个分区镜像的校验，签名验证，以及vbmeta数据的解析，包括了各种flags的处理以及dm-verity所需要的参数解析。
目前，在系统启动的原生逻辑中，如图2所示，终端设备在开机时正常启动slot_a分区，如果slot_a分区镜像AVB校验失败，则终端设备切换到slot_b分区进行启动，如果slot_b分区启动，则终端开机成功。然而，如果slot_b分区镜像AVB校验失败，则终端设备进入Fastboot模式。
然而，系统启动分区发生数据损坏大部分是概率性问题，原因可能是由电平跳变、硬件器件(如存储介质)的概率性故障导致，并非是永久性损坏问题。例如，硬件存储介质使用时的环境因素、温度因素、静电因素等不可预知的因素都可能导致概率性电平跳变，进而导致系统启动分区镜像校验失败。研究发现，大部分由于分区镜像校验失败而进入Fastboot模式的终端设备，在其系统启动分区被重启激活并再次启动后，都能正常启动，这就更加印证了存储器件存在概率性异常问题，而非是永久性异常。
在实际应用中，由于Android A/B分区系统需要开辟两个boot存储空间和两个system存储空间，这是为了保证升级分区不对运行分区产生影响，是实现系统OTA(Over-the-Air，空中下载)不宕机的一个保障。
在OTA场景下，A/B分区系统更新又称之为无缝更新(Seamless updates)。其中，OTA更新在系统后台运行，该过程中用户仍可以正常使用设备。待更新完成后，需重启一次方可进入新系统。若OTA更新失败后(OTA更新无法应用或应用后无法启动)，设备可重启回滚到旧分区继续使用，并重新尝试更新升级。终端设备可采用流式升级方式，即无需/data或/cache分区留出足够空间用于存储下载的升级包，也可进行OTA升级。终端设备确保在OTA更新期间磁盘上保留一套可以正常启动使用的系统，减少刷机变砖的可能性，减轻售后服务工作量。
在一种实际应用场景中，终端设备对slot_b分区进行OTA升级，OTA升级失败后系统回滚至slot_a分区。此时，slot_a分区正常可启动，slot_b分区无法启动(或称不可启动)。终端设备在开机时正常启动slot_a分区，如果slot_a分区镜像AVB校验失败，则由 于slot_b分区无法启动，终端直接进入Fastboot模式。
在另一种实际应用场景中，终端设备对slot_b分区进行OTA升级，OTA升级成功，slot_b分区正常可启动。此时，slot_a分区正常可启动，slot_b分区也正常可启动。终端设备在开机时正常启动slot_b分区，如果slot_b分区镜像AVB校验失败，则终端设备切换到slot_a分区进行启动，如果slot_a分区启动，则终端开机成功。然而，如果slot_a分区镜像AVB校验失败，则终端设备进入Fastboot模式。
在这些应用场景中，已有逻辑无法处理分区镜像概率性校验失败的问题。一旦分区镜像AVB校验失败就切换分区，切换的分区镜像再次AVB校验失败，则终端进入Fastboot模式，无疑增加了终端设备进入Fastboot模式的几率，缺乏稳定的恢复机制，降低了用户的使用体验。
为了解决上述问题，本申请实施例提供了一种系统启动方法。在该方法中，充分考虑了分区镜像AVB校验概率性失败的问题，设计了一种恢复策略，保证了终端在分区镜像AVB校验概率性失败时，能够自动恢复并正常启动系统，以此降低终端设备进入Fastboot模式的几率，进而提升用户的使用体验。
在本申请实施例中，终端设备系统启动涉及的场景可以包括正常使用场景和OTA升级场景。其中，正常使用场景又可以划分为OTA升级成功场景和OTA升级失败回滚场景。
在基于这几种应用场景对本申请实施例提供的系统启动方法进行阐述之前，对相关概念进行解释说明。
终端设备开机启动可以是用户按压设备的电源键触发的，也可以是由于系统的某些设置自行触发的，例如终端设备定时启动等，还可以是由于系统的某些异常而自行触发的，本申请实施例对此不做限定。
Bootloader为了判断一个系统启动分区是否为可以启动的状态，需要为其定义对应的属性(状态)。示例性的，其状态说明如下：
属性Active，为活动分区标识，排他，代表分区为启动分区，bootloader总会选择该分区进行系统启动；
属性bootable，表示分区存在一套可能可以启动的系统；
属性successful，表示分区的系统能正常启动；
属性unbootable，代表分区损坏，无法启动，在升级过程总被标记。
其中，分区被标记为unbootable时，其他标记(active、bootable、successful)会被清空，而分区被标记为active时，unbootable标记将会被清空。
在slot_a分区和slot_b分区中，只有一个分区可以具有active属性，但两个分区可以同时具有bootable属性和successful属性。
在终端设备开机启动时，bootloader检测到1个或者2个slot分区都是bootable的状态，选择active属性的slot分区或者选择successful属性的slot分区进行尝试启动。如果分区启动成功，则可以设置该分区属性为successful和active；如果分区启动失败，则可以设置该分区属性为unbootable，并设置另一个分区的属性为active进行下一次尝试。
下述结合几个场景对slot分区的属性设置进行说明：
1.普通场景(Normal cases)
普通场景是最常见的情形，例如设备出厂时，slot_a分区和slot_b分区都可以成功启动并正常运行，所以两个分区都设置为bootable和successful。假设从slot_b分区启动，所以只有slot_b分区设置为active。
2.升级中(Update in progress)
slot_b分区检测到升级数据，在slot_a分区进行升级，此时将slot_a分区标识为unbootable，另外清除slot_a分区的successful标识；slot_b分区属性仍然为active，bootable和successful。
3.更新完成，等待重启(Update applied,reboot pending)
slot_b分区将slot_a分区成功更新后，将slot_a分区标识为bootable。另外，由于重启后需要从slot_a分区启动，所以也需要将slot_a分区设置为active。但是，由于还没有验证过slot_a分区是否能成功运行，所以slot_a分区不设置successful；slot_b分区的状态变为bootable和successful，但没有active。
4.重新系统成功启动(System rebooted into new update)
设备重启后，bootloader检测到slot_a分区为active，所以加载slot_a分区系统。进入slot_a分区系统后如果能正常运行，需要将slot_a分区标识为successful。对比普通场景，slot_a分区和slot_b分区都设置为bootable和successful，但active从slot_b分区切换到slot_a分区。至此，slot_b分区成功更新并切换到slot_a分区，设备重新进入普通场景。
场景一
在本场景中，终端设备处于正常使用状态，且在此之前终端设备某个系统启动分区OTA升级成功。此时，终端设备的两个系统启动分区(如slot_a分区和slot_b分区)均处于正常可启动(bootable)状态。
如图4所示，假设slot_a分区的属性为active，终端设备在开机时正常启动slot_a分区。如果slot_a分区镜像AVB校验失败，则终端设备重启slot_a分区。如果重启slot_a分区时，slot_a分区成功启动，则表明果slot_a分区镜像AVB校验失败为概率性问题，通过重启的恢复策略即可使终端设备正常启动。如果重启slot_a分区时，slot_a分区镜像再次AVB校验失败，则终端设备再次重启slot_a分区。如果再次重启slot_a分区时，slot_a分区成功启动，则表明slot_a分区镜像AVB校验失败为概率性问题，通过重启的恢复策略即可使终端设备正常启动。如果再次重启slot_a分区时，slot_a分区镜像又一次AVB校验失败，则表明slot_a分区镜像AVB校验失败非概率性问题，可能为slot_a分区镜像永久性损坏问题，此时切换到slot_b分区继续启动。
需要指出的是，终端设备由于重启后需要从slot_a分区启动，所以终端设备在重启前需要将slot_a分区设置为active。
继续参照图4，在终端设备切换到slot_b分区进行启动时，如果slot_b分区slot_b分区，则此时通过分区切换实现了对终端设备异常开机问题的修复。在终端设备切换到slot_b分区进行启动时，如果slot_b分区镜像AVB校验失败，则终端设备重启slot_b分区。如果重启slot_b分区时，slot_b分区成功启动，则表明果slot_b分区镜像AVB校验 失败为概率性问题，通过重启的恢复策略即可使终端设备正常启动。如果重启slot_b分区时，slot_b分区镜像再次AVB校验失败，则表明slot_b分区镜像AVB校验失败非概率性问题，可能为slot_b分区镜像永久性损坏问题，此时终端设备进入Fastboot模式。
需要指出的是，终端设备由于重启后需要从slot_b分区启动，所以终端设备在重启前需要将slot_b分区设置为active。
在由于某个系统启动分区镜像校验失败导致终端设备出现开机故障时，终端设备根据与当前系统启动分区对应的前一次恢复记录来选择下一次的恢复策略。其中，如果当前系统启动分区发生第一次AVB校验失败和第二次AVB校验失败之后，则为了排除概率性AVB校验失败问题，将重启作为下一次的恢复策略；如果当前系统启动分区发生第三次AVB校验失败之后，则可以确定当前系统启动分区非概率性AVB校验失败问题，可能为分区镜像永久性损坏，将切换分区启动作为下一次的恢复策略。在切换分区之后，第四次AVB校验的是对区镜像，如果对区镜像AVB校验失败，为了排除对区概率性AVB校验失败问题，将重启作为下一次的恢复策略；如果对区镜像连续两个AVB校验失败，则可以确定对区非概率性AVB校验失败问题，可能为分区镜像永久性损坏，终端设备进入Fastboot模式。
需要注意的是，在上述流程中，slot_a分区重启两次，slot_b分区重启一次，该重启次数仅仅为示例性的说明。为了解决分区镜像AVB校验失败的概率性问题，slot_a分区和/或slot_b分区的重启次数可以根据实际情况合理性设置，例如为两到三次等，本申请实施例对此不做限定。
这样，本方案可以保证终端设备更加安全地实现自动恢复，增加终端设备在异常AVB校验失败之后的可靠性，保证异常情况下终端设备能够自恢复，极大减少了终端设备由于分区镜像AVB校验概率性失败问题而导致死机的概率。
场景二
在本场景中，终端设备处于正常使用状态，且在此之前终端设备某个系统启动分区OTA升级失败回滚。此时，终端设备的两个系统启动分区，一个为正常可启动(bootable)状态，一个为异常不可启动(unbootable)状态。
如图5所示，假设slot_a分区的属性为active，终端设备在开机时正常启动slot_a分区。如果slot_a分区镜像AVB校验失败，则终端设备重启slot_a分区。如果重启slot_a分区时，slot_a分区成功启动，则表明果slot_a分区镜像AVB校验失败为概率性问题，通过重启的恢复策略即可使终端设备正常启动。如果重启slot_a分区时，slot_a分区镜像再次AVB校验失败，则终端设备再次重启slot_a分区。如果再次重启slot_a分区时，slot_a分区成功启动，则表明slot_a分区镜像AVB校验失败为概率性问题，通过重启的恢复策略即可使终端设备正常启动。如果再次重启slot_a分区时，slot_a分区镜像又一次AVB校验失败，则表明slot_a分区镜像AVB校验失败非概率性问题，可能为slot_a分区镜像永久性损坏问题。
需要指出的是，终端设备由于重启后需要从slot_a分区启动，所以终端设备在重启前需要将slot_a分区设置为active。
此时，若终端设备需要切换到slot_b分区进行继续启动，则首先需要对slot_b分区的属性进行判断。如果slot_b分区的属性为正常可启动(bootable)状态，则终端设备切换到slot_b分区继续启动，后续流程可以参照场景一，在此不再赘述。如果slot_b分区的属性为异常不可启动(unbootable)状态，则终端设备直接进入Fastboot模式。
这样，对于处在正常使用过程中的终端设备，终端设备可分为两种：一种为OTA成功升级之后的终端设备，两个分区都是可启动的，另外一种为OTA升级失败并回滚之后的终端设备，此时终端设备的另外一个分区是不可启动的。因此，终端设备在使用过程(非OTA升级)中发生AVB镜像校验失败时，需要判断终端设备对区是否可启动，当对区可启动时，才会执行切分区的恢复策略。
另一种可选的实施方式中，在终端设备OTA升级失败回滚的场景下，虽然升级失败的系统启动分区的状态的异常不可启动(unbootable)，但在终端设备OTA升级失败回滚后，两个系统启动分区的镜像应该是一致的。示例性的，在slot_b分区OTA升级之前，slot_a分区的镜像为镜像1，slot_b分区的镜像也为镜像1；在slot_b分区OTA升级失败回滚之后，slot_a分区的镜像不变为镜像1，slot_b分区的镜像也未成功升级，还是镜像1。
由此，在终端设备OTA升级失败回滚的场景下，当slot_a分区多次重启已排除概率性AVB镜像校验失败问题时，也可以尝试切换至slot_b分区以执行如上文所述的恢复策略。其中，需要指出的是，为了实现此种实施方式，需要在切换至slot_b分区启动之前，将slot_b分区的属性设置为active。
场景三
在本场景中，终端设备处于OTA升级状态。
当终端设备处于OTA升级状态时，如果出现了分区镜像出现了AVB校验失败问题，则为了保证OTA的原生升级流程的正常执行，终端设备不会执行基于概率性AVB校验失败问题而确定的恢复策略。
如图6所示，假设在slot_a分区启动过程中，终端设备检测到分区镜像AVB校验失败问题，则首先判断slot_a分区是否处于OTA升级过程中。若slot_a分区处于OTA升级过程中，则按照已有逻辑继续启动，否则按照本申请实施例提供的系统启动逻辑继续启动，可以参照场景一和场景二，在此不再赘述。
示例性的，在slot_a分区处于OTA升级过程中，如果slot_a分区镜像AVB校验失败，则不会执行基于概率性AVB校验失败问题而确定的恢复策略，而是按照OTA升级失败的逻辑将系统回滚至slot_b分区。
这样，将终端设备的正常使用场景与OTA升级场景进行分区，使终端设备执行基于概率性AVB校验失败问题而确定的恢复策略，不会对原生的OTA升级流程产生影响，确保了OTA原生升级流程可以正常则执行。
为了实现本申请实施例提供的系统启动方法，如图7所示，终端设备可以包括Bootloader开机框架、启动故障检测(BootDetector)模块、启动故障恢复(BootRecovery) 模块以及适配器(adapter)。
其中，Bootloader用于进行不开机故障检测，在本申请实施例中具体用于检测分区镜像AVB校验是否失败；BootDetector用于处理不开机故障，在本申请实施例中具体用于处于分区镜像AVB校验失败故障；BootRecovery用于确定及记录故障恢复策略，在本申请实施例中具体用于确定及记录与分区镜像AVB校验失败对应的故障恢复策略。
继续参照图7，在终端设备的物理资源中包括存储分区以及保留物理内存。其中，保留物理内存用于存储系统当前所处启动阶段的标识信息。示例性的，系统启动阶段包括但不限于Bootloader启动阶段、kernel启动阶段、Android启动阶段等。
如图8所示，存储分区可以用于存储终端设备系统启动信息和系统恢复信息。其中，系统启动信息中至少可以包括系统启动日志信息，每组日志信息至少包括日志头信息、Bootloader日志信息和kernel日志信息。其中，日志头信息用于描述Bootloader日志信息和kernel日志信息所占用的字节数。系统恢复信息中至少可以包括系统恢复所采用的策略信息，还可以包括系统恢复记录。关于存储分区的格式以及字段分布，本申请实施例不做限定。
为了保证Bootloader和kernel能够同时访问存储分区并不依赖文件系统，存储分区可以被设计成裸分区的形式。
需要说明的是，为了使得本申请提供的系统启动方法适用于不同芯片平台，终端设备中还设置有预先封装的适配器，以使BootDetector和BootRecovery可以通过该适配器访问与不同芯片平台对应的存储分区(裸分区)。
图9示例性的示出了一种模块交互示意图。如图9所示，本申请实施例提供的系统启动方法的步骤具体包括：
1.Bootloader检测到分区镜像AVB校验失败。
在终端设备的开启过程中，Bootloader检测是否存在不开机故障。在本实施例中，Bootloader用于检测启动系统的slot分区的镜像是否存在AVB校验失败问题。
2.Bootloader调用BootDetector处理开机故障。
当Bootloader检测到当前存在slot分区镜像AVB校验失败的问题时，调用BootDetector处理开机故障。在本实施例中，Bootloader调用BootDetector处理的是slot分区镜像AVB校验失败问题。
示例性的，Bootloader调用BootDetector时，设置的处理参数可以包括但不限于：slot分区标识，slot分区是否可启动的状态(unbootable或bootable)。其中，处理参数中包括的slot分区标识，用于指示当前发生镜像AVB校验失败的分区。
3.BootDetector校验处理参数的合法性。
BootDetector接收到Bootloader的调用之后，首先校验处理参数的合法性，若处理参数合法则继续向下执行，否则不响应Bootloader的调用。
4.BootDetector调用BootRecovery获取恢复策略。
当Bootloader的调用处理参数合法时，BootDetector继续调用BootRecovery以获取相应的恢复策略。
示例性的，BootDetector调用BootRecovery时的参数，可以包括但不限于：slot分区 标识，slot分区是否可启动的状态(unbootable或bootable)。其中，参数中包括的slot分区标识，用于指示当前发生镜像AVB校验失败的分区。
5.BootRecovery读取恢复记录。
响应于BootDetector的调用，BootRecovery可以在存储分区(裸分区)中读取与本轮开机对应的恢复记录。其中，恢复记录可以包括但不限于：slot分区标识，AVB校验失败次数等。需要说明的是，恢复记录也可以存储于其他分区，本实施例对此不做限定。
6.BootRecovery校验更正恢复记录。
BootRecovery对读取到的恢复记录进行校验，以确保读取到的恢复记录的准确性和合法性。在确定读取到的恢复记录通过校验之后，对恢复记录进行更正存储。
示例性的，假设读取到的恢复记录为：slot_a分区，AVB校验失败次数为1，则在BootDetector调用参数指示当前发生镜像AVB校验失败的分区为slot_a分区时，将恢复记录更正为slot_a分区，AVB校验失败次数为2。
又示例性的，假设读取到的恢复记录为：slot_a分区，AVB校验失败次数为3，则在BootDetector调用参数指示当前发生镜像AVB校验失败的分区为slot_b分区时，将恢复记录更正为slot_a分区，AVB校验失败次数为3；slot_b分区，AVB校验失败次数为1。
再示例性的，假设读取到的恢复记录为空，则在BootDetector调用参数指示当前发生镜像AVB校验失败的分区为slot_a分区时，将恢复记录更正为slot_a分区，AVB校验失败次数为1。
7.BootRecovery选择恢复策略。
BootRecovery根据更正后的恢复记录，选择当前的恢复策略。
假设，分区切换前终端设备设置的AVB校验失败次数阈值为x1，分区切换后终端设备设置的AVB校验失败次数阈值为x2。其中，AVB校验失败次数阈值x1可以设置为大于2的整数，AVB校验失败次数阈值x2可以设置为大于1的整数。
在终端设备开始在slot_a分区启动的情况下，slot_a分区的AVB校验失败次数阈值为x1。由于分区切换后终端设备在slot_b分区启动，则slot_b分区的AVB校验失败次数阈值为x2。
示例性的，分区切换前终端设备设置的AVB校验失败次数阈值x1可以设置为3，分区切换后终端设备设置的AVB校验失败次数阈值x2可以设置为2。可以理解的，此处提及的AVB校验失败次数阈值仅为示例性的举例，可以根据实际情况合理性设置，既能解决分区镜像AVB校验失败的概率性问题，又不会由于重启次数过多而影响用户使用体验。
BootRecovery根据恢复记录，如果确定slot_a分区的AVB校验失败次数小于阈值x1，则将当前的恢复策略确定为在slot_a分区进行系统重启。
BootRecovery根据恢复记录，如果确定slot_a分区的AVB校验失败次数等于阈值x1，slot_b分区的AVB校验失败次数为0(或者称不存在slot_b分区的恢复记录)，且slot_b分区的属性为可启动的状态(bootable)，则将当前的恢复策略确定为切换到slot_b分区进行系统启动。
BootRecovery根据恢复记录，如果确定slot_a分区的AVB校验失败次数等于阈值x1，且slot_b分区的AVB校验失败次数小于阈值x2，则将当前的恢复策略确定为在slot_b分 区进行系统重启。
BootRecovery根据恢复记录，如果确定slot_a分区的AVB校验失败次数等于阈值x1，且slot_b分区的AVB校验失败次数等于阈值x2，则将当前的恢复策略确定进入Fastboot模式。
8.BootRecovery保存恢复策略。
在确定当前的恢复策略之后，BootRecovery将恢复策略保存至存储分区(裸分区)。
9.BootRecovery向BootDetector返回恢复策略。
10.BootDetector保存日志。
BootDetector接收到BootRecovery反馈的恢复策略之后，生成系统恢复日志(Bootloader log)写入存储分区(裸分区)中，以使后续可以根据日志信息定位相应的恢复策略便于读取。
11.BootDetector更新日志meta信息。
BootDetector根据在存储分区(裸分区)中写入Bootloader log的情形，适应性地更新日志meta信息。其中，日志meta信息用于对存储分区(裸分区)中存储的日志信息进行描述。
12.BootDetector指示Bootloader执行恢复策略。
BootDetector根据BootRecovery反馈的恢复策略指示执行相应的恢复策略。
13.Bootloader重启开机。
在恢复策略指示在slot_a分区进行系统重启，或者切换到slot_b分区进行系统启动，或者在slot_b分区进行系统重启时，Bootloader执行相应的重启开机操作。
在恢复策略指示进入Fastboot模式时，Bootloader执行相应的进入Fastboot模式的操作。
14.Bootloader开机成功。
如果在前次系统启动时，分区镜像AVB校验失败为概率性问题，则在恢复策略指示在slot_a分区进行系统重启，或者切换到slot_b分区进行系统启动，或者在slot_b分区进行系统重启，Bootloader执行相应的重启操作可以使终端设备开机成功，避免终端设备进入Fastboot模式。
15.BootCollector转储日志及系统恢复结果。
待终端设备开机成功后，安卓系统启动成功。BootCollector为安卓系统应用程序层中的模块，用于收集终端设备在启动过程中的日志信息以及系统恢复结果。
16.BootCollector将日志及系统恢复结果上传至云端。
当BootCollector启动后，在存储分区(裸分区)中读取相应的日志信息以及系统恢复结果，以将这些日志信息以及系统恢复结果上传至云端。
示例性的，BootCollector可以在存储分区(裸分区)中读取本轮开机流程中与最后一次启动对应的日志信息以及系统恢复结果，也可以读取本轮开机流程中所有的日志信息以及系统恢复结果。本申请实施例对此不做限定。
本流程未尽详细解释之处可以参照已有技术，在此不再赘述。
作为一种可选的实施方式，BootCollector可以对slot分区每次出现AVB校验失败问 题、执行的恢复策略，以及系统启动是否成功，进行对应性的记录，例如可以是通过日志的形式进行记录。
这样，在终端设备执行恢复策略正常启动后，运维人员就可以根据相应的日志信息分析当前启动分区是否由于镜像AVB校验失败概率性问题被重启过，以及重启后是否镜像AVB校验成功且系统成功启动。
如图10所示为电子设备100的结构示意图。可选地，电子设备100可以为终端，也可以称为终端设备，终端可以为蜂窝电话(cellular phone)或平板电脑(pad)等设备，本申请不做限定。应该理解的是，图10所示的电子设备100仅是电子设备的一个范例，并且电子设备100可以具有比图中所示的更多的或者更少的部件，可以组合两个或多个的部件，或者可以具有不同的部件配置。图10中所示出的各种部件可以在包括一个或多个信号处理和/或专用集成电路在内的硬件、软件、或硬件和软件的组合中实现。
电子设备100可以包括：处理器110，外部存储器接口120，内部存储器121，通用串行总线(universal serial bus，USB)接口130，充电管理模块140，电源管理模块141，电池142，天线1，天线2，移动通信模块150，无线通信模块160，音频模块170，扬声器170A，受话器170B，麦克风170C，耳机接口170D，传感器模块180，按键190，马达191，指示器192，摄像头193，显示屏194，以及用户标识模块(subscriber identification module，SIM)卡接口195等。其中传感器模块180可以包括压力传感器，陀螺仪传感器，加速度传感器，温度传感器，运动传感器，气压传感器，磁传感器，距离传感器，接近光传感器，指纹传感器，触摸传感器，环境光传感器，骨传导传感器等。
处理器110可以包括一个或多个处理单元，例如：处理器110可以包括应用处理器(application processor，AP)，调制解调处理器，图形处理器(graphics processing unit，GPU)，图像信号处理器(image signal processor，ISP)，控制器，存储器，视频编解码器，数字信号处理器(digital signal processor，DSP)，基带处理器，和/或神经网络处理器(neural-network processing unit，NPU)等。其中，不同的处理单元可以是独立的器件，也可以集成在一个或多个处理器中。
其中，控制器可以是电子设备100的神经中枢和指挥中心。控制器可以根据指令操作码和时序信号，产生操作控制信号，完成取指令和执行指令的控制。
处理器110中还可以设置存储器，用于存储指令和数据。在一些实施例中，处理器110中的存储器为高速缓冲存储器。
USB接口130是符合USB标准规范的接口，具体可以是Mini USB接口，Micro USB接口，USB Type C接口等。USB接口130可以用于连接充电器为电子设备100充电，也可以用于电子设备100与外围设备之间传输数据。也可以用于连接耳机，通过耳机播放音频。该接口还可以用于连接其他电子设备，例如AR设备等。
充电管理模块140用于从充电器接收充电输入。其中，充电器可以是无线充电器，也可以是有线充电器。在一些有线充电的实施例中，充电管理模块140可以通过USB接口130接收有线充电器的充电输入。在一些无线充电的实施例中，充电管理模块140可以通过电子设备100的无线充电线圈接收无线充电输入。充电管理模块140为电池142 充电的同时，还可以通过电源管理模块141为电子设备供电。
电源管理模块141用于连接电池142，充电管理模块140与处理器110。电源管理模块141接收电池142和/或充电管理模块140的输入，为处理器110，内部存储器121，外部存储器，显示屏194，摄像头193，和无线通信模块160等供电。
电子设备100的无线通信功能可以通过天线1，天线2，移动通信模块150，无线通信模块160，调制解调处理器以及基带处理器等实现。
天线1和天线2用于发射和接收电磁波信号。电子设备100中的每个天线可用于覆盖单个或多个通信频带。不同的天线还可以复用，以提高天线的利用率。例如：可以将天线1复用为无线局域网的分集天线。在另外一些实施例中，天线可以和调谐开关结合使用。
移动通信模块150可以提供应用在电子设备100上的包括2G/3G/4G/5G等无线通信的解决方案。移动通信模块150可以包括至少一个滤波器，开关，功率放大器，低噪声放大器(low noise amplifier，LNA)等。
无线通信模块160可以提供应用在电子设备100上的包括无线局域网(wireless local area networks，WLAN)(如无线保真(wireless fidelity，Wi-Fi)网络)，蓝牙(bluetooth，BT)，全球导航卫星系统(global navigation satellite system，GNSS)，调频(frequency modulation，FM)，近距离无线通信技术(near field communication，NFC)，红外技术(infrared，IR)等无线通信的解决方案。
在一些实施例中，电子设备100的天线1和移动通信模块150耦合，天线2和无线通信模块160耦合，使得电子设备100可以通过无线通信技术与网络以及其他设备通信。
电子设备100通过GPU，显示屏194，以及应用处理器等实现显示功能。GPU为图像处理的微处理器，连接显示屏194和应用处理器。GPU用于执行数学和几何计算，用于图形渲染。处理器110可包括一个或多个GPU，其执行程序指令以生成或改变显示信息。
显示屏194用于显示图像，视频等。显示屏194包括显示面板。在一些实施例中，电子设备100可以包括1个或N个显示屏194，N为大于1的正整数。
电子设备100可以通过ISP，摄像头193，视频编解码器，GPU，显示屏194以及应用处理器等实现拍摄功能。
ISP用于处理摄像头193反馈的数据。例如，拍照时，打开快门，光线通过镜头被传递到摄像头感光元件上，光信号转换为电信号，摄像头感光元件将所述电信号传递给ISP处理，转化为肉眼可见的图像。ISP还可以对图像的噪点，亮度，肤色进行算法优化。ISP还可以对拍摄场景的曝光，色温等参数优化。在一些实施例中，ISP可以设置在摄像头193中。
摄像头193用于捕获静态图像或视频。物体通过镜头生成光学图像投射到感光元件。感光元件可以是电荷耦合器件(charge coupled device，CCD)或互补金属氧化物半导体(complementary metal-oxide-semiconductor，CMOS)光电晶体管。感光元件把光信号转换成电信号，之后将电信号传递给ISP转换成数字图像信号。ISP将数字图像信号输出到DSP加工处理。DSP将数字图像信号转换成标准的RGB，YUV等格式的图像信号。在 一些实施例中，电子设备100可以包括1个或N个摄像头193，N为大于1的正整数。
外部存储器接口120可以用于连接外部存储卡，例如Micro SD卡，实现扩展电子设备100的存储能力。外部存储卡通过外部存储器接口120与处理器110通信，实现数据存储功能。
内部存储器121可以用于存储计算机可执行程序代码，所述可执行程序代码包括指令。处理器110通过运行存储在内部存储器121的指令，从而执行电子设备100的各种功能应用以及数据处理，例如使得电子设备100实现本申请实施例中的系统启动方法。内部存储器121可以包括存储程序区和存储数据区。其中，存储程序区可存储操作系统，至少一个功能所需的应用程序(比如声音播放功能，图像播放功能等)等。存储数据区可存储电子设备100使用过程中所创建的数据(比如音频数据，电话本等)等。此外，内部存储器121可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件，闪存器件，通用闪存存储器(universal flash storage，UFS)等。
电子设备100可以通过音频模块170，扬声器170A，受话器170B，麦克风170C，耳机接口170D，以及应用处理器等实现音频功能。例如音乐播放，录音等。
音频模块170用于将数字音频信息转换成模拟音频信号输出，也用于将模拟音频输入转换为数字音频信号。音频模块170还可以用于对音频信号编码和解码。在一些实施例中，音频模块170可以设置于处理器110中，或将音频模块170的部分功能模块设置于处理器110中。
扬声器170A，也称“喇叭”，用于将音频电信号转换为声音信号。电子设备100可以通过扬声器170A收听音乐，或收听免提通话。在一些实施例中，电子设备100可以设置多个扬声器170A。
受话器170B，也称“听筒”，用于将音频电信号转换成声音信号。当电子设备100接听电话或语音信息时，可以通过将受话器170B靠近人耳接听语音。
麦克风170C，也称“话筒”，“传声器”，用于将声音信号转换为电信号。当拨打电话或发送语音信息时，用户可以通过人嘴靠近麦克风170C发声，将声音信号输入到麦克风170C。电子设备100可以设置至少一个麦克风170C。在另一些实施例中，电子设备100可以设置两个麦克风170C，除了采集声音信号，还可以实现降噪功能。在另一些实施例中，电子设备100还可以设置三个，四个或更多麦克风170C，实现采集声音信号，降噪，还可以识别声音来源，实现定向录音功能等。
耳机接口170D用于连接有线耳机。耳机接口170D可以是USB接口130，也可以是3.5mm的开放移动电子设备平台(open mobile terminal platform，OMTP)标准接口，美国蜂窝电信工业协会(cellular telecommunications industry association of the USA，CTIA)标准接口。
压力传感器用于感受压力信号，可以将压力信号转换成电信号。在一些实施例中，压力传感器可以设置于显示屏194。电子设备100也可以根据压力传感器的检测信号计算触摸的位置。
陀螺仪传感器可以用于确定电子设备100的运动姿态。在一些实施例中，可以通过陀螺仪传感器确定电子设备100围绕三个轴(即，x，y和z轴)的角速度。
加速度传感器可检测电子设备100在各个方向上(一般为三轴)加速度的大小。当电子设备100静止时加速度传感器可检测出重力的大小及方向。加速度传感器还可以用于识别电子设备姿态，应用于横竖屏切换，计步器等应用。
触摸传感器，也称“触控面板”。触摸传感器可以设置于显示屏194，由触摸传感器与显示屏194组成触摸屏，也称“触控屏”。触摸传感器用于检测作用于其上或附近的触摸操作。触摸传感器可以将检测到的触摸操作传递给应用处理器，以确定触摸事件类型。
按键190包括开机键(或称电源键)，音量键等。按键190可以是机械按键。也可以是触摸式按键。电子设备100可以接收按键输入，产生与电子设备100的用户设置以及功能控制有关的键信号输入。
马达191可以产生振动提示。马达191可以用于来电振动提示，也可以用于触摸振动反馈。例如，作用于不同应用(例如拍照，音频播放等)的触摸操作，可以对应不同的振动反馈效果。
指示器192可以是指示灯，可以用于指示充电状态，电量变化，也可以用于指示消息，未接来电，通知等。
电子设备100的软件系统可以采用分层架构，事件驱动架构，微核架构，微服务架构，或云架构。本申请实施例以分层架构的Android系统为例，示例性说明电子设备100的软件结构。
图11是本申请实施例的电子设备100的软件结构框图。
电子设备100的分层架构将软件分成若干个层，每一层都有清晰的角色和分工。层与层之间通过软件接口通信。在一些实施例中，将Android系统分为四层，从上至下分别为应用程序层，应用程序框架层，安卓运行时(Android Runtime)和系统库，以及内核层。
应用程序层可以包括一系列应用程序包。
如图11所示，应用程序包可以包括相机、日历、地图、WLAN、音乐、短信息、图库、通话、视频等应用程序。
应用程序包还可以包括BootCollector(启动数据收集)模块。其中，BootCollector模块可以用于收集终端设备在启动过程中的日志信息以及系统恢复结果。
应用程序框架层为应用程序层的应用程序提供应用编程接口(application programming interface，API)和编程框架。应用程序框架层包括一些预先定义的函数。
如图11所示，应用程序框架层可以包括窗口管理器，内容提供器，视图系统，电话管理器，资源管理器，通知管理器等。
窗口管理器用于管理窗口程序。窗口管理器可以获取显示屏大小，判断是否有状态栏，锁定屏幕，截取屏幕等。
内容提供器用来存放和获取数据，并使这些数据可以被应用程序访问。所述数据可以包括视频，图像，音频，拨打和接听的电话，浏览历史和书签，电话簿等。
视图系统包括可视控件，例如显示文字的控件，显示图片的控件等。视图系统可用 于构建应用程序。显示界面可以由一个或多个视图组成的。例如，包括短信通知图标的显示界面，可以包括显示文字的视图以及显示图片的视图。
电话管理器用于提供电子设备100的通信功能。例如通话状态的管理(包括接通，挂断等)。
资源管理器为应用程序提供各种资源，比如本地化字符串，图标，图片，布局文件，视频文件等等。
通知管理器使应用程序可以在状态栏中显示通知信息，可以用于传达告知类型的消息，可以短暂停留后自动消失，无需用户交互。比如通知信息被用于告知下载完成，消息提醒等。通知信息还可以是以图表或者滚动条文本形式出现在系统顶部状态栏的通知，例如后台运行的应用程序的通知，通知信息还可以是以对话窗口形式出现在屏幕上的通知。通知信息还例如可以是在状态栏提示文本信息，发出的提示音，电子设备的振动，指示灯的闪烁等。
Android Runtime包括核心库和虚拟机。Android Runtime负责安卓系统的调度和管理。
核心库包含两部分：一部分是java语言需要调用的功能函数，另一部分是安卓的核心库。
应用程序层和应用程序框架层运行在虚拟机中。虚拟机将应用程序层和应用程序框架层的java文件执行为二进制文件。虚拟机用于执行对象生命周期的管理，堆栈管理，线程管理，安全和异常的管理，以及垃圾回收等功能。
系统库可以包括多个功能模块。例如：表面管理器(surface manager)，媒体库(Media Libraries)，三维图形处理库(例如：OpenGL ES)，2D图形引擎(例如：SGL)等。
表面管理器用于对显示子系统进行管理，并且为多个应用程序提供了2D和3D图层的融合。
媒体库支持多种常用的音频，视频格式回放和录制，以及静态图像文件等。媒体库可以支持多种音视频编码格式，例如：MPEG4，H.264，MP3，AAC，AMR，JPG，PNG等。
三维图形处理库用于实现三维图形绘图，图像渲染，合成，和图层处理等。
2D图形引擎是2D绘图的绘图引擎。
内核层是硬件和软件之间的层。内核层至少包含显示驱动，音频驱动，Wi-Fi驱动，蓝牙驱动，传感器驱动等。其中，硬件至少包括处理器、显示屏、Wi-Fi模块、传感器等。
可以理解的是，图11示出的软件结构中的层以及各层中包含的部件，并不构成对电子设备100的具体限定。在本申请另一些实施例中，电子设备100可以包括比图示更多或更少的层，以及每个层中可以包括更多或更少的部件，本申请不做限定。
可以理解的是，电子设备为了实现本申请实施例中的系统启动方法，其包含了执行各个功能相应的硬件和/或软件模块。结合本文中所公开的实施例描述的各示例的算法步骤，本申请能够以硬件或硬件和计算机软件的结合形式来实现。某个功能究竟以硬件还是计算机软件驱动硬件的方式来执行，取决于技术方案的特定应用和设计约束条件。本领域技术人员可以结合实施例对每个特定的应用来使用不同方法来实现所描述的功能， 但是这种实现不应认为超出本申请的范围。
本实施例还提供一种计算机存储介质，该计算机存储介质中存储有计算机指令，当该计算机指令在电子设备上运行时，使得电子设备执行上述相关方法步骤实现上述实施例中的系统启动方法。
本实施例还提供了一种计算机程序产品，当该计算机程序产品在计算机上运行时，使得计算机执行上述相关步骤，以实现上述实施例中的系统启动方法。
另外，本申请的实施例还提供一种装置，这个装置具体可以是芯片，组件或模块，该装置可包括相连的处理器和存储器；其中，存储器用于存储计算机执行指令，当装置运行时，处理器可执行存储器存储的计算机执行指令，以使芯片执行上述各方法实施例中的系统启动方法。
其中，本实施例提供的电子设备(如手机等)、计算机存储介质、计算机程序产品或芯片均用于执行上文所提供的对应的方法，因此，其所能达到的有益效果可参考上文所提供的对应的方法中的有益效果，此处不再赘述。
通过以上实施方式的描述，所属领域的技术人员可以了解到，为描述的方便和简洁，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将装置的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。
在本申请所提供的几个实施例中，应该理解到，所揭露的装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，模块或单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个装置，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。
以上所述，以上实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的范围。

Claims (23)

  1. 一种系统启动方法，其特征在于，应用于电子设备中，所述电子设备包括第一系统启动分区和第二系统启动分区，包括：
    所述电子设备在所述第一系统启动分区中进行系统启动的过程中，如果所述第一系统启动分区的镜像校验失败，则所述电子设备在所述第一系统启动分区中进行系统重启；
    所述电子设备在所述第一系统启动分区中系统重启成功。
  2. 根据权利要求1所述的方法，其特征在于，还包括：
    在所述电子设备在所述第一系统启动分区中进行系统重启的过程中，如果所述第一系统启动分区的镜像校验失败，则所述电子设备切换到第二系统启动分区中进行系统启动；
    所述电子设备在第二系统启动分区中进行系统启动的过程中，如果所述第二系统启动分区的镜像校验失败，则所述电子设备在所述第二系统启动分区中进行系统重启；
    所述电子设备在所述第二系统启动分区中系统重启成功。
  3. 根据权利要求2所述的方法，其特征在于，所述电子设备切换到第二系统启动分区中进行系统启动，包括：
    如果所述第二系统启动分区的属性为可启动状态，则所述电子设备切换到第二系统启动分区中进行系统启动。
  4. 根据权利要求3所述的方法，其特征在于，还包括：
    如果所述第二系统启动分区的属性为不可启动状态，则所述电子设备进行快速启动模式。
  5. 根据权利要求2所述的方法，其特征在于，还包括：
    在所述电子设备在所述第二系统启动分区中进行系统重启的过程中，如果所述第二系统启动分区的镜像校验失败，则所述电子设备进行快速启动模式。
  6. 根据权利要求2所述的方法，其特征在于，如果所述第一系统启动分区的镜像校验失败，则所述电子设备在所述第一系统启动分区中进行系统重启，包括：
    如果所述第一系统启动分区的镜像校验失败，且所述第一系统启动分区的镜像校验失败次数小于第一阈值，则所述电子设备在所述第一系统启动分区中进行系统重启；
    如果所述第一系统启动分区的镜像校验失败，则所述电子设备切换到第二系统启动分区中进行系统启动，包括：
    如果所述第一系统启动分区的镜像校验失败，且所述第一系统启动分区的镜像校验失败次数等于所述第一阈值，则所述电子设备切换到所述第二系统启动分区中进行系统启动；
    其中，第一阈值大于2。
  7. 根据权利要求2所述的方法，其特征在于，如果所述第二系统启动分区的镜像校验失败，则所述电子设备在所述第二系统启动分区中进行系统重启，包括：
    如果所述第二系统启动分区的镜像校验失败，且所述第二系统启动分区的镜像校验失败次数小于第二阈值，则所述电子设备在所述第二系统启动分区中进行系统重启；
    其中，第二阈值大于1。
  8. 根据权利要求1-7任一项所述的方法，其特征在于，如果所述第一系统启动分区的镜像校验失败，则所述电子设备在所述第一系统启动分区中进行系统重启，包括：
    如果所述第一系统启动分区的镜像校验失败，且所述第一系统启动分区未处于OTA升级中，则所述电子设备在所述第一系统启动分区中进行系统重启。
  9. 根据权利要求1所述的方法，其特征在于，在所述电子设备在所述第一系统启动分区中进行系统重启时，还包括：记录与所述第一系统启动分区的镜像校验失败对应的日志信息以及恢复策略，所述恢复策略为所述电子设备在所述第一系统启动分区中进行系统重启。
  10. 根据权利要求2所述的方法，其特征在于，在所述电子设备在所述第二系统启动分区中进行系统重启时，还包括：记录与所述第二系统启动分区的镜像校验失败对应的日志信息以及恢复策略，所述恢复策略为所述电子设备在所述第二系统启动分区中进行系统重启。
  11. 根据权利要求2所述的方法，其特征在于，在所述电子设备切换到第二系统启动分区中进行系统启动时，还包括：记录与所述第一系统启动分区的镜像校验失败对应的日志信息以及恢复策略，所述恢复策略为所述电子设备切换到第二系统启动分区中进行系统启动。
  12. 根据权利要求9-11任一项所述的方法，其特征在于，在所述电子设备系统启动成功后，还包括：
    向云端上传所述日志信息及恢复策略。
  13. 一种电子设备，其特征在于，包括：
    一个或多个处理器；
    存储器；
    以及一个或多个计算机程序，其中所述一个或多个计算机程序存储在所述存储器上，当所述计算机程序被所述一个或多个处理器执行时，使得所述电子设备执行如权利要求1-12中任一项所述的系统启动方法。
  14. 一种计算机可读存储介质，包括计算机程序，其特征在于，当所述计算机程序在电子设备上运行时，使得所述电子设备执行如权利要求1-12中任一项所述的系统启动方法。
  15. 一种系统启动方法，其特征在于，应用于电子设备中，所述电子设备包括第一系统启动分区和第二系统启动分区，包括：
    所述电子设备在所述第一系统启动分区中进行系统启动的过程中，如果所述第一系统启动分区的镜像校验失败，且所述第一系统启动分区未处于OTA升级中，则所述电子设备在所述第一系统启动分区中进行系统重启，所述电子设备在所述第一系统启动分区中进行系统重启的结果包括重启成功，与所述第一系统启动分区重启成功对应的日志信息用于指示所述第一系统启动分区镜像校验失败为概率性故障，非永久性损坏；
    所述电子设备在所述第一系统启动分区中进行系统重启的过程中，如果所述第一系统启动分区的镜像校验失败，则所述电子设备切换到第二系统启动分区中进行系统启动；
    所述电子设备在第二系统启动分区中进行系统启动的过程中，如果所述第二系统启动分区的镜像校验失败，则所述电子设备在所述第二系统启动分区中进行系统重启；所述电子设备在所述第二系统启动分区中进行系统重启的结果包括重启成功，与所述第二系统启动分区重启成功对应的日志信息用于指示所述第二系统启动分区镜像校验失败为概率性故障，非永久性损坏；
    在所述电子设备在所述第二系统启动分区中进行系统重启的过程中，如果所述第二系统启动分区的镜像校验失败，则所述电子设备进行快速启动模式；
    其中，所述电子设备在所述第一系统启动分区中进行系统启动之前，所述电子设备在所述第二系统启动分区中进行了OTA升级，所述OTA升级成功或所述OTA升级后回滚。
  16. 根据权利要求15所述的方法，其特征在于，所述电子设备切换到第二系统启动分区中进行系统启动，包括：
    如果所述第二系统启动分区的属性为可启动状态，则所述电子设备切换到第二系统启动分区中进行系统启动。
  17. 根据权利要求16所述的方法，其特征在于，还包括：
    如果所述第二系统启动分区的属性为不可启动状态，则所述电子设备进行快速启动模式。
  18. 根据权利要求15所述的方法，其特征在于，如果所述第一系统启动分区的镜像校验失败，则所述电子设备在所述第一系统启动分区中进行系统重启，包括：
    如果所述第一系统启动分区的镜像校验失败，且所述第一系统启动分区的镜像校验失败次数小于第一阈值，则所述电子设备在所述第一系统启动分区中进行系统重启；
    如果所述第一系统启动分区的镜像校验失败，则所述电子设备切换到第二系统启动分区中进行系统启动，包括：
    如果所述第一系统启动分区的镜像校验失败，且所述第一系统启动分区的镜像校验失败次数等于所述第一阈值，则所述电子设备切换到所述第二系统启动分区中进行系统启动；
    其中，第一阈值大于2。
  19. 根据权利要求15所述的方法，其特征在于，如果所述第二系统启动分区的镜像校验失败，则所述电子设备在所述第二系统启动分区中进行系统重启，包括：
    如果所述第二系统启动分区的镜像校验失败，且所述第二系统启动分区的镜像校验失败次数小于第二阈值，则所述电子设备在所述第二系统启动分区中进行系统重启；
    其中，第二阈值大于1。
  20. 根据权利要求15所述的方法，其特征在于，在所述电子设备在所述第一系统启动分区中进行系统重启时，还包括：记录与所述第一系统启动分区的镜像校验失败对应的日志信息以及恢复策略，所述恢复策略为所述电子设备在所述第一系统启动分区中进行系统重启。
  21. 根据权利要求15所述的方法，其特征在于，在所述电子设备在所述第二系统启动分区中进行系统重启时，还包括：记录与所述第二系统启动分区的镜像校验失败对应的日志信息以及恢复策略，所述恢复策略为所述电子设备在所述第二系统启动分区中进行系统重启。
  22. 根据权利要求15所述的方法，其特征在于，在所述电子设备切换到第二系统启动分区中进行系统启动时，还包括：记录与所述第一系统启动分区的镜像校验失败对应的日志信息以及恢复策略，所述恢复策略为所述电子设备切换到第二系统启动分区中进行系统启动。
  23. 根据权利要求22所述的方法，其特征在于，在所述电子设备系统启动成功后，还包括：
    向云端上传所述日志信息及恢复策略。
PCT/CN2023/117642 2022-10-09 2023-09-08 系统启动方法及电子设备 WO2024078218A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202211229448.1A CN115328563B (zh) 2022-10-09 2022-10-09 系统启动方法及电子设备
CN202211229448.1 2022-10-09

Publications (1)

Publication Number Publication Date
WO2024078218A1 true WO2024078218A1 (zh) 2024-04-18

Family

ID=83913383

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2023/117642 WO2024078218A1 (zh) 2022-10-09 2023-09-08 系统启动方法及电子设备

Country Status (2)

Country Link
CN (2) CN115328563B (zh)
WO (1) WO2024078218A1 (zh)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115328563B (zh) * 2022-10-09 2023-04-14 荣耀终端有限公司 系统启动方法及电子设备
CN116467015B (zh) * 2023-06-20 2023-10-20 荣耀终端有限公司 镜像生成方法、系统启动校验方法及相关设备

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106095625A (zh) * 2016-07-13 2016-11-09 上海斐讯数据通信技术有限公司 无线接入设备启动方法及系统
US20180004503A1 (en) * 2016-06-29 2018-01-04 Vmware, Inc. Automated upgradesystem for a service-based distributed computer system
CN111562935A (zh) * 2020-07-14 2020-08-21 江苏海平面数据科技有限公司 一种ota安全升级系统及其升级方法
CN112328358A (zh) * 2020-10-28 2021-02-05 惠州华阳通用电子有限公司 一种基于虚拟机的双系统启动方法及存储介质
CN115328563A (zh) * 2022-10-09 2022-11-11 荣耀终端有限公司 系统启动方法及电子设备

Family Cites Families (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7610481B2 (en) * 2006-04-19 2009-10-27 Intel Corporation Method and apparatus to support independent systems in partitions of a processing system
CN103377054A (zh) * 2012-04-16 2013-10-30 联想(北京)有限公司 启动方法和启动装置
CN103678030A (zh) * 2012-09-04 2014-03-26 杭州海康威视数字技术股份有限公司 多系统设备启动系统及其方法
CN104182242A (zh) * 2013-05-28 2014-12-03 华为技术有限公司 一种系统启动方法及装置
CN104572229B (zh) * 2015-02-12 2018-07-20 西安诺瓦电子科技有限公司 嵌入式系统的固件升级方法以及固件升级装置
US10102008B2 (en) * 2015-09-02 2018-10-16 Dell Products L.P. Managed boot process system
CN105760201B (zh) * 2016-02-29 2019-05-28 华为技术有限公司 一种嵌入式装置的启动方法和装置
CN105975864A (zh) * 2016-04-29 2016-09-28 北京小米移动软件有限公司 操作系统的启动方法、装置及终端
CN106250262A (zh) * 2016-08-10 2016-12-21 深圳市蜂联科技有限公司 一种基于双镜像的防止SD使用过程中flash被意外篡改的方法
US10025587B2 (en) * 2016-08-17 2018-07-17 American Megatrends Inc. Method of bootup and installation, and computer system thereof
US10635451B2 (en) * 2016-09-08 2020-04-28 Hewlett-Packard Development Company, L.P. Mass storage medium having an operating system but not a partition table pre-installed
CN107577563A (zh) * 2017-09-26 2018-01-12 晶晨半导体(上海)股份有限公司 一种系统升级异常断电的保护方法及终端设备
CN109101279B (zh) * 2018-06-26 2021-08-24 珠海全志科技股份有限公司 一种多版本系统的兼容性启动方法
CN109582372B (zh) * 2018-11-12 2022-01-28 海信视像科技股份有限公司 一种系统的启动方法及装置
CN110134426A (zh) * 2019-04-18 2019-08-16 深圳市致宸信息科技有限公司 一种嵌入式系统升级方法、装置及终端设备
US11361080B2 (en) * 2020-04-13 2022-06-14 Cisco Technology, Inc. Reducing the secure boot time of full network operating system images using a combination of partitioning, staging and amortized verification techniques
CN112882757A (zh) * 2021-01-26 2021-06-01 东莞市峰谷科技有限公司 一种嵌入式系统双分区安全启动方法
CN113504918A (zh) * 2021-05-17 2021-10-15 深圳市广通远驰科技有限公司 设备树配置优化方法、装置、计算机设备和存储介质

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20180004503A1 (en) * 2016-06-29 2018-01-04 Vmware, Inc. Automated upgradesystem for a service-based distributed computer system
CN106095625A (zh) * 2016-07-13 2016-11-09 上海斐讯数据通信技术有限公司 无线接入设备启动方法及系统
CN111562935A (zh) * 2020-07-14 2020-08-21 江苏海平面数据科技有限公司 一种ota安全升级系统及其升级方法
CN112328358A (zh) * 2020-10-28 2021-02-05 惠州华阳通用电子有限公司 一种基于虚拟机的双系统启动方法及存储介质
CN115328563A (zh) * 2022-10-09 2022-11-11 荣耀终端有限公司 系统启动方法及电子设备

Also Published As

Publication number Publication date
CN115328563B (zh) 2023-04-14
CN117707626A (zh) 2024-03-15
CN115328563A (zh) 2022-11-11

Similar Documents

Publication Publication Date Title
US11803451B2 (en) Application exception recovery
WO2024078218A1 (zh) 系统启动方法及电子设备
KR102503341B1 (ko) 보안 서비스 삭제 방법 및 전자 장치
JP6510070B2 (ja) システム稼働方法およびインテリジェント端末
CN102830984B (zh) 固件更新的方法、芯片以及通信终端
CN112055424B (zh) 电子装置以及切换电子装置的方法
CN107273160A (zh) 一种版本升级的方法及装置
WO2019062635A1 (zh) 升级方法和装置
CN110865837B (zh) 一种进行系统升级的方法和终端
CN111373379A (zh) 一种数据备份方法及终端
WO2021143168A1 (zh) 可信执行环境操作系统崩溃处理方法及电子设备
CN112347048A (zh) 电子装置及其共享数据的方法
CN112416411B (zh) 升级方法及装置、设备端、服务器、计算机可读介质
WO2022063037A1 (zh) 一种补丁包安装方法和装置
US11379458B2 (en) Electronic device and data management method thereof
CN112486733B (zh) 系统还原方法、装置、终端及存储介质
CN116382791B (zh) 一种配置文件的保护方法及电子设备
CN116700768B (zh) 一种应用的处理方法及相关装置
CN114138343A (zh) 一种终端及终端启动方法
KR100588199B1 (ko) 휴대 단말기에서 프로그램 다운로드 실패시 이의 복구방법 및 이를 적용한 휴대 단말기
CN114968314B (zh) 显示设备的固件升级方法、装置、电子设备及存储介质
CN116028433B (zh) 数据迁移方法和电子设备
CN117707630A (zh) 分区切换过程中的中断处理方法、设备及存储介质
WO2016008139A1 (zh) 用户设备的系统安装方法和装置
CN117130627A (zh) 配件升级方法及电子设备