Abnormal restart mode determination method, device, electronic device and storage medium

Abstract

The embodiments of the present application provide a method, device, electronic device and storage medium for determining an abnormal restart mode, which belongs to the field of computer technology. The method includes: when an abnormality occurs in the UEFI stage of the boot process, obtaining a first policy value of a first abnormal log capture policy and a second policy value of a second abnormal log capture policy; when the first policy value is different from the second policy value, obtaining the parameter value of the operating parameter of the electronic device; based on the parameter value of the operating parameter, determining the type of the electronic device; when the type of the electronic device is the first type, determining that the abnormal restart mode of the electronic device is a direct restart, and the first type is used to indicate that the electronic device skips operations unrelated to the restart operation when the restart is abnormal. In the case of an abnormality in the UEFI stage of the boot process, the embodiment of the present application directly restarts the first type of electronic device, shortening the abnormal recovery time.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to a method, device, electronic device and storage medium for determining an abnormal restart mode. Background Art

[0002] During the boot process, the operating system of the electronic device will enter the UEFI (Unified Extensible Firmware Interface) stage. When an abnormality occurs in the UEFI stage, the electronic device needs to determine the abnormal restart method, and then restart according to the determined abnormal restart method to recover from the abnormality.

[0003] In the related art, the electronic device obtains the policy value of the apdp policy and the policy value of the dload_mode policy, and then makes a decision based on the policy value of the apdp policy and the policy value of the dload_mode policy, and then determines the abnormal restart method based on the decision value, and then restarts according to the determined abnormal restart method. Among them, the apdp policy and the dload_mode policy are two strategies for determining the amount of abnormal log capture. For commercial electronic devices, the policy value of the apdp policy is generally mini, and the policy value of the dload_mode policy is generally full, so the decision value obtained may be full or mini. When the decision value is full, it is necessary to capture the abnormal log in full. At this time, the abnormal restart method determined is: display the abnormal log interface (i.e., the dump interface) to capture the abnormal log and then restart; when the decision value is mini, it is necessary to capture a small amount of abnormal logs. At this time, the restart method determined is: restart directly.

[0004] However, for commercial electronic devices, users do not have the need to capture abnormal logs, and displaying the abnormal log interface will prolong the recovery time of the electronic device, resulting in poor user experience. Therefore, it is urgent to provide a new method for determining an abnormal restart mode, so that the electronic device's operating system can be directly restarted when an abnormality occurs during the UEFI stage. Summary of the invention

[0005] Multiple aspects of the present application provide a method, device, electronic device and storage medium for determining an abnormal restart mode, which can avoid entering the dump interface and directly restart when an abnormality occurs in the UEFI stage of the boot process, thereby shortening the abnormal recovery time and improving the user experience.

[0006] In a first aspect, an embodiment of the present application provides a method for determining an abnormal restart mode, the method comprising: when an abnormality occurs in the Unified Extensible Firmware Interface (UEFI) stage of the boot process of an electronic device, obtaining a first policy value of a first abnormal log capture strategy and a second policy value of a second abnormal log capture strategy, and then comparing the first policy value with the second policy value; when the first policy value is different from the second policy value, obtaining a parameter value of an operating parameter of the electronic device, and then determining the type of the electronic device based on the parameter value of the operating parameter of the electronic device; when the type of the electronic device is the first type, determining that the abnormal restart mode of the electronic device is a direct restart.

[0007] The first abnormal log capture strategy may be an apdp strategy, the second abnormal log capture strategy may be a dload_mode strategy, etc. The operation parameter is used to indicate the operation state of the electronic device when an abnormality occurs. The first type may be a commercial type, which is used to indicate that the electronic device skips operations unrelated to the restart operation when an abnormal restart occurs.

[0008] By adopting the method provided in the embodiment of the present application, when an electronic device has an abnormality in the UEFI stage of the boot process, and the first policy value of the first abnormal log capture policy and the second policy value of the second abnormal log capture policy are different, the type of the electronic device is determined according to the parameter value of the operating parameter of the electronic device. If the type of the electronic device is the first type, the abnormal restart mode is no longer determined relying on the decision values ​​of the first policy value and the second policy value, but the abnormal restart mode of the electronic device is determined to be a direct restart, thereby ensuring that the operating system of the electronic device can be directly restarted when an abnormality occurs when entering the UEFI stage, avoiding the display of the dump interface, shortening the abnormal recovery time, and improving the user experience.

[0009] In another possible implementation manner of the first aspect, the operating parameter includes a fuse blown parameter and a log version identification parameter, and accordingly, the electronic device determines the type of the electronic device based on a parameter value of the operating parameter, including the following situations:

[0010] In the first case, when the parameter value of the fuse blown parameter indicates that the fuse has been blown, and the parameter value of the log version identification parameter indicates that the operating system of the electronic device is a logless version, the type of the electronic device is determined to be the first type;

[0011] In the second case, when the parameter value of the fuse blown parameter indicates that the fuse has been blown, and the parameter value of the log version identification parameter indicates that the operating system is a log version, it is determined that the type of the electronic device is the second type;

[0012] In the third case, when the parameter value of the fuse blown parameter indicates that the fuse is not blown, and the parameter value of the log version identification parameter indicates that the operating system is a logless version, the type of the electronic device is determined to be the second type;

[0013] In a fourth case, when the parameter value of the fuse blown parameter indicates that the fuse is not blown, and the parameter value of the log version identification parameter indicates that the operating system is a log version, it is determined that the type of the electronic device is the second type.

[0014] The second type is used to instruct the electronic device to perform all operations related to and unrelated to the restart operation when the electronic device is abnormally restarted.

[0015] The operating parameters of the embodiment of the present application include different types of parameters, each parameter has a different parameter value, and based on the parameter values ​​of the different types of parameters included in the operating parameters, a method for determining the type of an electronic device is provided.

[0016] In another possible implementation of the first aspect, the electronic device introduces a third-party policy based on the first abnormal log capture strategy and the second abnormal log capture strategy. The policy values ​​of the third-party policies in different types of electronic devices are different. Generally speaking, the policy value of the third-party policy corresponding to the first type is a first value, and the first value is used to indicate that the electronic device does not capture or captures part of the abnormal log when an abnormality occurs during the startup process. In response to the policy value of the third-party policy being the first value, it can be determined that the abnormal restart method of the electronic device is a direct restart, so that the abnormal log interface is no longer displayed, but the electronic device is directly restarted, thereby shortening the abnormal recovery time.

[0017] In another possible implementation of the first aspect, when the type of the electronic device is the second type, the electronic device makes a decision based on the first policy value and the second policy value to obtain a decision value, and then determines an abnormal restart method of the electronic device based on the decision value.

[0018] The second type is used to instruct the electronic device to perform all operations related to and unrelated to the restart operation when the electronic device is abnormally restarted. When the electronic device needs to perform all operations of abnormal restart, a decision is made based on the first strategy value and the second strategy value, thereby providing a method for determining an abnormal restart mode.

[0019] In another possible implementation of the first aspect, the electronic device determines the abnormal restart mode of the electronic device based on the decision value, including the following two situations:

[0020] In the first case, when the decision value is a first value, the first value is used to indicate that the electronic device does not capture or captures part of the abnormal log when an abnormality occurs during the boot process, and it can be determined that the abnormal startup mode of the electronic device is direct restart;

[0021] In the second case, when the decision value is the second value, the second value is used to instruct the electronic device to capture a full amount of abnormal logs when an abnormality occurs during the startup process. It can be determined that the abnormal startup mode of the electronic device is to display the abnormal log capture interface and then restart.

[0022] When the method provided in the embodiment of the present application makes a decision based on the first exception log capture strategy and the second exception log capture strategy, different exception restart methods are determined according to different decision values. In a scenario where a full amount of exception logs need to be captured, the user's demand for capturing exception logs is met by displaying an exception log capture interface. In a scenario where no capture is required or a small amount of exception logs need to be captured, the abnormal recovery time is shortened by directly restarting the computer, thereby meeting the user's electronic device usage requirements.

[0023] In another possible implementation manner of the first aspect, the first value is mini, and the second value is full.

[0024] In a second aspect, a device for determining an abnormal restart mode is provided, the device comprising at least one module, and the at least one module is used to implement the method for determining an abnormal restart mode provided by the first aspect and possible implementations thereof.

[0025] In a third aspect, an electronic device is provided, comprising a processor and a memory; the memory stores at least one program code; the at least one program code is used to be called and executed by the processor to implement the method for determining the abnormal restart mode as described in the first aspect.

[0026] In a fourth aspect, a computer-readable storage medium is provided, wherein at least one computer program is stored in the computer-readable storage medium, and when the at least one computer program is executed by a processor, the method for determining the abnormal restart mode as described in the first aspect can be implemented.

[0027] In a fifth aspect, a computer program product is provided, the computer program product comprising a computer program, and when the computer program is executed by a processor, the method for determining the abnormal restart mode as described in the first aspect can be implemented. BRIEF DESCRIPTION OF THE DRAWINGS

[0028] The drawings described herein are used to provide a further understanding of the present application and constitute a part of the present application. The illustrative embodiments of the present application and their descriptions are used to explain the present application and do not constitute an improper limitation on the present application. In the drawings:

[0029] Figure 1 A schematic diagram of the structure of an electronic device provided as an exemplary embodiment of the present application;

[0030] Figure 2 is a software structure block diagram of the electronic device of the embodiment of the present application;

[0031] Figure 3 A flowchart of a method for determining an abnormal restart mode provided by another exemplary embodiment of the present application;

[0032] Figure 4 is a schematic diagram of a decision result of a third-party strategy provided by another exemplary embodiment of the present application;

[0033] Figure 5 is a flow chart of a method for determining an abnormal restart mode provided by another exemplary embodiment of the present application;

[0034] Figure 6 is a flow chart of a method for determining an abnormal restart mode provided by another exemplary embodiment of the present application;

[0035] Figure 7 It is a structural diagram of a device for determining an abnormal restart mode provided by another exemplary embodiment of the present application. DETAILED DESCRIPTION

[0036] In order to make the purpose, technical solution and advantages of the present application clearer, the technical solution of the present application will be clearly and completely described below in combination with the specific embodiments of the present application and the corresponding drawings. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without making creative work are within the scope of protection of the present application.

[0037] It can be understood that the terms "each", "multiple" and "any" used in the embodiments of the present application, multiple includes two or more, each refers to each of the corresponding multiple, and any refers to any one of the corresponding multiple. For example, multiple words include 10 words, and each word refers to each of the 10 words, and any word refers to any one of the 10 words. In addition, the descriptions of "first", "second", etc. in the embodiments of the present application are used to distinguish different messages, devices, modules, etc., do not represent the order of precedence, and do not limit the "first" and "second" to different types.

[0038] It should be noted that the terms "include", "comprises" or any other variations thereof are intended to cover non-exclusive inclusion, so that a process, method, commodity or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, commodity or device. In the absence of further restrictions, the elements defined by the sentence "comprises a ..." do not exclude the existence of other identical elements in the process, method, commodity or device including the elements.

[0039] It should also be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of relevant data must comply with the relevant laws, regulations and standards of the relevant countries and regions, and provide corresponding operation entrances for users to choose to authorize or refuse.

[0040] Before executing the embodiments of the present application, the terms involved in the embodiments of the present application are first explained.

[0041] The fuse blowing mechanism is a secure boot solution (secureboot) provided according to different application requirements, which is used to protect the secondary data used for booting and some communications.

[0042] The inint.rc file is a configuration file, a script written in the Android system initialization language. It is a script file executed when the Android system starts up and is responsible for the initial settings of the system, such as mounting the file system, creating directories, setting properties, starting services, etc.

[0043] UEFI defines the interface between the operating system and the platform firmware. The UEFI system can be divided into the XBL stage and the ABL stage from power-on to shutdown. Among them, the XBL stage is used to initialize some hardware to prepare the execution environment for the ABL stage when the system resource environment is small. The ABL stage is used for further initialization of system hardware, implementation of customized functions and booting of the operating system.

[0044] Figure 1 1 shows a schematic diagram of the structure of the electronic device 100. The electronic device 100 may be a mobile phone, a personal computer (PC), a tablet computer, an AR device, a VR device, a car computer, a wearable device, a smart home device, etc.

[0045] 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. The sensor module 180 may include a pressure sensor 180A, a gyroscope sensor 180B, an air pressure sensor 180C, a magnetic sensor 180D, an acceleration sensor 180E, a distance sensor 180F, a proximity light sensor 180G, a fingerprint sensor 180H, a temperature sensor 180J, a touch sensor 180K, an ambient light sensor 180L, a bone conduction sensor 180M, etc.

[0046] It is to be understood that the structure illustrated in the embodiment of the present application does not constitute a specific limitation on the electronic device 100. In other embodiments of the present application, the electronic device 100 may include more or fewer components than shown in the figure, or combine some components, or split some components, or arrange the components differently. The components shown in the figure may be implemented in hardware, software, or a combination of software and hardware.

[0047] 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 video codec, a digital signal processor (DSP), a baseband processor, and / or a neural-network processing unit (NPU), etc. Different processing units may be independent devices or integrated into one or more processors.

[0048] The controller can generate operation control signals according to the instruction operation code and timing signal to complete the control of instruction fetching and execution.

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

[0050] In some embodiments, the processor 110 may include one or more interfaces. The interface may include an inter-integrated circuit (I2C) interface, an inter-integrated circuit sound (I2S) interface, a pulse code modulation (PCM) interface, a universal asynchronous receiver / transmitter (UART) interface, a mobile industry processor interface (MIPI), a general-purpose input / output (GPIO) interface, a subscriber identity module (SIM) interface, and / or a universal serial bus (USB) interface, etc.

[0051] The I2C interface is a bidirectional synchronous serial bus, including a serial data line (SDA) and a serial clock line (SCL). In some embodiments, the processor 110 may include multiple groups of I2C buses. The processor 110 may be coupled to the touch sensor 180K, the charger, the flash, the camera 193, etc. through different I2C bus interfaces. For example: the processor 110 may be coupled to the touch sensor 180K through the I2C interface, so that the processor 110 communicates with the touch sensor 180K through the I2C bus interface, thereby realizing the touch function of the electronic device 100.

[0052] The I2S interface can be used for audio communication. In some embodiments, the processor 110 can include multiple I2S buses. The processor 110 can be coupled to the audio module 170 via the I2S bus to achieve communication between the processor 110 and the audio module 170. In some embodiments, the audio module 170 can transmit an audio signal to the wireless communication module 160 via the I2S interface to achieve the function of answering a call through a Bluetooth headset.

[0053] The PCM interface can also be used for audio communication, sampling, quantizing and encoding analog signals. In some embodiments, the audio module 170 and the wireless communication module 160 can be coupled via a PCM bus interface. In some embodiments, the audio module 170 can also transmit audio signals to the wireless communication module 160 via the PCM interface to realize the function of answering calls via a Bluetooth headset. Both the I2S interface and the PCM interface can be used for audio communication.

[0054] The UART interface is a universal serial data bus for asynchronous communication. The bus can be a bidirectional communication bus. It converts the data to be transmitted between serial communication and parallel communication. In some embodiments, the UART interface is generally used to connect the processor 110 and the wireless communication module 160. For example, the processor 110 communicates with the Bluetooth module in the wireless communication module 160 through the UART interface to implement the Bluetooth function. In some embodiments, the audio module 170 can transmit an audio signal to the wireless communication module 160 through the UART interface to implement the function of playing music through a Bluetooth headset.

[0055] The MIPI interface can be used to connect the processor 110 with peripheral devices such as the display screen 194 and the camera 193. The MIPI interface includes a camera serial interface (CSI), a display serial interface (DSI), etc. In some embodiments, the processor 110 and the camera 193 communicate via the CSI interface to implement the shooting function of the electronic device 100. The processor 110 and the display screen 194 communicate via the DSI interface to implement the display function of the electronic device 100.

[0056] The GPIO interface can be configured by software. The GPIO interface can be configured as a control signal or as a data signal. In some embodiments, the GPIO interface can be used to connect the processor 110 with the camera 193, the display 194, the wireless communication module 160, the audio module 170, the sensor module 180, etc. The GPIO interface can also be configured as an I2C interface, an I2S interface, a UART interface, a MIPI interface, etc.

[0057] 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 transfer 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.

[0058] It is understandable that the interface connection relationship between the modules illustrated in the embodiment of the present application is only a schematic illustration and does not constitute a structural limitation on the electronic device 100. In other embodiments of the present application, the electronic device 100 may also adopt different interface connection methods in the above embodiments, or a combination of multiple interface connection methods.

[0059] 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. In some wired charging embodiments, the charging management module 140 may receive charging input from a wired charger through the USB interface 130. In some wireless charging embodiments, the charging management module 140 may receive wireless charging input through a wireless charging coil of the electronic device 100. While the charging management module 140 is charging the battery 142, it may also power the electronic device through the power management module 141.

[0060] 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, and supplies power to the processor 110, the internal memory 121, the display screen 194, the camera 193, and the wireless communication module 160. The power management module 141 can also be used to monitor parameters such as battery capacity, battery cycle number, battery health status (leakage, impedance), etc. In some other embodiments, the power management module 141 can also be set in the processor 110. In other embodiments, the power management module 141 and the charging management module 140 can also be set in the same device.

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

[0062] 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. For example, antenna 1 can be reused as a diversity antenna for a wireless local area network. In some other embodiments, the antenna can be used in combination with a tuning switch.

[0063] 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. The mobile communication module 150 can receive electromagnetic waves from the antenna 1, and filter, amplify, and process the received electromagnetic waves, and transmit them to the modulation and demodulation processor for demodulation. The mobile communication module 150 can also amplify the signal modulated by the modulation and demodulation processor, and convert it into electromagnetic waves for radiation through the antenna 1. In some embodiments, at least some of the functional modules of the mobile communication module 150 can be set in the processor 110. In some embodiments, at least some of the functional modules of the mobile communication module 150 can be set in the same device as at least some of the modules of the processor 110.

[0064] The modem processor may include a modulator and a demodulator. Among them, the modulator is used to modulate the low-frequency baseband signal to be sent into a medium-high frequency signal. The demodulator is used to demodulate the received electromagnetic wave signal into a low-frequency baseband signal. The demodulator then transmits the demodulated low-frequency baseband signal to the baseband processor for processing. After the low-frequency baseband signal is processed by the baseband processor, it is passed to the application processor. The application processor outputs a sound signal through an audio device (not limited to a speaker 170A, a receiver 170B, etc.), or displays an image or video through a display screen 194. In some embodiments, the modem processor may be an independent device. In other embodiments, the modem processor may be independent of the processor 110 and be set in the same device as the mobile communication module 150 or other functional modules.

[0065] The wireless communication module 160 can provide wireless communication solutions including wireless local area networks (WLAN) (such as wireless fidelity (Wi-Fi) networks), bluetooth (BT), global navigation satellite system (GNSS), frequency modulation (FM), near field communication (NFC), infrared (IR), etc., which are applied to the electronic device 100. The wireless communication module 160 can be one or more devices integrating at least one communication processing module. The wireless communication module 160 receives electromagnetic waves via the antenna 2, modulates the frequency of the electromagnetic wave signal and performs filtering, and sends the processed signal to the processor 110. The wireless communication module 160 can also receive the signal to be sent from the processor 110, modulate the frequency of it, amplify it, and convert it into electromagnetic waves for radiation through the antenna 2.

[0066] In some embodiments, the antenna 1 of the electronic device 100 is coupled to the mobile communication module 150, and the antenna 2 is coupled to the wireless communication module 160, so that the electronic device 100 can communicate with the network and other devices through wireless communication technology. The wireless communication technology may include global system for mobile communications (GSM), general packet radio service (GPRS), code division multiple access (CDMA), wideband code division multiple access (WCDMA), time-division code division multiple access (TD-SCDMA), long term evolution (LTE), BT, GNSS, WLAN, NFC, FM, and / or IR technology. The GNSS may include a global positioning system (GPS), a global navigation satellite system (GLONASS), a Beidou navigation satellite system (BDS), a quasi-zenith satellite system (QZSS) and / or a satellite based augmentation system (SBAS).

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

[0068] The display screen 194 is used to display images, videos, etc. The display screen 194 includes a display panel. The display panel can be a liquid crystal display (LCD), an organic light-emitting diode (OLED), an active-matrix organic light-emitting diode or an active-matrix organic light-emitting diode (AMOLED), a flexible light-emitting diode (FLED), Miniled, MicroLed, Micro-oLed, a quantum dot light-emitting diode (QLED), etc. In some embodiments, the electronic device 100 may include 1 or N display screens 194, where N is a positive integer greater than 1.

[0069] The electronic device 100 can realize the shooting function through ISP, camera 193, video codec, GPU, display screen 194 and application processor.

[0070] ISP is used to process the data fed back by 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 ISP for processing and converts it into an image visible to the naked eye. ISP can also perform algorithm optimization on the noise, brightness, and skin color of the image. ISP can also optimize the exposure, color temperature and other parameters of the shooting scene. In some embodiments, ISP can be set in camera 193.

[0071] The 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. The photosensitive element converts the optical signal into an electrical signal, and then passes the electrical signal 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 other format. In some embodiments, the electronic device 100 may include 1 or N cameras 193, where N is a positive integer greater than 1.

[0072] The digital signal processor is used to process digital signals, and can process not only digital image signals but also other digital signals. For example, when the electronic device 100 is selecting a frequency point, the digital signal processor is used to perform Fourier transform on the frequency point energy.

[0073] Video codecs are used to compress or decompress digital videos. The electronic device 100 may support one or more video codecs. Thus, the electronic device 100 may play or record videos in a variety of coding formats, such as Moving Picture Experts Group (MPEG) 1, MPEG2, MPEG3, MPEG4, etc.

[0074] NPU is a neural network (NN) computing processor. By drawing on the structure of biological neural networks, such as the transmission mode between neurons in the human brain, it can quickly process input information and can also continuously self-learn. Through NPU, applications such as intelligent cognition of electronic device 100 can be realized, such as image recognition, face recognition, voice recognition, text understanding, etc.

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

[0076] The internal memory 121 can be used to store computer executable program codes, which include instructions. The internal memory 121 may include a program storage area and a data storage area. Among them, the program storage area may store an operating system, an application required for at least one function (such as a sound playback function, an image playback function, etc.), etc. 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. In addition, the internal memory 121 may include a high-speed random access memory, and may also include a non-volatile memory, such as at least one disk storage device, a flash memory device, a universal flash storage (UFS), etc. The processor 110 executes various functional applications and data processing of the electronic device 100 by running instructions stored in the internal memory 121, and / or instructions stored in a memory provided in the processor.

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

[0078] 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. In some embodiments, 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.

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

[0080] The receiver 170B, also called a "earpiece", is used to convert audio electrical signals into sound signals. When the electronic device 100 receives a call or voice message, the voice can be received by placing the receiver 170B close to the human ear.

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

[0082] The earphone interface 170D is used to connect a wired earphone and can be a USB interface 130 or a 3.5 mm open mobile terminal platform (OMTP) standard interface or a cellular telecommunications industry association of the USA (CTIA) standard interface.

[0083] The pressure sensor 180A is used to sense the pressure signal and can convert the pressure signal into an electrical signal. In some embodiments, the pressure sensor 180A can be set on the display screen 194. There are many types of pressure sensors 180A, such as resistive pressure sensors, inductive pressure sensors, capacitive pressure sensors, etc. The capacitive pressure sensor can be a parallel plate including at least two conductive materials. When a force acts on the pressure sensor 180A, the capacitance between the electrodes changes. The electronic device 100 determines the intensity of the pressure according to the change in capacitance. When a touch operation acts on the display screen 194, the electronic device 100 detects the touch operation intensity according to the pressure sensor 180A. The electronic device 100 can also calculate the touch position according to the detection signal of the pressure sensor 180A. In some embodiments, touch operations acting on the same touch position but with different touch operation intensities can correspond to different operation instructions. For example: when a touch operation with a touch operation intensity less than the first pressure threshold acts on the short message application icon, an instruction to view the short message is executed. When a touch operation with a touch operation intensity greater than or equal to the first pressure threshold acts on the short message application icon, an instruction to create a new short message is executed.

[0084] The gyro sensor 180B can be used to determine the motion posture of the electronic device 100. In some embodiments, the angular velocity of the electronic device 100 around three axes (i.e., x, y, and z axes) can be determined by the gyro sensor 180B. The gyro sensor 180B can be used for anti-shake shooting. For example, when the shutter is pressed, the gyro sensor 180B detects the angle of the electronic device 100 shaking, calculates the distance that the lens module needs to compensate based on the angle, and allows the lens to offset the shaking of the electronic device 100 through reverse movement to achieve anti-shake. The gyro sensor 180B can also be used for navigation and somatosensory game scenes.

[0085] The air pressure sensor 180C is used to measure air pressure. In some embodiments, the electronic device 100 calculates the altitude through the air pressure value measured by the air pressure sensor 180C to assist positioning and navigation.

[0086] The magnetic sensor 180D includes a Hall sensor. The electronic device 100 can use the magnetic sensor 180D to detect the opening and closing of the flip leather case. In some embodiments, when the electronic device 100 is a flip phone, the electronic device 100 can detect the opening and closing of the flip cover according to the magnetic sensor 180D. Then, according to the detected opening and closing state of the leather case or the opening and closing state of the flip cover, the flip cover can be automatically unlocked.

[0087] The acceleration sensor 180E 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 magnitude and direction of gravity can be detected. It can also be used to identify the posture of the electronic device and is applied to applications such as horizontal and vertical screen switching and pedometers.

[0088] The distance sensor 180F is used to measure the distance. The electronic device 100 can measure the distance by infrared or laser. In some embodiments, when shooting a scene, the electronic device 100 can use the distance sensor 180F to measure the distance to achieve fast focusing.

[0089] The proximity light sensor 180G may include, for example, a light emitting diode (LED) and a light detector, such as a photodiode. The light emitting diode may be an infrared light emitting diode. The electronic device 100 emits infrared light outward through the light emitting diode. The electronic device 100 uses a photodiode to detect infrared reflected light from nearby objects. When sufficient reflected light is detected, it can be determined that there is an object near the electronic device 100. When insufficient reflected light is detected, the electronic device 100 can determine that there is no object near the electronic device 100. The electronic device 100 can use the proximity light sensor 180G to detect that the user holds the electronic device 100 close to the ear to talk, so as to automatically turn off the screen to save power. The proximity light sensor 180G can also be used in leather case mode and pocket mode to automatically unlock and lock the screen.

[0090] The ambient light sensor 180L is used to sense the ambient light brightness. The electronic device 100 can adaptively adjust the brightness of the display screen 194 according to the perceived ambient light brightness. The ambient light sensor 180L can also be used to automatically adjust the white balance when taking pictures. The ambient light sensor 180L can also cooperate with the proximity light sensor 180G to detect whether the electronic device 100 is in a pocket to prevent accidental touches.

[0091] The fingerprint sensor 180H is used to collect fingerprints. The electronic device 100 can use the collected fingerprint characteristics to implement fingerprint unlocking, access application locks, fingerprint photography, fingerprint call answering, etc.

[0092] The temperature sensor 180J is used to detect temperature. In some embodiments, the electronic device 100 uses the temperature detected by the temperature sensor 180J to execute a temperature processing strategy. For example, when the temperature reported by the temperature sensor 180J exceeds a threshold, the electronic device 100 reduces the performance of a processor located near the temperature sensor 180J to reduce power consumption and implement thermal protection. In other embodiments, when the temperature is lower than another threshold, the electronic device 100 heats the battery 142 to avoid abnormal shutdown of the electronic device 100 due to low temperature. In other embodiments, when the temperature is lower than another threshold, the electronic device 100 performs a boost on the output voltage of the battery 142 to avoid abnormal shutdown caused by low temperature.

[0093] The touch sensor 180K is also called a "touch control device". The touch sensor 180K can be set on the display screen 194. The touch sensor 180K and the display screen 194 form a touch screen, also called a "touch control screen". The touch sensor 180K is used to detect touch operations acting on or near it. The touch sensor can pass the detected touch operation to the application processor to determine the type of touch event. Visual output related to the touch operation can be provided through the display screen 194. In other embodiments, the touch sensor 180K can also be set on the surface of the electronic device 100, which is different from the position of the display screen 194.

[0094] The bone conduction sensor 180M can obtain a vibration signal. In some embodiments, the bone conduction sensor 180M can obtain a vibration signal of a vibrating bone block of the vocal part of the human body. The bone conduction sensor 180M can also contact the human pulse to receive a blood pressure beat signal. In some embodiments, the bone conduction sensor 180M can also be set in an earphone and combined into a bone conduction earphone. The audio module 170 can parse out a voice signal based on the vibration signal of the vibrating bone block of the vocal part obtained by the bone conduction sensor 180M to realize a voice function. The application processor can parse the heart rate information based on the blood pressure beat signal obtained by the bone conduction sensor 180M to realize a heart rate detection function.

[0095] The key 190 includes a 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.

[0096] 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. For example, touch operations acting on different applications (such as taking pictures, audio playback, etc.) can correspond to different vibration feedback effects. For touch operations acting on different areas of the display screen 194, motor 191 can also correspond to different vibration feedback effects. Different application scenarios (for example: time reminders, receiving messages, alarm clocks, games, etc.) can also correspond to different vibration feedback effects. The touch vibration feedback effect can also support customization.

[0097] The indicator 192 may be an indicator light, which may be used to indicate the charging status, power changes, messages, missed calls, notifications, etc.

[0098] The SIM card interface 195 is used to connect a SIM card. The SIM card can be connected to and separated from the electronic device 100 by inserting it into the SIM card interface 195 or pulling it out from the SIM card interface 195. The electronic device 100 can support 1 or N SIM card interfaces, where N is a positive integer greater than 1. The SIM card interface 195 can support Nano SIM cards, Micro SIM cards, SIM cards, and the like. Multiple cards can be inserted into the same SIM card interface 195 at the same time. The types of the multiple cards can be the same or different. The SIM card interface 195 can also be compatible with different types of SIM cards. The SIM card interface 195 can also be compatible with external memory cards. The electronic device 100 interacts with the network through the SIM card to implement functions such as calls and data communications. In some embodiments, the electronic device 100 uses an eSIM, i.e., an embedded SIM card. The eSIM card can be embedded in the electronic device 100 and cannot be separated from the electronic device 100.

[0099] 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. Figure 2 It is a software structure block diagram of the electronic device 100 according to an embodiment of the present application.

[0100] The layered architecture divides the software into several layers, each with clear roles and division of labor. The layers communicate with each other through software interfaces. In some embodiments, the Android system is divided into four layers, from top to bottom: the application layer, the application framework layer, the Android runtime and system library, and the kernel layer.

[0101] The application layer can include a series of application packages.

[0102] like Figure 2 As shown, the application package may include camera, gallery, calendar, call, map, navigation, WLAN, Bluetooth, music, video, short message and other applications.

[0103] The application framework layer provides an application programming interface (API) and a programming framework for the applications in the application layer. The application framework layer includes some predefined functions.

[0104] like Figure 2 As shown, 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.

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

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

[0107] The view system includes visual controls, such as controls for displaying text, controls for displaying images, etc. The view system can be used to build applications. A display interface can be composed of one or more views. For example, a display interface including a text notification icon can include a view for displaying text and a view for displaying images.

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

[0109] The resource manager provides various resources for applications, such as localized strings, icons, images, layout files, video files, and so on.

[0110] The notification manager enables applications to display notification information in the status bar. It can be used to convey notification-type messages and can disappear automatically after a short stay without user interaction. For example, the notification manager is used to notify download completion, message reminders, etc. The notification manager 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 notifications of applications running in the background, or a notification that appears on the screen in the form of a dialog window. For example, a text message is displayed in the status bar, a prompt sound is emitted, an electronic device vibrates, an indicator light flashes, etc.

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

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

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

[0114] The system library may 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.

[0115] The surface manager is used to manage the display subsystem and provide the fusion of 2D and 3D layers for multiple applications.

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

[0117] The 3D graphics processing library is used to implement 3D graphics drawing, image rendering, compositing, and layer processing.

[0118] A 2D graphics engine is a drawing engine for 2D drawings.

[0119] The kernel layer is the layer between hardware and software. The kernel layer contains at least display driver, camera driver, audio driver, and sensor driver.

[0120] The following is an illustrative description of the workflow of the software and hardware of the electronic device 100 in conjunction with capturing a photo scene.

[0121] When the touch sensor 180K receives a touch operation, the corresponding hardware interrupt is sent to the kernel layer. The kernel layer processes the touch operation into a raw input event (including touch coordinates, timestamp of the touch operation, and other information). The raw input event is stored in the kernel layer. The application framework layer obtains the raw input event from the kernel layer and identifies the control corresponding to the input event. For example, if the touch operation is a touch single-click operation and the control corresponding to the single-click operation is the control of the camera application icon, the camera application calls the interface of the application framework layer to start the camera application, and then starts the camera driver by calling the kernel layer to capture static images or videos through the camera 193.

[0122] The present application embodiment provides a method for determining an abnormal restart mode. Figure 1 For example, the electronic device in the embodiment of the present application is executed. Figure 3 , the method flow provided in the embodiment of the present application includes:

[0123] 301. When an exception occurs in a unified extensible firmware interface (UEFI) phase of a boot process of an electronic device, a first policy value of a first exception log capture policy and a second policy value of a second exception log capture policy are obtained.

[0124] Among them, the first abnormal log capture strategy and the second abnormal log capture strategy are used to determine the number of abnormal logs to be captured when an abnormality occurs during the startup process of the electronic device. The startup process includes not only the UEFI stage before entering the kernel, but also the startup stage after entering the kernel. The first abnormal log capture strategy can be an apdp strategy, and the second abnormal log capture strategy can be a dload_mode strategy. In different startup stages, the policy values ​​of the first abnormal log capture strategy and the second abnormal log capture strategy are different. In an embodiment of the present application, in the UEFI stage before entering the kernel, the policy values ​​of the first abnormal log capture strategy and the second abnormal log capture strategy can be mini or full; in the startup stage after entering the kernel, the policy values ​​of the first abnormal log capture strategy and the second abnormal log capture strategy can both be mini. Among them, mini is used to indicate that the electronic device does not capture or captures part of the abnormal log when an abnormality occurs during the startup process. In actual business scenarios, the amount of abnormal logs captured is very small, usually tens of K, not more than 1M. full is used to instruct the electronic device to capture the full amount of exception logs when an exception occurs during the boot process. In actual business scenarios, the amount of exception logs captured is large, which can reach more than ten GB or even hundreds of GB. The first policy value of the first exception log capture policy can be configured by the manufacturer's technical staff according to the target users before the electronic device leaves the factory. If it is for commercial users, since commercial users have no need to capture exception logs and need to recover quickly when an exception occurs, the first policy value of the first exception log capture policy can be set to mini; if it is for non-commercial users, such as test users, since test users need to capture exception logs when an exception occurs during the boot process, the first policy value of the first exception log capture policy can be set to full. The second policy value of the second exception log capture policy can also be set by the manufacturer's technical personnel according to the stage where the exception occurs before the electronic device leaves the factory. For the UEFI stage before entering the kernel, the policy value of the second exception log capture policy defaults to full. In the boot stage after entering the kernel, the second policy value of the second exception log capture policy is written by debug_init.rc. If it is for commercial users, the second policy value written in debug_init.rc is mini. If it is for non-commercial users, the second policy value written in debug_init.rc can be full.

[0125] When the electronic device is returned to the factory, the manufacturer's technicians can also modify the first policy value of the first abnormal log capture policy and the second policy value of the second abnormal log capture policy, so as to facilitate testing and debugging and other scenarios that require full capture of abnormal logs. Specifically, the manufacturer's technicians can use fastboot commands or node writing to change the set policy values.

[0126] During the booting process of the electronic device, in response to an exception occurring in the UEFI stage, the electronic device obtains a first policy value of a first exception log capture policy and a second policy value of a second exception log capture policy. When the electronic device obtains the first policy value of the first exception log capture policy, it can be read from a certain image file of the electronic device, and the image file is used to store the policy value set by the manufacturer's technicians for the first exception log capture policy. When the electronic device obtains the second policy value of the second exception log capture policy, it can be read from a certain node of the electronic device, and the node is used to store the policy value set by the manufacturer's technicians for the second exception log capture policy.

[0127] 302. When the first policy value is different from the second policy value, obtain a parameter value of an operating parameter of the electronic device.

[0128] When the first policy value of the first abnormal log capture policy and the second policy value of the second abnormal log capture policy are obtained, the electronic device compares the first policy value and the second policy value. When the first policy value and the second policy value are different, for example, the first policy value of the apdp policy is mini, and the second policy value of the dload_mode policy is full, in order to improve the reliability of the decision result, the electronic device needs to use a third-party policy to determine the abnormal restart method of the electronic device at the current moment. Before using a third-party policy to determine the abnormal restart method of the electronic device at the current moment, the electronic device needs to obtain the parameter value of the operating parameter, and then determine the type of the electronic device based on the parameter value of the operating parameter, and then determine the abnormal restart method based on the policy value of the third-party policy corresponding to the type of the electronic device.

[0129] Among them, the operation parameter is used to indicate the operation state of the electronic device when an abnormality occurs, including a fuse blown parameter and a log version identification parameter. Different parameter values ​​of the fuse blown parameter are used to indicate whether the electronic device has blown the fuse. If the parameter value of the fuse blown parameter indicates that the electronic device has blown the fuse, the operating system of the electronic device will no longer perform some operations during the boot process, such as the full capture operation of the abnormal log, thereby providing the user with a minimalist operation mode; if the parameter value of the fuse blown parameter indicates that the electronic device has not blown the fuse, the operating system of the electronic device will perform operations according to the complete boot process during the boot process, thereby obtaining all data during the operation of the electronic device. Different parameter values ​​of the log version identification parameter are used to indicate whether the operating system of the electronic device needs to capture the full amount of abnormal logs. If the parameter value of the log version identification parameter indicates that the operating system is a logless version, when an abnormality occurs during the boot process, the electronic device does not need to capture the full amount of abnormal logs; if the parameter value of the log version identification parameter indicates that the operating system is a log version, when an abnormality occurs during the boot process, the electronic device needs to capture the full amount of abnormal logs.

[0130] 303. Determine the type of the electronic device based on the parameter value of the operating parameter.

[0131] Among them, the types of electronic devices include the first type and the second type, etc. The first type is used to instruct the electronic device to skip operations unrelated to the restart operation when it is abnormally restarted. The operations unrelated to the restart include the full extraction operation of the abnormal log, etc., and also include some other operations. By not performing these operations unrelated to the restart operation, the restart time of the electronic device is shortened, and the resource consumption of the restart process is saved, which is more friendly to merchant users. In practical applications, the first type of electronic device is also called a commercial type of electronic device. The second type is used to instruct the electronic device to perform all operations related to and unrelated to the restart operation when it is abnormally restarted. Although the operation is performed according to the boot process, the integrity of the operation process is guaranteed, and the complete boot data is obtained, some operations unrelated to the restart operation are performed, which not only prolongs the restart time of the electronic device, but also consumes a lot of resources. For commercial users, the experience effect is not good. In practical applications, the second type of electronic device is also called a non-commercial type of electronic device.

[0132] In the embodiment of the present application, the type of the electronic device is determined based on the parameter value of the operating parameter, including but not limited to the following situations:

[0133] In the first case, when the parameter value of the fuse blown parameter indicates that the fuse has been blown, and the parameter value of the log version identification parameter indicates that the operating system of the electronic device is a logless version, the type of the electronic device is determined to be the first type.

[0134] In the second case, when the parameter value of the fuse blown parameter indicates that the fuse has been blown, and the parameter value of the log version identification parameter indicates that the operating system is a log version, the type of the electronic device is determined to be the second type.

[0135] In the third case, when the parameter value of the fuse blowing parameter indicates that the fuse is not blown, and the parameter value of the log version identification parameter indicates that the operating system is a log-free version, the type of the electronic device is determined to be the second type.

[0136] In a fourth case, when the parameter value of the fuse blown parameter indicates that the fuse is not blown, and the parameter value of the log version identification parameter indicates that the operating system is a log version, it is determined that the type of the electronic device is the second type.

[0137] In summary, when the fuse of an electronic device is blown and the version of the operating system is a log-free version, the electronic device is a first type of electronic device, that is, a commercial type of electronic device. Apart from this, other electronic devices are non-commercial type electronic devices.

[0138] The method provided by the implementation of the present application can identify whether an electronic device is a commercial type electronic device based on the parameter values ​​of the fuse blowing parameter and the log version identification parameter, so that the relevant configuration parameters of the electronic device can be changed according to the identification result to meet the usage requirements of different scenarios.

[0139] Furthermore, the embodiment of the present application also sets different policy values ​​for the third-party policy for different types of electronic devices. Specifically, the policy value of the third-party policy corresponding to the first type is set to a first value, and the policy value of the third-party policy corresponding to the second type is set to a second value. The first value is used to indicate that the electronic device does not capture or captures part of the abnormal log when an abnormality occurs during the boot process, and the first value can be mini; the second value is used to indicate that the electronic device captures the full amount of abnormal logs when an abnormality occurs during the boot process, and the second value can be full.

[0140] Figure 4 A schematic diagram showing the policy results of a third-party policy is shown in Figure 4 When the fuse of the electronic device is blown and the version of the operating system is a log-free version, the policy value of the third-party policy is mini; when the fuse of the electronic device is blown and the version of the operating system is a log version, the policy value of the third-party policy is full; when the fuse of the electronic device is not blown and the version of the operating system is a log-free version, the policy value of the third-party policy is full; when the fuse of the electronic device is not blown and the version of the operating system is a log version, the policy value of the third-party policy is full.

[0141] 304. When the type of the electronic device is the first type, determine that the abnormal restart mode of the electronic device is direct restart.

[0142] In an embodiment of the present application, when the first policy value of the first abnormal log capture policy and the second policy value of the second abnormal log capture policy are different, in order to improve the reliability of the decision result, the electronic device determines the abnormal restart mode of the electronic device in combination with the type to which it belongs. When the type of the electronic device is the first type, the policy value of the third-party policy corresponding to the first type is the first value, and in response to the policy value of the third-party policy being the first value, the electronic device determines that the abnormal restart mode is a direct restart. Further, in response to the determined abnormal restart mode of the electronic device, the electronic device directly restarts without displaying the abnormal log interface.

[0143] The method provided in the application embodiment is that when an electronic device has an abnormality in the UEFI stage of the boot process, the first abnormal log capture strategy and the second abnormal log capture strategy are used to make a decision. When the first strategy value of the first abnormal log capture strategy and the second strategy value of the second abnormal log capture strategy are different, it means that the decision result based on the first abnormal log capture strategy and the second abnormal log capture strategy is not reliable. In order to improve the reliability of the decision result, a third-party strategy is introduced, and then the abnormal restart method of the electronic device is determined based on the third-party strategy. For commercial electronic devices, the strategy value of the third-party strategy is mini, which can ensure that the electronic device is directly powered on and restarted without displaying the abnormal log interface (i.e., the dump interface), shortening the abnormal recovery time and improving the user experience.

[0144] The embodiment of the present application provides a method for determining an abnormal restart mode. Taking an electronic device executing the embodiment of the present application as an example, see Figure 5 , the method provided in the embodiment of the present application includes:

[0145] 501. When an exception occurs in the unified extensible firmware interface (UEFI) phase of the boot process of the electronic device, a first policy value of a first exception log capture policy and a second policy value of a second exception log capture policy are obtained.

[0146] The implementation method of this step is the same as that of the above step 301. Please refer to the above step 301 for details and will not be repeated here.

[0147] 502. When the first policy value is different from the second policy value, obtain a parameter value of an operating parameter of the electronic device.

[0148] The implementation method of this step is the same as that of the above step 303. Please refer to the above step 302 for details, which will not be repeated here.

[0149] 503. Determine the type of the electronic device based on the parameter value of the operating parameter.

[0150] The implementation method of this step is the same as that of the above step 303. Please refer to the above step 502 for details, which will not be repeated here.

[0151] 504. When the type of the electronic device is the second type, a decision is made based on the first policy value and the second policy value to obtain a decision value.

[0152] When the type of the electronic device is the second type, that is, a non-commercial type of electronic device, a decision can be made based on the first policy value of the first abnormal log capture policy and the second policy value of the second abnormal log capture policy, and then the abnormal restart mode of the electronic device is determined based on the determined policy value. When making a decision based on the first policy value and the second policy value, the parameter value of the fuse blown parameter of the electronic device can be obtained. If the parameter value of the fuse blown parameter indicates that the electronic device has blown the fuse, the final decision value can mainly refer to the first policy value of the first abnormal log capture policy, that is, the policy value of the apdp policy; if the parameter value of the fuse blown parameter indicates that the electronic device has not blown the fuse, the final decision value can mainly refer to the second policy value of the second abnormal log capture policy, that is, the policy value of the dload_mode policy.

[0153] 505. Determine an abnormal restart mode of the electronic device based on the decision value.

[0154] The electronic device determines an abnormal restart mode of the electronic device based on the decision value, including but not limited to the following two situations:

[0155] In the first case, when the decision value is a first value, the first value is used to instruct the electronic device not to capture or to capture part of the abnormal log when an abnormality occurs during the startup process. In response to the decision value being the first value, the electronic device determines that the abnormal startup method is to restart directly.

[0156] Furthermore, in response to the abnormal restart mode of the electronic device being a direct restart, the electronic device directly restarts without displaying an abnormal log interface, thereby shortening the abnormal recovery time of the electronic device and improving the user experience.

[0157] In the second case, when the decision value is a second value, the second value is used to instruct the electronic device to capture a full amount of abnormal logs when an abnormality occurs during the startup process. In response to the decision value being the second value, the electronic device determines that the abnormal startup method is to display the abnormal log capture interface and then restart.

[0158] Furthermore, in response to the abnormal restart method of the electronic device being to display the abnormal log capture interface and then restart, the electronic device first displays the abnormal log interface to capture the abnormal log, and after the abnormal log capture is completed, it is backed up and then restarted, thereby meeting the user's demand for abnormal log capture. The extracted abnormal log can be used by technical personnel to analyze the current abnormal problem, thereby avoiding the recurrence of the abnormal problem in the subsequent startup process.

[0159] It should be noted that the above two embodiments describe in detail that when an abnormality occurs in the UEFI stage, the electronic device determines the abnormal restart mode, and then restarts based on the determined abnormal restart mode. When an abnormality occurs in the electronic device during the boot phase after entering the kernel, since the first policy value of the first abnormal log capture policy and the second policy value of the second abnormal log capture policy are both the first value, i.e., mini, the electronic device directly boots and restarts without displaying the abnormal log interface.

[0160] Figure 6 shows abnormal restart modes in different stages of the electronic device startup process, see Figure 6 , the electronic device goes through two stages when it is turned on. One is the UEFI stage before entering the kernel. The UEFI stage includes the XBL stage and the ABL stage; the other is the boot stage after entering the kernel. When an exception occurs in the UEFI stage and an abnormal restart is required, the original solution (i.e., the existing technical solution) obtains the policy value of the apdp policy: mini, and obtains the policy value of the dload_mode policy: full, and then makes a decision based on the policy value of the apdp policy: mini and the policy value of the dload_mode policy: full, and the decision result is mini or full. When the decision result is full, the electronic device first displays the dump interface and then restarts. There is a certain probability of entering the dump interface using the original solution, resulting in a poor user experience. The embodiment of the present application adds a third-party decision on the basis of the original solution. When the type of the electronic device is the first type, that is, the electronic device is a commercial electronic device, the policy value of the third-party policy is mini. At this time, the policy value of the third-party decision is used as the basis. Therefore, when the policy value of the third-party decision is combined with the policy value of the apdp policy and the decision value of the dload_mode policy for decision, it can be guaranteed that the final decision result is mini. In response to the final decision value of mini, the electronic device directly restarts without entering the dump interface.

[0161] When an exception occurs during the boot phase after entering the kernel and an abnormal restart is required, the electronic device obtains the policy value of the apdp policy: mini, and obtains the policy value of the dload_mode policy: mini, and then makes a decision based on the policy value of the apdp policy: mini and the policy value of the dload_mode policy: mini. The final decision result is mini. In response to the final decision value of mini, the electronic device directly restarts without entering the dump interface.

[0162] It should be noted that the execution subject of each step of the method provided in the above embodiment can be the same device, or the method can be executed by different devices. In addition, in some processes described in the above embodiments and the accompanying drawings, multiple operations that appear in a specific order are included, but it should be clearly understood that these operations may not be executed or executed in parallel in the order in which they appear in this article, and the sequence numbers of the operations, such as 301, 302, etc., are only used to distinguish between different operations, and the sequence numbers themselves do not represent any execution order. In addition, these processes may include more or fewer operations, and these operations may be executed in sequence or in parallel.

[0163] FIG7 is a schematic diagram of a structure of a device for determining an abnormal restart mode provided by another exemplary embodiment of the present application. Figure 7 As shown, the device comprises:

[0164] The first acquisition module 701 is used to acquire a first policy value of a first abnormal log capture policy and a second policy value of a second abnormal log capture policy when an abnormality occurs in the unified extensible firmware interface UEFI stage of the boot process of the electronic device;

[0165] A second acquisition module 702, configured to acquire a parameter value of an operation parameter of the electronic device when the first policy value is different from the second policy value, the operation parameter being used to indicate an operation state of the electronic device when an abnormality occurs;

[0166] A first determination module 703, configured to determine the type of the electronic device based on the parameter value of the operating parameter;

[0167] The second determination module 704 is used to determine that the abnormal restart mode of the electronic device is to directly execute the restart process when the type of the electronic device is the first type, and the first type is used to instruct the electronic device to skip operations unrelated to the restart operation when abnormally restarting.

[0168] In another embodiment of the present application, the operating parameters include a fuse blown parameter and a log version identification parameter, and the first determination module 703 is used to determine that the type of the electronic device is the first type when the parameter value of the fuse blown parameter indicates that the fuse has been blown and the parameter value of the log version identification parameter indicates that the operating system of the electronic device is a log-free version; when the parameter value of the fuse blown parameter indicates that the fuse has been blown and the parameter value of the log version identification parameter indicates that the operating system is a log version, the type of the electronic device is determined to be the second type, and the second type is used to indicate that the electronic device performs all operations related to and unrelated to the restart operation during an abnormal restart; when the parameter value of the fuse blown parameter indicates that the fuse is not blown and the parameter value of the log version identification parameter indicates that the operating system is a log-free version, the type of the electronic device is determined to be the second type; when the parameter value of the fuse blown parameter indicates that the fuse is not blown and the parameter value of the log version identification parameter indicates that the operating system is a log version, the type of the electronic device is determined to be the second type.

[0169] In another embodiment of the present application, the policy value of the third-party policy corresponding to the first type is a first numerical value, and the first numerical value is used to indicate that the electronic device does not capture or captures part of the abnormal log when an abnormality occurs during the startup process. The second determination module 704 is used to determine that the abnormal restart method of the electronic device is a direct restart in response to the policy value of the third-party policy being the first numerical value.

[0170] In another embodiment of the present application, the device further comprises:

[0171] a decision module, configured to make a decision based on the first policy value and the second policy value to obtain a decision value when the type of the electronic device is the second type, wherein the second type is used to instruct the electronic device to perform all operations related to and unrelated to the restart operation when the electronic device is abnormally restarted;

[0172] The third determination module is used to determine the abnormal restart mode of the electronic device based on the decision value.

[0173] In another embodiment of the present application, a third determination module is used to determine that the abnormal startup mode of the electronic device is direct restart when the decision value is a first value, and the first value is used to indicate that the electronic device does not capture or captures part of the abnormal log when an abnormality occurs during the startup process; when the decision value is a second value, it is determined that the abnormal startup mode of the electronic device is to display the abnormal log capture interface and then restart, and the second value is used to indicate that the electronic device captures the full amount of abnormal logs when an abnormality occurs during the startup process.

[0174] In another embodiment of the present application, the first value is mini, and the second value is full.

[0175] An embodiment of the present application provides a computer-readable storage medium, in which at least one computer program is stored. When the at least one computer program is executed by a processor, the above-mentioned method for determining an abnormal restart mode can be implemented.

[0176] An embodiment of the present application provides a computer program product, which includes a computer program. When the computer program is executed by a processor, the method for determining the abnormal restart mode can be implemented.

[0177] The above is only an embodiment of the present application and is not intended to limit the present application. For those skilled in the art, the present application may have various changes and variations. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application should be included in the scope of the claims of the present application.

Claims

1. A method for determining an abnormal restart mode, characterized in that: The method comprises: When an exception occurs in the unified extensible firmware interface (UEFI) phase of the boot process of the electronic device, a first policy value of a first exception log capture policy and a second policy value of a second exception log capture policy are obtained; When the first policy value is different from the second policy value, obtaining a parameter value of an operating parameter of the electronic device, where the operating parameter is used to indicate an operating state of the electronic device when an abnormality occurs, and the operating parameter includes a fuse blown parameter and a log version identification parameter; When the parameter value of the fuse blown parameter indicates that the fuse has been blown, and the parameter value of the log version identification parameter indicates that the operating system of the electronic device is a logless version, determining that the type of the electronic device is the first type; When the type of the electronic device is the first type, it is determined that the abnormal restart mode of the electronic device is direct restart, and the first type is used to instruct the electronic device to skip operations unrelated to the restart operation when abnormally restarting.

2. The method according to claim 1, characterized in that: The method further comprises: When the parameter value of the fuse blown parameter indicates that the fuse has been blown, and the parameter value of the log version identification parameter indicates that the operating system is a log version, it is determined that the type of the electronic device is a second type, and the second type is used to indicate that the electronic device performs all operations related to and unrelated to the restart operation when abnormally restarting; When the parameter value of the fuse blown parameter indicates that the fuse is not blown, and the parameter value of the log version identification parameter indicates that the operating system is a logless version, determining that the type of the electronic device is the second type; When the parameter value of the fuse blown parameter indicates that the fuse is not blown, and the parameter value of the log version identification parameter indicates that the operating system is a log version, it is determined that the type of the electronic device is the second type.

3. The method according to claim 1, characterized in that The policy value of the third-party policy corresponding to the first type is a first value, and the first value is used to indicate that when an abnormality occurs in the electronic device during the boot process, no abnormality log is captured or part of the abnormality log is captured. When the type of the electronic device is the first type, determining that the abnormal restart mode of the electronic device is to directly execute the restart process includes: In response to the policy value of the third-party policy being the first value, determining that the abnormal restart mode of the electronic device is a direct restart.

4. The method according to claim 1, characterized in that: The method further comprises: When the type of the electronic device is the second type, a decision is made based on the first policy value and the second policy value to obtain a decision value, and the second type is used to instruct the electronic device to perform all operations related to and unrelated to the restart operation when the electronic device is abnormally restarted; Based on the decision value, an abnormal restart mode of the electronic device is determined.

5. The method according to claim 4, characterized in that The determining, based on the decision value, an abnormal restart mode of the electronic device includes: When the decision value is a first value, it is determined that the abnormal startup mode of the electronic device is direct restart, and the first value is used to instruct the electronic device not to capture or to capture part of the abnormal log when an abnormality occurs during the startup process; When the decision value is a second value, it is determined that the abnormal startup mode of the electronic device is to display an abnormal log capture interface and then restart. The second value is used to instruct the electronic device to capture a full amount of abnormal logs when an abnormality occurs during the startup process.

6. The method according to claim 5, characterized in that The first value is mini, and the second value is full.

7. A device for determining an abnormal restart mode, characterized in that: The device comprises: A first acquisition module is used to acquire a first policy value of a first abnormal log capture policy and a second policy value of a second abnormal log capture policy when an abnormality occurs in a unified extensible firmware interface (UEFI) phase of a boot process of the electronic device; a second acquisition module, configured to acquire, when the first policy value is different from the second policy value, a parameter value of an operation parameter of the electronic device, wherein the operation parameter is used to indicate an operation state of the electronic device when an abnormality occurs, and the operation parameter includes a fuse blown parameter and a log version identification parameter; A first determination module, configured to determine that the type of the electronic device is a first type when the parameter value of the fuse blown parameter indicates that the fuse has been blown and the parameter value of the log version identification parameter indicates that the operating system of the electronic device is a non-log version; The second determination module is used to determine that the abnormal restart mode of the electronic device is direct restart when the type of the electronic device is a first type, and the first type is used to instruct the electronic device to skip operations unrelated to the restart operation when abnormally restarting.

8. The device according to claim 7, characterized in that The first determination module is further used to determine that the type of the electronic device is a second type when the parameter value of the fuse blown parameter indicates that the fuse has been blown and the parameter value of the log version identification parameter indicates that the operating system is a log version, and the second type is used to indicate that the electronic device performs all operations related to and unrelated to the restart operation during an abnormal restart; when the parameter value of the fuse blown parameter indicates that the fuse is not blown and the parameter value of the log version identification parameter indicates that the operating system is a no-log version, the type of the electronic device is determined to be the second type; when the parameter value of the fuse blown parameter indicates that the fuse is not blown and the parameter value of the log version identification parameter indicates that the operating system is a log version, the type of the electronic device is determined to be the second type.

9. The device according to claim 7, characterized in that The policy value of the third-party policy corresponding to the first type is a first value, and the first value is used to indicate that the electronic device does not capture or captures part of the abnormal log when an abnormality occurs during the startup process. The second determination module is used to determine that the abnormal restart method of the electronic device is a direct restart in response to the policy value of the third-party policy being the first value.

10. The device according to claim 7, characterized in that The device also includes: a decision module, configured to make a decision based on the first policy value and the second policy value to obtain a decision value when the type of the electronic device is the second type, wherein the second type is used to instruct the electronic device to perform all operations related to and unrelated to the restart operation when the electronic device is abnormally restarted; The third determining module is used to determine an abnormal restart mode of the electronic device based on the decision value.

11. The device according to claim 10, characterized in that The third determination module is used to determine that the abnormal startup mode of the electronic device is direct restart when the decision value is a first value, and the first value is used to indicate that the electronic device does not capture or captures part of the abnormal log when an abnormality occurs during the startup process; when the decision value is a second value, determine that the abnormal startup mode of the electronic device is to display an abnormal log capture interface and then restart, and the second value is used to indicate that the electronic device captures a full amount of abnormal logs when an abnormality occurs during the startup process.

12. The device according to claim 11, characterized in that The first value is mini, and the second value is full.

13. An electronic device, characterized in that: It comprises a processor and a memory; the memory stores at least one program code; the at least one program code is used to be called and executed by the processor to implement the method for determining the abnormal restart mode as described in any one of claims 1 to 6.

14. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores at least one computer program, and when the at least one computer program is executed by a processor, the method for determining an abnormal restart mode according to any one of claims 1 to 6 can be implemented.

15. A computer program product, characterized in that The computer program product comprises a computer program, and when the computer program is executed by a processor, the method for determining an abnormal restart mode according to any one of claims 1 to 6 can be implemented.

Images