CN117707626A

CN117707626A - System starting method and electronic equipment

Info

Publication number: CN117707626A
Application number: CN202310331935.7A
Authority: CN
Inventors: 钟微; 余亮
Original assignee: Honor Device Co Ltd
Current assignee: Honor Device Co Ltd
Priority date: 2022-10-09
Filing date: 2022-10-09
Publication date: 2024-03-15
Also published as: CN115328563A; CN115328563B; WO2024078218A1

Abstract

The embodiment of the application provides a system starting method and electronic equipment. In the method, in the process that the electronic equipment starts a system in one of the system starting partitions, if the mirror image verification of the system starting partition fails, the electronic equipment continues to restart the system in the system starting partition; the electronic equipment is successfully restarted in the first system starting partition. Therefore, the probability problem of failure of image verification of the system starting partition can be solved, the self-recovery capacity of the electronic equipment in the system starting process is improved, and the probability of crash of the electronic equipment caused by the probability failure of image verification is greatly reduced.

Description

System starting method and electronic equipment

The present application is a divisional application, the name of the original application is a system start method and an electronic device, the application number of the original application is 202211229448.1, the original application date is 2022, 10 and 09, and the entire content of the original application is incorporated by reference in the present application.

Technical Field

The application relates to the technical field of intelligent terminals, in particular to a system starting method and electronic equipment.

Background

From the overall starting-up flow of the terminal equipment, bootLoader is operated first after the terminal equipment is powered on. That is, in an embedded operating system, the BootLoader is running before the operating system kernel runs. The BootLoader can initialize the hardware device and build a memory space map to bring the system's hardware and software environment to a proper state to prepare the correct environment for the final call to the operating system kernel.

In the BootLoader stage, each system boot partition image is checked, and once each system boot partition image fails to check, the terminal device enters a Fastboot mode. At this time, the user needs to ask a professional maintenance person to solve. In view of the fact that users increasingly depend on mobile intelligent terminals represented by smart phones, the terminal system enters a Fastboot mode, which definitely brings serious trouble to life and work of the users.

Therefore, when the mobile intelligent terminal encounters a startup fault in the BootLoader stage, how to reduce the probability of the terminal entering the Fastboot mode is a problem to be solved.

Disclosure of Invention

In order to solve the above technical problems, embodiments of the present application provide a system starting method and an electronic device. In the method, in the process that the electronic equipment starts the system in one of the system starting partitions, if the mirror image verification of the system starting partition fails, the electronic equipment continues to restart the system in the system starting partition, so that the probability problem of the failure of the mirror image verification of the system starting partition is solved, the self-recovery capacity of the electronic equipment in the system starting process is improved, and the probability of the crash of the electronic equipment caused by the probability failure of the mirror image verification is greatly reduced.

In a first aspect, an embodiment of the present application provides a system startup method. The method is applied to the electronic equipment, and the electronic equipment comprises a first system starting partition and a second system starting partition. The method comprises the following steps: comprising the following steps:

in the process that the electronic equipment starts the system in the first system starting partition, if the mirror image verification of the first system starting partition fails, the electronic equipment restarts the system in the first system starting partition;

the electronic equipment is successfully restarted in the first system starting partition.

The failure of the image verification is largely a probabilistic problem, and is exemplified by the probability that the failure is caused by level modulation, hardware devices, and not permanent damage.

Therefore, if the image verification of a certain system starting partition fails, the electronic equipment continues to restart the system in the system starting partition, so that the probability problem of the image verification failure of the system starting partition is solved, the self-recovery capacity of the electronic equipment in the system starting process is improved, and the probability of dead halt of the electronic equipment due to the probability failure of the image verification is greatly reduced.

According to a first aspect, the method further comprises: in the process that the electronic equipment restarts the system in the first system starting partition, if the mirror image verification of the first system starting partition fails, the electronic equipment is switched to a second system starting partition to start the system;

In the process that the electronic equipment starts the system in the second system starting partition, if the mirror image verification of the second system starting partition fails, the electronic equipment restarts the system in the second system starting partition;

and the electronic equipment is successfully restarted in the second system starting partition.

The first system starting partition and the second system starting partition are backup partitions.

Thus, if the image verification failure of a certain system boot partition is not a probabilistic problem, the electronic device switches to boot the partition. When the electronic equipment is started on the area, if the mirror image verification on the area also fails, the electronic equipment continues to restart the system in the area, so that the probability problem of failure of the mirror image verification of the system starting partition is solved, the self-recovery capacity of the electronic equipment in the system starting process is improved, and the probability of dead halt of the electronic equipment due to the probability failure of the mirror image verification is greatly reduced.

According to the first aspect, or any implementation manner of the first aspect, the switching, by the electronic device, to the second system start partition to perform system start may include: if the attribute of the second system starting partition is in a starting state, the electronic equipment is switched to the second system starting partition to start the system.

Under an application scene, if the second system starting partition OTA is successfully upgraded by the electronic equipment, the first system starting partition and the second system starting partition are both in a starting state, and the electronic equipment can switch between the two partitions.

According to the first aspect, or any implementation manner of the first aspect, the method further includes: and if the attribute of the second system startup partition is in an unbootable state, the electronic equipment performs a quick startup mode.

In an application scenario, when the electronic device starts the partition OTA to the second system, if rollback occurs due to upgrade failure, the attribute of the second system start partition is in a non-bootable state, at this time, the electronic device will not switch between the two partitions, but when the first system start partition is confirmed to be a non-probabilistic damage problem, the electronic device performs a fast start mode (Fastboot mode).

According to the first aspect, or any implementation manner of the first aspect, the method further includes: and in the process that the electronic equipment restarts the system in the second system starting partition, if the mirror image verification of the second system starting partition fails, the electronic equipment performs a quick starting mode.

Under an application scenario, when the electronic device confirms that the first system startup partition and the second system startup partition are both not damaged probabilistically, the electronic device performs a fast startup mode (Fastboot mode).

According to the first aspect, or any implementation manner of the first aspect, if the image verification of the first system start partition fails, the electronic device performs a system restart in the first system start partition, including:

if the image verification of the first system starting partition fails, and the image verification failure times of the first system starting partition is smaller than a first threshold value, the electronic equipment restarts the system in the first system starting partition;

if the mirror image verification of the first system starting partition fails, the electronic equipment is switched to a second system starting partition to start the system, and the method comprises the following steps:

if the image verification of the first system starting partition fails and the image verification failure times of the first system starting partition are equal to a first threshold value, the electronic equipment is switched to a second system starting partition to start the system; wherein the first threshold is greater than 2.

Illustratively, the second threshold is 3.

Thus, if the image verification of a certain system starting partition fails, the electronic equipment continues to restart the system for multiple times (for example, two to three times) in the system starting partition, so that the probability problem of the image verification failure of the system starting partition is solved, the self-recovery capacity of the electronic equipment in the system starting process is improved, and the electronic equipment is prevented from entering a Fastboot mode. If the electronic equipment cannot be started normally after restarting the system for a plurality of times in the system starting partition, the problem of non-probabilistic damage of the system starting partition can be confirmed, and at the moment, the electronic equipment is switched to the partition to start continuously.

According to the first aspect, or any implementation manner of the first aspect, if the image verification of the second system start partition fails, the electronic device performs a system restart in the second system start partition, including:

if the image verification of the second system starting partition fails and the image verification failure times of the second system starting partition is smaller than a second threshold value, the electronic equipment restarts the system in the second system starting partition; wherein the second threshold is greater than 1.

Illustratively, the second threshold is 2.

Therefore, after the electronic equipment performs partition switching, if the mirror image verification of a certain system starting partition fails, the electronic equipment continues to restart the system for multiple times (for example, two to three times) in the system starting partition, so that the probability problem of the failure of the mirror image verification of the system starting partition is solved, the self-recovery capacity of the electronic equipment in the system starting process is improved, and the electronic equipment is prevented from entering a Fastboot mode.

If the image verification of the first system starting partition fails and the first system starting partition is not in OTA upgrading, the electronic equipment restarts the system in the first system starting partition.

In this way, the normal use scene of the terminal equipment and the OTA upgrading scene are partitioned, so that the terminal equipment executes a recovery strategy determined based on the probability AVB verification failure problem, the original OTA upgrading process is not influenced, and the original OTA upgrading process can be ensured to be executed normally.

According to the first aspect, or any implementation manner of the first aspect, when the electronic device performs a system restart in the first system start partition, the method further includes: recording log information corresponding to the failure of the mirror image verification of the first system starting partition and a recovery strategy, wherein the recovery strategy is used for restarting the system of the electronic equipment in the first system starting partition.

According to the first aspect, or any implementation manner of the first aspect, when the electronic device performs a system restart in the second system start partition, the method further includes: recording log information corresponding to the failure of the mirror image verification of the second system starting partition and a recovery strategy, wherein the recovery strategy is used for restarting the system of the electronic equipment in the second system starting partition.

According to the first aspect, or any implementation manner of the first aspect, when the electronic device is switched to the second system start partition to perform system start, the method further includes: recording log information corresponding to the failure of the mirror image verification of the first system starting partition and a recovery strategy, wherein the recovery strategy is that the electronic equipment is switched to the second system starting partition to start the system.

According to the first aspect, or any implementation manner of the first aspect, after the electronic device system is started successfully, the method further includes: and uploading the log information and the recovery strategy to the cloud.

In a second aspect, embodiments of the present application provide 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 on the memory, which when executed by the one or more processors, cause the electronic device to perform the system start-up method of any of the first aspect and the first aspect.

Any implementation manner of the second aspect and the second aspect corresponds to any implementation manner of the first aspect and the first aspect, respectively. The technical effects corresponding to the second aspect and any implementation manner of the second aspect may be referred to the technical effects corresponding to the first aspect and any implementation manner of the first aspect, which are not described herein.

In a third aspect, embodiments of the present application provide a computer-readable storage medium. The computer readable storage medium comprises a computer program which, when run on an electronic device, causes the electronic device to perform the system start-up method of any of the first aspect and the first aspect.

Any implementation manner of the third aspect and any implementation manner of the third aspect corresponds to any implementation manner of the first aspect and any implementation manner of the first aspect, respectively. The technical effects corresponding to the third aspect and any implementation manner of the third aspect may be referred to the technical effects corresponding to the first aspect and any implementation manner of the first aspect, which are not described herein.

In a fourth aspect, embodiments of the present application provide a computer program product comprising a computer program which, when executed, causes a computer to perform the system start-up method according to any one of the first or second aspects.

Any implementation manner of the fourth aspect and any implementation manner of the fourth aspect corresponds to any implementation manner of the first aspect and any implementation manner of the first aspect, respectively. Technical effects corresponding to any implementation manner of the fourth aspect may be referred to the technical effects corresponding to any implementation manner of the first aspect, and are not described herein.

In a fifth aspect, the present application provides a chip comprising processing circuitry, a transceiver pin. Wherein the transceiver pin and the processing circuit communicate with each other via an internal connection path, the processing circuit performing the system start-up method as in the first aspect or any one of the first aspects to control the receiving pin to receive signals and to control the transmitting pin to transmit signals.

Any implementation manner of the fifth aspect and any implementation manner of the fifth aspect corresponds to any implementation manner of the first aspect and any implementation manner of the first aspect, respectively. Technical effects corresponding to any implementation manner of the fifth aspect may be referred to the technical effects corresponding to any implementation manner of the first aspect, and are not described herein.

Drawings

Fig. 1 is a frame diagram of a startup procedure of an Android system terminal shown in an exemplary manner;

FIG. 2 is a schematic diagram of a system start-up flow in the prior art;

FIG. 3a is a schematic diagram of an exemplary application scenario;

FIG. 3b is a schematic diagram of an exemplary application scenario;

FIG. 4 is a schematic diagram of a system start-up procedure according to an embodiment of the present disclosure;

FIG. 5 is a schematic diagram of a system start-up procedure according to an embodiment of the present disclosure;

FIG. 6 is a schematic diagram of a system start-up procedure according to an embodiment of the present disclosure;

FIG. 7 is a schematic of a software framework at system start-up that is exemplary;

FIG. 8 is a schematic diagram of data in an exemplary illustrated storage partition;

FIG. 9 is a schematic diagram of exemplary module interactions;

fig. 10 is a schematic diagram of a hardware structure of an exemplary electronic device;

fig. 11 is a software configuration diagram of an exemplary electronic device.

Detailed Description

The following description of the embodiments of the present application will be made clearly and fully with reference to the accompanying drawings, in which it is evident that the embodiments described are some, but not all, of the embodiments of the present application. All other embodiments, which can be made by one of ordinary skill in the art based on the embodiments herein without making any inventive effort, are intended to be within the scope of the present application.

The term "and/or" is herein merely an association relationship describing an associated object, meaning that there may be three relationships, e.g., a and/or B, may represent: a exists alone, A and B exist together, and B exists alone.

The terms first and second and the like in the description and in the claims of embodiments of the present application are used for distinguishing between different objects and not necessarily for describing a particular sequential order of objects. For example, the first target object and the second target object, etc., are used to distinguish between different target objects, and are not used to describe a particular order of target objects.

In the embodiments of the present application, words such as "exemplary" or "such as" are used to mean serving as examples, illustrations, or descriptions. Any embodiment or design described herein as "exemplary" or "for example" should not be construed as preferred or advantageous over other embodiments or designs. Rather, the use of words such as "exemplary" or "such as" is intended to present related concepts in a concrete fashion.

In the description of the embodiments of the present application, unless otherwise indicated, the meaning of "a plurality" means two or more. For example, the plurality of processing units refers to two or more processing units; the plurality of systems means two or more systems.

The method provided by the embodiment of the application can be applied to various types of electronic equipment. For example, the electronic device in the embodiments of the present application may be an electronic device such as a mobile phone, a tablet computer, a desktop, a laptop, a handheld computer, a notebook, an ultra-mobile personal computer (ultra-mobile personal computer, UMPC), a netbook, a cellular phone, a personal digital assistant (personal digital assistant, PDA), an augmented reality (augmented reality, AR) \virtual reality (VR) device, and the specific form of the electronic device is not limited in the embodiments of the present application.

In an embodiment of the present application, an electronic device may include a hardware layer, an operating system layer running above the hardware layer, and an application layer running above the operating system layer. The hardware layer includes hardware such as a central processing unit (central processing unit, CPU), a memory management unit (memory management unit, MMU), and a memory (also referred to as a main memory). The operating system may be any one or more computer operating systems that implement business processes through processes (processes), such as an Android operating system, an iOS operating system, or a windows operating system, etc. The application layer comprises applications such as a browser, an address book, word processing software, instant messaging software and the like.

The following describes a startup procedure of the terminal by taking an Android operating system as an example. The Android operating system starting process can be divided into two phases, wherein the first phase is the Linux starting process, and the second phase is the Android starting process (which can be called an upper-layer starting process). Fig. 1 is a frame diagram of a startup procedure of a terminal based on an Android system. As shown in fig. 1, the startup procedure includes:

01. boot rom—when the Boot key is pressed, the Boot chip starts to execute from the preset code cured in Rom, and then loads the Boot program into RAM.

02. Bootloader, also known as a boot loader, is a section of program that runs before the operating system runs, and is the first program that runs to copy an operating system image file into RAM and then jump to the entry of the image file to execute the file, also known as entering a boot loader mode.

03. Kernel-after loading the Kernel into memory, first enter the Kernel boot phase, at the end of the Kernel boot phase, call start_kernel to enter the Kernel start phase, mainly finish most of the initialization work of the Kernel. Start_kernel will eventually Start the init process of the user space.

04. init Process-after initializing the kernel, an init process is started, all processes in Linux come out of the init process directly or indirectly. The init process is responsible for creating the most critical several core daemon processes in the system, including but not limited to zygate and service manager. Wherein zygate is the first dalvik virtual machine started by android, which is responsible for starting Java processes. service manager is the basis for Binder communication.

05. Zygate process—this process is the parent of all Java processes. For example, the zygate virtual machine starts a sub-process system_server while defining a Socket for receiving a request from actigraphy manager service to start an application.

06. System Server Process-when the System Server Process is started, activityManagerService is initialized. Meanwhile, a service library of the local system is loaded, a createSystemContext () is called to create a system context, an ActivityThread is created, various services are started, and the like.

07. Home Activity-after ActivityManagerService is started, finishBooting () is called to complete the booting process, and meanwhile, a startup broadcast is sent, a Home interface is entered, and a desktop is displayed.

In the above boot flow, bootloader performs validity check on the image file of the operating system. Because the android system is an operating system based on a kernel, in the actual starting process, a boot program image, a kernel image and a main system image of the starting operating system can be sequentially loaded into a memory, the validity of each image is sequentially verified in the memory, the next image is loaded into the memory only after the previous image is verified to be legal, and the main system image can be unfolded into a main system program really seen by a user under the help of the kernel until the main system image is also verified to be legal, so that the starting whole process of the android device is completed.

It should be noted that the description given herein is only a summary of the actual starting process, which is more complex, but the principles are the same, and different versions of the android system may make some adjustments in the details of some steps, which is not limited in detail herein.

In other words, it is necessary to check whether the main system image satisfies the validity before being developed as the main system program, and only after the validity check is passed, the main system image is developed as the main system program. And once the mirror image validity verification of the main system fails, the android system cannot be started normally.

At present, android A/B partition systems are mostly adopted by Android system terminals. The A/B partition system, as the name implies, has two sets of systems, one set of system partitions and the other set of backup partitions. The two systems are shipped from the factory as, and may be different thereafter, one new version and the other old version.

Assume that the normal system startup partition is slot_a and the backup system startup partition is slot_b. When the data of the slot_a partition is damaged, the terminal equipment can be automatically switched to the slot_b partition to restart the system, and if the slot_b partition is unavailable or the data of the slot_b partition is damaged, the terminal equipment can automatically enter a Fastboot mode. Wherein Fastboot mode refers to a fast start mode. Fastboot is a simple flush protocol defined by Android, which can be flushed through the Fastboot command line tool. Once the terminal device enters Fastboot mode, the user needs to ask a professional maintenance staff to solve.

In one implementation, the data integrity, reliability, and legitimacy of the partition image file is verified in a Bootloader based on a AVB (Android verify boot) security mechanism. The AVB checking function is mainly realized by an external/AVB/libavb library, and the work mainly completed by the library comprises checking of each partition mirror image, signature verification and analysis of vbmeta data, including processing of various flags and parameter analysis required by dm-quality.

At present, in the native logic of system startup, as shown in fig. 2, a terminal device normally starts a slot_a partition when the terminal device is started, if the check of the slot_a partition mirror image AVB fails, the terminal device is switched to a slot_b partition to start, and if the slot_b partition starts, the terminal is started successfully. However, if the slot_b partition image AVB check fails, the terminal device enters the Fastboot mode.

However, the occurrence of data corruption in system boot partitions is largely a probabilistic problem, as it may be caused by level jumps, probabilistic failure of hardware devices (such as storage media), and not permanent corruption problems. For example, unpredictable factors such as environmental factors, temperature factors, static factors, etc. may cause probabilistic level jumps when the hardware storage medium is in use, which in turn may cause the system to boot the partition image verification failure. The research finds that most of terminal equipment entering the Fastboot mode due to failure of partition image verification can be normally started after the system startup partition is restarted and activated and restarted, so that the probability abnormality problem of the storage device is more verified, and the storage device is not permanently abnormal.

In practical application, since the Android A/B partition system needs to open up two boot storage spaces and two system storage spaces, the aim of ensuring that an upgrade partition does not affect an operation partition is to realize that a system OTA (Over-the-Air) is not down.

In the OTA scenario, A/B partition system updates are also known as Seamless updates (Seamless updates). The OTA update runs in the background of the system, and the user can still normally use the device in the process. After the update is completed, the new system can be accessed by restarting once. If the OTA update fails (the OTA update cannot be applied or cannot be started after the application), the device can restart to roll back to the old partition to continue to use, and re-attempt to update the upgrade. The terminal equipment can adopt a streaming upgrade mode, namely, the terminal equipment can also carry out OTA upgrade without reserving enough space for storing the downloaded upgrade package by/data or/cache partition. The terminal equipment ensures that a set of system which can be normally started to be used is reserved on the disk during OTA updating, reduces the possibility of changing bricks when a user brushes the machine, and reduces the workload of after-sales service.

In an actual application scenario, a terminal device performs OTA upgrade on a slot_b partition, and after the OTA upgrade fails, the system rolls back to the slot_a partition. At this time, the partition slot_a is bootable normally, and the partition slot_b is not bootable (or is not bootable). And normally starting the slot_a partition when the terminal equipment is started, and if the AVB verification of the slot_a partition image fails, directly entering a Fastboot mode by the terminal because the slot_b partition cannot be started.

In another practical application scenario, the terminal device performs OTA upgrade on the slot_b partition, the OTA upgrade is successful, and the slot_b partition can be started normally. At this time, the partition slot_a may be started normally, and the partition slot_b may be started normally. And normally starting the slot_b partition when the terminal equipment is started, if the AVB verification of the slot_b partition image fails, switching the terminal equipment to the slot_a partition for starting, and if the slot_a partition is started, successfully starting the terminal. However, if the slot_a partition image AVB check fails, the terminal device enters the Fastboot mode.

In these application scenarios, there is a problem that the logic cannot handle failure of the partition image probabilistic check. And once the AVB check of the partition image fails, the partition is switched, and the switched partition image fails the AVB check again, so that the terminal enters the Fastboot mode, the probability of the terminal equipment entering the Fastboot mode is certainly increased, a stable recovery mechanism is lacked, and the use experience of a user is reduced.

In order to solve the above problems, the embodiment of the present application provides a system startup method. In the method, the problem of probabilistic failure of the partition mirror image AVB verification is fully considered, a recovery strategy is designed, and the system can be automatically recovered and normally started when the partition mirror image AVB verification fails, so that the probability of the terminal equipment entering the Fastboot mode is reduced, and the use experience of a user is further improved.

In the embodiment of the application, the scenes involved in the system start of the terminal equipment can comprise a normal use scene and an OTA upgrade scene. The normal use scene can be divided into an OTA upgrade success scene and an OTA upgrade failure rollback scene.

Before explaining the system starting method provided by the embodiment of the application based on the application scenes, the related concepts are explained.

The starting up of the terminal device may be triggered by the user pressing a power key of the device, or may be triggered by some settings of the system, for example, the terminal device is started at a fixed time, or may be triggered by some anomalies of the system, which is not limited in this embodiment of the present application.

In order for a Bootloader to determine whether a system boot partition is in a state that can be booted, it is necessary to define a corresponding attribute (state) for it. The state is illustrated by way of example as follows:

attribute Active, which is an Active partition identification, exclusive, and representing that a partition is a starting partition, bootloader always selects the partition to start the system;

attribute bootable, which indicates that a set of possible system capable of starting exists in the partition;

attribute success indicates that the system of the partition can be started normally;

The attribute unbootable represents that the partition is damaged, cannot be started and is always marked in the upgrading process.

The other flags (active, bootable, successful) are cleared when the partition is marked as unset, and the unset flag is cleared when the partition is marked as active.

Of the slot_a partition and the slot_b partition, only one partition may have an active attribute, but two partitions may have both a bootable attribute and a success attribute.

When the terminal equipment is started, the bootloader detects that 1 or 2 slot partitions are in bootable state, and selects the slot partition with active attribute or selects the slot partition with successfull attribute to start in an attempt. If the partition is successfully started, the partition attribute can be set as success and active; if the partition fails to start, the partition attribute may be set as unbootable, and the attribute of another partition may be set as active for the next attempt.

The following describes the attribute setting of the slot partition in combination with several scenarios:

1. common scene (Normal cases)

The common scenario is the most common situation, for example, when the device leaves the factory, the slot_a partition and the slot_b partition can be successfully started and normally run, so that both partitions are set as bootable and successful. Suppose that a boot is initiated from the slot_b partition, only the slot_b partition is set to active.

2. In upgrading (Update in progress)

Upgrading data is detected by the slot_b partition, upgrading is carried out on the slot_a partition, at the moment, the slot_a partition is marked as an unbootable, and additionally, the success mark of the slot_a partition is cleared; the slot_b partition attribute is still active, bootable and success.

3. Update complete, wait for restart (Update applied, reboot pending)

And after the slot_b partition successfully updates the slot_a partition, the slot_a partition is marked as bootable. In addition, since it is necessary to start from the slot_a partition after the restart, it is also necessary to set the slot_a partition to active. However, since it has not been verified whether the slot_a partition can run successfully, the slot_a partition is not set with success; the state of the slot_b partition becomes bootable and successful, but no active.

4. Successful start-up of the re-system (System rebooted into new update)

After the equipment is restarted, the bootloader detects that the slot_a partition is active, so that the slot_a partition system is loaded. If the system can normally run after entering the slot_a partition system, the slot_a partition needs to be identified as a success. In contrast to the normal scenario, the slot_a partition and the slot_b partition are set as bootable and successful, but active is switched from the slot_b partition to the slot_a partition. So far, the slot_b partition is successfully updated and switched to the slot_a partition, and the device reenters the common scene.

Scene one

In the present scenario, the terminal device is in a normal use state, and before that, a certain system of the terminal device starts a partition OTA upgrade successfully. At this time, two system startup partitions (such as a slot_a partition and a slot_b partition) of the terminal device are both in a normal bootable (bootable) state.

As shown in fig. 4, assuming that the attribute of the slot_a partition is active, the terminal device normally starts the slot_a partition when the terminal device is started. If the slot_a partition image AVB check fails, the terminal equipment restarts the slot_a partition. If the slot_a partition is restarted, the slot_a partition is successfully started, the result shows that the failure of the AVB check of the mirror image of the slot_a partition is a probability problem, and the terminal equipment can be started normally through a restarting recovery strategy. If the AVB check of the slot_a partition image fails again when restarting the slot_a partition, the terminal equipment restarts the slot_a partition again. If the slot_a partition is restarted, the slot_a partition is successfully started, the defect that the AVB of the mirror image of the slot_a partition fails to be checked is indicated to be a probability problem, and the terminal equipment can be started normally through a restarting recovery strategy. If the AVB check of the slot_a partition image fails again when restarting the slot_a partition image again, the non-probabilistic problem of the AVB check failure of the slot_a partition image is indicated, and the problem of permanent damage of the slot_a partition image is possibly caused, and the partition image is switched to the slot_b partition to continue to be started.

It should be noted that, since the terminal device needs to be started from the slot_a partition after restarting, the terminal device needs to set the slot_a partition to active before restarting.

With continued reference to fig. 4, when the terminal device is switched to the slot_b partition to start, if the slot_b partition is the slot_b partition, the problem of abnormal starting of the terminal device is repaired by partition switching at this time. When the terminal equipment is switched to the slot_b partition for starting, if the AVB verification of the slot_b partition image fails, the terminal equipment restarts the slot_b partition. If the partition of the slot_b is restarted, the partition of the slot_b is successfully started, the result shows that the failure of the AVB check of the mirror image of the partition of the slot_b is a probability problem, and the terminal equipment can be started normally through a restarting recovery strategy. If the AVB check of the partition image of the partition_b fails again when restarting the partition of the partition_b, the non-probabilistic problem of the AVB check failure of the partition image of the partition_b is indicated, which may be the problem of permanent damage of the partition image of the partition_b, and the terminal device enters the Fastboot mode.

It should be noted that, since the terminal device needs to be started from the slot_b partition after restarting, the terminal device needs to set the slot_b partition to active before restarting.

When the terminal equipment is in power-on failure due to failure of the mirror image verification of a certain system starting partition, the terminal equipment selects the next recovery strategy according to the previous recovery record corresponding to the current system starting partition. If the current system starting partition fails to check the first AVB and fails to check the second AVB, restarting is used as a next recovery strategy to eliminate the problem of the probabilistic AVB failure; if the current system starting partition fails to check the AVB for the third time, the problem that the current system starting partition fails to check the AVB non-probability can be determined, the current system starting partition is possibly permanently damaged, and the switching partition is started to be used as a next recovery strategy. After the partition is switched, the fourth AVB check is to mirror the region, if the AVB check of the region fails, the restarting is used as the next recovery strategy in order to eliminate the problem of the failure of the AVB check of the region probability; if the two continuous AVB checks of the zone mirror image fail, the problem of non-probabilistic AVB check failure of the zone can be determined, the zone mirror image is possibly permanently damaged, and the terminal equipment enters a Fastboot mode.

It should be noted that in the above procedure, the slot_a partition is restarted twice and the slot_b partition is restarted once, and the number of restarts is merely illustrative. In order to solve the probabilistic problem of failure in the partition image AVB verification, the number of restarting the slot_a partition and/or the slot_b partition may be reasonably set according to the actual situation, for example, two to three times, which is not limited in the embodiment of the present application.

Therefore, the scheme can ensure that the terminal equipment can realize automatic recovery more safely, increase the reliability of the terminal equipment after the abnormal AVB verification fails, ensure that the terminal equipment can recover automatically under the abnormal condition, and greatly reduce the probability of dead halt of the terminal equipment due to the probability failure problem of the partition mirror image AVB verification.

Scene two

In this scenario, the terminal device is in a normal use state, and before that, a certain system of the terminal device starts the partition OTA upgrade and fails to roll back. At this time, two systems of the terminal device start partitions, one is in a normal bootable (bootable) state and one is in an abnormal non-bootable (bootable) state.

As shown in fig. 5, assuming that the attribute of the slot_a partition is active, the terminal device normally starts the slot_a partition when the terminal device is started. If the slot_a partition image AVB check fails, the terminal equipment restarts the slot_a partition. If the slot_a partition is restarted, the slot_a partition is successfully started, the result shows that the failure of the AVB check of the mirror image of the slot_a partition is a probability problem, and the terminal equipment can be started normally through a restarting recovery strategy. If the AVB check of the slot_a partition image fails again when restarting the slot_a partition, the terminal equipment restarts the slot_a partition again. If the slot_a partition is restarted, the slot_a partition is successfully started, the defect that the AVB of the mirror image of the slot_a partition fails to be checked is indicated to be a probability problem, and the terminal equipment can be started normally through a restarting recovery strategy. If the AVB check of the slot_a partition image fails again when restarting the slot_a partition again, the non-probabilistic problem of the slot_a partition image AVB check failure is indicated, and the problem of permanent damage of the slot_a partition image is likely.

At this time, if the terminal device needs to switch to the slot_b partition to continue starting, the attribute of the slot_b partition needs to be judged first. If the attribute of the slot_b partition is in a normal bootable (bootable) state, the terminal device switches to the slot_b partition to continue to start, and the subsequent flow can refer to the first scene and is not described herein. If the attribute of the slot_b partition is in an abnormal non-bootable (unbootable) state, the terminal device directly enters a Fastboot mode.

Thus, for terminal devices that are in normal use, the terminal devices can be divided into two types: for a terminal device after an OTA upgrade has succeeded, both partitions are bootable, and for a terminal device after an OTA upgrade has failed and rolled back, the other partition of the terminal device is not bootable. Therefore, when the AVB image verification failure occurs in the use process (not OTA upgrade) of the terminal device, it needs to be determined whether the terminal device is bootable to the zone, and when the terminal device is bootable to the zone, the recovery policy of cutting the zone is executed.

In another alternative embodiment, in the scenario that the end device OTA upgrade fails to roll back, although the exception of the state of the system boot partition that fails to upgrade is not bootable (bootable), after the end device OTA upgrade fails to roll back, the images of the two system boot partitions should be identical. The image of the slot_a partition is an image 1, and the image of the slot_b partition is an image 1 before the OTA upgrade of the slot_b partition; after the OTA of the slot_a partition fails to upgrade and rolls back, the image of the slot_a partition does not become image 1, the image of the slot_b partition is not successfully upgraded, or the image 1.

Thus, in the scenario of a terminal device OTA upgrade failure rollback, when a slot_a partition reboots multiple times to eliminate the probabilistic AVB image verification failure problem, a switch to a slot_b partition may also be attempted to execute a recovery policy as described above. It should be noted that, in order to implement such an embodiment, before switching to the slot_b partition starts, the attribute of the slot_b partition needs to be set to active.

Scene three

In this scenario, the terminal device is in an OTA upgrade state.

When the terminal equipment is in an OTA upgrading state, if the problem of AVB verification failure of the partition mirror image occurs, the terminal equipment cannot execute a recovery strategy determined based on the problem of probabilistic AVB verification failure in order to ensure normal execution of the original upgrading flow of the OTA.

As shown in fig. 6, assuming that in the boot process of the slot_a partition, the terminal device detects the problem of failure in checking the partition image AVB, it is first determined whether the slot_a partition is in the process of OTA upgrade. If the slot_a partition is in the process of OTA upgrading, starting is continued according to the existing logic, otherwise, starting is continued according to the system starting logic provided by the embodiment of the application, and the first scene and the second scene can be referred to, and details are not repeated here.

Illustratively, if the mirrored AVB check of the slot_a partition fails during the OTA upgrade, the recovery policy determined based on the probabilistic AVB check failure problem is not executed, but the system is rolled back to the slot_b partition according to the logic of the OTA upgrade failure.

In order to implement the system startup method provided in the embodiments of the present application, as shown in fig. 7, the terminal device may include a Bootloader startup framework, a startup failure detection (BootDetector) module, a startup failure recovery (BootRecovery) module, and an adapter (adapter).

The Bootloader is used for detecting a non-startup fault, and in the embodiment of the application, the Bootloader is specifically used for detecting whether partition mirror image AVB verification fails; the BootDetector is used for processing the non-startup fault, and is specifically used for detecting the failure fault of the partition mirror image AVB in the embodiment of the application; the BootRecovery is used for determining and recording a failure recovery policy, and in this embodiment of the present application, is specifically used for determining and recording a failure recovery policy corresponding to a failure of checking the partition mirror AVB.

With continued reference to fig. 7, a memory partition is included in the physical resources of the terminal device as well as reserved physical memory. The physical memory is reserved for storing identification information of the current starting stage of the system. Exemplary system startup phases include, but are not limited to, bootloader startup phase, kernel startup phase, android startup phase, and the like.

As shown in fig. 8, the memory partition may be used to store terminal device system start-up information and system recovery information. The system start information at least comprises system start log information, and each group of log information at least comprises log header information, bootloader log information and kernel log information. The log header information is used for describing byte numbers occupied by Bootloader log information and kernel log information. The system recovery information may include at least policy information used for system recovery, and may also include a system recovery record. The embodiments of the present application are not limited with respect to the format and field distribution of the memory partition.

To ensure that Bootloader and kernel can access the memory partition simultaneously and independently of the file system, the memory partition may be designed in the form of a bare partition.

It should be noted that, in order to make the system starting method provided by the present application suitable for different chip platforms, a pre-packaged adapter is further provided in the terminal device, so that the BootDetector and BootRecovery can access the storage partitions (bare partitions) corresponding to different chip platforms through the adapter.

Fig. 9 illustrates a schematic diagram of module interactions. As shown in fig. 9, the steps of the system starting method provided in the embodiment of the present application specifically include:

and 1. Detecting that the partition image AVB verification fails by the bootloader.

In the starting process of the terminal equipment, the Bootloader detects whether a non-starting fault exists. In this embodiment, bootloader is used to detect whether the image of the slot partition of the starting system has an AVB verification failure problem.

Bootloader calls BootDetector to handle the power-on failure.

And when the Bootloader detects that the current slot partition image AVB verification fails, invoking a BootDetector to process the startup fault. In this embodiment, the Bootloader calls the BootDetector to process the problem of failure in the AVB check of the slot partition image.

Illustratively, when the Bootloader calls the BootDetector, the set processing parameters may include, but are not limited to: the slot partition identifies the status (bootable or bootable) of whether the slot partition is bootable. The slot partition identifier included in the processing parameter is used for indicating the partition where the mirror image AVB verification fails currently.

BootDetector checks the validity of the processing parameters.

After the BootDetector receives the call of the Bootloader, firstly checking the validity of the processing parameters, if the processing parameters are legal, continuing to execute downwards, otherwise, not responding to the call of the Bootloader.

And 4, the BootDetector calls a BootRecovery acquisition recovery strategy.

When the call processing parameters of the Bootloader are legal, the BootDetector continues to call BootRecovery to acquire a corresponding recovery strategy.

Exemplary parameters when a BootDetector calls BootRecovery may include, but are not limited to: the slot partition identifies the status (bootable or bootable) of whether the slot partition is bootable. The slot partition identifier included in the parameter is used for indicating the partition where the mirror image AVB verification fails currently.

BootRecovery read recovery record.

In response to a boot call, the boot may read a recovery record corresponding to the current boot in a storage partition (bare partition). Wherein the recovery record may include, but is not limited to: slot partition identification, AVB check failure times, etc. Note that, the recovery record may be stored in another partition, which is not limited in this embodiment.

Bootrecovery check correction recovery record.

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.

Illustratively, assume that the read recovery record is: and correcting the recovery record to be the slot_a partition when the boot call parameter indicates that the partition which is currently subjected to the mirror image AVB verification failure is the slot_a partition, wherein the AVB verification failure times are 1, and the AVB verification failure times are 2.

Also by way of example, assume that the read recovery record is: if the number of AVB check failures is 3 in the slot_a partition, correcting the recovery record to be the slot_a partition when the boot call parameter indicates that the partition which is currently subjected to the mirror image AVB check failure is the slot_b partition, and the number of AVB check failures is 3; and the partition_b is partitioned, and the AVB check failure times are 1.

For another example, assuming that the read recovery record is empty, when the BootDetector call parameter indicates that the partition where the current image AVB check failure occurs is a slot_a partition, the recovery record is corrected to be a slot_a partition, and the AVB check failure number is 1.

BootRecovery chooses a recovery strategy.

And the BootRecovery selects the current recovery strategy according to the corrected recovery record.

Assume that the AVB check failure number threshold set by the terminal device before partition switching is x1, and the AVB check failure number threshold set by the terminal device after partition switching is x2. The AVB number of times of failure threshold x1 may be set to an integer greater than 2, and the AVB number of times of failure threshold x2 may be set to an integer greater than 1.

And under the condition that the terminal equipment starts to start at the slot_a partition, the AVB check failure frequency threshold value of the slot_a partition is x1. And after partition switching, starting the terminal equipment in the slot_b partition, wherein the AVB check failure frequency threshold value of the slot_b partition is x2.

For example, the AVB check failure number threshold x1 set by the terminal device before partition switching may be set to 3, and the AVB check failure number threshold x2 set by the terminal device after partition switching may be set to 2. It can be appreciated that the AVB check failure number threshold mentioned herein is only an exemplary example, and may be reasonably set according to practical situations, so that the probability problem of the failure of the partition mirror AVB check can be solved, and the user experience is not affected due to excessive restarting times.

And according to the recovery record, if the AVB check failure times of the slot_a partition are smaller than the threshold value x1, determining the current recovery strategy as system restart in the slot_a partition.

And according to the recovery record, if the AVB check failure times of the slot_a partition are equal to the threshold value x1, the AVB check failure times of the slot_b partition are 0 (or the recovery record of the slot_b partition does not exist), and the attribute of the slot_b partition is in a bootable state (bootable), determining the current recovery strategy to be switched to the slot_b partition for system startup.

And according to the recovery record, if the AVB check failure times of the slot_a partition are determined to be equal to the threshold value x1 and the AVB check failure times of the slot_b partition are determined to be smaller than the threshold value x2, determining the current recovery strategy as system restart in the slot_b partition.

And according to the recovery record, if the AVB check failure times of the slot_a partition are equal to the threshold value x1 and the AVB check failure times of the slot_b partition are equal to the threshold value x2, determining the current recovery strategy to enter a Fastboot mode.

BootRecovery save recovery strategy.

After determining the current recovery policy, bootRecovery saves the recovery policy to the storage partition (bare partition).

BootRecovery returns a recovery policy to BootDetector.

BootDetector keeps a log.

After the BootDetector receives the recovery strategy fed back by the BootRecovery, a system recovery log (Bootloader log) is generated and written into the storage partition (bare partition), so that the corresponding recovery strategy can be positioned according to log information later and is convenient to read.

BootDetector update log meta information.

The BootDetector adaptively updates log meta information according to the situation where Bootloader log is written in a storage partition (bare partition). The log meta information is used to describe log information stored in a storage partition (bare partition).

Bootdetector instructs Bootloader to execute the recovery policy.

And the BootDetector executes a corresponding recovery strategy according to the recovery strategy instruction fed back by the BootRecovery.

Bootloader reboots.

And when the recovery strategy indicates that the system is restarted in the slot_a partition, or is switched to the slot_b partition to be started, or the system is restarted in the slot_b partition, the Bootloader executes corresponding restarting operation.

And when the recovery strategy indicates to enter the Fastboot mode, the Bootloader executes corresponding operation of entering the Fastboot mode.

Bootloader power on was successful.

If the failure of the partition mirror image AVB verification is a probabilistic problem when the previous system is started, the recovery strategy indicates to restart the system in the slot_a partition, or switches to the slot_b partition to start the system, or restarts the system in the slot_b partition, and the Bootloader executes the corresponding restarting operation, so that the terminal equipment can be started successfully, and the terminal equipment is prevented from entering the Fastboot mode.

BootCollector dump log and system recovery results.

And after the terminal equipment is successfully started, the android system is successfully started. The BootCollector is a module in an application program layer of the android system and is used for collecting log information and a system recovery result of the terminal equipment in the starting process.

And uploading the log and the system recovery result to the cloud end by the BootCollector.

When the BootCollector is started, corresponding log information and a system recovery result are read in the storage partition (bare partition) so as to upload the log information and the system recovery result to the cloud.

The BootCollector may read, in a storage partition (bare partition), log information and a system recovery result corresponding to the last startup in the current boot process, or may read all log information and a system recovery result in the current boot process. The embodiments of the present application are not limited in this regard.

The present process is not explained in detail with reference to the prior art, and is not described in detail herein.

As an alternative implementation manner, the BootCollector may record the correspondence, for example, in the form of a log, for each occurrence of an AVB check failure problem, an executed recovery policy, and whether the system is started successfully or not in the slot partition.

Therefore, after the terminal equipment executes the recovery strategy and is normally started, operation and maintenance personnel can analyze whether the current starting partition is restarted due to the mirror image AVB verification failure probability problem or not according to the corresponding log information, and whether the mirror image AVB verification is successful and the system is started successfully after the restarting.

Fig. 10 is a schematic diagram of the electronic device 100. Alternatively, the electronic device 100 may be a terminal, which may also be referred to as a terminal device, and the terminal may be a cellular phone (cellular phone) or a tablet computer (pad), which is not limited in this application. It should be understood that the electronic device 100 shown in fig. 10 is only one example of an electronic device, and that the electronic device 100 may have more or fewer components than shown in the figures, may combine two or more components, or may have different component configurations. The various components shown in fig. 10 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: processor 110, external memory interface 120, internal memory 121, universal serial bus (universal serial bus, USB) interface 130, charge management module 140, power management module 141, battery 142, antenna 1, antenna 2, mobile communication module 150, wireless communication module 160, audio module 170, speaker 170A, receiver 170B, microphone 170C, headset interface 170D, sensor module 180, keys 190, motor 191, indicator 192, camera 193, display 194, and subscriber identity module (subscriber identification module, SIM) card interface 195, etc. The sensor module 180 may include a pressure sensor, a gyroscope sensor, an acceleration sensor, a temperature sensor, a motion sensor, a barometric sensor, a magnetic sensor, a distance sensor, a proximity 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, such as: the processor 110 may include an application processor (application processor, AP), a modem processor, a graphics processor (graphics processing unit, GPU), an image signal processor (image signal processor, ISP), a controller, a memory, a video codec, a digital signal processor (digital signal processor, DSP), a baseband processor, and/or a neural network processor (neural-network processing unit, NPU), etc. Wherein the different processing units may be separate devices or may be integrated in one or more processors.

The controller may be a neural hub and a command center of the electronic device 100, among others. The controller can generate operation control signals according to the instruction operation codes and the time sequence signals to finish the control of instruction fetching and instruction execution.

A memory may also be provided in the processor 110 for storing instructions and data. In some embodiments, the memory in the processor 110 is a cache memory.

The USB interface 130 is an interface conforming to the USB standard specification, and may specifically be a Mini USB interface, a Micro USB interface, a USB Type C interface, or the like. The USB interface 130 may be used to connect a charger to charge the electronic device 100, and may also be used to transfer data between the electronic device 100 and a peripheral device. And can also be used for connecting with a headset, and playing audio through the headset. The interface may also be used to connect other electronic devices, such as AR devices, etc.

The charge management module 140 is configured to receive a charge input from a charger. The charger can be a wireless charger or a wired charger. In some wired charging embodiments, the charge management module 140 may receive a charging input of a wired charger through the USB interface 130. In some wireless charging embodiments, the charge management module 140 may receive wireless charging input through a wireless charging coil of the electronic device 100. The charging management module 140 may also supply power to the electronic device through the power management module 141 while charging the battery 142.

The power management module 141 is used for connecting the battery 142, and the charge management module 140 and the processor 110. The power management module 141 receives input from the battery 142 and/or the charge management module 140 and provides power to the processor 110, the internal memory 121, the external memory, the display 194, the camera 193, the wireless communication module 160, and the like.

The wireless communication function of the electronic device 100 may be implemented by the antenna 1, the antenna 2, the mobile communication module 150, the wireless communication module 160, a modem processor, a baseband processor, and the like.

The antennas 1 and 2 are used for transmitting and receiving electromagnetic wave signals. Each antenna in the electronic device 100 may be used to cover a single or multiple communication bands. Different antennas may also be multiplexed to improve the utilization of the antennas. For example: the antenna 1 may be multiplexed into a diversity antenna of a wireless local area network. In other embodiments, the antenna may be used in conjunction with a tuning switch.

The mobile communication module 150 may provide a solution for wireless communication including 2G/3G/4G/5G, etc., applied to the electronic device 100. The mobile communication module 150 may include at least one filter, switch, power amplifier, low noise amplifier (low noise amplifier, LNA), etc.

The wireless communication module 160 may provide solutions for wireless communication including wireless local area network (wireless local area networks, WLAN) (e.g., wireless fidelity (wireless fidelity, wi-Fi) network), bluetooth (BT), global navigation satellite system (global navigation satellite system, GNSS), frequency modulation (frequency modulation, FM), near field wireless communication technology (near field communication, NFC), infrared technology (IR), etc., as applied to the electronic device 100.

In some embodiments, antenna 1 and mobile communication module 150 of electronic device 100 are coupled, and antenna 2 and wireless communication module 160 are coupled, such that electronic device 100 may communicate with a network and other devices through wireless communication techniques.

The electronic device 100 implements display functions through a GPU, a display screen 194, an application processor, and the like. The GPU is a microprocessor for image processing, and is connected to the display 194 and the application processor. The GPU is used to perform mathematical and geometric calculations for graphics rendering. 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, and the like. The display 194 includes a display panel. In some embodiments, the electronic device 100 may include 1 or N display screens 194, N being a positive integer greater than 1.

The electronic device 100 may implement photographing functions through an ISP, a camera 193, a video codec, a GPU, a display screen 194, an application processor, and the like.

The ISP is used to process data fed back by the camera 193. For example, when photographing, the shutter is opened, light is transmitted to the camera photosensitive element through the lens, the optical signal is converted into an electric signal, and the camera photosensitive element transmits the electric signal to the ISP for processing and is converted into an image visible to naked eyes. ISP can also optimize the noise, brightness and skin color of the image. The ISP can also optimize parameters such as exposure, color temperature and the like of a shooting scene. In some embodiments, the ISP may be provided in the camera 193.

The camera 193 is used to capture still images or video. The object generates an optical image through the lens and projects the optical image onto the photosensitive element. The photosensitive element may be a charge coupled device (charge coupled device, CCD) or a Complementary Metal Oxide Semiconductor (CMOS) phototransistor. The photosensitive element converts the optical signal into an electrical signal, which is then transferred to the ISP to be converted 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 the like format. In some embodiments, electronic device 100 may include 1 or N cameras 193, N being a positive integer greater than 1.

The external memory interface 120 may be used to connect an external memory card, such as a Micro SD card, to enable expansion of the memory capabilities of the electronic device 100. The external memory card communicates with the processor 110 through an external memory interface 120 to implement data storage functions.

The internal memory 121 may be used to store computer executable program code including instructions. The processor 110 executes various functional applications of the electronic device 100 and data processing by executing instructions stored in the internal memory 121, for example, to cause the electronic device 100 to implement a system start-up method in an embodiment of the present application. The internal memory 121 may include a storage program area and a storage data area. The storage program area may store an application program (such as a sound playing function, an image playing function, etc.) required for at least one function of the operating system, etc. The storage data area may store data created during use of the electronic device 100 (e.g., audio data, phonebook, etc.), and so on. In addition, the internal memory 121 may include a high-speed random access memory, and may further include a nonvolatile memory such as at least one magnetic disk storage device, a flash memory device, a universal flash memory (universal flash storage, UFS), and the like.

The electronic device 100 may implement audio functions through an audio module 170, a speaker 170A, a receiver 170B, a microphone 170C, an earphone interface 170D, an application processor, and the like. Such as music playing, recording, etc.

The audio module 170 is used to convert digital audio information into an analog audio signal output and also to convert an analog audio input into a digital audio signal. The audio module 170 may also be used to encode and decode audio signals. In some embodiments, the audio module 170 may be disposed in the processor 110, or a portion of the functional modules of the audio module 170 may be disposed in the processor 110.

The speaker 170A, also referred to as a "horn," is used to convert audio electrical signals into sound signals. The electronic device 100 may listen to music, or to hands-free conversations, through the speaker 170A. In some embodiments, the electronic device 100 may be provided with a plurality of speakers 170A.

A receiver 170B, also referred to as a "earpiece", is used to convert the audio electrical signal into a sound signal. When electronic device 100 is answering a telephone call or voice message, voice may be received by placing receiver 170B in close proximity to the human ear.

Microphone 170C, also referred to as a "microphone" or "microphone", is used to convert sound signals into electrical signals. When making a call or transmitting voice information, the user can sound near the microphone 170C through the mouth, inputting a sound signal to the microphone 170C. The electronic device 100 may be provided with at least one microphone 170C. In other embodiments, the electronic device 100 may be provided with two microphones 170C, and may implement a noise reduction function in addition to collecting sound signals. In other embodiments, the electronic device 100 may also be provided with three, four, or more microphones 170C to enable collection of sound signals, noise reduction, identification of sound sources, directional recording functions, etc.

The earphone interface 170D is used to connect a wired earphone. The headset interface 170D may be a USB interface 130 or a 3.5mm open mobile electronic device platform (open mobile terminal platform, OMTP) standard interface, a american cellular telecommunications industry association (cellular telecommunications industry association of the USA, CTIA) standard interface.

The pressure sensor is used for sensing a pressure signal and can convert the pressure signal into an electric signal. In some embodiments, the pressure sensor may be provided on the display screen 194. The electronic device 100 may also calculate the location of the touch based on the detection signal of the pressure sensor.

The gyroscopic sensor may be used to determine a motion pose of the electronic device 100. In some embodiments, the angular velocity of electronic device 100 about three axes (i.e., x, y, and z axes) may be determined by a gyroscopic sensor.

The acceleration sensor may detect the magnitude of acceleration of the electronic device 100 in various directions (typically three axes). The acceleration sensor may detect the magnitude and direction of gravity when the electronic device 100 is stationary. The acceleration sensor can also be used for recognizing the gesture of the electronic equipment, and is applied to the applications such as horizontal and vertical screen switching, pedometers and the like.

Touch sensors, also known as "touch panels". The touch sensor may be disposed on the display screen 194, and the touch sensor and the display screen 194 form a touch screen, which is also referred to as a "touch screen". The touch sensor is used to detect a touch operation acting on or near it. The touch sensor may communicate the detected touch operation to the application processor to determine the touch event type.

The keys 190 include a power-on key (or power key), a volume key, etc. The keys 190 may be mechanical keys. Or may be a touch key. The electronic device 100 may receive key inputs, generating key signal inputs related to user settings and function controls of the electronic device 100.

The motor 191 may generate a vibration cue. The motor 191 may be used for incoming call vibration alerting as well as for touch vibration feedback. For example, touch operations acting on different applications (e.g., photographing, audio playing, etc.) may correspond to different vibration feedback effects.

The indicator 192 may be an indicator light, may be used to indicate a state of charge, a change in charge, a message indicating a missed call, a notification, etc.

The software system of the electronic device 100 may employ a layered architecture, an event driven architecture, a microkernel architecture, a microservice architecture, or a cloud architecture. In this embodiment, taking an Android system with a layered architecture as an example, a software structure of the electronic device 100 is illustrated.

Fig. 11 is a software configuration block diagram of the electronic device 100 of the embodiment of the present application.

The layered architecture of the electronic device 100 divides the software into several layers, each with a distinct role and division of labor. The layers communicate with each other through a software interface. In some embodiments, the Android system is divided into four layers, from top to bottom, an application layer, an application framework layer, an Zhuoyun row (Android run) and system libraries, and a kernel layer, respectively.

The application layer may include a series of application packages.

As shown in fig. 11, the application package may include applications for cameras, calendars, maps, WLANs, music, short messages, gallery, calls, videos, etc.

The application package may also include a BootCollector module. The BootCollector module can be used for collecting log information and a system recovery result of the terminal equipment in a starting process.

The application framework layer provides an application programming interface (application programming interface, API) and programming framework for application programs of the application layer. The application framework layer includes a number of predefined functions.

As shown in fig. 11, the application framework layer may include a window manager, a content provider, a view system, a phone manager, a resource manager, a notification manager, and the like.

The window manager is used for managing window programs. The window manager can acquire the size of the display screen, judge whether a status bar exists, lock the screen, intercept the screen and the like.

The content provider is used to store and retrieve data and make such data accessible to applications. The data may include video, images, audio, calls made and received, browsing history and bookmarks, phonebooks, etc.

The view system includes visual controls, such as controls to display text, controls to display pictures, and the like. The view system may be used to build applications. The display interface may be composed of one or more views. For example, a display interface including a text message notification icon may include a view displaying text and a view displaying a picture.

The telephony manager is used to provide the communication functions of the electronic device 100. Such as the management of call status (including on, hung-up, etc.).

The resource manager provides various resources for the application program, such as localization strings, icons, pictures, layout files, video files, and the like.

The notification manager allows the application to display notification information in a status bar, can be used to communicate notification type messages, can automatically disappear after a short dwell, and does not require user interaction. Such as notification information is used to inform that the download is complete, a message alert, etc. The notification information may also be a notification in the form of a chart or scroll bar text appearing in the system top status bar, such as a notification of a background running application, or a notification appearing on a screen in the form of a dialog window. The notification information may be, for example, a text message presented in a status bar, a presentation sound emitted, vibration of an electronic device, flashing of an indicator light, or the like.

Android run time includes a core library and virtual machines. Android run is responsible for scheduling and management of the Android system.

The core library consists of two parts: one part is a function which needs to be called by java language, and the other part is a core library of android.

The application layer and the application framework layer run in a virtual machine. The virtual machine executes java files of the application program layer and the application program framework layer as binary files. The virtual machine is used for executing the functions of object life cycle management, stack management, thread management, security and exception management, garbage collection and the like.

The system library may include a plurality of functional modules. For example: surface manager (surface manager), media Libraries (Media Libraries), three-dimensional graphics processing Libraries (e.g., openGL ES), 2D graphics engines (e.g., SGL), etc.

The surface manager is used to manage the display subsystem and provides a fusion of 2D and 3D layers for multiple applications.

Media libraries support a variety of commonly used audio, video format playback and recording, still image files, and the like. The media library may support a variety of audio video encoding formats, such as: MPEG4, h.264, MP3, AAC, AMR, JPG, PNG, etc.

The three-dimensional graphic processing library is used for realizing three-dimensional graphic drawing, image rendering, synthesis, layer processing and the like.

The 2D graphics engine is a drawing engine for 2D drawing.

The kernel layer is a layer between hardware and software. The kernel layer contains at least display driver, audio driver, wi-Fi driver, bluetooth driver, sensor driver, etc. The hardware at least comprises a processor, a display screen, a Wi-Fi module, a sensor and the like.

It will be appreciated that the layers and components contained in the layers in the software structure shown in fig. 11 do not constitute a specific limitation on the electronic device 100. In other embodiments of the present application, electronic device 100 may include more or fewer layers than shown, and more or fewer components may be included in each layer, as the present application is not limited.

It may be understood that, in order to implement the system start method in the embodiments of the present application, the electronic device includes corresponding hardware and/or software modules that perform each function. The steps of an algorithm for each example described in connection with the embodiments disclosed herein may be embodied in hardware or a combination of hardware and computer software. Whether a function is implemented as hardware or computer software driven hardware depends upon the particular application and design constraints imposed on the solution. Those skilled in the art may implement the described functionality using different approaches for each particular application in conjunction with the embodiments, but such implementation is not to be considered as outside the scope of this application.

The present embodiment also provides a computer storage medium having stored therein computer instructions which, when executed on an electronic device, cause the electronic device to perform the above-described related method steps to implement the system start-up method in the above-described embodiments.

The present embodiment also provides a computer program product which, when run on a computer, causes the computer to perform the above-mentioned related steps to implement the system start-up method in the above-mentioned embodiments.

In addition, embodiments of the present application also provide an apparatus, which may be specifically a chip, a component, or a module, and may include a processor and a memory connected to each other; the memory is used for storing computer-executable instructions, and when the device is running, the processor can execute the computer-executable instructions stored in the memory, so that the chip executes the system starting method in the above method embodiments.

The electronic device (such as a mobile phone) provided in this embodiment, the computer storage medium, the computer program product or the chip are used to execute the corresponding method provided above, so that the beneficial effects thereof can be referred to the beneficial effects in the corresponding method provided above, and will not be described herein.

It will be appreciated by those skilled in the art that, for convenience and brevity of description, only the above-described division of the functional modules is illustrated, and in practical application, the above-described functional allocation may be performed by different functional modules according to needs, i.e. the internal structure of the apparatus is divided into different functional modules to perform all or part of the functions described above.

In the several embodiments provided in this application, it should be understood that the disclosed apparatus and method may be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative, e.g., the division of modules or units is merely a logical function division, and there may be additional divisions when actually implemented, e.g., multiple units or components may be combined or integrated into another apparatus, or some features may be omitted or not performed. Alternatively, the coupling or direct coupling or communication connection shown or discussed with each other may be an indirect coupling or communication connection via some interfaces, devices or units, which may be in electrical, mechanical or other form.

The above embodiments are merely for illustrating the technical solution of the present application, and not for limiting the same; although the present application has been described in detail with reference to the foregoing embodiments, it should be understood by those of ordinary skill in the art that: the technical scheme described in the foregoing embodiments can be modified or some technical features thereof can be replaced by equivalents; such modifications and substitutions do not depart from the spirit of the corresponding technical solutions from the scope of the technical solutions of the embodiments of the present application.

Claims

1. The system starting method is characterized by being applied to electronic equipment, wherein the electronic equipment comprises a first system starting partition and a second system starting partition, and comprises the following steps:

and the electronic equipment is successfully restarted in the first system starting partition.

2. The method as recited in claim 1, further comprising:

in the process that the electronic equipment restarts the system in the first system starting partition, if the mirror image verification of the first system starting partition fails, the electronic equipment is switched to a second system starting partition to start the system;

3. The method of claim 2, wherein the electronic device switching into the second system boot partition for system boot comprises:

and if the attribute of the second system starting partition is in a starting state, the electronic equipment is switched to the second system starting partition to start the system.

4. A method according to claim 3, further comprising:

and if the attribute of the second system starting partition is in a non-starting state, the electronic equipment performs a quick starting mode.

5. The method as recited in claim 2, further comprising:

and in the process that the electronic equipment restarts the system in the second system starting partition, if the mirror image verification of the second system starting partition fails, the electronic equipment performs a quick starting mode.

6. The method of claim 2, wherein if the image verification of the first system boot partition fails, the electronic device performs a system restart in the first system boot partition, comprising:

If the mirror verification of the first system starting partition fails, the electronic equipment is switched to a second system starting partition to start the system, and the method comprises the following steps:

if the image verification of the first system starting partition fails, and the image verification failure times of the first system starting partition is equal to the first threshold value, the electronic equipment is switched to the second system starting partition to start the system;

wherein the first threshold is greater than 2.

7. The method of claim 2, wherein if the image verification of the second system boot partition fails, the electronic device performs a system restart in the second system boot partition, comprising:

if the image verification of the second system starting partition fails, and the image verification failure times of the second system starting partition is smaller than a second threshold value, the electronic equipment restarts the system in the second system starting partition;

wherein the second threshold is greater than 1.

8. The method of any of claims 1-7, wherein if the image verification of the first system boot partition fails, the electronic device performs a system restart in the first system boot partition, comprising:

9. The method of claim 1, wherein upon a system restart of the electronic device in the first system boot partition, further comprising: recording log information corresponding to the image verification failure of the first system starting partition and a recovery strategy, wherein the recovery strategy is that the electronic equipment restarts the system in the first system starting partition.

10. The method of claim 2, wherein upon a system restart of the electronic device in the second system boot partition, further comprising: recording log information corresponding to the image verification failure of the second system starting partition and a recovery strategy, wherein the recovery strategy is that the electronic equipment restarts the system in the second system starting partition.

11. The method of claim 2, wherein upon a system boot at the time of the electronic device switching into a second system boot partition, further comprising: recording log information corresponding to the mirror image verification failure of the first system starting partition and a recovery strategy, wherein the recovery strategy is that the electronic equipment is switched into a second system starting partition to start the system.

12. The method of any of claims 9-11, further comprising, after the electronic device system has been successfully booted:

and uploading the log information and the recovery strategy to the cloud.

13. An electronic device, comprising:

one or more processors;

a memory;

and one or more computer programs, wherein the one or more computer programs are stored on the memory, which when executed by the one or more processors, cause the electronic device to perform the system boot method of any of claims 1-12.

14. A computer readable storage medium comprising a computer program, characterized in that the computer program, when run on an electronic device, causes the electronic device to perform the system start-up method according to any of claims 1-12.