Watchdog detection method, device and storage medium

Abstract

The present application provides a watchdog detection method, device and storage medium. In this method, after the system critical task timeout detection watchdog is initialized, the status information of the critical process detected by it is set to a normal mark, that is, it is marked that the critical process is in a normal state and can execute the corresponding business. When the system critical task timeout detection watchdog detects that the action executed by the critical process is not completed within the timeout period, the normal mark is modified to an abnormal mark, and the abnormal mark is sent to the kernel layer's deadlock detection watchdog, triggering the deadlock detection watchdog to perform a reset operation, so that the critical process with the abnormality can return to normal and the device can be used normally.

Description

Technical Field

[0001] The present application relates to the field of communications, and in particular to a watchdog detection method, device, and storage medium. Background Art

[0002] A watchdog, also known as a watchdog timer, is essentially a timer. In practical applications, watchdogs can include both software and hardware watchdogs. Current implementations of both software and hardware watchdogs typically have one input and one output. The input is called "kicking the dog" or "serving the dog," while the output is typically used to reset the business process or hardware it's monitoring when an anomaly occurs, restoring it to normal operation.

[0003] Taking the software watchdog as an example, although the current software watchdog can restore the business process it detects, in actual applications, due to interference from uncontrollable factors, the software watchdog may not be able to successfully reset the business process it detects, or even fail, thus affecting the normal use of the device. Summary of the Invention

[0004] In order to solve the above technical problems, the present application provides a watchdog detection method, device and storage medium, which aim to realize the interaction between the upper-layer software watchdog and the lower-layer software watchdog, so that the upper-layer software watchdog can trigger the lower-layer software watchdog to reset, so that abnormal business processes can be restored to normal regardless of whether the upper-layer software watchdog fails, thereby ensuring that the device can be used normally.

[0005] In the first aspect, the present application provides a watchdog detection method. The method includes: initializing a system critical task timeout detection watchdog, setting the status information identifying the critical process to a normal mark, and the system critical task timeout detection watchdog is used to detect whether the action executed by the critical process started in the application framework layer is completed; after the system critical task timeout detection watchdog detects that the action executed by the critical process calls the start node, it records the execution time of the action executed by the critical process; when the execution time reaches the timeout time corresponding to the action, the system critical task timeout detection watchdog queries whether the end node of the action is called; when the end node is not called, the system critical task timeout detection watchdog changes the status information identifying the critical process from a normal mark to an abnormal mark; the system critical task timeout detection watchdog sends the abnormal mark to the deadlock detection watchdog in the kernel layer, and the deadlock detection watchdog performs a reset operation.

[0006] Therefore, the watchdog detection method provided by the present application, after the system critical task timeout detection watchdog is initialized, sets the status information of the critical process it detects to a normal mark, that is, it indicates that the critical process is in a normal state and can execute the corresponding business, and is set to when the system critical task timeout detection watchdog detects that the action executed by the critical process is not completed within the timeout period, by modifying the normal mark to an abnormal mark, and then sending the abnormal mark to the kernel layer's deadlock detection watchdog, triggering the deadlock detection watchdog to perform a reset operation, so that the critical process with the abnormality can be restored to normal regardless of whether the system critical task timeout detection watchdog can successfully reset the critical process it detects or whether it fails, thereby ensuring that the device can be used normally.

[0007] According to the first aspect, before the system critical task timeout detection watchdog sends the abnormal mark to the deadlock detection watchdog in the kernel layer, the method also includes: the system critical task timeout detection watchdog performs a reset operation; after the reset is successful, the system critical task timeout detection watchdog modifies the status information of the critical process from the abnormal mark to the normal mark, and sends the normal mark to the deadlock detection watchdog in the kernel layer; after the reset fails, the system critical task timeout detection watchdog executes the step of sending the abnormal mark to the deadlock detection watchdog in the kernel layer.

[0008] Exemplarily, the system critical task timeout detection watchdog located at the application framework layer can be regarded as a software watchdog located at the upper layer.

[0009] For example, the deadlock detection watchdog at the kernel layer can be regarded as a software watchdog at the lower layer.

[0010] Exemplarily, when the software watchdog at the upper layer performs a reset operation, the impact on the electronic device is smaller than when the software watchdog at the lower layer performs a reset operation.

[0011] Therefore, in the watchdog detection method provided by the present application, the system critical task timeout detection watchdog at the upper layer first performs a reset operation before notifying the deadlock detection watchdog at the lower layer to perform a reset operation. When the system critical task timeout detection watchdog fails to successfully reset the critical process it detects, it notifies the deadlock detection watchdog at the lower layer to perform a reset operation, so that the reset operation can have as little impact on the operation of the electronic device as possible, thereby ensuring the user experience.

[0012] According to the first aspect, or any implementation method of the first aspect above, after the reset fails, before executing the step of the system critical task timeout detection watchdog sending the abnormal mark to the deadlock detection watchdog in the kernel layer, the method also includes: the system critical task timeout detection watchdog detects the abnormal time length of the status information of the critical process in the abnormal mark; when the abnormal time length is less than the time length threshold, the system critical task timeout detection watchdog re-executes the reset operation; when the abnormal time length is not less than the time length threshold, the system critical task timeout detection watchdog executes the step of sending the abnormal mark to the deadlock detection watchdog in the kernel layer.

[0013] Therefore, the watchdog detection method provided by the present application, when the abnormal duration is less than the duration threshold, for example, when the system critical task timeout detection watchdog corresponds to the 2 detection cycles, gives priority to using the system critical task timeout detection watchdog to perform a reset, that is, the software watchdog of this layer resets the business process it detects, and when the abnormal duration is not less than the duration threshold, notifies the stuck detection watchdog, that is, the lower-layer software watchdog performs a reset, so that the reset operation can have as little impact on the operation of the electronic device as possible, further ensuring the user experience.

[0014] According to the first aspect, or any implementation of the first aspect above, the duration threshold is determined based on the timeout duration, the detection period of the deadlock detection watchdog, and the delay between the application framework layer and the kernel layer.

[0015] Therefore, the watchdog detection method provided in this application, on the basis of considering the detection cycle of the upper-layer software watchdog, further considers the delay problem between the upper-layer software watchdog and the lower-layer software watchdog, thereby making the hierarchical recovery scheme in this application more reasonable.

[0016] According to the first aspect, or any implementation method of the first aspect above, after the reset fails, before executing the step of the system critical task timeout detection watchdog sending the abnormal mark to the deadlock detection watchdog in the kernel layer, the method also includes: the system critical task timeout detection watchdog detects the abnormal duration of the status information of the critical process in the abnormal mark; the system critical task timeout detection watchdog determines the number of timeouts based on the abnormal duration and the timeout duration; when the number of timeouts is less than the number threshold, the system critical task timeout detection watchdog re-executes the reset operation; when the abnormal duration is not less than the number threshold, the system critical task timeout detection watchdog executes the step of sending the abnormal mark to the deadlock detection watchdog in the kernel layer.

[0017] Therefore, the watchdog detection method provided by the present application determines the number of timeouts when the critical process is in an abnormal state. When the number of timeouts is less than the number threshold, the system critical task timeout detection watchdog is used to perform a reset. That is, the software watchdog of this layer resets the business process it detects. When the number of timeouts is not less than the number threshold, the stuck detection watchdog is notified, that is, the software watchdog of the lower layer performs a reset, so that the reset operation can have as little impact on the operation of the electronic device as possible, further ensuring the user experience.

[0018] According to the first aspect, or any implementation method of the above first aspect, the system critical task timeout detection watchdog sends the abnormal mark to the deadlock detection watchdog in the kernel layer, and the deadlock detection watchdog performs the reset operation, including: the system critical task timeout detection watchdog sends the abnormal mark to the pre-packaged public node in the kernel layer, and the public node is used to decide whether the deadlock detection watchdog performs the reset operation; the public node determines to perform the reset operation based on the abnormal mark and the preset strategy; when it is determined to perform the reset operation, the deadlock detection watchdog is notified to perform the reset operation.

[0019] Therefore, the watchdog detection method provided by the present application pre-encapsulates a common node that can decide whether the lower-level software watchdog should perform the reset when the upper-level software watchdog fails to successfully reset the abnormal business process. The common node uniformly receives status marks sent by different upper-level software watchdogs to identify the business process / actions performed by the upper-level software watchdog detection. By analyzing and deciding the status marks according to preset strategies, the deadlock detection watchdog is notified to perform the reset only when it is determined that the deadlock detection watchdog needs to perform the reset, making the hierarchical recovery scheme in the present application more reasonable.

[0020] According to the first aspect, or any implementation of the first aspect above, when the end node is called, detection of actions executed by the critical process is stopped.

[0021] Therefore, the watchdog detection method provided by the present application sets the system critical task timeout detection watchdog to stop detecting the actions executed by the critical process after determining that the receiving node is called, that is, the action executed by the critical process is completed normally, thereby greatly saving the overhead of electronic equipment resources.

[0022] According to the first aspect, or any implementation of the first aspect above, initializing the system critical task timeout detection watchdog includes: initializing the system critical task timeout detection watchdog during the process of starting the critical process.

[0023] Therefore, the watchdog detection method provided by this application initializes the system critical task timeout detection watchdog during the process of starting the critical process, ensuring that the critical detection watchdog can start detection in time when the function corresponding to the action executed by the critical process is called.

[0024] According to the first aspect, or any implementation of the first aspect above, the system critical task timeout detection watchdog is initialized, and the method also includes: when starting the critical process and calling the function corresponding to the action executed by the critical process, the system critical task timeout detection watchdog is initialized.

[0025] Therefore, the watchdog detection method provided by this application initializes the system critical task timeout detection watchdog only when the function corresponding to the action executed by the critical process is called, so that it can determine which actions need to be detected by the system critical task timeout detection watchdog according to business needs, and better adapt to various application scenarios.

[0026] According to the first aspect, or any implementation method of the first aspect above, when starting a critical process and calling the function corresponding to the action executed by the critical process, the system critical task timeout detection watchdog is initialized, and the method also includes: setting a hierarchical recovery mark for the function corresponding to the action executed by the critical process; wherein the hierarchical recovery mark is used to identify that when the status information of the critical process is an abnormal mark, the system critical task timeout detection watchdog notifies the stuck detection watchdog to perform a reset operation.

[0027] Therefore, the watchdog detection method provided by the present application can, by setting a hierarchical recovery mark, select the hierarchical recovery solution provided by the present application according to business needs in actual applications, thereby better meeting user needs.

[0028] In a second aspect, the present application provides an electronic device comprising: one or more processors, a memory, and one or more computer programs; wherein the one or more computer programs are stored on the memory, and when the computer programs are executed by the one or more processors, the electronic device executes instructions of the method in the first aspect or any possible implementation of the first aspect.

[0029] In a third aspect, the present application provides a computer-readable medium for storing a computer program, wherein the computer program includes instructions for executing the method in the first aspect or any possible implementation of the first aspect.

[0030] In a fourth aspect, the present application provides a computer program comprising instructions for executing the method in the first aspect or any possible implementation of the first aspect.

[0031] In a fifth aspect, the present application provides a chip comprising a processing circuit and a transceiver pin. The transceiver pin and the processing circuit communicate with each other via an internal connection path, and the processing circuit executes the method of the first aspect or any possible implementation of the first aspect to control the receive pin to receive a signal and to control the transmit pin to send a signal. BRIEF DESCRIPTION OF THE DRAWINGS

[0032] Figure 1 is a schematic diagram of the hardware structure of an electronic device shown as an example;

[0033] Figure 2 is a schematic diagram of the software structure of an electronic device shown as an example;

[0034] Figure 3 A schematic diagram of a system architecture corresponding to the watchdog detection method provided in an embodiment of the present application is exemplified;

[0035] Figure 4 One of the flowcharts of the watchdog detection method provided in an embodiment of the present application is exemplified;

[0036] Figure 5 For Figure 4 Schematic diagram of application scenarios to which the watchdog detection method is applicable;

[0037] Figure 6 The second flowchart of the watchdog detection method provided by the embodiment of the present application is exemplified;

[0038] Figure 7 For Figure 6 Schematic diagram of application scenarios to which the watchdog detection method is applicable;

[0039] Figure 8 The third flowchart of the watchdog detection method provided by the embodiment of the present application is exemplified;

[0040] Figure 9 For Figure 8 Schematic diagram of application scenario three to which the watchdog detection method is applicable;

[0041] Figure 10 is another schematic diagram exemplarily illustrating an application scenario to which the watchdog detection method is applicable;

[0042] Figure 11 is another schematic diagram exemplarily illustrating an application scenario to which the watchdog detection method is applicable;

[0043] Figure 12 This is one of the schematic diagrams for exemplarily showing CPU core status detection;

[0044] Figure 13 This is a second schematic diagram illustrating an exemplary CPU core status detection;

[0045] Figure 14 This is another schematic diagram illustrating an application scenario to which the watchdog detection method is applicable. DETAILED DESCRIPTION

[0046] The following will be combined with the drawings in the embodiments of this application to clearly and completely describe the technical solutions in the embodiments of this application. Obviously, the embodiments described are part of the embodiments of this application, not all of them. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

[0047] The term "and / or" in this article is merely a description of the association relationship between associated objects, indicating that three relationships may exist. For example, A and / or B can mean: A exists alone, A and B exist at the same time, and B exists alone.

[0048] In the description and claims of the embodiments of this application, the terms "first" and "second" are used to distinguish different objects, rather than to describe a specific order of objects. For example, the terms "first target object" and "second target object" are used to distinguish different objects, rather than to describe a specific order of objects.

[0049] In the embodiments of this application, words such as "exemplary" or "for example" are used to indicate examples, illustrations, or descriptions. Any embodiment or design described as "exemplary" or "for example" in the embodiments of this application should not be interpreted as being preferred or advantageous over other embodiments or designs. Rather, the use of words such as "exemplary" or "for example" is intended to present the relevant concepts in a concrete manner.

[0050] In the description of the embodiments of this application, unless otherwise specified, "multiple" means two or more. For example, "multiple processing units" means two or more processing units; "multiple systems" means two or more systems.

[0051] Before describing the technical solutions of the embodiments of the present application, the hardware structure and software structure of the electronic device to which the embodiments of the present application are applicable are first described with reference to the accompanying drawings.

[0052] See also Figure 1 , Figure 1 Schematic diagram of the hardware structure of the electronic device 100.

[0053] Optionally, the electronic device 100 may be a terminal, which may also be referred to as a terminal device. The terminal may be a cellular phone or a tablet computer, etc., which is not limited in this application.

[0054] Continue to see Figure 1 The electronic device 100 may include: a processor 110, an external memory interface 120, an internal memory 121, a universal serial bus (USB) interface 130, a charging management module 140, a power management module 141, a battery 142, an antenna 1, an antenna 2, a mobile communication module 150, a wireless communication module 160, an audio module 170, a speaker 170A, a receiver 170B, a microphone 170C, an earphone interface 170D, a sensor module 180, a button 190, a motor 191, an indicator 192, a camera 193, a display 194, and a subscriber identification module (SIM) card interface 195. The sensor module 180 may include a pressure sensor, a gyroscope sensor, an air pressure sensor, a magnetic sensor, an acceleration sensor, a distance sensor, a proximity light sensor, a fingerprint sensor, a temperature sensor, a touch sensor, an ambient light sensor, a bone conduction sensor, and the like.

[0055] The processor 110 may include one or more processing units. For example, the processor 110 may include an application processor (AP), a modem processor, a graphics processing unit (GPU), an image signal processor (ISP), a controller, a memory, a video codec, a digital signal processor (DSP), a baseband processor, and / or a neural-network processing unit (NPU). The different processing units may be independent devices or integrated into one or more processors.

[0056] The controller may be the nerve center and command center of the electronic device 100. The controller may generate an operation control signal according to the instruction operation code and the timing signal to complete the control of fetching and executing instructions.

[0057] The processor 110 may also be provided with a memory for storing instructions and data. In some embodiments, the processor 110 may include one or more interfaces, such as a PCM interface, a universal serial bus (USB) interface, etc. The PCM interface may 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 may be coupled via a PCM bus interface. In some embodiments, the audio module 170 may also transmit audio signals to the wireless communication module 160 via the PCM interface, thereby enabling the function of answering calls via a Bluetooth headset. Both the I2S interface and the PCM interface may be used for audio communication. The USB interface 130 is an interface that complies with USB standard specifications, and may specifically be a Mini USB interface, a Micro USB interface, a USB Type C interface, etc. The USB interface 130 may be used to connect a charger to charge the electronic device 100, or to transmit data between the electronic device 100 and peripheral devices. It may also be used to connect headphones to play audio through the headphones. This interface may also be used to connect other electronic devices, such as AR devices.

[0058] Furthermore, it should be noted that in some embodiments, the processor 110 may include a built-in hardware watchdog. For example, a timer in the processor 110 may be used as the hardware watchdog. The processor 110 is initialized by a program, with initial values ​​written to it, and the timer is started to monitor the processor 110. If an error occurs in the processor 110, the timer sends a restart signal to the processor 110.

[0059] In addition, in some other embodiments, an independent watchdog chip can be provided in the electronic device 100 as a hardware watchdog for detecting the processor 110. The watchdog chip mainly includes a watchdog feeding pin (generally connected to the general purpose input / output (GPIO) of the processor 110) and a reset pin (connected to the reset / reset (RESET) pin of the processor 110). If the processor 110 does not change the level of the watchdog feeding pin within a certain period of time, the reset pin will change state to reset the processor 110.

[0060] The charging management module 140 is configured to receive charging input from a charger. While charging the battery 142, the charging management module 140 can also power the electronic device through the power management module 141. The power management module 141 is configured to connect the battery 142, the charging management module 140, and the processor 110. The power management module 141 receives input from the battery 142 and / or the charging management module 140 to power the processor 110, the internal memory 121, the external memory, the display 194, the camera 193, and the wireless communication module 160.

[0061] The wireless communication function of the electronic device 100 can be implemented through antenna 1, antenna 2, mobile communication module 150, wireless communication module 160, modem processor and baseband processor. Antenna 1 and antenna 2 are used to transmit and receive electromagnetic wave signals. Mobile communication module 150 can provide wireless communication solutions including 2G / 3G / 4G / 5G applied to the electronic device 100. Wireless communication module 160 can provide wireless communication solutions including wireless local area networks (WLAN) (such as wireless fidelity (Wi-Fi) network), Bluetooth (BT), global navigation satellite system (GNSS), frequency modulation (FM), near field communication technology (NFC), infrared technology (IR) applied to the electronic device 100. In some embodiments, the antenna 1 of the electronic device 100 is coupled to the mobile communication module 150, and the antenna 2 is coupled to the wireless communication module 160, so that the electronic device 100 can communicate with the network and other devices through wireless communication technology.

[0062] The electronic device 100 implements display functions through a GPU, a display screen 194 , and an application processor. The display screen 194 is used to display images, videos, etc. In some embodiments, the electronic device 100 may include one or N display screens 194 , where N is a positive integer greater than one.

[0063] The electronic device 100 can implement a camera function through an ISP, a camera 193, a video codec, a GPU, a display 194, and an application processor. The camera 193 is used to capture still images or videos. In some embodiments, the electronic device 100 may include one or N cameras 193, where N is a positive integer greater than one.

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

[0065] The external memory interface 120 can be used to connect an external memory card, such as a Micro SD card, to expand the storage capacity of the electronic device 100. The external memory card communicates with the processor 110 via the external memory interface 120 to implement data storage functions. For example, files such as music and videos can be stored on the external memory card.

[0066] The internal memory 121 can be used to store computer executable program code, which includes instructions. The processor 110 executes various functional applications and data processing of the electronic device 100 by running the instructions stored in the internal memory 121, so that the electronic device 100 implements the watchdog detection method in the embodiment of the present application. The internal memory 121 may include a program storage area and a data storage area. Among them, the program storage area can store an operating system, an application required for at least one function (such as a sound playback function, an image playback function, etc.), etc. The data storage area can store data created during the use of the electronic device 100 (such as audio data, a phone book, etc.), etc.

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

[0068] The audio module 170 is used to convert digital audio information into analog audio signal output, and is also used to convert analog audio input into digital audio signals. The audio module 170 can also be used to encode and decode audio signals. In some embodiments, the audio module 170 can be provided in the processor 110, or some functional modules of the audio module 170 can be provided in the processor 110.

[0069] The speaker 170A, also called a "speaker", is used to convert audio electrical signals into sound signals. The electronic device 100 can listen to music or listen to hands-free calls through the speaker 170A.

[0070] The receiver 170B, also called a "handset", is used to convert audio electrical signals into sound signals. When the electronic device 100 receives a call or a voice message, the user can place the receiver 170B close to the ear to hear the voice.

[0071] Microphone 170C, also called "microphone" or "microphone", is used to convert sound signals into electrical signals.

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

[0073] The pressure sensor is used to sense pressure signals and convert them into electrical signals. In some embodiments, the pressure sensor can be provided on the display screen 194. In some embodiments, touch operations at the same touch location but with different touch operation intensities can correspond to different operation instructions.

[0074] A touch sensor, also known as a "touch panel," can be provided on display screen 194. The touch sensor and display screen 194 together form a touch screen, also known as a "touch screen." The touch sensor is used to detect touch operations applied to or near the touch sensor. The touch sensor can transmit the detected touch operations 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.

[0075] The keys 190 include a power key, a volume key, etc. The electronic device 100 can receive key inputs and generate key signal inputs related to user settings and function controls of the electronic device 100 .

[0076] This concludes the introduction to the hardware structure of the electronic device 100. It should be understood that Figure 1 The electronic device 100 shown is only an example. In a specific implementation, the electronic device 100 may have more or fewer components than those shown in the figure, may combine two or more components, or may have a different component configuration. Figure 1 The various components shown in the drawings may be implemented in hardware, software, or a combination of hardware and software, including one or more signal processing and / or application specific integrated circuits.

[0077] Regarding the software structure of the electronic device, this application still uses Figure 1 The electronic device 100 shown is taken as an example. Figure 2 The software structure of the electronic device 100 is described. Before describing the software structure of the electronic device 100, the architecture that can be adopted by the software system of the electronic device 100 is first described.

[0078] Specifically, in actual applications, the software system of the electronic device 100 may adopt a layered architecture, an event-driven architecture, a micro-kernel architecture, a micro-service architecture, or a cloud architecture.

[0079] In addition, it is understandable that the software systems used by current mainstream electronic devices include but are not limited to Windows systems, Android systems, and iOS systems. For ease of explanation, the embodiment of the present application takes the layered architecture Android system as an example to exemplify the software structure of the electronic device 100.

[0080] In addition, the subsequent description of the watchdog detection solution provided in the embodiment of the present application and the electronic devices involved are all based on the Android system as an example. However, in specific implementations, the watchdog detection solution provided in the embodiment of the present application is also applicable to other systems.

[0081] See also Figure 2 , Figure 2 This is a software structure block diagram of the electronic device 100 according to an embodiment of the present application.

[0082] The layered architecture of electronic device 100 divides the software into several layers, each with a clear role and division of labor. Layers communicate with each other via software interfaces. In some embodiments, the Android system is divided into three layers: the application layer, the application framework layer, and the kernel layer, from top to bottom.

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

[0084] like Figure 2 As shown, the application package may include applications such as camera, gallery, calendar, call, map, navigation, music, video, short message, etc.

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

[0086] like Figure 2 As shown, the application framework layer may include system services (System Server), system service watchdog (System Server WatchDog), layer integrator (SurfaceFlinger), system critical task timeout detection watchdog (Xcollie), initialization service (Init), initialization service watchdog (Init watchdog), etc.

[0087] The System Server provides basic Android services and is a fundamental requirement for the Android system to operate. Several services reside in the System Server, including common ones such as WMS (Window Manager Server), AMS (Activity Manager System Service), and PMS (Package Manager Server). These services exist as threads within the System Server process.

[0088] System Server WatchDog detects deadlocks, unresponsiveness, and other issues in the System Server. When a System Server failure occurs, System Server WatchDog kills the System Server process, performing a soft restart and self-recovery. System Server WatchDog detects two main types of objects: object locks and thread handlers.

[0089] The System Server WatchDog is initialized and started in the System Server process. When the System Server is started, various Android services are registered and started, including the initialization and startup of the System Server WatchDog.

[0090] The System Server periodically checks whether key services, such as AMS and WMS, are operating normally. If the System Server detects that these services are operating normally, it feeds the System Server WatchDog. If the System Server detects that any of these services are not operating normally, it does not feed the System Server WatchDog. If the System Server fails to feed the System Server WatchDog for multiple (e.g., three) consecutive cycles, the System Server WatchDog resets the System Server process.

[0091] SurfaceFlinger is launched in the System Server process and is responsible for unified management of the device's frame buffer. During startup, SurfaceFlinger creates two threads: one for detecting console events and the other for rendering the system's UI. Specifically, SurfaceFlinger manages the display subsystem and provides fusion of 2D and 3D layers for multiple applications.

[0092] In some implementations, SurfaceFlinger may also be provided in the system library of the Android system, which is not limited in this application.

[0093] The system's critical task timeout detection watchdog (Xcollie) is used to detect the completion of actions executed in critical processes. Xcollie can be configured with two threads: one thread sets the critical process's status to normal when the critical thread begins executing an action, and determines whether to set the critical process's status to abnormal based on whether the critical process's execution has timed out. The other thread polls the status of each critical process and resets the critical process if its status is marked as abnormal.

[0094] For example, the key processes may be SurfaceFlinger, Vold (volume Daemon), AudioFlinger, Face Regconize (face recognition), and the like.

[0095] Vold, the Volume daemon, manages hot-plugging and unplugging of storage devices in Android. AudioFlinger, the executor of audio system policies, is responsible for managing audio streaming devices and processing and transmitting audio streaming data. Face Regconize implements facial recognition and verification.

[0096] Init is the first process in the Linux user space, and therefore the first process in the Linux kernel-based Android user space. The Init process is primarily responsible for parsing property files and initializing properties, parsing the init.rc script, triggering actions and starting services, providing system property service management and completing corresponding triggering events, and maintaining system-level services.

[0097] The Init watchdog is used to detect the Init process and reset the Init process if it is abnormal.

[0098] Furthermore, it should be understood that the kernel layer is a layer between hardware and software.

[0099] like Figure 2 As shown, the kernel layer at least includes a hung detect watchdog and a CPU core status watchdog.

[0100] Among them, the Hungdetect watchdog is used to detect the kernel system and control the kernel restart when a kernel error (Kernel Panic) occurs.

[0101] In this embodiment, the Hungdetect watchdog is also used to detect the System Server WatchDog, Xcollie and Init watchdogs, and control the kernel to restart when any of the System Server WatchDog, Xcollie and Init watchdogs fails, or the services detected by any of the System Server WatchDog, Xcollie and Init watchdogs cannot be restored.

[0102] The CPU core status watchdog is used to detect the operating status of each CPU core and control the core restart when the CPU core status meets the preset core restart conditions.

[0103] In this embodiment, the hardware watchdog can also detect the Hungdetect watchdog and the CPU core status watchdog, and control the entire machine to restart when either the Hungdetect watchdog or the CPU core status watchdog fails, or the Hungdetect watchdog and the CPU core status watchdog cannot successfully restart the kernel.

[0104] In this embodiment, the hardware watchdog can also monitor the Hungdetect watchdog and the CPU core status watchdog, for example, monitoring the reset action of the Hungdetect watchdog and the CPU core status watchdog. In particular, if either the Hungdetect watchdog or the CPU core status watchdog fails, or the Hungdetect watchdog and the CPU core status watchdog cannot successfully restart the kernel, the hardware watchdog can control the entire machine to restart.

[0105] Exemplarily, the kernel layer may further include a software watchdog (referred to herein as a hungtast watchdog) for detecting whether a process is in a D (uninterruptible sleep, uninterruptible deep sleep) state.

[0106] Correspondingly, in practical applications, the hardware watchdog can also detect the hungtast watchdog.

[0107] It is understandable that regarding the detection of the hungtast watchdog by the hardware watchdog, you can refer to the detection of the hungdetect watchdog by the hardware watchdog mentioned above, which will not be repeated here.

[0108] This concludes the introduction to the software structure of the electronic device 100. It is understood that Figure 2 The layers in the illustrated software structure and the components contained in each layer do not constitute a specific limitation on the electronic device 100. In other embodiments of the present application, the electronic device 100 may include more or fewer layers than shown, and each layer may include more or fewer components, which is not limited in the present application.

[0109] It is understandable that in order to implement the watchdog detection method in this application, the electronic device includes hardware and / or software modules that perform the corresponding functions. In combination with the algorithm steps of each example described in the embodiments disclosed herein, this application can be implemented in the form of hardware or a combination of hardware and computer software. Whether a function is executed in the form of hardware or computer software driving hardware depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application in combination with the embodiments, but such implementation should not be considered to be beyond the scope of this application.

[0110] Based on the above hardware and software structures, the present application provides a watchdog detection method capable of achieving hierarchical recovery. Specifically, in this watchdog detection method, the watchdog at the lower layer of the electronic device can not only detect whether the service at this layer is abnormal and reset the service at this layer when the service at this layer is abnormal, but can also detect the upper layer watchdog and reset the service at this layer when the upper layer watchdog fails or is unable to restore the upper layer service, thereby achieving recovery of the upper layer service.

[0111] It should be noted that the "layers" involved in this article can be divided according to the software and hardware of the electronic device, or according to the system architecture of the electronic device, and this application does not impose any restrictions on this.

[0112] See also Figure 3 , Figure 3 The following is a diagram of the system architecture provided by the embodiment of the present application. The following uses the first and second layers of an electronic device as an example to explain the watchdog detection method provided by this embodiment. Among them, the first layer is the upper layer of the second layer.

[0113] like Figure 3 As shown, the first layer of the electronic device includes a first watchdog for detecting a first service in the first layer and resetting or restarting the first service when the first service is abnormal.

[0114] For example, when the first service operates normally, the first service periodically performs a first dog feeding operation on the first watchdog. When the first service fails to operate normally, the first service stops the first dog feeding operation on the first watchdog. If the first watchdog does not receive the first dog feeding operation from the first service within one detection cycle or multiple (e.g., three) consecutive detection cycles, the first service is reset or restarted.

[0115] As another example, the first watchdog periodically obtains the first status mark of the first service. When the first service is operating normally, its first status mark indicates that the service is normal; when the first service cannot operate normally, its first status mark indicates that the service is abnormal. For example, when the status mark is "ERROR", it indicates that the service is abnormal; when the status mark is "OK", it indicates that the service is normal. If the first status mark of the first service obtained by the first watchdog indicates that the first service is abnormal, or the first status marks of the first service obtained in multiple consecutive (such as 3) detection cycles all indicate that the first service is abnormal, the first service is reset or restarted.

[0116] like Figure 3 As shown, the second layer of the electronic device includes a second watchdog for detecting the second service in the second layer and resetting or restarting the second service when the second service is abnormal.

[0117] Exemplarily, when the second service operates normally, the second service periodically performs a second dog feeding operation on the second watchdog. When the second service fails to operate normally, the second service stops the second dog feeding operation on the second watchdog. If the second watchdog does not receive the second dog feeding operation of the second service within one detection cycle or multiple (e.g., three) consecutive detection cycles, the second service is reset or restarted.

[0118] In another exemplary embodiment, the second watchdog periodically obtains a second status flag of the second service. When the second service operates normally, its second status flag indicates that the service is normal; when the second service cannot operate normally, its second status flag indicates that the service is abnormal. If the second status flag of the second service obtained by the second watchdog indicates that the second service is abnormal, or if the second status flag of the second service obtained within multiple consecutive (e.g., three) detection cycles indicates that the second service is abnormal, the second watchdog resets or restarts the second service.

[0119] Continue to see Figure 3The second watchdog, in addition to monitoring the second service in the second layer, is also used to monitor the first watchdog and, if the first watchdog fails, reset or restart the second service. After the second service is successfully reset or restarted, the first service in the first layer is reloaded and run, allowing the first service to return to normal operation. A first watchdog failure can mean either the failure of the first watchdog or the inability of the first watchdog to successfully restore or restart the first service.

[0120] Exemplarily, when the first watchdog operates normally and the first service it detects operates normally, the first watchdog periodically performs a third dog feeding operation on the second watchdog. When the first watchdog fails to operate normally, or fails to successfully recover or restart the first service, the first watchdog stops the third dog feeding operation on the second watchdog. If the second watchdog does not receive the third dog feeding operation from the first watchdog within one detection cycle or within multiple (e.g., three) consecutive detection cycles, it resets or restarts the second service.

[0121] As another example, the second watchdog periodically obtains the third status flag of the first watchdog. When the first watchdog operates normally and the first service it detects operates normally, the third status flag of the first watchdog indicates that the service is normal. When the first watchdog fails to operate normally, or fails to successfully restore or restart the first service, the third status flag of the first watchdog indicates that the service is abnormal. If the third status flag of the first watchdog obtained by the second watchdog indicates that the service is abnormal, or if the third status flag of the first watchdog obtained within multiple consecutive (e.g., three) detection cycles all indicate that the service is abnormal, the second watchdog resets or restarts the second service.

[0122] When both the first watchdog and the second watchdog are software watchdogs, the detection period of the second watchdog for the first watchdog is longer than the detection period of the first watchdog for the first service. Optionally, the detection period of the second watchdog for the first watchdog is an integer multiple of the detection period of the first watchdog for the first service, such as 2 times.

[0123] As an optional implementation, the first layer is an application layer of the electronic device, and the second layer is an application framework layer of the electronic device.

[0124] As another optional implementation, the first layer is the application framework layer of the electronic device, and the second layer is the kernel layer of the electronic device.

[0125] As another optional implementation, the first layer is the application kernel layer of the electronic device, and the second layer is the hardware layer of the electronic device, wherein the first service is the kernel system and the second service is the processing chip.

[0126] It should be noted that the second watchdog resets or restarts the second service, which can be triggered by the second service stopping the first dog feeding operation or the status mark of the second service indicating a service abnormality, or by the first watchdog stopping the second dog feeding operation or the status mark of the first watchdog indicating a service abnormality.

[0127] In this way, by setting up a detection mechanism between layers, hierarchical recovery of electronic devices is achieved. Since the second layer is the lower layer of the first layer, the granularity of business recovery or restart in the second layer is greater than the granularity of business recovery or restart in the first layer, so that the success rate of business recovery in the first layer is higher. Among them, when the first watchdog in the first layer of the electronic device cannot successfully restore the first business it detects, the first business in the first layer can be restored through the second layer (that is, the next layer), that is, after resetting or restarting the second business, the first business is reloaded and run, so that the first business in the first layer can be restored to normal. If the second business in the second layer cannot be successfully restored, it can continue to be restored through its next layer (that is, the third layer), thereby avoiding the problem of repeated reset or restart operations in a certain layer of the electronic device without success.

[0128] Based on the above-described hierarchical recovery solution and its implementation, several specific scenarios to which it is applicable are described below.

[0129] Scene 1

[0130] In this scenario, a detection mechanism is set between the application framework layer and the kernel layer of the electronic device. Taking the Hungdetect watchdog in the kernel layer detecting the System Server WatchDog in the application framework layer as an example, the watchdog detection method provided in this application is explained.

[0131] See also Figure 4 , Figure 4 The figure is a flowchart of an exemplary method for executing a watchdog detection method by System Server WatchDog.

[0132] like Figure 4 As shown in the figure, the process of System Server WatchDog executing the watchdog detection method includes:

[0133] Step 101: Initialize the system service watchdog during the process of starting the system service process.

[0134] From the above description, we can know that the system service watchdog, namely System Server WatchDog, is used to detect the system service process in the application framework layer, namely the System Server process, for example, to detect whether the System Server process has deadlocked or is unresponsive.

[0135] Step 102: The system service process detects whether it is operating normally according to a preset period.

[0136] It should be noted that, when the System Server process is started, various Android services are registered and started, such as AMS, WMS, etc. Therefore, the operation in step 102 is, for example, that the system service process periodically checks whether the key services registered and started therein are running normally.

[0137] Accordingly, when these key services are operating normally, it is determined that the system service process is currently operating normally, and step 103 is executed; otherwise, it is determined that the system service process cannot operate normally, and step 105 is executed.

[0138] Step 103: The system service process sends a first dog feeding message to the system service watchdog.

[0139] For example, in some implementations, the first dog-feeding information sent by the system service process to the system service watchdog may be, for example, “kick” mark information, or other agreed information.

[0140] Based on the working principle of the watchdog, when the system service watchdog receives the first dog feeding information sent by the system service process during the dog feeding cycle, it will assume that the system service process is currently operating normally and there is no need to perform a reset operation. That is, after the system service watchdog receives the first dog feeding information, it will not process the system service process.

[0141] Step 104: the system service watchdog sends a second dog feeding message to the deadlock detection watchdog located in the kernel layer.

[0142] For example, in some implementations, the second dog-feeding information sent by the unified service watchdog to the stuck detection watchdog may be, for example, “kick” mark information, or other agreed information.

[0143] Based on the working principle of the watchdog, when the stuck detection watchdog receives the second dog feeding information sent by the system service watchdog during the dog feeding cycle, it will believe that the system service process can currently run normally and there is no need to perform a reset operation. That is, after the stuck detection watchdog receives the second dog feeding information, it will not restart the kernel system.

[0144] This embodiment does not limit the timing of step 103 and step 104.

[0145] Step 105: If the system service watchdog does not receive the first dog feeding message sent by the system service process during the dog feeding cycle, it stops sending the second dog feeding message to the deadlock detection watchdog and performs a reset operation on the system service process.

[0146] Specifically, in some implementations, in order to avoid frequent resetting operations on the system service process, i.e., restarting, and reducing the impact on users' use of electronic devices, the system service watchdog can be set to perform a reset operation on the system service process when it fails to receive the first dog feeding information sent by the system service process during multiple (such as 3) consecutive dog feeding cycles, or within the detection cycle.

[0147] Furthermore, in some implementations, to avoid the situation where the system service process sends a first dog-feeding message but, due to some reasons, such as interference from external factors, the first dog-feeding message does not reach the system service watchdog in time, thereby causing the system service watchdog to mistakenly believe that the system service process has an abnormality and perform a reset operation on the system service process, it can be configured to first trigger the dog barking when the first dog-feeding message from the system service process is not received within n dog-feeding cycles, and then perform the dog bite when the first dog-feeding message from the system service process is not received within (n+1) dog-feeding cycles.

[0148] Exemplarily, n is an integer greater than 0.

[0149] In addition, the dog bite mentioned above triggers the system service watchdog to reset the system service process, while the dog barking is to remind the operation and maintenance personnel to perform maintenance tests on the system.

[0150] Accordingly, in order to facilitate operation and maintenance personnel to perform maintenance and testing on the system and accurately locate abnormal problems, when the dog barks, the system service watchdog can capture the abnormal log through pre-compiled dump logic.

[0151] Furthermore, it should be noted that when the system service watchdog stops sending the second feed message to the jam detection watchdog, if it does not receive the second feed message from the system service watchdog within a preset period, it will be assumed that the system service watchdog has failed to reset the system service process, or that the system service watchdog has failed, meaning it is unable to reset the system service process. In this case, the jam detection watchdog will perform a reset operation, namely, restart the kernel system. Thus, after the kernel successfully restarts, the System Server process will be reloaded and restarted, thus returning to normal operation.

[0152] Furthermore, the jam detection watchdog receives not only the first feed message from the upper-layer system service watchdog but also the third feed message from the kernel system at its own layer. Therefore, in practice, the jam detection watchdog can be triggered to reset if it fails to receive either the second or third feed message within a preset period.

[0153] In addition, since the second dog feeding information and the third dog feeding information come from different objects, the corresponding preset periods may be different. The specific setting method can be set according to actual business needs, and this application does not impose any restrictions on this.

[0154] In addition, it should be noted that, in actual applications, the first dog feeding information may be actively sent by the system service process to the system service watchdog, or may be actively obtained by the system service watchdog from the system service process, which is not limited in this embodiment.

[0155] Correspondingly, the second dog feeding information may be actively sent by the system service watchdog to the jam detection watchdog, or may be actively obtained by the jam detection watchdog from the system service watchdog, which is not limited in this embodiment.

[0156] Correspondingly, the third watchdog feeding information may be actively sent by the kernel system to the jam detection watchdog, or may be actively obtained by the jam detection watchdog from the kernel system, which is not limited in this embodiment.

[0157] Therefore, the watchdog detection method provided in this embodiment connects the SystemServer WatchDog that detects the System Server to the Hungdetect watchdog of the kernel layer. When an abnormality occurs in the System Server WatchDog and the detected business process cannot be restored to normal by resetting, the Hungdetect watchdog of the kernel layer performs a reset operation. Based on the above-mentioned principle of hierarchical recovery, the business process with the abnormality can be restored to normal, thereby ensuring the normal use of the electronic device.

[0158] In order to better understand the implementation of System Server WatchDog access to Hungdetect watchdog, the following is combined Figure 5 Provide specific instructions.

[0159] See also Figure 5 , Figure 5 The figure is a schematic diagram showing an exemplary application scenario.

[0160] like Figure 5As shown, the application framework layer of the electronic device includes System Server WatchDog, which is used to detect the System Server process in the application framework layer, for example, to detect whether the System Server process has deadlocked, is unresponsive, or other problems.

[0161] The System Server process periodically checks whether key services running in its process are operating normally. Key services may be, for example, AMS and WMS. When all key services running in the System Server process are operating normally, the System Server process periodically performs the first dog-feeding operation on the System Server WatchDog. That is, the System Server process periodically sends the aforementioned first dog-feeding information to the System Server WatchDog, or the System Server WatchDog periodically obtains the first dog-feeding information from the System Server process. When any key service running in the System Server process fails to operate normally, the System Server process stops the first dog-feeding operation on the System ServerWatchDog.

[0162] If the System Server WatchDog does not receive the first dog feeding operation of the System Server process within one detection cycle or multiple (such as three) consecutive detection cycles, the System Server WatchDog restarts the System Server process.

[0163] like Figure 5 As shown, the kernel layer of the electronic device includes a Hungdetect watchdog for detecting whether the kernel system is operating normally.

[0164] Among them, when the kernel system operates normally, the kernel system regularly performs the second dog feeding operation on the Hungdetect watchdog, that is, the kernel system regularly sends the third dog feeding information mentioned above to the Hungdetect watchdog, or the Hungdetect watchdog regularly obtains the third dog feeding information from the kernel system. When the kernel system fails to operate normally, the kernel system stops the second dog feeding operation on the Hungdetect watchdog.

[0165] If the Hungdetect watchdog does not receive the second feeding operation of the kernel system within one detection cycle or multiple (such as 3) consecutive detection cycles, the kernel system will be restarted.

[0166] Continue to see Figure 5In addition to monitoring the kernel system, the Hungdetect watchdog can also monitor the SystemServer WatchDog. If a SystemServer WatchDog exception occurs, the watchdog will restart the kernel system. After the kernel restarts successfully, the SystemServer process will be reloaded, allowing the SystemServer process to return to normal operation. A SystemServerWatchDog exception can mean that the SystemServerWatchDog has failed, or that the SystemServerWatchDog cannot successfully restart the SystemServer process.

[0167] When System Server WatchDog is running normally and the System Server process it detects is running normally, System Server WatchDog periodically performs the third feeding operation on the Hungdetect watchdog. That is, System Server WatchDog periodically sends the aforementioned second feeding information to the Hungdetect watchdog, or the Hungdetect watchdog periodically obtains the third feeding information from System Server WatchDog. When System Server WatchDog fails to run normally or fails to successfully restart the System Server process, System Server WatchDog stops the third feeding operation on the Hungdetect watchdog.

[0168] If the Hungdetect watchdog does not receive the third feeding operation from the System Server WatchDog within one detection cycle or multiple (e.g., three) consecutive detection cycles, it restarts the kernel system. Furthermore, after the kernel restart is successful, the System Server process will be reloaded and started to restore normal operation.

[0169] The detection period of the Hungdetect watchdog for the System Server WatchDog is longer than the detection period of the SystemServer WatchDog for the System Server process. Optionally, the detection period of the Hungdetect watchdog for the SystemServer WatchDog is an integer multiple of the detection period of the System Server WatchDog for the System Server process. For example, the detection period of the System Server WatchDog for the System Server process is 30 seconds, and the detection period of the Hungdetect watchdog for the System Server WatchDog is 60 seconds.

[0170] In this way, by establishing a detection mechanism between the kernel layer and the application framework layer, hierarchical recovery of electronic devices is achieved. Because the granularity of kernel restarts is greater than that of system server process restarts, kernel restarts can greatly improve the success rate of system server process recovery when the system server process fails to restart successfully. This also avoids the problem of the electronic device's application framework layer repeatedly restarting the system server process but failing.

[0171] Furthermore, it should be noted that in an electronic device restart scenario, the kernel system may successfully boot, but the System Server process may fail to boot. In this case, the kernel's Hungdetect watchdog will continue to check the System Server WatchDog. Since the System Server process failed to boot, the System Server WatchDog cannot feed the Hungdetect watchdog. Consequently, the Hungdetect watchdog will deem the System Server WatchDog abnormal and restart the kernel system again, potentially causing the kernel system to reboot multiple times.

[0172] In order to solve this problem, the present embodiment adjusts the startup time of the Hungdetect watchdog in the kernel layer. Wherein, after the System Server is successfully started, the Hungdetect watchdog will start the monitoring function of the System Server WatchDog, rather than starting after the kernel system is started.

[0173] When the electronic device is initialized and restarted, the System Server will be killed (killed), and the System Server WatchDog will also turn off the dog feeding function. At this time, the System Server WatchDog will no longer feed the Hungdetect watchdog in the kernel layer. The System Server WatchDog will not continue to feed the Hungdetect watchdog until the System Server is successfully restarted.

[0174] During the electronic device initialization process, the kernel system boots first, followed by processes in the application framework layer. When the kernel system initializes, the Hungdetect watchdog in the kernel layer starts, but its monitoring function for the System Server WatchDog is not enabled. When the System Server in the application framework layer initializes, the Hungdetect watchdog in the kernel layer is instructed to start monitoring the System Server WatchDog.

[0175] For example, when the System Server performs an initialization operation, it sends an indication message to the Hungdetect watchdog in the kernel layer, where the indication message is used to indicate that the System Server has been initialized or to instruct the Hungdetect watchdog to start monitoring the System Server Watchdog. Furthermore, based on the indication message, the kernel system starts its monitoring function for the System Server Watchdog to monitor the System Server Watchdog.

[0176] In this way, since the monitoring function of the Hungdetect watchdog on the System Server WatchDog is started after the SystemServer is started, or at least started once successfully, the problem of the Hungdetect watchdog monitoring the System Server WatchDog before the System Server is started can be avoided, and the phenomenon of the Hungdetect watchdog mistakenly thinking that the System Server WatchDog is abnormal before the System Server is started and restarting the kernel system will not occur.

[0177] Scene 2

[0178] In this scenario, a detection mechanism is set between the application framework layer and the kernel layer of the electronic device. Taking the Hungdetect watchdog (stuck detection watchdog) in the kernel layer detecting the system critical task timeout detection watchdog (Xcollie) in the application framework layer as an example, the watchdog detection method provided in this application is explained.

[0179] See also Figure 6 , Figure 6 This is a flowchart illustrating an exemplary method of connecting Xcollie to a Hungdetect watchdog to implement a watchdog detection method.

[0180] like Figure 6 As shown, the watchdog detection method provided in this embodiment specifically includes:

[0181] Step 201 : Initialize a system critical task timeout detection watchdog, and set the status information identifying the critical process to a normal flag.

[0182] Specifically, the key processes mentioned in this embodiment may be, for example, Vold, SurfaceFlinger, AudioFlinger, Face Regconize, etc. mentioned above, which are not listed one by one this time and are not limited in this application.

[0183] In addition, it should be noted that regarding the timing of initializing the system's critical task timeout detection watchdog, in some implementations, it can be initialized during the process of starting the critical process, thereby ensuring that the critical detection watchdog can start detection in time when the function corresponding to the action performed by the critical process is called.

[0184] In addition, from the above description, it can be seen that the system critical task timeout detection watchdog is a resident thread in the critical process, which is used to detect whether the action (action) executed by the critical detection is completed. Taking SurfaceFlinger as an example, the action detected by the system critical task timeout detection watchdog can be, for example, whether the action of rendering the system UI is completed. Therefore, in other implementations, the system critical task timeout detection watchdog can also be initialized when the critical process is started and the function corresponding to the action executed by the critical process is called. In this way, it is possible to determine which actions need to be detected by the system critical task timeout detection watchdog according to business needs, so as to better adapt to various application scenarios.

[0185] In other words, whether to initialize the system critical task timeout detection watchdog and whether the system critical task timeout detection watchdog detects whether the action is executed can be determined according to actual business needs.

[0186] In addition, regarding the above-mentioned process, after the system critical task timeout detection watchdog is successfully initialized, the status information identifying the critical process is set to a normal mark, for example, it can be set to "OK".

[0187] Correspondingly, the abnormal mark mentioned below can be represented by "ERROR", for example.

[0188] In addition, in some implementations, it may be agreed that "1" is used as a normal mark and "0" is used as an abnormal mark as needed.

[0189] It should be understood that the above description is only an example for better understanding the technical solution of this embodiment and is not intended to be the sole limitation of this embodiment. In practical applications, normal marking and abnormal marking can be agreed upon as needed, and this application does not impose any limitation on this.

[0190] Step 202 : After detecting the call start node of the action executed by the critical process, the system critical task timeout detection watchdog records the execution time of the action executed by the critical process.

[0191] It is understandable that in actual applications, the action executed by the key process is specifically implemented by a functional function (or program code, hereinafter collectively referred to as a function) that implements the action, and in the function there will be a start node (begin identifier) ​​that indicates the start of the action and an end node (end identifier) ​​that indicates the end of the action.

[0192] For example, the system critical task timeout detection watchdog can obtain the start time of the action according to the call of the begin flag, and obtain the end time of the action according to the call of the end flag.

[0193] In addition, the timeout period for each action can be reasonably set based on the business characteristics and the time required for the action to be executed normally.

[0194] For example, for an action with a completion time of 5ms (the time from the call start node to the call end node), the timeout period can be 5ms, 8ms, or n*5ms.

[0195] Exemplarily, n is an integer greater than 0.

[0196] It should be understood that the above description is merely an example listed for a better understanding of the technical solution of this embodiment, and is not intended to be the sole limitation on this embodiment.

[0197] Step 203: When the execution duration reaches the timeout duration corresponding to the action, the system key task timeout detects whether the end node of the watchdog query action is called.

[0198] Specifically, if the execution duration reaches the timeout duration corresponding to the action but the end node is not called, that is, if a timeout occurs, step 204 is executed; otherwise, step 206 is executed.

[0199] In step 204 , the system critical task timeout detection watchdog modifies the status information identifying the critical process from a normal mark to an abnormal mark.

[0200] Specifically, when a timeout occurs, it indicates that the action executed by the critical process was not completed. This may be due to an exception in the critical process. Therefore, in order to reset the system's critical task timeout detection watchdog or the critical process deadlock detection watchdog to restore the critical process to normal operation, it is necessary to modify the status information identifying the critical process from a normal mark to an abnormal mark, such as changing "OK" to "ERROR". In this way, after the critical process performs the reset operation and the next initialization is successful, "ERROR" can be changed back to "OK", and the system's critical task timeout detection watchdog can resume detecting the required action.

[0201] In step 205 , the system critical task timeout detection watchdog sends an abnormality flag to the stuck detection watchdog in the kernel layer, and the stuck detection watchdog performs a reset operation.

[0202] It is understandable that, because the application framework layer is located above the kernel layer, the system-critical task timeout detection watchdog located in the application framework has less impact on the electronic device when performing a reset operation than the freeze detection watchdog located in the kernel layer when performing a reset operation. Therefore, in some implementations, the system-critical task timeout detection watchdog may first perform a reset operation before executing step 205.

[0203] For example, if the key detection watchdog is reset successfully, the key process will be restored to normal, and the status information of the key process will be modified from the abnormal mark to the normal mark, and the normal mark will be sent to the deadlock detection watchdog in the kernel layer. In this way, when the preset cycle (dog feeding cycle) is reached, the deadlock detection watchdog will not bark or even bite (that is, perform a reset operation on the kernel system).

[0204] For example, if the key detection watchdog fails to reset successfully, for example, the key process is not restored to normal, or the system key task timeout detection watchdog fails and the key process cannot be reset, step 205 is executed in this case, that is, the lower layer deadlock detection watchdog is used for reset.

[0205] In addition, it should be understood that in actual applications, the granularity of the business recovery or restart performed by the deadlock detection watchdog at the lower layer is greater than the granularity of the business recovery or restart performed by the system critical task timeout detection watchdog at the upper layer, and the impact of the deadlock detection watchdog performing a reset operation on the electronic equipment is greater than the impact of the system critical task timeout detection watchdog performing a reset operation on the electronic equipment. Therefore, the period for triggering the deadlock detection watchdog to perform a reset is usually greater than the period for triggering the system critical task timeout detection watchdog to perform a reset.

[0206] Based on this, in order to better understand in the watchdog detection solution of this embodiment when the system critical task timeout detects the reset operation in the watchdog and when the stuck detection watchdog performs the reset operation, two specific implementation methods are given below.

[0207] Method 1:

[0208] Exemplarily, the system critical task timeout detection watchdog detects that the state information of the critical process is in the abnormal time length marked as abnormal.

[0209] Correspondingly, when the abnormal duration is less than the duration threshold, the system critical task timeout detection watchdog re-executes the reset operation; when the abnormal duration is not less than the duration threshold, the above step 205 is executed.

[0210] It is understandable that regarding the above-mentioned time threshold, in some implementations it can be determined based on the timeout duration of the action in which the timeout occurs, the detection cycle of the deadlock detection watchdog (which can also be understood as the dog feeding cycle) and the delay between the application framework layer and the kernel layer.

[0211] Method 2:

[0212] For example, similar to Method 1, the system critical task timeout detection watchdog can still detect the abnormal duration of the critical process's status information being marked as abnormal. The difference is that in this method, the number of timeouts is determined to determine whether the system critical task timeout detection watchdog continues to perform the reset operation or the deadlock detection watchdog performs the reset operation. Therefore, after obtaining the abnormal duration, the system critical task timeout detection watchdog can determine the number of timeouts based on the abnormal duration and the timeout duration.

[0213] Correspondingly, when the number of timeouts is less than the number threshold, the system critical task timeout detection watchdog re-executes the reset operation; when the abnormal duration is not less than the number threshold, step 205 is executed.

[0214] The setting of the number of timeouts is similar to the setting of the duration threshold. It can be set according to business needs and actual conditions. This application does not impose any restrictions on this.

[0215] It should be understood that the above description is merely an example listed for a better understanding of the technical solution of this embodiment, and is not intended to be the sole limitation on this embodiment.

[0216] Furthermore, it's important to note that in practice, in addition to the system-critical task timeout detection watchdog, the application framework layer also includes system service watchdogs, initialization watchdogs, and other watchdogs for monitoring different business processes. Therefore, to enable the lower-layer jam detection watchdog to detect the various upper-layer watchdogs, a pre-packaged common node can be set up in the kernel layer to determine whether the jam detection watchdog should initiate a reset.

[0217] Accordingly, the system critical task timeout detection watchdog sends an abnormal flag to the deadlock detection watchdog. In this implementation scheme in which a public node is set, the abnormal flag is specifically sent to the public node in the kernel layer.

[0218] Exemplarily, a preset policy is pre-installed in the public node, namely, a policy for determining whether the jam detection watchdog should perform a reset operation. Therefore, upon receiving an abnormality flag from an upper-layer watchdog, such as the system-critical task timeout detection watchdog described in this embodiment, the public node determines whether the jam detection watchdog should perform a reset operation based on the abnormality flag and the preset policy.

[0219] Accordingly, when the common node determines that the jam detection watchdog needs to perform a reset operation through processing, it notifies the jam detection watchdog to perform a reset operation.

[0220] For example, in some implementations, when the public node determines that a reset operation needs to be performed by the deadlock detection watchdog, it can actively send a reset instruction to the deadlock detection watchdog, or the deadlock detection watchdog can periodically obtain instruction information decided by the public node from the public node, and then perform a reset operation when the reset instruction is obtained.

[0221] In addition, it should be noted that in order to make the technical solution provided in this embodiment applicable to more application scenarios and meet different business needs, in actual applications, it is possible to identify which actions have abnormal execution processes according to business needs, and reset them with the help of the lower-level deadlock detection watchdog.

[0222] For example, the above operation can be performed by setting a hierarchical recovery flag for the function corresponding to the action executed by the critical process when starting a critical process and calling the function corresponding to the action executed by the critical process, and when initializing the system critical task timeout detection watchdog. In this way, if the status information of the critical process is abnormal and the action executed by the critical process is set with a hierarchical recovery flag, the system critical task timeout detection watchdog will notify the deadlock detection watchdog to perform a reset operation.

[0223] It should be noted that the aforementioned hierarchical recovery mark can be set as needed in actual applications and is not restricted at this time.

[0224] For example, in some implementations, the system critical task timeout detection watchdog can only send the exception mark of the critical process corresponding to the action with the hierarchical recovery mark set to the deadlock detection watchdog. In this way, after the deadlock detection watchdog receives the exception mark, or the public node receives the exception mark, it does not need to consider whether the critical process corresponding to the exception mark has the hierarchical recovery mark set. By default, all received ones have the hierarchical recovery mark set, that is, the deadlock detection watchdog intervenes.

[0225] For example, in other implementations, the system critical task timeout detection watchdog may not distinguish whether the critical process has a hierarchical recovery mark set. When it detects that the status information identifying the critical process has changed, it directly sends the status information identifying the critical process and other marking information set for the critical process, such as the hierarchical recovery mark, to the lower-level public node or the deadlock detection watchdog, which will identify whether intervention is needed.

[0226] It should be understood that the above description is merely an example listed for a better understanding of the technical solution of this embodiment, and is not intended to be the sole limitation on this embodiment.

[0227] Step 206: Stop detecting actions executed by the critical process.

[0228] It is understandable that in actual applications, the changes in key process states are shown in Table 1.

[0229] Table 1 Key process status change table

[0230] Scenario state Initialization (init) normal Execution ends (end) normal Execution timeout (Timeout) abnormal

[0231] That is to say, within the timeout period, if the end node is called, it means that the action executed this time has ended normally. In this case, the system critical task timeout detection watchdog does not need to be processed, that is, no reset operation is required. Therefore, after the action executed this time has ended normally, the system critical task timeout detection watchdog can stop detecting the action executed by the critical process, thereby saving the occupation of electronic equipment system resources.

[0232] Furthermore, it should be noted that when implementing the watchdog detection method provided in this embodiment based on a system architecture applicable to the aforementioned hierarchical recovery scheme, when the end node is called, status information identifying the critical process can also be sent to the lower layer, i.e., the kernel layer's jam detection watchdog. In this case, the status information sent by the system's critical task timeout detection watchdog to the jam detection watchdog is specifically a normal flag, such as "OK," indicating that the critical process is in a normal state.

[0233] In addition, in some implementations, when the detection of the action is completed, the information sent by the system critical task timeout detection watchdog to the deadlock detection watchdog can also be status information indicating that the action has ended normally. In this way, when the subsequent deadlock detection watchdog does not receive status information about the critical process executing the action within a preset period (dog feeding period), it will not consider that an abnormality has occurred in the critical process, or that the system critical task timeout detection watchdog has failed, and will not perform a reset operation.

[0234] Therefore, the watchdog detection method provided in this embodiment connects Xcollie, which detects the key process, to the Hungdetect watchdog of the kernel layer. When an abnormality occurs in Xcollie and the detected business process cannot be restored to normal by resetting, the Hungdetect watchdog of the kernel layer performs a reset operation. Based on the above-mentioned principle of hierarchical recovery, the business process with the abnormality can be restored to normal, thereby ensuring the normal use of the electronic device.

[0235] In order to better understand the implementation of Xcollie access to Hungdetect watchdog, the following is combined Figure 7 Provide specific instructions.

[0236] See also Figure 7 , Figure 7 The figure is a schematic diagram showing an exemplary application scenario.

[0237] like Figure 7 As shown, the application framework layer of the electronic device includes Xcollie, which is used to detect whether the action executed by the key process SurfaceFlinger is completed, such as detecting whether the UI operation of the rendering system is completed.

[0238] As you can understand, SurfaceFlinger is started in the System Server process and is responsible for unified management of the device's frame buffer. During the startup process, SurfaceFlinger creates two threads, one of which is used to detect console events (hereinafter referred to as thread A), and the other thread (hereinafter referred to as thread B) is used to render the system's UI. Specifically, SurfaceFlinger can be used to manage the display subsystem and provide fusion of 2D and 3D layers for multiple applications.

[0239] Xcollie is used to detect whether the actions executed in the critical process are completed. Xcollie can set two threads. One thread (hereinafter referred to as thread C) is used to set the status mark of the critical process to normal when the critical thread starts executing the action, and determines whether to set the status mark of the critical process to abnormal based on whether the critical process execution action has timed out. The other thread (hereinafter referred to as thread D) is used to poll the status of each critical process and reset the critical process if the status mark of the critical process is abnormal.

[0240] Based on the features of Xcollie and SurfaceFlinger, continue to see Figure 7 , the first status mark obtained by Xcollie from SurfaceFlinger is specifically obtained by thread D in Xcollie.

[0241] Exemplarily, in some implementations, the first status flag may be actively determined by thread D based on console events detected by thread A in SurfaceFlinger and / or progress information rendered by thread B.

[0242] Exemplarily, in other implementations, the information for determining the first status flag may be actively sent by thread A and thread B in SurfaceFlinger to Xcollie, and then thread D in Xcollie determines the first status flag according to the received information.

[0243] Continue to see Figure 7 When the action executed by SurfaceFlinger is executed normally, the first status mark obtained by Xcollie is a normal mark, such as "OK". When the action executed by SurfaceFlinger times out, the first status mark obtained by Xcollie is an abnormal mark, such as "ERROR".

[0244] In other words, the information SurfaceFlinger gives to Xcollie is actually to identify its status. Whether Xcollie performs a reset operation or notifies the kernel layer's Hungdetect watchdog to perform a reset operation is determined by the first status flag that identifies its status.

[0245] Exemplarily, in some implementations, if the first status marks obtained by Xcollie within one detection cycle or multiple consecutive (such as 3) detection cycles are all abnormal marks, the SurfaceFlinger process is restarted, that is, Xcollie performs a reset operation.

[0246] Continue to see Figure 7 ,The kernel layer of the electronic device includes a Hungdetect watchdog to detect whether the kernel system is ,operating normally.

[0247] Wherein, when the kernel system is running normally, the kernel system regularly feeds the Hungdetect watchdog. When the kernel system cannot run normally, the kernel system stops feeding the Hungdetect watchdog.

[0248] Exemplarily, if the Hungdetect watchdog does not receive a feeding operation from the kernel system within one detection cycle or multiple (such as three) consecutive detection cycles, the kernel system is restarted, that is, a reset operation is performed.

[0249] Continue to see Figure 7 In addition to detecting the kernel system, the Hungdetect watchdog can also detect Xcollie and restart the kernel system when Xcollie is abnormal. After the kernel restarts successfully, the SurfaceFlinger process is reloaded, allowing the SurfaceFlinger process to return to normal. Among them, Xcollie abnormality can refer to Xcollie failure or the inability of Xcollie to successfully restart the SurfaceFlinger process.

[0250] Among them, when Xcollie runs normally and the SurfaceFlinger process it detects runs normally, Xcollie can actively send the second status mark to the Hungdetect watchdog, or the Hungdetect watchdog can actively obtain the second status mark from Xcollie.

[0251] It is understandable that in some implementations, whether Xcollie actively sends the second status mark to the Hungdetect watchdog, or the Hungdetect watchdog actively obtains the second status mark from Xcollie, it can be done according to a preset cycle, that is, regular sending or regular acquisition.

[0252] It should be noted that, in actual applications, the second state mark may be the same as or different from the first state mark.

[0253] Exemplarily, when the first state mark is a normal mark, if Xcollie is normal (valid), the second state mark is the same as the first state mark, and is also a normal mark.

[0254] For example, when the first state mark is a normal mark, if Xcollie is abnormal (failed), the second state mark is different from the first state mark, specifically an abnormal mark.

[0255] For example, when the first state mark is an abnormal mark, no matter whether Xcollie is normal or not, the second state mark is the same as the first state mark, that is, an abnormal mark.

[0256] That is to say, for the scenario where Xcollie is connected to Hungdetect, regardless of whether Xcollie can run normally or whether the SurfaceFlinger process can be restarted, the Hungdetect watchdog can obtain the second status mark.

[0257] In addition, it should be noted that, in some other implementations, the second status mark may be the detection of the communication channel between the Hungdetect watchdog and the Xcollie, or the detection of information sent by the Xcollie.

[0258] Specifically, if the Hungdetect watchdog fails to query any information provided by Xcollie and fails to detect the current state of Xcollie, an abnormal second state flag may be generated.

[0259] For example, if the Hungdetect watchdog does not obtain the second status flag indicating that the SurfaceFlinger process has returned to normal within one detection cycle or multiple (such as three) consecutive detection cycles, or does not obtain information indicating that Xcollie has stopped detecting the action executed by SurfaceFlinger, the kernel system will be restarted. Then, after the kernel restart is successful, the SurfaceFlinger process will be reloaded and started to return to normal.

[0260] In addition, it is understandable that in order to ensure the implementation of this solution, the detection cycle of the Hungdetect watchdog on Xcollie is longer than the detection cycle of Xcollie on the SurfaceFlinger process.

[0261] Optionally, the detection period of the Hungdetect watchdog on Xcollie is an integer multiple of the detection period of Xcollie on the SurfaceFlinger process. For example, the detection period of Xcollie on the SurfaceFlinger process is 30 seconds, and the detection period of the Hungdetect watchdog on Xcollie is 60 seconds.

[0262] In this way, by setting up a detection mechanism between the kernel layer and the application framework layer, hierarchical recovery of electronic devices is achieved. Because the granularity of kernel restart is greater than that of SurfaceFlinger process restart, when the SurfaceFlinger process cannot be restarted successfully, restarting the kernel can greatly improve the success rate of restoring the SurfaceFlinger process, thereby avoiding the problem of the electronic device's application framework layer repeatedly restarting the SurfaceFlinger process but failing.

[0263] Scenario 3

[0264] In this scenario, a detection mechanism is set between the application framework layer and the kernel layer of the electronic device, wherein the Hungdetect watchdog in the kernel layer can simultaneously detect multiple software watchdogs in the application framework layer.

[0265] See also Figure 8 , Figure 8 The figure is a flow chart showing an example of connecting multiple software watchdogs in the application framework layer to the Hungdetect watchdog by means of a public node pre-packaged in the kernel layer, so that the Hungdetect watchdog can detect multiple software watchdogs in the application framework layer at the same time.

[0266] like Figure 8 As shown, the watchdog detection method provided in this embodiment uses a public node pre-packaged in the kernel layer, specifically including:

[0267] Step 301: The public node receives information provided by each software watchdog in the application framework layer.

[0268] For example, the software watchdogs mentioned above may be, for example, System Server WatchDog, Xcollie, Init watchdog, etc., which are not listed one by one here and are not limited in this application.

[0269] Accordingly, the information provided by the aforementioned software watchdogs is related to the characteristics of the software watchdogs in practical applications.

[0270] For example, for System Server WatchDog, the information provided may be the second dog feeding information mentioned in the above scenario one.

[0271] It is understandable that when the information provided by System Server WatchDog is the second dog feeding information, it indicates that System Server WatchDog is effective and the System Server process detected by it is also normal.

[0272] Accordingly, in some implementation scenarios, the information provided by System Server WatchDog may not be the second watchdog information. For example, when System Server WatchDog fails or the System Server process it detects is abnormal, System Server WatchDog will stop providing the second watchdog information. In this case, System ServerWatchDog may no longer provide information, or set the provided information to "null", or provide agreed exception information in order to facilitate informing the lower-level public nodes that the current situation is abnormal.

[0273] The information provided by Xcollie can be the second status mark mentioned in the above scenario 2. According to the description of scenario 2, when a reset operation is required with the help of the hang detect watchdog, the second status mark is an abnormal mark. When the status of Xcollie and the corresponding key process is normal, the second status mark provided is a normal mark.

[0274] It should be understood that the above description is merely an example listed for a better understanding of the technical solution of this embodiment, and is not intended to be the sole limitation on this embodiment.

[0275] Step 302: The public node determines the priority of information provided by each software watchdog according to the service process corresponding to each software watchdog.

[0276] For example, taking the Android system as an example, most key processes are registered and started in the System Server process. Therefore, the normal operation of the System Server process is a prerequisite for ensuring the normal operation of other key processes. Therefore, in some implementations, information related to the System Server process can be determined as the first priority, and information provided by other key processes running in the System Server process can be determined as the second priority, that is, the first priority is higher than the second priority.

[0277] Based on this, if the information is provided by System Server WatchDog, the priority is determined to be the first priority; if the information is provided by Xcollie, the priority is determined to be the second priority.

[0278] It should be understood that the above description is merely an example for better understanding the technical solution of this embodiment and is not intended to be the sole limitation of this embodiment. In actual applications, the priorities of different business processes can also be reasonably set according to other business requirements to better adapt to various application scenarios.

[0279] Step 303: The public node determines whether to perform a reset operation based on a preset decision and the determined priority of the information provided by each software watchdog.

[0280] Exemplarily, in some implementations, the preset decision may stipulate that when the information of the first priority is the second watchdog information mentioned above, it indicates that the System Server process is normal. At this time, no matter what the information provided by other software watchdogs is, there is currently no need for the deadlock detection watchdog to intervene and perform a reset operation.

[0281] Exemplarily, in other implementations, the preset decision may stipulate that when the information with the first priority is the second dog feeding information mentioned above, and when n pieces of information provided by other software watchdogs (for example, N) are abnormal information, it is determined that the deadlock detection watchdog needs to intervene to perform a reset operation.

[0282] Exemplarily, n is an integer greater than 1, and N is an integer greater than n.

[0283] For example, within a detection cycle, a public node receives a total of 5 software watchdog messages, one of which is provided by the System Server WatchDog, and 4 (i.e., N mentioned above) are provided by other software watchdogs (2 of which are normal information and 2 are abnormal information). If it is stipulated that n ≥ 2, the stuck detection watchdog must intervene to perform a reset operation. In this case, the decision information made by the public node is the reset instruction.

[0284] Exemplarily, in other implementations, the preset decision may stipulate that the information with the first priority is the second dog feeding information mentioned above, and the software watchdog that provides the second priority information is a designated software watchdog. For example, when the reset mark is set, it is determined that the deadlock detection watchdog needs to intervene to perform a reset operation.

[0285] Furthermore, based on the above, we can also consider the failure of each software watchdog in the upper layer, or the abnormality of the business process it detects. If it does not return to normal in multiple consecutive cycles (such as 3), the public node determines that the deadlock detection watchdog needs to intervene and perform a reset operation.

[0286] It should be understood that the above description is only an example for better understanding the technical solution of this embodiment and is not intended to be the sole limitation of this embodiment. In actual applications, different preset policies can also be reasonably set according to other business needs to better adapt to various application scenarios.

[0287] Accordingly, based on the above preset strategy and the determined priority of the information provided by each software watchdog, if it is determined that a reset operation needs to be performed, step 304 is executed; otherwise, step 305 is executed.

[0288] Step 304: The public node provides a reset instruction to trigger the stuck detection watchdog to perform a reset operation.

[0289] For details about the reset operation performed by the watchdog during the stuck detection process, please refer to the above scenarios 1 and 2, which will not be repeated here.

[0290] Step 305: The public node provides the agreed watchdog feeding information to the stuck detection watchdog.

[0291] Understandably, the public node provides the agreed watchdog information, such as a "kick" mark or an "OK" mark, so that the stuck detection card gate dog knows that the upper-level software watchdog and the business process it detects are normal, and there is no need for it to intervene and restart the kernel system.

[0292] Therefore, the watchdog detection method provided in this embodiment pre-encapsulates a common node that can decide whether the lower-layer software watchdog should perform the reset when the upper-layer software watchdog fails to successfully reset the abnormal business process. The common node uniformly receives status marks sent by different upper-layer software watchdogs to identify the business process / actions performed by the upper-layer software watchdog detection. By analyzing and deciding the status marks according to preset strategies, the deadlock detection watchdog is notified to perform the reset only when it is determined that the deadlock detection watchdog needs to perform the reset, making the hierarchical recovery scheme in this application more reasonable.

[0293] In addition, according to business needs, public nodes can decide a processing result based on the dog feeding information and status marks from different upper-level software watchdogs, thereby minimizing the restart operation of the kernel system by the deadlock detection watchdog without affecting the user's use of electronic devices, thereby reducing resource overhead.

[0294] In order to better understand the implementation scheme of connecting multiple software watchdogs in the application framework layer to the Hungdetect watchdog, the following takes the Hungdetect watchdog in the kernel layer to simultaneously detect the System ServerWatchDog and Xcollie in the application framework layer as an example to explain the watchdog detection method provided by this application.

[0295] See also Figure 9 , Figure 9 The figure is a schematic diagram showing an exemplary application scenario.

[0296] like Figure 9 As shown, the application framework layer of the electronic device includes System Server WatchDog, the System Server process detected by System Server WatchDog, Xcollie, and key processes corresponding to Xcollie, such as SurfaceFlinger; the kernel layer of the electronic device includes the Hungdetect watchdog, which is used to detect whether the kernel system is running normally, and a public node that communicates with the System Server WatchDog and Xcollie of the application framework layer and the Hungdetect watchdog of the kernel layer respectively.

[0297] Regarding System Server WatchDog detecting the System Server process, the System Server process performing the first watchdog feeding operation on System Server WatchDog, when to restart the System Server process, and when System Server WatchDog performs the second watchdog feeding operation (the second watchdog feeding information in Scenario 1), please refer to the description in Scenario 1 and will not be repeated here.

[0298] Regarding how Xcollie detects the action in SurfaceFlinger, how Xcollie obtains the first status mark of SurfaceFlinger, when to restart SurfaceFlinger, and when Xcollie provides the second status mark, please refer to the description in Scenario 2 for details, which will not be repeated here.

[0299] For details about how the Hungdetect watchdog detects the kernel system, the kernel system performs the third feeding operation on the Hungdetect watchdog, and when to restart the kernel system, please refer to the description of the Hungdetect watchdog detecting the kernel system of this layer in Scenario 1 or Scenario 2. We will not repeat them here.

[0300] The following combination Figure 9 The focus is on writing the second feeding operation and the second status flag into the public node of the kernel layer, and the public node decides whether the dead detection watchdog performs the reset operation instead of directly giving it to the hungdetect watchdog.

[0301] For example, in a specific implementation, a preset policy may be pre-installed in the public node according to business requirements, that is, a policy for deciding whether the stuck detection watchdog performs a reset operation.

[0302] Therefore, the public node will decide whether the Hungdetect watchdog needs to perform a reset operation based on the preset strategy, the obtained dog feeding information and the status mark.

[0303] Regarding the watchdog feeding information obtained above, in some implementation scenarios, the information obtained may be that the SystemServer WatchDog is normal. In this case, it indicates that the monitored System Server process is also normal, and the System Server WatchDog is feeding the Hungdetect watchdog normally.

[0304] Correspondingly, in other implementation scenarios, you may also get information describing that the System Server WatchDog has failed, or that the System Server WatchDog is normal but the System Server process it monitors is abnormal. The System Server WatchDog stops providing dog feeding information to the Hungdetect watchdog, that is, the second dog feeding operation cannot be performed. It can also be understood that the System Server WatchDog feeds the Hungdetect watchdog abnormally.

[0305] Regarding the status flags mentioned above, in some implementation scenarios, they may be normal flags, that is, both Xcollie and SurfaceFlinger are normal. In other implementation scenarios, they may be abnormal flags, that is, at least one of Xcollie and SurfaceFlinger is abnormal.

[0306] Correspondingly, the public node will obtain decision information through processing.

[0307] Exemplarily, in some implementations, the decision information obtained by the public node can be actively pushed to the Hungdetect watchdog, or can be actively obtained from the public node by the Hungdetect watchdog.

[0308] For example, if the decision information requires the Hungdetect watchdog to perform a reset operation, in one scenario, when the public node determines that the Hungdetect watchdog needs to perform a reset operation, it will proactively notify the Hungdetect watchdog to perform the reset operation. In another scenario, when the public node determines that the Hungdetect watchdog needs to perform a reset operation, it can first save the decision information and wait for the Hungdetect watchdog to periodically obtain the decision information from the public node. Then, when the reset instruction is obtained, the public node will perform the reset operation.

[0309] Correspondingly, when the decision information is obtained that the Hungdetect watchdog does not need to perform a reset operation, the agreed dog feeding information can be sent to the Hungdetect watchdog to feed the dog, thereby avoiding the Hungdetect watchdog triggering dog barking or even dog biting.

[0310] As another example, in some implementations, a public node in the kernel layer is used to store the kicking information of the software watchdog in the application framework layer to the Hungdetect watchdog, as well as the sent process status information. The kicking information may include the name of the software watchdog and the kicking action (kick), and the process status information may include the name of the software watchdog and the process status (OK or ERROR). As a consumer of the public node, the Hungdetect watchdog can regularly (or periodically) check the kicking information stored in the public node and the sent process status information (such as OK or ERROR).

[0311] The Hungdetect watchdog determines whether to reset the kernel system based on the periodic (or periodic) kick information and / or process status information obtained from the public node, as well as a preset policy. The preset policy can be the aforementioned preset decision and the priority of the information provided by each software watchdog, which will not be detailed here.

[0312] It should be understood that the above description is merely an example listed for a better understanding of the technical solution of this embodiment, and is not intended to be the sole limitation on this embodiment.

[0313] Scene 4

[0314] In this scenario, a detection mechanism is set between the kernel layer and the hardware layer of the electronic device. Taking the hardware watchdog in the hardware layer detecting the Hungdetect watchdog in the kernel layer as an example, the watchdog detection method provided in this application is explained.

[0315] Figure 10 The figure is a schematic diagram showing an exemplary application scenario.

[0316] like Figure 10 As shown, the kernel layer of the electronic device includes a Hungdetect watchdog for detecting whether the kernel system is operating normally.

[0317] Wherein, when the kernel system operates normally, the kernel system regularly performs the first dog feeding operation to the Hungdetect watchdog. When the kernel system cannot operate normally, the kernel system stops the first dog feeding operation to the Hungdetect watchdog. If the Hungdetect watchdog does not receive the first dog feeding operation of the kernel system within a detection cycle or in a plurality of (such as 3) detection cycles in a row, the kernel system is restarted.

[0318] like Figure 10 As shown, the hardware layer of the electronic device includes a hardware watchdog (Hardware WatchDog) for detecting the hardware chip.

[0319] Among them, when the program in the hardware chip runs normally, the hardware chip will regularly perform a second dog feeding operation on the hardware watchdog, such as resetting the first timing of the hardware watchdog to zero to restart the timing. When the program in the hardware chip runs abnormally, the second dog feeding operation on the hardware watchdog is stopped.

[0320] If the hardware watchdog does not receive the second feed operation from the hardware chip, and the first timer increases to the first set value, the hardware chip is reset, thereby restarting the entire electronic device. Here, the detection period corresponding to the first timer is the detection period used by the hardware watchdog to detect the hardware chip. The first timer in the hardware watchdog is used to implement the first timer operation.

[0321] Continue to see Figure 10 In addition to detecting hardware chips, the hardware watchdog can also detect the Hungdetect watchdog. If the Hungdetect watchdog fails, the hardware chip will be reset to restart the entire electronic device and restore the kernel system. A Hungdetect watchdog failure can mean either the Hungdetect watchdog fails or the Hungdetect watchdog fails to successfully restart the kernel system.

[0322] Among them, when the Hungdetect watchdog runs normally and the kernel system it detects runs normally, the Hungdetect watchdog regularly performs a third dog feeding operation on the Hungdetect watchdog, such as resetting the second timer of the hardware watchdog to zero to restart the timer. When the Hungdetect watchdog fails to run normally or fails to successfully restart the kernel system, the Hungdetect watchdog stops the third dog feeding operation on the hardware watchdog.

[0323] As an optional implementation manner, the Hungdetect watchdog stops the third dog feeding operation on the hardware watchdog before triggering the kernel system reset (or restart).

[0324] When the hardware watchdog does not receive the third feeding operation from the Hungdetect watchdog, if the second timer increases to the second set value, the hardware chip is reset to restart the entire electronic device. Here, the detection period corresponding to the second timer is the detection period used by the hardware watchdog to detect the Hungdetect watchdog. The second timer in the hardware watchdog is used to implement the second timer operation.

[0325] In this way, by establishing a detection mechanism between the hardware layer and the kernel layer, a hierarchical recovery of electronic devices is achieved. Because the granularity of hardware restart is greater than that of kernel restart, hardware restart can greatly improve the success rate of kernel system recovery when the kernel cannot be successfully restarted. This also avoids the problem of the kernel layer of the electronic device repeatedly restarting the kernel system without success.

[0326] Scene 5

[0327] In this scenario, a detection mechanism is set between the kernel layer and the hardware layer of the electronic device. Taking the hardware watchdog in the hardware layer detecting the CPU core status watchdog in the kernel layer as an example, the watchdog detection method provided in this application is explained.

[0328] Figure 11 The figure is a schematic diagram showing an exemplary application scenario.

[0329] like Figure 11 As shown, the core layer of the electronic device includes a CPU core state watchdog for checking the CPU operating state and controlling the restart of the core when the CPU operating state meets the preset core restart condition.

[0330] Specifically, the CPU core status watchdog can be used to detect the operating status of each CPU core and control the restart of the core when the operating status of each CPU core meets the preset core restart condition.

[0331] The CPU core status watchdog periodically obtains the operating status of each CPU core and controls a core restart when the CPU core status meets a preset core restart condition. For example, the CPU core status watchdog obtains the operating status of each CPU core every 30 seconds and controls a core restart when the CPU core status meets a preset core restart condition.

[0332] As an optional implementation, the CPU core status watchdog can determine the running status of the CPU core based on whether the tasks on the CPU core can be scheduled, thereby detecting CPU scheduling problems.

[0333] Among them, a target task is bound to each core of the CPU, and the target task runs regularly on the bound CPU core. For example, the target task runs on the CPU core to which it is bound once every 30 seconds. The CPU core status watchdog regularly detects whether the target tasks bound to each CPU core can be scheduled through the first detection task, thereby determining the running status of each CPU core. For example, the first detection task checks once every 30 seconds whether the target tasks bound to each CPU core can be scheduled. If the target task on a certain CPU core cannot be scheduled, the CPU core status watchdog can determine that the running status of the CPU core is abnormal; if the target task on a certain CPU core can be scheduled, the CPU core status watchdog can determine that the running status of the CPU core is normal.

[0334] like Figure 12 As shown, the CPU of the electronic device includes eight cores, namely CPU0, CPU1, CPU2, ..., CPU7. Each CPU core is bound to a target task, for example, CPU0 is bound to target task Tast 0, CPU1 is bound to target task Tast 1, CPU2 is bound to target task Tast 2, ..., and CPU7 is bound to target task Tast 7. Each target task is scheduled to run on the CPU core to which it is bound, for example, target task Tast 0 is scheduled to run on CPU0, target task Tast 1 is scheduled to run on CPU1, target task Tast 2 is scheduled to run on CPU2, ..., and target task Tast 7 is scheduled to run on CPU7.

[0335] The CPU core status watchdog periodically detects whether each target task (Tast 0-Tast 7) ​​can be scheduled on the CPU core to which it is bound through the first detection task, thereby determining the operating status of each CPU core. Among them, the first detection task can run on any CPU core. For example, if Tast 0 cannot be scheduled on the CPU0 core to which it is bound, the CPU core status watchdog can determine that the operating status of the CPU0 core is abnormal. For example, if Tast 7 can be scheduled on the CPU0 core to which it is bound, the CPU core status watchdog can determine that the operating status of the CPU7 core is normal. In this way, the CPU core status watchdog can determine the operating status of each CPU core.

[0336] For example, "1" and "0" can be used to identify the operating status of a CPU core. For example, when the operating status of a CPU core is "1," the CPU core is operating normally; when the operating status of a CPU core is "0," the CPU core is operating abnormally. Furthermore, the first detection task periodically detects whether each target task can be scheduled on its bound CPU core and, based on the detection results, generates an operating status identifier corresponding to each CPU core. The CPU core status watchdog can then determine whether the operating status of each CPU core is abnormal based on the operating status identifier generated by the first detection task. The number of bits in the operating status identifier is the same as the number of CPU cores. For example, if a CPU includes eight cores, namely CPU0, CPU1, CPU2, ..., CPU7, the operating status identifier may include eight bits, with the values ​​of the eight bits sequentially identifying the operating status of each CPU core. Assuming the operating status identifier generated by the first detection task is "111111101," the CPU core status watchdog can determine, based on this operating status identifier, that the operating status of CPU6 is abnormal and that the remaining CPU cores are operating normally.

[0337] As another optional implementation, the CPU core status watchdog may determine the operating status of the CPU core based on the detection message.

[0338] The CPU core status watchdog can determine the operating status of the CPU core based on the detection message regularly through the second detection task. For example, the CPU core status watchdog can determine the operating status of the CPU core based on the detection message once every 30 seconds through the second detection task.

[0339] For example, the CPU core status watchdog may send a detection message to a CPU core whose physical state is online through the second detection task. If a detection feedback message is received from the CPU core in response to the detection message, the CPU core's operating state is determined to be normal; otherwise, the CPU core's operating state is determined to be abnormal. It should be noted that the CPU core status watchdog may not detect the operating state of a CPU core whose physical state is offline.

[0340] Optionally, the detection message may be a ping message. The CPU core status watchdog may send a ping message to the CPU core in the form of an interrupt through the second detection task, and the CPU core may send a feedback message in the form of an interrupt in response to the ping message, thereby enabling the CPU core status watchdog to detect a CPU interrupt storm.

[0341] like Figure 13 As shown, the CPU of the electronic device includes eight cores, namely CPU0, CPU1, CPU2, ..., CPU7. The CPU core status watchdog periodically sends ping messages to the CPU cores in the online physical state in sequence through the second detection task. If a feedback message is received from the CPU core in response to the ping message, the CPU core is determined to be able to respond normally and its operating state is determined to be normal. Otherwise, the CPU core is unable to respond normally and its operating state is determined to be abnormal. For example, after the CPU core status watchdog sends a ping message to the CPU0 core in the online physical state through the second detection task, if a feedback message is received from the CPU0 core in response to the ping message, the operating state of the CPU0 core is determined to be normal. For another example, after the CPU core status watchdog sends a ping message to the CPU1 core in the online physical state through the second detection task, if a feedback message is not received from the CPU1 core in response to the ping message, the operating state of the CPU1 core is determined to be abnormal. In this way, the CPU core status watchdog can determine the operating state of each CPU core.

[0342] After determining the operating status of each CPU core, the CPU core state watchdog determines whether the operating status of each CPU core meets the preset core restart condition. If so, the CPU core state watchdog controls the core to be restarted. This embodiment does not limit the preset core restart condition.

[0343] Exemplarily, if the number of CPU cores with abnormal operating states exceeds a preset number threshold, the CPU core state watchdog determines whether the operating states of the respective CPU cores meet a preset core restart condition and controls the core to be restarted.

[0344] As another example, if the operating state of a target CPU core is abnormal, the CPU core status watchdog determines whether the operating state of each CPU core meets the preset core restart conditions and controls the core restart. The target CPU core is a CPU core of a preset type, such as a large CPU core or a relatively important core in the CPU. For example, if CPU0 is a large CPU core and its operating state is abnormal, the CPU core status watchdog determines whether the operating state of each CPU core meets the preset core restart conditions and controls the core restart.

[0345] As an optional embodiment, the CPU core status watchdog can determine the first operating state of the CPU core based on whether a task on the CPU core can be scheduled, and the CPU core status watchdog can determine the second operating state of the CPU core based on the detection message. When both the first operating state and the second operating state of a CPU core indicate an abnormality, the CPU core status watchdog determines that the CPU is operating abnormally.

[0346] As another optional embodiment, the CPU core status watchdog may determine the first operating state of the CPU core based on whether a task on the CPU core can be scheduled, and the CPU core status watchdog may determine the second operating state of the CPU core based on the detection message. When either the first operating state or the second operating state of a CPU core indicates an abnormality, the CPU core status watchdog determines that the CPU is operating abnormally.

[0347] like Figure 11 As shown, the hardware layer of the electronic device includes a hardware watchdog (Hardware WatchDog) for detecting the hardware chip.

[0348] Among them, when the program in the hardware chip runs normally, the hardware chip will regularly perform a second dog feeding operation on the hardware watchdog, such as resetting the first timing of the hardware watchdog to zero to restart the timing. When the program in the hardware chip runs abnormally, the second dog feeding operation on the hardware watchdog is stopped.

[0349] If the hardware watchdog does not receive the second feed operation from the hardware chip, and the first timer increases to the first set value, the hardware chip is reset, thereby restarting the entire electronic device. Here, the detection period corresponding to the first timer is the detection period used by the hardware watchdog to detect the hardware chip. The first timer in the hardware watchdog is used to implement the first timer operation.

[0350] Continue to see Figure 11In addition to detecting hardware chips, hardware watchdogs can also detect CPU core status watchdogs. If the CPU core status watchdog fails, the hardware chip will be reset, allowing the entire electronic device to reboot and the core system to recover. A CPU core status watchdog failure can mean either the CPU core status watchdog has failed or the CPU core status watchdog has been unable to successfully reboot the core system.

[0351] Among them, when the CPU core status watchdog is operating normally and the CPU core status it detects does not meet the preset kernel restart conditions, the CPU core status watchdog periodically performs a third dog feeding operation on the Hungdetect watchdog, such as resetting the second timer of the hardware watchdog to zero to restart the timing. When the CPU core status watchdog cannot operate normally or the kernel system cannot be successfully restarted, the CPU core status watchdog stops the third dog feeding operation on the hardware watchdog.

[0352] As an optional implementation manner, the CPU core status watchdog stops the third dog feeding operation on the hardware watchdog before triggering the kernel system reset (or restart).

[0353] If the hardware watchdog does not receive the third feed from the CPU core status watchdog, and the second timer increases to the second set value, the hardware chip is reset, thereby completely restarting the electronic device. Here, the detection period corresponding to the second timer is the detection period used by the hardware watchdog to detect the CPU core status watchdog. The second timer in the hardware watchdog is used to implement the second timer operation.

[0354] In one embodiment, in addition to detecting the hardware chip, the hardware watchdog can also detect the CPU core status watchdog and the Hungdetect watchdog in the kernel layer at the same time. At this time, a second timer and a third timer can be set in the hardware watchdog, which are respectively used to detect the CPU core status watchdog and the Hungdetect watchdog's dog feeding operations on the hardware watchdog. For example, when the hardware watchdog does not receive the dog feeding operation from the CPU core status watchdog, if the second timing increases to the second set value, the hardware chip is reset to restart the entire electronic device. When the hardware watchdog does not receive the dog feeding operation from the Hungdetect watchdog, if the third timing increases to the third set value, the hardware chip is reset to restart the entire electronic device. Here, the detection period corresponding to the second timing is the detection period used by the hardware watchdog to detect the CPU core status watchdog; the detection period corresponding to the third timing is the detection period used by the hardware watchdog to detect the Hungdetect watchdog. The hardware watchdog is used to detect the CPU core status watchdog's detection period, which is also the detection period corresponding to the second timing, and is longer than the CPU core status watchdog's detection period. The hardware watchdog is used to detect the hung detect watchdog's detection period, which is also the detection period corresponding to the third timing, and is longer than the hung detect watchdog's detection period. This embodiment does not limit the values ​​of the first set value, the second set value, and the third set value.

[0355] If the hardware watchdog can also detect other watchdogs in the kernel layer at the same time, the processing method can refer to the above-mentioned hardware watchdog's detection of the hungdetect watchdog or the CPU core status watchdog, which is not repeated here.

[0356] In this way, by establishing a detection mechanism between the hardware layer and the kernel layer, a hierarchical recovery of electronic devices is achieved. Because the granularity of hardware restart is greater than that of kernel restart, hardware restart can greatly improve the success rate of kernel system recovery when the kernel cannot be successfully restarted. This also avoids the problem of the kernel layer of the electronic device repeatedly restarting the kernel system without success.

[0357] Scene 6

[0358] In this scenario, detection mechanisms are set up between the application framework layer and the kernel layer, and between the kernel layer and the hardware layer of the electronic device, and the Hungdetect watchdog in the kernel layer can simultaneously detect multiple software watchdogs in the application framework layer.

[0359] Figure 14 The figure is a schematic diagram showing an exemplary application scenario.

[0360] like Figure 14As shown, the application framework layer of an electronic device includes the System Server Watchdog, Xcollie, and Init watchdog. The System Server Watchdog monitors the System Server process in the application framework layer, for example, to detect deadlocks, unresponsiveness, and other issues. Xcollie checks the completion of actions executed by the critical SurfaceFlinger process, such as the completion of UI operations in the rendering system. The Init watchdog monitors the Init process.

[0361] The kernel layer of electronic devices includes a HungDetect watchdog and a CPU core status watchdog. The HungDetect watchdog monitors the kernel system, for example, to detect a kernel freeze. The CPU core status watchdog monitors the operating status of each CPU core, for example, to detect abnormal operation.

[0362] The hardware layer of electronic equipment includes a hardware watchdog. Figure 14 The first hardware watchdog, the second hardware watchdog, and the third hardware watchdog shown in the figure can be understood as hardware watchdogs with different processing logics set for different chips and different platforms. The embodiment of the present application provides a technical solution for hierarchical recovery of electronic devices, which can adapt to different hardware watchdogs, such as Figure 14 The first hardware watchdog, the second hardware watchdog, and the third hardware watchdog are shown in FIG. The adaptation for different hardware watchdogs can be implemented during the code compilation phase. The following explanation is given using the actual use of the first watchdog in an electronic device as an example.

[0363] See also Figure 14 In this embodiment, the kernel layer Hungdetect watchdog can not only detect the kernel system, but also detect the System Server WatchDog, Xcollie and Init watchdogs in the application framework layer.

[0364] In this embodiment, the kernel layer sets a public node for storing the kick information sent by the software watchdog in the application framework layer to the Hungdetect watchdog, as well as the sent process status information. As a consumer of the public node, the Hungdetect watchdog can periodically (or periodically) check the kick information stored in the public node and the sent process status information (such as OK or ERROR).

[0365] Furthermore, after periodically obtaining the kick-dog information and process status information stored in the public node, the Hungdetect watchdog determines whether to perform a kernel restart operation according to a preset strategy.

[0366] Optionally, when any software watchdog in the application framework layer detected by the Hungdetect watchdog is abnormal, the Hungdetect watchdog will perform a kernel restart operation to restore the corresponding process in the application framework layer through kernel restart.

[0367] Optionally, when multiple software watchdogs in the application framework layer detected by the Hungdetect watchdog are abnormal, the Hungdetect watchdog then performs a kernel restart operation to restore corresponding processes in the application framework layer through kernel restart.

[0368] Optionally, when any software watchdog in the application framework layer detected by the Hungdetect watchdog is abnormal for multiple consecutive cycles, the Hungdetect watchdog performs a kernel restart operation to restore the corresponding process in the application framework layer by kernel restart.

[0369] For example, taking three cycles as an example, assuming that the Hungdetect watchdog fails to obtain the kicking information from the System Server WatchDog for three consecutive cycles, or obtains the process status information sent by Xcollie as ERROR for three consecutive cycles, the kernel restart operation is executed.

[0370] Similarly, in this embodiment, the first hardware watchdog in the hardware layer can not only detect the hardware chip, but also detect the Hungdetect watchdog and the CPU core status watchdog in the kernel layer.

[0371] If the Hungdetect watchdog or the CPU core status watchdog fails to kick the first hardware watchdog on time, the first hardware watchdog resets the hardware chip it detects and restarts the entire machine to restore the kernel system by restarting the entire machine.

[0372] For any details not explained in this scenario, please refer to the description in the previous scenario and will not be repeated here.

[0373] In this way, by setting up a detection mechanism between electronic device layers, hierarchical recovery of electronic devices is achieved. Because the granularity of the next recovery is greater than that of the upper layer's recovery, if the upper layer fails to recover successfully, the success rate of the upper layer's recovery can be improved by restarting the lower layer. This can also avoid the problem of a certain layer of the electronic device repeatedly restarting but failing.

[0374] In addition, it should be noted that in order to make the watchdog detection method provided in this application adaptable to different chip platforms, thereby realizing multi-level watchdog protection, so as to achieve comprehensive coverage of electronic equipment and ensure that electronic equipment can be used normally, a pre-packaged adapter node can also be set in the kernel layer so that the CPU core status watchdog and Hungdetect watchdog in the kernel layer can be detected by the hardware watchdog provided by different chip platforms.

[0375] For example, because the loading time required for hardware watchdogs on different platforms varies, if the CPU core status watchdog fails to receive the dog feeding information within the same timeframe, some hardware watchdogs may interpret the watchdog as normal, while others may interpret it as abnormal, leading to the watchdog barking or even biting. Therefore, to ensure that the technical solution of this application is adaptable to different hardware watchdogs, when the electronic device is started, the hardware watchdog's shutdown interface can be called to shut it down, and the hardware watchdog can be enabled after the upper-layer software watchdog is started.

[0376] In addition, in order to simplify the calling program and avoid code redundancy during the specific implementation, the interface for initializing the hardware dog, the interface for triggering the dog bite (perform reset) and the interface for stopping feeding the dog can be uniformly encapsulated, and then these unified interfaces can be used to call the processing logic of the hardware dog currently used by the electronic device, thereby realizing a set of solutions that can adapt to different hardware watchdogs.

[0377] This embodiment further provides a computer storage medium storing computer instructions. When the computer instructions are executed on an electronic device, the electronic device executes the above-mentioned related method steps to implement the watchdog detection method in the above-mentioned embodiment.

[0378] This embodiment further provides a computer program product. When the computer program product is run on a computer, it enables the computer to execute the above-mentioned related steps to implement the watchdog detection method in the above-mentioned embodiment.

[0379] In addition, an embodiment of the present application also provides a device, which can specifically be a chip, component or module, and the device may include a connected processor and memory; wherein the memory is used to store computer-executable instructions, and when the device is running, the processor can execute the computer-executable instructions stored in the memory to enable the chip to execute the watchdog detection method in the above-mentioned method embodiments.

[0380] Among them, the electronic device, computer storage medium, computer program product or chip provided in this embodiment is used to execute the corresponding method provided above. Therefore, the beneficial effects that can be achieved can refer to the beneficial effects of the watchdog detection method provided above, and will not be repeated here.

[0381] Through the description of the above implementation methods, technical personnel in the relevant field can understand that for the convenience and simplicity of description, only the division of the above-mentioned functional modules is used as an example. In actual applications, the above-mentioned functions can be distributed and completed by different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above.

[0382] In the several embodiments provided in this application, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are merely schematic. For example, the division of modules or units is only a logical function division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another device, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0383] As described above, the above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit them. Although the present application has been described in detail with reference to the above embodiments, ordinary technicians in this field should understand that they can still modify the technical solutions recorded in the above embodiments, or make equivalent replacements for some of the technical features therein. However, these modifications or replacements do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present application.

Claims

1. A watchdog detection method, characterized in that: The method comprises: Initialize a system critical task timeout detection watchdog and set the status information identifying the critical process to a normal mark. The system critical task timeout detection watchdog is located in the application framework layer and is used to detect whether the action executed by the critical process started in the application framework layer is completed; After detecting that the action executed by the critical process has called a start node, the system critical task timeout detection watchdog records the execution time of the action executed by the critical process and sends the normal flag to the deadlock detection watchdog in the kernel layer according to a preset period; wherein, if the status information is the normal flag, the deadlock detection watchdog does not perform a reset operation on the kernel system; When the execution duration reaches the timeout duration corresponding to the action, the system key task timeout detection watchdog queries whether the end node of the action is called; When the end node is called, the system critical task timeout detection watchdog stops detecting the action executed by the critical process and sends the normal flag to the deadlock detection watchdog; When the end node is not called, the system critical task timeout detection watchdog modifies the status information identifying the critical process from the normal mark to the abnormal mark, and performs a reset operation on the critical process; After the reset is successful, the system critical task timeout detection watchdog modifies the status information from the abnormal mark to the normal mark, and sends the normal mark to the stuck detection watchdog; After the reset fails, the system critical task timeout detection watchdog sends the abnormal flag to the deadlock detection watchdog in the kernel layer, and the deadlock detection watchdog performs a reset operation on the kernel system; wherein, the reset failure includes not restoring the critical process to normal, or the system critical task timeout detection watchdog fails.

2. The method according to claim 1, characterized in that After a reset fails, before executing the step of the system key task timeout detection watchdog sending the abnormal flag to the stuck detection watchdog in the kernel layer, the method further includes: The system critical task timeout detection watchdog detects the abnormal duration of the state information of the critical process being in the abnormal mark; When the abnormal duration is less than the duration threshold, the system critical task timeout detection watchdog re-executes the reset operation; When the abnormal duration is not less than the duration threshold, the system key task timeout detection watchdog sends the abnormal flag to the deadlock detection watchdog in the kernel layer.

3. The method according to claim 2, characterized in that The duration threshold is determined according to the timeout duration, the detection period of the deadlock detection watchdog, and the delay between the application framework layer and the kernel layer.

4. The method according to claim 1, wherein After a reset fails, before executing the step of the system key task timeout detection watchdog sending the abnormal flag to the stuck detection watchdog in the kernel layer, the method further includes: The system critical task timeout detection watchdog detects the abnormal duration of the state information of the critical process being in the abnormal mark; The system critical task timeout detection watchdog determines the number of timeouts according to the abnormality duration and the timeout duration; When the timeout number is less than the number threshold, the system critical task timeout detection watchdog re-executes the reset operation; When the abnormal duration is not less than the number threshold, the system key task timeout detection watchdog sends the abnormal flag to the deadlock detection watchdog in the kernel layer.

5. The method according to claim 1, characterized in that The system key task timeout detection watchdog sends the abnormal flag to the stuck detection watchdog in the kernel layer, and the stuck detection watchdog performs a reset operation, including: The system critical task timeout detection watchdog sends the abnormal flag to a pre-packaged public node in the kernel layer, and the public node is used to decide whether the stuck detection watchdog performs a reset operation; The public node determines whether to perform a reset operation according to the abnormality mark and a preset strategy; When it is determined to perform a reset operation, the jam detection watchdog is notified to perform a reset operation.

6. The method according to any one of claims 1 to 5, characterized in that The initialization system key task timeout detection watchdog includes: During the process of starting the critical process, the system critical task timeout detection watchdog is initialized.

7. The method according to any one of claims 1 to 5, characterized in that The method further comprises: When the key process is started and the function corresponding to the action executed by the key process is called, the system key task timeout detection watchdog is initialized.

8. The method according to claim 7, characterized in that When initializing the system critical task timeout detection watchdog, the method further includes: Setting a hierarchical recovery flag for a function corresponding to an action executed by the critical process; The hierarchical recovery mark is used to identify that when the status information of the critical process is the abnormal mark, the system critical task timeout detection watchdog notifies the deadlock detection watchdog to perform a reset operation.

9. An electronic device, characterized in that: include: one or more processors, memory, and one or more computer programs; The one or more computer programs are stored in the memory, and when the one or more processors execute the computer programs, the electronic device executes the watchdog detection method according to any one of claims 1 to 8.

10. A computer-readable storage medium, characterized in that The invention comprises a computer program, which, when running on an electronic device, enables the electronic device to execute the watchdog detection method according to any one of claims 1 to 8.

Images