Crash log monitoring method, device, apparatus and storage medium
By listening to and filtering crash logs of Android applications, the problem of difficulty in collecting crash information caused by Android system fragmentation is solved, enabling fast and accurate crash problem resolution.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- TCL OVERSEAS ELECTRONIC (HUIZHOU) CO LTD
- Filing Date
- 2022-04-15
- Publication Date
- 2026-06-23
Smart Images
Figure CN114741224B_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of computer application technology, and specifically to a method, device, apparatus, and storage medium for monitoring crash logs. Background Technology
[0002] For many software applications, users often encounter abnormal problems while using the software, and they are often at a loss. The process of feedback through multiple layers and then solving the problem through the software is time-consuming and has a cycle. It is often time-consuming and laborious to reproduce the problem and troubleshoot it, which is not worth the effort.
[0003] Android is a free and open-source operating system based on Linux, primarily used on mobile devices such as smartphones and tablets. Due to its open-source nature, Android has attracted a large number of developers, leading to multiple versions of the Android system and applications on the market. This proliferation of versions has resulted in poor system compatibility, severe fragmentation of the Android system, and frequent application crashes. Some serious crashes even occur after software release, degrading the user experience. Crashes are unavoidable in development; poorly designed code, unreliable network conditions, and troublesome fragmentation can all cause crashes. Worse still, when an application crashes, developers often cannot determine the cause, thus requiring information about the crash at the time of the crash. Therefore, collecting crash information is crucial. However, current technology lacks effective methods for collecting crash information. Summary of the Invention
[0004] This invention provides a method, device, apparatus, and storage medium for monitoring crash logs, aiming to solve the technical problem of not being able to effectively collect valid exception data after a program encounters an exception.
[0005] To achieve the above objectives, the present invention provides a method for monitoring crash logs, comprising:
[0006] If an exception is detected in the running application, the corresponding exception data of the application is obtained.
[0007] The abnormal data is filtered based on the abnormal type it corresponds to, and the filtered abnormal data is then stored.
[0008] To achieve the above objectives, this application also proposes a crash log monitoring device, comprising:
[0009] The data acquisition module is used to obtain the corresponding exception data of the running application if an exception is detected.
[0010] The data filtering module is used to filter abnormal data based on the abnormality type corresponding to the abnormal data, and to store the filtered abnormal data.
[0011] To achieve the above objectives, this application also proposes a crash log monitoring device, which includes a memory, a processor, and a crash log monitoring program stored in the memory and executable on the processor. When the processor executes the crash log monitoring program, it implements the steps of the crash log monitoring method described above.
[0012] To achieve the above objectives, this application also proposes a computer-readable storage medium storing a crash log listener, which, when executed by a processor, implements the steps of the crash log listening method described above.
[0013] In this application, by monitoring the application, if abnormal behavior of the application is detected and causes a crash, the abnormal data corresponding to the abnormal behavior is obtained, and then the abnormal data is filtered and stored. This allows development and maintenance personnel to observe application abnormalities based on the stored abnormal data, and resolve crash problems more promptly and accurately, avoiding the need to spend a lot of time investigating the cause of the crash. Attached Figure Description
[0014] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on the structures shown in these drawings without creative effort.
[0015] Figure 1 This is a schematic diagram of the module structure of a crash log monitoring method according to an embodiment of the present invention;
[0016] Figure 2 This is a flowchart of a crash log monitoring method according to an embodiment of the present invention;
[0017] Figure 3 This is a schematic diagram of the module structure of a crash log monitoring method according to an embodiment of the present invention. Detailed Implementation
[0018] It should be understood that the specific embodiments described herein are merely illustrative of the invention and are not intended to limit the invention.
[0019] Please refer to Figure 1 , Figure 1This is a schematic diagram of the hardware structure of the crash log monitoring device provided in various embodiments of the present invention. The crash log monitoring device includes components such as an execution module 01, a memory 02, a processor 03, and a battery system. Those skilled in the art will understand that... Figure 1 The device shown may also include more or fewer components than illustrated, or combine certain components, or have different component arrangements. The processor 03 is connected to both the memory 02 and the execution module 01. The memory 02 stores a crash log monitoring program, which is simultaneously executed by the processor 03.
[0020] Execution module 01 can obtain the corresponding exception data of the running application if it detects an exception; it can filter the exception data based on the exception type and store the filtered exception data. At the same time, it sends the above information back to processor 03.
[0021] Memory 02 can be used to store software programs and various data. Memory 02 may mainly include a program storage area and a data storage area. The program storage area may store the operating system, applications required for multiple functions, etc.; the data storage area may store data or information created based on the use of IoT terminals, etc. In addition, memory 02 may include high-speed random access memory, and may also include non-volatile memory, such as multiple disk storage devices, flash memory devices, or other volatile solid-state storage devices.
[0022] Processor 03 is the control center of the processing platform. It connects various parts of the entire IoT terminal via various interfaces and lines. By running or executing software programs and / or modules stored in memory 02, and by calling data stored in memory 02, it performs various functions of the IoT terminal and processes data, thereby providing overall monitoring of the crash log monitoring device. Processor 03 may include one or more processing units; preferably, processor 03 may integrate an application processor and a modem processor. The application processor mainly handles the operating system, user interface, and applications, while the modem processor mainly handles wireless communication. It is understood that the modem processor may not be integrated into processor 03.
[0023] Those skilled in the art will understand that Figure 1 The structure of the crash log monitoring device shown in the diagram does not constitute a limitation on the device and may include more or fewer components than shown, or combine certain components, or have different component arrangements.
[0024] Based on the above hardware structure, various embodiments of the method of the present invention are proposed.
[0025] To address the aforementioned issues, this application proposes a crash log monitoring method, referring to... Figure 2 In a first embodiment of the crash log monitoring method of the present invention, the crash log monitoring method includes:
[0026] Step S100: If an exception is detected in the running application, obtain the exception data corresponding to the application.
[0027] In this embodiment, there are at least two ways to monitor the application. The first method is global exception monitoring, which involves defining a custom global monitoring entry point, setting a global exception handling class that implements the exception handler class interface, and globally setting it as the exception handling monitor. The second method is single-threaded exception monitoring, which involves setting a single-threaded exception handler class interface and setting exception handling monitors separately for different threads. In one embodiment, global exception monitoring can be achieved by defining a custom global Application class and a custom CrashHandler, then setting CrashHandler as the global exception handling class for global exception monitoring. In another embodiment, single-threaded exception monitoring targets only a single thread. When an uncaught exception occurs in the application, the Java Virtual Machine will use the getDefaultUncaughtExceptionHandler method to query the UncaughtExceptionHandler for that thread to monitor for exceptions within that thread.
[0028] In this embodiment, regardless of whether a global exception listener or a single-threaded exception listener is used, as long as an application exception is detected, the application's exception data can be obtained. For example, when the application starts running, a listener interface is loaded for each application and initialized; these listener interfaces are used to monitor for exceptions in the native layer.
[0029] Specifically, firstly, listener interfaces are loaded for each application. In this embodiment, the listener interface is implemented through a listener, which is a regular Java program that implements a specific interface. The listener is used to monitor method calls or attribute changes of another Java object. Each listener interface contains several abstract methods for handling the aforementioned events. Typically, each application has a listener interface corresponding to a listener, and each interface can also define one or more listener methods. When a specific event occurs, these listener methods are called. For example, when a method call or attribute change event occurs on the monitored object, the specific listener method set in the listener interface will be executed immediately. The listener interface in this application is used to monitor whether an exception occurs in the Native layer. Linux has a signal mechanism, which is an important way for Linux processes to communicate. Linux signals are used for normal task scheduling and inter-process communication. On the other hand, they are also responsible for monitoring system exceptions and interrupts. When a system exception occurs, the Linux kernel generates exception data and notifies the current process. When the listener program receives the exception data notification from the Linux kernel, it knows that an exception has occurred in the Native layer, and then obtains the exception data at the time of the exception.
[0030] Step S200: Filter the abnormal data based on the abnormal type corresponding to the abnormal data, and store the filtered abnormal data.
[0031] In this embodiment, after acquiring the exception data when the application encounters an exception, further filtering of the exception data is required. The filtering rules are pre-set by those skilled in the art and can be adjusted in real time. Specifically, there are many reasons that can cause application exceptions at the Native level, such as hardware malfunctions, illegal memory access, memory crashes, or errors in libraries called by the process, causing the process to send a termination signal and terminate itself. Since the causes of application exceptions vary, the exception data at the time of the exception also varies. Exception data refers to useful software and hardware information involved in the application's operation. For example, exception data might be logcat logs recording the exception occurrence process, information about the terminal device being used, or basic information about the crashed application. Collecting this type of exception data helps program developers fully understand the specific reasons for Native crashes. Therefore, when an application encounters an exception, different exception data needs to be collected, filtered, and then the filtered exception data stored.
[0032] This application monitors the application. If abnormal behavior is detected that causes the application to crash, the application obtains the abnormal data corresponding to the abnormal behavior, filters the abnormal data, and stores the filtered abnormal data. This allows developers and maintainers to observe application anomalies based on the stored abnormal data, resolve crashes more promptly and accurately, and avoid spending a lot of time investigating the cause of the crash.
[0033] Specifically, before capturing abnormal data, it is necessary to capture the exception interface and obtain the abnormal data through this interface. In this embodiment, if abnormal data occurs in the application, it can be obtained through the exception capture interface. The exception interface is the interface for obtaining abnormal data. Specifically, if an uncaught exception occurs in the Native layer, the abnormal data can be obtained through the exception capture interface.
[0034] Furthermore, there are many reasons why an application might encounter exceptions. That is, there are many types of exceptions corresponding to the exception data. We can retrieve the corresponding exception types from the exception data and then filter the exception data based on these types. In other words, we can store exception data of a subset of exception types and filter out exception data of another subset.
[0035] As mentioned above, exceptions such as hardware malfunctions, code errors, illegal memory access, memory crashes, or errors in libraries called by a process causing it to send a termination signal and terminate itself, can all lead to application exceptions. Since the causes of application exceptions vary, the types of exceptions that occur also differ. These exception types can be obtained from exception data. In one embodiment, exception data for hardware malfunctions, code errors, and illegal memory accesses needs to be saved, while other exception types need to be filtered.
[0036] For example, consider the following C code:
[0037] int*p = 0;
[0038] *p = 1;
[0039] When the second line of code is executed, the program crashes. The pointer `p` defined here is a null pointer; assigning a value to a null pointer is not allowed, which will cause a native exception, leading to a crash. This type of exception can be categorized as a code exception.
[0040] Therefore, the abnormal data can be stored. This embodiment obtains the abnormal data corresponding to the abnormal data and filters the abnormal data according to the abnormal data type, which can quickly obtain abnormal data of higher priority types, which facilitates program maintenance and saves memory.
[0041] In one embodiment, if an exception is detected in a running application, after obtaining the exception data corresponding to the application, the method further includes:
[0042] An error message is sent based on the abnormal data. The error message is used to notify the user that an error has occurred.
[0043] In one embodiment, if an exception is detected in a running application, the exception data corresponding to the application is obtained, including:
[0044] If a running application is detected as about to crash or has already crashed, then obtain the corresponding exception data for the application that is about to crash or has already crashed.
[0045] Normally, if an application encounters an exception, it will further lead to a crash. When a crash occurs, the system will kill the running application, causing it to crash or prompting the user that the application has stopped running. However, in this embodiment, if the system detects an exception in the application, and the exception is causing the application to crash or detects that the application has already crashed, it will obtain the exception data corresponding to the crash and send an exception prompt message to the user based on the exception data, to inform the user that the application has encountered an exception and may be about to crash or has already crashed.
[0046] If the application has not yet crashed, the error message can prompt the user to take action to avoid a crash; if the application has already crashed, the error message can prompt the user to prevent the system from killing the running application, thus preventing the impact of the crash from spreading further.
[0047] In one embodiment, the abnormal data is filtered based on the abnormal type corresponding to the abnormal data, and the filtered abnormal data is stored, including:
[0048] The anomaly type corresponding to the abnormal data is determined based on the pre-set anomaly type priority.
[0049] If the anomaly type of the abnormal data is of important priority, then the abnormal data is set as important abnormal data and stored as important abnormal data; where important abnormal data is abnormal data that is about to become uncontrollable, and important priority is the anomaly type that has a corresponding relationship with important abnormal data.
[0050] In one embodiment, after determining the exception type corresponding to the exception data based on a pre-set exception type priority, the method further includes:
[0051] If the anomaly type of the abnormal data is of general priority, then the abnormal data is set as general abnormal data and filtered; where general abnormal data is controllable abnormal data, and general priority is the anomaly type that has a corresponding relationship with general abnormal data.
[0052] In this embodiment, based on the priority of the anomaly type, the abnormal data can be divided into important abnormal data and general abnormal data. The priority of the abnormal data is preset by those skilled in the art or by the user and can be adjusted in real time according to specific circumstances. Specifically, those skilled in the art can set the priority of abnormal data based on its impact, or they can set the priority of abnormal data based on the user's set level of attention.
[0053] In some embodiments, abnormal data is prioritized based on its impact. Among the abnormal data's corresponding abnormal types, some abnormal types cause crashes that are controllable, while others cause crashes that are uncontrollable. To avoid uncontrollable data anomalies causing excessive impact, it is necessary to filter out and store uncontrollable abnormal data. Therefore, the abnormal types of uncontrollable abnormal data are set as important priorities, and these important priority abnormal data are filtered out and stored so that those skilled in the art can maintain and repair the application based on these important priority abnormal data in subsequent processes.
[0054] In other embodiments, abnormal data is categorized based on user priority. If a user wants to analyze exceptions related to illegal memory access, this type can be set as a high priority, while other exception types are set to general priority. The high-priority exception data is then stored, and the general-priority exception data is filtered. This data categorization and storage method in this embodiment allows for the centralized collection of abnormal data of high user interest, enabling users to quickly obtain the exception types they want for unified analysis.
[0055] Furthermore, in this embodiment, all types can be set to high priority, or all types can be set to low priority. Alternatively, all abnormal data can be flexibly divided into three, four, or even more priority categories based on data type; no specific limitation is made here. By dividing abnormal data into categories, users can store only the abnormal data that is of high importance to them, while filtering out some less important abnormal data, thereby saving memory.
[0056] In one embodiment, storing the filtered abnormal data includes:
[0057] Store the filtered abnormal data to a specified path on the device or storage disk.
[0058] In this embodiment, the abnormal data records key information about the crash. By analyzing this data, developers can identify the cause of the crash. Furthermore, the abnormal data may contain duplicate information; therefore, a deduplication process is required before storing the abnormal data. Further, storing the filtered abnormal data can involve writing it to a specified path on the device where the application runs, storing it in a specified path on a storage disk, or uploading it to a cloud server. It is worth noting that abnormal data can be stored using one or more of these methods. After storing the abnormal data, developers can retrieve it based on its storage path or method and analyze it to maintain and repair the application.
[0059] In one embodiment, after storing the filtered abnormal data into a designated path on a device or storage disk, the method further includes:
[0060] If an abnormal data export request is received;
[0061] The export request is verified. If the verification passes, the filtered abnormal data is exported.
[0062] In this embodiment, after the filtered abnormal data is stored in the form of log information on a device, storage disk, or cloud server, users need to pass identity verification if they want to read or export this stored abnormal data. Only after passing identity verification can users read or export the stored abnormal data; if identity verification fails, users cannot read or export the stored abnormal data.
[0063] like Figure 3 As shown, the present invention also proposes a crash log monitoring device, which includes:
[0064] The data acquisition module A10 is used to obtain the corresponding exception data of the running application if an exception is detected.
[0065] The data filtering module A20 is used to filter abnormal data based on the abnormality type corresponding to the abnormal data, and to store the filtered abnormal data.
[0066] As one implementation of this application, the data acquisition module A10 includes:
[0067] Anomaly alert unit: used to send anomaly alert information based on the abnormal data, the anomaly alert information being used to alert the user that an anomaly has occurred.
[0068] As one implementation of this application, the data acquisition module A10 further includes:
[0069] The data acquisition unit is used to obtain abnormal data corresponding to the application that is about to crash or has already crashed if it is detected that the running application is about to crash or has already crashed.
[0070] As one implementation of this application, the data acquisition module A20 includes:
[0071] A determination unit is used to determine the anomaly type corresponding to the anomaly data according to a pre-set anomaly type priority.
[0072] The first setting unit is configured to set the abnormal data as important abnormal data and store the important abnormal data if the abnormal data has an important priority; wherein the important abnormal data is abnormal data that is about to become uncontrollable, and the important priority is an abnormal type that has a corresponding relationship with the important abnormal data.
[0073] As one implementation of this application, the data acquisition module A20 further includes:
[0074] The second setting unit is used to set the abnormal data as general abnormal data and filter the general abnormal data if the abnormal data has a general priority. The general abnormal data is controllable abnormal data, and the general priority is an abnormal type that corresponds to the general abnormal data.
[0075] As one implementation of this application, the data acquisition module A20 further includes:
[0076] A storage unit is used to store the filtered abnormal data into a specified path in a device or storage disk.
[0077] As one implementation of this application, the data acquisition module A20 further includes:
[0078] The receiving unit is used to handle requests to export abnormal data if such requests are received.
[0079] The verification unit is used to verify the identity of the export request. If the identity verification passes, the filtered abnormal data is exported.
[0080] The crash log listener is used to implement crash log listening methods at runtime.
[0081] The present invention also proposes a crash log monitoring device, which includes a memory, a processor, and a crash log monitoring program stored in the memory and executable on the processor. When the processor executes the crash log monitoring program, it implements the steps of the methods of various embodiments of the present invention.
[0082] This invention also proposes a computer-readable storage medium storing a crash log monitoring program. When executed by a processor, the crash log monitoring program implements the steps of the aforementioned crash log monitoring method. The storage medium includes a computer-readable storage medium, which can be... Figure 1 The memory in the storage medium can be at least one of ROM (Read-Only Memory) / RAM (Random Access Memory), magnetic disk, optical disk, etc. The storage medium includes several instructions to cause an Internet of Things (IoT) terminal device with a processor (which may be a mobile phone, computer, server, IoT terminal, or network device, etc.) to execute the methods of the various embodiments of the present invention.
[0083] In this invention, the terms "first," "second," "third," "fourth," and "fifth" are used for descriptive purposes only and should not be construed as indicating or implying relative importance. Those skilled in the art can understand the specific meaning of the above terms in this invention according to the specific circumstances.
[0084] In the description of this specification, the references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in multiple embodiments or examples of the present invention. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of different embodiments or examples.
[0085] Although embodiments of the present invention have been shown and described above, the scope of protection of the present invention is not limited thereto. It is understood that the above embodiments are exemplary and should not be construed as limiting the present invention. Those skilled in the art can make changes, modifications, and substitutions to the above embodiments within the scope of the present invention, and such changes, modifications, and substitutions should all be covered within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.
Claims
1. A method for monitoring crash logs, characterized in that, include: If an exception is detected in a running application, the exception data corresponding to the application is obtained. The exception includes the application being about to crash and the application having already crashed. The step of obtaining the exception data corresponding to the application if an exception is detected in a running application includes: when it is detected that a running application is about to crash, obtaining the first exception data of the application that is about to crash; when it is detected that the application has already crashed, obtaining the second exception data of the application that has already crashed. Based on the first abnormal data, a first abnormal prompt message is sent to the user to prompt the user to take action in order to avoid a crash; based on the second abnormal data, a second abnormal prompt message is sent to the user to prompt the user to prevent the system from killing the running application; The abnormal data is filtered based on its corresponding anomaly type, and the filtered abnormal data is stored. The step of filtering the abnormal data based on its corresponding anomaly type and storing the filtered abnormal data includes: The anomaly type corresponding to the abnormal data is determined according to the pre-set anomaly type priority. If the anomaly type of the abnormal data is of general priority, then the abnormal data is set as general abnormal data and filtered to save memory. If the anomaly type of the abnormal data is of high priority, then the abnormal data is set as important abnormal data and stored, so as to maintain and repair the application based on the important abnormal data.
2. The method as described in claim 1, characterized in that, The stored and filtered abnormal data includes: The filtered abnormal data is stored in a specified path on the device or storage disk.
3. The method as described in claim 2, characterized in that, After storing the filtered abnormal data into a specified path on the device or storage disk, the method further includes: If an abnormal data export request is received; The export request is verified for identity. If the identity verification passes, the filtered abnormal data is exported.
4. A crash log monitoring device, characterized in that, include: The data acquisition module is used to obtain the corresponding abnormal data of the running application if an abnormality is detected. The abnormality of the application includes the application being about to crash and the application having already crashed. The data acquisition module is used to obtain the first abnormal data of the application that is about to crash when the running application is detected to be about to crash; and to obtain the second abnormal data of the application that has already crashed when the application is detected to have already crashed. The data acquisition module is used to send a first abnormality prompt message to the user based on the first abnormality data to prompt the user to take action in order to avoid a crash; and to send a second abnormality prompt message to the user based on the second abnormality data to prompt the user to prevent the system from killing the running application. The data filtering module is used to filter the abnormal data based on the abnormal type corresponding to the abnormal data, and store the filtered abnormal data; the data filtering module is used to determine the abnormal type corresponding to the abnormal data according to the pre-set abnormal type priority. If the anomaly type of the abnormal data is of general priority, then the abnormal data is set as general abnormal data and filtered to save memory. If the anomaly type of the abnormal data is of high priority, then the abnormal data is set as important abnormal data and stored, so as to maintain and repair the application based on the important abnormal data.
5. A crash log monitoring device, characterized in that, The crash log monitoring device includes a memory, a processor, and a crash log monitoring program stored in the memory and executable on the processor. When the processor executes the crash log monitoring program, it implements the steps of the crash log monitoring method as described in any one of claims 1 to 3.
6. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a crash log listener program, which, when executed by a processor, implements the steps of the crash log listening method as described in any one of claims 1 to 3.