Gatekeeper detection method, apparatus, and storage medium

By setting a system service watchdog in the system service process, interaction between the upper and lower watchdogs is achieved, ensuring that abnormal processes are reset, solving device abnormality problems caused by software watchdog failure, and improving device reliability and user experience.

CN116450386BActive Publication Date: 2025-10-17HONOR DEVICE CO LTD
View PDF 2 Cites 0 Cited by

Patent Information

Application Number
CN202210017935.5
Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Filing Date
2022-01-07
Publication Date
2025-10-17
Estimated Expiration
2042-01-07

AI Technical Summary

Technical Problem

Existing software watchdogs may fail due to interference from uncontrollable factors, resulting in the inability to reset the business process and affecting the normal use of the equipment.

Method used

By setting a system service watchdog in the system service process, it is detected whether the system service process of the application framework layer is running normally. If it is not running normally, it stops sending dog feeding information to the deadlock detection watchdog, triggering the lower-layer software watchdog to reset, realizing the interaction between the upper and lower layer watchdogs, and ensuring the recovery of abnormal processes.

Benefits of technology

Even if the upper-layer software watchdog fails, the abnormal process can be reset by the lower-layer watchdog, ensuring normal use of the device, reducing the impact on user experience, and facilitating maintenance and problem location by capturing abnormal logs.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN116450386B_ABST
    Figure CN116450386B_ABST
Patent Text Reader

Abstract

The application provides a watchdog detection method, device and storage medium. In the method, a system service watchdog for detecting a system service process is connected to a kernel layer deadlock detection watchdog. When the system service watchdog abnormally operates and cannot be restored to normal by resetting, the kernel layer deadlock detection watchdog performs a reset operation, so that the abnormal service process can be restored to normal based on the principle of the layered and hierarchical restoration, thereby ensuring normal use of the electronic device.
Need to check novelty before this filing date? Find Prior Art

Description

TECHNICAL FIELD

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

[0002] A watchdog, also known as a watchdog timer, is essentially a timer. In practical applications, a watchdog can include a software watchdog and a hardware watchdog. Whether it is a software watchdog or a hardware watchdog, in the current implementation scenario, there is generally one input and one output. The input is called kicking the dog or servicing the dog, and the output is generally used to reset the corresponding business process or hardware when an exception occurs in the business process or hardware detected by the watchdog, so as to restore the business process or hardware to normal.

[0003] Taking a software watchdog as an example, although the current software watchdog can restore the business process it detects, in practical applications, due to uncontrollable interference factors, the software watchdog can fail to successfully reset the business process it detects, or even the software watchdog fails, thereby affecting the normal use of the device. SUMMARY

[0004] To solve the above technical problems, the present application provides a watchdog detection method, device and storage medium, aiming to realize the interaction between the upper-layer software watchdog and the lower-layer software watchdog, so that the lower-layer software watchdog can be triggered to reset by the upper-layer software watchdog, and the abnormal business process 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 a first aspect, the present application provides a watchdog detection method. The method comprises: initializing a system service watchdog in the process of starting a system service process, the system service watchdog being used to detect whether the system service process in an application program framework layer is normal; the system service process detecting whether it is running normally according to a preset period; when running normally, the system service process sends first kicking information to the system service watchdog, and the system service watchdog sends second kicking information to a dead lock detection watchdog located in a kernel layer; when not running normally, the system service watchdog stops sending the second kicking information to the dead lock detection watchdog, and performs a reset operation on the system service process.

[0006] Illustratively, the system service watchdog located in the application program framework layer can be regarded as an upper-layer software watchdog.

[0007] Illustratively, the dead lock detection watchdog located in the kernel layer can be regarded as a lower-layer software watchdog.

[0008] For example, the upper-layer software watchdog has less impact on the electronic device than the lower-layer software watchdog when performing the reset operation.

[0009] Therefore, the watchdog detection method provided by the application can realize the interaction between the upper-layer software watchdog and the lower-layer software watchdog, and the lower-layer software watchdog can be triggered to perform the reset by the upper-layer software watchdog, so that the abnormal service process can be restored to normal, regardless of whether the upper-layer software watchdog is invalid, thereby ensuring that the device can be normally used.

[0010] According to the first aspect, the system service process runs a key service; and the system service process detects whether the system service process is normally running according to a preset period, including: the system service process detects whether the key service is normally running according to the preset period; when the key service is normally running, it is determined that the system service process is normally running; and when the key service is not normally running, it is determined that the system service process is not normally running.

[0011] For example, when the system service process is started, the Android service registers and starts various key services, such as AMS, WMS, etc.

[0012] For example, since these key services are running in the system service process, if these key services are normally running, it indicates that the system service process is normally running. Therefore, the watchdog detection method provided by the application gives priority to using the system key task timeout detection watchdog to perform the reset when the abnormal duration is less than the duration threshold, for example, 2 detection periods corresponding to the system key task timeout detection watchdog, that is, the software watchdog of the current layer resets the service process detected thereby, and notifies the deadlock detection watchdog, that is, the software watchdog of the lower layer, to perform the reset when the abnormal duration is not less than the duration threshold, so that the reset operation can have as little impact as possible on the work of the electronic device, and the user experience is further ensured. According to the key service running in the system service process, whether the system service process is normally running can be accurately determined.

[0013] According to the first aspect, or any one of the implementation manners of the first aspect, when normally running, the system service process sends first feeding information to the system service watchdog, and the system service watchdog sends second feeding information to the deadlock detection watchdog located in the kernel layer, including: when normally running, the system service process sends first feeding information to the system service watchdog; and when normally running and reaching the feeding period of the deadlock detection watchdog relative to the system service watchdog, the system service watchdog sends second feeding information to the deadlock detection watchdog located in the kernel layer.

[0014] For example, when the system service process is running normally, the second feeding information sent by the system service watchdog to the freeze detection watchdog can be sent to the freeze detection watchdog after the system service watchdog receives the first feeding information, or can be sent to the freeze detection watchdog when the feeding period of the freeze detection watchdog relative to the system service watchdog is reached.

[0015] According to the first aspect, or any one of the implementations of the first aspect, when not running normally, the system service watchdog stops sending the second feeding information to the freeze detection watchdog, and performs the reset operation on the system service process, including: when not running normally, the system service watchdog determines an abnormal duration in which the system service process does not run normally; the system service watchdog determines the number of abnormalities according to the abnormal duration and the feeding period of the system service process relative to the system service watchdog; when the number of abnormalities is greater than n feeding periods, and the system service watchdog does not receive the first feeding information sent by the system service process, the system service watchdog stops sending the second feeding information to the freeze detection watchdog, and performs the reset operation on the system service process; wherein n is an integer greater than 0.

[0016] Therefore, the watchdog detection method provided by the present application avoids frequent reset operations, i.e. restarts, on the system service process, reduces the impact on the user using the electronic device, and ensures the user experience.

[0017] According to the first aspect, or any one of the implementations of the first aspect, when the number of abnormalities is greater than n feeding periods, and the system service watchdog does not receive the first feeding information sent by the system service process, the system service watchdog stops sending the second feeding information to the freeze detection watchdog, and performs the reset operation on the system service process, including: when the number of abnormalities is greater than n feeding periods, and the system service watchdog does not receive the first feeding information sent by the system service process, the system service watchdog stops sending the second feeding information to the freeze detection watchdog, and triggers the dog bark; when n+m feeding periods, and the system service watchdog does not receive the first feeding information sent by the system service process, the system service watchdog performs the reset operation on the system service process; wherein m is an integer greater than 0.

[0018] Thus, the watchdog detection method provided in the application avoids the situation that the system service watchdog mistakenly considers that the system service process is abnormal and performs the reset operation on the system service process due to the fact that the first dog feeding information is not timely sent to the system service watchdog due to some reasons such as external interference, thereby reducing the influence of the user using the electronic device and ensuring the user experience.

[0019] According to the first aspect or any one of the implementations of the first aspect, after triggering the dog barking, the method further includes: the system service watchdog capturing the daily log.

[0020] For example, the system service watchdog can capture the abnormal log by using the pre-compiled dump logic.

[0021] Thus, the watchdog detection method provided in the application captures the abnormal log, thereby facilitating the maintenance and test of the system by the operation and maintenance personnel and accurately locating the abnormal problem.

[0022] According to the first aspect or any one of the implementations of the first aspect, when not running normally, after the system service watchdog stops sending the second dog feeding information to the dead lock detection watchdog and performs the reset operation on the system service process, the method further includes: after the reset is successful, the system service watchdog sends the second dog feeding information to the dead lock detection watchdog.

[0023] Thus, the watchdog detection method provided in the application sends the second dog feeding information to the lower-level dead lock detection watchdog after the reset operation performed by the upper-level software watchdog is successful, thereby avoiding the reset operation performed by the lower-level dead lock detection watchdog, reducing the influence of the user using the electronic device and ensuring the user experience.

[0024] According to the first aspect or any one of the implementations of the first aspect, the system service watchdog sends the second dog feeding information to the dead lock detection watchdog located in the kernel layer, including: the system service watchdog sends the second dog feeding information to a public node pre-encapsulated in the kernel layer, and the public node is used to determine whether to perform the reset operation by the dead lock detection watchdog; wherein, when the public node does not receive the second dog feeding information, the public node determines whether to perform the reset operation according to a preset strategy; when it is determined to perform the reset operation, the public node notifies the dead lock detection watchdog to perform the reset operation.

[0025] Therefore, the watchdog detection method provided in the application can pre-package a common node capable of determining whether the software watchdog at the lower layer performs reset when the software watchdog at the upper layer fails to successfully reset the abnormal service process, and the common node uniformly interfaces with the state marks sent by the software watchdog at the upper layer and identifying the service process / service process execution action detected by the software watchdog at the upper layer. When the second watchdog feeding information is not received, the common node determines whether the watchdog at the lower layer needs to perform reset according to a preset strategy, and only notifies the watchdog at the lower layer to perform reset when it is determined that the watchdog at the lower layer needs to perform reset. Therefore, the layered and hierarchical recovery scheme in the application is more reasonable.

[0026] In a second aspect, the 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 in the memory, and when the computer programs are executed by the one or more processors, the electronic device executes the instructions of the method in the first aspect or any possible implementation manner of the first aspect.

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

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

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

[0030] Figure 1 A schematic diagram of the hardware structure of the electronic device is exemplarily shown;

[0031] Figure 2 A schematic diagram of the software structure of the electronic device is exemplarily shown;

[0032] Figure 3 A schematic diagram of the system architecture corresponding to the watchdog detection method provided by the embodiment of the application is exemplarily shown;

[0033] Figure 4 One of the flowcharts of the watchdog detection method provided by the embodiment of the application is exemplarily shown;

[0034] Figure 5For the watchdog detection method shown in Figure 4 A schematic diagram of an application scenario to which the watchdog detection method shown in

[0035] Figure 6 A second flowchart of the watchdog detection method provided by the embodiment of the application shown for example;

[0036] Figure 7 For the watchdog detection method shown in Figure 6 A schematic diagram of an application scenario to which the watchdog detection method shown in

[0037] Figure 8 A third flowchart of the watchdog detection method provided by the embodiment of the application shown for example;

[0038] Figure 9 A schematic diagram of an application scenario three to which the watchdog detection method shown in Figure 8

[0039] Figure 10 A further schematic diagram of an application scenario to which the watchdog detection method is applicable shown for example;

[0040] Figure 11 A further schematic diagram of an application scenario to which the watchdog detection method is applicable shown for example;

[0041] Figure 12 A first schematic diagram of the CPU core state detection shown for example;

[0042] Figure 13 A second schematic diagram of the CPU core state detection shown for example;

[0043] Figure 14 A further schematic diagram of an application scenario to which the watchdog detection method is applicable shown for example. DETAILED DESCRIPTION

[0044] The technical solutions in the embodiments of the application will be described clearly and completely below with reference to the drawings in the embodiments of the application. Obviously, the described embodiments are only some of the embodiments of the application, but not all the embodiments of the application. Based on the embodiments in the application, all other embodiments obtained by those of ordinary skill in the art without creative work fall within the scope of protection of the application.

[0045] The term "and / or" in this document merely describes an association relationship of associated objects, and indicates that there can be three relationships, for example, A and / or B, which can represent three cases of existence of A alone, existence of A and B simultaneously, and existence of B alone.

[0046] ​The terms "first" and "second" and the like in the description and claims of the present application are used for distinguishing between similar elements and not necessarily for describing a specific sequential or chronological order. For example, the first target object and the second target object are used for distinguishing between similar objects but not for describing specific sequential or chronological order, either of which can be altered as appropriate or desirable.

[0047] In the present application, the word "exemplary" or "for example" is used to mean serving as an example, instance, or illustration. Any embodiment or design described as "exemplary" or "for example" in the present application should not be construed as preferred or advantageous over other embodiments or designs. Rather, the exemplary or example embodiments are presented for purposes of illustration.

[0048] In the description of the present application, the meaning of "a plurality of" is two or more unless otherwise specified. For example, a plurality of processing units means two or more processing units; a plurality of systems means two or more systems.

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

[0050] Referring to Figure 1 , Figure 1 is a schematic diagram of the hardware structure of the electronic device 100.

[0051] Optionally, the electronic device 100 can be a terminal, which can also be referred to as a terminal device. The terminal can be a cellular phone or a pad, and the present application is not limited thereto.

[0052] Continuing to refer to Figure 1The electronic device 100 can include a processor 110, an external memory interface 120, an internal memory 121, a universal serial bus (USB) interface 130, a charging management module 140, a power management module 141, a battery 142, an antenna 1, an antenna 2, a mobile communication module 150, a wireless communication module 160, an audio module 170, a speaker 170A, a receiver 170B, a microphone 170C, a headset interface 170D, a sensor module 180, a key 190, a motor 191, an indicator 192, a camera 193, a display screen 194, and a subscriber identification module (SIM) card interface 195, etc. The sensor module 180 can include a pressure sensor, a gyroscope sensor, a barometric 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, etc.

[0053] The processor 110 can include one or more processing units, for example: the processor 110 can 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), etc. Different processing units can be independent devices, or can be integrated in one or more processors.

[0054] The controller can be the nerve center and command center of the electronic device 100. The controller can generate operation control signals according to instruction operation codes and timing signals, and complete the control of fetching and executing instructions.

[0055] The processor 110 can also be provided with a memory for storing instructions and data. In some embodiments, the processor 110 can include one or more interfaces, such as a PCM interface, a universal serial bus (USB) interface, and the like. The PCM interface can also be used for audio communication, sampling, quantizing, and encoding analog signals. In some embodiments, the audio module 170 and the wireless communication module 160 can be coupled through a PCM bus interface. In some embodiments, the audio module 170 can also transmit audio signals to the wireless communication module 160 through the PCM interface to implement the function of answering a phone call through a Bluetooth headset. Both the I2S interface and the PCM interface can be used for audio communication. The USB interface 130 is an interface that complies with the USB standard specification, and can be a Mini USB interface, a Micro USB interface, a USB Type C interface, or the like. The USB interface 130 can be used to connect a charger to charge the electronic device 100, and can also be used to transmit data between the electronic device 100 and a peripheral device. The interface can also be used to connect a headset to play audio through the headset. The interface can also be used to connect other electronic devices, such as an AR device, and the like.

[0056] In addition, it should be noted that in some embodiments, the processor 110 can be built-in with a hardware watchdog, for example, a timer in the processor 110 is used as a hardware watchdog. The processor 110 initializes the timer through a program, writes an initial value, and starts the timer to detect the processor 110. Once the processor 110 has an error, the timer sends a restart signal to the processor 110.

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

[0058] The charging management module 140 is configured to receive charging input from a charger. The charging management module 140 can also supply power to the electronic device through the power management module 141 while charging the battery 142. 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 supply power to the processor 110, the internal memory 121, the external memory, the display 194, the camera 193, and the wireless communication module 160.

[0059] The wireless communication function of the electronic device 100 can be implemented through the antenna 1, the antenna 2, the mobile communication module 150, the wireless communication module 160, the modem processor, and the baseband processor. The antenna 1 and the antenna 2 are configured to transmit and receive electromagnetic wave signals. The mobile communication module 150 can provide a solution for wireless communication including 2G / 3G / 4G / 5G, etc. applied to the electronic device 100. The wireless communication module 160 can provide a solution for wireless communication including wireless local area networks (WLAN) (e.g., wireless fidelity (Wi-Fi) network), Bluetooth (BT), global navigation satellite system (GNSS), frequency modulation (FM), near field communication (NFC), infrared (IR) technology, etc. 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 a network and other devices through wireless communication technology.

[0060] The electronic device 100 can implement a display function through the GPU, the display 194, and the application processor. The display 194 is configured to display images, videos, etc. In some embodiments, the electronic device 100 can include one or N displays 194, where N is a positive integer greater than 1.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0085] System Server is the provider of Android basic services, and is the most basic requirement for Android system running. Some services in the system reside in System Server, such as WMS (Window Manager Server), AMS (Activity Manager System Service), PMS (PackageManager Server), etc. These services exist in the System Server process in the form of a thread.

[0086] System Server WatchDog is used to detect whether System Server has problems such as deadlock and non-response. When System Server fails, System Server WatchDog kills the System Server process to achieve soft restart and self-recovery of System Server. The objects detected by System Server WatchDog mainly include two categories, one is object lock, and the other is thread Handler.

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

[0088] System Server periodically detects whether the key services such as AMS and WMS are running normally. If System Server detects that the key services such as AMS and WMS are running normally, System Server WatchDog is fed. If System Server detects that any of the key services such as AMS and WMS is not running normally, System Server WatchDog is not fed. When System Server does not feed System Server WatchDog for a plurality of (such as three) periods, System Server WatchDog resets the System Server process.

[0089] SurfaceFlinger is started in the System Server process and is responsible for managing the device's frame buffer. SurfaceFlinger creates two threads in the process of starting, one of which is used to detect console events, and the other is used to render the system UI. Specifically, SurfaceFlinger can be used to manage the display subsystem and provide 2D and 3D layer fusion for multiple applications.

[0090] In some implementations, SurfaceFlinger can also be set in the system library of the Android system, which is not limited in the present application.

[0091] The system critical task timeout detection watchdog (Xcollie) is used to detect whether the action performed in the critical process is completed. Xcollie can set two threads, one of which is used to set the state flag of the critical process to normal when the critical thread starts to perform the action, and to set the state flag of the critical process to abnormal according to whether the action performed by the critical process is timed out, and the other thread is used to poll the state of each critical process and reset the critical process when the state flag of the critical process is abnormal.

[0092] For example, the critical process can be SurfaceFlinger, Vold (volume daemon), AudioFlinger, Face Regconize (face recognition), etc.

[0093] Vold, the volume daemon, is used to manage the hot plug events of the storage class in Android. AudioFlinger is the executor of the audio system policy, responsible for managing the audio stream device and processing and transmitting the audio stream data. Face Regconize is used to implement face recognition and face verification.

[0094] Init is the first process in the user space of the Linux system, that is, the first process in the user space of the Android system based on the Linux kernel. The Init process is mainly responsible for parsing the property file and initializing the property, parsing the script init.rc, triggering the Action and starting the Service, providing system property service management and completing the corresponding trigger event, and maintaining the system-level Service.

[0095] The Init watchdog is used to detect the Init process and reset the Init process when the Init process is abnormal.

[0096] Further, it should be appreciated that the kernel layer is a layer between hardware and software.

[0097] As shown in Figure 2 the kernel layer includes at least a Hungdetect watchdog and a CPU core status watchdog.

[0098] The Hungdetect watchdog is configured to detect the kernel system and control kernel restart when a kernel panic occurs.

[0099] In this embodiment, the Hungdetect watchdog is further configured to detect the System Server WatchDog, the Xcollie, and the Init watchdog, and control kernel restart when any of the System Server WatchDog, the Xcollie, and the Init watchdog fails or when any service detected by the System Server WatchDog, the Xcollie, and the Init watchdog fails to recover.

[0100] The CPU core status watchdog is configured to detect the running status of each core of the CPU and control kernel restart when the CPU core status satisfies a preset kernel restart condition.

[0101] In this embodiment, the hardware watchdog is further configured to detect the Hungdetect watchdog and the CPU core status watchdog, and control the whole machine to restart when any of the Hungdetect watchdog and the CPU core status watchdog fails or when the Hungdetect watchdog and the CPU core status watchdog fail to successfully restart the kernel.

[0102] In this embodiment, the hardware watchdog is further configured to monitor the Hungdetect watchdog and the CPU core status watchdog, for example, monitor the reset action of the Hungdetect watchdog and the CPU core status watchdog. When any of the Hungdetect watchdog and the CPU core status watchdog fails or when the Hungdetect watchdog and the CPU core status watchdog fail to successfully restart the kernel, the hardware watchdog controls the whole machine to restart.

[0103] For example, the kernel layer can further include a software watchdog (hereinafter referred to as a hungtast watchdog) configured to detect whether a process is in a D (uninterruptible sleep) state.

[0104] Correspondingly, in actual applications, the hardware watchdog can further detect the hungtast watchdog.

[0105] It can be understood that the detection of the hungtast watchdog by the hardware watchdog can refer to the detection of the hungdetect watchdog by the hardware watchdog described above, and will not be described again.

[0106] The software structure of the electronic device 100 is introduced here, and it can be understood that, Figure 2 The layers in the software structure shown and the components included 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 can include more or fewer layers than shown, and each layer can include more or fewer components, which are not limited in the present application.

[0107] It can be understood that the electronic device includes hardware and / or software modules corresponding to the execution of each function in order to implement the watchdog detection method in the present application. The algorithm steps of each example described in combination with the embodiments disclosed herein can be implemented in hardware or a combination of hardware and computer software. Whether a certain function is executed in hardware or computer software driven 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 beyond the scope of the present application.

[0108] Based on the hardware structure and software structure described above, the present application provides a watchdog detection method capable of realizing layered and hierarchical recovery. Specifically, in the watchdog detection method, the watchdog of the lower layer of the electronic device can not only detect whether the service of the current layer is abnormal and reset the service of the current layer when the service of the current layer is abnormal, but also detect the watchdog of the upper layer, and reset the service of the current layer when the watchdog of the upper layer is invalid or the watchdog of the upper layer cannot recover the service of the upper layer, so as to realize the recovery of the service of the upper layer.

[0109] It should be noted that the "layer" referred to herein can be divided according to the software and hardware of the electronic device, or can be divided according to the system architecture of the electronic device, which is not limited in the present application.

[0110] Referring to Figure 3 , Figure 3 The system architecture diagram provided by the embodiments of the present application is shown. The watchdog detection method provided by the present embodiment is explained and described below by taking the first layer and the second layer of the electronic device as examples. The first layer is the upper layer of the second layer.

[0111] As Figure 3 shown, the first watchdog is included in the first layer of the electronic device, which is used to detect the first service in the first layer and reset or restart the first service when the first service is abnormal.

[0112] For example, when the first service is running normally, the first service feeds the first watchdog at a first feeding time. When the first service is unable to run normally, the first service stops feeding the first watchdog. If the first watchdog does not receive the first feeding from the first service within one detection period or within a plurality of (e.g., 3) consecutive detection periods, the first watchdog resets or restarts the first service.

[0113] For another example, the first watchdog obtains a first status flag of the first service. When the first service is running normally, the first status flag indicates that the service is normal; when the first service is unable to run normally, the first status flag indicates that the service is abnormal. For example, when the status flag is "ERROR", it indicates that the service is abnormal; when the status flag is "OK", it indicates that the service is normal. If the first status flag obtained by the first watchdog indicates that the first service is abnormal, or if the first status flag obtained by the first watchdog within a plurality of (e.g., 3) consecutive detection periods all indicates that the first service is abnormal, the first watchdog resets or restarts the first service.

[0114] As shown in FIG. 1, the electronic device includes a second watchdog in a second layer of the electronic device, which detects a second service in the second layer and resets or restarts the second service when the second service is abnormal. Figure 3

[0115] For example, when the second service is running normally, the second service feeds the second watchdog at a second feeding time. When the second service is unable to run normally, the second service stops feeding the second watchdog. If the second watchdog does not receive the second feeding from the second service within one detection period or within a plurality of (e.g., 3) consecutive detection periods, the second watchdog resets or restarts the second service.

[0116] For another example, the second watchdog obtains a second status flag of the second service. When the second service is running normally, the second status flag indicates that the service is normal; when the second service is unable to run normally, the second status flag indicates that the service is abnormal. If the second status flag obtained by the second watchdog indicates that the second service is abnormal, or if the second status flag obtained by the second watchdog within a plurality of (e.g., 3) consecutive detection periods all indicates that the second service is abnormal, the second watchdog resets or restarts the second service.

[0117] Continuing to refer to FIG. 1, Figure 3 ​, the second watchdog, in addition to detecting the second service in the second layer, is also used for detecting the first watchdog and performing a reset or restart operation on the second service when the first watchdog is abnormal, so as to reload the first service in the first layer to run after the second service is reset or restarted successfully, so that the first service returns to normal. Wherein, the first watchdog abnormality can mean that the first watchdog fails, or the first watchdog cannot successfully recover or restart the first service.

[0118] For example, when the first watchdog is normally running and the first service detected by it is normally running, the first watchdog performs a third feeding operation on the second watchdog. When the first watchdog cannot normally run, or cannot successfully recover or restart the first service, the first watchdog stops the third feeding operation on the second watchdog. If the second watchdog does not receive the third feeding operation of the first watchdog within a detection period or within a plurality of (such as 3) consecutive detection periods, it performs a reset or restart operation on the second service.

[0119] For another example, the second watchdog acquires a third status mark of the first watchdog. When the first watchdog is normally running and the first service detected by it is normally running, the third status mark of the first watchdog indicates that the service is normal; when the first watchdog cannot normally run, or cannot successfully recover or restart the first service, the third status mark of the first watchdog indicates that the service is abnormal. If the third status mark of the first watchdog acquired by the second watchdog indicates that the service is abnormal, or the third status mark of the first watchdog acquired within a plurality of (such as 3) consecutive detection periods all indicates that the service is abnormal, the second watchdog performs a reset or restart operation on the second service.

[0120] Wherein, when the first watchdog and the second watchdog are both 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 (such as 2 times) of the detection period of the first watchdog for the first service.

[0121] As an optional implementation, the first layer is an application program layer of the electronic device, and the second layer is an application program framework layer of the electronic device. Wherein, the first service is an application program, and the second service is a system service.

[0122] As another optional implementation, the first layer is an application program framework layer of the electronic device, and the second layer is a kernel layer of the electronic device. Wherein, the first service is a system service, and the second service is a kernel system.

[0123] As yet another optional implementation, the first layer is an application program kernel layer of the electronic device, and the second layer is a hardware layer of the electronic device. Wherein, the first service is a kernel system, and the second service is a processing chip.

[0124] It should be noted that the second watchdog triggers the reset or restart operation of the second service, which can be triggered by the first watchdog stopping the second feeding operation or the state flag of the first watchdog indicating service exception, or by the second service stopping the first feeding operation or the state flag of the second service indicating service exception.

[0125] In this way, by setting the detection mechanism between the layers, the layered and hierarchical recovery of the electronic device is realized. Since the second layer is the lower layer of the first layer, the granularity of the service recovery or restart of the second layer is greater than that of the first layer, so that the success rate of the first layer service recovery is higher. When the first watchdog in the first layer of the electronic device fails to successfully recover the first service it detects, the first service in the first layer can be recovered through the second layer (i.e. the next layer), that is, the first service is reloaded and run after the second service is reset or restarted, so that the first service in the first layer is recovered to normal. If the second service in the second layer also fails to successfully recover, it can continue to be recovered through the next layer (i.e. the third layer), thereby avoiding the problem that the reset or restart operation is repeatedly performed in a layer of the electronic device but fails to be successful.

[0126] Based on the layered and hierarchical recovery scheme described above, the following describes several specific scenarios applicable to the layered and hierarchical recovery scheme.

[0127] Scenario One

[0128] In this scenario, a detection mechanism is set between the application framework layer and the kernel layer of the electronic device, and the Hungdetect watchdog in the kernel layer detects the System Server WatchDog in the application framework layer as an example to explain the watchdog detection method provided by the present application.

[0129] Referring to Figure 4 , Figure 4 The flowchart of the System Server WatchDog executing the watchdog detection method is shown as an example.

[0130] As shown in Figure 4 , the flowchart of the System Server WatchDog executing the watchdog detection method includes the following steps:

[0131] Step 101, initializing the system service watchdog during the startup of the system service process.

[0132] As can be seen from the foregoing description, the system service watchdog, i.e. the System Server WatchDog, is used to detect the system service process, i.e. the System Server process, in the application framework layer, for example, to detect whether the System Server process has a deadlock, no response, or other problems.

[0133] In step 102, the system service process detects whether it is running normally according to a preset period.

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

[0135] Correspondingly, when these key services are running normally, it is determined that the system service process is currently running normally, and step 103 is performed; otherwise, it is determined that the system service process cannot run normally, and step 105 is performed.

[0136] In step 103, the system service process sends first feeding information to the system service watchdog.

[0137] For example, in some implementations, the first feeding information sent by the system service process to the system service watchdog can be, for example, "kick" marked information, or other agreed information.

[0138] Based on the working principle of the watchdog, when the system service watchdog receives the first feeding information sent by the system service process within the feeding period, it is considered that the system service process is currently running normally, and no reset operation is required, i.e. after receiving the first feeding information, the system service watchdog does not process the system service process.

[0139] In step 104, the system service watchdog sends second feeding information to the deadlock detection watchdog located in the kernel layer.

[0140] For example, in some implementations, the second feeding information sent by the system service watchdog to the deadlock detection watchdog can be, for example, "kick" marked information, or other agreed information.

[0141] Based on the working principle of the watchdog, when the deadlock detection watchdog receives the second feeding information sent by the system service watchdog within the feeding period, it is considered that the system service process is currently running normally, and no reset operation is required, i.e. after receiving the second feeding information, the deadlock detection watchdog does not restart the kernel system.

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

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

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

[0145] 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 that if the first dog-feeding message from the system service process is not received within n dog-feeding cycles, the dog barking is first triggered, and if the first dog-feeding message from the system service process is not received within (n+m) dog-feeding cycles, the dog bite is then executed.

[0146] Exemplarily, n is an integer greater than 0, and m is an integer greater than 0.

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

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

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

[0150] In addition, for the deadlock detection watchdog, in addition to receiving the first feeding information provided by the system service watchdog from the upper layer, the third feeding information provided by the kernel system detected by the current layer is also received. Therefore, in actual application, the condition for triggering the reset operation of the deadlock detection watchdog can be that the second feeding information is not received within a preset period, or the third feeding information is not received within a preset period.

[0151] In addition, since the second feeding information and the third feeding information are from different objects, the corresponding preset periods can be different, and the specific setting mode can be set according to actual business requirements, which is not limited in the present application.

[0152] In addition, it should be noted that in actual application, the first feeding information can be actively sent by the system service process to the system service watchdog, or can be actively acquired by the system service watchdog from the system service process, which is not limited in the present embodiment.

[0153] Correspondingly, the second feeding information can be actively sent by the system service watchdog to the deadlock detection watchdog, or can be actively acquired by the deadlock detection watchdog from the system service watchdog, which is not limited in the present embodiment.

[0154] Correspondingly, the third feeding information can be actively sent by the kernel system to the deadlock detection watchdog, or can be actively acquired by the deadlock detection watchdog from the kernel system, which is not limited in the present embodiment.

[0155] Therefore, the watchdog detection method provided in the present embodiment can connect the Hungdetect watchdog in the kernel layer by detecting the System Server WatchDog, and when the System Server WatchDog is abnormal and cannot be restored to normal by the reset operation of the Hungdetect watchdog, the Hungdetect watchdog in the kernel layer can perform the reset operation, so that the abnormal business process can be restored to normal based on the above hierarchical and graded recovery principle, and the normal use of the electronic device is ensured.

[0156] In order to better understand the implementation scheme of connecting the Hungdetect watchdog to the System Server WatchDog, the following will be specifically described in combination with Figure 5 .

[0157] Referring to Figure 5 , Figure 5 An application scenario diagram is exemplarily shown.

[0158] As 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.

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

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

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

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

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

[0164] Continue to see Figure 5, Hungdetect watchdog can detect not only the kernel system, but also the System Server WatchDog, and restart the kernel system when the System Server WatchDog is abnormal, so as to reload the System Server process after the kernel restarts successfully, and make the System Server process normal. The abnormality of the System Server WatchDog can refer to the failure of the System Server WatchDog, or the failure of the System Server WatchDog to successfully restart the System Server process.

[0165] When the System Server WatchDog is running normally and the System Server process detected by the System Server WatchDog is running normally, the System Server WatchDog periodically performs a third feeding operation on the Hungdetect watchdog, that is, the System Server WatchDog periodically sends the second feeding information to the Hungdetect watchdog, or the Hungdetect watchdog periodically acquires the third feeding information from the System Server WatchDog. When the System Server WatchDog cannot run normally, or cannot successfully restart the System Server process, the System Server WatchDog stops the third feeding operation on the Hungdetect watchdog.

[0166] If the Hungdetect watchdog does not receive the third feeding operation of the System Server WatchDog within one detection period or a plurality of (such as 3) continuous detection periods, the Hungdetect watchdog restarts the kernel system. Further, after the kernel restarts successfully, the System Server process is reloaded and started to recover to normal.

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

[0168] In this way, by setting the detection mechanism between the kernel layer and the application framework layer, the layered and hierarchical recovery of the electronic device is realized. Since the granularity of the kernel restart is greater than the granularity of the System Server process restart, when the System Server process cannot be restarted successfully, the success rate of recovering the System Server process can be greatly improved by kernel restart, and the problem that the electronic device repeatedly restarts the System Server process but cannot be successful can also be avoided.

[0169] In addition, it should be noted that in an application scenario of restarting the electronic device, the kernel system may start successfully, but the System Server process may not start successfully. At this time, the Hungdetect watchdog in the kernel layer will still detect the System Server WatchDog. Since the System Server process does not start successfully, the System Server WatchDog cannot perform the Hungdetect watchdog feeding operation, and the Hungdetect watchdog will consider that the System Server WatchDog is abnormal, and restart the kernel system again, which may cause the problem of multiple kernel system restarts.

[0170] To solve this problem, the Hungdetect watchdog in the kernel layer is adjusted in the starting time. Wherein, after the System Server starts successfully, the Hungdetect watchdog will start the monitoring function on the System Server WatchDog, not after the kernel system starts.

[0171] When the electronic device is initialized to restart, the System Server is killed, and the System Server WatchDog is also closed to feed the dog. At this time, the System Server WatchDog does not feed the Hungdetect watchdog in the kernel layer any more. Until the System Server is successfully restarted, the System Server WatchDog continues to feed the Hungdetect watchdog.

[0172] In the process of initializing the electronic device, the kernel system is started first, and then the processes in the application framework layer are started. When the kernel system is initialized, the Hungdetect watchdog in the kernel layer is started, but the monitoring function of the Hungdetect watchdog to the System Server WatchDog is not started. When the System Server in the application framework layer is initialized, the Hungdetect watchdog in the kernel layer is instructed to start the monitoring function of the Hungdetect watchdog to the System Server WatchDog.

[0173] For example, when the System Server performs the initialization operation, the indication information is sent to the Hungdetect watchdog in the kernel layer. The indication information is used to indicate that the System Server has been initialized, or is used to instruct the Hungdetect watchdog to start the monitoring function of the Hungdetect watchdog to the System Server WatchDog. Further, the kernel system starts the monitoring function of the Hungdetect watchdog to the System Server WatchDog based on the indication information, so as to realize the monitoring of the System Server WatchDog.

[0174] In this way, since the monitoring function of the Hungdetect watchdog to the System Server WatchDog is started after the System Server is started, at least after the System Server is successfully started once, the problem that the Hungdetect watchdog monitors the System Server WatchDog before the System Server is started can be avoided, and the phenomenon that the Hungdetect watchdog mistakenly considers that the System Server WatchDog is abnormal before the System Server is started and restarts the kernel system can be avoided.

[0175] Scenario two

[0176] In the present scenario, a detection mechanism is set between the application framework layer and the kernel layer of the electronic device, and the Hungdetect watchdog (deadlock detection watchdog) in the kernel layer detects the Xcollie (system key task timeout detection watchdog) in the application framework layer, for example, to explain the watchdog detection method provided by the present application.

[0177] Referring to Figure 6 , Figure 6 The Xcollie accesses the Hungdetect watchdog, which is an example of the flowchart of the watchdog detection method.

[0178] As Figure 6 indicated, the watchdog detection method provided by the present embodiment specifically includes:

[0179] Step 201, initializing the system key task timeout detection watchdog, and setting the state information identifying the key process to a normal mark.

[0180] Specifically, the key process mentioned in the present embodiment may, for example, be the Vold, SurfaceFlinger, AudioFlinger, Face Regconize, etc. mentioned above, which will not be listed one by one, and the present application does not limit this.

[0181] In addition, it should be noted that the timing of initializing the system key task timeout detection watchdog may, in some implementations, be during the process of starting the key process, so that the key detection watchdog can start detecting in time when the function corresponding to the action performed by the key process is called.

[0182] In addition, as can be known from the above description, the system key task timeout detection watchdog is a resident thread in the key process, which is used to detect whether the action performed by the key detection is completed. For example, the action performed by the SurfaceFlinger may be whether the action of rendering the system UI is completed. Therefore, in other implementations, the system key task timeout detection watchdog may also be initialized when the key process is started and the function corresponding to the action performed by the key process is called, so that it can be determined according to the business requirements which actions need to be detected by the system key task timeout detection watchdog, and better adapt to various application scenarios.

[0183] That is, whether to initialize the system key task timeout detection watchdog, whether the system key task timeout detection watchdog detects the completion of the action, can be determined according to the actual business requirements.

[0184] In addition, the state information identifying the critical process can be set as a normal mark, such as "OK", after the system critical task timeout detection watchdog is successfully initialized.

[0185] Correspondingly, the abnormal mark mentioned below can be represented as "ERROR".

[0186] In addition, in some implementations, "1" can be agreed as the normal mark and "0" can be agreed as the abnormal mark as needed.

[0187] It should be understood that the above description is only an example for better understanding the technical solution of the embodiment and is not the only limitation of the embodiment. In actual application, the normal mark and the abnormal mark can be agreed as needed, and the present application does not limit this.

[0188] In step 202, the system critical task timeout detection watchdog records the execution duration of the action of the critical process after detecting that the action call of the critical process is started.

[0189] It can be understood that, in actual application, the action of the critical process is implemented by a function (or program code, hereinafter referred to as function) implementing the action, and the function includes a start node (begin identifier) identifying the start of the action and an end node (end identifier) identifying the end of the action.

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

[0191] In addition, the timeout duration of each action can be reasonably set according to the business characteristics and the time required for the normal completion of the action.

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

[0193] For example, n is an integer greater than 0.

[0194] It should be understood that the above description is only an example for better understanding the technical solution of the embodiment and is not the only limitation of the embodiment.

[0195] In step 203, the system critical task timeout detection watchdog queries whether the end node of the action is called when the execution duration reaches the timeout time corresponding to the action.

[0196] Specifically, when the timeout occurs, i.e. the execution duration reaches the timeout time corresponding to the action but the end node is not invoked, step 204 is performed; otherwise, step 206 is performed.

[0197] In step 204, the system critical task timeout detection watchdog modifies the state information of the critical process from the normal mark to the abnormal mark.

[0198] Specifically, when the timeout occurs, it indicates that the action performed by the critical process is not completed, which may be caused by an abnormality of the critical process. Therefore, in order to enable the system critical task timeout detection watchdog or the critical process detection watchdog to perform the reset operation to restore the critical process to normal, the state information of the critical process needs to be modified from the normal mark to the abnormal mark, such as modifying "OK" to "ERROR". In this way, after the critical process performs the reset operation and is successfully initialized next time, the "ERROR" can be modified back to "OK", and the system critical task timeout detection watchdog can continue to detect the action to be detected.

[0199] In step 205, 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.

[0200] It can be understood that, since 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 the reset operation than the deadlock detection watchdog located in the kernel layer. Therefore, in some implementations, before step 205 is performed, the system critical task timeout detection watchdog can perform the reset operation.

[0201] For example, if the critical process detection watchdog is successfully reset, i.e. the critical process is restored to normal, the state information of the critical process is modified from the abnormal mark to the normal mark, and the normal mark is sent to the deadlock detection watchdog in the kernel layer, so that the deadlock detection watchdog does not bark or even bite (i.e. performs the reset operation on the kernel system) when the preset period (feed dog period) arrives.

[0202] For example, if the critical process detection watchdog is not successfully reset, e.g. the critical process is not restored to normal or the system critical task timeout detection watchdog fails to reset the critical process, in this case, step 205 is performed, i.e. the reset is performed by means of the lower-level deadlock detection watchdog.

[0203] In addition, it needs to be understood that, in actual application, the granularity of the business recovery or restart performed by the stuck detection watchdog located at the lower layer is greater than the granularity of the business recovery or restart performed by the system critical task timeout detection watchdog located at the upper layer, and the influence of the reset operation performed by the stuck detection watchdog on the electronic device is greater than the influence of the reset operation performed by the system critical task timeout detection watchdog on the electronic device, so the period of triggering the reset performed by the stuck detection watchdog is usually greater than the period of triggering the reset performed by the system critical task timeout detection watchdog.

[0204] Based on this, in order to better understand when the reset operation is performed by the system critical task timeout detection watchdog and when the reset operation is performed by the stuck detection watchdog in the watchdog detection scheme in the embodiment, two specific implementation manners are given below.

[0205] Manner 1:

[0206] For example, the system critical task timeout detection watchdog detects the abnormal duration in which the state information of the critical process is in the abnormal mark.

[0207] 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, step 205 is performed.

[0208] It can be understood that, regarding the duration threshold mentioned above, in some implementation manners, the duration threshold can be determined according to the timeout duration of the action that appears timeout, the detection period (which can also be understood as the dog feeding period) of the stuck detection watchdog, and the time delay between the application program framework layer and the kernel layer.

[0209] Manner 2:

[0210] For example, similar to manner 1, the system critical task timeout detection watchdog can still detect the abnormal duration in which the state information of the critical process is in the abnormal mark. The difference is that, in this manner, whether the reset operation is continued to be performed by the system critical task timeout detection watchdog or the reset operation is performed by the stuck detection watchdog is determined by judging the timeout number. Therefore, after obtaining the abnormal duration, the system critical task timeout detection watchdog can determine the timeout number according to the abnormal duration and the timeout duration.

[0211] Correspondingly, 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, step 205 is performed.

[0212] Regarding the setting of the timeout number, similar to the setting of the duration threshold, the timeout number can be set according to the business requirement combined with the actual situation, and the present application does not limit this.

[0213] It should be understood that the above description is only an example for better understanding the technical solutions of the embodiments and is not the only limitation of the embodiments.

[0214] In addition, it should be noted that in actual applications, in addition to the system critical task timeout detection watchdog in the application framework layer, there are also system service watchdogs, initialization watchdogs and other watchdogs for detecting different business processes. Therefore, in order to enable the lower-layer dead lock detection watchdog to detect different watchdogs in the upper layer, a pre-packaged common node for deciding whether to perform a reset operation by the dead lock detection watchdog can be set in the kernel layer.

[0215] Correspondingly, the exception flag sent by the system critical task timeout detection watchdog to the dead lock detection watchdog is specifically sent to the common node in the kernel layer in the implementation scheme in which the common node is set.

[0216] For example, the common node is pre-installed with a preset strategy, that is, a strategy for deciding whether to perform a reset operation by the dead lock detection watchdog. Therefore, after receiving the exception flag sent by the watchdog in the upper layer, for example, the system critical task timeout detection watchdog in the embodiment, the common node determines whether a reset operation needs to be performed by the dead lock detection watchdog according to the exception flag and the preset strategy.

[0217] Correspondingly, the common node notifies the dead lock detection watchdog to perform a reset operation through processing when it is determined that a reset operation needs to be performed by the dead lock detection watchdog.

[0218] For example, in some implementation manners, the common node can actively send a reset instruction to the dead lock detection watchdog when it is determined that a reset operation needs to be performed by the dead lock detection watchdog, or the dead lock detection watchdog can periodically obtain instruction information decided by the common node from the common node, and then perform a reset operation when the reset instruction is obtained.

[0219] In addition, it should be noted that in order to enable the technical solutions provided in the embodiment to be applicable to more application scenarios and meet different business requirements, in actual applications, the execution process of which actions appear abnormal can be identified according to business requirements, and the lower-layer dead lock detection watchdog can be used for resetting.

[0220] For example, the above operation can be performed when a critical process is started, a function corresponding to an action performed by the critical process is called, and a layered recovery flag is set for the function corresponding to the action performed by the critical process when the system critical task timeout detection watchdog is initialized. In this way, when the state information of the critical process is an abnormal state and the action performed by the critical process is set by the layered recovery flag, the system critical task timeout detection watchdog will notify the dead lock detection watchdog to perform a reset operation.

[0221] It should be noted that the hierarchical recovery mark described above can be set as needed in actual application, and is not limited this time.

[0222] 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, so that the deadlock detection watchdog does not need to consider whether the critical process corresponding to the exception mark sets the hierarchical recovery mark after receiving the exception mark, or the public node receiving the exception mark, and by default, all received exception marks set the hierarchical recovery mark, that is, the deadlock detection watchdog intervenes.

[0223] 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, so that the deadlock detection watchdog does not need to consider whether the critical process corresponding to the exception mark sets the hierarchical recovery mark after receiving the exception mark, or the public node receiving the exception mark, and by default, all received exception marks set the hierarchical recovery mark, that is, the deadlock detection watchdog intervenes.

[0224] It should be understood that the above description is only an example for better understanding the technical scheme of the embodiment and is not the only limitation of the embodiment.

[0225] Step 206, stop detecting the action executed by the critical process.

[0226] It can be understood that in actual application, the change of the critical process state is shown in Table 1.

[0227] Table 1 Critical process state change table

[0228] Scenario State Initialization (init) Normal End of execution (end) Normal Execution timeout (Timeout) Exception

[0229] That is, if the end node is called within the timeout duration, it means that the action executed this time ends normally, in which case the system critical task timeout detection watchdog does not need to be processed, that is, it does not need to be reset. Therefore, after the action executed this time ends normally, the system critical task timeout detection watchdog can stop detecting the action executed by the critical process, thereby saving the occupation of the electronic device system resource.

[0230] Further, it is to be noted that when the end node is invoked in implementing the watchdog detection method provided by the embodiment based on the above-mentioned layered hierarchical recovery scheme, the state information identifying the critical process can also be sent to the Hungdetect watchdog of the lower layer, i.e., the kernel layer. For this case, the state information sent by the system critical task timeout detection watchdog to the Hungdetect watchdog is specifically a normal mark identifying that the critical process is in a normal state, for example, "OK".

[0231] Further, in some implementations, when the detection of the action ends, the information sent by the system critical task timeout detection watchdog to the Hungdetect watchdog can also be state information identifying that the action ends normally, so that the Hungdetect watchdog does not consider that the critical process is abnormal or that the system critical task timeout detection watchdog is invalid, and thus does not perform the reset operation, when the Hungdetect watchdog does not receive the state information about the execution of the action by the critical process within a preset period (dog feeding period).

[0232] Therefore, the watchdog detection method provided by the embodiment can make the abnormal business process return to normal based on the principle of the above-mentioned layered hierarchical recovery, by connecting the Xcollie detecting the critical process to the Hungdetect watchdog of the kernel layer, so that the Hungdetect watchdog of the kernel layer performs the reset operation when the Xcollie is abnormal and cannot restore the detected business process to normal through the reset, thereby ensuring the normal use of the electronic device.

[0233] In order to better understand the implementation scheme of connecting the Xcollie to the Hungdetect watchdog, the following will be specifically described in combination with Figure 7 .

[0234] Referring to Figure 7 , Figure 7 , an application scenario shown by way of example is schematically shown.

[0235] As shown in Figure 7 , the Xcollie is included in the application framework layer of the electronic device, for detecting whether the action performed by the critical process SurfaceFlinger is completed, for example, detecting whether the UI operation of the rendering system is completed.

[0236] It is appreciated that SurfaceFlinger is started in the System Server process and is responsible for managing the frame buffer of the device. SurfaceFlinger creates two threads in the process of starting, 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 UI of the system. Specifically, SurfaceFlinger can be used to manage the display subsystem and provide 2D and 3D layer fusion for multiple applications.

[0237] Xcollie is used to detect whether the action performed in the critical process is completed. Wherein, Xcollie can set two threads, one thread (hereinafter referred to as thread C) is used to set the state flag of the critical process to normal when the critical thread starts to perform the action, and determine whether to set the state flag of the critical process to abnormal according to whether the action performed by the critical process is timeout, and one thread (hereinafter referred to as thread D) is used to poll the state of each critical process, and reset the critical process when the state flag of the critical process is abnormal.

[0238] Based on the characteristics of Xcollie and SurfaceFlinger, please continue to refer to Figure 7 , the first state flag obtained by Xcollie from SurfaceFlinger, specifically obtained by thread D in Xcollie.

[0239] Exemplarily, in some implementations, the first state flag can be determined by thread D according to the console events detected by thread A and / or the progress information of thread B in SurfaceFlinger.

[0240] Exemplarily, in some other implementations, the information for determining the first state flag can be sent by thread A and thread B in SurfaceFlinger to Xcollie, and then thread D in Xcollie determines the first state flag according to the received information.

[0241] Please continue to refer to Figure 7 When the action performed by SurfaceFlinger is normally executed, the first state flag obtained by Xcollie is a normal flag, for example, "OK", and when the action performed by SurfaceFlinger appears timeout, the first state flag obtained by Xcollie is an abnormal flag, for example, "ERROR".

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

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

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

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

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

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

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

[0249] It can be understood that, in some implementations, whether the Xcollie actively sends the second status mark to the Hungdetect watchdog or the Hungdetect watchdog actively acquires the second status mark from the Xcollie, the preset period can be performed, that is, the second status mark is sent or acquired at a preset period.

[0250] It should be noted that, in actual applications, the second status mark can be the same as or different from the first status mark.

[0251] For example, when the first status mark is a normal mark, if the Xcollie is normal (valid), the second status mark is the same as the first status mark, that is, the second status mark is also a normal mark.

[0252] For example, when the first status mark is a normal mark, if the Xcollie is abnormal (invalid), the second status mark is different from the first status mark, that is, the second status mark is an abnormal mark.

[0253] For example, when the first status mark is an abnormal mark, whether the Xcollie is normal or not, the second status mark is the same as the first status mark, that is, the second status mark is an abnormal mark.

[0254] That is, for the scenario in which the Xcollie accesses the Hungdetect, whether the Xcollie can normally run or whether the SurfaceFlinger process can be restarted, the Hungdetect watchdog can acquire the second status mark.

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

[0256] Specifically, if the Hungdetect watchdog does not query any information provided by the Xcollie and cannot detect the current state of the Xcollie, an abnormal second status mark can be generated.

[0257] For example, if the Hungdetect watchdog does not acquire the second status mark indicating that the SurfaceFlinger process is restored to normal or does not acquire the information indicating that the Xcollie stops detecting the action of the SurfaceFlinger within one detection period or within a plurality of (for example, 3) continuous detection periods, the kernel system is restarted. Further, after the kernel is successfully restarted, the SurfaceFlinger process is reloaded and started to restore normal.

[0258] Further, it is understandable that, in order to ensure the implementation of the scheme, the detection period of the Hungdetect watchdog on the Xcollie is longer than the detection period of the Xcollie on the SurfaceFlinger process.

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

[0260] In this way, by setting the detection mechanism between the kernel layer and the application framework layer, the layered and hierarchical recovery of the electronic device is realized. Since the granularity of the kernel restart is greater than the granularity of the SurfaceFlinger process restart, when the SurfaceFlinger process cannot be restarted successfully, the success rate of recovering the SurfaceFlinger process can be greatly improved by kernel restart, and the problem that the electronic device application framework layer repeatedly restarts the SurfaceFlinger process but cannot be successful can also be avoided.

[0261] Scenario three

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

[0263] Referring to Figure 8 , Figure 8 To illustrate, the common node pre-packaged in the kernel layer is used to connect the multiple software watchdogs in the application framework layer to the Hungdetect watchdog, so as to realize that the Hungdetect watchdog can simultaneously detect multiple software watchdogs in the application framework layer.

[0264] As Figure 8 indicated, the watchdog detection method provided by the present embodiment uses the common node pre-packaged in the kernel layer, and specifically includes:

[0265] Step 301, the common node receives information provided by each software watchdog in the application framework layer.

[0266] For example, the above-mentioned software watchdogs can be System Server WatchDog, Xcollie, Init watchdog, etc., which will not be listed one by one this time, and the present application does not limit this.

[0267] Correspondingly, the information provided by each software watchdog described above is related to the characteristics of the software watchdog in actual application.

[0268] For example, for the System Server WatchDog, the information provided can be the second feeding information described in scenario one above.

[0269] It can be understood that when the information provided by the System Server WatchDog is the second feeding information, it indicates that the System Server WatchDog is effective and the System Server process detected by the System Server WatchDog is also normal.

[0270] Correspondingly, in some implementation scenarios, the information provided by the System Server WatchDog can also not be the second feeding information, for example, when the System Server WatchDog is ineffective or the System Server process detected by the System Server WatchDog is abnormal, the System Server WatchDog will stop providing the second feeding information, in which case, the System Server WatchDog can no longer provide information, or set the provided information to be "null", or in order to facilitate informing the lower layer public node that the current has been abnormal, the agreed abnormal information can be provided.

[0271] The information provided by the Xcollie can be the second state flag described in scenario two above. According to the description of scenario two, when the reset operation needs to be performed by means of the Hungdetect watchdog, the second state flag is an abnormal flag, and when the Xcollie and the corresponding key process are normal, the second state flag provided is a normal flag.

[0272] It should be understood that the above description is only an example for better understanding the technical solutions of the embodiments and is not the only limitation of the embodiments.

[0273] Step 302, the public node determines the priority of the information provided by each software watchdog according to the business process corresponding to each software watchdog.

[0274] For example, in the Android system, most of the key processes are registered and started in the System Server process, so the System Server process is normally the prerequisite for ensuring the normality of other key processes, and therefore in some implementations, the information related to the System Server process can be determined as the first priority, and the information provided by other key processes running in the System Server process can be determined as the second priority, i.e., the first priority is higher than the second priority.

[0275] Based on this, if the information is provided by the System Server WatchDog, the priority is determined as the first priority, and if the information is provided by the Xcollie, the priority is determined as the second priority.

[0276] It should be understood that the above description is only an example for better understanding the technical solutions of the embodiments and is not the only limitation of the embodiments. In actual applications, the priorities of different business processes can be reasonably set according to other business requirements to better adapt to various application scenarios.

[0277] In step 303, the public node determines whether to perform a reset operation according to the preset decision and the priority of the information provided by each software watchdog.

[0278] For example, in some implementations, the preset decision can stipulate that when the information of the first priority is the second feeding dog information, i.e., the System Server process is normal, regardless of the content of the information provided by other software watchdogs, the current dead lock detection watchdog does not need to intervene to perform a reset operation.

[0279] For example, in some implementations, the preset decision can stipulate that when the information of the first priority is the second feeding dog information, and the information provided by other software watchdogs (such as N) has n abnormal information, it is determined that the current dead lock detection watchdog needs to intervene to perform a reset operation.

[0280] For example, n is an integer greater than 1, and N is an integer greater than n.

[0281] For example, the public node receives a total of 5 pieces of information of software watchdogs in a detection period, one of which is provided by the System Server WatchDog, and 4 (i.e., the above-mentioned N) are provided by other software watchdogs (2 pieces of information are normal information, and 2 pieces of information are abnormal information), if it is stipulated that n≥2, the dead lock detection watchdog needs to intervene to perform a reset operation, then in this case, the decision information made by the public node is a reset instruction.

[0282] For example, in another implementation, the preset decision can provide that, when the first priority information is the second feeding dog information mentioned above, and the software watchdog providing the second priority information is a designated software watchdog, for example, a reset flag is set, it is determined that the current needs the stuck detection watchdog to intervene to perform the reset operation.

[0283] Further, on the basis of the above, it can also be considered that each software watchdog of the upper layer fails, or that the detected business process exception is time, if it does not recover normally for a plurality of consecutive periods (such as 3), the common node determines that the current needs the stuck detection watchdog to intervene to perform the reset operation.

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

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

[0286] Step 304, the common node provides a reset instruction to trigger the stuck detection watchdog to perform the reset operation.

[0287] For the description of the reset operation performed by the stuck detection watchdog, see the above scene one and scene two, which will not be repeated here.

[0288] Step 305, the common node provides the agreed feeding dog information to the stuck detection watchdog.

[0289] It can be understood that the common node can provide the agreed feeding dog information, for example, a "kick" flag, or an "OK" flag, etc., so that the stuck detection watchdog knows that the software watchdog of the upper layer and the detected business process are normal, and the current does not need to intervene to restart the kernel system.

[0290] Therefore, the watchdog detection method provided by the embodiment pre-packages the common node which can decide whether the lower layer software watchdog performs the reset when the upper layer software watchdog fails to successfully reset the abnormal business process, the common node uniformly interfaces the state flag sent by the upper layer different software watchdogs, which identifies the state of the business process detected by the software watchdog of the upper layer / the action performed by the business process, the stuck detection watchdog is notified to perform the reset only when it is determined that the stuck detection watchdog needs to perform the reset, so that the layered and hierarchical recovery scheme in the application is more reasonable.

[0291] In addition, the public node can determine a processing result according to feeding information from different software watchdogs in an upper layer, state flag decision, so as to reduce the restart operation of the kernel system by the dead lock detection watchdog as much as possible without affecting the use of the electronic device by the user, and reduce resource consumption.

[0292] In order to better understand the implementation scheme of the multiple software watchdogs in the application framework layer accessing the Hungdetect watchdog, the following takes the Hungdetect watchdog in the kernel layer simultaneously detecting the System Server WatchDog and the Xcollie in the application framework layer as an example to explain the watchdog detection method provided by the present application.

[0293] Referring to Figure 9 , Figure 9 An application scenario diagram is shown by way of example.

[0294] As Figure 9 shown, the System Server WatchDog, the System Server process detected by the System Server WatchDog, the Xcollie, and the key process corresponding to the Xcollie, such as the SurfaceFlinger, are included in the application framework layer of the electronic device; the Hungdetect watchdog for detecting whether the kernel system is running normally is included in the kernel layer of the electronic device; and the public node for respectively communicating with the System Server WatchDog, the Xcollie, and the Hungdetect watchdog in the kernel layer is included.

[0295] Regarding the System Server WatchDog detecting the System Server process, the System Server process performs a first feeding operation on the System Server WatchDog, when to restart the System Server process, and when the System Server WatchDog performs a second feeding operation (the second feeding information in scenario one), which are described in detail in scenario one, and will not be repeated here.

[0296] Regarding the Xcollie detecting the action in the SurfaceFlinger, how the Xcollie obtains the first state flag of the SurfaceFlinger, when to restart the SurfaceFlinger, and when the Xcollie provides the second state flag, which are described in detail in scenario two, and will not be repeated here.

[0297] As to 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 scenario one or scenario two about how the Hungdetect watchdog detects the kernel system of the current layer, which will not be repeated here.

[0298] The following will be described in combination with Figure 9 The common node is used to write the second feeding operation and the second state mark into the kernel layer, and to decide whether to perform the reset operation by the Hungdetect watchdog, instead of directly giving to the Hungdetect watchdog.

[0299] For example, in the implementation, the common node can be pre-installed with preset strategies according to business requirements, i.e. the strategies for deciding whether to perform the reset operation by the Hungdetect watchdog.

[0300] Therefore, the common node will decide whether to perform the reset operation by the Hungdetect watchdog according to the pre-installed preset strategies, and the obtained feeding information and state mark.

[0301] As to the above-mentioned obtained feeding information, in some implementation scenarios, the obtained information can be the information describing that the SystemServer WatchDog is normal. For this case, it indicates that the monitored System Server process is also normal, and the feeding of the SystemServer WatchDog to the Hungdetect watchdog is normal.

[0302] Correspondingly, in other implementation scenarios, the obtained information can be the information describing that the SystemServer WatchDog is abnormal, or the SystemServer WatchDog is normal but the monitored System Server process is abnormal, and the SystemServer WatchDog stops providing the feeding information to the Hungdetect watchdog, i.e. cannot perform the second feeding operation, which can also be understood as that the feeding of the SystemServer WatchDog to the Hungdetect watchdog is abnormal.

[0303] As to the above-mentioned state mark, in some implementation scenarios, it can be a normal mark, i.e. Xcollie and SurfaceFlinger are both normal. In other implementation scenarios, it can be an abnormal mark, i.e. at least one of Xcollie and SurfaceFlinger is abnormal.

[0304] Correspondingly, the common node will obtain the decision information through processing.

[0305] Exemplarily, in some implementations, the common node processes the obtained decision information, which can be actively pushed to the Hungdetect watchdog or actively acquired by the Hungdetect watchdog from the common node.

[0306] Taking the decision information as an example that the Hungdetect watchdog needs to perform a reset operation, in one scenario, the common node actively informs the Hungdetect watchdog to perform the reset operation when it determines that the Hungdetect watchdog needs to perform the reset operation. In another scenario, the common node can first save the decision information when it determines that the Hungdetect watchdog needs to perform the reset operation, and wait for the Hungdetect watchdog to periodically acquire the decision information determined by the common node from the common node, and then perform the reset operation when the reset instruction is acquired.

[0307] Correspondingly, when the decision information obtained is not required to be executed by the Hungdetect watchdog to perform the reset operation, the Hungdetect watchdog can be uniformly sent the agreed feeding information to realize feeding, so as to avoid the Hungdetect watchdog triggering the dog bark, and even the dog bite.

[0308] Exemplarily, in some implementations, the common node in the kernel layer is used to store the kick dog information of the software watchdog to the Hungdetect watchdog and the process state information sent in the application framework layer. The kick dog information can include the name of the software watchdog and the kick action (kick), and the process state information can include the name of the software watchdog and the process state (OK or ERROR). The Hungdetect watchdog, as a consumer of the common node, can periodically (or periodically) check the kick dog information and the process state information (such as OK or ERROR) stored in the common node.

[0309] The Hungdetect watchdog determines whether to perform the operation of resetting the kernel system based on the kick dog information and / or the process state information acquired in the common node periodically (or periodically) and the preset strategy. The preset strategy can be the priority of the preset decision and the information provided by each software watchdog mentioned above, which will not be described herein.

[0310] It should be understood that the above description is only an example for better understanding the technical scheme of the embodiment and is not the only limitation of the embodiment.

[0311] Scenario four

[0312] In the present scenario, a detection mechanism is arranged between the kernel layer and the hardware layer of the electronic device, and the Hungdetect watchdog in the kernel layer is detected by the hardware watchdog in the hardware layer. The watchdog detection method provided by the present application is explained and described by taking the Hungdetect watchdog as an example.

[0313] Figure 10 An application scenario shown by way of example is schematically shown in the accompanying drawings.

[0314] As shown in Figure 10 , the Hungdetect watchdog is included in the kernel layer of the electronic device, and is used to detect whether the kernel system is running normally.

[0315] When the kernel system is running normally, the kernel system performs a first feeding operation on the Hungdetect watchdog at a regular time. When the kernel system is unable to run normally, the kernel system stops the first feeding operation on the Hungdetect watchdog. If the Hungdetect watchdog does not receive the first feeding operation from the kernel system within one detection period or within a plurality of (for example, 3) consecutive detection periods, the Hungdetect watchdog restarts the kernel system.

[0316] As shown in Figure 10 , the hardware watchdog (Hardware WatchDog) is included in the hardware layer of the electronic device, and is used to detect the hardware chip.

[0317] When the program in the hardware chip is running normally, the hardware chip performs a second feeding operation on the hardware watchdog at a regular time, such as setting the first timer of the hardware watchdog to zero to make it start timing again. When the program in the hardware chip is running abnormally, the second feeding operation on the hardware watchdog is stopped.

[0318] When the hardware watchdog does not receive the second feeding operation from the hardware chip, and the first timer increases to a first set value, the hardware watchdog resets the hardware chip to restart the electronic device. Here, the detection period corresponding to the first timer is the detection period of the hardware watchdog for detecting the hardware chip. The first timer in the hardware watchdog is used to implement the first timing operation.

[0319] Continuing to refer to Figure 10 , the hardware watchdog can not only detect the hardware chip, but also detect the Hungdetect watchdog, and reset the hardware chip when the Hungdetect watchdog is abnormal, so as to restart the electronic device and restore the kernel system. The Hungdetect watchdog abnormality can refer to the Hungdetect watchdog failure, or the Hungdetect watchdog being unable to successfully restart the kernel system.

[0320] When the Hungdetect watchdog is running normally and the kernel system detected by the Hungdetect watchdog is running normally, the Hungdetect watchdog performs a third feeding operation on the Hungdetect watchdog, such as resetting the second time of the hardware watchdog to zero, so that the hardware watchdog restarts counting. When the Hungdetect watchdog cannot run normally or cannot successfully restart the kernel system, the Hungdetect watchdog stops the third feeding operation on the hardware watchdog.

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

[0322] When the second time increases to the second set value without receiving the third feeding operation of the Hungdetect watchdog, the hardware watchdog resets the hardware chip, and the electronic device is restarted. Here, the detection period corresponding to the second time is the detection period of the hardware watchdog for detecting the Hungdetect watchdog. The second timer in the hardware watchdog is used to implement the operation of the second time.

[0323] In this way, by setting the detection mechanism between the hardware layer and the kernel layer, the layered and hierarchical recovery of the electronic device is achieved. Since the granularity of hardware restart is greater than that of kernel restart, when the kernel cannot be successfully restarted, the success rate of recovering the kernel system can be greatly improved by hardware restart, and the problem that the kernel system cannot be successfully restarted repeatedly in the kernel layer of the electronic device can also be avoided.

[0324] Scenario five

[0325] In this scenario, a detection mechanism is set between the kernel layer and the hardware layer of the electronic device. For example, the hardware watchdog in the hardware layer detects the CPU core state watchdog in the kernel layer.

[0326] Figure 11 An application scenario diagram is shown for illustration.

[0327] As Figure 11 shown, the CPU core state watchdog is included in the kernel layer of the electronic device, and is used to check the running state of the CPU and control the kernel to restart when the running state of the CPU meets a preset kernel restart condition.

[0328] Specifically, the CPU core state watchdog can be used to detect the running state of each CPU core and control the kernel to restart when the running state of each CPU core meets a preset kernel restart condition.

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

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

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

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

[0333] The CPU core state watchdog determines the running state of each CPU core by detecting whether each target task (Tast 0-Tast 7) can be scheduled on the CPU core to which it is bound. 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 state watchdog can determine that the CPU0 core is in an abnormal running state. For example, if Tast 7 can be scheduled on the CPU0 core to which it is bound, the CPU core state watchdog can determine that the CPU7 core is in a normal running state. In this way, the CPU core state watchdog can determine the running state of each CPU core.

[0334] For example, the running state of a CPU core can be identified using "1" and "0". For example, when the running state of a CPU core is "1", the CPU core is in a normal running state; when the running state of a CPU core is "0", the CPU core is in an abnormal running state. Further, the first detection task detects whether each target task can be scheduled on the CPU core to which it is bound, and generates a running state identifier corresponding to each CPU core according to the detection result, and the CPU core state watchdog can determine whether the running state of each CPU core is abnormal according to the running state identifier generated by the first detection task. The number of bits in the running state identifier is the same as the number of CPU cores. For example, a CPU includes eight cores, CPU0, CPU1, CPU2,..., and CPU7, and the running state identifier can include eight bits, and the values of the eight bits identify the running state of each CPU core in turn. Assuming that the running state identifier generated by the first detection task is "111111101", the CPU core state watchdog can determine that the running state of the CPU6 core is abnormal and the running state of the other CPU cores is normal according to the running state identifier.

[0335] As another optional implementation, the CPU core state watchdog can determine the running state of the CPU core based on the probe message.

[0336] For example, the CPU core state watchdog can determine the running state of the CPU core based on the probe message every 30 seconds through the second detection task.

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

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

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

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

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

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

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

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

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

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

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

[0348] Continue to see Figure 11The hardware watchdog can detect not only the hardware chip, but also the CPU core state watchdog, and reset the hardware chip when the CPU core state watchdog is abnormal, so as to restart the whole electronic device and restore the kernel system. The CPU core state watchdog abnormality can refer to the failure of the CPU core state watchdog, or the failure of the CPU core state watchdog to successfully restart the kernel system.

[0349] When the CPU core state watchdog is running normally and the CPU core state detected by the CPU core state watchdog does not meet the preset kernel restart condition, the CPU core state watchdog performs a third feeding operation on the Hungdetect watchdog, such as setting the second timer of the hardware watchdog to zero, so that the hardware watchdog restarts the timing. When the CPU core state watchdog cannot run normally, or cannot successfully restart the kernel system, the CPU core state watchdog stops the third feeding operation on the hardware watchdog.

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

[0351] When the hardware watchdog does not receive the third feeding operation of the CPU core state watchdog, if the second timer increases to the second set value, the hardware watchdog resets the hardware chip to restart the whole electronic device. Here, the detection period corresponding to the second timer is the detection period of the hardware watchdog for detecting the CPU core state watchdog. The second timer in the hardware watchdog is used to implement the operation of the second timer.

[0352] In an embodiment, the hardware watchdog can detect not only the hardware chip, but also the CPU core state watchdog and the Hungdetect watchdog in the kernel layer. In this case, the second timer and the third timer can be set in the hardware watchdog to detect the feeding operation of the CPU core state watchdog and the Hungdetect watchdog to the hardware watchdog, respectively. For example, when the hardware watchdog does not receive the feeding operation of the CPU core state watchdog, if the second time increases to the second set value, the hardware chip is reset to realize the restart of the electronic device. When the hardware watchdog does not receive the feeding operation of the Hungdetect watchdog, if the third time increases to the third set value, the hardware chip is reset to realize the restart of the electronic device. Here, the detection period corresponding to the second time is the detection period of the hardware watchdog for detecting the CPU core state watchdog, and the detection period corresponding to the third time is the detection period of the hardware watchdog for detecting the Hungdetect watchdog. The detection period of the hardware watchdog for detecting the CPU core state watchdog, i.e., the detection period corresponding to the second time, is longer than the detection period of the CPU core state watchdog, and the detection period of the hardware watchdog for detecting the Hungdetect watchdog, i.e., the detection period corresponding to the third time, is longer than the detection period of the Hungdetect watchdog. The first set value, the second set value, and the third set value are not limited in the embodiment.

[0353] If the hardware watchdog can also detect other watchdogs in the kernel layer, the processing manner can refer to the detection of the Hungdetect watchdog or the CPU core state watchdog by the hardware watchdog, which will not be described herein.

[0354] In this way, by setting the detection mechanism between the hardware layer and the kernel layer, the layered and hierarchical recovery of the electronic device is realized. Since the granularity of hardware restart is greater than that of kernel restart, when the kernel cannot be restarted successfully, the hardware restart can greatly improve the success rate of recovering the kernel system, and the problem that the kernel system cannot be successfully restarted repeatedly in the kernel layer of the electronic device can also be avoided.

[0355] Scenario six

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

[0357] Figure 14 An application scenario is exemplarily shown in a schematic diagram.

[0358] As Figure 14As shown, the System Server WatchDog, the Xcollie, and the Init watchdog are included in the application framework layer of the electronic device. The System Server WatchDog is configured to detect the System Server process in the application framework layer, for example, to detect whether the System Server process is deadlocked, unresponsive, or the like. The Xcollie is configured to detect whether the action performed by the key process SurfaceFlinger is completed, for example, to detect whether the UI operation of the rendering system is completed. The Init watchdog is configured to detect the Init process.

[0359] The Hungdetect watchdog and the CPU core state watchdog are included in the kernel layer of the electronic device. The Hungdetect watchdog is configured to detect the kernel system, for example, to detect whether the kernel system is deadlocked. The CPU core state watchdog is configured to detect the running state of each core of the CPU, for example, to detect whether each core of the CPU is abnormally running.

[0360] The hardware watchdog is included in the hardware layer of the electronic device. The first hardware watchdog, the second hardware watchdog, and the third hardware watchdog shown in the above are different hardware watchdogs with different processing logics for different chips and different platforms. Figure 14 The first hardware watchdog, the second hardware watchdog, and the third hardware watchdog shown in the above can be understood as hardware watchdogs with different processing logics for different chips and different platforms. The technical solution provided in the embodiments of the present application can adapt to different hardware watchdogs, for example, the first hardware watchdog, the second hardware watchdog, and the third hardware watchdog shown in the above. Figure 14 The first hardware watchdog, the second hardware watchdog, and the third hardware watchdog shown in the above can be understood as hardware watchdogs with different processing logics for different chips and different platforms. The technical solution provided in the embodiments of the present application can adapt to different hardware watchdogs, for example, the first hardware watchdog, the second hardware watchdog, and the third hardware watchdog shown in the above.

[0361] Referring to Figure 14 In the present embodiment, the Hungdetect watchdog in the kernel layer can not only detect the kernel system, but also detect the System Server WatchDog, the Xcollie, and the Init watchdog in the application framework layer.

[0362] In the present embodiment, the kernel layer sets a common node configured to store the kick-dog information of the software watchdog in the application framework layer to the Hungdetect watchdog and the process state information sent by the Hungdetect watchdog. The Hungdetect watchdog, as a consumer of the common node, can periodically check the kick-dog information stored in the common node and the process state information (such as OK or ERROR) sent by the Hungdetect watchdog.

[0363] Further, the Hungdetect watchdog periodically acquires the kick-dog information stored in the public node and the process state information, and determines whether to perform a kernel restart operation according to a preset strategy.

[0364] Optionally, when the Hungdetect watchdog detects an exception of any software watchdog in the application framework layer, the Hungdetect watchdog performs a kernel restart operation to recover the corresponding process in the application framework layer through the kernel restart.

[0365] Optionally, when the Hungdetect watchdog detects exceptions of multiple software watchdogs in the application framework layer, the Hungdetect watchdog performs a kernel restart operation to recover the corresponding process in the application framework layer through the kernel restart.

[0366] Optionally, when the Hungdetect watchdog detects that any software watchdog in the application framework layer is abnormal for multiple continuous periods, the Hungdetect watchdog performs a kernel restart operation to recover the corresponding process in the application framework layer through the kernel restart.

[0367] For example, assuming that the Hungdetect watchdog does not acquire the kick-dog information of the System Server WatchDog for three continuous periods, or acquires the process state information sent by the Xcollie for three continuous periods and the process state information is ERROR, the Hungdetect watchdog performs a kernel restart operation.

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

[0369] If the Hungdetect watchdog or the CPU core state watchdog does not perform the kick-dog operation on the first hardware watchdog in time, the first hardware watchdog resets the hardware chip detected thereby, and restarts the whole machine to recover the kernel system through the restart of the whole machine.

[0370] For details not explained in this scenario, refer to the description in the foregoing scenario, which will not be repeated here.

[0371] In this way, by setting the detection mechanism between the electronic device layers, the layered and hierarchical recovery of the electronic device is achieved. Since the granularity of the next recovery is greater than that of the upper layer recovery, when the upper layer cannot be successfully recovered, the success rate of the upper layer recovery is improved through the lower layer restart, and the problem that a certain layer of the electronic device cannot be successfully recovered through repeated restarts is also avoided.

[0372] In addition, it should be noted that, in order to adapt the watchdog detection method provided in the present application to different chip platforms, so as to realize multi-level dog watching, so as to realize comprehensive coverage of the electronic device, and ensure that the electronic device can be normally used, a pre-packaged adaptation node can also be set in the kernel layer, so that the CPU core state watchdog and Hungdetect watchdog in the kernel layer can be detected by the hardware watchdog provided by different chip platforms.

[0373] For example, because the hardware watchdogs of different platforms require different time to load, in the same time, the dog-feeding information provided by the CPU core state watchdog is not acquired, for different hardware watchdogs, some of them can be considered as normal, and some of them can be considered as abnormal, and then the dog barking and even dog biting are executed. Therefore, in order to ensure that the technical solution of the present application can adapt to different hardware watchdogs, when the electronic device is started, the closing interface of the hardware watchdog can be called to close it, and after the upper-layer software watchdogs are started, the hardware watchdog is started.

[0374] In addition, in the specific implementation, in order to simplify the calling program and avoid code redundancy, the interfaces for initializing the hardware dog, triggering the dog biting (executing the reset) and stopping the dog feeding can be uniformly packaged, and then the processing logic of the hardware dog currently used by the electronic device is called through the uniform interfaces, so that one set of solutions can adapt to different hardware watchdogs.

[0375] The embodiment also provides a computer storage medium, which stores computer instructions, when the computer instructions run on the electronic device, the electronic device executes the related method steps to realize the watchdog detection method in the above embodiment.

[0376] The embodiment also provides a computer program product, when the computer program product runs on the computer, the computer executes the related steps to realize the watchdog detection method in the above embodiment.

[0377] In addition, the embodiment of the present application also provides a device, which can be a chip, a component or a module. The device can include a processor and a memory connected to each other. The memory is used to store computer execution instructions. When the device runs, the processor can execute the computer execution instructions stored in the memory, so that the chip executes the watchdog detection method in the above method embodiments.

[0378] The electronic device, the computer storage medium, the computer program product or the chip provided in the embodiment can execute the corresponding method provided in the above, and the beneficial effects that can be achieved are referred to the beneficial effects of the watchdog detection method provided in the above, which will not be described herein again.

[0379] Through the description of the above embodiments, those skilled in the art can understand that, for the convenience and brevity of description, only the division of the above functional modules is exemplified, and in actual application, the above functions can be completed by different functional modules according to needs, that is, the internal structure of the device is divided into different functional modules to complete all or part of the functions described above.

[0380] In several embodiments provided in the present application, it should be understood that the disclosed apparatus and method can be implemented in other ways. For example, the apparatus embodiments described above are only illustrative, for example, the division of modules or units is only a logical function division, and actual implementation can have another division manner, for example, a plurality of units or components can be combined or integrated into another device, or some features can be ignored or not executed. In addition, the coupling or direct coupling or communication connection between the displayed or discussed ones can be indirect coupling or communication connection through some interfaces, devices or units, which can be electrical, mechanical or other forms.

[0381] The above description and the above embodiments are only used to illustrate the technical solutions of the present application, but not to limit them; although the present application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that the technical solutions recorded in the foregoing embodiments can still be modified, or some technical features can be replaced by equivalents; and these modifications or replacements do not make the essence of the corresponding technical solutions 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: During the process of starting the system service process, the system service watchdog in the application framework layer is initialized, and the system service watchdog is used to detect whether the system service process in the application framework layer is normal; wherein, after the system service process is started, the deadlock detection watchdog in the kernel layer is instructed to start the monitoring function of the system service watchdog; The system service process detects whether it is operating normally according to a preset period; During normal operation, the system service process sends a first dog feeding message to the system service watchdog, and the system service watchdog sends a second dog feeding message to the deadlock detection watchdog located in the kernel layer; When the system is not operating normally, the system service watchdog stops sending the second dog feeding information to the deadlock detection watchdog and performs a reset operation on the system service process; wherein, if the system service watchdog cannot operate normally or the system service process cannot be successfully restarted, the deadlock detection watchdog performs a reset operation and restarts the kernel system; wherein, after the kernel system is successfully restarted, the system service process is reloaded and started; The system service watchdog sends a second dog feeding message to the deadlock detection watchdog located at the kernel layer, including: The system service watchdog sends the second dog feeding information to a public node pre-packaged in the kernel layer, and the public node is used to decide whether the stuck detection watchdog performs a reset operation; When the public node does not receive the second dog feeding information, it determines whether to perform a reset operation according to a preset strategy; When determining to perform a reset operation, the common node detects whether the system service watchdog resumes normal operation within a preset period; When normal operation is not restored, the public node provides a reset instruction to trigger the stuck detection watchdog in the kernel layer to perform a reset operation; When normal operation is restored, the public node provides the agreed dog feeding information to the stuck detection watchdog.

2. The method according to claim 1, characterized in that A key service is running in the system service process; The system service process detects whether it is operating normally according to a preset period, including: The system service process detects whether the key service is operating normally according to a preset period; When the key service is operating normally, determining that the system service process is operating normally; When the key service does not operate normally, it is determined that the system service process does not operate normally.

3. The method according to claim 1, characterized in that During normal operation, the system service process sends a first dog feeding message to the system service watchdog, and the system service watchdog sends a second dog feeding message to a deadlock detection watchdog located at the kernel layer, including: During normal operation, the system service process sends the first dog feeding information to the system service watchdog; During normal operation and when the dog feeding cycle of the jam detection watchdog relative to the system service watchdog is reached, the system service watchdog sends the second dog feeding information to the jam detection watchdog located at the kernel layer.

4. The method according to claim 1, wherein When the process is not operating normally, the system service watchdog stops sending the second dog feeding information to the deadlock detection watchdog and performs a reset operation on the system service process, including: When the system service process is not operating normally, the system service watchdog determines the abnormal duration of the abnormal operation of the system service process; The system service watchdog determines the number of abnormalities according to the abnormality duration and the feeding cycle of the system service process relative to the system service watchdog; When the number of abnormalities is greater than n dog feeding cycles and the system service watchdog does not receive the first dog feeding information sent by the system service process, stop sending the second dog feeding information to the stuck detection watchdog and perform a reset operation on the system service process; Wherein, n is an integer greater than 0.

5. The method according to claim 4, characterized in that When the number of abnormalities is greater than n dog feeding cycles and the system service watchdog does not receive the first dog feeding information sent by the system service process, stopping sending the second dog feeding information to the stuck detection watchdog and performing a reset operation on the system service process, including: When the number of abnormalities is greater than n dog feeding cycles and the system service watchdog does not receive the first dog feeding information sent by the system service process, stop sending the second dog feeding information to the stuck detection watchdog and trigger the dog to bark; After n+m dog feeding cycles, when the system service watchdog does not receive the first dog feeding information sent by the system service process, performing a reset operation on the system service process; Here, m is an integer greater than 0.

6. The method according to claim 5, characterized in that After triggering the dog to bark, the method further includes: The system service watchdog captures daily logs.

7. The method according to any one of claims 1 to 6, characterized in that When the system service watchdog stops sending the second dog feeding information to the deadlock detection watchdog and performs a reset operation on the system service process, the method further includes: After the reset is successful, the system service watchdog sends the second dog feeding information to the stuck detection watchdog.

8. 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 7.

9. 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 7.

Citation Information

Patent Citations

  • Watch-dog implementation method and device based on Nios II system

    CN103645962A

  • Embedded software watchdog design method and device, equipment and storage medium

    CN110297724A