A stability fault analysis method, apparatus, medium, and equipment

Abstract

This invention provides a stability fault analysis method, apparatus, medium, and device. The method includes: acquiring log files from the raw log data of an Android device; scanning each log file to identify whether it contains content that matches a fault type identification fingerprint in a preset fault type identification fingerprint database; if so, determining one or more stability faults of different fault types present in the Android device, and identifying the corresponding first anchor point data in the log file; summarizing the first anchor point data of all log files according to fault type to obtain the corresponding second anchor point data; and extracting corresponding feature index data from the second anchor point data corresponding to each fault type based on a preset feature index fingerprint database, and performing analysis using corresponding analysis methods. This method can greatly improve the efficiency of retrieval and association of raw log data, and improve the accuracy of association of fault data in different log data corresponding to the same fault type.

Description

Technical Field

[0001] This invention relates to the field of Android device technology, and in particular to a technique for stability fault analysis. Background Technology

[0002] In existing technologies, stability fault analysis for Android devices typically requires manual switching and comparison between different raw log files, which is both time-consuming and has a high analysis threshold. With the increasing number of mobile applications and their growing functional complexity, the complexity of the Android system is also continuously increasing. The sources of raw log data in Android devices are becoming increasingly diverse, and the data volume is constantly expanding, further raising the analysis threshold and increasing the time consumption. Especially in the root cause analysis of stability faults such as crashes, application not responding (ANR), and software watchdog timeouts (SWT), there are still shortcomings such as low data retrieval efficiency and difficulty in determining the correlation between data from different sources, further complicating the qualitative analysis of root causes.

[0003] Therefore, optimizing the stability fault analysis method for Android devices to improve the efficiency of log data retrieval, increase the accuracy of determining the correlation between different log data, and thus improve the accuracy of determining the root cause of stability faults is an urgent technical problem to be solved. Summary of the Invention

[0004] In order to at least partially solve the above-mentioned technical problems, the purpose of this invention is to provide a stability fault analysis method, apparatus, medium, and Android device.

[0005] According to one aspect of the present invention, a stability failure analysis method is provided, wherein the method includes: Retrieve several log files from the raw log data of an Android device; Each log file is scanned to identify whether there is content that matches one or more fault type identification fingerprints in the preset fault type identification fingerprint database. If so, it is determined that the Android device has one or more fault types of stability faults, and the first anchor point data corresponding to the stability fault of each fault type in the log file is determined. The first anchor point data of all log files are summarized by fault type to obtain the second anchor point data corresponding to the stability fault of each fault type. The fault type identification fingerprint corresponds one-to-one with the fault type, and the fault type includes at least: Crash, ANR, and Watchdog / SWT. Based on a preset feature index fingerprint database, feature index data corresponding to the stability fault of each fault type is extracted from the second anchor point data corresponding to the stability fault of each fault type, and the feature index data corresponding to the stability fault of each fault type is analyzed using the analysis method corresponding to the fault type.

[0006] Optionally, the construction of the fault type identification fingerprint includes: Based on the fault type, several historical log files, including stability fault data, are classified and labeled to obtain a sample dataset corresponding to each fault type. For each fault type, feature data representing the fault type is extracted from each sample dataset. The feature data of all fault types are summarized to determine the first regular expression corresponding to the fault type. The first regular expression is then associated with the fault category identifier, applicable log file type, priority, and named capture field to obtain the fault type identification fingerprint corresponding to the fault type. The feature data includes at least text fragments, time format, process / thread identifier format, and performance parameter fields.

[0007] Optionally, the preset feature index fingerprint database includes at least: Fingerprint extraction methods include timestamp-based fingerprint extraction, process / thread identifier-based fingerprint extraction, and performance parameter-based fingerprint extraction. The time format data in the feature data of all different fault types are summarized, and a second regular expression is determined as the timestamp for fingerprint extraction. The process / thread identifier format data in the feature data of all different fault types are summarized, and a third regular expression is determined as the fingerprint for extracting process / thread identifiers. The same performance parameter field data in the feature data of all different fault types are summarized, and a fourth regular expression is determined as the performance parameter extraction fingerprint of the performance parameter.

[0008] Optionally, if the fault type includes Crash, the characteristic indicator data includes at least: Faulty process, abnormal thread, exception type, Java stack trace, and native backtrace; The step of employing an analysis method corresponding to the fault type to analyze the characteristic index data corresponding to the stability fault of each fault type includes: The determined characteristic index data is input into the Crash analysis algorithm, which outputs several possible root causes of the Crash stability failure and their confidence levels, and the possible root cause with the highest confidence level is determined as the root cause of the Crash stability failure.

[0009] Optionally, if the fault type includes ANR, the characteristic indicator data includes at least: CPU load for main thread response timeout, rendering metrics, and preset failure time window; The step of employing an analysis method corresponding to the fault type to analyze the characteristic index data corresponding to the stability fault of each fault type includes: The feature index data is vectorized to obtain a feature index data vector, and the feature index data vector is input into the ANR root cause analysis model to output several possible root causes of the stability failure of the ANR and their confidence levels. The possible root cause with the highest confidence level is determined as the root cause of the stability failure of the ANR.

[0010] Optionally, if the root cause of the ANR stability failure includes lock contention, a graph-based deadlock detection process is also triggered to further determine the root cause.

[0011] Optionally, the fault type identification fingerprint is iteratively updated based on the newly added log file.

[0012] Optionally, the step of determining the first anchor point data corresponding to the stability fault for each fault type in the log file includes: Record the log line number and timestamp that match the identification fingerprint of each fault type in the log file, and determine the corresponding context log data based on a preset window threshold. The context log data includes at least one of the following parameter fields: process / thread identifier, process / thread name, lock address or transaction identifier. The identification information of the log file, the timestamp, and the context log data are used as the first anchor point data corresponding to the stability fault of the fault type in the log file.

[0013] Optionally, the first anchor data of all log files is summarized according to fault type to obtain the second anchor data corresponding to the stability fault of each fault type, including: Based on timestamps and fault types, align the first anchor point data corresponding to stability faults of the same fault type across all log files; By concatenating the first anchor data corresponding to the stability fault of the fault type in each log file after aligning the parameter fields with the same parameters, the second anchor data corresponding to the stability fault of the fault type is obtained.

[0014] Optionally, the stability fault analysis method further includes: Summarize the analysis results of stability failures for each failure type and output an analysis report.

[0015] According to another aspect of the present invention, a stability failure analysis apparatus is provided, wherein the apparatus comprises: The first module is used to obtain several log files from the raw log data of the Android device; The second module is used to scan each log file to identify whether there is content that matches one or more fault type identification fingerprints in the preset fault type identification fingerprint database. If there is, it is determined that the Android device has one or more fault types of stability faults, and the first anchor point data corresponding to the stability fault of each fault type in the log file is determined. The first anchor point data of all log files is summarized by fault type to obtain the second anchor point data corresponding to the stability fault of each fault type. The fault type identification fingerprint corresponds one-to-one with the fault type. The fault types include at least: Crash, ANR and Watchdog / SWT. The third module is used to extract the characteristic index data corresponding to the stability fault of each fault type from the second anchor point data corresponding to the stability fault of each fault type based on the preset characteristic index fingerprint library, and to analyze the characteristic index data corresponding to the stability fault of each fault type using the analysis method corresponding to the fault type.

[0016] Optionally, the stability fault analysis device further includes: The fourth module is used to summarize the analysis results of stability failures for each type of failure and output an analysis report.

[0017] According to another aspect of the present invention, a computer-readable medium is provided, wherein computer-readable instructions are stored on the medium, which are executed by a processor to implement part or all of any of the above methods.

[0018] According to another aspect of the present invention, an apparatus is provided, wherein the apparatus comprises: One or more processors; and a memory storing computer-readable instructions that, when executed, cause the processor to perform some or all of the operations described above.

[0019] Compared with existing technologies, this invention provides a stability fault analysis method, apparatus, medium, and Android device. The method includes: acquiring several log files from the raw log data of the Android device; scanning each log file to identify whether it contains content matching one or more fault type identification fingerprints in a preset fault type identification fingerprint database; if so, determining that the Android device has one or more fault types of stability faults, and determining the first anchor point data corresponding to the stability fault of each fault type in the log files; and summarizing the first anchor point data of all log files according to fault type to obtain the second anchor point data corresponding to the stability fault of each fault type, wherein the fault type identification fingerprint corresponds one-to-one with the fault type, and the fault types include at least: Crash, ANR, and Watchdog / SWT; based on the preset feature index fingerprint database, extracting the feature index data corresponding to the stability fault of each fault type from the second anchor point data corresponding to the stability fault of each fault type, and analyzing the feature index data corresponding to the stability fault of each fault type using an analysis method corresponding to the fault type. This invention performs a unified fault type identification fingerprint matching scan on each log file in the acquired raw log data of an Android device to determine the anchor point data corresponding to the stability fault of the fault type. Feature index data is then extracted and analyzed, which can greatly improve the retrieval and association efficiency of raw log data and improve the accuracy of association of fault data in different log data corresponding to the same fault type. Attached Figure Description

[0020] Other features, objects, and technical effects of the present invention will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings: Figure 1 A schematic diagram of a stability fault analysis method for an Android device according to one aspect of the present invention is shown. Figure 2 A schematic diagram of a stability fault analysis apparatus deployed on an Android device according to another aspect of the present invention is shown. The same or similar reference numerals in the accompanying drawings represent the same or similar parts. Detailed Implementation

[0021] The present invention will now be described in further detail with reference to the accompanying drawings.

[0022] In a typical configuration of various embodiments of the present invention, the method execution entity, each trusted party of the system and / or each module of the device may include one or more processors (CPU), input / output interfaces, network interfaces and memory.

[0023] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0024] Computer-readable media include both permanent and non-permanent, removable and non-removable media that can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include non-transitory computer-readable media, such as modulated data signals and carrier waves.

[0025] To further illustrate the technical means adopted and the effects achieved by the present invention, the technical solution of the present invention will be clearly and completely described below in conjunction with the accompanying drawings and embodiments and / or optional embodiments.

[0026] Figure 1 The diagram illustrates a stability fault analysis method according to one aspect of the present invention, applied to an Android device, wherein one embodiment of the method includes: S101 retrieves several log files from the raw log data; S102 scans each log file to identify whether there is content that matches one or more fault type identification fingerprints in the preset fault type identification fingerprint database. If there is, it is determined that the Android device has one or more fault types of stability faults, and the first anchor point data corresponding to the stability fault of each fault type in the log file is determined. The first anchor point data of all log files is summarized by fault type to obtain the second anchor point data corresponding to the stability fault of each fault type. The fault type identification fingerprint corresponds one-to-one with the fault type. The fault type includes at least: Crash, ANR and Watchdog / SWT. S103 extracts the characteristic index data corresponding to the stability fault of each fault type from the second anchor point data corresponding to the stability fault of each fault type based on the preset characteristic index fingerprint library, and analyzes the characteristic index data corresponding to the stability fault of each fault type using the analysis method corresponding to the fault type.

[0027] This invention provides a stability fault analysis method applied to device 100. Device 100 establishes a connection with Android device 200 via USB or WiFi. Device 100 can communicate with Android device 200 using ADB (Android Debug Bridge) tools or dedicated diagnostic tools. Device 100 includes, but is not limited to, personal computers, laptops, industrial computers, embedded computers, and servers. Android device 200 can be a mobile smart terminal, wearable device, smart vehicle system, smart home device, etc., based on the Android platform. This is merely an example; other existing or future devices and / or resource platforms suitable for this invention should also be included within the scope of protection of this invention.

[0028] During the debugging or use of Android device 200, Android device 200 generates a lot of raw log data related to the running status of various levels of the system and applications, and various hardware modules. This raw log data is placed in a compressed comprehensive log dataset (or comprehensive log compressed package). For example, Android device 200 using a Qualcomm main chip (or Qualcomm platform) places the raw log data in QLOG; Android device 200 using a Unisoc main chip (or Unisoc platform) places the raw log data in YLOG; and Android device 200 using a MediaTek main chip (or MediaTek platform) places the raw log data in MTKLOG. In addition, Android device 200 also places the raw log data in a comprehensive log bugreport based on the native Android system mechanism. Compared to QLOG / YLOG / MTKLOG, the log context content in bugreport has been simplified.

[0029] A bug report typically includes: a logcat file that records application and system runtime log information (including printouts from the Java and Native layers) sorted by time; a dumpstate file that records snapshots of device hardware / process / memory states; a kernellog file that records Linux kernel logs; traces files that record thread stacks during ANRs; a tombstone file that records Native crash logs; and dropbox files that structure system-level exception events, among others.

[0030] In this embodiment, in step S101, device 100 can obtain raw log data, including several log files, from Android device 200 via ADB tools or dedicated diagnostic tools, using a USB or WiFi connection. Preferably, it obtains QLOG (if Android device 200 uses a Qualcomm main chip), YLOG (if Android device 200 uses a Unisoc main chip), or MTKLOG (if Android device 200 uses a MediaTek main chip). It can also obtain bugreport. After obtaining the raw log data, it can be parsed to obtain each log file.

[0031] If debugging Android device 200 is required, device 100 can stream the raw log data of Android device 200 to perform stability fault analysis in real time. Compared with batch acquisition of log data and analysis, this can improve the timeliness and efficiency of stability fault analysis.

[0032] Continuing in this embodiment, after obtaining each log file, in step S102, device 100 can scan each log file one by one. For each log file, it identifies whether there is content that matches one or more fault type identification fingerprints in a preset fault type identification fingerprint library. If a log file contains content that matches one or more fault type identification fingerprints in the preset fault type identification fingerprint library, it can be determined that the Android device 200 has a stability fault of one or more corresponding fault types. Further, based on the content in the log file that matches one or more fault type identification fingerprints in the preset fault type identification fingerprint library, the first anchor point data corresponding to the stability fault of each fault type in the log file can be determined. After completing the scanning and matching identification of all log files one by one, the first anchor point data of all log files with matching can be summarized according to the fault type to obtain the second anchor point data corresponding to the stability fault of each fault type. Among them, the fault type identification fingerprints in the preset fault type identification fingerprint library correspond one-to-one with the fault types. The fault types related to the stability fault of the Android device include at least: Crash, ANR, and Watchdog / SWT. If the resources of device 100 are sufficient, the scanning of each log file can be performed in parallel using multiple threads to improve processing efficiency.

[0033] Continuing in this embodiment, after obtaining the second anchor point data corresponding to the stability fault of each fault type of the Android device 200, in step S103, the device 100 can process the second anchor point data corresponding to the stability fault of each fault type to extract feature index data. Specifically, the device 100 can extract data matching one or more feature index fingerprints in the preset feature index fingerprint library from the second anchor point data corresponding to the stability fault of each fault type to obtain the feature index data corresponding to the stability fault of that fault type. Further, an analysis method corresponding to the fault type can be used to analyze the feature index data corresponding to the stability fault of that fault type to determine the root cause of the stability fault of the Android device 200 for that fault type.

[0034] The fault type identification fingerprint database in step S102 includes several pre-built fault type identification fingerprints. Optionally, the construction of the fault type identification fingerprints in the fault type identification fingerprint database includes: Based on the fault type, several historical log files, including stability fault data, are classified and labeled to obtain a sample dataset corresponding to each fault type. For each fault type, feature data representing the fault type is extracted from each sample dataset. The feature data of all fault types are summarized to determine the first regular expression corresponding to the fault type. The first regular expression is then associated with the fault category identifier, applicable log file type, priority, and named capture field to obtain the fault type identification fingerprint corresponding to the fault type. The feature data includes at least text fragments, time format, process / thread identifier format, and performance parameter fields.

[0035] In this optional embodiment, several historical log files containing stability failure data for each failure type can be categorized and labeled according to each failure type, such as Crash, ANR, or Watchdog / SWT, to obtain a sample dataset corresponding to each failure type. Then, for each sample dataset corresponding to a failure type, feature data characterizing that failure type is extracted from each sample data. The feature data characterizing the failure type extracted from each sample data includes at least text fragments, time formats, process identifier formats, thread identifier formats, and performance parameter fields. The text fragments in all the extracted feature data characterizing the failure type are then summarized. Based on the summarization result, a first regular expression corresponding to the failure type can be determined, and it is associated with the corresponding failure type identifier, applicable log file type, priority, and named capture field to obtain the failure type identification fingerprint. During matching scans, the associated configured failure type identifier, named capture field, etc., can be used as an index to improve readability, maintainability, and semantic clarity. When the same log content matches multiple fault type identification fingerprints simultaneously, the configured priority can be used to determine which fault type identification fingerprint is used as the final matching scan result. Alternatively, when similar text fragments exist in different log files, the matching order can be controlled and conflicts resolved by combining the configured applicable log file types and priorities. This can reduce false or duplicate identifications and improve the accuracy and stability of fault type identification. All fault type identification fingerprints corresponding to all fault types are compiled into a fault type identification fingerprint database.

[0036] An example, the first regular expression corresponding to the fault type identification fingerprint of fault type "Crash" can be represented as follows: FATAL EXCEPTION:\s*(?P<thread_name> .+), or, signal\s+(?P<signal_num> \d+)\s+\((?P<signal_name> [^)]+)\); The first regular expression corresponding to the fault type identification fingerprint of ANR can be represented as follows: Input dispatching timed out, or, am_anr; The first regular expression corresponding to the fingerprint for fault type identification of Watchdog / SWT can be represented as follows: system_server not responding, or Blocked in handler, or, Watchdog.

[0037] The feature index fingerprint library in step S103 includes several pre-built feature index fingerprints corresponding to fault types. Optionally, the feature index fingerprint library includes at least: Fingerprint extraction methods include timestamp-based fingerprint extraction, process / thread identifier-based fingerprint extraction, and performance parameter-based fingerprint extraction. The time format data in the feature data of all different fault types are summarized, and a second regular expression is determined as the timestamp for fingerprint extraction. The process / thread identifier format data in the feature data of all different fault types are summarized, and a third regular expression is determined as the fingerprint for extracting process / thread identifiers. The same performance parameter field data in the feature data of all different fault types are summarized, and a fourth regular expression is determined as the performance parameter extraction fingerprint of the performance parameter.

[0038] In this optional embodiment, for all sample data including different fault types, the time format data in the feature data of all different fault types can be summarized. Based on the summarization result, a second regular expression can be determined as a timestamp fingerprint extraction. The process identifier format or thread identifier format data in the feature data of all different fault types can be summarized. Based on the summarization result, a third regular expression can be determined as a process or thread identifier fingerprint extraction. The data of the same performance parameter field in the feature data of all different fault types can be summarized. Based on the summarization result, a fourth regular expression corresponding to that performance parameter can be determined as a performance parameter fingerprint extraction. By traversing each performance parameter field in the feature data of all different fault types, the performance parameter fingerprint extraction corresponding to each performance parameter can be obtained. The obtained timestamp fingerprint extraction, process identifier fingerprint extraction, thread identifier fingerprint extraction, and performance parameter fingerprint extraction for each performance parameter are combined to form a feature indicator fingerprint library. The performance parameters may include: rendering performance, lock contention enhancement performance, CPU parameters, load parameters, frame drop parameters, memory parameters, timeout parameters, etc.

[0039] An example, the second regular expression for extracting fingerprints from timestamps can be represented as follows: (?P <ts>\d{2}-\d{2}\s+\d{2}:\d{2}:\d{2}\.\d{3}); The third regular expression for extracting the fingerprint from the process identifier can be represented as follows: pid[:= ](?P <pid>\d+), The third regular expression for extracting the fingerprint from the thread identifier can be represented as follows: tid[:= ](?P <tid>\d+); The fourth regular expression for extracting fingerprints from rendering performance parameters can be represented as follows: Skipped\s+(?P<skip_frames> \d+)\s+frames, The fourth regular expression for fingerprint extraction to enhance lock contention performance can be represented as follows: waiting to lock<(?P<lock_addr> 0x[0-9a-fA-F]+)>, and, held by thread\s+(?P<owner_tid> \d+), The fourth regular expression for extracting fingerprints from CPU parameters can be represented as follows: CPU usage from (?P <start>.+) to (?P <end>.+), The fourth regular expression for extracting fingerprints from load parameters can be represented as follows: Load:\s+(?P <load1>\d+\.\d+)\s+ / \s+(?P <load5>\d+\.\d+)\s+ / \s+(?P <load15>\d+\.\d+), The fourth regular expression for extracting fingerprints from frame drop parameters can be represented as follows: Skipped\s+(?P <frames>\d+)\s+frames, The fourth regular expression for extracting fingerprints from memory parameters can be represented as follows: PSS:\s*(?P <pss>\d+), The fourth regular expression for extracting the fingerprint using the timeout parameter can be represented as follows: Timed out after (?P<wait_time> \d+)ms.

[0040] If, after scanning all log files one by one in step S102, a log file contains content matching the Crash fault type identification fingerprint, then device 100 can determine the first anchor point data corresponding to the stability fault type Crash in each relevant log file, and summarize the first anchor point data corresponding to the stability fault type Crash in all relevant log files to obtain the second anchor point data corresponding to the stability fault type Crash. In step S103, based on a preset feature index fingerprint database, the corresponding feature index data for the stability fault type Crash is extracted from the second anchor point data. Optionally, if the fault type includes Crash, in step S103, the feature index data includes at least: Faulty process, abnormal thread, exception type, Java stack trace, and native backtrace; The step of employing an analysis method corresponding to the fault type to analyze the characteristic index data corresponding to the stability fault of each fault type includes: The determined characteristic index data is input into the Crash analysis algorithm, which outputs several possible root causes of the Crash stability failure and their confidence levels, and the possible root cause with the highest confidence level is determined as the root cause of the Crash stability failure.

[0041] In this optional embodiment, if the determined fault type of the Android device 200 includes Crash, then in step S103, the device 100 can filter the context from the second anchor point data corresponding to the Crash fault type based on a preset feature indicator fingerprint library, and then extract the feature indicator data related to the Crash fault type, including at least: fault process, abnormal thread, abnormal type or signal number, Java stack, and Native backtrace, etc., which can be used for subsequent root cause analysis of the Crash fault type. To further improve the accuracy and completeness of the subsequent analysis, the extracted feature indicator data may also include: signal number, Native stack, foreground and background states, CPU / rendering context data and signal information of the first preset time window before the fault. In step S103, the extracted feature indicator data is input into the Crash analysis algorithm, which outputs several possible root causes of the stability fault of the Crash fault type of the Android device 200 and the confidence level of each possible root cause, and determines the possible root cause with the highest confidence level as the root cause of the stability fault of the Crash fault type of the Android device 200.

[0042] If, after scanning all log files one by one in step S102, a log file contains content matching the ANR fault type identification fingerprint, then device 100 can determine the first anchor point data corresponding to the stability fault being an ANR fault type in each relevant log file, and summarize the first anchor point data corresponding to the stability fault being an ANR fault type in all relevant log files to obtain the second anchor point data corresponding to the stability fault being an ANR fault type. In step S103, based on a preset feature index fingerprint database, the corresponding feature index data for the stability fault being an ANR fault type is extracted from the second anchor point data. Optionally, if the fault type includes ANR, in step S103, the feature index data includes at least: CPU load for main thread response timeout, rendering metrics, and preset failure time window; The step of employing an analysis method corresponding to the fault type to analyze the characteristic index data corresponding to the stability fault of each fault type includes: The feature index data is vectorized to obtain a feature index data vector, and the feature index data vector is input into the ANR root cause analysis model to output several possible root causes of the stability failure of the ANR and their confidence levels. The possible root cause with the highest confidence level is determined as the root cause of the stability failure of the ANR.

[0043] In this optional embodiment, if the determined fault type of the Android device 200 includes ANR, then in step S103, the device 100 can filter out the context from the second anchor point data corresponding to the stability fault type ANR according to the preset feature index fingerprint library, and then extract the feature index data related to the ANR fault type, including at least: core feature index data such as main thread response timeout, rendering index, and CPU load in the second preset fault time window, which can be used for subsequent stability fault root cause analysis of the ANR fault type. The main thread response timeout can be obtained from the filtered context, such as Input dispatching timed out and CheckTime, usually in milliseconds. Rendering metrics can be determined based on extracted Skipped frames, OpenGLRenderer slow frames, Choreographer dropped frames, and other data to quantify the UI thread or rendering pressure. Based on a preset time window before the failure (e.g., 5 seconds before the failure, specifically set according to historical labeled samples, the performance level of 200 Android devices, or stress test results), CPU load includes at least the overall system CPU utilization, the average CPU set utilization of the top-app where the failed process is located, and the average utilization of large / small cores. It may also include single-core peak utilization, iowait ratio, runqueue length, and other data. In step S103, the extracted feature metric data is vectorized, including first performing dimensionless and normalized processing on each feature metric data, and then vectorizing it to form a feature metric data vector. Then, the obtained feature index data vector is input into the ANR root cause analysis model, which outputs several possible root causes of stability failure of ANR failure type of Android device 200 and the confidence level of each possible root cause, and the possible root cause with the highest confidence level is determined as the stability failure root cause of ANR failure type of Android device 200.

[0044] Optionally, if the root cause of the ANR stability failure includes lock contention, a graph-based deadlock detection process is also triggered to further determine the root cause.

[0045] In this optional embodiment, in step S103, if the root cause of the stability failure of the ANR fault type of the Android device 200 includes lock contention, the device 100 may also trigger a graph-based deadlock detection process to further determine the root cause. The graph-based deadlock detection process may include: 1. Node Generation. First, locate the suspected lock contention timestamp corresponding to the ANR fault type in the second anchor point data, and then extract the full Trace file corresponding to the timestamp; then map each thread in the full Trace file to a graph node N in the directed graph, and establish a mapping table between thread Tid, thread name, process group, thread group and graph node N.

[0046] 2. Thread Filtering. Scan all threads in the extracted full trace file and determine the state of each thread. If it is in the Blocked or Waiting state, extract the thread Tid, thread name, waiting lock ID, and lock holder ID; otherwise, ignore the thread or set its corresponding graph node to a dependency-free graph node.

[0047] 3. Edge Mapping. Parse the lock dependency information (such as "waiting to lock<address>", "held by thread...", etc.) in the full Trace file. (One thread can correspond to one or more lock addresses to be acquired.) Based on the parsing results, if a thread T1 is waiting for lock L, and lock L is currently held by thread T2, then a directed edge E is established from graph node N1 (corresponding to thread T1) to graph node N2 (corresponding to thread T2), indicating that T1 depends on T2 to release the lock. If multiple lock dependencies exist, multiple directed edges are established. The lock addresses, lock holders, and lock dependencies mentioned above can all be obtained directly from the thread stack and lock description fields in the full Trace file.

[0048] 4. Cycle Detection. Check if there are cycles in the directed graph. If a cycle exists, the root cause of the ANR failure type for Android device 200 can be determined to be "logical deadlock," and the deadlock topology result can be output. The output deadlock topology result can at least include: thread Tid, thread name, lock address, and lock dependencies between threads. If the relevant log data also contains the file name and line number of the stack frame, the corresponding source code line number can also be output; if the relevant log data does not directly contain it, symbolic parsing can be performed based on function symbols, shared library identifiers, and address offsets to obtain the corresponding method or function location information. If no cycle is found, it can be further determined whether the blocking chain points to the Native critical thread. If the blocking chain points to the Native critical thread, the root cause of the ANR failure type for Android device 200 can be determined to be "system component suspension." If the blocking chain does not point to the Native critical thread, the root cause of the ANR failure type for Android device 200 can be determined to be "suspected main thread heavy load or rendering blocking," or the root cause of the ANR failure type for Android device 200 can be maintained, i.e., lock contention.

[0049] The Depth-First Search (DFS) algorithm is the preferred choice for checking for cycles in the directed graph. Other algorithms such as Tarjan's algorithm, topology elimination algorithm, Kosaraju's algorithm, or Johnson's cycle detection algorithm can also be used.

[0050] If, after scanning all log files in step S102, a log file contains content matching the Watchdog / SWT fault type identification fingerprint, then device 100 can determine the first anchor point data corresponding to the Watchdog / SWT stability fault type in each relevant log file. The device then summarizes the first anchor point data corresponding to the Watchdog / SWT stability fault type in all relevant log files to obtain the second anchor point data corresponding to the Watchdog / SWT stability fault type. In step S103, based on a preset feature index fingerprint database, the corresponding feature index data for the Watchdog / SWT stability fault type is extracted from the second anchor point data, and analyzed using a method corresponding to the Watchdog / SWT fault type. Stability failures are typically Watchdog / SWT failures, and the root cause is likely a suspected lock contention deadlock. A deadlock detection process can be used to analyze the corresponding characteristic data: First, locate the trigger point, then extract the corresponding full trace according to the preset window size, and then scan all threads to determine if there are any threads in the Blocked or Waiting state. If so, extract the thread's Tid, waiting lock ID, and lock holder ID, etc., and use the graph theory-based deadlock detection process described above to determine whether the root cause of the stability failure is a deadlock.

[0051] Optionally, the fault type identification fingerprint is iteratively updated based on the newly added log file.

[0052] In this optional embodiment, newly acquired log files can also be used as historical log data, labeled according to their corresponding fault types, and used as new sample data to update the sample dataset and iteratively update the fault type fingerprint to further improve the accuracy of fault type identification.

[0053] Optionally, in step S102, determining the first anchor point data corresponding to the stability fault of each fault type in the log file includes: Record the log line number and timestamp that match the identification fingerprint of each fault type in the log file, and determine the corresponding context log data based on a preset window threshold. The context log data includes at least one of the following parameter fields: process / thread identifier, process / thread name, lock address or transaction identifier. The identification information of the log file, the timestamp, and the context log data are used as the first anchor point data corresponding to the stability fault of the fault type in the log file.

[0054] In this optional embodiment, in step S102, when scanning a log file and identifying content in the log file that matches one or more fault type identification fingerprints in a preset fault type identification fingerprint database, the first anchor point data corresponding to the stability fault of each fault type in the log file is determined. Specifically, firstly, the log line number and timestamp that match the first regular expression in each fault type identification fingerprint in the log file are recorded, and the corresponding context log data is determined based on a preset window threshold (e.g., 50 lines above and below the log line number, or 5 seconds before and after the timestamp). The context log data should include at least one of the following parameter fields: process identifier, thread identifier, process name, thread name, lock address, or transaction identifier. After determining the root cause of the stability fault of the fault type, the relevant parameter fields can be further used as location information, thereby improving the efficiency of repairing the relevant stability fault. Secondly, the identification information, recorded timestamps, and determined context log data of the log file are used as the first anchor point data corresponding to the stability fault of the aforementioned fault type in the log file. The identification information of the log file is used to characterize the source of the first anchor point data and can be any one or a combination of the log file's filename, relative path, absolute path, entry path within the archive package, or other identification information capable of distinguishing the source of the first anchor point data. For example, if the log file trace.txt contains content that matches the ANR fault type identification fingerprint in the preset fault type identification fingerprint database, then the identification information of the log file in the first anchor point data corresponding to the stability fault of the determined ANR can be traces.txt, / data / anr / traces.txt, or bugreport-001 / FS / data / anr / traces.txt (indicating it originates from bugreport).

[0055] Optionally, in step S102, the first anchor data of all log files is summarized according to the fault type to obtain the second anchor data corresponding to the stability fault of each fault type, including: Based on timestamps and fault types, align the first anchor point data corresponding to stability faults of the same fault type across all log files; By concatenating the first anchor data corresponding to the stability fault of the fault type in each log file after aligning the parameter fields with the same parameters, the second anchor data corresponding to the stability fault of the fault type is obtained.

[0056] In this optional embodiment, in step S102, all log files containing first anchor data corresponding to stability faults of a certain fault type (some log files may contain multiple first anchor data corresponding to stability faults of different fault types) are processed. Specifically, firstly, based on the fault type corresponding to the first anchor data and the timestamp therein, the first anchor data corresponding to the same fault type of stability faults in all log files are aligned in chronological order. Secondly, for all the aligned first anchor data corresponding to the same fault type of stability faults, all first anchor data with the same parameter fields are concatenated to obtain the second anchor data corresponding to the stability fault of that fault type. The parameter fields may include multiple ones (e.g., the aforementioned process identifier, thread identifier, process name, thread name, lock address, or transaction identifier, etc.). For each parameter field, all the first anchor data corresponding to the same fault type of stability faults with the same parameter fields are concatenated, and then the concatenated data corresponding to each parameter field are used together as the second anchor data corresponding to the stability fault of that fault type.

[0057] Optionally, this stability failure analysis method further includes: S104 summarizes the analysis results of stability faults for each fault type and outputs an analysis report.

[0058] In this optional embodiment, the device 100, through step S103, uses an analysis method corresponding to the fault type to analyze the characteristic index data corresponding to the stability fault of each fault type. After obtaining the analysis results of the stability fault of each fault type, in step S104, the device 100 can also summarize the analysis results of the stability fault of each fault type to form an analysis report. The analysis report can be output to guide the debugging of the device 100 or to perform further data analysis or other purposes.

[0059] The specific values ​​shown in the examples of the above embodiments and / or optional embodiments of the present invention are only examples. The actual values ​​can be set according to the actual application scenario and the hardware resources of the device 100.

[0060] Through the above embodiments and / or optional embodiments of the present invention, the device 100, based on a preset fault type identification fingerprint database, uniformly performs fault type identification fingerprint matching scans on different log files in the acquired raw log data to determine anchor point data corresponding to the stability fault of the fault type. Then, feature index data is extracted from the anchor point data, and stability analysis is performed using the analysis method corresponding to the fault type to obtain the analysis results. This can greatly improve the retrieval and association efficiency of raw log data, as well as improve the accuracy of association and analysis of fault data in different log data corresponding to the same fault type. For the root cause of stability faults of some fault types, more accurate location information can be further clarified, which can help improve the efficiency of subsequent debugging and repair of stability faults of related fault types.

[0061] Figure 2 A stability failure analysis apparatus according to another aspect of the present invention is shown, wherein, in one embodiment, the apparatus comprises: The first module 210 is used to obtain several log files from the raw log data of the Android device; The second module 220 is used to scan each log file to identify whether there is content that matches one or more fault type identification fingerprints in the preset fault type identification fingerprint database. If there is, it is determined that the Android device has one or more fault types of stability faults, and the first anchor point data corresponding to the stability fault of each fault type in the log file is determined. The first anchor point data of all log files is summarized by fault type to obtain the second anchor point data corresponding to the stability fault of each fault type. The fault type identification fingerprint corresponds one-to-one with the fault type. The fault type includes at least: Crash, ANR and Watchdog / SWT. The third module 230 is used to extract the characteristic index data corresponding to the stability fault of each fault type from the second anchor point data corresponding to the stability fault of each fault type based on the preset characteristic index fingerprint library, and to analyze the characteristic index data corresponding to the stability fault of each fault type using the analysis method corresponding to the fault type.

[0062] In this embodiment, the device is deployed within a device whose hardware and software environment is identical to that of the aforementioned device 100. Device 100 can connect to Android device 200 via USB or WiFi.

[0063] In this embodiment of the device, the first module 210 of the device can obtain raw log data including several log files from the Android device 200 for stability fault analysis of the Android device.

[0064] Continuing with this device embodiment, the second module 220 of the device can scan each log file one by one. For each log file, it identifies whether there is content that matches one or more fault type identification fingerprints in a preset fault type identification fingerprint database. If a log file contains content that matches one or more fault type identification fingerprints in the preset fault type identification fingerprint database, it can be determined that the Android device 200 has a stability fault of one or more corresponding fault types. Further, based on the content in the log file that matches one or more fault type identification fingerprints in the preset fault type identification fingerprint database, the first anchor point data corresponding to the stability fault of each fault type in the log file can be determined. After completing the scanning and matching identification of all log files one by one, the first anchor point data of all matching log files can be summarized according to the fault type to obtain the second anchor point data corresponding to the stability fault of each fault type. The fault type identification fingerprints in the preset fault type identification fingerprint database correspond one-to-one with the fault types. The fault types related to the stability fault of the Android device include at least: Crash, ANR, and Watchdog / SWT. If the resources of the device 100 are sufficient, the second module 220 can use multi-threading to perform parallel scanning of each log file to improve processing efficiency.

[0065] Continuing with this device embodiment, the third module 230 of the device can process the second anchor point data corresponding to the stability fault of each fault type, and extract feature index data from it. Specifically, according to a preset feature index fingerprint library, data matching one or more feature index fingerprints in the preset feature index fingerprint library can be extracted from the second anchor point data corresponding to the stability fault of each fault type to obtain the feature index data corresponding to the stability fault of that fault type. Further, an analysis method corresponding to the fault type can be used to analyze the feature index data corresponding to the stability fault of that fault type to determine the root cause of the stability fault of the Android device 200 for that fault type.

[0066] Optionally, the stability fault analysis device further includes: The fourth module, 240, is used to summarize the analysis results of stability faults for each fault type and output an analysis report.

[0067] The device 100 uses the third module 230 to analyze the characteristic index data corresponding to the stability fault of each fault type using the analysis method corresponding to the fault type. After obtaining the analysis results of the stability fault of each fault type, in this optional device embodiment, the fourth module 240 of the device can also summarize the analysis results of the stability fault of each fault type to form an analysis report. The analysis report can be output to guide the debugging of the device 100 or to perform further data analysis or other purposes.

[0068] In the above-described device embodiments, the various components of the device can achieve the same functions as those not mentioned in the aforementioned related method embodiments and / or optional embodiments, and will not be repeated here.

[0069] According to another aspect of the present invention, a computer-readable medium is also provided, the computer-readable medium storing computer-readable instructions that can be executed by a processor to implement the foregoing method embodiments and / or optional embodiments, or to implement some or all of the foregoing method embodiments and / or optional embodiments.

[0070] It should be noted that the method embodiments and / or optional embodiments in this invention do not strictly limit the order of execution of each step, as long as the method embodiments and / or optional embodiments can solve the defects existing in the prior art, achieve the inventive purpose of this invention, and obtain beneficial effects. The method embodiments and / or optional embodiments in this invention can be implemented in software and / or combinations of software and hardware. The software program involved in this invention can be executed by a processor to implement the steps or functions of the above embodiments. Similarly, the software program of this invention (including related data structures) can be stored in a computer-readable recording medium.

[0071] Furthermore, part or all of the present invention can be applied as a computer program product, such as computer program instructions, which, when executed by a computer, can invoke or provide the methods and / or technical solutions according to the present invention through the operation of the computer. The program instructions invoking the methods of the present invention may be stored in a fixed or removable recording medium, and / or transmitted via a data stream in a broadcast or other signal carrying medium, and / or stored in the working memory of a computer device operating according to the program instructions.

[0072] According to another aspect of the present invention, an apparatus is also provided, the apparatus comprising: a memory for storing computer program instructions and a processor for executing the program instructions, wherein when the computer program instructions are executed by the processor, the apparatus is triggered to run the methods and / or technical solutions of the foregoing embodiments, or the apparatus is triggered to run part or all of the methods and / or technical solutions of the foregoing embodiments.

[0073] It will be apparent to those skilled in the art that the present invention is not limited to the details of the exemplary embodiments described above, and that the invention can be implemented in other specific forms without departing from its spirit or essential characteristics. Therefore, the embodiments should be considered in all respects as exemplary and non-limiting, and the scope of the invention is defined by the appended claims rather than the foregoing description. Thus, all variations falling within the meaning and scope of equivalents of the claims are intended to be embraced within the present invention. No reference numerals in the claims should be construed as limiting the scope of the claims.

[0074] In this invention, when terms such as "upper," "lower," "left," "right," "front," "rear," "top," "bottom," "inner," "outer," "middle," "vertical," "horizontal," "lateral," and "longitudinal" are used, the indicated orientation and / or positional relationship is based on the orientation and / or positional relationship shown in the accompanying drawings. These terms are primarily for the purpose of better describing this invention and its embodiments, and are not intended to limit the indicated device, element, or component to having a specific orientation, or to be constructed and operated in a specific orientation. Furthermore, some of the above terms, in addition to indicating orientation or positional relationship, can also be used to indicate other meanings; for example, the term "upper" can also be used in some cases to indicate a certain dependency or connection relationship. Those skilled in the art can understand the specific meaning of these terms in this invention according to the specific circumstances. Furthermore, the terms "installation," "setting," "equipped with," "connection," and "linking" should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral structure; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection via an intermediate medium; and they can refer to an internal connection between two devices, elements, or components. Those skilled in the art can understand the specific meaning of these terms in this invention based on the specific circumstances.

[0075] Furthermore, the terms "first," "second," etc., are primarily used to distinguish different devices, units, modules, elements, circuits, or components (which may be the same or different in specific type and construction), and are not intended to indicate or imply the relative importance, order, and / or quantity of the indicated devices, units, modules, elements, circuits, or components. Unless otherwise stated, "a plurality of" means two or more.

[0076] Furthermore, it is clear that the word "comprising" does not exclude other units or steps, and the singular does not exclude the plural. Multiple units or devices recited in the device claims may also be implemented by a single unit or device through software and / or hardware.< / pss> < / frames> < / end> < / start> < / tid> < / pid> < / ts>

Claims

1. A stability fault analysis method characterized by, The method includes: Retrieve several log files from the raw log data of an Android device; Each log file is scanned to identify whether there is content that matches one or more fault type identification fingerprints in the preset fault type identification fingerprint database. If so, it is determined that the Android device has one or more fault types of stability faults, and the first anchor point data corresponding to the stability fault of each fault type in the log file is determined. The first anchor point data of all log files are summarized by fault type to obtain the second anchor point data corresponding to the stability fault of each fault type. The fault type identification fingerprint corresponds one-to-one with the fault type, and the fault type includes at least: Crash, ANR, and Watchdog / SWT. Based on a preset feature index fingerprint database, feature index data corresponding to the stability fault of each fault type is extracted from the second anchor point data corresponding to the stability fault of each fault type, and the feature index data corresponding to the stability fault of each fault type is analyzed using the analysis method corresponding to the fault type.

2. The method of claim 1, wherein, The construction of a fault type identification fingerprint includes: Based on the fault type, several historical log files, including stability fault data, are classified and labeled to obtain a sample dataset corresponding to each fault type. For each fault type, feature data representing the fault type is extracted from each sample dataset. The feature data of all fault types are summarized to determine the first regular expression corresponding to the fault type. The first regular expression is then associated with the fault category identifier, applicable log file type, priority, and named capture field to obtain the fault type identification fingerprint corresponding to the fault type. The feature data includes at least text fragments, time format, process / thread identifier format, and performance parameter fields.

3. The method of claim 2, wherein, The preset feature index fingerprint database includes at least: Fingerprint extraction methods include timestamp-based fingerprint extraction, process / thread identifier-based fingerprint extraction, and performance parameter-based fingerprint extraction. The time format data in the feature data of all different fault types are summarized, and a second regular expression is determined as the timestamp for fingerprint extraction. The process / thread identifier format data in the feature data of all different fault types are summarized, and a third regular expression is determined as the fingerprint for extracting process / thread identifiers. The same performance parameter field data in the feature data of all different fault types are summarized, and a fourth regular expression is determined as the performance parameter extraction fingerprint of the performance parameter.

4. The method of claim 3, wherein, If the fault type includes Crash, the characteristic indicator data shall include at least: Faulty process, abnormal thread, exception type, Java stack trace, and native backtrace; The step of employing an analysis method corresponding to the fault type to analyze the characteristic index data corresponding to the stability fault of each fault type includes: The determined characteristic index data is input into the Crash analysis algorithm, which outputs several possible root causes of the Crash stability failure and their confidence levels, and the possible root cause with the highest confidence level is determined as the root cause of the Crash stability failure.

5. The method of claim 3, wherein, If the fault type includes ANR, the characteristic indicator data shall include at least: CPU load for main thread response timeout, rendering metrics, and preset failure time window; The step of employing an analysis method corresponding to the fault type to analyze the characteristic index data corresponding to the stability fault of each fault type includes: The feature index data is vectorized to obtain a feature index data vector, and the feature index data vector is input into the ANR root cause analysis model to output several possible root causes of the stability failure of the ANR and their confidence levels. The possible root cause with the highest confidence level is determined as the root cause of the stability failure of the ANR.

6. The method of claim 5, wherein, If the root cause of the stability failure of the ANR includes lock contention, a graph theory-based deadlock detection process is also triggered to further determine the root cause.

7. The method according to claim 2, characterized in that, Based on the newly added log files, the fault type identification fingerprint is iteratively updated.

8. The method according to claim 1, characterized in that, The step of determining the first anchor point data corresponding to the stability fault for each fault type in the log file includes: Record the log line number and timestamp that match the identification fingerprint of each fault type in the log file, and determine the corresponding context log data based on a preset window threshold. The context log data includes at least one of the following parameter fields: process / thread identifier, process / thread name, lock address or transaction identifier. The identification information of the log file, the timestamp, and the context log data are used as the first anchor point data corresponding to the stability fault of the fault type in the log file.

9. The method according to claim 8, characterized in that, The first anchor point data of all log files is summarized according to fault type to obtain the second anchor point data corresponding to the stability fault of each fault type, including: Based on timestamps and fault types, align the first anchor point data corresponding to stability faults of the same fault type across all log files; By concatenating the first anchor data corresponding to the stability fault of the fault type in each log file after aligning the parameter fields with the same parameters, the second anchor data corresponding to the stability fault of the fault type is obtained.

10. The method according to claim 1, characterized in that, The method further includes: Summarize the analysis results of stability failures for each failure type and output an analysis report.

11. A stability fault detection device, characterized in that, Deployed on an Android device, the device includes: The first module is used to obtain several log files from the raw log data of the Android device; The second module is used to scan each log file to identify whether there is content that matches one or more fault type identification fingerprints in the preset fault type identification fingerprint database. If there is, it is determined that the Android device has one or more fault types of stability faults, and the first anchor point data corresponding to the stability fault of each fault type in the log file is determined. The first anchor point data of all log files is summarized by fault type to obtain the second anchor point data corresponding to the stability fault of each fault type. The fault type identification fingerprint corresponds one-to-one with the fault type. The fault types include at least: Crash, ANR and Watchdog / SWT. The third module is used to extract the characteristic index data corresponding to the stability fault of each fault type from the second anchor point data corresponding to the stability fault of each fault type based on the preset characteristic index fingerprint library, and to analyze the characteristic index data corresponding to the stability fault of each fault type using the analysis method corresponding to the fault type.

12. The apparatus according to claim 11, characterized in that, The device further includes: The fourth module is used to summarize the analysis results of stability failures for each type of failure and output an analysis report.

13. A computer-readable medium, characterized in that, It stores computer-readable instructions that are executed by a processor to implement the method as described in any one of claims 1 to 10.

14. A device, characterized in that, The device includes: One or more processors; and A memory storing computer-readable instructions, which, when executed, cause the one or more processors to perform the method as described in any one of claims 1 to 10.

Images