System recovery method and electronic device

Abstract

The application discloses a system recovery method and an electronic device. When the system of the electronic device is restarted, the latest fault information is acquired. Based on the latest fault information, the fault type of the electronic device is determined. In the case that the fault type is peripheral device fault, the fault peripheral device is determined. The device tree corresponding to the electronic device is acquired. The device tree includes multiple nodes, and the multiple nodes correspond to each peripheral device in the electronic device respectively. The state of the node corresponding to the fault peripheral device in the device tree is modified to a disabled state. Based on the modified device tree, each peripheral device in the electronic device is started. The fault peripheral device in the disabled state is not started. In this way, since the fault peripheral device is not started when the system is restarted, the fault peripheral device is not monitored to be faulty, so that it can be ensured that the fault peripheral device does not interfere with the normal start of the system.

Description

Technical Field

[0001] This application belongs to the field of terminal technology, specifically relating to a system recovery method and an electronic device. Background Technology

[0002] With the rapid development of mobile phones and other electronic devices, their functions are becoming increasingly diverse. For example, electronic devices can capture images, collect sensor data such as user movement and health, and play music. The realization of these functions is inseparable from the support of peripheral devices (hereinafter referred to as peripherals).

[0003] However, if a peripheral device malfunctions during the startup or use of an electronic device, the device may repeatedly restart automatically and fail to boot into the system normally. Consequently, because it cannot boot into the system and therefore cannot access data, the user experience is negatively impacted. Summary of the Invention

[0004] This application provides a system recovery method and an electronic device that can solve the problem that when peripheral devices malfunction, the electronic device repeatedly restarts automatically and cannot enter the system normally.

[0005] In a first aspect, this application provides a system recovery method, which is applied to an electronic device. The method includes: acquiring the latest fault information when the electronic device restarts its system; determining the fault type of the electronic device based on the latest fault information; identifying the faulty peripheral device when the fault type is a peripheral device fault; and preventing the faulty peripheral device from starting.

[0006] In this way, since the faulty peripheral will not be started when the system restarts, the faulty peripheral will not be detected, thus ensuring that the faulty peripheral will not interfere with the normal startup of the system.

[0007] In one possible implementation, after identifying the faulty peripheral device, the method further includes: if the faulty peripheral device does not include a display screen or a touch sensor, displaying a first prompt message, the first prompt message being used to prompt the user whether to isolate the faulty peripheral device.

[0008] Thus, assuming neither the display screen nor the touch sensor is malfunctioning, a first prompt message can be displayed on the screen. This first prompt message may include two selection controls: "Yes" and "No". This allows the user, if the touch sensor is not malfunctioning, to choose whether to isolate the faulty peripheral device or not by clicking the "Yes" or "No" controls.

[0009] In one possible implementation, preventing the faulty peripheral device from starting includes: preventing the faulty peripheral device from starting in response to receiving an isolation confirmation operation input by a user; or, if the faulty peripheral device includes a display screen or a touch sensor, preventing the faulty peripheral device from starting.

[0010] Thus, the conditions for triggering the operation to prevent the faulty peripheral device from starting can be divided into the following two cases:

[0011] The first method involves receiving an isolation confirmation operation from the user. For example, if the user selects to isolate a faulty peripheral device by clicking the "Yes" control, the electronic device can receive the user's isolation confirmation operation. In response to receiving the user's isolation confirmation operation, the faulty peripheral device is prevented from starting.

[0012] The second scenario involves a faulty peripheral device including a display screen or a touch sensor. In this case, the electronic device may be unable to perform a display function, or even if it does display an interface, it may not be able to detect the user's touch operation. Therefore, if the faulty peripheral device includes a display screen or a touch sensor, the step of displaying the first prompt information can be skipped, and the faulty peripheral device can be directly prevented from starting.

[0013] In one possible implementation, preventing the faulty peripheral device from starting includes: obtaining a device tree corresponding to the electronic device; the device tree includes multiple nodes, each node corresponding to a peripheral device in the electronic device; modifying the state of the node corresponding to the faulty peripheral device in the device tree to a disabled state; and starting each peripheral device in the electronic device based on the modified device tree; wherein the faulty peripheral device in the disabled state is not started.

[0014] In this way, by modifying the state of the node corresponding to the faulty peripheral device in the device tree to the disabled state, when loading peripheral devices, the faulty peripheral device in the disabled state will not be loaded, and the faulty peripheral device will not be started. As a result, the faulty peripheral device will not be detected, thus ensuring that the system starts normally.

[0015] In one possible implementation, before obtaining the device tree corresponding to the electronic device, the method further includes: if the electronic device includes multiple device trees, determining the device tree corresponding to the electronic device from among the multiple device trees; wherein the multiple device trees correspond to different series of electronic devices, and the peripheral device parameters corresponding to different series of electronic devices are different.

[0016] In one possible implementation, activating the peripheral devices in the electronic device based on the modified device tree includes: traversing each node in the device tree and activating the peripheral devices corresponding to each node based on the state of each node; wherein, the peripheral devices corresponding to nodes in the activated state are activated, and the peripheral devices corresponding to nodes in the disabled state are not activated.

[0017] In this way, since the status of the faulty peripheral device is modified to be disabled in the device tree, the faulty peripheral device will not be activated when the peripheral devices in the electronic device are started, thus ensuring that the faulty peripheral device will not interfere with the normal startup of the system.

[0018] In one possible implementation, activating each peripheral device in the electronic device based on the modified device tree includes: activating each peripheral device in the electronic device based on the modified device tree and the activation priority of each peripheral device; wherein, peripheral devices corresponding to nodes in the activated state are activated, and peripheral devices corresponding to nodes in the disabled state are not activated.

[0019] This allows peripheral devices with higher startup priority that are already in the startup state to be started first.

[0020] In one possible implementation, the method further includes: in response to the electronic device's system being in backup file system dump mode, transferring fault information in the electronic device's memory to a disk.

[0021] Dump mode is a special operating mode in the XBL phase, used to handle system or hardware failures. In other words, when an electronic device detects a system or hardware failure, it triggers a reboot, and during the XBL phase, the system enters dump mode. To prevent the loss of fault information in memory after a power outage, in response to the electronic device's system being in dump mode, the fault information in the electronic device's memory is transferred to disk.

[0022] In one possible implementation, when the system restarts, obtaining the latest fault information includes: obtaining the latest fault information from the disk.

[0023] Since the fault information has been pre-loaded onto the disk, the latest fault information, namely the fault information that triggered this restart operation, can be retrieved from the disk.

[0024] In one possible implementation, the method further includes: after the electronic device restarts, determining whether the disk of the electronic device contains the latest fault information; if the disk of the electronic device contains the latest fault information, generating a second prompt message, the second prompt message being used to prompt the user that the faulty peripheral device has malfunctioned.

[0025] Thus, after the electronic device's system restarts, if the latest fault information is detected on the disk—for example, if the latest fault information on the disk includes a display screen fault—it indicates that the cause of the system restart was a display screen malfunction. A second notification message can then be generated to alert the user that the display screen has malfunctioned.

[0026] In one possible implementation, the method further includes: after the electronic device restarts, monitoring whether the electronic device has malfunctioned; if a malfunction is detected, saving the malfunction information corresponding to the malfunction to the memory of the electronic device, and triggering a restart operation.

[0027] In a second aspect, this application provides an electronic device, the electronic device including a memory and a processor; the memory and the processor are coupled; the memory is used to store computer program code, the computer program code including computer instructions, which, when the processor executes the computer instructions, cause the electronic device to perform the method as described in any one of the first aspects.

[0028] Thirdly, this application provides a computer-readable storage medium storing a computer program or instructions that, when executed, perform the method as described in any one of the first aspects. Attached Figure Description

[0029] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0030] Figure 1 This application provides a schematic diagram of a system restart process.

[0031] Figure 2 A schematic diagram of the hardware structure of an electronic device provided in an embodiment of this application;

[0032] Figure 3 A software architecture diagram of an electronic device provided in an embodiment of this application;

[0033] Figure 4 This is a schematic diagram illustrating the workflow of a system recovery method provided in an embodiment of this application;

[0034] Figure 5 An example user interface diagram of a first prompt message provided in an embodiment of this application;

[0035] Figure 6 A schematic diagram illustrating the workflow of yet another system recovery method provided in this application embodiment;

[0036] Figure 7 An example user interface diagram of a second prompt message provided in an embodiment of this application;

[0037] Figure 8 A schematic diagram illustrating the workflow of yet another system recovery method provided in this application embodiment;

[0038] Figure 9 This is a schematic diagram of a chip structure provided in an embodiment of this application. Detailed Implementation

[0039] With the rapid development of mobile phones and other electronic devices, their functions are becoming increasingly diverse. For example, electronic devices can capture images, collect sensor data such as user movement and health, and play music. The realization of these functions is inseparable from the support of peripheral devices (hereinafter referred to as peripherals).

[0040] In some embodiments, the electronic device may include a display screen, a camera module, sensors (such as touch sensors, pressure sensors, accelerometers, etc.), a smart power amplifier (smart PA), a microphone, a motor, NFC, a fingerprint module, and other peripherals.

[0041] During the startup or use of electronic devices, the devices can monitor for malfunctions in their peripherals in real time. If a malfunction is detected, an automatic restart will be triggered.

[0042] For example, such as Figure 1 As shown, the automatic reboot operation mainly includes five stages: the extensible boot loader (XBL) stage, the Unified extensible firmware interface (UEFI) stage, the Linux kernel stage, the Linux init stage, and the Android stage.

[0043] The XBL stage is the first stage of system startup. During this stage, the electronic device primarily executes hardware initialization and bootloader code. The XBL is a small program, typically stored in the electronic device's boot memory (e.g., flash memory). Its main tasks are to initialize the hardware, load the boot kernel and file system, and then hand control over to the booting kernel.

[0044] The UEFI stage is the second stage of system startup. After the bootloader starts, the electronic device loads the UEFI firmware. The UEFI firmware is responsible for further hardware initialization, loading the bootloader or operating system kernel from the disk, and other tasks. The bootloader loads the operating system kernel, usually the Linux kernel, but it could also be the kernel of another operating system. After the kernel is loaded, the bootloader transfers control to the kernel, putting it into kernel mode.

[0045] The Linux Kernel stage is the third stage of system startup. During the Linux Kernel stage, kernel data structures are initialized, hardware (such as the CPU, memory management unit, peripheral drivers, etc.) is initialized, and the root file system is mounted.

[0046] The Linux Init phase is the fourth stage of system startup. The Linux Init phase is primarily responsible for initializing the system. During the Linux Init phase, the system executes a series of initialization scripts and configuration files to start various system services and daemons. These scripts and configuration files typically define the tasks that should run when the system starts, such as loading drivers, configuring the network, and setting the hostname.

[0047] The Android phase is the fifth stage of system startup. During the Android phase, various system services and applications can be launched. For example, applications may include a desktop manager, application services, and user interfaces.

[0048] Please continue reading Figure 1 Both the Linux Init stage and the Android stage can monitor whether the peripherals of an electronic device have malfunctioned. For example, if the electronic device fails to start its display, the device can determine that the display is faulty. If a peripheral of the electronic device is detected to have malfunctioned, the fault information can be recorded in memory first, and then an automatic restart operation can be triggered, which involves executing the five stages mentioned above.

[0049] However, as Figure 1As shown, because the peripheral device failure issue remains unresolved, the LinuxInit stage still detects the failure after the electronic device automatically restarts, triggering another automatic restart. Therefore, currently, when a peripheral device malfunctions, the electronic device repeatedly restarts automatically and fails to boot into the system normally. Consequently, the inability to boot into the system and access data from the electronic device negatively impacts the user experience.

[0050] To address the aforementioned issues, this application provides a system recovery method that, in response to detecting peripheral device failures in electronic devices, prevents the faulty peripheral device from starting during system restart. Thus, since the faulty peripheral device will not start during system restart, its failure will not be detected, ensuring that the faulty peripheral device will not interfere with the normal startup of the system.

[0051] The system recovery method provided in this application can be applied to electronic devices. In some embodiments, the electronic device may be a mobile phone, tablet computer, handheld computer, personal computer (PC), personal digital assistant (PDA), wearable device, etc. This application does not limit the specific form of the electronic device.

[0052] For example, taking a mobile phone as an electronic device, Figure 2 A schematic diagram of the structure of an electronic device provided in an embodiment of this application is shown.

[0053] like Figure 2 As shown, 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, a headphone jack 170D, a sensor module 180, buttons 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, a barometric pressure sensor 180C, a magnetic sensor 180D, an accelerometer sensor 180E, a distance sensor 180F, a proximity 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.

[0054] It is understood that the structures illustrated in the embodiments of the present invention do not constitute a specific limitation on the electronic device 100. In other embodiments of this application, the electronic device 100 may include more or fewer components than illustrated, or combine some components, or split some components, or have different component arrangements. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

[0055] Processor 110 may include one or more processing units, such as application processors (APs), modem processors, graphics processing units (GPUs), image signal processors (ISPs), controllers, video codecs, digital signal processors (DSPs), baseband processors, and / or neural network processing units (NPUs). These different processing units may be independent devices or integrated into one or more processors.

[0056] The controller can generate operation control signals based on the instruction opcode and timing signals to complete the control of instruction fetching and execution.

[0057] The processor 110 may also include a memory for storing instructions and data. In some embodiments, the memory in the processor 110 is a cache memory. This memory can store instructions or data that the processor 110 has just used or that are used repeatedly. If the processor 110 needs to use the instruction or data again, it can retrieve it directly from the memory. This avoids repeated accesses, reduces the waiting time of the processor 110, and thus improves the efficiency of the system.

[0058] In some embodiments, the processor 110 may include one or more interfaces. Interfaces 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.

[0059] 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 I2C buses. The processor 110 can couple to the touch sensor 180K, charger, flash, camera 193, etc., through different I2C bus interfaces. For example, the processor 110 can couple to the touch sensor 180K through the I2C interface, enabling the processor 110 and the touch sensor 180K to communicate through the I2C bus interface, thereby realizing the touch function of the electronic device 100.

[0060] The I2S interface can be used for audio communication. In some embodiments, the processor 110 may include multiple I2S buses. The processor 110 can be coupled to the audio module 170 via the I2S bus to enable communication between the processor 110 and the audio module 170. In some embodiments, the audio module 170 can transmit audio signals to the wireless communication module 160 via the I2S interface to enable the function of answering phone calls through a Bluetooth headset.

[0061] 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 the 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, enabling the function of answering phone calls through a Bluetooth headset. Both the I2S interface and the PCM interface can be used for audio communication.

[0062] The UART interface is a universal serial data bus used for asynchronous communication. This bus can be a bidirectional communication bus. It converts the data to be transmitted between serial and parallel communication. In some embodiments, the UART interface is typically 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 via the UART interface to implement Bluetooth functionality. In some embodiments, the audio module 170 can transmit audio signals to the wireless communication module 160 via the UART interface to enable music playback through Bluetooth headphones.

[0063] The MIPI interface can be used to connect the processor 110 to peripheral devices such as the display screen 194 and the camera 193. The MIPI interface includes a camera serial interface (CSI) and a display serial interface (DSI). In some embodiments, the processor 110 and the camera 193 communicate via the CSI interface to enable the electronic device 100 to capture images. The processor 110 and the display screen 194 communicate via the DSI interface to enable the electronic device 100 to display images.

[0064] The GPIO interface can be configured via software. It can be configured as a control signal or a data signal. In some embodiments, the GPIO interface can be used to connect the processor 110 to a camera 193, a display screen 194, a wireless communication module 160, an audio module 170, a 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.

[0065] USB port 130 is a USB standard compliant interface, specifically a Mini USB port, Micro USB port, USB Type-C port, etc. USB port 130 can be used to connect a charger to charge electronic device 100, and can also be used for data transfer between electronic device 100 and peripheral devices. It can also be used to connect headphones for audio playback. This interface can also be used to connect other electronic devices, such as AR devices.

[0066] It is understood that the interface connection relationships between the modules illustrated in the embodiments of the present invention are merely illustrative and do not constitute a structural limitation on the electronic device 100. In other embodiments of this application, the electronic device 100 may also employ different interface connection methods or combinations of multiple interface connection methods as described in the above embodiments.

[0067] The charging management module 140 receives charging input from a charger. The charger can be a wireless charger or a wired charger. In some wired charging embodiments, the charging management module 140 receives charging input from the wired charger via the USB interface 130. In some wireless charging embodiments, the charging management module 140 receives wireless charging input via the wireless charging coil of the electronic device 100. While charging the battery 142, the charging management module 140 can also supply power to the electronic device via the power management module 141.

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

[0069] The wireless communication function of electronic device 100 can be realized through antenna 1, antenna 2, mobile communication module 150, wireless communication module 160, modem processor and baseband processor, etc.

[0070] 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 one or more communication frequency bands. Different antennas can also be multiplexed to improve antenna utilization. For example, antenna 1 can be multiplexed as a diversity antenna for a wireless local area network. In some other embodiments, the antennas can be used in conjunction with tuning switches.

[0071] The mobile communication module 150 can provide solutions for wireless communication, including 2G / 3G / 4G / 5G, applied to the electronic device 100. The mobile communication module 150 may include at least one filter, switch, power amplifier, low noise amplifier (LNA), etc. The mobile communication module 150 can receive electromagnetic waves via antenna 1, and perform filtering, amplification, and other processing on the received electromagnetic waves before transmitting them to a modem processor for demodulation. The mobile communication module 150 can also amplify the signal modulated by the modem processor and convert it into electromagnetic waves for radiation via antenna 1. In some embodiments, at least some functional modules of the mobile communication module 150 may be housed in the processor 110. In some embodiments, at least some functional modules of the mobile communication module 150 and at least some modules of the processor 110 may be housed in the same device.

[0072] The modem processor may include a modulator and a demodulator. The modulator modulates the low-frequency baseband signal to be transmitted into a mid-to-high frequency signal. The demodulator demodulates 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 processing by the baseband processor, the low-frequency baseband signal is transmitted to the application processor. The application processor outputs sound signals through an audio device (not limited to speaker 170A, receiver 170B, etc.) or displays images or videos through the display screen 194. In some embodiments, the modem processor may be a separate device. In other embodiments, the modem processor may be independent of the processor 110 and may be housed in the same device as the mobile communication module 150 or other functional modules.

[0073] The wireless communication module 160 can provide solutions for wireless communication applications on the electronic device 100, including wireless local area networks (WLANs) (such as wireless fidelity (Wi-Fi) networks), Bluetooth (BT), global navigation satellite system (GNSS), frequency modulation (FM), near field communication (NFC), and infrared (IR) technologies. 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 antenna 2, performs frequency modulation and filtering of the electromagnetic wave signals, and sends the processed signal to processor 110. The wireless communication module 160 can also receive signals to be transmitted from processor 110, perform frequency modulation and amplification, and convert them into electromagnetic waves for radiation via antenna 2.

[0074] In some embodiments, antenna 1 of electronic device 100 is coupled to mobile communication module 150, and antenna 2 is coupled to wireless communication module 160, enabling electronic device 100 to communicate with networks and other devices via 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 technologies, etc. The GNSS may include the Global Positioning System (GPS), the Global Navigation Satellite System (GLONASS), the BeiDou Navigation Satellite System (BDS), the Quasi-Zenith Satellite System (QZSS), and / or satellite-based augmentation systems (SBAS).

[0075] Electronic device 100 implements display functions through a GPU, a display screen 194, and an application processor. The GPU is a microprocessor for image processing, connected to the display screen 194 and the application processor. The GPU is used to perform mathematical and geometric calculations and for graphics rendering. Processor 110 may include one or more GPUs, which execute program instructions to generate or modify display information.

[0076] Display screen 194 is used to display images, videos, etc. Display screen 194 includes a display panel. The display panel may be a liquid crystal display (LCD), an organic light-emitting diode (OLED), an active-matrix organic light-emitting diode (AMOLED), a flexible light-emitting diode (FLED), a miniature LED, a microLED, a quantum dot light-emitting diode (QLED), etc. In some embodiments, electronic device 100 may include one or N displays 194, where N is a positive integer greater than 1.

[0077] Electronic device 100 can perform shooting functions through ISP, camera 193, video codec, GPU, display 194 and application processor.

[0078] The ISP (Image Signal Processor) is used to process data fed back from the camera 193. For example, when taking a picture, the shutter is opened, and light is transmitted through the lens to the camera's photosensitive element. The light signal is converted into an electrical signal, and the camera's photosensitive element transmits the electrical signal to the ISP for processing, converting it into an image visible to the naked eye. The ISP can also perform algorithmic optimization on image noise and brightness. The ISP can also optimize parameters such as exposure and color temperature of the shooting scene. In some embodiments, the ISP can be set in the camera 193.

[0079] Camera 193 is used to capture still images or videos. An object is projected onto a photosensitive element by generating an optical image through the lens. The photosensitive element can be a charge-coupled device (CCD) or a complementary metal-oxide-semiconductor (CMOS) phototransistor. The photosensitive element converts the light signal into an electrical signal, which is then passed to an ISP for conversion into a digital image signal. The ISP outputs the digital image signal to a DSP for processing. The DSP converts the digital image signal into image signals in standard RGB, YUV, or other formats. In some embodiments, the electronic device 100 may include one or N cameras 193, where N is a positive integer greater than 1.

[0080] Digital signal processors (DSPs) are used to process digital signals. Besides digital image signals, they can also process other digital signals. For example, when electronic device 100 selects a frequency, the DSP can perform Fourier transforms on the frequency energy.

[0081] Video codecs are used to compress or decompress digital video. Electronic device 100 may support one or more video codecs. Thus, electronic device 100 can play or record videos in various encoding formats, such as Moving Picture Experts Group (MPEG) 1, MPEG2, MPEG3, MPEG4, etc.

[0082] An NPU (Neural Processing Unit) is a computational processor for neural networks (NNs). By borrowing the structure of biological neural networks, such as the transmission patterns between neurons in the human brain, it can rapidly process input information and continuously learn on its own. NPUs enable intelligent cognitive applications in electronic devices, such as image recognition, facial recognition, speech recognition, and text understanding.

[0083] The external storage 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 storage interface 120 to perform data storage functions. For example, music, video, and other files can be saved on the external memory card.

[0084] Internal memory 121 can be used to store computer executable program code, which includes instructions. Internal memory 121 may include a program storage area and a data storage area. The program storage area may store the operating system, at least one application program required for a function (such as sound playback, image playback, etc.), etc. The data storage area may store data created during the use of electronic device 100 (such as audio data, phonebook, etc.). Furthermore, internal memory 121 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, universal flash storage (UFS), etc. Processor 110 executes various functional applications and data processing of electronic device 100 by running instructions stored in internal memory 121 and / or instructions stored in memory located in the processor.

[0085] Electronic device 100 can implement audio functions, such as music playback and recording, through audio module 170, speaker 170A, receiver 170B, microphone 170C, headphone jack 170D, and application processor.

[0086] The audio module 170 is used to convert digital audio information into analog audio signals for output, and also to convert analog audio input into digital audio signals. The audio module 170 can also be used for encoding and decoding audio signals. In some embodiments, the audio module 170 may be located in the processor 110, or some functional modules of the audio module 170 may be located in the processor 110.

[0087] The speaker 170A, also known as a "loudspeaker," is used to convert audio electrical signals into sound signals. The electronic device 100 can listen to music or make hands-free calls through the speaker 170A. Multiple speakers 170A can be installed in the electronic device 100; for example, a speaker 170A can be installed on the top of the electronic device 100, or a speaker 170A can be installed on the bottom, etc.

[0088] The receiver 170B, also known as a "handpiece," is used to convert audio electrical signals into sound signals. When the electronic device 100 answers a telephone call or voice message, the receiver 170B can be brought close to the ear to hear the voice. In some embodiments, the speaker 170A and the receiver 170B can also be configured as a single component, which is not a limitation of this application.

[0089] Microphone 170C, also known as a "microphone" or "voice transducer," is used to convert sound signals into electrical signals. When making a phone call or sending a voice message, the user can speak by bringing their mouth close to microphone 170C, inputting the sound signal into microphone 170C. Electronic device 100 may have at least one microphone 170C. In some embodiments, electronic device 100 may have two microphones 170C, which, in addition to collecting sound signals, can also perform noise reduction. In other embodiments, electronic device 100 may also have three, four, or more microphones 170C, which can collect sound signals, reduce noise, identify the sound source, and perform directional recording, etc.

[0090] The 170D headphone jack is used to connect wired headphones. The 170D headphone jack can be a USB 130 interface or a 3.5mm Open Mobile Terminal Platform (OMTP) standard interface, a CTIA (Cellular Telecommunications Industry Association of the USA) standard interface.

[0091] Pressure sensor 180A is used to sense pressure signals and convert them into electrical signals. In some embodiments, pressure sensor 180A can be disposed on display screen 194. There are many types of pressure sensors 180A, such as resistive pressure sensors, inductive pressure sensors, and capacitive pressure sensors. A capacitive pressure sensor may include at least two parallel plates with conductive material. When force is applied to pressure sensor 180A, the capacitance between the electrodes changes. Electronic device 100 determines the pressure intensity based on the change in capacitance. When a touch operation is applied to display screen 194, electronic device 100 detects the intensity of the touch operation based on pressure sensor 180A. Electronic device 100 can also calculate the touch position based on the detection signal from pressure sensor 180A. In some embodiments, touch operations applied to the same touch position but with different touch operation intensities can correspond to different operation commands. For example, when a touch operation with an intensity less than a first pressure threshold is applied to the SMS application icon, a command to view an SMS is executed. When a touch operation with an intensity greater than or equal to the first pressure threshold is applied to the SMS application icon, a command to create a new SMS is executed.

[0092] The gyroscope sensor 180B can be used to determine the motion attitude of the electronic device 100. In some embodiments, the gyroscope sensor 180B can determine the angular velocity of the electronic device 100 about three axes (i.e., the x, y, and z axes). The gyroscope sensor 180B can be used for image stabilization. For example, when the shutter is pressed, the gyroscope sensor 180B detects the angle of the shake of the electronic device 100, calculates the distance that the lens module needs to compensate based on the angle, and allows the lens to counteract the shake of the electronic device 100 by moving in the opposite direction, thus achieving image stabilization. The gyroscope sensor 180B can also be used in navigation and motion-sensing game scenarios.

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

[0094] 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 cover. 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 using the magnetic sensor 180D. Then, based on the detected opening and closing state of the cover or the flip cover, features such as automatic flip unlocking can be set.

[0095] The 180E accelerometer can detect the magnitude of acceleration of electronic device 100 in various directions (typically three axes). When electronic device 100 is stationary, it can detect the magnitude and direction of gravity. It can also be used to identify the posture of electronic devices and applied to applications such as screen orientation switching and pedometers.

[0096] A distance sensor 180F is used to measure distance. Electronic device 100 can measure distance via infrared or laser. In some embodiments, during a shooting scene, electronic device 100 can utilize the distance sensor 180F to measure distance for rapid focusing.

[0097] The proximity sensor 180G may include, for example, a light-emitting diode (LED) and a light detector, such as a photodiode. The LED may be an infrared LED. The electronic device 100 emits infrared light outward through the LED. The electronic device 100 uses the 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 may use the proximity sensor 180G to detect when a user holds the electronic device 100 close to their ear for a call, so as to automatically turn off the screen to save power. The proximity sensor 180G can also be used in holster mode and pocket mode for automatic unlocking and locking of the screen.

[0098] The ambient light sensor 180L is used to sense the brightness of ambient light. The electronic device 100 can adaptively adjust the brightness of the display screen 194 based on the sensed 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 work with the proximity sensor 180G to detect whether the electronic device 100 is in a pocket to prevent accidental touches.

[0099] The fingerprint sensor 180H is used to collect fingerprints. The electronic device 100 can utilize the characteristics of the collected fingerprints to achieve fingerprint unlocking, accessing application locks, taking photos with fingerprints, answering calls with fingerprints, etc.

[0100] Temperature sensor 180J is used to detect temperature. In some embodiments, electronic device 100 uses the temperature detected by temperature sensor 180J to execute a temperature handling strategy. For example, when the temperature reported by temperature sensor 180J exceeds a threshold, electronic device 100 performs thermal protection by reducing the performance of a processor located near temperature sensor 180J to reduce power consumption. In other embodiments, when the temperature is below another threshold, electronic device 100 heats battery 142 to prevent abnormal shutdown of electronic device 100 due to low temperature. In still other embodiments, when the temperature is below yet another threshold, electronic device 100 boosts the output voltage of battery 142 to prevent abnormal shutdown due to low temperature.

[0101] Touch sensor 180K, also known as a "touch device," can be located on display screen 194. The touch sensor 180K and display screen 194 together form a touchscreen, also known as a "touchscreen." Touch sensor 180K detects touch operations applied to or near it. The touch sensor can transmit 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 display screen 194. In other embodiments, touch sensor 180K may also be located on the surface of electronic device 100, in a different position than display screen 194.

[0102] The bone conduction sensor 180M can acquire vibration signals. In some embodiments, the bone conduction sensor 180M can acquire vibration signals from the vibrating bone segments of the human vocal cords. The bone conduction sensor 180M can also contact the human pulse to receive blood pressure signals. In some embodiments, the bone conduction sensor 180M can also be incorporated into headphones to form bone conduction headphones. The audio module 170 can parse the voice signals from the vibrating bone segments of the vocal cords acquired by the bone conduction sensor 180M to realize voice functionality. The application processor can parse heart rate information from the blood pressure signals acquired by the bone conduction sensor 180M to realize heart rate detection functionality.

[0103] Buttons 190 include a power button, volume buttons, etc. Buttons 190 can be mechanical buttons or touch-sensitive buttons. Electronic device 100 can receive button input and generate key signal inputs related to user settings and function control of electronic device 100.

[0104] Motor 191 can generate vibration alerts. Motor 191 can be used for incoming call vibration alerts or for touch vibration feedback. For example, different vibration feedback effects can correspond to touch operations performed on different applications (such as taking photos, playing audio, etc.). Motor 191 can also correspond to different vibration feedback effects for touch operations performed on different areas of the display screen 194. Different application scenarios (such as time reminders, receiving messages, alarm clocks, games, etc.) can also correspond to different vibration feedback effects. The touch vibration feedback effect can also be customized.

[0105] Indicator 192 can be an indicator light, used to indicate charging status, power changes, or to indicate messages, missed calls, notifications, etc.

[0106] The SIM card interface 195 is used to connect a SIM card. The SIM card can be inserted into or removed from the SIM card interface 195 to make contact with and separate from the electronic device 100. The electronic device 100 can support one 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, etc. Multiple cards can be inserted into the same SIM card interface 195 simultaneously. The multiple cards can be of the same or different types. The SIM card interface 195 is also compatible with different types of SIM cards. The SIM card interface 195 is also compatible with external memory cards. The electronic device 100 interacts with the network through the SIM card to realize functions such as calls and data communication. 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.

[0107] The software system of electronic device 100 can adopt a layered architecture, event-driven architecture, microkernel architecture, microservice architecture, or cloud architecture. This embodiment of the invention uses the layered architecture Android system as an example to exemplify the software structure of electronic device 100.

[0108] Figure 3 This is a software structure block diagram of the electronic device 100 according to an embodiment of this application.

[0109] A layered architecture divides software into several layers, each with a clear role and function. 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 libraries, and the kernel layer.

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

[0111] like Figure 3 As shown, the application package may include applications such as camera, gallery, calendar, call, map, navigation, WLAN, Bluetooth, music, video, and SMS.

[0112] The application framework layer provides application programming interfaces (APIs) and a programming framework for applications in the application layer. The application framework layer includes some predefined functions.

[0113] like Figure 3 As shown, the application framework layer may include a window manager, content provider, view system, phone manager, resource manager, notification manager, etc.

[0114] The window manager is used to manage windowed applications. It can retrieve screen size, determine the presence of a status bar, lock the screen, and capture screenshots, among other things.

[0115] Content providers store and retrieve data, making that data accessible to applications. This data may include videos, images, audio, made and received phone calls, browsing history and bookmarks, phone books, etc.

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

[0117] The phone manager is used to provide communication functions for electronic device 100. For example, it manages call status (including connection and disconnection).

[0118] The file explorer provides applications with various resources, such as localized strings, icons, images, layout files, video files, and more.

[0119] The notification manager allows applications to display notifications in the status bar. These notifications can be used to deliver informational messages and can disappear automatically after a short pause, requiring no user interaction. For example, the notification manager can be used to notify users of completed downloads or message alerts. The notification manager can also display notifications as icons or scrolling text in the top status bar, such as notifications from background applications, or as dialog boxes on the screen. Examples include displaying text messages in the status bar, emitting sounds, vibrating electronic devices, and flashing indicator lights.

[0120] The Android Runtime consists of core libraries and a virtual machine. The Android runtime is responsible for the scheduling and management of the Android system.

[0121] The core library consists of two parts: one part is the functionalities that need to be called by the Java language, and the other part is the Android core library.

[0122] The application layer and application framework layer run in a virtual machine. The virtual machine executes the Java files of the application layer and application framework layer as binary files. The virtual machine is used to perform functions such as object lifecycle management, stack management, thread management, security and exception management, and garbage collection.

[0123] System libraries can include multiple functional modules. For example: surface manager, media libraries, 3D graphics processing libraries (e.g., OpenGL ES), 2D graphics engines (e.g., SGL), etc.

[0124] The Surface Manager is used to manage the display subsystem and provides the blending of 2D and 3D layers for multiple applications.

[0125] The media library supports playback and recording of various common audio and video formats, as well as still image files. It supports multiple audio and video encoding formats, such as MPEG4, H.264, MP3, AAC, AMR, JPG, and PNG.

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

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

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

[0129] The following is a detailed description of a system recovery method provided in the embodiments of this application.

[0130] like Figure 4 As shown, if an electronic device experiences a processing system or hardware failure during startup or use, it will attempt an automatic restart. The automatic restart process of an electronic device mainly includes five stages: the XBL stage, the UEFI stage, the Linux Kernel stage, the Linux Init stage, and the Android stage. The XBL stage can be executed by the XBL process, the UEFI stage by the UEFI process, the Linux Kernel stage by the kernel, the Linux Init stage by the Init process, and the Android stage by the Android system.

[0131] The following is based on Figure 4 The system startup process shown below provides a detailed description of the system recovery method provided in this application embodiment.

[0132] The XBL phase is the first phase of system startup. The XBL phase may include the following steps:

[0133] S201, the system enters backup file system dump mode.

[0134] The automatic restart operation of electronic devices first enters the XBL (Extended Boot Record) stage. Dump mode is a special operating mode within the XBL stage, used to handle system or hardware failures. In other words, when an electronic device detects a system or hardware failure, it triggers a restart operation, and during the XBL stage, the system enters dump mode.

[0135] S202, in response to the system entering dump mode, reads fault information from the memory of the electronic device.

[0136] During the Linux Init and Android phases, if an electronic device detects a peripheral malfunction, it records the fault information and saves it to the device's memory for later diagnosis and analysis. This allows the system to retrieve the fault information from the device's memory once it enters dump mode.

[0137] In some embodiments, fault information may include fault type, error code, and the context in which the fault occurred. For example, fault type may include peripheral device fault, system-on-chip (SoC) fault, central processor (CPU) fault, etc. Different fault types correspond to different error codes, thus allowing the fault type to be determined based on the error code.

[0138] If the fault type is a peripheral device fault, the fault information may also include the identifier of the peripheral device that malfunctioned. For example, peripheral identifier 001 indicates a display screen fault, peripheral identifier 002 indicates a touch sensor fault, peripheral identifier 003 indicates a camera module fault, peripheral identifier 004 indicates a pressure sensor fault, peripheral identifier 005 indicates a smart power amplifier (smart PA) fault, peripheral identifier 006 indicates a microphone fault, peripheral identifier 007 indicates a motor fault, peripheral identifier 008 indicates an NFC fault, and peripheral identifier 009 indicates a fingerprint module fault, etc. Thus, based on peripheral identifiers 001-009 in the fault information, it is possible to determine which peripheral device malfunctioned.

[0139] S203, the fault information is transferred to the electronic device's disk.

[0140] It should be noted that the electronic device remains powered during the XBL phase. After the XBL phase is completed, the power is turned off first, and then the device is rebooted to enter the UEFI phase.

[0141] Since data stored in the memory of an electronic device is lost when power is cut off, but data stored on its hard drive is not, fault information in memory is first transferred to the hard drive during the XBL (Error Boot Recording) stage to prevent the loss of fault information after power failure.

[0142] After the fault information is saved to the disk, the electronic device is powered off, restarted, and enters the UEFI phase. The UEFI phase is the second phase of system startup. The UEFI phase may include the following steps:

[0143] S204: Retrieve the latest fault information from the electronic device's disk.

[0144] Since the fault information has been transferred to the disk during the XBL stage, the fault information can still be retrieved from the disk of the electronic device after it is powered off and restarted.

[0145] In some embodiments, the electronic device may store multiple fault information on its disk. In this case, the latest fault information is obtained in S204 so that the obtained fault information is the fault information that occurred before this restart.

[0146] In one possible implementation, the latest fault information can be determined from multiple fault information entries based on their storage time. For example, the fault information whose storage time is closest to the current system time can be determined as the latest fault information.

[0147] In one possible implementation, the latest fault information can be determined from multiple fault information entries based on their occurrence times. For example, the fault information whose occurrence time is closest to the current system time can be determined as the latest fault information.

[0148] In one possible implementation, if the fault information is transferred to the electronic device's disk during this startup process, a marker can be added to the most recently transferred fault information. This marker allows the identification of the latest fault information on the disk.

[0149] S205, based on the fault information, determine whether the fault type of the electronic device is a peripheral fault.

[0150] There are many reasons why electronic devices may restart, such as peripheral malfunctions, CPU failures, and SoC (System-on-a-Chip) failures. The fault information records the fault type. Therefore, during the UEFI (Unified Electronic Components) phase, the fault type of the electronic device can be determined based on the fault information. For example, the fault type can be determined based on the error code in the fault information.

[0151] S206, if the fault type is peripheral fault, determine whether the faulty peripheral is the display screen or the touch sensor.

[0152] In some embodiments, if the fault type is a peripheral fault, the peripheral identifier in the fault information, such as 001-009, can be used to determine which peripheral is faulty, i.e., to identify the faulty peripheral.

[0153] If the faulty peripheral is not the display or touch sensor, proceed with steps S207-S209. If the faulty peripheral is the display or touch sensor, proceed with steps S208-S209.

[0154] S207 If the faulty peripheral does not include a display screen or touch sensor, a first prompt message is displayed to prompt the user whether to isolate the faulty peripheral.

[0155] If the faulty peripheral does not include a display screen, a first warning message can be displayed on the screen. If the faulty peripheral does not include a touch sensor, the user can choose whether to isolate the faulty peripheral by clicking on the controls displayed on the screen.

[0156] For example, taking the faulty peripheral device as the front-facing camera module in the camera module as an example, such as Figure 5 As shown, a first prompt message, "Isolate the front camera module?", can be displayed on the user interface of the electronic device. After the first prompt message is displayed, the user can click the "Yes" or "No" control to trigger different processing flows.

[0157] For example, if the electronic device detects that the user clicks the "Yes" control, steps S208 to S209 are executed. If the electronic device detects that the user clicks the "No" control, step S209 is executed.

[0158] It should be noted that in this embodiment, there may be one or more faulty peripherals. If there are multiple faulty peripherals, the generated first prompt message can be used to prompt the user whether to isolate all faulty peripherals.

[0159] S208, Modify the status of the faulty peripheral node in the flattened device tree (FDT) to disabled.

[0160] In some embodiments, if a first prompt message is displayed on the screen of an electronic device and an isolation confirmation operation by the user is detected, the state of the faulty peripheral node in the device tree can be modified to disabled.

[0161] For example, the user's confirmation of isolation can be achieved by the user clicking the "Yes" control in the first prompt message.

[0162] In some embodiments, if step S206 determines that the faulty peripheral is a display screen or a touch sensor, step S207 can be skipped and step S208 can be executed, that is, the status of the faulty peripheral node in the device tree can be directly modified to disabled in the background.

[0163] The device tree is a registry used to describe peripheral devices and related information.

[0164] In some embodiments, the device tree may include multiple nodes, each node corresponding to a peripheral device and its corresponding peripheral device information. For example, the peripheral device information may include the peripheral device name, peripheral device status, etc. The peripheral device status includes two states: enabled and disabled.

[0165] In some embodiments, modifying the state of a faulty peripheral node in the device tree to disabled can be achieved by traversing each node in the device tree to find the node corresponding to the faulty peripheral. After finding the node corresponding to the faulty peripheral, the peripheral state of that node can be modified to disabled.

[0166] For example, taking the faulty peripheral as a front-facing camera module, traverse each node in the device tree to find the node corresponding to the front-facing camera module. After finding the node corresponding to the front-facing camera module, set the status attribute of that node to "disabled" or "off" to disable the peripheral corresponding to the front-facing camera module.

[0167] In practice, the status of a faulty peripheral node in the device tree can be modified to disabled using functions such as fdt_begin_node, fdt_end_node, fdt_add_string_, and fdt_del_last_string_.

[0168] In this way, the status of the faulty peripheral node in the modified device tree will be disabled.

[0169] Typically, different series of electronic devices from the same manufacturer may use different peripheral models and performance parameters. Therefore, in some embodiments, a single electronic device may store multiple device trees, each corresponding to a different series of peripheral devices.

[0170] For example, three device trees are stored in the same electronic device, where device tree 01 corresponds to the peripherals of the A series electronic device, device tree 02 corresponds to the peripherals of the B series electronic device, and device tree 03 corresponds to the peripherals of the C series electronic device.

[0171] Thus, in some embodiments, the state of a faulty peripheral node in each device tree of the electronic device can be modified to be disabled.

[0172] S209 continues to boot and enter the Linux Kernel stage.

[0173] If the fault type is not a peripheral fault, or if it is a non-isolated confirmation operation in response to user input, then proceed directly to step S209.

[0174] The user's confirmation of not isolating can be achieved by clicking the "No" control in the first prompt message.

[0175] The above embodiments are merely illustrative examples of the UEFI stage processing flow using steps S204-S209, and do not imply any limitation on the UEFI stage processing flow. For example, as Figure 6 As shown, the UEFI phase processing flow can also adopt the following steps:

[0176] S301 retrieves the latest fault information from the electronic device's disk.

[0177] S302, based on the fault information, determine whether the fault type of the electronic device is a peripheral fault.

[0178] S303, if the fault type is peripheral fault, then identify the faulty peripheral.

[0179] S304, Modify the status of the faulty peripheral node in the device tree to disabled.

[0180] S305 continues to boot and enters the Linux Kernel stage.

[0181] In other words, Figure 6 In the UEFI phase processing flow shown, after identifying the faulty peripheral device, the status of the faulty peripheral device node in the device tree can be directly modified to disabled. There is no need to perform the steps of determining whether the faulty peripheral device is a display screen or a touch sensor, and determining whether to display the first prompt message based on the determination result. This simplifies the UEFI phase processing flow.

[0182] Steps S301-S303 can be found in the description of steps S204-S206 above, and steps S304-S305 can be found in the description of steps S208-S209 above, and will not be repeated here.

[0183] The Linux Kernel stage is the third stage of system startup. Upon entering the Linux Kernel stage, the bootloader transfers control to the kernel, causing it to enter kernel mode. The Linux Kernel stage may include the following steps:

[0184] S210, Determine the device tree corresponding to the current electronic device.

[0185] In some embodiments, multiple device trees may be stored within the same electronic device. Therefore, upon entering the Linux Kernel stage, the device tree corresponding to the current electronic device can be determined. For example, the product information of the current electronic device can be obtained first, and based on this information, it can be determined that the current electronic device is a B series device. Furthermore, the device tree corresponding to the current electronic device can be determined to be device tree 02. In this way, various peripherals can be loaded subsequently based on device tree 02.

[0186] It should be noted that if an electronic device contains only one device tree, that device tree can be directly identified as the device tree corresponding to the electronic device.

[0187] After determining the device tree corresponding to the current electronic device, the system enters the Linux Init stage. The Linux Init stage is the fourth stage of system startup and can also be referred to as Linux user space.

[0188] The Linux Init phase is responsible for initializing the system. During the Linux Init phase, the system executes a series of initialization scripts and configuration files to start various system services and daemons. These scripts and configuration files typically define the tasks that should run when the system starts, such as loading drivers, configuring the network, and setting the hostname.

[0189] Taking the loading of peripheral drivers as an example, after entering the Linux Init stage, peripheral drivers can be loaded based on the defined device tree. It should be understood that during the Linux Init stage, peripheral drivers that are enabled in the device tree are loaded, while those that are disabled are not. Since the state of faulty peripheral nodes in the device tree is modified to disabled during the UEFI stage, faulty peripheral drivers are not loaded during the Linux Init stage. This ensures that faulty peripherals will not interfere with the normal system startup.

[0190] Specifically, the Linux Init phase may include the following steps:

[0191] S211, Load the peripheral driver corresponding to the node whose status is enabled in the device tree.

[0192] In some embodiments, peripheral drivers corresponding to each node that is enabled can be loaded one by one based on the modified device tree.

[0193] In some embodiments, peripheral drivers corresponding to nodes in the enabled state can also be loaded based on preset priority rules.

[0194] For example, the Linux Init phase can be divided into two loading phases based on preset priority rules. The first loading phase loads higher-priority peripheral drivers and system services, while the second loading phase loads lower-priority peripheral drivers and system services.

[0195] S212, after loading the peripheral driver corresponding to the node whose status is enabled in the device tree, monitor whether a new peripheral failure occurs.

[0196] In some embodiments, if a peripheral driver fails to load successfully during the Linux Init phase, the system will report an error, allowing the electronic device to detect a peripheral failure.

[0197] For example, if the display of the electronic device malfunctions again during the reboot phase, the system will report the display malfunction when the display is loaded during the Linux Init phase.

[0198] S213 If a peripheral device malfunction is detected, the malfunction information is recorded in the memory of the electronic device.

[0199] When a peripheral device malfunctions, the system can automatically save the relevant fault information to the electronic device's memory.

[0200] Furthermore, after recording the fault information into the electronic device's memory, an automatic restart operation is triggered again. That is, the system re-enters the XBL stage and re-executes steps S201-S212. Correspondingly, in the UEFI stage, the status of the display node in the device tree is modified to disabled.

[0201] After the Linux Init phase initializes the system, the system proceeds to the Android phase, the fifth stage of system startup, also known as the Android user space. The Android phase allows the launch of various applications, including the desktop manager, application services, and user interface. Specifically, the Android phase may include the following steps:

[0202] S214, during the Android phase, determines whether the disk contains new fault information.

[0203] In this embodiment, the fault information on the disk is transferred from memory to disk during the XBL stage. Therefore, the new fault information refers to the latest fault information transferred from memory to disk during this boot process.

[0204] In some embodiments, if fault information is transferred to the electronic device's disk during this startup process, a marker can be added to the latest transferred fault information. This marker allows determination of whether the disk contains new fault information. For example, if the disk contains a marker, it is determined that the disk contains new fault information. If the disk does not contain a marker, it is determined that the disk does not contain new fault information.

[0205] S215, if the disk contains new fault information, a second prompt message is generated to notify the user that the peripheral device has malfunctioned.

[0206] In some embodiments, the second prompt message may be displayed to the user on the user interface of the electronic device.

[0207] For example, such as Figure 7 As shown, a second prompt message, "Front-facing camera module malfunction, please go to a nearby store for repair as soon as possible," can be displayed on the user interface of the electronic device. After displaying the second prompt message, the user is aware that the front-facing camera module has malfunctioned, allowing them to back up the data on their electronic device in a timely manner and go to a nearby store for repair of the front-facing camera module as soon as possible.

[0208] In some embodiments, the second prompt message can be delivered to the user via the electronic device's speaker. For example, after the system enters the Android stage, the system may announce via speaker, "Front-facing camera module malfunction, please go to the nearest store for repair as soon as possible."

[0209] In some embodiments, the second prompt message can be displayed to the user through a combination of displaying it on the user interface of the electronic device and broadcasting it through the electronic device's speaker. For example, after the system enters the Android stage, the second prompt message "Front-facing camera module malfunction, please go to a nearby store for repair as soon as possible" can be displayed on the user interface of the electronic device, and the same message can be broadcast through the speaker.

[0210] In some embodiments, it may be further determined whether the faulty peripheral is a display screen or a speaker. If the faulty peripheral is a display screen, the second prompt message can be delivered to the user via the electronic device's speaker. If the faulty peripheral is a speaker, the second prompt message can be delivered to the user via display on the electronic device's user interface.

[0211] Additionally, during the Android phase, it is also possible to monitor for new peripheral device malfunctions. If a new peripheral device malfunction is detected, the malfunction information is recorded in the memory of the electronic device. For details, please refer to the descriptions of steps S212 and S213, which will not be repeated here.

[0212] In summary, the system recovery method provided in this application isolates faulty peripherals during system restart to ensure that faulty peripherals do not interfere with the normal system startup. Specifically, faulty peripherals can be identified during the UEFI phase and their status in the device tree can be modified to disabled. This prevents the loading of disabled peripheral drivers during the Linux Init phase, thus avoiding loading failures and ensuring that faulty peripherals do not interfere with the normal system startup. After restarting, the user can then access the data in the electronic device.

[0213] It should be noted that the above embodiments are only illustrative examples of the case where the electronic device includes multiple device trees. If the electronic device includes only one device tree, step S210 can be skipped.

[0214] Figure 8 This is a flowchart illustrating a system recovery method provided in an embodiment of this application. Figure 8 As shown, the method may include the following steps:

[0215] S401: Obtain the latest fault information when the electronic device restarts its system.

[0216] S402, Based on the latest fault information, determine the fault type of the electronic device.

[0217] S403, when the fault type is peripheral device fault, identify the faulty peripheral device.

[0218] S404, prevent faulty peripheral devices from starting.

[0219] In one possible implementation, after identifying the faulty peripheral device, the method further includes: if the faulty peripheral device does not include a display screen or a touch sensor, displaying a first prompt message, the first prompt message being used to prompt the user whether to isolate the faulty peripheral device. For details of this implementation, please refer to the description of steps S206-S207, which will not be repeated here.

[0220] In one possible implementation, preventing the faulty peripheral device from starting includes: preventing the faulty peripheral device from starting in response to receiving an isolation confirmation operation input by the user; or, if the faulty peripheral device includes a display screen or a touch sensor, preventing the faulty peripheral device from starting. For details of this implementation, please refer to the description of steps S206-S208, which will not be repeated here.

[0221] In one possible implementation, preventing the startup of a faulty peripheral device includes: obtaining a device tree corresponding to the electronic device; the device tree includes multiple nodes, each node corresponding to a peripheral device in the electronic device; modifying the state of the node corresponding to the faulty peripheral device in the device tree to a disabled state; and starting each peripheral device in the electronic device based on the modified device tree; wherein, faulty peripheral devices in a disabled state are not started. For details of this implementation, please refer to the description of step S208, which will not be repeated here.

[0222] In one possible implementation, before obtaining the device tree corresponding to the electronic device, the method further includes: if the electronic device includes multiple device trees, determining the device tree corresponding to the electronic device from among the multiple device trees; wherein the multiple device trees correspond to different series of electronic devices, and the peripheral device parameters included in different series of electronic devices are different. For details of this implementation, please refer to the description of step S210, which will not be repeated here.

[0223] In one possible implementation, based on the modified device tree, each peripheral device in the electronic device is activated, including: traversing each node in the device tree and activating the peripheral device corresponding to each node based on the state of each node; wherein, the peripheral device corresponding to a node in the activated state is activated, and the peripheral device corresponding to a node in the disabled state is not activated. For details of this implementation, please refer to the description of step S211, which will not be repeated here.

[0224] In one possible implementation, based on the modified device tree, each peripheral device in the electronic device is activated, including: based on the modified device tree and the activation priority of each peripheral device, each peripheral device in the electronic device is activated; wherein, peripheral devices corresponding to nodes in the activated state are activated, and peripheral devices corresponding to nodes in the disabled state are not activated. For details of this implementation, please refer to the description of step S211, which will not be repeated here.

[0225] In one possible implementation, the method further includes: in response to the electronic device's system being in backup file system dump mode, transferring the fault information in the electronic device's memory to a disk. For details of this implementation, please refer to the description of steps S201-S203, which will not be repeated here.

[0226] In one possible implementation, upon system restart, the latest fault information is obtained, including retrieving the latest fault information from the disk. For details of this implementation, please refer to the description of step S204, which will not be repeated here.

[0227] In one possible implementation, the method further includes: after the electronic device restarts its system, determining whether the latest fault information is included in the electronic device's disk; if the latest fault information is included in the electronic device's disk, generating a second prompt message, which is used to notify the user that a faulty peripheral device has malfunctioned. For details of this implementation, please refer to the description of steps S214-S215, which will not be repeated here.

[0228] In one possible implementation, the method further includes: after the electronic device restarts, monitoring whether a new fault occurs in the electronic device; if a new fault is detected, saving the fault information corresponding to the new fault to the memory of the electronic device, and triggering a restart operation. For details of this implementation, please refer to the description of steps S212-S213, which will not be repeated here.

[0229] The various method embodiments described herein can be independent solutions or combinations based on internal logic, and all such solutions fall within the protection scope of this application.

[0230] It is understood that the methods and operations implemented by electronic devices in the above-described method embodiments can also be implemented by components (such as chips, modules, or circuits) that can be used in electronic devices.

[0231] The above embodiments describe the system recovery method provided in this application. It is understood that, in order to achieve the above functions, the electronic device includes hardware structures and / or software modules corresponding to each function. Those skilled in the art should readily recognize that, based on the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein, this application can be implemented in hardware or a combination of hardware and computer software. Whether a function is executed in hardware or by computer software driving hardware depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0232] The above, combined with Figures 1 to 8 The system recovery method provided in the embodiments of this application is described in detail below. Figure 9 The apparatus provided in the embodiments of this application is described in detail. It should be understood that the description of the apparatus embodiments corresponds to the description of the method embodiments. Therefore, for content not described in detail, please refer to the method embodiments above. For the sake of brevity, it will not be repeated here.

[0233] This application also provides a processing apparatus, which includes at least one processor and a communication interface. The communication interface is used to provide information input and / or output to the at least one processor, which is used to execute the methods described in the above method embodiments.

[0234] It should be understood that the aforementioned processing device can be a chip. For example, see Figure 9 , Figure 9 This is a structural block diagram of a chip provided in an embodiment of this application. Figure 9 The chip shown can be a general-purpose processor or a special-purpose processor. The chip 500 may include at least one processor 501. The at least one processor 501 can be used to execute... Figures 1 to 8 The technical solution shown in any one of the embodiments.

[0235] Optionally, the chip 500 may also include a transceiver 502, which is used to receive control from the processor 501 for performing... Figures 1 to 8 The technical solution shown in any of the embodiments. Optionally, Figure 9 The chip 500 shown may also include a storage medium 503. Specifically, the transceiver 502 may be replaced by a communication interface that provides information input and / or output to the at least one processor 501.

[0236] It should be noted that, Figure 9 The chip 500 shown can be implemented using the following circuits or devices: one or more field programmable gate arrays (FPGAs), programmable logic devices (PLDs), application-specific integrated circuits (ASICs), system-on-chips (SoCs), central processors (CPUs), network processors (NPs), digital signal processors (DSPs), microcontrollers (MCUs), controllers, state machines, gate logic, discrete hardware components, any other suitable circuits, or any combination of circuits capable of performing the various functions described throughout this application.

[0237] In implementation, each step of the above method can be completed by integrated logic circuits in the processor's hardware or by instructions in software. The steps of the method disclosed in the embodiments of this application can be directly implemented by a hardware processor, or by a combination of hardware and software modules in the processor. The software modules can reside in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. This storage medium is located in memory, and the processor reads information from the memory and, in conjunction with its hardware, completes the steps of the above method. To avoid repetition, detailed descriptions are omitted here.

[0238] It is understood that the memory in the embodiments of this application can be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. The non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. The volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous linked dynamic random access memory (SLDRAM), and direct rambus RAM (DR RAM). It should be noted that the memory used in the systems and methods described herein is intended to include, but is not limited to, these and any other suitable types of memory.

[0239] According to the method provided in the embodiments of this application, the embodiments of this application also provide a computer program product, which includes: a computer program or instructions, which, when executed on a computer, cause the computer to perform... Figures 1 to 8 The method of any one of the embodiments shown.

[0240] According to the method provided in the embodiments of this application, the embodiments of this application also provide a computer storage medium storing a computer program or instructions, which, when executed on a computer, cause the computer to perform... Figures 1 to 8 The method of any one of the embodiments shown.

[0241] Based on the method provided in the embodiments of this application, this application also provides an electronic device. The electronic device includes a memory and a processor; the memory and the processor are coupled; the memory stores computer program code, which includes computer instructions. When the processor executes the computer instructions, the electronic device performs the system recovery method provided in the above embodiments.

[0242] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, device modules, and electronic devices described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0243] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of modules is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple modules or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be an indirect coupling or communication connection through some interfaces, devices, or units, and may be electrical, mechanical, or other forms.

[0244] The modules described as separate components may or may not be physically separate. The components shown as modules may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0245] In addition, the functional modules in the various embodiments of this application can be integrated into one processing unit, or each module can exist physically separately, or two or more modules can be integrated into one unit.

[0246] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0247] The device, system, processing device, chip, computer storage medium, computer program product, and electronic device for determining the photo duration provided in the above-described embodiments of this application are all used to execute the method provided above. Therefore, the beneficial effects they can achieve can be referred to the beneficial effects corresponding to the method provided above, and will not be repeated here.

[0248] It should be understood that in the various embodiments of this application, the execution order of each step should be determined by its function and internal logic, and the size of each step number does not mean the order of execution, and does not constitute a limitation on the implementation process of the embodiments.

[0249] The various parts of this specification are described in a progressive manner. Similar or identical parts between the various embodiments can be referred to interchangeably. Each embodiment focuses on the differences from other embodiments. In particular, the embodiments for the device, system, chip, computer storage medium, computer program product, and electronic device for determining the photographing duration are basically similar to the method embodiments, so the descriptions are relatively simple, and relevant details can be found in the descriptions within the method embodiments.

[0250] Although preferred embodiments of this application have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of this application.

[0251] The embodiments described above do not constitute a limitation on the scope of protection of this application.

Claims

1. A system recovery method, characterized by, The method is applied to an electronic device, and the method includes: When the electronic device restarts, obtain the latest fault information; Based on the latest fault information, determine the fault type of the electronic device; In the case where the fault type is a peripheral device fault, the faulty peripheral device is identified; Preventing the faulty peripheral device from starting includes: Obtain the device tree corresponding to the electronic device; the device tree includes multiple nodes, and the multiple nodes correspond to each peripheral device in the electronic device; Modify the status of the node corresponding to the faulty peripheral device in the device tree to a disabled state; Based on the modified device tree, each peripheral device in the electronic device is activated; wherein, faulty peripheral devices that are disabled are not activated. After identifying the faulty peripheral device, the method further includes: If the faulty peripheral device does not include a display screen or a touch sensor, a first prompt message is displayed, which prompts the user whether to isolate the faulty peripheral device. In response to the electronic device's system being in backup file system dump mode, the fault information in the electronic device's memory is transferred to the disk; When the electronic device restarts, the latest fault information is obtained, including: When the electronic device restarts, the latest fault information is retrieved from the disk.

2. The method of claim 1, wherein, The method of preventing the faulty peripheral device from starting includes: In response to receiving an isolation confirmation operation from the user, the faulty peripheral device is prevented from starting; or, If the faulty peripheral device includes a display screen or a touch sensor, the faulty peripheral device shall be prevented from starting.

3. The method of claim 1, wherein, Before obtaining the device tree corresponding to the electronic device, the method further includes: When the electronic device includes multiple device trees, a device tree corresponding to the electronic device is determined from among the multiple device trees; wherein, the multiple device trees correspond to different series of electronic devices, and the peripheral device parameters corresponding to different series of electronic devices are different.

4. The method of claim 1, wherein, The step of activating the peripheral devices in the electronic device based on the modified device tree includes: Traverse each node in the device tree and start the peripheral device corresponding to each node based on the state of each node; wherein, the peripheral device corresponding to the node in the started state is started, and the peripheral device corresponding to the node in the disabled state is not started.

5. The method of claim 1, wherein, The step of activating each peripheral device in the electronic device based on the modified device tree includes: Based on the modified device tree and the startup priority of each peripheral device, each peripheral device in the electronic device is started; wherein, the peripheral devices corresponding to nodes in the startup state are started, and the peripheral devices corresponding to nodes in the disabled state are not started.

6. The method of claim 1, wherein, The method further includes: After the electronic device's system restarts, determine whether the electronic device's disk contains the latest fault information; If the latest fault information is included in the disk of the electronic device, a second prompt message is generated to notify the user that the faulty peripheral device has malfunctioned.

7. The method of claim 1, wherein, The method further includes: After the electronic device's system restarts, monitor whether the electronic device has malfunctioned; If a malfunction is detected in the electronic device, the malfunction information corresponding to the malfunction is saved to the memory of the electronic device, and a restart operation is triggered.

8. An electronic device, comprising: The electronic device includes a memory and a processor; the memory and the processor are coupled; the memory is used to store computer program code, the computer program code including computer instructions, which, when executed by the processor, cause the electronic device to perform the method as described in any one of claims 1-7.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program or instructions, and when the computer program or instructions are executed, the method as described in any one of claims 1-7 is performed.

Images