Log generation method and electronic device

Abstract

The application provides a log generation method and an electronic device. The method comprises: in the case where the electronic device fails, acquiring a first original log related to the failure, and acquiring a process identifier related to the failure; acquiring a first call chain based on the process identifier, the first call chain comprising a binder chain and a lock chain; adding the first call chain to the first original log to obtain a first target log. In the application, when the electronic device fails, the call chain related to the failure process is added to the original log to obtain a target log. Thus, the developer can solve the failure more quickly and effectively through the target log with the added call chain.

Description

TECHNICAL FIELD

[0001] Embodiments of the present application relate to the field of terminal devices, and in particular to a log generation method and an electronic device. BACKGROUND

[0002] With the popularity and development of electronic devices, electronic devices with touch screens have gradually entered people's lives. Existing electronic devices may malfunction due to abnormal running of some key processes during use, resulting in problems such as unresponsive electronic devices or unresponsive system services. When detecting that the electronic device malfunctions, fault positioning can be performed through relevant log information. Therefore, how to obtain more accurate log information is a technical problem to be solved. SUMMARY

[0003] To solve the above technical problems, the present application provides a log generation method and an electronic device. In the method, if it is detected that the electronic device malfunctions, the call chain related to the fault process is added to the original log to obtain the target log. In this way, the developer can more quickly and effectively solve the fault by adding the call chain to the target log.

[0004] In a first aspect, embodiments of the present application provide a log generation method. The method comprises: in the case where the electronic device malfunctions, obtaining a first original log related to the fault, and obtaining a process identifier related to the fault; obtaining a first call chain based on the process identifier, the first call chain comprising a binder chain and a lock chain; adding the first call chain to the first original log to obtain a first target log. In this way, the developer can quickly and effectively locate the fault in combination with the binder chain and the lock chain.

[0005] According to the first aspect, obtaining the process identifier related to the fault comprises: if the fault is an application unresponsive, obtaining a main process identifier corresponding to an abnormal application program, and taking the main process identifier as the process identifier related to the fault. In this way, the call chain associated with the main process can be obtained when the electronic device malfunctions abnormally.

[0006] According to the first aspect, or any one of the implementation manners of the first aspect, after obtaining the first target log, the method comprises: killing the process corresponding to the main process identifier. In this way, not only can the call chain be obtained to facilitate the developer to locate the fault, but also the fault application program can be attempted to be recovered to ensure the user's experience.

[0007] According to a first aspect, or any possible implementation mode of the first aspect, the process identifier related to the fault is obtained, including: if the fault is a system watchdog exception, obtaining an identifier of a system service process, and taking the identifier of the system service process as the process identifier related to the fault. In this way, the call chain associated with the system service can be obtained when the system watchdog exception occurs in the electronic device.

[0008] According to the first aspect, or any possible implementation mode of the first aspect, after the first target log is obtained, the method further includes: determining whether a deadlock event occurs in the system service process based on the lock chain; and if the deadlock event occurs in the system service process, determining a peer process of the system service process based on the binder chain, and killing the peer process. In this way, not only the call chain associated with the system service process can be obtained to facilitate the developer to locate the fault, but also the system service process can be recovered to ensure the user experience.

[0009] According to the first aspect, or any possible implementation mode of the first aspect, after the peer process is killed, the method further includes: if the electronic device does not return to normal operation, obtaining a second call chain, and obtaining a second original log related to the fault; adding the second call chain to the second original log to obtain a second target log. In this way, the electronic device can obtain the latest target log to facilitate the developer to locate the fault more accurately.

[0010] According to the first aspect, or any possible implementation mode of the first aspect, after the second target log is obtained, the method further includes: killing the system service process. In this way, the electronic device is automatically restarted, which can ensure the user experience to a certain extent.

[0011] According to the first aspect, or any possible implementation mode of the first aspect, the call depth of the process in the binder chain is 3 layers.

[0012] According to a second aspect, the embodiments of the present application provide an electronic device. The electronic device includes: one or more processors; a memory; and one or more computer programs, wherein the one or more computer programs are stored in the memory, and when the computer programs are executed by the one or more processors, the electronic device performs the following steps: in the case that a fault occurs in the electronic device, obtaining a first original log related to the fault, and obtaining a process identifier related to the fault; obtaining a first call chain based on the process identifier, the first call chain including a binder chain and a lock chain; and adding the first call chain to the first original log to obtain a first target log.

[0013] According to a second aspect, when the computer program is executed by one or more processors, the electronic device is caused to perform the following steps: if the fault is that the application does not respond, obtaining an identification of a main process corresponding to the abnormal application, and taking the identification of the main process as the process identification related to the fault.

[0014] According to the second aspect, or any one of the implementations of the second aspect, when the computer program is executed by one or more processors, the electronic device is caused to perform the following steps: killing the process corresponding to the identification of the main process.

[0015] According to the second aspect, or any one of the implementations of the second aspect, when the computer program is executed by one or more processors, the electronic device is caused to perform the following steps: if the fault is a system watchdog exception, obtaining an identification of a system service process, and taking the identification of the system service process as the process identification related to the fault.

[0016] According to the second aspect, or any one of the implementations of the second aspect, when the computer program is executed by one or more processors, the electronic device is caused to perform the following steps: determining whether a deadlock event occurs to the system service process based on a lock chain; if the deadlock event occurs to the system service process, determining a peer process of the system service process based on a binder chain, and killing the peer process.

[0017] According to the second aspect, or any one of the implementations of the second aspect, when the computer program is executed by one or more processors, the electronic device is caused to perform the following steps: if the electronic device does not recover to normal operation, obtaining a second call chain, and obtaining a second original log related to the fault; adding the second call chain to the second original log to obtain a second target log.

[0018] According to the second aspect, or any one of the implementations of the second aspect, when the computer program is executed by one or more processors, the electronic device is caused to perform the following steps: killing the system service process.

[0019] According to the second aspect, or any one of the implementations of the second aspect, the call depth of the process in the binder chain is 3 layers.

[0020] According to a third aspect, an embodiment of the present application provides a chip. The chip comprises one or more interface circuits and one or more processors; the interface circuit is configured to receive a signal from a memory of an electronic device and send a signal to the processor, the signal comprising computer instructions stored in the memory; when the processor executes the computer instructions, the electronic device is caused to perform the fault detection method of the first aspect and any one of the implementations of the first aspect.

[0021] The third aspect and any kind of implementation manner of the third aspect correspond to the first aspect and any kind of implementation manner of the first aspect respectively. The technical effects corresponding to the third aspect and any kind of implementation manner of the third aspect can be referred to the technical effects corresponding to the first aspect and any kind of implementation manner of the first aspect, which will not be described here.

[0022] In a fourth aspect, the embodiments of the present application provide a computer readable storage medium. The computer readable storage medium includes a computer program, characterized in that when the computer program is run on an electronic device, the electronic device executes the first aspect and any one of the fault detection methods in the first aspect.

[0023] The fourth aspect and any kind of implementation manner of the fourth aspect correspond to the first aspect and any kind of implementation manner of the first aspect respectively. The technical effects corresponding to the fourth aspect and any kind of implementation manner of the fourth aspect can be referred to the technical effects corresponding to the first aspect and any kind of implementation manner of the first aspect, which will not be described here. BRIEF DESCRIPTION OF DRAWINGS

[0024] Figure 1 An application scenario schematic diagram provided by the embodiments of the present application;

[0025] Figure 2 A display schematic diagram of an interface when the electronic device has an application non-response exception provided by the embodiments of the present application;

[0026] Figure 3 A structural schematic diagram of an electronic device shown by the embodiments of the present application;

[0027] Figure 4 A software structure schematic diagram of an electronic device shown by the embodiments of the present application;

[0028] Figure 5 A flow schematic diagram of a log generation method provided by the embodiments of the present application;

[0029] Figure 6 A framework schematic diagram of a log generation method provided by the embodiments of the present application;

[0030] Figure 7 A schematic diagram of a call chain in a log generation method provided by the embodiments of the present application;

[0031] Figure 8 A flow schematic diagram of a log generation method provided by another embodiment of the present application;

[0032] Figure 9 A flow schematic diagram of a log generation method provided by still another embodiment of the present application;

[0033] Figure 10Another embodiment of the present application provides a schematic diagram of a lock chain corresponding to a deadlock in a log generation method. DETAILED DESCRIPTION

[0034] The technical solutions in the embodiments of the present application will be clearly and completely described in connection with the drawings in the embodiments of the present application. Obviously, the described embodiments are some of the embodiments of the present application, rather than all the embodiments of the present application. Based on the embodiments in the present application, all other embodiments obtained by a person of ordinary skill in the art without creative effort belong to the scope of protection of the present application.

[0035] It should be understood that when used in the specification and the appended claims of the present application, the term "comprising" indicates the presence of the described features, integers, steps, operations, elements, and / or components, but does not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof.

[0036] It should also be understood that in the embodiments of the present application, "one or more" means one, two, or more than two; "and / or" describes the association relationship of the associated objects, which means that there can be three relationships; for example, A and / or B can mean that A exists alone, A and B exist together, and B exists alone, where A and B can be singular or plural. The character " / " generally represents an "or" relationship between the associated objects before and after it.

[0037] The terms "first" and "second" and the like in the specification and claims of the embodiments of the present application are used to distinguish different objects, rather than to describe a specific order of the objects. For example, the first target object and the second target object are used to distinguish different target objects, rather than to describe a specific order of the target objects.

[0038] In the present application, the reference "one embodiment" or "some embodiments" and the like means that the specific features, structures or characteristics described in connection with the embodiment are included in one or more embodiments of the present application. Therefore, the statements "in one embodiment", "in some embodiments", "in other some embodiments", "in other embodiments" and the like appearing in different places in the specification are not necessarily all referring to the same embodiment, but mean "one or more but not all embodiments", unless otherwise specifically emphasized. The terms "include", "contain", "have" and their variants mean "include but are not limited to", unless otherwise specifically emphasized.

[0039] In the description of the embodiments 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.

[0040] Before introducing the method in the embodiments of the present application, in order to facilitate the understanding of the embodiments of the present application by the person skilled in the art, the related concepts involved in the embodiments of the present application are introduced.

[0041] 1) Process

[0042] A process is a running activity of an application program on a certain data set, and is a basic unit of resource allocation and scheduling of an operating system (for example, an Android system). Each process will occupy a block of memory space, and an application program runs on an operating system in the form of one or more processes to realize corresponding functions.

[0043] 2) Thread

[0044] A thread is an entity of a process, and is a smaller basic unit that can independently run than a process. Threads can share all resources owned by the process with other threads belonging to the same process. A thread can create and cancel another thread, and multiple threads in the same process can be executed in parallel.

[0045] 3) Object lock

[0046] An object lock is a mechanism for ensuring that only one thread accesses a certain method or variable at the same time. In object-oriented languages such as Java, when a thread accesses synchronized code, the thread must obtain the object lock of the code, otherwise the thread will be blocked until the object lock is released.

[0047] An object lock is a mutual exclusion lock, that is, at most one thread can obtain the lock, and when thread A attempts to obtain the object lock held by thread B, thread A must wait or block until thread B releases the lock, and then thread A can obtain the object lock to access the corresponding method or variable.

[0048] 4) Thread blocking

[0049] Thread blocking usually refers to a timeout phenomenon caused by the fact that a thread pauses for a duration longer than a certain preset value during execution. For example, thread A needs the execution result of thread B as an input parameter to continue execution, and if thread A does not obtain the execution result of thread B, it will pause execution. When thread A does not obtain the execution result of thread B within a preset time, thread A will be blocked.

[0050] 5) ANR

[0051] ANR (Application Not Responding) refers to a delay in the display interface of an electronic device when performing a specific function, and frame loss phenomenon.

[0052] Specifically, ANR refers to the execution time of an application when responding to a user operation exceeding the threshold value preset by the electronic device. The preset threshold value refers to the time preset by the electronic device to handle a single event. In most cases, the application can recover to normal after a short period of time. If the application continues to remain stuck after a short period of time, it will cause a higher level of warning, resulting in the user's operation being unable to be successfully executed.

[0053] 6) watchdog

[0054] The watchdog is a software running in the Android platform, which is used to monitor the system_server (system service process). The system_server is the most important process in the Android platform, and most services in the platform run in it. There are nearly 50 threads running in the system_server process, and the death of any one thread can cause the entire system to be stuck.

[0055] The watchdog is used to monitor the system services running in the system service process, and to capture the stack information when the watchdog exception is monitored. In addition, the watchdog restarts the system service when the watchdog exception is monitored and the system does not automatically recover within a specified time.

[0056] 7) system_sever

[0057] The system_server is the core of the Android system, and is the system service module of the Android framework layer. The main function of this module is to manage the system services for Android application development. It starts initialization and operation immediately after the Dalvik virtual machine is started, and other system services run in the environment of the system_server process.

[0058] 8) IPC

[0059] Inter-Process Communication (IPC) refers to some techniques or methods for transferring data or signals between at least two processes or threads. IPC is mainly used for message passing between different processes in a computer system.

[0060] The process is the smallest unit of computer resource allocation, each process has its own virtual address space, and is isolated from the virtual address space of other processes, that is, a process can only access its own virtual address space and cannot access the virtual address space of other processes. In order to enable different processes to access and coordinate with each other, the operating system provides a variety of IPC mechanisms. For example, the binder mechanism.

[0061] 9) binder

[0062] binder is a way of inter-process communication in the Android system, and is one of the most important features in the Android system. Android includes four components, namely Activity (workflow), Service (service), Broadcast (broadcast receiver) and ContentProvider (content provider), different applications run in different processes, and binder is the bridge for communication between these processes. As the name "binder" suggests, binder glues together the various components in the system and serves as a bridge between components.

[0063] binder adopts a C / S architecture, which can include Client (client), Server (server), ServiceManager (service management) and binder driver, wherein ServiceManager is used to manage various services in the system.

[0064] The Client process is a process that uses services, the Server process is a process that provides services, and the ServiceManager process is used to convert the binder name in character form into a reference to the binder in the Client, so that the Client can obtain a reference to the binder entity in the Server through the binder. The binder driver is responsible for establishing binder communication between processes, transferring binders between processes, managing binder reference counts, transferring data packets between processes, and interacting with a series of underlying supports.

[0065] Please refer to Figure 1 , an application scenario example provided by the embodiment of the present application. As shown in Figure 1 , when the user operates the electronic device 100, the electronic device 100 generates a target log, and then the electronic device 100 can upload the generated log to the cloud (server) through a communication network. On this basis, the developer can obtain the log of the electronic device 100 from the cloud (server) through the terminal device 200. By analyzing the target log, the developer can determine the cause of the fault.

[0066] In addition, the electronic device 100 and the terminal device 200 can also be directly connected through the development tool, that is, the terminal device 200 obtains the log information of the electronic device 100 through the development tool, and analyzes the log information to obtain the fault reason.

[0067] If the application program in the electronic device cannot respond to the touch operation of the user within a certain time during the running process, it indicates that the electronic device may have an application non-response exception (ANR). At this time, a prompt box such as Figure 2 may be popped up on the display interface of the electronic device, which informs the user that the application A has an application non-response exception during the running process. If the user clicks the "close application" control, the electronic device forcibly closes the main process of the application A and records the log related to the fault.

[0068] In addition, if the system service of the electronic device cannot respond to the touch operation of the user within a certain time during the running process, it indicates that the electronic device may have a system watchdog exception problem. The system watchdog exception problem can be monitored by a watchdog.

[0069] When the electronic device has an application non-response exception or a system server non-response exception, the log related to the fault is recorded, but the log recorded at this time only contains information related to the main process, and the developer cannot quickly locate the fault position through the log. Therefore, it greatly affects the developer to solve the fault.

[0070] Therefore, in order to quickly and effectively locate the fault position, the embodiment of the present application can determine the process related to the fault when the electronic device has a fault. On this basis, the call chain related to the process is obtained, and the call chain is added to the original log to obtain the target log. In this way, the developer can more quickly and effectively solve the fault through the target log with the added call chain.

[0071] The log generation method in the embodiment of the present application can be applied to the electronic device as shown in Figure 3 , the electronic device 100 as shown in Figure 3 may be a terminal, also known as a terminal device. The terminal can be a cellular phone, a pad, a wearable device, or an Internet of Things device with a camera, and the present application is not limited. It should be noted that the structural diagram of the electronic device 100 can be applied to the electronic device in Figure 2 .

[0072] It should be further noted that the electronic device 100 can have more or less components than those shown in the figure, can combine two or more components, or can have a different configuration of components. Figure 3 The various components shown in the figure can be implemented in hardware, software, or a combination of hardware and software, including one or more signal processing and / or application-specific integrated circuits.

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

[0074] It can be understood that the structure shown in the embodiment of the present application does not constitute a specific limitation on the electronic device 100. In other embodiments of the present application, the electronic device 100 can include more or fewer components than shown, or combine certain components, or split certain components, or different component arrangements. The components shown can be implemented in hardware, software, or a combination of software and hardware.

[0075] 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 into one or more processors.

[0076] 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 instruction fetching and instruction execution.

[0077] The processor 110 can also be provided with a memory for storing instructions and data. In some embodiments, the memory in the processor 110 is a cache memory. The USB interface 130 is an interface conforming to the USB standard specification, and can be a MiniUSB interface, a MicroUSB interface, a USB Type-C interface, etc. The USB interface 130 can be used to connect a charger to charge the electronic device 100, and can also be used to transmit data between the electronic device 100 and a peripheral device. It 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 AR devices, etc.

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

[0079] The power management module 141 is used to connect the battery 142, the charging management module 140, and the processor 110. The power management module 141 receives input from the battery 142 and / or the charging management module 140 to provide power to the processor 110, the internal memory 121, the external memory, the display screen 194, the camera 193, and the wireless communication module 160, etc. The wireless communication function of the electronic device 100 can be realized through the antenna 1, the antenna 2, the mobile communication module 150, the wireless communication module 160, the modem processor, and the baseband processor, etc.

[0080] The antenna 1 and the antenna 2 are used to transmit and receive electromagnetic wave signals. Each antenna in the electronic device 100 can be used to cover a single or multiple communication frequency bands. Different antennas can also be multiplexed to improve the utilization rate of the antennas. For example, the antenna 1 can be multiplexed as a diversity antenna for a wireless local area network. In some other embodiments, the antennas can be used in combination with tuning switches.

[0081] 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 mobile communication module 150 can include at least one filter, a switch, a power amplifier, a low noise amplifier (LNA), etc. The wireless communication module 160 can provide a solution for wireless communication including wireless local area networks (WLAN) (e.g., wireless fidelity (Wi-Fi) networks), Bluetooth (BT), global navigation satellite systems (GNSS), frequency modulation (FM), near field communication (NFC), infrared (IR) technology, etc. applied to the electronic device 100.

[0082] In some embodiments, the antenna 1 of the electronic device 100 is coupled with the mobile communication module 150, and the antenna 2 is coupled with the wireless communication module 160, so that the electronic device 100 can communicate with a network and other devices through wireless communication technology.

[0083] The electronic device 100 implements a display function through a GPU, a display screen 194, and an application processor, etc. The GPU is a microprocessor for image processing, connected to the display screen 194 and the application processor. The GPU is used to perform mathematical and geometric calculations for graphics rendering. The processor 110 can include one or more GPUs that execute program instructions to generate or change display information.

[0084] The display screen 194 is used to display images, videos, etc. The display screen 194 includes a display panel. The display panel can adopt a liquid crystal display (LCD), an organic light-emitting diode (OLED). In some embodiments, the electronic device 100 can include 1 or N display screens 194, N being a positive integer greater than 1.

[0085] The camera 193 is configured to capture still images or videos. An object projects an optical image through a lens to a photosensitive element. The photosensitive element can be a charge coupled device (CCD) or a complementary metal-oxide-semiconductor (CMOS) phototransistor. The photosensitive element converts the optical signal into an electrical signal, which is then transmitted to an ISP for conversion into a digital image signal. The ISP outputs the digital image signal to a DSP for processing. The DSP converts the digital image signal into a standard image signal in a format such as RGB, YUV, or the like. In some embodiments, the electronic device 100 can include one or N cameras 193, where N is a positive integer greater than one.

[0086] The external memory interface 120 can be configured to connect an external memory card, such as a MicroSD card, to extend the storage capacity of the electronic device 100. The external memory card communicates with the processor 110 via the external memory interface 120 to store data. For example, music, video, and the like can be stored in the external memory card.

[0087] The internal memory 121 can be configured to store computer-executable program code including instructions. The processor 110 executes various functions of the electronic device 100 and processes data by running the instructions stored in the internal memory 121. The internal memory 121 can include a program storage area and a data storage area. The program storage area can store an operating system, at least one application program required for a function (such as a sound play function, an image play function, or the like), and the like. The data storage area can store data created during use of the electronic device 100 (such as audio data, a phonebook, or the like), and the like. In addition, the internal memory 121 can include a high-speed random access memory, and can further include a non-volatile memory such as at least one of a magnetic disk storage device, a flash memory device, a universal flash storage (UFS), or the like.

[0088] The electronic device 100 can implement an audio function through the audio module 170, the speaker 170A, the receiver 170B, the microphone 170C, the earphone interface 170D, the application processor, and the like. For example, music play, voice recording, and the like can be implemented.

[0089] The audio module 170 is configured to convert digital audio information into an analog audio signal and output the same, and to convert an analog audio input into a digital audio signal. The audio module 170 can also be configured to encode and decode an audio signal. In some embodiments, the audio module 170 can be disposed in the processor 110, or some of the functional modules of the audio module 170 can be disposed in the processor 110.

[0090] A touch sensor, also known as a "touch panel," can be located on the display screen 194. The touch sensor and display screen 194 together form a touchscreen, also called a "touch screen." The touch sensor detects touch operations applied to or near it. The touch sensor can transmit the detected touch operation to the application processor to determine the type of touch event. Visual output related to the touch operation can be provided through the display screen 194. In other embodiments, the touch sensor may also be located on the surface of the electronic device 100, in a different position than the display screen 194.

[0091] Buttons 190 include a power button, volume buttons, etc. Buttons 190 can be mechanical buttons or touch buttons. The electronic device 100 can receive button input and generate key signal inputs related to user settings and function control. Pressing the power button can turn the phone screen off or on. Furthermore, if the power button is pressed for a certain duration, the electronic device 100 can enter a restart state.

[0092] Motor 191 can generate vibration alerts. Motor 191 can be used for incoming call vibration alerts or for touch vibration feedback. For example, different vibration feedback effects can be corresponding to touch operations applied to different applications (such as taking photos, playing audio, etc.).

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

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

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

[0096] like Figure 4 As shown, the application layer can include applications such as camera, gallery, calendar, call, map, WLAN, Bluetooth, music, video, and SMS. The application framework layer provides application programming interfaces (APIs) and a programming framework for the applications in the application layer. The application framework layer includes some predefined functions. For example... Figure 4 As shown, the application framework layer can include a window manager, content provider, view system, phone manager, resource manager, notification manager, etc. The window manager can run within the aforementioned system_server.

[0097] The kernel layer is a layer between the hardware and the above-mentioned software layer. The kernel layer at least includes a power key driver, a display driver, a fault detection module, a fault handling module, and a log generation module, etc. The hardware can include a camera, a display screen, a microphone, a processor, a memory, and the like.

[0098] The fault detection module is configured to determine whether the electronic device is faulty. If the electronic device is faulty, the fault detection module can be configured to obtain a process identifier related to the fault. In addition, the fault detection module can also be configured to determine whether the electronic device is restored to normal operation.

[0099] The log generation module is configured to obtain a call chain related to the fault process, and add information of the call chain to the original log to obtain a target log.

[0100] The fault handling module is configured to correspondingly take different fault handling operations when the electronic device occurs different types of exceptions. For example, when the electronic device occurs an application non-response exception, the fault handling module can kill the main process of the fault application program.

[0101] It can be understood that, Figure 4 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.

[0102] In the embodiments of the present application, when it is determined that the electronic device is faulty, a process related to the fault can be determined. On this basis, a call chain corresponding to the process is obtained, and the call chain is added to the original log to obtain a target log. In this way, the developer can quickly locate the position where the fault occurs by using the log to which the call chain is added, thereby accelerating the rate of fault resolution.

[0103] As shown in the figure, Figure 5 The log generation method provided by the embodiments of the present application can include the following steps S110 to S140.

[0104] Step S110: The fault detection module determines whether the electronic device is faulty.

[0105] In the embodiments of the present application, the fault of the electronic device can be an application non-response exception (ANR) of the electronic device, or a system watchdog exception (vmwatchdog) of the electronic device. The application non-response exception can be caused by blocking of the main process of the application program running on the electronic device, or by blocking of a thread in the main process.

[0106] In addition, the system watchdog exception can also be referred to as a system service unresponsive exception, which can be caused by a blocking of a system service process of the electronic device during running, i.e., a thread in the system service process is blocked to cause the system service unresponsive exception of the electronic device. Therefore, the failure of the electronic device in the embodiment of the present application can be caused by the thread blocking.

[0107] As a manner, the failure detection module can detect whether the electronic device has a failure, and if it is detected that the electronic device has a failure, the failure detection module can acquire the process identification related to the failure, i.e., step S120 is entered. In addition, if the failure detection module does not detect that the electronic device has a failure, the failure detection operation can be continuously performed.

[0108] In some embodiments, when the failure detection module determines whether the electronic device has a failure, the running parameter of the electronic device can be acquired. Generally, the running parameter is a direct embodiment of the running status of the electronic device, and thus the embodiment of the present application can determine whether the electronic device has a failure through the running parameter of the electronic device, so as to ensure the accuracy of the failure detection.

[0109] In other embodiments, when the failure detection module determines whether the electronic device has a failure, it can determine whether the electronic device has an application unresponsive exception or a system watchdog exception.

[0110] As a manner, when the failure detection module determines whether the electronic device has an application unresponsive exception / system watchdog exception, the identification corresponding to the application unresponsive exception / system watchdog exception can be acquired, and whether the electronic device has a failure is determined based on the identification.

[0111] Specifically, the failure detection module can determine whether the identification corresponding to the application unresponsive exception / system watchdog exception is a specified identification, and if the identification corresponding to the application unresponsive exception / system watchdog exception is the specified identification, it is determined that the electronic device has the application unresponsive exception / system watchdog exception.

[0112] In the embodiment of the present application, the identification corresponding to the application unresponsive exception / system watchdog exception is mainly used to represent whether the electronic device has the corresponding exception. As an example, the identification corresponding to the application unresponsive exception is A, and if A is 1, it represents that the electronic device has the application unresponsive exception. In addition, if A is 0, it represents that the electronic device does not have the application unresponsive exception.

[0113] As another example, the identification corresponding to the system watchdog exception is W, and if B is 1, it represents that the electronic device has the system watchdog exception. In addition, if W is 0, it represents that the electronic device does not have the system watchdog exception.

[0114] It should be noted that the specified identifier can also be other values, and the specific value is not limited herein as long as it can be distinguished from whether the application non-response exception / system watchdog exception occurs.

[0115] As another way, when the fault detection module determines whether the electronic device has an application non-response exception, it can also obtain the waiting time of the application process. When the waiting time of the application process exceeds a first specified time length, it is determined that the electronic device has an application non-response exception. The first specified time length can be 5s.

[0116] As another way, when the fault detection module determines whether the electronic device has a system watchdog exception, it can also obtain the waiting time of the system service process. When the waiting time exceeds a second specified time length, it is determined that the electronic device has a system watchdog exception. The second specified time length can be 30s.

[0117] Step S120: The fault detection module obtains the fault-related process identifier.

[0118] As a way, when the fault detection module determines that the electronic device has a fault, it can obtain the fault-related process identifier, that is, determine the process that causes the fault.

[0119] From the above introduction, it is known that the blocking of the process / thread usually causes the electronic device to have a fault, that is, to have a freezing phenomenon. Therefore, when it is determined that the electronic device has a fault, the application embodiment can obtain the process that causes the fault, that is, obtain the fault-related process identifier.

[0120] In the application embodiment, the fault-related process identifier can be a main process identifier. For example, when the electronic device runs an application program 1 and has an application non-response exception, the fault detection module can determine the main process A of the application program 1, and take the identifier of the main process A as the fault-related process identifier.

[0121] In addition, when the fault detection module obtains the fault-related process identifier, it can also obtain a thread identifier, where the thread identifier can be an identifier of a thread in the main thread. The fault of the electronic device can be caused by the blocking of a thread in the main process, and the position of the fault can be located more quickly and effectively by obtaining the thread identifier.

[0122] Step S130: The fault detection module sends the process identifier to the log generation module.

[0123] In some embodiments, when the fault detection module obtains the process identifier related to the fault, the fault detection module can send the process identifier to the log generation module, and the log generation module can obtain the call chain based on the process identifier, i.e., step S130.

[0124] It should be noted that the process identifier sent by the fault detection module can include not only the identifier of the process, but also the identifier of the thread in the process.

[0125] Step S140: The log generation module obtains the call chain based on the process identifier, and adds the call chain to the original log to obtain the target log.

[0126] As one way, when the log generation module obtains the process identifier, the log generation module can obtain the call chain associated with the process identifier, and then add the call chain to the original log to obtain the target log.

[0127] In the embodiments of the present application, the call chain associated with the process identifier can include a binder chain and a lock chain. The binder chain can be composed of the call relationship between processes. In other words, the binder chain can be the call relationship generated by the inter-process communication performed by each process.

[0128] In addition, the lock chain can be composed of the relationship of the object locks corresponding to the threads in the process. The object lock can be a mutex, i.e., at most one thread in a process can obtain the target lock.

[0129] As one way, the binder chain can also be referred to as a binder call chain. The binder call chain includes at least one process, and the at least one process includes at least one thread. When the binder call chain includes two or more processes, the call chain includes at least a cross-process call and a cross-thread call.

[0130] In some embodiments, when the log generation module obtains the binder call chain based on the process identifier, the log generation module can first take the process corresponding to the process identifier as a first node, and then search the preset call chain cache to determine whether there is a call chain with the first node as a starting node.

[0131] The call chain cache is used to store the call chain, and the binder call chain represents a directed graph of the call relationship between nodes. One binder call chain includes at least a starting node and a terminating node. The starting node represents the first node of the call chain, and the terminating node represents the last node of the call chain. For example, the binder call chain is in the form of A→B→C, which means that node A first calls node B, and then node B calls node C.

[0132] In order to better understand the call chain, the present application provides an example as followsFigure 6 The example diagram is shown. From Figure 6 It can be seen that process A calls process B, and process B calls process C. The calling relationship between these processes can form a binder chain. The binder chain can be expressed as: process A→process B→process C. Process A can be an application process, process B can be a service process, and process C can be a HAL (Hardware Abstraction Layer) process.

[0133] It should be noted that the calling depth of the processes in the binder chain is configurable. As a manner, the calling depth of the processes in the binder chain can be 3.

[0134] In addition, when process A calls process B, it can be implemented by calling a thread in process B. As shown in Figure 6 Process A calls by calling thread 1 (Thread1) in process B. In addition, when process B is called, thread 1 (Thread1) in process B needs to acquire lock 1 to execute the corresponding task, and lock 1 is held by thread 2 (Thread1), so thread 1 (Thread1) is in a lock waiting state. In addition, process B calls process C through thread 2 (Thread2).

[0135] In some embodiments, the calling relationship between threads in the same process forms a lock chain. For example, the lock chain can be T1→T2, which means that the lock that thread T1 waits for is held by thread T2.

[0136] As a manner, the log generation module can include a lock indexer, through which the thread holding the lock can be obtained, and then the lock chain can be obtained. The lock indexer can be a bidirectional indexer, that is, through the identifier of the lock, the identifier of the associated thread can be indexed. In addition, through the identifier of the thread, the identifier of the associated lock can also be indexed.

[0137] In the embodiments of the present application, each process corresponds to a unique process identifier, and each thread in each process also corresponds to a unique thread identifier. In addition, each lock can also correspond to a unique lock identifier. The thread and the lock can be bidirectionally indexed.

[0138] Specifically, each thread can correspond to multiple locks, wherein the multiple locks can include a lock held by the thread and a lock waited by the thread. Through the lock waited by the thread, it can be known that the lock waited by the target thread is held by which thread, and through the held lock, it can be known that which thread is waiting for the lock held by the target thread. In addition, the lock chain in

[0139] As an example, thread 1 corresponds to lock 1, lock 2 and lock 3. Among them, lock 1 is a lock that thread 1 waits for, and lock 2 and lock 3 are locks that thread 1 holds. It can be seen that lock 1 that thread 1 waits for is being held by thread 4, and only when thread 4 releases lock 1, thread 1 can execute the corresponding task.

[0140] In addition, since the threads and the locks can be bidirectionally indexed, the embodiment of the present application can also determine other threads waiting for the locks through the locks held by thread 1. For example, thread 4 holds lock 1 and lock 4, the thread waiting for lock 1 is thread 1, and the thread waiting for lock 4 is thread 5. In summary, through bidirectional indexing of threads and locks, the embodiment of the present application can obtain the lock chain.

[0141] As an example, in the same process, at least two threads compete for the same object lock,

[0142] In order to better understand the call chain, the embodiment of the present application gives an example diagram as shown in Figure 7 Through 101 in Figure 7 , the embodiment of the present application can obtain the binder chain. In addition, through 102, the embodiment of the present application can obtain the lock chain. Figure 7 “From” in Figure 7 indicates the calling process, and “Dest” indicates the called process. Exemplarily, the process identifier of the calling process in

[0143] is “2231”. Figure 7 As a way, a process can have a calling relationship with multiple threads in another process. For example, the fourth thread of process “2231” in

[0144] may call the second thread of process “1132”. For another example, the third thread of process “2231” can call the fifth thread of process “1132”. Figure 7 As shown in 102, it indicates the calling relationship between threads in the same process, that is, the lock chain. Among them, Tid can be the identifier of different threads in the same process. Tid: 1 can be the identifier of the first thread in process 2231; Tid: 2 can be the identifier of the second thread in process 2231; Tid: 3 can be the identifier of the third thread in process 2231; Tid: 4 can be the identifier of the fourth thread in process 2231.

[0145] Figure 7 Through the above introduction, it is known that the main process in Figure 7It is seen that the thread 1 "Tid: 1" in the system service process is in a blocking state, and the lock it waits for is held by the thread 4 "Tid: 4". In addition, it is seen that the process "2231" can call the thread 2 in the process "1132" through the thread 4 "Tid: 4". Figure 8 It is seen that the thread 1 "Tid: 1" in the system service process is in a blocking state, and the lock it waits for is held by the thread 4 "Tid: 4". In addition, it is seen that the process "2231" can call the thread 2 in the process "1132" through the thread 4 "Tid: 4".

[0146] In the embodiment of the application, the binder chain and the lock chain can be pre-stored in the electronic device, and after the process identifier is acquired, the binder chain and the lock chain can be acquired correspondingly.

[0147] It should be noted that the call chain acquired by the embodiment of the application can be one or multiple, and the actual communication between processes is determined.

[0148] In some embodiments, after the call chain is acquired, the log generation module can add the call chain to the original log to obtain a target log. The original log can be log information corresponding to a specified time period acquired when the electronic device fails. The original log can be an application unresponsive log, a system watchdog exception log, or a long key log, etc.

[0149] As an example, when it is determined that the electronic device has an application unresponsive exception, the log generation module can acquire an application unresponsive exception log (ANR log), and at the same time, can acquire a call chain related to the application unresponsive exception. On this basis, the call chain is added to the application unresponsive exception log.

[0150] As another example, when it is determined that the electronic device has a system watchdog exception, the log generation module can acquire a system watchdog exception log (watchdog log), and at the same time, can acquire a call chain related to the system watchdog exception. On this basis, the call chain is added to the system watchdog exception log.

[0151] As another example, when it is detected that the user long-presses the power key, and the long-press time exceeds the preset time, the log generation module can acquire a long key log, and at the same time, can acquire a call chain related to the long-press operation. On this basis, the call chain is added to the long key log. Specifically, the binder chain and the locker chain related to the system_server are added to the long key log.

[0152] In summary, the application unresponsive exception log, the system watchdog exception log, or the long key log, etc. finally acquired by the embodiment of the application can include a call chain. When these logs are acquired, the developer can quickly and effectively solve the fault by using the call chain included.

[0153] In addition, the original log can include a plurality of log blocks, and each log block has a different acquisition time. For example, a log block generated at a start time of a specified time period is a start log, and a log block generated at an end time of the specified time period is an end log block.

[0154] In some embodiments, after the log generation module acquires the call chain corresponding to the process identifier, the log generation module can add the call chain to the original log to obtain a target log. When adding the call chain to the original log, the embodiments of the present application can add the call chain to a start position of the original log, i.e., before adding the call chain to a start log block. In addition, the call chain can also be added to an end position of the original log, i.e., after adding the call chain to an end log block.

[0155] In other embodiments, in order to enable the developer to quickly and effectively find the call chain, after adding the call chain to the original log, the embodiments of the present application can also acquire a position of the call chain, and then write the position to a start position of the target log, i.e., before writing the position information of the call chain to a start log block. When viewing the target log, the developer can quickly and effectively acquire the addition position of the call chain, thereby accelerating the rate of fault resolution.

[0156] In other embodiments, a call chain file can be added in the electronic device, and the call chain file can store the call relationship between different processes and the lock relationship between threads in a process. In other words, after acquiring the call chain, the log generation module can write the call chain to the call chain file, and the target log is composed of the call chain file and the original log. When analyzing the target log, the developer can directly know the relationship between processes and between threads in a process through the call chain file, and then combine the log information to quickly and effectively locate the source of the fault.

[0157] As a way, after adding the call chain to the original log to obtain the target log, the log generation module can send the target log to a server, so that the server can analyze the fault rate of the electronic device according to the target log.

[0158] Optionally, after the server analyzes the fault rate of the electronic device according to the target log, on the one hand, the server can display the fault rate to the manufacturer, so that the manufacturer can measure the quality standard of the electronic device according to the fault rate index, and can find more faults and possible operations.

[0159] On the other hand, the server can also display the fault rate to the developer, so that the developer can locate the problem of the electronic device that appears to be faulty, such as application unresponsiveness and system service unresponsiveness, and solve the problem, thereby improving the product quality of the electronic device.

[0160] In other implementations, when the log generation module obtains the target log, it can send the target log to the server, which then forwards the received target log to the developers. The developers can analyze the target log to determine the location of the fault and provide corresponding solutions. Alternatively, the log generation module can directly send the target log to the developers to instruct them to analyze the fault.

[0161] In other implementations, the developer can be a repair technician at a service center. When analyzing electronic device malfunctions, the repair technician can use a repair feedback tool to capture target logs and then analyze the reasons for application unresponsiveness / system service unresponsiveness based on the captured target logs.

[0162] As an example, repair personnel at a service center can retrieve target logs from the electronic device's storage using remote desktop and SMS verification codes, and then print these target logs. Additionally, the service center can be configured with repair tools and feedback tools, allowing repair personnel to quickly and effectively retrieve and analyze the target logs.

[0163] like Figure 9 As shown, another embodiment of this application provides a log generation method, which may include the following steps S210 to S260.

[0164] Step S210: The fault detection module determines whether the electronic device is experiencing an application unresponsiveness anomaly.

[0165] As explained above, an application unresponsiveness exception can be caused by a blockage in the main process of an application running on an electronic device. Specifically, a thread within the main process may become blocked, leading to the application unresponsiveness exception. Therefore, the fault detection module can determine whether an electronic device is experiencing an application unresponsiveness exception.

[0166] In one approach, the fault detection module can obtain the identifier corresponding to the application unresponsiveness anomaly, and then determine whether the identifier is a specified identifier. If it is a specified identifier, then the electronic device is determined to have experienced an application unresponsiveness anomaly. For example, it can determine whether the identifier corresponding to the application unresponsiveness anomaly is 1. If the identifier is 1, then the electronic device is determined to have experienced an application unresponsiveness anomaly. Conversely, if the identifier is 0, then the electronic device is determined not to have experienced an application unresponsiveness anomaly.

[0167] As another way, the fault detection module can also first acquire the application currently running on the electronic device, then determine the process corresponding to the application, and acquire the waiting time of the process. When the waiting time exceeds the first specified time length, it is determined that the electronic device has an application unresponsive exception. The first specified time length can be 5s. For example, the main process of the application A is blocked when performing the corresponding task, and the blocking time exceeds the first specified time length. At this time, the fault detection module can determine that the electronic device has an application unresponsive exception.

[0168] In some embodiments, if the fault detection module determines that the electronic device has an application unresponsive exception, the main process identifier corresponding to the abnormal application can be acquired, that is, step S220 is entered. In addition, if the fault detection module does not detect that the electronic device has an application unresponsive exception, the application unresponsive exception can be continuously monitored.

[0169] Step S220: The fault detection module acquires the main process identifier corresponding to the abnormal application.

[0170] In the embodiments of the present application, each application can correspond to a main process. When it is determined that the electronic device has an application unresponsive exception, the fault detection module can determine the application that causes the exception. Then the main process of the application is acquired, and the identifier thereof is taken as the main process identifier corresponding to the abnormal application.

[0171] Step S230: The fault detection module sends the main process identifier to the log generation module.

[0172] As a way, after the fault detection module acquires the main process identifier, it can send the main process identifier to the log generation module.

[0173] Step S240: The log generation module acquires the call chain based on the main process identifier, and adds the call chain to the original log to obtain the target log.

[0174] In the embodiments of the present application, after the log generation module acquires the main process identifier, it can acquire the call chain based on the main process identifier. As known from the above introduction, the call chain includes a binder chain and a lock chain. The binder chain includes the calling relationship between the main process and other processes. The lock chain can include the lock relationship between threads in the process, that is, the lock holding and lock waiting relationship. How to acquire the lock chain and the binder chain has been described in detail in the above embodiments, and will not be repeated here.

[0175] As a way, after the log generation module acquires the call chain based on the main process identifier, it can add the call chain to the original log to obtain the target log.

[0176] Step S250: The log generation module sends the kill instruction information to the fault processing module.

[0177] As a manner, after obtaining the target log, the log generation module can send the kill instruction information to the fault processing module to instruct the fault processing module to kill the main process, i.e., entering step S260.

[0178] For example, the kill instruction information can include the identifier of the process to be killed, and the fault processing module can kill the process corresponding to the identifier after receiving the kill instruction information.

[0179] As another manner, after obtaining the target log, the log generation module can also instruct the electronic device to output a prompt box, and when detecting that the user inputs the instruction information of "closing the application", the log generation module can send the kill instruction information to the fault processing module.

[0180] Step S260: The fault processing module kills the main process.

[0181] As a manner, after receiving the kill instruction information, the fault processing module can kill the main process, i.e., forcibly closing the application program.

[0182] As shown in Figure 10 Another embodiment of the present application provides a log generation method, which can include the following steps S301-S314.

[0183] Step S301: The fault detection module determines whether the electronic device has a system watchdog exception.

[0184] As known from the above introduction, the system watchdog exception can be caused by the blocking of the system service process of the electronic device during running, i.e., the blocking of a thread in the system service process causes the system watchdog exception of the electronic device. Therefore, when determining whether the electronic device has a system watchdog exception, the fault detection module can determine whether the system service process has a blocking event, and if the system service process has a blocking event, it is determined that the electronic device has a system watchdog exception.

[0185] As a manner, the fault detection module can first obtain the waiting time of the system service process, and when the waiting time exceeds a second specified time length, it is determined that the electronic device has a system watchdog exception. The second specified time length can be 30s. For example, the system service process is blocked when performing a corresponding task, and the blocking time exceeds the second specified time length, at which time it is determined that the electronic device has a system watchdog exception.

[0186] In some embodiments, if the fault detection module determines that the system watchdog exception occurs in the electronic device, the process identifier related to the exception is acquired, i.e., step S302 is entered. In addition, if the fault detection module does not detect that the system unresponsive exception occurs in the electronic device, the system unresponsive exception can be continuously monitored.

[0187] Step S302: The fault detection module acquires the process identifier related to the exception.

[0188] In the embodiments of the present application, the fault detection module can acquire the process identifier related to the exception when the waiting time of the system service process exceeds the second specified time length. In addition, the process identifier related to the exception can be the process identifier corresponding to the system service process.

[0189] Step S303: The fault detection module sends the process identifier to the log generation module.

[0190] As a way, when the fault detection module acquires the process identifier related to the exception, it can send the process identifier to the log generation module to instruct the log generation module to acquire the first call chain.

[0191] Step S304: The log generation module acquires the binder chain and the lock chain of the first call chain related to the process identifier, and adds the binder chain and the lock chain to the first original log to obtain the first target log.

[0192] As known from the above introduction, the binder chain can include the call relationship between the system service process and other processes. In addition, the process can include multiple threads, and these threads usually exist in the case of holding a lock and waiting for a lock, so the lock chain can be formed. The lock chain includes the lock relationship between threads in the same process. How to acquire the lock chain and the binder chain is described in detail in the above embodiments, and will not be repeated here.

[0193] Step S305: The log generation module sends the deadlock detection indication information to the deadlock detector.

[0194] The deadlock detection indication information is used to instruct the deadlock detector to detect whether the system service process has a deadlock event. In addition, the deadlock detection indication information can carry the binder chain and the lock chain.

[0195] Step S306: The deadlock detector determines whether the system service process has a deadlock event based on the lock chain.

[0196] In some implementations, a deadlock event refers to a situation where all threads within the same process are in a lock-equaling state, and a closed-loop lock-equaling state is formed among the threads during the lock-equaling process. Therefore, when a deadlock detector receives a deadlock detection indication, it can determine whether a deadlock event has occurred in the system service process based on the lock chain. To better understand the lock chain corresponding to deadlock, embodiments of this application provide, as follows: Figure 10 The diagram shown.

[0197] pass Figure 10 It can be seen that the lock that thread 1 "Tid:1" is waiting for is held by thread 3 "Tid:3", the lock that thread 3 "Tid:3" is waiting for is held by thread 4 "Tid:4", and the lock that thread 4 "Tid:4" is waiting for is held by thread 1 "Tid:1". Therefore, ​ Threads 1, 3, and 4 are all in a lock-equaling state, and a closed-loop lock-equaling state is formed among the threads. As a result, none of the threads can acquire the lock, thus a deadlock event occurs.

[0198] In one approach, when the deadlock detector determines that a deadlock event has occurred in a system service process, it can send a kill instruction to the fault handling module, which then proceeds to step S307.

[0199] Step S307: The deadlock detector sends a kill instruction to the fault handling module.

[0200] In one approach, after determining that a deadlock event has occurred in a system service process, the deadlock detector can send a kill instruction to the fault handling module, instructing the fault handling module to kill the peer process of the system service process, i.e., proceed to step S308. For example, the kill instruction may include the identifier of the process to be killed, which may be the identifier of the peer process.

[0201] Step S308: The fault handling module kills the peer process.

[0202] In some implementations, when the fault handling module receives a kill instruction from the log generation module, it can kill the peer process based on its identifier, i.e., shut down the peer process. The peer process can be the last process in the binder call chain.

[0203] As an example, the binder call chain obtained by the log generation module is in the form of: A→B→C. Here, A represents the system service process. When a deadlock event is determined to have occurred in the system service process, the fault handling module can kill the peer process C, that is, shut down process C.

[0204] In some embodiments, after the failure handling module kills the peer process, the failure handling module can send a recovery detection request to the failure detection module, i.e., step S309.

[0205] Step S309: The failure handling module sends a recovery detection request to the failure detection module.

[0206] Step S310: The failure detection module determines whether the electronic device has returned to normal operation.

[0207] As one way, after receiving the recovery detection request, the failure detection module can determine whether the electronic device has returned to normal operation when the waiting time of the system service process reaches the third specified time length. The return to normal operation can be that the system service process is switched from the blocking state to the normal operation state, i.e., the system watchdog exception is eliminated. The second specified time length can be 60s.

[0208] In addition, if the electronic device returns to normal operation, the failure detection module can continue to detect the system watchdog exception of the electronic device. If the electronic device does not return to normal operation, a log acquisition request is sent to the log generation module, i.e., step S311.

[0209] Step S311: The failure detection module sends a log acquisition request to the log generation module.

[0210] Step S312: The log generation module acquires the second call chain and adds the second call chain to the second original log to obtain the second target log.

[0211] In some embodiments, the log generation module can acquire the second call chain and add the second call chain to the second original log when receiving the log acquisition request.

[0212] The second call chain can also include a binder chain and a lock chain. In addition, the binder chain includes the calling relationship between the main process and other processes. The lock chain includes the relationship between locks in the same process, i.e., the relationship of holding locks and waiting for locks. It should be noted that the second call chain and the first call chain can be the same or different, and the actual situation is specific.

[0213] In the embodiments of the present application, the second original log and the first original log contain logs with the same format, and the difference between them is the time when the logs are generated. In other words, the first log and the second target log contain logs with basically the same content, and the difference is the time when they are generated.

[0214] Step S313: The log generation module sends system restart instruction information to the failure handling module.

[0215] In some embodiments, after obtaining the target log, the log generation module can send system restart instruction information to the fault processing module to instruct the fault processing module to restart the system of the electronic device.

[0216] Step S314: The fault processing module restarts the system.

[0217] In the embodiments of the present application, when the fault processing module receives the system restart instruction information, it can restart the system of the electronic device. Specifically, the fault processing module can directly kill the system service process to restart the system. For example, the binder call chain obtained by the log generation module is in the form of A→B→C. Wherein, A can be a system service process, and when restarting the system, the fault processing module can directly close the process A, so that the system of the electronic device enters the restart state.

[0218] It can be understood that, in order to realize the above functions, the electronic device contains corresponding hardware and / or software modules for executing various functions. The algorithm steps of each example described in conjunction with the embodiments disclosed herein can be realized in the form of hardware or a combination of hardware and computer software. Whether a certain function is realized in the form of hardware or computer software driving hardware depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application in conjunction with the embodiments, but such implementation should not be considered beyond the scope of the present application.

[0219] The embodiments also provide a computer storage medium, which stores computer instructions, when the computer instructions are run on an electronic device, the electronic device executes the related method steps described above to realize the log generation method in the embodiments described above.

[0220] The embodiments also provide a computer program product, when the computer program product is run on a computer, the computer executes the related steps described above to realize the log generation method in the embodiments described above.

[0221] In addition, the embodiments of the present application also provide 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 is running, the processor can execute the computer execution instructions stored in the memory to make the chip execute the log generation method in the method embodiments described above.

[0222] Among them, the electronic device, computer storage medium, computer program product or chip provided by the embodiments can be used to execute the corresponding method provided above, so the beneficial effects that can be achieved are referred to the beneficial effects in the corresponding method provided above, which will not be described here.

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

[0224] 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 schematic, for example, the division of the 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 units shown or discussed can be indirect coupling or communication connection through some interface, device or unit, and can be electrical, mechanical or other forms.

[0225] The units described as separate components can or can not be physically separate, and the components shown as units can be one physical unit or multiple physical units, that is, can be located in one place, or can be distributed to multiple different places. Part or all of the units can be selected according to actual needs to achieve the purpose of the embodiment scheme.

[0226] In addition, each functional unit in each embodiment of the present application can be integrated in one processing unit, or each unit can be physically present alone, or two or more units can be integrated in one unit. The integrated unit can be realized in the form of hardware or in the form of a software functional unit.

[0227] Any content of each embodiment of the present application, and any content of the same embodiment, can be freely combined. Any combination of the above is within the scope of the present application.

[0228] The integrated unit, if implemented in the form of a software function unit and sold or used as an independent product, can be stored in a readable storage medium. Based on such understanding, the technical solutions of the embodiments of the present application, essentially or in other words, the part that contributes to the prior art, or all or part of the technical solutions can be embodied in the form of a software product. The software product is stored in a storage medium, including a number of instructions to make a device (which can be a single-chip microcomputer, a chip, etc.) or a processor execute all or part of the steps of the various embodiments of the method of the present application. The aforementioned storage medium includes: a U disk, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk, and various media that can store program codes.

[0229] The embodiments of the present application are described above in combination with the drawings, but the present application is not limited to the specific embodiments described above, and the specific embodiments described above are only illustrative, not limiting. Those skilled in the art can make many forms under the inspiration of the present application without departing from the scope of the present application and the scope of protection of the claims.

Claims

1. A log generation method, characterized in that, Applied to electronic devices, the method includes: In the event of a malfunction in the electronic device, a first raw log related to the malfunction is obtained, as well as a process identifier related to the malfunction; the first raw log includes an application unresponsive log, a system watchdog exception log, or a long key press log. A first call chain is obtained based on the process identifier. The first call chain includes a binder chain and a lock chain. The binder chain includes a first process corresponding to the process identifier and a second process that has a call relationship with the first process. The lock chain includes the call relationships between threads in the first process and the call relationships between threads in the second process. The first call chain is added to the beginning or end of the first original log to obtain the first target log; Obtain the position information of the first call chain in the first target log, and write the position information to the beginning position of the first target log.

2. The method according to claim 1, characterized in that, The step of obtaining the process identifier related to the fault includes: If the fault is that the application is unresponsive, then obtain the main process identifier corresponding to the abnormal application and use the main process identifier as the process identifier related to the fault.

3. The method according to claim 2, characterized in that, After obtaining the first target log, the process includes: Kill the process corresponding to the main process identifier.

4. The method according to claim 1, characterized in that, The step of obtaining the process identifier related to the fault includes: If the fault is a system watchdog malfunction, the identifier of the system service process is obtained and used as the process identifier related to the fault.

5. The method according to claim 4, characterized in that, After obtaining the first target log, the process includes: Based on the lock chain, determine whether a deadlock event has occurred in the system service process; If a deadlock event occurs in the system service process, the peer process of the system service process is determined based on the binder chain, and the peer process is killed.

6. The method according to claim 5, characterized in that, After killing the peer process, the following is included: If the electronic device fails to return to normal operation, then obtain the second call chain and the second original log related to the fault. The second call chain is added to the second original log to obtain the second target log.

7. The method according to claim 6, characterized in that, After obtaining the second target log, the process includes: Kill the system service process.

8. The method according to any one of claims 1 to 7, characterized in that, The process call depth in the binder chain is 3 levels.

9. An electronic device, characterized in that, include: One or more processors; Memory; And one or more computer programs, wherein the one or more computer programs are stored on the memory, and when the computer programs are executed by the one or more processors, cause the electronic device to perform the following steps: in the event of a malfunction of the electronic device, obtaining a first raw log related to the malfunction, and obtaining a process identifier related to the malfunction; the first raw log includes an application unresponsive log, a system watchdog exception log, or a long key press log; A first call chain is obtained based on the process identifier. The first call chain includes a binder chain and a lock chain. The binder chain includes a first process corresponding to the process identifier and a second process that has a call relationship with the first process. The lock chain includes the call relationships between threads in the first process and the call relationships between threads in the second process. The first call chain is added to the beginning or end of the first original log to obtain the first target log; Obtain the position information of the first call chain in the first target log, and write the position information to the beginning position of the first target log.

10. The device according to claim 9, characterized in that, When the computer program is executed by the one or more processors, the electronic device performs the following steps: If the fault is that the application is unresponsive, then obtain the main process identifier corresponding to the abnormal application and use the main process identifier as the process identifier related to the fault.

11. The device according to claim 10, characterized in that, When the computer program is executed by the one or more processors, the electronic device performs the following steps: Kill the process corresponding to the main process identifier.

12. The device according to claim 9, characterized in that, When the computer program is executed by the one or more processors, the electronic device performs the following steps: If the fault is a system watchdog malfunction, the identifier of the system service process is obtained and used as the process identifier related to the fault.

13. The device according to claim 12, characterized in that, When the computer program is executed by the one or more processors, the electronic device performs the following steps: Based on the lock chain, determine whether a deadlock event has occurred in the system service process; If a deadlock event occurs in the system service process, the peer process of the system service process is determined based on the binder chain, and the peer process is killed.

14. The device according to claim 13, characterized in that, When the computer program is executed by the one or more processors, the electronic device performs the following steps: If the electronic device fails to return to normal operation, then obtain the second call chain and the second original log related to the fault. The second call chain is added to the second original log to obtain the second target log.

15. The device according to claim 14, characterized in that, When the computer program is executed by the one or more processors, the electronic device performs the following steps: Kill the system service process.

16. The device according to any one of claims 9 to 15, characterized in that, The process call depth in the binder chain is 3 levels.

17. A computer-readable storage medium comprising a computer program, characterized in that, When the computer program is run on an electronic device, it causes the electronic device to perform the log generation method as described in any one of claims 1-8.

Images