Abnormality processing method, apparatus, and electronic device

Abstract

This application discloses an exception handling method, apparatus, and electronic device, belonging to the field of electronic device technology. The method includes: after the kernel of the electronic device starts but before the system framework starts, if an SWT restart event is detected, then acquiring abnormal operation information associated with the SWT restart event; wherein the system of the electronic device includes multiple decoupled functional modules; based on the abnormal operation information, determining the target functional module that caused the SWT restart event from the multiple decoupled functional modules; and disabling the target functional module.

Description

Technical Field

[0001] This application belongs to the field of electronic equipment technology, specifically relating to an anomaly handling method, apparatus, and electronic equipment. Background Technology

[0002] A software watchdog (SWT) is a commonly used health monitoring mechanism for electronic devices. It monitors the system's operational status by periodically resetting a counter. When a system anomaly causes the heartbeat to be lost, SWT will trigger a system restart to restore normal system operation through automatic restart of the electronic device.

[0003] In related technologies, SWT can only perform mechanical restart recovery when the system is abnormal. For example, when there are continuous abnormal timings after an Over-The-Air (OTA) upgrade, electronic devices are prone to getting stuck in a vicious cycle of repeated restarts, causing the electronic devices to get stuck in the boot stage and unable to enter the system, thus reducing the availability of the electronic devices. Summary of the Invention

[0004] The purpose of this application is to provide an anomaly handling method, apparatus, and electronic device that can prevent electronic devices from falling into a vicious cycle of repeated restarts due to functional abnormalities, thereby improving the availability of electronic devices.

[0005] In a first aspect, embodiments of this application provide an exception handling method applied to an electronic device, the method comprising: After the kernel of the electronic device starts but before the system framework starts, if a software watchdog (SWT) restart event is detected, abnormal operation information associated with the SWT restart event is obtained; wherein, the system of the electronic device contains multiple decoupled functional modules; Based on the abnormal operation information, the target functional module that caused the SWT restart event is determined from the plurality of decoupled functional modules; Disable the target functional module.

[0006] Secondly, embodiments of this application provide an anomaly handling device applied to an electronic device, the device comprising: The acquisition module is used to acquire abnormal operation information associated with the SWT restart event if an SWT restart event is detected after the kernel of the electronic device starts but before the system framework starts; wherein, the system of the electronic device includes multiple decoupled functional modules; The determination module is used to determine the target functional module that caused the SWT restart event from the plurality of decoupled functional modules based on the abnormal operation information. Disable module, used to disable the target functional module.

[0007] Thirdly, embodiments of this application provide an electronic device including a processor, a memory, and a program or instructions stored in the memory and executable on the processor, wherein the program or instructions, when executed by the processor, implement the steps of the exception handling method described in the first aspect.

[0008] Fourthly, embodiments of this application provide a readable storage medium on which a program or instructions are stored, which, when executed by a processor, implement the steps of the exception handling method described in the first aspect.

[0009] Fifthly, embodiments of this application provide a chip, which includes a processor and a communication interface. The communication interface and the processor are coupled, and the processor is used to run programs or instructions to implement the steps of the exception handling method as described in the first aspect.

[0010] In this embodiment of the application, after the kernel of the electronic device starts but before the system framework starts, if an SWT restart event is detected, abnormal operation information associated with the SWT restart event is obtained; wherein, the system of the electronic device includes multiple decoupled functional modules; based on the abnormal operation information, the target functional module causing the SWT restart event is determined from the multiple decoupled functional modules; and the target functional module is disabled.

[0011] As can be seen, in this embodiment of the application, in the intermediate stage between the kernel startup of the electronic device and the system framework startup, by analyzing the abnormal operation information of historical SWT restart events and utilizing the decoupling characteristics of the system's functional modules, the target functional module that caused the abnormality is accurately located and disabled. This enables self-repair on the device side without external intervention, avoiding the vicious cycle of repeated restarts caused by functional abnormalities and improving the availability of the electronic device. Attached Figure Description

[0012] Figure 1 This is an example diagram of the SWT exception handling process provided by related technologies; Figure 2 This is one of the flowcharts of an exception handling method provided in the embodiments of this application; Figure 3 This is a second flowchart of an exception handling method provided in an embodiment of this application; Figure 4 This is an example diagram of the SWT exception handling process provided in the embodiments of this application; Figure 5 This is a structural block diagram of an exception handling device provided in an embodiment of this application; Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application; Figure 7 This is a schematic diagram of the hardware structure of an electronic device that implements an embodiment of this application. Detailed Implementation

[0013] The technical solutions of the embodiments of this application will be clearly described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application are within the scope of protection of this application.

[0014] The terms "first," "second," etc., used in the specification and claims of this application are used to distinguish similar objects and not to describe a specific order or sequence. It should be understood that such terms can be used interchangeably where appropriate so that embodiments of this application can be implemented in orders other than those illustrated or described herein, and the objects distinguished by "first," "second," etc., are generally of the same class and the number of objects is not limited; for example, a first object can be one or more. Furthermore, in the specification and claims, "and / or" indicates at least one of the connected objects, and the character " / " generally indicates that the preceding and following objects are in an "or" relationship.

[0015] SWT exception handling procedures in related technologies, such as Figure 1 As shown: After an electronic device is powered on, the kernel starts first, followed by the complete system framework startup, loading all functional modules from the system installation package, including various newly added features, such as... Figure 1 The system includes new features 1, 2, ..., 8, etc. Under this architecture, the functional modules are highly coupled and lack independent operational status control mechanisms.

[0016] When a functional module in the system installation package (such as new feature 1) has a defect or an anomaly, the function will trigger an SWT soft interrupt during operation, causing the system to crash and triggering the restart of electronic devices. During the restart process, the system will generate and record a dropbox file containing information about the anomaly, for subsequent offline analysis.

[0017] However, when the electronic device restarts and re-enters the system, the problematic function module (new function 1) is still loaded and running normally. This causes the system to trigger the abnormal function again, triggering the SWT soft interrupt and causing the electronic device to restart once more. This cycle repeats, trapping the electronic device in a vicious cycle of "abnormal trigger → restart → trigger again → restart again," ultimately causing the device to get stuck at the boot stage and unable to enter the system normally. Users are unaware of this process and cannot intervene, only able to wait for the manufacturer to push a fix via OTA. During this period, the electronic device is completely unusable, severely impacting the user experience.

[0018] The anomaly handling method provided in this application will be described in detail below with reference to the accompanying drawings, specific embodiments, and application scenarios.

[0019] Figure 2 This is one of the flowcharts of an exception handling method provided in the embodiments of this application, applied to electronic devices, such as... Figure 2 As shown, the method may include the following steps: step 201, step 202 and step 203.

[0020] In step 201, after the kernel of the electronic device starts but before the system framework starts, if an SWT restart event is detected, abnormal operation information associated with the SWT restart event is obtained; wherein, the system of the electronic device contains multiple decoupled functional modules.

[0021] The exception handling method in this embodiment is executed in the intermediate stage between the kernel startup and the system framework startup of the electronic device. Kernel startup refers to the process of loading and running the operating system kernel after the electronic device is powered on. During this stage, the system completes basic operations such as hardware initialization, memory management establishment, and driver loading, providing a foundation for the subsequent operation of the system framework and applications.

[0022] The reason for choosing this timing is that when an electronic device experiences a SWT restart, the system has already crashed once and cannot execute complex diagnostic logic at the moment of the crash. However, after the kernel starts but before the system framework is loaded, the system environment has basically returned to stability, and functional modules that may cause abnormalities again have not yet been loaded. Analyzing and processing the SWT restart event at this time can not only safely read the abnormal running information left by the previous crash, but also disable the abnormal functional modules before the system framework starts, thereby preventing functional abnormalities from triggering SWT restarts again from the source and achieving safe recovery of the electronic device.

[0023] In this embodiment, an SWT restart event refers to an electronic device restart event caused by the triggering of the Software Watchdog (SWT) mechanism. A software watchdog is a system health monitoring mechanism that monitors the system's operating status by periodically resetting a counter. When a system anomaly causes a loss of heartbeat, i.e., the system fails to reset the counter within a specified time, the SWT mechanism is triggered, leading to an automatic restart of the electronic device in order to restore normal system operation. Each device restart triggered by this event is recorded as an SWT restart event.

[0024] In this embodiment, the existence of an SWT restart event can be determined by analyzing historical operation records. These historical operation records refer to historical restart logs or abnormal archive data stored on the device side.

[0025] In this embodiment, by analyzing historical restart logs or abnormal archive data stored on the device side to trace SWT restart events, accurate diagnosis can be achieved based on historical abnormal records without interfering with the current operation of the system, providing a reliable basis for subsequent self-repair.

[0026] In this embodiment of the application, abnormal operation information refers to on-site data associated with the SWT restart event, such as system-generated dropbox files, exception stacks, log files, etc., which can be used for subsequent analysis.

[0027] In this embodiment, to support accurate anomaly localization and self-healing, the system architecture of the electronic device was optimized. Specifically, taking the system installation package as an example, the system installation package contains multiple decoupled functional modules. That is, for non-core additional functions, such as new selling point functions, track optimization, and user experience improvement functions, modular and component-based design is adopted when going live, and the functional modules are decoupled from each other to prevent related coupling. Core functions can maintain the original architecture without forced decoupling. Through this differentiated design, each non-core functional module can be loaded or removed independently, and the system has complete compatibility with its existence state. For example, through the interface method of "boolean enable=mSwt.getFunctionStatus(inttype)", an independent enable status flag is configured for each functional module. When enable is true, the function is available; otherwise, the function is disabled. This modular decoupling design provides an architectural foundation for the subsequent accurate shutdown of abnormal functions, ensuring the stability of core functions while allowing non-core functions to be flexibly shut down when problems occur.

[0028] In step 202, based on the abnormal operation information, the target functional module that caused the SWT restart event is determined from multiple decoupled functional modules.

[0029] In this embodiment, the target functional module refers to the specific functional module that caused the SWT restart event, as determined by abnormal operation information analysis. These modules are typically non-core supplementary functions, such as new selling point features, track optimization features, or user experience improvement features. When a functional module malfunctions and triggers continuous SWT restarts, it is identified as the target functional module through abnormal operation information. This module possesses characteristics such as locatability (accurately identifiable through stack traces), tailorability (adopting a decoupled design, disabling it does not affect the core system functions), and recoverability (it can be re-enabled after subsequent OTA upgrades).

[0030] In this embodiment of the application, it is considered that when SWT triggers a restart, the system will generate a dropbox file containing the exception stack, function call chain and other context information before the crash. This information records the execution path of the program at the time of the exception. Since different types of functional modules will exhibit different stack characteristics when they crash (for example, the class name and function name of a specific functional module will appear repeatedly in the stack), by analyzing the exception running information, the specific source of the exception, i.e. the target functional module, can be located.

[0031] In some embodiments, accurate diagnosis can be achieved through exception stack analysis. Accordingly, step 202 above may specifically include the following steps: step 2021, step 2022, step 2023 and step 2024. In step 2021, the exception stack data in the exception runtime information is parsed to obtain the functional classes and / or functions contained in the exception stack frame.

[0032] In this embodiment, after obtaining the abnormal execution information, parsing the exception stack data in the exception execution information can yield the functional classes and / or functions contained in the exception stack frame, such as the getAuthToken function under the android.accounts. package and the connectGatt function under the android.bluetooth. package. This functional class and function information records the program's execution path at the time the exception occurred, and is a key clue for locating the source of the exception.

[0033] In step 2022, the functional class and / or function are matched with a preset mapping table; wherein, the mapping table records the correspondence between different functional category IDs and functional class feature information and / or function feature information.

[0034] In this embodiment of the application, a mapping table is pre-configured in the electronic device. The mapping table records the correspondence between different functional category IDs and functional class feature information and / or function feature information. For example, the mapping table is shown in Table 1 below.

[0035]

[0036] Table 1 In this embodiment of the application, matching entries can be found by comparing the parsed functional classes and / or functions with the feature information in the mapping table.

[0037] In step 2023, the functional category ID corresponding to the successfully matched functional class and / or function is determined as the target category ID.

[0038] In this embodiment of the application, when a certain group of functional classes and / or functions successfully matches an entry in the mapping table, the functional category ID corresponding to that entry is determined as the target category ID. This target category ID is an identifier for the abnormal functional module, such as "account authentication_type01" or "Bluetooth connection_type02", etc.

[0039] In step 2024, the corresponding target functional module is determined from multiple decoupled functional modules based on the target classification ID.

[0040] In this embodiment, based on the target category ID, the specific functional module corresponding to that ID is found in the system installation package, which is the target functional module that caused the SWT restart event. Since each functional module adopts a modular decoupled design, and each functional module has an independent enabled status identifier, the specific functional module can be quickly located using the target category ID.

[0041] As can be seen, in this embodiment of the application, by matching the exception stack features with a preset mapping table, the specific functional module causing the exception can be inferred in reverse, thereby clarifying the specific functional point that caused the SWT to restart, rather than simply attributing it to an overall system exception, thus providing a reliable basis for accurately disabling the exception functional module in the future.

[0042] In step 203, the target functional module is disabled.

[0043] In this embodiment, after identifying the target functional module, it can be disabled by adjusting its enable status flag (e.g., setting enable to false), closing the module, or blocking its loading process. Because the functional module employs a decoupled design, disabling it will not affect the normal operation of other core functions. For example, if a value-added function (such as a new selling point feature, track optimization, or user experience enhancement feature) is found to trigger an SWT restart, the function can be temporarily disabled by not loading it, setting its status flag to disable, or directly closing the module. In this case, the electronic device can resume normal startup and use after the abnormal function is removed. Even if the function is temporarily unavailable, the core functions of the user's electronic device remain usable, thus avoiding the problem of the device being stuck in the boot process and unable to enter the system due to non-core function malfunctions.

[0044] As can be seen from the above embodiments, in this embodiment, after the kernel of the electronic device starts but before the system framework starts, if an SWT restart event is detected, abnormal operation information associated with the SWT restart event is obtained; wherein, the system of the electronic device contains multiple decoupled functional modules; based on the abnormal operation information, the target functional module causing the SWT restart event is determined from the multiple decoupled functional modules; and the target functional module is disabled.

[0045] As can be seen, in this embodiment of the application, in the intermediate stage between the kernel startup of the electronic device and the system framework startup, by analyzing the abnormal operation information of historical SWT restart events and utilizing the decoupling characteristics of the system's functional modules, the target functional module that caused the abnormality is accurately located and disabled. This enables self-repair on the device side without external intervention, avoiding the vicious cycle of repeated restarts caused by functional abnormalities and improving the availability of the electronic device.

[0046] Figure 3 This is a second flowchart of an exception handling method provided in this application embodiment, applied to electronic devices. In this application embodiment, to avoid false triggering caused by occasional factors such as instantaneous load, a continuous exception judgment mechanism can also be introduced, such as... Figure 3 As shown, the method may include the following steps: step 301, step 302 and step 303.

[0047] In step 301, after the kernel of the electronic device starts but before the system framework starts, if N consecutive SWT restart events are detected within a preset time period, abnormal operation information associated with the N consecutive SWT restart events is obtained; wherein, the system of the electronic device contains multiple decoupled functional modules, and N≥2.

[0048] In practical applications, a single SWT restart may be caused by sporadic factors such as instantaneous load surges, rather than a genuine functional module failure. Disabling functionality immediately upon a single restart event could lead to misjudgments and unnecessary function shutdowns, impacting user experience. To avoid this problem, this application introduces a judgment mechanism based on the number of consecutive anomalies. Specifically, a preset duration (e.g., 5 minutes, 10 minutes, or 30 minutes, configurable according to actual needs) and a consecutive count threshold N (N≥2, e.g., 3 or 5 times) are set. Subsequent diagnostic and repair processes are triggered only when N consecutive SWT restart events are detected within the preset duration, and abnormal operational information associated with these N consecutive SWT restart events is obtained.

[0049] In this embodiment of the application, it can be determined whether there are N consecutive SWT restart events by analyzing historical operation records.

[0050] In this embodiment of the application, this judgment method based on the number of consecutive anomalies can effectively filter out occasional interference. Only when the same abnormal pattern occurs repeatedly in a short period of time is it identified as a persistent fault that requires intervention, thereby improving the accuracy of positioning.

[0051] In step 302, based on the abnormal operation information, the functional module that is associated with N consecutive SWT restart events is identified as the target functional module.

[0052] In this embodiment, after obtaining abnormal operation information from N consecutive SWT restart events, the abnormal information of each SWT restart event is analyzed separately. Through exception stack analysis and feature matching (refer to the specific implementation of steps 2021 to 2024), the functional module corresponding to each SWT restart event is determined. If N consecutive SWT restart events all point to the same functional module, that is, the functional module is identified as the source of the exception in each restart event, then the functional module is determined as the target functional module. This "multiple points to the same module" judgment condition further strengthens the reliability of fault location, ensuring that the disabled functional module is indeed the cause of repeated restarts.

[0053] In step 303, the target functional module is disabled.

[0054] In this embodiment, after identifying the target functional module, its enabled status flag (e.g., setting enable to false), the module is closed, or its loading process is blocked to disable the functional module. Because the functional module employs a decoupled design, disabling it will not affect the normal operation of other core functions. For example, if a value-added function (such as a new selling point feature, track optimization, or user experience enhancement feature) is found to trigger an SWT restart, the function can be temporarily disabled by not loading it, setting its status flag to disable, or directly closing the module. In this case, the electronic device can resume normal startup and use after the abnormal function is removed. Even if the function is temporarily unavailable, the core functions of the user's electronic device remain usable, thus avoiding the problem of the device being stuck in the boot process and unable to enter the system due to non-core function malfunctions.

[0055] For example, the SWT exception handling process in this application embodiment is as follows: Figure 4 As shown: After an electronic device is powered on, the kernel starts first. In the intermediate stage before the system framework starts, if multiple SWT restart events are detected within a short period of time, the SWT analysis module is activated and begins to execute the exception diagnosis process.

[0056] The SWT analysis module first extracts abnormal runtime information associated with historical SWT restart events, including system-recorded dropbox files and exception stack data. Then, it compares this exception stack information with a pre-configured stack trace file corresponding to the new features. This stack trace file is pre-configured with the characteristic class names and function information of each functional module.

[0057] By matching stack traces, the SWT analysis module can accurately pinpoint the specific functional module causing the anomaly. When it is determined that a functional module in the system installation package (such as new feature 1) has a defect or anomaly, the system does not need to load the complete system framework; instead, it directly disables the abnormal functional module.

[0058] It should be noted that for other functional modules that are not new feature 1, if an SWT soft interrupt is triggered during subsequent operation and causes the device to restart, the system will also output the corresponding dropbox file. However, these abnormal events will be stored as independent exception records and will not affect the currently completed diagnosis and disabling results.

[0059] In this embodiment, because the system adopts a modular and decoupled design, the coupling between functional modules is low, and it has an independent operation status control mechanism. Therefore, disabling new function 1 will not affect the normal loading and operation of other functional modules. After disabling the abnormal functional module, the system framework continues to start. At this time, the disabled new function 1 will no longer be loaded and executed, thus avoiding a vicious cycle of infinite restarts due to functional abnormalities. The electronic device can enter the system normally, and the user's core functional experience is unaffected. The disabled non-core functions will be re-enabled after subsequent OTA repairs.

[0060] As can be seen from the above embodiments, in this embodiment, a continuous anomaly judgment mechanism is introduced in the intermediate stage after kernel startup and before system framework startup. Based on the statistical analysis of N consecutive SWT restart events within a preset time, the functional modules that repeatedly cause anomalies are accurately identified and disabled, avoiding false triggering caused by occasional factors such as instantaneous load, and improving the accuracy of anomaly diagnosis and the reliability of the self-repair mechanism.

[0061] In some embodiments provided in this application, the exception handling method may further include the following steps after step 203 or step 303: step 401 and step 402.

[0062] In step 401, a diagnostic report is generated; wherein the diagnostic report includes abnormal operation information, the identifier of the target functional module, and the disabled execution results.

[0063] In this embodiment, after disabling the target functional module on the device side, a diagnostic report is generated to record complete information about the anomaly and the repair process. This diagnostic report includes at least the following: abnormal operation information associated with the SWT restart event (such as exception stack data, Dropbox information, etc.), the identifier of the identified target functional module (e.g., functional category ID or module name), and the execution result of the disabling operation (e.g., whether the disabling was successful, the disabling time, etc.). This diagnostic report is equivalent to a problem log on the device side, recording in detail the occurrence of the anomaly, the diagnostic process, and the repair measures taken, providing the initial basis for subsequent in-depth analysis and repair.

[0064] In step 402, the diagnostic report is sent to the cloud server for subsequent OTA upgrade and repair.

[0065] In this embodiment, the electronic device sends the generated diagnostic report to a cloud server. The manufacturer can summarize and analyze a large number of returned diagnostic reports to pinpoint the root cause of the problem, such as confirming that a code defect in a specific functional module is causing the anomaly. After finding the root cause, the manufacturer can develop a fix patch and push it to the user's electronic device via OTA (Over-The-Air). Once the user's electronic device receives the OTA update package and completes the update, the defect in the functional module is fixed, and the disabled functional module can be re-enabled and restored to normal use.

[0066] As can be seen, in this embodiment, the above steps construct a complete processing flow from temporary repair on the device side to permanent resolution on the manufacturer side: the device side achieves rapid self-recovery by disabling abnormal functions, ensuring the immediate availability of the device; the manufacturer side analyzes and locates the root cause through diagnostic reports and pushes repair patches via OTA, ultimately enabling the disabled functional modules to be re-enabled. This approach minimizes the scope and duration of the system problem's impact, improving the stability of electronic devices and ensuring the continuity of user experience.

[0067] In some embodiments provided in this application, the exception handling method provided in this application has good scalability, and is not only applicable to the diagnosis and repair of SWT restart events, but can also be extended to other types of system exceptions. Accordingly, in the above... Figure 2 or Figure 3 Based on the illustrated embodiment, the following step can be added: Step 403.

[0068] In step 403, if an abnormal event corresponding to another preset fault type is detected besides the SWT restart event, the repair action corresponding to the other preset fault type is executed according to the preset fault repair strategy extension library.

[0069] In this embodiment of the application, a fault repair strategy extension library is pre-configured in the electronic device. The extension library records a variety of preset fault types and the corresponding repair actions for each preset fault type.

[0070] Specifically, the preset fault types may include, but are not limited to, at least one of the following: memory leak (referring to the continuous occupation of system memory resources that cannot be released), deadlock (referring to multiple threads or processes being blocked due to waiting for resources from each other), thermal runaway (referring to the continuous rise of device temperature beyond the normal range), driver abnormality (referring to hardware driver malfunctions), etc.

[0071] For different fault types, the extension library predefines corresponding repair actions, such as process isolation (suitable for problems caused by a single process, such as memory leaks), selective thread restart (suitable for thread-level blocking problems, such as deadlocks), dynamic frequency reduction (suitable for temperature-related faults, such as thermal runaway), and driver version rollback (suitable for hardware compatibility issues, such as driver anomalies).

[0072] In this embodiment of the application, it is also possible to determine whether there are abnormal events corresponding to other preset fault types by analyzing historical operation records.

[0073] In this embodiment, when an electronic device detects an abnormal event corresponding to a preset fault type other than the SWT restart event during operation, it first identifies the fault type to which the abnormal event belongs, then queries the fault repair strategy extension library to obtain the repair action corresponding to the fault type, and executes the repair action to achieve self-repair. For example, when a memory leak abnormality is detected, a repair action to isolate the relevant processes can be executed; when a thermal runaway abnormality is detected, a repair action to dynamically reduce the frequency can be executed.

[0074] As can be seen, in this embodiment, by introducing a fault repair strategy extension library, the original exception handling method for SWT restarts is extended into a general system-level self-detection and self-repair framework. With future technological advancements, new fault types and corresponding repair actions can be continuously added to the extension library, enabling electronic devices to possess continuously evolving self-repair capabilities, thereby improving the stability and availability of electronic devices.

[0075] The exception handling method provided in this application can be executed by an exception handling device. This application uses an exception handling device executing the exception handling method as an example to illustrate the exception handling device provided in this application.

[0076] Figure 5 This is a structural block diagram of an exception handling device provided in an embodiment of this application, which is applied to electronic devices, such as... Figure 5 As shown, the exception handling device 500 may include: an acquisition module 501, a determination module 502, and a disable module 503.

[0077] The acquisition module 501 is used to acquire abnormal operation information associated with the SWT restart event if an SWT restart event is detected after the kernel of the electronic device starts but before the system framework starts; wherein, the system of the electronic device includes multiple decoupled functional modules; The determining module 502 is used to determine the target functional module that caused the SWT restart event from the plurality of decoupled functional modules based on the abnormal operation information. The disable module 503 is used to disable the target function module.

[0078] As can be seen from the above embodiments, in this embodiment, during the intermediate stage after the kernel of the electronic device starts and before the system framework starts, by analyzing the abnormal operation information of historical SWT restart events, and utilizing the decoupling characteristics of the system's functional modules, the target functional module that caused the abnormality is accurately located and disabled. This enables self-repair on the device side without external intervention, avoiding the vicious cycle of repeated restarts caused by functional abnormalities in the electronic device and improving the availability of the electronic device.

[0079] Optionally, as an embodiment, the determining module 502 is specifically used to parse the abnormal stack data in the abnormal operation information to obtain the functional classes and / or functions contained in the abnormal stack frame; match the functional classes and / or functions with a preset mapping table; wherein, the mapping table records the correspondence between different functional category IDs and functional class feature information and / or function feature information; determine the functional category ID corresponding to the successfully matched functional class and / or function as the target category ID; and determine the corresponding target functional module from the plurality of decoupled functional modules according to the target category ID.

[0080] Optionally, as an embodiment, the acquisition module 501 is specifically used to acquire abnormal operation information associated with the N consecutive SWT restart events if N consecutive SWT restart events are detected within a preset time period, wherein N≥2; The determining module 502 is specifically used to determine the functional module that is associated with the N consecutive SWT restart events as the target functional module based on the abnormal operation information.

[0081] Optionally, as an embodiment, the exception handling device 500 may further include: A generation module is used to generate a diagnostic report; wherein the diagnostic report includes the abnormal operation information, the identifier of the target functional module, and the disabled execution results; The startup module is used to send the diagnostic report to the cloud server for subsequent OTA upgrades and repairs.

[0082] Optionally, as an embodiment, the exception handling device 500 may further include: The processing module is used to perform repair actions corresponding to other preset fault types according to the preset fault repair strategy extension library when an abnormal event corresponding to other preset fault types is detected, in addition to the SWT restart event. The fault repair strategy extension library records a variety of preset fault types and the corresponding repair actions for each preset fault type. The preset fault types include at least one of the following: memory leak, deadlock, thermal runaway, and driver anomaly. The repair actions include at least one of the following: process isolation, selective thread restart, dynamic frequency reduction, and driver version rollback.

[0083] The exception handling device in this application embodiment can be a device, or a component, integrated circuit, or chip in a terminal. The device can be a mobile electronic device or a non-mobile electronic device. For example, mobile electronic devices can be mobile phones, tablets, laptops, PDAs, in-vehicle electronic devices, wearable devices, ultra-mobile personal computers (UMPCs), netbooks, or personal digital assistants (PDAs), etc., while non-mobile electronic devices can be servers, network attached storage (NAS), personal computers (PCs), televisions (TVs), ATMs, or self-service machines, etc. This application embodiment does not impose specific limitations.

[0084] The exception handling device in this application embodiment can be a device with an operating system. This operating system can be Android, iOS, or other possible operating systems; this application embodiment does not specifically limit it.

[0085] The exception handling device provided in this application embodiment can achieve... Figure 2 or Figure 3 To avoid repetition, the various processes implemented in the method embodiment shown will not be described again here.

[0086] Optionally, such as Figure 6 As shown, this application embodiment also provides an electronic device 600, including a processor 601, a memory 602, and a program or instructions stored in the memory 602 and executable on the processor 601. When the program or instructions are executed by the processor 601, they implement the various processes of the above-described exception handling method embodiment and achieve the same technical effect. To avoid repetition, they will not be described again here.

[0087] It should be noted that the electronic devices in the embodiments of this application include the mobile electronic devices and non-mobile electronic devices described above.

[0088] Figure 7 This is a schematic diagram of the hardware structure of an electronic device that implements an embodiment of this application.

[0089] The electronic device 700 includes, but is not limited to, components such as: radio frequency unit 701, network module 702, audio output unit 703, input unit 704, sensor 705, display unit 706, user input unit 707, interface unit 708, memory 709, and processor 710.

[0090] Those skilled in the art will understand that the electronic device 700 may also include a power supply (such as a battery) for supplying power to various components. The power supply may be logically connected to the processor 710 through a power management system, thereby enabling functions such as managing charging, discharging, and power consumption through the power management system. Figure 7 The electronic device structure shown does not constitute a limitation on the electronic device. The electronic device may include more or fewer components than shown, or combine certain components, or have different component arrangements, which will not be elaborated here.

[0091] The processor 710 is configured to, after the kernel of the electronic device starts but before the system framework starts, if an SWT restart event is detected, acquire abnormal operation information associated with the SWT restart event; wherein the system of the electronic device includes multiple decoupled functional modules; based on the abnormal operation information, determine the target functional module that caused the SWT restart event from the multiple decoupled functional modules; and disable the target functional module.

[0092] As can be seen, in this embodiment of the application, in the intermediate stage between the kernel startup of the electronic device and the system framework startup, by analyzing the abnormal operation information of historical SWT restart events and utilizing the decoupling characteristics of the system's functional modules, the target functional module that caused the abnormality is accurately located and disabled. This enables self-repair on the device side without external intervention, avoiding the vicious cycle of repeated restarts caused by functional abnormalities and improving the availability of the electronic device.

[0093] Optionally, as an embodiment, the processor 710 is specifically configured to parse the exception stack data in the exception operation information to obtain the functional classes and / or functions contained in the exception stack frame; match the functional classes and / or functions with a preset mapping table; wherein, the mapping table records the correspondence between different functional category IDs and functional class feature information and / or function feature information; determine the functional category ID corresponding to the successfully matched functional class and / or function as the target category ID; and determine the corresponding target functional module from the plurality of decoupled functional modules according to the target category ID.

[0094] Optionally, as an embodiment, the processor 710 is specifically configured to, if N consecutive SWT restart events are detected within a preset time period, acquire abnormal operation information associated with the N consecutive SWT restart events, wherein N≥2; and determine the functional modules associated with all N consecutive SWT restart events as target functional modules based on the abnormal operation information.

[0095] Optionally, as an embodiment, the processor 710 is further configured to generate a diagnostic report; wherein the diagnostic report includes the abnormal operation information, the identifier of the target functional module, and the disabled execution results; and the diagnostic report is sent to a cloud server for subsequent over-the-air (OTA) upgrade and repair.

[0096] Optionally, as an embodiment, the processor 710 is further configured to, when detecting an abnormal event corresponding to other preset fault types besides the SWT restart event, perform a repair action corresponding to the other preset fault types according to a preset fault repair strategy extension library; The fault repair strategy extension library records a variety of preset fault types and the corresponding repair actions for each preset fault type. The preset fault types include at least one of the following: memory leak, deadlock, thermal runaway, and driver anomaly. The repair actions include at least one of the following: process isolation, selective thread restart, dynamic frequency reduction, and driver version rollback.

[0097] It should be understood that, in this embodiment, the input unit 704 may include a graphics processing unit (GPU) 7041 and a microphone 7042. The GPU 7041 processes image data of still images or videos obtained by an image capture device (such as a camera) in video capture mode or image capture mode. The display unit 706 may include a display panel 7061, which may be configured in the form of a liquid crystal display, an organic light-emitting diode, etc. The user input unit 707 includes a touch panel 7071 and other input devices 7072. The touch panel 7071 is also called a touch screen. The touch panel 7071 may include a touch detection device and a touch controller. Other input devices 7072 may include, but are not limited to, physical keyboards, function keys (such as volume control buttons, power buttons, etc.), trackballs, mice, and joysticks, which will not be described in detail here. The memory 709 can be used to store software programs and various data, including but not limited to applications and operating systems. Processor 710 can integrate an application processor and a modem processor. The application processor mainly handles the operating system, user interface, and applications, while the modem processor mainly handles wireless communication. It is understood that the modem processor may also not be integrated into processor 710.

[0098] This application also provides a readable storage medium storing a program or instructions. When the program or instructions are executed by a processor, they implement the various processes of the above-described exception handling method embodiments and achieve the same technical effect. To avoid repetition, they will not be described again here.

[0099] The processor is the processor in the electronic device described in the above embodiments. The readable storage medium includes computer-readable storage media, such as computer read-only memory (ROM), random access memory (RAM), magnetic disk, or optical disk.

[0100] This application embodiment also provides a chip, which includes a processor and a communication interface. The communication interface is coupled to the processor. The processor is used to run programs or instructions to implement the various processes of the above-described exception handling method embodiments and can achieve the same technical effect. To avoid repetition, it will not be described again here.

[0101] It should be understood that the chip mentioned in the embodiments of this application may also be referred to as a system-on-a-chip, system chip, chip system, or system-on-a-chip, etc.

[0102] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element. Furthermore, it should be noted that the scope of the methods and apparatuses in the embodiments of this application is not limited to performing functions in the order shown or discussed, but may also include performing functions substantially simultaneously or in the reverse order, depending on the functions involved. For example, the described methods may be performed in a different order than described, and various steps may be added, omitted, or combined. Additionally, features described with reference to certain examples may be combined in other examples.

[0103] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a computer software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk), including several instructions to cause a terminal (which may be a mobile phone, computer, server, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0104] The embodiments of this application have been described above with reference to the accompanying drawings. However, this application is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms under the guidance of this application without departing from the spirit and scope of the claims, and all of these forms are within the protection scope of this application.

Claims

1. An exception handling method, characterized in that, Applied to electronic devices, the method includes: After the kernel of the electronic device starts but before the system framework starts, if a software watchdog (SWT) restart event is detected, abnormal operation information associated with the SWT restart event is obtained; wherein, the system of the electronic device contains multiple decoupled functional modules; Based on the abnormal operation information, the target functional module that caused the SWT restart event is determined from the plurality of decoupled functional modules; Disable the target functional module.

2. The method according to claim 1, characterized in that, The step of determining the target functional module causing the SWT restart event from the plurality of decoupled functional modules based on the abnormal operation information includes: Parse the exception stack data in the exception operation information to obtain the functional classes and / or functions contained in the exception stack frame; The functional classes and / or functions are matched with a preset mapping table; wherein, the mapping table records the correspondence between different functional category identifiers ID and functional class feature information and / or function feature information; The functional category ID corresponding to the successfully matched functional class and / or function is determined as the target category ID; Based on the target classification ID, the corresponding target functional module is determined from the plurality of decoupled functional modules.

3. The method according to claim 1, characterized in that, If a Software Watchdog Timer (SWT) restart event is detected, abnormal operation information associated with the SWT restart event is obtained, including: If N consecutive SWT restart events are detected within a preset time period, abnormal operation information associated with the N consecutive SWT restart events is obtained, where N≥2; The step of determining the target functional module causing the SWT restart event from the plurality of decoupled functional modules based on the abnormal operation information includes: Based on the abnormal operation information, the functional modules associated with the N consecutive SWT restart events are identified as the target functional modules.

4. The method according to claim 1, characterized in that, After disabling the target functional module, the method further includes: Generate a diagnostic report; wherein the diagnostic report includes the abnormal operation information, the identifier of the target functional module, and the disabled execution results; The diagnostic report will be sent to the cloud server for subsequent over-the-air (OTA) upgrades and repairs.

5. The method according to claim 1, characterized in that, The method further includes: If an abnormal event corresponding to another preset fault type is detected, in addition to the SWT restart event, the repair action corresponding to the other preset fault type is executed according to the preset fault repair strategy extension library. The fault repair strategy extension library records a variety of preset fault types and the corresponding repair actions for each preset fault type. The preset fault types include at least one of the following: memory leak, deadlock, thermal runaway, and driver anomaly. The repair actions include at least one of the following: process isolation, selective thread restart, dynamic frequency reduction, and driver version rollback.

6. An anomaly handling device, characterized in that, Applied to electronic devices, the device includes: The acquisition module is used to acquire abnormal operation information associated with the SWT restart event if an SWT restart event is detected after the kernel of the electronic device starts but before the system framework starts; wherein, the system of the electronic device includes multiple decoupled functional modules; The determination module is used to determine the target functional module that caused the SWT restart event from the plurality of decoupled functional modules based on the abnormal operation information. Disable module, used to disable the target functional module.

7. The apparatus according to claim 6, characterized in that, The determining module is specifically used to parse the abnormal stack data in the abnormal operation information to obtain the functional classes and / or functions contained in the abnormal stack frame; match the functional classes and / or functions with a preset mapping table; wherein, the mapping table records the correspondence between different functional category identifiers ID and functional class feature information and / or function feature information; determine the functional category ID corresponding to the successfully matched functional class and / or function as the target category ID; and determine the corresponding target functional module from the plurality of decoupled functional modules based on the target category ID.

8. The apparatus according to claim 6, characterized in that, The acquisition module is specifically used to acquire abnormal operation information associated with the N consecutive SWT restart events if N consecutive SWT restart events are detected within a preset time period, where N≥2; The determining module is specifically used to determine the functional module that is associated with the N consecutive SWT restart events as the target functional module based on the abnormal operation information.

9. The apparatus according to claim 6, characterized in that, The device further includes: A generation module is used to generate a diagnostic report; wherein the diagnostic report includes the abnormal operation information, the identifier of the target functional module, and the disabled execution results; The startup module is used to send the diagnostic report to the cloud server for subsequent OTA upgrades and repairs.

10. The apparatus according to claim 6, characterized in that, The device further includes: The processing module is used to perform repair actions corresponding to other preset fault types according to the preset fault repair strategy extension library when an abnormal event corresponding to other preset fault types is detected, in addition to the SWT restart event. The fault repair strategy extension library records a variety of preset fault types and the corresponding repair actions for each preset fault type. The preset fault types include at least one of the following: memory leak, deadlock, thermal runaway, and driver anomaly. The repair actions include at least one of the following: process isolation, selective thread restart, dynamic frequency reduction, and driver version rollback.

11. An electronic device, characterized in that, The electronic device includes a processor, a memory, and a program or instructions stored in the memory and executable on the processor, wherein the program or instructions, when executed by the processor, implement the steps of the exception handling method as described in any one of claims 1-5.

Images