Abnormality processing method, electronic equipment, storage medium, product and vehicle

Abstract

The invention relates to an exception handling method, electronic equipment, a storage medium, a product and a vehicle, and the method comprises the steps: responding to a monitored exception event of an application program, and detecting whether a target daemon thread of a terminal triggers a restart operation or not, so as to determine the type of the exception event; and determining abnormal information corresponding to the abnormal event according to a strategy corresponding to the type of the abnormal event. The method can improve the processing efficiency of the abnormal event in the operating system.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and in particular to an anomaly handling method, electronic device, storage medium, product, and vehicle. Background Technology

[0002] Currently, most smart terminals are equipped with an operating system. However, when smart terminals run applications on an operating system, abnormalities such as malfunctions may occur. In related technologies, when an application encounters an abnormality, key information about the time of the abnormality cannot be presented to the user or maintenance personnel, making it difficult to trace the problem and reducing development and maintenance efficiency. Summary of the Invention

[0003] This application provides an exception handling method, electronic device, storage medium, product, and vehicle to solve the above-mentioned problems.

[0004] To achieve the above objectives, according to a first aspect of this application, an exception handling method is provided, which is applied to a terminal, the method comprising:

[0005] In response to an abnormal event detected by the application, the system detects whether the target daemon thread of the terminal has triggered a restart operation to determine the type of the abnormal event.

[0006] The abnormal information corresponding to the abnormal event is determined using a strategy that corresponds to the type of the abnormal event.

[0007] Optionally, detecting whether the target daemon thread of the terminal triggers a restart operation to determine the type of the abnormal event includes:

[0008] If no restart operation is detected by the target daemon thread of the terminal, the type of the abnormal event is determined to be the first type, which is used to indicate an application abnormality;

[0009] When the target daemon thread of the terminal is detected to have triggered a restart operation, the type of the abnormal event is determined to be the second type, which is used to indicate an abnormality in the system program.

[0010] Optionally, the anomaly information includes anomaly record information and attribution information. The anomaly record information is used to record the context information when the anomaly event occurs, and the attribution information is used to indicate the attribution object of the anomaly event.

[0011] The step of determining the abnormal information corresponding to the abnormal event using a strategy corresponding to the type of the abnormal event includes:

[0012] Based on the strategy corresponding to the type of the abnormal event, the abnormal record information corresponding to the abnormal event is determined;

[0013] Based on the anomaly record information, determine the attribution information corresponding to the anomaly event.

[0014] Optionally, determining the exception record information corresponding to the exception event based on the strategy corresponding to the type of the exception event includes:

[0015] If the type of the abnormal event is the first type, the abnormal log file corresponding to the abnormal event of the first type is parsed to obtain the abnormal record information corresponding to the abnormal event of the first type.

[0016] Optionally, determining the exception record information corresponding to the exception event based on the strategy corresponding to the type of the exception event includes:

[0017] After the restart operation, determine whether the target system directory corresponding to the target daemon thread stores the relevant information recorded when the abnormal event occurred:

[0018] If it exists, then based on the recorded relevant information, determine the abnormal record information corresponding to the second type of abnormal event.

[0019] Optionally, the exception log information includes the application's identification information and stack information, and determining the attribution information corresponding to the exception event based on the exception log information includes:

[0020] Based on the identification information and the preset mapping relationship, the associated users associated with the identification information are obtained, so as to determine the attribution information corresponding to the abnormal event;

[0021] The preset mapping relationship is used to indicate the associated users corresponding to each of the multiple preset identifiers.

[0022] Optionally, the method further includes:

[0023] When the prompt function is enabled, the abnormal information is displayed on the corresponding interface of the terminal using a preset assertion method.

[0024] According to a second aspect of this application, embodiments of this application also provide an electronic device, comprising:

[0025] A memory on which computer programs are stored;

[0026] A processor is configured to execute the computer program in the memory to implement the steps of any of the methods provided in the embodiments of this application.

[0027] According to a third aspect of this application, embodiments of this application also provide a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the steps of any of the methods provided in the embodiments of this application.

[0028] According to a fourth aspect of this application, embodiments of this application also provide a computer program product, including a computer program or instructions that, when executed by a processor, implement the steps of any of the methods provided in embodiments of this application.

[0029] According to a fifth aspect of this application, embodiments of this application also provide a vehicle including the aforementioned electronic device, or performing the steps of any of the methods provided in embodiments of this application.

[0030] Some embodiments of this application include at least the following beneficial effects: by identifying and displaying a prompt window for abnormal information, abnormal problems in the application can be effectively located, the accuracy of abnormal problem assignment can be improved, and the problem-solving cycle of abnormal problems in the application can be reduced.

[0031] Other features and advantages of this application will be described in detail in the following detailed description section. Attached Figure Description

[0032] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0033] To gain a more complete understanding of this application and its beneficial effects, the following description will be provided in conjunction with the accompanying drawings, wherein the same reference numerals in the following description denote the same parts.

[0034] Figure 1 This is an application scenario diagram of the exception handling method shown in some embodiments of this application;

[0035] Figure 2 This is an exemplary flowchart of an exception handling method according to some embodiments of this application;

[0036] Figure 3 These are exemplary schematic diagrams of an exception handling system according to some embodiments of this application;

[0037] Figure 4 This is an exemplary schematic diagram of an anomaly monitoring module according to some embodiments of this application;

[0038] Figure 5This is a schematic diagram of the structure of an anomaly display module according to some embodiments of this application;

[0039] Figure 6 This is a schematic diagram of the structure of an electronic device according to some embodiments of this application;

[0040] Figure 7 This is an exemplary schematic diagram of a vehicle according to some embodiments of this application. Detailed Implementation

[0041] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. All other embodiments obtained by those skilled in the art based on the embodiments of this application without creative effort are within the protection scope of this application.

[0042] To facilitate understanding of the implementation schemes provided in this application, the relevant application background of the exception handling method provided in this application will be explained first.

[0043] In related technologies, the notification of abnormal events depends on the normal operation of the operating system. When an abnormal event occurs at the level of core system components, such as a serious crash of a system service process or a critical service blockage causing the system watchdog timeout, the system usually triggers an automatic restart to restore basic functions. This results in the inability to capture key information at the time of the abnormality, making it impossible to present the abnormality to users or maintenance personnel, thus reducing the effectiveness of system maintenance or problem diagnosis.

[0044] In view of this, some embodiments of this application provide an exception handling method that, by analyzing information such as the call stack of the exception process function and the object responsible for the exception, determines the exception information when the exception event occurs and displays the exception information to the user, which can improve the accuracy of problem assignment and reduce the problem resolution cycle.

[0045] Figure 1 This is an application scenario diagram of the exception handling method shown in some embodiments of this application.

[0046] The technical solutions described in some embodiments of this application can be applied to application development and testing, internal version testing, etc.

[0047] The implementing entity of the technical solution in this application embodiment can be an electronic device, which may include an exception handling device. This exception handling device can be implemented in hardware and / or software, and can be configured in any electronic device with network communication capabilities. The electronic device can be a server, a terminal, or other similar device.

[0048] like Figure 1 As shown, the exception handling method provided in this application embodiment can be applied to, for example, Figure 1 The application environment shown depicts a terminal communicating with a server via a network. This terminal can be, but is not limited to, various personal computers, laptops, smartphones, tablets, portable wearable devices, smart voice interaction devices, smart home appliances, in-vehicle terminals, and other vehicle-to-everything (V2X) devices.

[0049] The server can be implemented using a standalone server or a server cluster composed of multiple servers. It is understood that the server provided in this application embodiment can be a standalone physical server, a server cluster composed of multiple physical servers, or a distributed system. It can also be a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, and big data and artificial intelligence platforms. The terminal and server can be connected directly or indirectly through wired or wireless communication methods; this application embodiment does not impose any limitations on this.

[0050] In some embodiments, the application scenario may also include, for example, networks, storage devices, etc. Networks may include any suitable wired or wireless networks that facilitate the exchange of information and / or data. Storage devices are used to store data, instructions, and / or any other information.

[0051] It is important to note that the application scenarios for exception handling methods are provided for illustrative purposes only and are not intended to limit the scope of this specification. Those skilled in the art can make various changes and modifications based on the descriptions in this specification. For example, application scenarios may also include databases, information sources, etc. Furthermore, application scenarios may be implemented on other devices to achieve similar or different functions. However, these changes and modifications will not depart from the scope of this specification.

[0052] Figure 2 This is an exemplary flowchart of an exception handling method according to some embodiments of this application. In some embodiments, process 200 may be executed based on an electronic device. Figure 2 As shown, process 200 includes the following steps.

[0053] Step 210: In response to the detected abnormal event of the application, check whether the target daemon thread of the terminal has triggered a restart operation to determine the type of abnormal event.

[0054] An application is a software entity installed and running on the operating system of a terminal. For example, applications can include, but are not limited to, instant messaging applications, video playback applications, navigation applications, and system-level service programs. For instance, in the Android operating system, each application has a unique package name as its identifier and can create one or more processes at runtime to execute different task modules. For example, an instant messaging application might handle message sending and receiving and UI rendering in its main process, while simultaneously running a push notification service in another process.

[0055] An abnormal event refers to an unexpected interruption event that occurs during the operation of an application on a terminal device. For example, abnormal events may include, but are not limited to, application process crashes, application unresponsiveness caused by main thread blocking, system service timeouts, or memory exceeding limits and being reclaimed by the system.

[0056] In some embodiments, abnormal events can be captured through system-level services. For example, in the Android operating system, a background monitoring service can be configured. This service can listen for file creation events in the ` / data / system / dropbox / abnormal logs` directory using a file observer (FileObserver). When a new log file named with tags such as "data_app_crash" or "data_app_anr" is detected, it is considered an abnormal event. Alternatively, a polling mechanism can be used to periodically scan log entries in the abnormal logs directory. Or, with preset permissions, the abnormal log files reported by `DropBoxManagerService` can be captured to listen for abnormal events. Another example is to monitor the running status of specific system services or critical processes.

[0057] In some embodiments, after an abnormal event is captured, the contents of the new log file can be further parsed to extract abnormal information such as the application package name, process name, process ID, exception type, and occurrence timestamp.

[0058] A target daemon is a pre-configured background monitoring service used to periodically check the running status of a monitored process. For example, a target daemon can be a standalone process, a system service, or a kernel daemon.

[0059] In some embodiments, the target daemon thread may be a system watchdog configured in the system to perform heartbeat detection on critical system services. When no response is received for several consecutive times, it is determined to be a timeout and a restart process is triggered.

[0060] In some embodiments, if a target daemon thread is detected to have triggered a restart operation within a preset time window at the same time as or after an abnormal event is detected, the restart operation can refer to restarting the application that experienced the abnormal event or a critical component of that application, or restarting the entire terminal device. This can be flexibly configured according to actual needs. For example, in the Android operating system, when the running system watchdog detects that a critical system service or critical process remains unresponsive and exceeds a preset tolerance threshold, it calls the system restart interface to terminate the current running state and restart the entire terminal device.

[0061] In some embodiments, when an abnormal event is detected, the target file is retrieved from the terminal's exception log directory, which stores file records of each abnormal event that occurs in the operating system. As an example, this exception log directory could be the Dropbox directory (managed by the DropBoxManagerService service), which can be used to synchronize file data recorded by the operating system each time an abnormal event occurs.

[0062] When an abnormal event is detected by the operating system, the corresponding target file can be found in the terminal's abnormal log directory (such as the dropbox directory mentioned above), and the file name of each target file or the file content of each target file can be identified from these target files.

[0063] It should be noted that since there are many reasons for abnormalities in the terminal's operating system, these reasons can be classified into three types: ANR, CRASH, and SWT.

[0064] It's understandable that, taking the Android operating system as an example, an ANR (Application Not Responding) exception is caused by an application becoming unresponsive. When an ANR exception occurs, a file (such as the ANR_LOG file) in the operating system's dropbox directory records the log content generated by the ANR exception, and the application records the stack trace information of the exception in the file used to record ANR.

[0065] For CRASH, it can be understood that a CRASH exception is caused by an application crash. When a CRASH exception occurs, a log file (such as the CRASH_LOG file) is created in the operating system's dropbox directory to record the contents of the CRASH exception. Additionally, the application records the stack trace of the exception in the file used for logging CRASH.

[0066] For SWT (Service Timeout), it can be understood that an SWT exception is caused by a system service failing to complete its operation within a specified time. When an SWT exception occurs, a log file (such as the SYSTEM_SERVICE_TIMEOUT_LOG file) in the operating system's dropbox directory records the log content of the exception event due to the system service's timeout failure. Furthermore, the system service records the stack trace of this exception event in a file used to record the system service's timeout failure. It can be understood that system service timeout failures are generally related to system service exceptions.

[0067] Among them, stack information is used to record function call information (function execution order) during the execution of a process or thread.

[0068] It should be understood that the types of abnormal events may include more or fewer than those shown above, and this application embodiment does not limit this.

[0069] Based on the above description, taking the Android operating system as an example, when listening for abnormal events in the operating system, the system begins to retrieve target files and their names from the terminal's exception log directory, such as the dropbox directory. For example, all exception log files in the dropbox directory can be retrieved as target files, or newly added exception log files can be retrieved as target files. The system then identifies the names of the retrieved target files and retrieves their contents.

[0070] In some embodiments, the type of exception when an operating system exception occurs can be determined based on the target file.

[0071] It is understandable that when an operating system on a terminal encounters an error, it will record different error log files in the operating system's error log directory (such as Dropbox) depending on the cause and type of the error. In some embodiments, the type of error can be determined by the filename of the target file or the content recorded in the target file.

[0072] As an example, we can first determine whether the target file contains a first file, a second file, or a third file. The first file is used to record log content generated by ANR, the second file is used to record log content generated by CRASH, and the third file is used to record log content generated by SWT. If the target file contains the first file, the exception type when the operating system encounters an abnormal event is determined to be ANR. If the target file contains the second file, the exception type when the operating system encounters an abnormal event is determined to be CRASH. If the target file contains the third file, the exception type when the operating system encounters an abnormal event is determined to be SWT.

[0073] For example, taking the Android operating system as an example, the first file can be ANR_LOG, the second file can be CRASH_LOG, and the third file can be SWT_LOG. That is, it can be determined whether the exception log directory contains a first file (such as the ANR_LOG file) recording log content generated by ANR, a second file (such as the CRASH_LOG file) recording log content generated by CRASH, or a third file (such as the SWT_LOG file) recording log content generated by SWT. If the exception log directory contains the first file, it indicates that the operating system has experienced an ANR exception; if it contains the second file, it indicates that the operating system has experienced a CRASH exception; and if it contains the third file, it indicates that the operating system has experienced an SWT exception.

[0074] Step 220: Determine the exception information corresponding to the exception event using a strategy that corresponds to the type of exception event.

[0075] In some embodiments, corresponding exception information can be generated based on the exception log file corresponding to the exception event.

[0076] In some embodiments, the exception type and the corresponding log content can be filled in according to a preset structure to generate the above-mentioned exception information.

[0077] The exception information may include the type of exception event, such as ANR, CRASH, or SWT, and the corresponding log content for that type of exception event. This preset structure can be understood as the structure of the exception information itself. This structure can be customized according to actual needs. As an example, the structure of the exception information can be defined as follows: {{ANR type, CRASH type, or SWT type, log content corresponding to the exception type}}. For example, the exception information can be obtained by filling in the obtained exception event type and the corresponding log content according to the above structure.

[0078] It is understandable that different types will correspond to different exception log files, and corresponding exception information can be generated based on the type and the log content corresponding to the exception.

[0079] In some embodiments of this application, classifying detected abnormal events and employing different strategies based on their type helps to obtain abnormal information matching the abnormal event, thereby improving the processing efficiency and location of abnormal events.

[0080] In some embodiments, detecting whether the target daemon thread of the terminal triggers a restart operation to determine the type of the abnormal event includes:

[0081] If no restart operation is detected by the target daemon thread of the terminal, the type of the abnormal event is determined to be the first type, which is used to indicate an application abnormality;

[0082] When the target daemon thread of the terminal is detected to have triggered a restart operation, the type of the abnormal event is determined to be the second type, which is used to indicate an abnormality in the system program.

[0083] In some embodiments, the first type may include types such as Application Not Responding (ANR) and Application Crash (CRASH). For example, if no restart operation is detected by the target daemon thread of the terminal and the target file contains a first file, then the exception type when the abnormal event occurs is determined to be ANR; or, if no restart operation is detected by the target daemon thread of the terminal and the target file contains a second file, then the exception type when the abnormal event occurs is determined to be CRASH.

[0084] In some embodiments, the second type may include types such as System WindowTimeout (SWT). For example, if a restart operation is triggered by the target daemon thread of the terminal and a third file is contained in the target file, then the exception type when the operating system encounters an abnormal event is determined to be SWT.

[0085] In some embodiments of this application, classifying abnormal events helps to accurately locate the root cause of the fault and provides developers with accurate debugging directions.

[0086] In some embodiments, the anomaly information includes anomaly record information and attribution information. The anomaly record information is used to record the context information at the time the anomaly event occurred, and the attribution information is used to indicate the attribution object of the anomaly event.

[0087] The step of determining the abnormal information corresponding to the abnormal event using a strategy corresponding to the type of the abnormal event includes:

[0088] Based on the strategy corresponding to the type of the abnormal event, the abnormal record information corresponding to the abnormal event is determined;

[0089] Based on the anomaly record information, determine the attribution information corresponding to the anomaly event.

[0090] Anomaly information is a set of data used to describe the abnormal characteristics of an abnormal event.

[0091] In some embodiments, exception logging information may include, but is not limited to, the type of exception event, the timestamp of occurrence, the process identifier (PID, ProcessID), stack trace information, memory usage status, CPU utilization, system log fragments, etc. For example, when a crash occurs, exception logging information may include the exception class name, error message, complete call stack sequence, the thread name and thread ID of the thread that caused the exception event, and the remaining memory size of the terminal, etc.

[0092] Attribution information is used to indicate the system level, task module, or responsible party to which the abnormal event should be attributed.

[0093] In some embodiments, different abnormal record information corresponds to different attribution information, and the correspondence can be determined by manual input or system preset.

[0094] In some embodiments, attribution information corresponding to anomalous events can be determined based on a machine learning classification model. During the training phase, an initial classification model is trained using a large amount of historical anomalous record information and its manually labeled attribution tags to establish a mapping relationship from raw anomalous record information to attribution information. During the inference phase, the anomalous record information corresponding to the current anomalous event is vectorized (e.g., processed using TF-IDF or word embedding techniques to process log text) to obtain the corresponding feature vector. This feature vector is then input into the trained model to output the attribution category and confidence score for each event, thus obtaining the attribution information.

[0095] In some embodiments, after determining the attribution information, it can be uploaded to the cloud platform along with the anomaly log information. The cloud platform can then generate a fault report or trigger an alarm based on the anomaly information. For example, the cloud platform can output the anomaly information to the relevant responsible personnel. For instance, when there is a network connection, the corresponding anomaly information can be sent to the relevant responsible personnel via email. When there is no network connection, the current anomaly information can be automatically copied and cached, and then transmitted to the relevant responsible personnel via email or other contact methods when there is a network connection.

[0096] In some embodiments of this application, by constructing a complete description of the abnormal event through abnormal record information and attribution information, the efficiency of abnormal diagnosis can be improved, enabling development, operation and maintenance and testing teams to quickly locate the responsible party for the problem, and at the same time shortening the abnormal response time.

[0097] In some embodiments, determining the exception record information corresponding to the exception event based on the strategy corresponding to the type of the exception event includes:

[0098] When the type of the abnormal event is the first type, the abnormal log file corresponding to the abnormal event of the first type is parsed to obtain the abnormal record information corresponding to the abnormal event of the first type.

[0099] An exception log file is a diagnostic data file generated by a system service and stored locally on the terminal device when an exception occurs. It records the context information at the time of the exception. For example, in the Android operating system, this exception log file is typically created by DropBoxManagerService and stored in the / data / system / dropbox / directory. The filename can include a timestamp and an exception tag, such as "data_app_crash@1713528000000.txt" or "data_app_anr@1713528060000.txt". The exception log file can contain multiple information segments, such as exception stack traces, process status, memory usage, CPU load, and thread lists.

[0100] Understandably, in the Android operating system, when ActivityManagerService detects that an application has crashed or is unresponsive, it calls the addErrorToDropBox interface to write the collected diagnostic data to DropBoxManagerService, which then serializes the received diagnostic data into an exception log file and stores it.

[0101] In some embodiments, exception log files can be captured in real time by reading the latest exception log file in the dropbox directory or by listening to file creation events in the dropbox directory through the FileObserver.

[0102] In some embodiments, when the type of the abnormal event is determined to be the first type, the parsing of the abnormal log file corresponding to the abnormal event is initiated. For example, the contents of the abnormal log file are read line by line, and key information segments are identified according to preset regular expressions or keywords (such as "at com.example.app", "CPU usage", "DALVIK THREADS") to obtain matching data items. The matching data items are then filled into a predefined data structure to form structured abnormal record information. This abnormal record information can be structured data composed of multiple fields, with one field corresponding to one matching data item. For example, the abnormal record information can include at least a basic information field, a stack information field, and an environment context field. The basic information field covers the type identifier of the abnormal event, the application package name, the process ID, the timestamp of the abnormal event, and the device model, etc.; the stack information field can include the abnormal class name, the abnormal message, the stack call sequence, and the line number of the error code, etc.; the environment context field can include the memory usage, CPU usage, battery level, and network status at the time of the abnormal event.

[0103] In some embodiments, determining the exception record information corresponding to the exception event based on the strategy corresponding to the type of the exception event includes:

[0104] After the restart operation, determine whether the target system directory corresponding to the target daemon thread stores the relevant information recorded when the abnormal event occurred:

[0105] If it exists, then based on the recorded relevant information, determine the abnormal record information corresponding to the second type of abnormal event.

[0106] The target system directory refers to the file system path where the target daemon stores its monitoring logs, restart records, or exception contexts during operation.

[0107] Understandably, the target system directory can be located in a protected path under the system partition, such as / data / system / respawn / , / var / log / daemon / , or / vendor / log / . For Watchdog, when the system is not responding, the heartbeat status of each service is written to the system file under the / data / system / watchdog directory.

[0108] In some embodiments, when the type of the abnormal event is determined to be the second type, a detection operation on the target system directory is performed after the restart operation. Specifically, based on the application package name or process name corresponding to the abnormal event occurring at the current time, a preset daemon thread mapping table can be queried to determine the associated target daemon thread, and the file path of the target system directory corresponding to the target daemon thread can be obtained; and it is checked whether there are log files or record entries in the target system directory that match the current abnormal event occurrence time window. For example, if the abnormal event occurrence time is T, then log files or record lines in the target system directory with timestamps that are the same as or close to T (e.g., within the event range of [T-30s, T+5s]) are matched.

[0109] In some embodiments, the recorded information may be determined by the target daemon thread based on the exception log file corresponding to the second type of exception event.

[0110] In some embodiments of this application, parsing the exception log file corresponding to the first type of exception event yields the corresponding exception record information, ensuring timely capture and analysis of software exceptions. Simultaneously, after a system restart, the target system directory corresponding to the target daemon thread is further checked to determine if information related to the exception event exists, and to identify the exception record information corresponding to the second type of exception event. This improves the integrity of exception information, avoids loss of exception information due to system restarts, and enhances the system's monitoring and handling capabilities for exception events, enabling rapid location and resolution of exception problems.

[0111] In some embodiments, the exception log information includes the application's identification information and stack information, and determining the attribution information corresponding to the exception event based on the exception log information includes:

[0112] Based on the identification information and the preset mapping relationship, the associated users associated with the identification information are obtained, so as to determine the attribution information corresponding to the abnormal event;

[0113] The preset mapping relationship is used to indicate the associated users corresponding to each of the multiple preset identifiers.

[0114] Application identification information refers to the information used to uniquely identify an application. For example, application identification information may include, but is not limited to, the application package name, process name, application signature hash, and version number. As an example, in the Android operating system, each application can be identified by a unique application package name.

[0115] Stack information refers to the call stack information generated when an abnormal event occurs, which is used to indicate the execution path of the application at the time of the abnormal event.

[0116] Pre-defined mapping relationships refer to pre-established data tables, which can be stored in a local database or a remote server. Pre-defined identifiers refer to the identifiers of applications with clearly defined responsibilities; these identifiers can be the application's package name or process name.

[0117] Associated users are entities that have a development, maintenance, management, or usage relationship with the application corresponding to the preset identifier. In some embodiments, associated users may be represented in ways including but not limited to the development team name, the email address of the person in charge of operations and maintenance, or an internal corporate account.

[0118] In some embodiments, the preset mapping relationship can be determined by system preset or manual input.

[0119] In some embodiments, the located exception log file is analyzed. For example, the content of the exception log file can be analyzed using keyword matching to obtain the process name or package name that generated the log file, i.e., to parse out the process name or package name to which the exception log file belongs. Based on the determined process name or package name, attribution information is obtained, which may include the user's name, email address, etc., and the exception log file is then sent to the corresponding user. One exemplary implementation of obtaining attribution information is: configuring a mapping table between attribution information and application identification information; when a new application is installed, the application's attribution information is added to this mapping table. The attribution information may include the user's name, email address, etc., and the application's identification information may include the application's process name or application package name.

[0120] In some embodiments of this application, the attribution information of abnormal events can be quickly determined by a preset mapping relationship, thereby assigning the abnormal events to the corresponding teams or users for processing, and thus improving the efficiency of abnormal handling.

[0121] In some embodiments, the method further includes:

[0122] When the prompt function is enabled, the abnormal information is displayed on the corresponding interface of the terminal using a preset assertion method.

[0123] In some embodiments, user actions can be detected and acquired in various ways to enable the prompt function. Users can input instructions to enable the prompt function by clicking buttons, checking options, entering commands, or using voice, and the terminal can enable the prompt function when it detects such instructions.

[0124] The interface corresponding to the terminal refers to the graphical user interface currently displayed on the terminal device.

[0125] Preset assertion methods can refer to a method where, when a specific type of abnormal event (such as CRASH, ANR, or SWT) is detected and the alert function is enabled, the operating system or application actively interrupts its current execution process and forces the display of the abnormal information on the interface. For example, a preset assertion method may include rendering an interface that covers the entire screen, displayed with a preset visual style (such as a red background, white text, and a warning icon).

[0126] For example, the default assertion method can be the red screen assertion method. The exception information displayed in the interface corresponding to the red screen assertion method includes, but is not limited to: the type of exception event (such as "CRASH" or "ANR"), the timestamp of occurrence, the application's identification information (such as the application package name and version number), the stack information (such as the exception class name and the line number of the error), and the exception attribution information (such as "Responsible party: Third-party login SDK V2.3.1"). The content of the displayed exception information can be flexibly configured according to the actual situation. For example, in the development and testing phase, the red screen assertion can display the complete Java stack trace; while in the production environment, for security reasons, only the de-identified key fields are displayed to avoid leaking sensitive code structures.

[0127] In some embodiments, the terminal device can enable the red screen assertion prompt function by connecting locally to adb (and executing adb root) and executing `setprop persist.sys.disable.asserttip false`, and conversely, disable the red screen assertion prompt function by setting it to `true`; alternatively, it can be controlled by setting a password, and after entering the password, the red screen assertion function can be controlled by turning the asserttip switch on / off; or, the red screen assertion prompt function can be controlled through a cloud server.

[0128] In some embodiments, when the prompting function is enabled, the abnormal information can be displayed on the corresponding interface of the terminal; if it is not enabled, the abnormal information can only be recorded in the local log of the interruption or reported to the cloud server, and not directly displayed to the user, so as to avoid interfering with ordinary users.

[0129] Understandably, the duration of the displayed error message is a preset time, such as automatically disappearing after 5 seconds, or requiring the user to manually click the "close" button; the visual style of the error message can use a red background with white text to indicate a warning, and the font size can be adapted to different screen densities.

[0130] In some embodiments of this application, under the premise of enabling the prompt function, abnormal information is displayed on the terminal interface in a preset assertion manner, which can realize the visual display of abnormal information and help locate and resolve abnormal events.

[0131] To better understand the above scheme, the exception handling method will be explained below with a specific embodiment.

[0132] When the native Android operating system detects application exceptions such as ANR and CRASH, it displays information such as the application package name in a dialog box on the user interface. Users can click "OK" or "Continue Waiting" to decide whether to exit the process or continue waiting. However, this method relies on the normal operation of the operating system. When an exception occurs, the operating system will automatically restart, preventing the exception information from being displayed. In addition, since there are many task modules involved in the development and testing process, when an exception message for a specific task module pops up, testers can only confirm that an exception occurred in that task module, but cannot determine the responsible person for that task module, or need to search for information, which reduces the efficiency of exception resolution. Furthermore, only the application package name can be displayed, not the exception stack information, making it difficult to accurately locate the exception.

[0133] Understandably, the native Android operating system calls the `ZygoteInit.zygoteInit` method during the process creation and initialization phase. The main tasks of `ZygoteInit` are to start the binder thread, call the process's `main` method, and set up handling methods for uncaught exceptions. When a process crashes, the `handleApplicationCrashInner` method is triggered. This method retrieves the process name and stack information of the crash and calls the `addErrorToDropBox` method of `ActivityManagerService` to pass this information to `DropBoxManagerService`. When an application process experiences an ANR (Application Not Responding) error, `appNotResponding` in `ActivityManagerService` also passes the process name and stack information of the ANR to `DropBoxManagerService` by calling `addErrorToDropBox`. Similarly, when the system experiences a SWT (Short-Terminal Wound) error, the watchdog thread passes the process names and stack information of each current thread of the system process to `DropBoxManagerService` by calling `addErrorToDropBox`.

[0134] As shown in the above process, by setting a listener in the `addErrorToDropBox` method of `DropBoxManagerService`, it is possible to listen for exception events such as CRASH / ANR / SWT in various processes of the Android operating system. When a process experiences CRASH or ANR, the process name and stack information of the exception event are obtained. By decrypting the process name and the list of module owners, the owner of the exception process is obtained. Then, all the above exception information is integrated and the exception display module interface is called to display the content on the terminal's exception prompt interface. When it is necessary to hide the exception prompt interface, it can be hidden by clicking the screen.

[0135] The above describes how to handle CRASH or ANR events in a process. However, when an SWT occurs in the Android operating system, the system is directly restarted, making it impossible to display an exception message interface. Therefore, relevant exception information for this type of event can be saved to a system directory (e.g., / data / system / watchdog). After restarting, the system checks this directory for relevant exception information during the boot process. If no such information is found, the boot process proceeds normally. If so, the system parses the process name and the list of module owners to obtain the relevant owner information. This information is then integrated with the SWT's stack trace and process name, and the exception display module interface is called to display the corresponding SWT exception information on the exception message interface. When the exception message interface is closed, the relevant exception information previously saved in the system directory (e.g., / data / system / watchdog) is deleted.

[0136] It should be noted that the exception display module can be implemented through a native service. The native service provides an interface to the upper framework layer. When the control switch for the red screen assertion prompt function is turned on, this service is automatically started. When the function switch is turned off, this service exits. This service receives the exception information passed by the upper framework layer, creates a Surface through the SurfaceFlinger createSurface interface, and draws the relevant exception information to display the exception prompt interface.

[0137] It should be noted that the above description of the process is for illustrative purposes only and does not limit the scope of this specification. Those skilled in the art can make various modifications and changes to the process under the guidance of this specification. However, these modifications and changes remain within the scope of this specification.

[0138] To better understand the above solution, the exception handling system will be explained below with a specific embodiment. For example... Figure 3As shown, the framework layer (e.g., Framework) in the exception handling system refers to the basic software framework in the Android operating system, which includes the application execution environment and system-level service management modules. Within this basic software framework layer, an application refers to a third-party application or pre-installed application installed and running on the terminal; system service processes (e.g., SystemServer) are processes that provide critical system services during system operation.

[0139] When an application crashes due to an uncaught exception, or when a critical service process in a system service becomes unresponsive due to blocking, the addErrorToDropBox interface provided by DropBoxManagerService will be called to write diagnostic data containing context information such as stack traces, CPU usage, and memory status to the corresponding log collector (e.g., the dropbox directory), resulting in a text file in the / data / system / dropbox / directory.

[0140] The exception handling module is used to continuously monitor new log entries in the DropBox directory through a file observer or polling mechanism, classify the captured exception information, and convert the original exception log file into structured data to determine whether to trigger a full-screen exception prompt interface according to a preset strategy.

[0141] A watchdog is a monitoring thread that is re-run by the operating system to periodically check the responsiveness of system service processes. Specifically, if a system service process fails to respond within several consecutive monitoring cycles, or if the overall system load remains saturated, the watchdog determines that an abnormal event has occurred and calls the preset exception reporting interface to trigger the exception handling process.

[0142] The interface layer (such as the JNI layer) is used to pass structured exception information from the basic software framework layer to the native layer. The native layer refers to the native code execution environment. In this native layer, the exception display module (such as the AssertTip module) is used to receive exception information from the JNI layer and display the exception message interface through a graphical synthesis service.

[0143] like Figure 4As shown, the exception handling system also includes an exception monitoring module. This module, when ActivityManagerService detects an application crash, calls the `addErrorToDropBox` method to log error information to a Dropbox log collector. Simultaneously, a file observer (e.g., FileObserver) in the BootReceiver monitors the tombstone directory (e.g., TOMBSTONE_DIR). When a new stack trace is detected, this information is passed to the subsequent exception handling module. The exception handling module performs further analysis and processing, such as displaying the error message in full-screen mode or performing other recovery operations. This ensures the system can promptly capture and respond to abnormal application behavior, improving system stability and user experience.

[0144] Adding assertions refers to the process by which an exception display module (such as AssertTip) draws and displays exception information on the screen when preset conditions are met. For example, after receiving instructions to display exception information, the exception display module bypasses the regular window management process (e.g., WindowManagerService may be outdated) and directly draws a full-screen interface on the top layer of the screen using SurfaceFlinger or by directly writing to the framebuffer, thus obtaining the exception display interface. The exception display interface can be rendered using a simple graphics library (such as Skia), with a red background and white text, ensuring clear display even under low resource conditions.

[0145] like Figure 5 As shown, the exception handling system also includes an exception display module, which is used to generate a corresponding exception prompt interface based on the parsed exception information and the queried attribution information (such as development team, responsible department, etc.).

[0146] For details on the implementation of each of the above operations, please refer to the previous examples, which will not be repeated here.

[0147] Figure 6 This is a schematic diagram of the structure of an electronic device according to some embodiments of this application. For example... Figure 6 As shown, the electronic device 600 may include a processor 601 and a memory 602. The electronic device 600 may also include one or more of a multimedia component 603, an input / output (I / O) component 604, and a communication component 605. In this embodiment, the electronic device 600 may be a device that implements the exception handling method provided in this embodiment.

[0148] The processor 601 controls the overall operation of the electronic device 600 to complete all or part of the steps in the above-described exception handling method. The memory 602 stores various types of data to support the operation of the electronic device 600. This data may include, for example, instructions for any application or method operating on the electronic device 600, and application-related data such as images, audio, video, etc. The memory 602 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as Static Random Access Memory (SRAM), Electrically Erasable Programmable Read Only Memory (EEPROM), Erasable Programmable Read Only Memory (EPROM), Programmable Read Only Memory (PROM), Read Only Memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The multimedia component 603 may include a screen and an audio component. The screen may be, for example, a touchscreen, and the audio component is used to output and / or input audio signals. For example, the audio component may include a microphone for receiving external audio signals. The received audio signals may be further stored in memory 602 or transmitted via communication component 605. The audio component also includes at least one speaker for outputting audio signals. I / O component 604 provides an interface between processor 601 and other interface modules, such as a keyboard, mouse, buttons, etc. These buttons may be virtual or physical buttons. Communication component 605 is used for wired or wireless communication between the electronic device 600 and other devices. Wireless communication, such as Wi-Fi, Bluetooth, Near Field Communication (NFC), 2G, 3G, 4G, Narrowband Internet of Things (NB-IoT), Enhanced Machine Type Communication (eMTC), or other 5G technologies, or combinations thereof, is not limited here. Therefore, the corresponding communication component 605 may include: a Wi-Fi module, a Bluetooth module, an NFC module, etc.

[0149] In an exemplary embodiment, the electronic device 600 may be implemented by one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), controllers, microcontrollers, microprocessors, or other electronic components to perform the above-described exception handling method.

[0150] In another exemplary embodiment, a computer-readable storage medium is also provided, on which program instructions are stored, which, when executed by a processor, implement the steps of the above-described exception handling method. For example, the computer-readable storage medium may be the memory 602 containing the program instructions, which may be executed by the processor 601 of the electronic device 600 to implement or execute the methods, steps, and logic diagrams disclosed in the embodiments of this application.

[0151] Alternatively, when the instructions are executed by a computer, they may be used to implement or execute the methods, steps, and logic diagrams disclosed in the embodiments of this application.

[0152] In another exemplary embodiment, a computer program product is also provided, including a computer program or instructions that, when executed by a processor, implement the steps of the above-described exception handling method. For example, the computer program product may be the memory 602 including the computer program, which may be executed by the processor 601 of the electronic device 600 to implement or execute the methods, steps, and logic diagrams disclosed in the embodiments of this application.

[0153] Alternatively, when the instructions are executed by a computer, they may be used to implement or execute the methods, steps, and logic diagrams disclosed in the embodiments of this application.

[0154] Figure 7 This is an exemplary schematic diagram of a vehicle according to some embodiments of this application.

[0155] like Figure 7 As shown, this application also provides a vehicle equipped with the electronic device provided in any of the above embodiments, the electronic device being used to execute the exception handling method provided in any of the above embodiments. The vehicle may be a gasoline-powered vehicle, a plug-in hybrid electric vehicle, or a new energy vehicle, etc., and this specification does not specifically limit it.

[0156] In one embodiment, the vehicle can be configured for fully or partially autonomous driving. For example, the vehicle can control itself while in autonomous driving mode, and can determine the current state of the vehicle and its surrounding environment through human intervention, determine the possible behaviors of at least one other vehicle in the surrounding environment, and determine the confidence level corresponding to the probability of that other vehicle performing a possible behavior, and control the vehicle based on the determined information. When the vehicle is in autonomous driving mode, it can be configured to operate without human interaction.

[0157] In the description of this application, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Therefore, a feature defined as "first" or "second" may explicitly or implicitly include one or more features. In the description of this application, "multiple" means two or more, unless otherwise explicitly specified.

[0158] The embodiments, implementation methods, and related technical features of this application can be combined and substituted for each other without conflict.

[0159] The above are merely preferred embodiments of this application and are not intended to limit this application in any way. Although the descriptions of each embodiment in this application have different focuses, and the parts not described in detail in a certain embodiment can be referred to the relevant embodiments of other embodiments, any simple modifications, equivalent changes and modifications made to the above embodiments based on the technical essence of this application without departing from the content of the technical solution of this application shall still fall within the scope of the technical solution of this application.

Claims

1. An abnormality processing method characterized by comprising: The method applied to a terminal comprises: In response to an abnormal event of an application program being monitored, it is detected whether a target daemon thread of the terminal triggers a restart operation to determine a type of the abnormal event; In a strategy corresponding to the type of the abnormal event, abnormal information corresponding to the abnormal event is determined.

2. The method of claim 1, wherein, The detection of whether the target daemon thread of the terminal triggers the restart operation to determine the type of the abnormal event comprises: When the target daemon thread of the terminal is not detected to trigger the restart operation, it is determined that the type of the abnormal event is a first type, and the first type is used to indicate an abnormality of the application program; When the target daemon thread of the terminal is detected to trigger the restart operation, it is determined that the type of the abnormal event is a second type, and the second type is used to indicate an abnormality of a system program.

3. The method of claim 1, wherein, The abnormal information comprises abnormal record information and attribution information, the abnormal record information is used to record context information at the time when the abnormal event occurs, and the attribution information is used to indicate an attribution object of the abnormal event. In the strategy corresponding to the type of the abnormal event, the abnormal record information corresponding to the abnormal event is determined based on the strategy corresponding to the type of the abnormal event. The abnormal record information corresponding to the abnormal event is determined according to the abnormal record information. The abnormal record information corresponding to the abnormal event is determined based on the strategy corresponding to the type of the abnormal event.

4. The method of claim 3, wherein, In a case where the type of the abnormal event is the first type, an abnormal log file corresponding to the abnormal event of the first type is parsed to obtain the abnormal record information corresponding to the abnormal event of the first type. The abnormal record information corresponding to the abnormal event is determined based on the strategy corresponding to the type of the abnormal event.

5. The method of claim 3, wherein, After the restart operation, it is determined whether a target system directory corresponding to the target daemon thread stores relevant information recorded at the time when the abnormal event occurs: If yes, the abnormal record information corresponding to the abnormal event of the second type is determined according to the recorded relevant information. The abnormal record information comprises identification information and stack information of the application program, and the attribution information corresponding to the abnormal event is determined according to the abnormal record information.

6. The method of claim 3, wherein, According to the identification information and a preset mapping relationship, an associated user associated with the identification information is obtained to determine the attribution information corresponding to the abnormal event. The preset mapping relationship is used to indicate associated users corresponding to a plurality of preset identifications. The method further comprises:

7. The method of claim 1, wherein, In a case where a prompt function is enabled, the abnormal information is displayed on a corresponding interface of the terminal in a preset assertion manner. Comprise:

8. An electronic device, comprising: A memory having a computer program stored thereon; A processor configured to execute the computer program in the memory to implement the steps of the method according to any one of claims 1 to 7. A computer program stored on a memory, the computer program being executed by a processor to implement the steps of the method according to any one of claims 1 to 7.

9. A computer-readable storage medium, characterized in that, ​ 10. A computer program product, characterised in that, comprising computer program or instructions to implement the steps of the method of any of claims 1 to 7 when the computer program or instructions are executed by a processor.

11. A vehicle characterized by comprising: comprising the electronic device of claim 8, or to implement the steps of the method of any of claims 1 to 7.

Images