Subsystem failure handling method and terminal device

Abstract

Embodiments of the present application provide a kind of sub-system fault processing method and terminal equipment, terminal equipment includes first processor, first processor runs with first sub-system, first sub-system runs with first process, the method includes: when first process crashes, current error prompt information is obtained;Error prompt information is used to indicate the error of process appearance;If there is first file in terminal equipment, whether target error prompt information exists in first file is determined;First file includes one or more groups of preset error prompt information, and target error prompt information refers to the preset error prompt information consistent with current error prompt information;If target error prompt information exists in first file, first sub-system is restarted;If target error prompt information does not exist in first file, first process is restarted.The method can dynamically select PDR or SSR, and the influence of software system improvement convenience and other processes in sub-system is considered.

Description

Technical Field

[0001] This application relates to the field of electronic technology, specifically to a subsystem fault handling method and terminal equipment. Background Technology

[0002] Currently, in the architecture of terminal devices, one or more subsystems can work in conjunction with an application processor (AP) to achieve different functions. For example, the AP can control the application digital signal processor (ADSP) subsystem to perform functions such as audio processing, sensor data acquisition, and charging management.

[0003] Process domains (PDs, or simply processes) within a subsystem may crash during operation due to malfunctions. Generally, process crashes can be handled in two ways: process domain restart (PDR) and subsystem restart (SSR). In PDR, the subsystem generates a PDR dump file and sends it to the AP side for developers to locate and analyze the problem. However, PDR dump files contain limited information, making it difficult to accurately pinpoint the root cause of some faults, hindering troubleshooting. SSR provides a more comprehensive dump file, but it can impact other processes. For example, if a sensor process in an ADSP malfunctions and the subsystem restarts, running audio and charger processes may cease operation, leading to audio playback interruptions, charging malfunctions, and negatively impacting user experience. Summary of the Invention

[0004] This application provides a subsystem fault handling method and terminal device that can dynamically select PDR or SSR, taking into account both the convenience of software system improvement and the impact on other processes in the subsystem.

[0005] In a first aspect, this application provides a subsystem fault handling method, which is executed by a terminal device. The terminal device includes a first processor, in which a first subsystem runs, and in which a first process runs. The method includes: when the first process crashes, obtaining current error message information; the error message information is used to indicate an error that has occurred in the process; if a first file exists in the terminal device, determining whether a target error message information exists in the first file; the first file includes one or more sets of preset error message information, and the target error message information refers to the preset error message information that is consistent with the current error message information; if the target error message information exists in the first file, restarting the first subsystem; if the target error message information does not exist in the first file, restarting the first process.

[0006] The first process can be any non-root process in the first subsystem. The error message subsystem outputs key information when a process crashes, such as its last words. The first file can be the parsed fault configuration file in a specific implementation.

[0007] Preset error messages can be pre-defined error messages corresponding to faults requiring a subsystem restart. For example, preset error messages might be pre-collected error messages that the PDR dump file cannot accurately locate and analyze the problem. In other words, if the subsystem outputs these preset error messages and a PDR is performed, the generated PDR dump file cannot pinpoint the root cause of the process crash, thus making accurate problem location and analysis impossible.

[0008] The subsystem fault handling method provided in the first aspect of this application compares the current error message with various preset error messages in a first file when the first process crashes and needs to be restarted. It determines whether an error message matching the current message exists in the first file. If it does, the subsystem is restarted; otherwise, the first process is restarted. In other words, this method dynamically selects between restarting the subsystem or restarting the process based on the current error message. This effectively balances the advantages and disadvantages of restarting the subsystem and restarting the process, taking into account the convenience of software system improvements and the impact on other processes, thereby improving the user experience.

[0009] Specifically, if the first file contains an error message consistent with the current error message, it indicates that the PDR dump file generated by restarting the process cannot accurately locate and analyze the problem. Therefore, a subsystem restart is chosen to resolve the fault while obtaining a more comprehensive dump file, facilitating accurate problem localization and analysis by developers. If the first file does not contain an error message consistent with the current error message, it means that the PDR dump file generated by restarting the process can accurately locate and analyze the problem. Therefore, a process restart is chosen, which not only quickly restores the faulty process but also prevents impact on other processes within the subsystem. For example, restarting the sensor process without restarting the ADSP subsystem prevents impact on the charger and audio processes, thereby preventing disruption to the user's normal use of charging and audio playback functions and improving the user experience.

[0010] In one possible implementation, after restarting the first subsystem, the method further includes: generating a first dump file; after restarting the first process, the method further includes: generating a second dump file.

[0011] The first dump file is also known as the SSR dump file. The second dump file is also known as the PDR dump file.

[0012] Optionally, after generating the first and second dump files, the terminal device can also report the first and second dump files to a remote server to facilitate the R&D personnel in analyzing and locating problems and improving the software program.

[0013] In one possible implementation, the terminal device further includes an application processor (AP), and the method further includes: the AP acquiring a first file; the AP sending one or more sets of preset error message information from the first file to the first processor via a QMI communication channel; and the first processor storing one or more sets of preset error message information.

[0014] The first processor has limited memory and computing power. In this implementation, the first file is obtained through the AP, and then one or more sets of preset error message information in the first file are sent to the first processor, thus saving the resources of the first processor.

[0015] In one possible implementation, the AP obtains the first file by: responding to the first switch being turned on, if it is determined that authorization information exists and the second switch is in the on state, then the AP parses the configuration parameters of the second switch to obtain the information of the second file; the authorization information indicates that the user has agreed to obtain the operating data of the terminal device, the configuration parameters of the second switch are pushed to the terminal device by the front-end server, and the second file is an unparsed configuration file that matches the device model and software version information of the terminal device; sending a download request to the configuration server; the download request carries the information of the second file; receiving the second file sent by the configuration server; performing security and integrity verification on the second file; and parsing the second file to obtain the first file.

[0016] The first switch can be a function switch in a specific implementation, and the second switch can be a fault file switch in a specific implementation. The authorization information is an authorization success message in a specific implementation.

[0017] Optionally, the first switch can be activated either by the user through the application interface or by developers sending a switch activation command to the terminal device via a remote server. Upon receiving the command, the terminal device activates the first switch. Activating the second switch is similar.

[0018] In this implementation, developers can centrally manage and configure the first file through a configuration server, while terminal devices download the second file from the configuration server. This facilitates management for developers and allows terminal devices to easily download and update the second file. Furthermore, the second file is only downloaded after confirming the existence of authorized information, fully guaranteeing user privacy and security, and improving user experience. In addition, the security and integrity of the second file are verified before parsing, enhancing its security and reliability, thereby increasing the success rate of subsequent fault handling.

[0019] In one possible implementation, in response to the first switch being turned on, if it is determined that authorization information exists and the second switch is in the on state, before the AP parses the configuration parameters of the second switch to obtain the information of the second file, the method further includes: the AP receiving target configuration parameters pushed by the front-end server, the target configuration parameters including the switch configuration parameters of the first switch and the second switch; the AP loading the target configuration parameters; the AP displaying a first interface; the first interface including the first switch and the second switch.

[0020] The target configuration parameters can be dynamic configuration parameters in a specific implementation.

[0021] In this implementation, the target configuration parameters are pushed to the terminal device via the front-end server, facilitating unified management by developers of the corresponding function (i.e., dynamic restart function) on the terminal device. After loading the target configuration parameters, the terminal device gains dynamic restart capability, enabling it to dynamically select the fault handling method for subsystem processes based on error conditions. This fully weighs the advantages and disadvantages of subsystem restart and process restart, taking into account the convenience of software system improvement and the impact on other processes, thereby improving the user experience.

[0022] In one possible implementation, the AP obtains the first file by: responding to the second switch being turned on; if it is determined that the first switch is in the on state and authorization information exists, the AP parses the configuration parameters of the second switch to obtain the information of the second file; the authorization information indicates that the user has agreed to obtain the operating data of the terminal device; the configuration parameters of the second switch are pushed to the terminal device by the front-end server; the second file is an unparsed configuration file that matches the device model and software version information of the terminal device; sending a download request to the configuration server; the download request carries the information of the second file; receiving the second file sent by the configuration server; performing security and integrity verification on the second file; and parsing the second file to obtain the first file.

[0023] In other words, requesting the download of the second file from the configuration server can be triggered by turning on the first switch or by turning on the second switch.

[0024] One possible implementation is to associate the first switch and the second switch. When the first switch is turned on, the terminal device can turn on the second switch by default, and when the second switch is turned on, the terminal device can also turn on the first switch by default.

[0025] In one possible implementation, the first file includes first device model information and first software version information; the AP sends one or more sets of preset error message information from the first file to the first processor through the QMI communication channel, including: the AP determining whether the first device model information is consistent with the device model information of the terminal device, and whether the first software version information is consistent with the software version information of the terminal device; if consistent, the AP sends one or more sets of preset error message information to the first processor through the QMI communication channel.

[0026] Because different device models and software versions correspond to different first files and have different preset error messages, in this implementation, the AP performs software version verification of the device model before sending data from the first file to the first processor. This prevents the sending of incorrect preset error messages to the first processor and improves the accuracy and reliability of the algorithm.

[0027] In one possible implementation, the first processor stores one or more sets of preset error message information, including: the first processor stores one or more sets of preset error message information to a circular queue; if a first file exists in the terminal device, the first processor determines whether the target error message information exists in the first file, including: the first processor retrieves one or more sets of preset error message information from the circular queue; if one or more sets of preset error message information exist in the circular queue, the first processor determines whether the target error message information exists in the one or more sets of preset error message information.

[0028] In this implementation, one or more sets of preset error message information are saved to a circular queue, which can be quickly accessed by the root process of the first subsystem, thus improving the efficiency of algorithm execution.

[0029] In one possible implementation, the method further includes: if there is no set of or multiple sets of preset error message information in the circular queue, the first processor determines whether the state of the third switch is open; if the state of the third switch is open, the first processor restarts the first subprocess; if the state of the third switch is closed, the first processor restarts the first subsystem.

[0030] The third switch can be the PDR switch in the specific implementation.

[0031] In other words, when the dynamic restart function is disabled, the system can determine whether to use SSR or PDR mode to restart based on the state of the PDR switch, thus ensuring the proper handling of subsystem faults.

[0032] In one possible implementation, a root process also runs in the first subsystem. The first processor determines whether a target error message exists in one or more sets of preset error message information, including: determining whether a target error message exists in one or more sets of preset error message information through the root process; and restarting the first subsystem, including: restarting the first subsystem through the root process.

[0033] The root process can communicate with any other process in the first subsystem and control the execution of other processes, including termination and restart. The root process can also control its own restart, thereby controlling the restart of the entire first subsystem. Therefore, in this implementation, the root process manages one or more sets of preset error messages and determines the restart method based on these messages, facilitating rapid fault handling and improving process recovery efficiency.

[0034] In one possible implementation, the method further includes: receiving a log collection instruction sent by a remote server; displaying a second interface in response to the log collection instruction, the second interface including authorization request information, the authorization request information being used to request the user to authorize the acquisition of the terminal device's operating data; acquiring the terminal device's logs in response to the user performing an authorization agreement operation on the second interface; and reporting the logs to the remote server.

[0035] The second interface can be an interface that includes a request for authorization pop-up in a specific implementation. The action of agreeing to authorization is, for example, clicking the "Agree to Authorize" control in the second interface.

[0036] In this implementation, the terminal device reports logs to a remote server, allowing developers to analyze subsystem faults using these logs. This facilitates software program improvements, version updates, and ultimately, a better user experience. Furthermore, obtaining user authorization before collecting logs ensures user privacy and security, further enhancing the user experience.

[0037] In one possible implementation, the first processor is an application digital signal processor (ADSP), and the first subsystem is an ADSP subsystem; or, the first processor is a computational digital signal processor (CDSP), and the first subsystem is a CDSP subsystem; or, the first processor is a modem, and the first subsystem is a modem subsystem; or, the first processor is a wireless local area network (WLAN) processor, and the first subsystem is a WLAN subsystem.

[0038] Secondly, this application provides an apparatus included in a terminal device, which has the function of implementing the terminal device behaviors described in the first aspect and possible implementations of the first aspect. The function can be implemented by hardware or by hardware executing corresponding software. The hardware or software includes one or more modules or units corresponding to the above functions. For example, a receiving module or unit, a processing module or unit, etc.

[0039] Thirdly, this application provides a terminal device, which includes: one or more processors and a memory; the one or more processors include a first processor; the memory is coupled to the one or more processors, and the memory is used to store computer program code, the computer program code including computer instructions, and the one or more processors call the computer instructions to cause the terminal device to execute any method of the technical solution in the first aspect.

[0040] Fourthly, this application provides a system that includes a front-end server, a configuration server, a remote server, and a terminal device as described in the third aspect.

[0041] Fifthly, this application provides a chip system including one or more processors, one of which includes a first processor; the one or more processors are configured to invoke computer instructions to cause a terminal device to execute the methods in the first aspect and any possible implementation thereof.

[0042] Optionally, the chip system may also include memory, which is connected to the processor via circuitry or wires.

[0043] Alternatively, the chip system may also include a communication interface.

[0044] In a sixth aspect, this application provides a computer-readable storage medium storing a computer program, which, when executed by a processor, causes the processor to perform any one of the methods in the first aspect of the technical solution.

[0045] In a seventh aspect, this application provides a computer program product, which includes computer program code. When the computer program code is run on a terminal device, it causes the terminal device to execute any one of the methods in the technical solution of the first aspect. Attached Figure Description

[0046] Figure 1 This is an example of a fault handling system 10 provided in the embodiments of this application;

[0047] Figure 2 This is a schematic diagram of the structure of a terminal device 100 provided in an embodiment of this application;

[0048] Figure 3 This is a software structure block diagram of an example fault handling system provided in an embodiment of this application;

[0049] Figure 4 This is a flowchart illustrating an example system fault handling method provided in an embodiment of this application;

[0050] Figure 5 This is a schematic diagram of a configuration webpage in a front-end server provided in an embodiment of this application;

[0051] Figure 6 This is a schematic diagram of an example of a request for authorization pop-up provided in an embodiment of this application;

[0052] Figure 7 This is a schematic diagram illustrating the interface changes of a user-generated feedback log provided in an embodiment of this application.

[0053] Figure 8 This is a flowchart illustrating another example of a system fault handling method provided in an embodiment of this application;

[0054] Figure 9This is a schematic diagram of interface changes in an example of a switch state setting process provided in an embodiment of this application;

[0055] Figure 10 This is a schematic diagram illustrating the communication principle between an AP and an ADSP, provided in an embodiment of this application.

[0056] Figure 11 This is a flowchart illustrating one example after another of the system fault handling methods provided in the embodiments of this application;

[0057] Figure 12 This is a schematic diagram illustrating the relationship between the root process and other processes in an example of an ADSP subsystem provided in this application embodiment. Detailed Implementation

[0058] The technical solutions of the embodiments of this application will be described below with reference to the accompanying drawings. In the description of the embodiments of this application, unless otherwise stated, " / " means "or," for example, A / B can mean A or B; "and / or" in this text is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Furthermore, in the description of the embodiments of this application, "multiple" refers to two or more than two.

[0059] Hereinafter, the terms "first," "second," and "third" 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. Thus, a feature defined as "first," "second," or "third" may explicitly or implicitly include one or more of that feature.

[0060] References to "one embodiment" or "some embodiments" as described in this application specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this application specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

[0061] To better understand the embodiments of this application, the terms or concepts that may be involved in the embodiments are explained below.

[0062] 1. Log

[0063] Logs are records of events, actions, and states that occur during the operation of a system, application, or service. Logs are typically stored in text format, in chronological order. Logs can contain various information, such as error messages, warnings, and normal operational procedures.

[0064] 2. Dump file

[0065] A dump file is typically a complete snapshot of the data in memory or the system state. A dump file can include the memory space of processes, register values, system configuration information, etc. The data in a dump file can be in binary format. Generally, dump files are generated in the event of a serious error or crash.

[0066] Both logs and dump files can be used to locate and analyze problems in a system or application, and they can complement each other. For example, when a system or application fails, logs can provide relevant information before and after the failure, while dump files can provide a detailed system state at the time of the failure. Combining the two allows for a more comprehensive understanding of the root cause of the problem.

[0067] Terminal devices may include multiple processors, such as APs, modems, ADSPs and computational digital signal processors (CDSPs), baseband processors, wireless local area network (WLAN) processors, etc.

[0068] The operating system of a terminal device may include a main system running on the AP (AP side) and one or more subsystems running on other processors. These subsystems may include, but are not limited to, subsystems running on an ADSP (ADSP subsystem), CDSP (CDSP subsystem), modem (modem subsystem), and WLAN processor (WLAN subsystem). The ADSP subsystem can be used to implement functions such as audio processing, sensor data acquisition, and charging management (e.g., battery statistics). The CDSP subsystem can be used to implement functions such as image signal processing and encoding / decoding. The WLAN subsystem is used to implement data processing and transmission during wireless communication. It should be noted that each subsystem can be controlled by the AP side to achieve its respective function.

[0069] Subsystems can implement various functions through processes. Taking the ADSP subsystem as an example, in order to realize sensor data acquisition, ADSP can create and run a sensor process (sensor PD); in order to realize audio processing, ADSP can create and run an audio process (audio PD); and in order to realize power statistics, ADSP can create and run a charger process (charger PD).

[0070] It should be understood that a subsystem's process may crash during operation due to a failure. After a process crash, the subsystem typically recovers by either process restart (PDR) or subsystem restart (SSR). Both PDR and SSR generate dump files. Developers can use these dump files to locate and analyze system problems, thereby gradually modifying and improving the software program and updating the software system version. As one possible implementation, the subsystem can determine whether to use PDR or SSR to recover the process based on the user-set PDR switch status. If the PDR switch is on, PDR is selected to recover the process; if the PDR switch is off, SSR is selected.

[0071] Both PDR and SSR restart methods have their advantages and disadvantages. During PDR, a PDR dump file is generated. After PDR, ADSP sends the PDR dump file to the AP side. Developers can obtain the PDR dump file from the AP side and use it to locate and analyze problems, thereby resolving faults and improving system stability. However, although the PDR dump file saves the core dump, its limited size means it cannot display call stack information or pipeline log information. For some faults, developers can locate the problem's location and resolve it using the PDR dump file; however, for others, the PDR dump file can only provide a preliminary assessment and cannot accurately pinpoint the root cause, thus failing to fundamentally resolve the fault or allow for software version correction and updates.

[0072] During SSR (Solution-Based Response), an SSR dump file is generated. After SSR, the ADSP sends the SSR dump file to the AP (Application Processor). Compared to PDR (Progressive Data Reset) dump files, SSR dump files can store more comprehensive information, making it easier for developers to analyze and locate problems. However, directly performing an SSR due to a process crash can affect other processes in the subsystem, impacting the implementation of other services and consequently affecting the user experience. For example, if the sensor process in the ADSP crashes and the ADSP subsystem is restarted directly, it will affect the audio and charger processes, leading to interrupted audio playback, invalid power statistics, and a degraded user experience.

[0073] Therefore, while PDR (Problem Location Management) does not affect other processes within the subsystem, it hinders developers from locating and analyzing problems, and impedes software system version improvements. Conversely, SSR (Service Response Management), while beneficial for developers in locating and analyzing problems and for software system version improvements, impacts other processes within the subsystem, affecting user experience. Thus, finding a balance between the advantages and disadvantages of PDR and SSR, considering both the ease of software system improvement and the impact on other processes, is a problem that needs to be addressed.

[0074] The subsystem fault handling method provided in this application embodiment can pre-save a fault configuration file in the subsystem. The fault configuration file includes one or more pre-collected error message messages (referred to as preset error message messages). If the subsystem outputs these preset error message messages and performs a Process Detection (PDR), the generated PDR dump file cannot accurately locate and analyze the problem. Therefore, when a process in the subsystem crashes, the subsystem outputs the current error message message and compares it with the preset error message messages. If a set of preset error message messages matches the current error message message, it indicates that the PDR dump file generated by restarting the current fault via PDR is insufficient for developers to locate and analyze the problem. In this case, the process is restored using a Service Response (SSR) method. This allows for obtaining a more comprehensive dump file, facilitating problem location and analysis by developers and contributing to software system version improvements. If no preset error message message matches the current error message message, it indicates that the PDR dump file generated by restarting the current fault via PDR is sufficient for developers to locate and analyze the problem. Therefore, the process is restored using PDR, preventing impact on other processes in the subsystem, thus preventing disruption to subsystem functionality and avoiding a negative user experience. In summary, the method provided in this application can dynamically select the restart method based on preset error message information, weighing the advantages and disadvantages of PDR and SSR, thereby balancing the convenience of software system improvement with the impact on other processes in the subsystem and improving user experience.

[0075] In other words, the method provided in this application can select different restart methods based on different faults, i.e., dynamically select the restart method. For ease of explanation, in this application embodiment, the function of selecting the PDR or SSR restart method according to the fault configuration file is referred to as the subsystem dynamic restart function, or simply the dynamic restart function. Of course, the name of this function is only an example and is not intended to be limiting. In actual applications, other names can be set as needed, such as the PDR to SSR function.

[0076] The subsystem fault handling method provided in this application embodiment can be applied to, for example, Figure 1The fault handling system 10 shown includes a terminal device 100 and a server 200 communicatively connected to the terminal device 100. The server 200 can be a cloud server; therefore, it can also be referred to as a cloud-side server or a cloud service center. The server 200 may include a front-end server, a remote server, a configuration server, a fault analysis server, etc.

[0077] Terminal device 100 may be a mobile phone, tablet computer, wearable device, in-vehicle device, augmented reality (AR) / virtual reality (VR) device, laptop computer, ultra-mobile personal computer (UMPC), netbook, personal digital assistant (PDA), or other device with subsystems. This application embodiment does not impose any restrictions on the specific type of terminal device 100.

[0078] For example, Figure 2 This is a schematic diagram of the structure of a terminal device 100 provided in an embodiment of this application. The terminal device 100 may include a processor 110, an external memory interface 120, an internal memory 121, a universal serial bus (USB) interface 130, a charging management module 140, a power management module 141, a battery 142, an antenna 1, an antenna 2, a mobile communication module 150, a wireless communication module 160, an audio module 170, a speaker 170A, a receiver 170B, a microphone 170C, a headphone jack 170D, a sensor module 180, buttons 190, a motor 191, an indicator 192, a camera 193, a display screen 194, and a subscriber identification module (SIM) card interface 195, etc. The sensor module 180 may include a pressure sensor 180A, a gyroscope sensor 180B, a barometric pressure sensor 180C, a magnetic sensor 180D, an accelerometer sensor 180E, a distance sensor 180F, a proximity sensor 180G, a fingerprint sensor 180H, a temperature sensor 180J, a touch sensor 180K, an ambient light sensor 180L, a bone conduction sensor 180M, etc.

[0079] It is understood that the structures illustrated in the embodiments of this application do not constitute a specific limitation on the terminal device 100. In other embodiments of this application, the terminal device 100 may include more or fewer components than illustrated, or combine some components, or split some components, or have different component arrangements. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

[0080] Processor 110 may include one or more processing units, such as: AP, modem processor, graphics processing unit (GPU), image signal processor (ISP), controller, memory, video codec, digital signal processor (DSP), baseband processor, WLAN processor, CDSP, ADSP, and / or neural network processing unit (NPU), etc. Different processing units may be independent devices or integrated into one or more processors.

[0081] The controller can serve as the central nervous system and command center of the terminal device 100. The controller can generate operation control signals based on the instruction opcode and timing signals to control the fetching and execution of instructions.

[0082] The processor 110 may also include a memory for storing instructions and data. In some embodiments, the memory in the processor 110 is a cache memory. This memory can store instructions or data that the processor 110 has just used or that are used repeatedly. If the processor 110 needs to use the instruction or data again, it can retrieve it directly from the memory. This avoids repeated accesses, reduces the waiting time of the processor 110, and thus improves the efficiency of the system.

[0083] In some embodiments, the processor 110 may include one or more interfaces. Interfaces may include an inter-integrated circuit (I2C) interface, an inter-integrated circuit sound (I2S) interface, a pulse code modulation (PCM) interface, a universal asynchronous receiver / transmitter (UART) interface, a mobile industry processor interface (MIPI), a general-purpose input / output (GPIO) interface, a subscriber identity module (SIM) interface, and / or a universal serial bus (USB) interface, etc.

[0084] The charging management module 140 receives charging input from a charger. The charger can be a wireless charger or a wired charger. In some wired charging embodiments, the charging management module 140 receives charging input from the wired charger via the USB interface 130. In some wireless charging embodiments, the charging management module 140 receives wireless charging input via the wireless charging coil of the terminal device 100. While charging the battery 142, the charging management module 140 can also supply power to the terminal device via the power management module 141. Optionally, the charging management module can update the power information in the interface based on the power statistics provided by the ADSP, and control the start and stop of charging, etc.

[0085] The wireless communication function of the terminal device 100 can be implemented through antenna 1, antenna 2, mobile communication module 150, wireless communication module 160, modem processor, and baseband processor.

[0086] The wireless communication module 160 can provide solutions for wireless communication applications on the terminal device 100, including wireless local area networks (WLANs) (such as wireless fidelity (Wi-Fi) networks), Bluetooth (BT), global navigation satellite system (GNSS), frequency modulation (FM), near field communication (NFC), and infrared (IR) technologies. The wireless communication module 160 can connect to a WLAN processor, which processes and transmits data during WLAN communication.

[0087] One or more sensors in sensor module 180 can be connected to ADSP, and the ADSP can acquire and process the sensor data.

[0088] The software architecture of the fault handling system is described below.

[0089] Figure 3 A software architecture block diagram of a fault handling system according to an embodiment of this application is shown. First, the cloud-side software architecture is described. For example... Figure 3As shown, the front-end server may include a function configuration management module. Optionally, the front-end server may run a front-end web development platform, such as Ares Ocean. The function configuration management module can be a module within the front-end web development platform. The function configuration management module is used to provide developers with a configuration webpage to configure the configuration parameters of relevant functions of the terminal device, including the configuration parameters for the dynamic restart function (hereinafter referred to as dynamic configuration parameters, also known as target configuration parameters), and the device whitelist for the dynamic restart function (hereinafter referred to as the device whitelist).

[0090] Dynamic configuration parameters include, but are not limited to, software version information, device model information, and configuration parameters for switches related to the dynamic restart function (hereinafter referred to as switch configuration parameters). The switches related to the dynamic restart function are those used by the user to enable or disable the dynamic restart function. The function configuration management module can push dynamic configuration parameters to the terminal device. After the terminal device loads the dynamic configuration parameters, it will have the dynamic restart function. After loading the switch configuration parameters, the terminal device's interface will display the switches related to the dynamic restart function, allowing the user to control whether the dynamic restart function is enabled or disabled. Of course, the function configuration management module can also push messages or data to the terminal device to cancel the dynamic restart function.

[0091] The device whitelist refers to the list of terminal devices for which the dynamic restart function is to be pushed.

[0092] The remote server may include a function configuration module and a remote log collection and control module. The function configuration module is used to save and manage dynamic configuration parameters, device whitelists, etc., configured in the function configuration management module. The remote log management module is used to control terminal devices to collect logs and manage the collected logs.

[0093] Optionally, the configuration server can run the Wiser Opera platform. The configuration server may include a fault file configuration module. This module provides developers with access to and archiving of fault configuration files, and provides an interface for terminal devices to download these files.

[0094] The fault analysis server is used to receive and manage logs and / or dump files reported by terminal devices. Optionally, the fault analysis server can also perform intelligent analysis of terminal device faults, or it can send logs and / or dump files to a front-end server, which then displays the logs and / or dump files to developers for fault analysis and problem localization.

[0095] The software architecture of the terminal device will be described next. The software system of the terminal device may include the main system running on the AP and subsystems running on other processors. These subsystems may include at least one of the following: ADSP subsystem, CDSP subsystem, modem subsystem, and WLAN subsystem.

[0096] The main system running on the AP can adopt a layered architecture, event-driven architecture, microkernel architecture, microservice architecture, or cloud architecture. This application uses a layered architecture Android system as an example for illustration. A layered architecture divides the software into several layers, each with a clear role and division of labor. Layers communicate with each other through software interfaces. In some embodiments, the Android system is divided into four layers, from top to bottom: the application layer 210, the application framework layer 220, the hardware abstraction layer 230, and the kernel layer 240.

[0097] Application layer 210 may include a series of application packages. For example... Figure 3 As shown, the application package may include applications for log collection and fault monitoring, as well as a terminal-side parsing module. The log collection application is used to remotely collect system operation logs and application operation logs from terminal devices. Optionally, the remote log collection method may include two methods: user-initiated feedback (hereinafter referred to as user-initiated feedback) and remote active collection (hereinafter referred to as active collection). In this embodiment, the log collection application may obtain user privacy authorization before collecting logs. Optionally, the log collection application may be, for example, an "intelligent detection" system.

[0098] The fault monitoring application is used to collect fault data (e.g., dump files) from the terminal device software system and report it to the server, so that the server can improve and refine the software program and update the software version based on the fault data. In this application example, the fault monitoring application can be used to carry some or all of the dynamic restart function. For example, the fault monitoring application can be used to display the on / off switch of the dynamic restart function to the user and receive the user's control operation on the switch, and control the dynamic restart function to be turned on or off based on the user's control operation. Another example is that the fault monitoring application can be used to download fault configuration files from the configuration server. Optionally, the fault monitoring application can be, for example, "Hiview" or "Beta Club".

[0099] The edge-side parsing module is used to parse the fault configuration file (also known as the second file), and to verify the software version information and device model information corresponding to the parsed fault configuration file (also known as the first file). After the verification is successful, the preset error message in the parsed fault configuration file is sent to the configuration file receiving module in the subsystem.

[0100] Of course, the application layer 210 may also include applications such as camera, gallery, calendar, call, map, navigation, WLAN, Bluetooth, music, video, and SMS. Figure 3 Not shown in the image.

[0101] The application framework layer 220 provides application programming interfaces (APIs) and programming frameworks for applications in the application layer. The application framework layer includes some predefined functions.

[0102] like Figure 3 As shown, the application framework layer 220 may include a sensor service for providing sensor data and related services to upper layers (such as the application layer 210). An audio service is used to provide audio processing services to upper layers. A charging service is used to provide charging-related data and services, such as battery level data, to upper layers.

[0103] Of course, the application framework layer 220 may also include a window manager, content provider, view system, phone manager, resource manager, notification manager, etc. Figure 3 (Not shown in the image).

[0104] The hardware abstraction layer (HAL) 230 is used to abstract and encapsulate the hardware functions provided by the terminal device. For example... Figure 3 As shown, the hardware abstraction layer 230 may include a sensor hardware abstraction layer (SHA), an audio hardware abstraction layer (AHA), and a charging hardware abstraction layer (Charger HAL). The sensor hardware abstraction layer provides a unified sensor data interface to the upper layers (such as the application framework layer 220) to provide sensor data and related services. The audio hardware abstraction layer provides a unified audio data interface to the upper layers to provide audio processing services. The charging hardware abstraction layer provides a unified charging control interface to the upper layers to provide charging-related data and services, including power data.

[0105] Kernel layer 240, also known as kernel driver layer 240, is the layer between hardware and software. For example... Figure 3 As shown, kernel layer 240 may include a subsystem management module, which is used to report dump files generated when a subsystem fails to the fault analysis server. Optionally, the subsystem management module is also used to handle system faults, including determining whether to control the subsystem to restart or control the entire machine to restart, based on the subsystem's fault handling results when a subsystem fails.

[0106] In addition, kernel layer 240 may also include display drivers, camera drivers, audio drivers, sensor drivers, etc. Figure 3 Not shown in the image.

[0107] The architecture of the ADSP subsystem is described below.

[0108] In one embodiment, the subsystem running on the ADSP can be a real-time operating system (RTOS). The RTOS can also employ a layered architecture. Specifically, the RTOS may include a kernel layer 250.

[0109] Kernel layer 250 may include a configuration file receiving module and a recovery decision module. The configuration file receiving module is used to receive and save preset error message information sent by the end-side parsing module on the AP side. Optionally, the configuration file receiving module can communicate with the end-side parsing module on the AP side based on the QMI communication mechanism.

[0110] The recovery decision module, upon process crash, determines whether to use PDR or SSR restart based on the fault configuration file and sends a dump file to the subsystem management file on the AP side. Optionally, the recovery decision module can communicate with the subsystem management file on the AP side based on the QMI communication mechanism.

[0111] For ease of understanding, the following embodiments of this application will be described using the following methods: Figure 2 and Figure 3 Taking the terminal device with the structure shown as an example, and in conjunction with the accompanying drawings and application scenarios, the subsystem fault handling method provided in this application embodiment will be specifically described.

[0112] The method provided in this embodiment mainly involves four stages: 1. Privacy authorization stage; 2. Function push stage; 3. Fault configuration file download and storage stage; 4. Fault handling stage. In the privacy authorization stage, the electronic device authorizes the user to collect data such as logs and dump files. In the function push stage, developers can push dynamic configuration parameters to the terminal device through the server. After receiving the dynamic configuration parameters, the terminal device can run the dynamic configuration parameters to enable dynamic restart functionality. In the fault configuration file download and storage stage, the terminal device downloads the fault configuration file from the configuration server, parses it, and stores it in the subsystem. In the fault handling stage, when a process in the subsystem crashes, the subsystem decides whether to use PDR (Process Reset) or SSR (Solution Reset) restart based on the stored fault configuration file.

[0113] The specific implementation process of the above four stages will be explained below.

[0114] 1. Privacy Authorization Stage

[0115] It is understood that during the fault handling phase of this application embodiment, the cloud side needs to obtain PDR dump files or SSR dump files. Additionally, to more accurately and comprehensively locate and analyze problems, the cloud side can also remotely collect logs from terminal devices. In this embodiment, before collecting logs, dump files, and other data (collectively referred to as operational data) from terminal devices, the user can be informed and their authorization for collecting operational data (also known as privacy authorization) can be obtained to fully guarantee the security of user privacy and improve user experience.

[0116] Optionally, privacy authorization can be triggered by remote log collection, which can be triggered by configuration operations performed by developers on the front-end server. Furthermore, as mentioned above, the methods for remotely collecting terminal device logs on the cloud side can include both proactive collection and autonomous feedback. Therefore, privacy authorization can include two parts: authorization for proactively collected operational data and authorization for autonomously fed-back operational data. These will be explained separately below with reference to the accompanying drawings.

[0117] Figure 4 This is a flowchart illustrating an example system fault handling method provided in an embodiment of this application. During the privacy authorization phase, the method includes:

[0118] S101. In response to the configuration operations of the R&D personnel, the function configuration management module in the front-end server sends the dynamic configuration parameters and device whitelist to the function configuration module in the remote server.

[0119] Configuration operations refer to setting dynamic configuration parameters and device whitelists on the configuration webpage. Specifically, Ares Ocean, running on the front-end server, can display the configuration webpage to developers. Developers can configure dynamic configuration parameters and device whitelists based on the configuration webpage. Dynamic configuration parameters include, but are not limited to, software version information, device model information, and switch configuration parameters.

[0120] In one specific embodiment, the dynamic restart function can be enabled and disabled through two switches: a function switch (also known as a property switch or log switch, etc.) and a fault file switch. The fault file switch triggers the download of the fault configuration file. The function switch controls the start and end of the dynamic restart function process. The dynamic restart function can only execute normally when both the function switch and the fault file switch are enabled.

[0121] It is understandable that the device model information and software version information in the dynamic configuration parameters are used to characterize the terminal devices to which that set of dynamic configuration parameters applies. In other words, each set of dynamic configuration parameters applies to a specific version of the software system on a particular terminal device. Developers can configure multiple sets of dynamic configuration parameters, and the software version information or device model information in different sets can be different.

[0122] The device whitelist is a list of terminal devices for which the dynamic restart function will be pushed. In other words, the cloud side pushes the dynamic restart function to terminal devices in the device whitelist. Optionally, the device whitelist includes one or more device identifiers. The device identifier is used to uniquely identify the terminal device, such as a serial number or IMEI. It can be understood that the more device identifiers in the device whitelist, the more terminal devices will have the dynamic restart function loaded, resulting in more fault-related data being acquired subsequently, which will greatly help in improving the software version. Developers can update the device whitelist to control the push of the dynamic configuration function to different terminal devices, thereby collecting fault data from different devices and further improving the software system.

[0123] For example, Figure 5 This example illustrates a configuration webpage in a front-end server. Figure 5 As shown, the configuration webpage 501 includes a set of dynamic configuration parameters. These parameters include device model, software version, and switch configuration parameters. The switch configuration parameters can include switch ID, switch name, switch type, and default switch state. Switch types include function switches and fault file switches. The default switch state refers to the switch's default state after the configuration parameters are loaded onto the terminal device. Optionally, both function switches and fault file switches can be set to "off" by default. This allows users to actively turn the switches on, preventing actions that contradict user intent and improving user experience. Optionally, the fault file switch configuration parameters can also include fault configuration file information. This information is used by the terminal device to download the fault configuration file from the configuration server. It can be understood that different device model and software version information in the dynamic configuration parameters correspond to different fault configuration file information. In other words, there is a correspondence between the fault configuration file information and the device model and software version information. Optionally, the fault configuration file information may include, but is not limited to, the file name, ID, and encryption / decryption method of the fault configuration file.

[0124] S102. The function configuration module in the remote server stores dynamic configuration parameters and device whitelists.

[0125] It should be understood that the front-end server provides a visual interface for developers and receives user input data. The remote server, as a supporting device for the front-end server, provides back-end services for data storage, processing, management, and configuration.

[0126] S103. The function configuration module in the remote server sends a configuration completion message to the function configuration management module in the front-end server. The configuration completion message indicates that the dynamic configuration parameters and device whitelist have been configured successfully.

[0127] The function configuration module sends a configuration completion message to the front-end server. On the one hand, the front-end server can display a relevant prompt interface to inform the developers that the configuration has been completed. On the other hand, after receiving the configuration completion message, the front-end server can trigger the push of dynamic configuration parameters to the terminal devices in the device whitelist. For details, please refer to the relevant content of the function push stage in the subsequent embodiments.

[0128] S104. The function configuration module in the remote server sends a configuration completion message to the remote log collection and control module.

[0129] After configuration, the terminal device can execute the process of actively collecting logs, as detailed in steps S105 to S109 below.

[0130] S105. After receiving the configuration completion message, the remote log collection control module sends remote log collection commands to the log collection applications of each terminal device in the device whitelist. The remote log collection commands instruct the terminal devices to collect and report logs.

[0131] S106. After receiving the remote log collection command, the log collection application displays an authorization request pop-up window 1. The authorization request pop-up window 1 displays authorization request information 1, which is used to request the user to authorize the remote server to actively collect the operating data of the terminal device.

[0132] For example, Figure 6 This is a schematic diagram of an example of a request for authorization pop-up window provided in an embodiment of this application. Figure 6 As shown, taking the log collection application "Intelligent Detection" as an example, after receiving a remote log collection command, the Intelligent Detection application can display an authorization request pop-up window 601. As shown, the authorization request pop-up window 601 displays authorization request information 1. In addition, the authorization request pop-up window 601 can also include an "Agree to Authorization" control 6011 and a "Disagree" control 6012. If the user clicks the "Agree to Authorization" control 6011, steps S107 to S109 are executed; if the user clicks the "Disagree" control 6012, steps S107 to S109 are not executed, and the Intelligent Detection application can send an authorization failure message 1 to the remote log management module and the fault monitoring application. The authorization failure message 1 indicates that authorization from the user for remote active collection of runtime data has not been obtained.

[0133] It should be noted that in this embodiment, different authorization request pop-ups are distinguished by adding numbers such as 1 and 2 after the request authorization pop-up, without limiting the number or format of pop-ups. Other names are similar and will not be elaborated further. Furthermore, the authorization request pop-up is merely an example of interface display and is not intended to limit the scope. In practical applications, log collection applications can also display authorization request information in other forms, such as bubbles, banners, capsules, etc. Other pop-ups are similar and will not be elaborated further.

[0134] S107. In response to the user's authorization operation 1, the log collection application sends an authorization success message 1 (also known as authorization information) to the fault monitoring application. The authorization success message 1 indicates that the user's authorization for actively collecting runtime data has been obtained.

[0135] The first action to grant authorization is, for example, clicking by the user. Figure 6 The “Agree to Authorize” control 6011 in the middle.

[0136] The fault monitoring application receives authorization success message 1 and can save it.

[0137] S108, The log collection application collects log 1.

[0138] Optionally, log 1 can be the system runtime log.

[0139] S109. The log collection application reports the collected log 1 to the remote log management module on the remote server.

[0140] It should be noted that steps S108 and S109 can be performed continuously; that is, the log collection application continuously collects logs and continuously reports the collected logs to the remote server. The remote log management module on the remote server saves the logs reported by the log collection application.

[0141] Alternatively, the terminal device can also execute the autonomous feedback log process, as detailed in steps S110 to S114 below. It should be noted that in this embodiment, the active log collection process shown in steps S105 to S109 and the autonomous feedback log process shown in steps S110 to S114 can both be executed, or one can be selected for execution. Furthermore, the execution order of the active log collection process and the autonomous feedback log process is not limited; they can be executed sequentially or simultaneously.

[0142] S110. When the log collection application detects a fault in the application on the terminal device, it displays a self-feedback query pop-up.

[0143] Specifically, the log collection application can monitor the running status of applications on the terminal device. When an application malfunctions, the log collection application will display a self-feedback prompt window, asking the user whether they want to report the problem.

[0144] For example, Figure 7 This is a schematic diagram illustrating the interface changes of a user-generated feedback log, provided as an embodiment of this application. For example... Figure 7 As shown in Figure (a), when a malfunction is detected in an application, the log collection application can display a self-inquiry pop-up window 701. The self-inquiry pop-up window 701 may include a "Feedback" control 7011 and a "No Feedback" control 7012. If the user clicks the "Feedback" control 7011, steps S111 to S114 are executed. If the user clicks the "No Feedback" control 7012, the current self-inquiry log process ends.

[0145] S111. In response to the user's action of agreeing to provide feedback independently, the log collection application displays an authorization request pop-up window 2. The authorization request pop-up window 2 displays authorization request information 2, which requests the user to authorize the independent feedback of the terminal device's operating data to the remote server.

[0146] Please continue reading Figure 7 Responding to user clicks Figure 7 The "Agree Feedback" control 7011 in Figure (a) is displayed on the terminal device as follows: Figure 7 The authorization request pop-up window 702 is shown in Figure (b). As shown, the authorization request pop-up window 702 includes an authorization request message 2, as well as an "Agree to Authorize" control 7021 and a "Disagree" control 7022. If the user clicks the "Agree to Authorize" control 7021, the terminal device executes the following steps S112 to S114. If the user clicks the "Disagree" control 7022, the terminal device does not execute steps S112 to S114, and may send an authorization failure message 2 to the fault monitoring application. The authorization failure message 2 indicates that the user's authorization for the autonomous feedback operation data has not been obtained.

[0147] S112. In response to the user's authorization operation 2, the log collection application sends an authorization success message 2 (also known as authorization information) to the fault monitoring application. The authorization success message 2 indicates that the user's authorization for autonomous feedback operation data has been obtained.

[0148] For example, the action to grant authorization is clicking. Figure 7 The “Agree to Authorize” control 7021 in Figure (b).

[0149] The fault monitoring application receives authorization success message 2 and can save it.

[0150] S113, The log collection application collects log 2.

[0151] Optionally, log 2 can be the runtime log of the application that failed.

[0152] S114. The log collection application reports the collected log 2 to the remote log management module on the remote server.

[0153] It should be noted that, unlike steps S108 and S109, steps S113 and S114 can be executed once for each application failure triggered by the user's authorized operation 2, and can be discontinued.

[0154] The remote log management module in the remote server can save the logs reported by the log collection application.

[0155] 2. Feature rollout phase

[0156] Optionally, the feature push phase can be triggered by a configuration completion message sent by a remote server. It is understood that the steps in the feature push phase can be executed synchronously with steps S105 to S114 in the privacy authorization phase described above, or they can be executed before or after these steps; there is no limitation on this.

[0157] For example, Figure 8 A flowchart illustrating another example of a system fault handling method provided in this application embodiment is shown below. Figure 8 As shown, during the feature push phase, the method includes:

[0158] S201. After receiving the configuration completion message sent by the remote server, the function configuration management module in the front-end server pushes dynamic configuration parameters that match the device model and software version to the fault monitoring application of each terminal device in the device whitelist.

[0159] Optionally, the front-end server can pre-store the device signal information and software version information of each device in the device whitelist. Based on this, the function configuration management module in the front-end server can determine a set of dynamic configuration parameters that are consistent with the device model and software version of each device in the device whitelist, and then send the set of dynamic configuration parameters to that device.

[0160] For example, in the first set of dynamic configuration parameters, the device model information is a1 and the software version information is a2. In the second set of dynamic configuration parameters, the device model information is b1 and the software version information is b2.

[0161] The device whitelist includes the device identifiers of device a, device b, and device c. Device a has a device signal of a1 and a software version of a2; device b has a device model of b1 and a software version of b2; and device c has a device model of a1 and a software version of a2. Therefore, the function configuration management module sends the first set of dynamic configuration parameters to devices a and c, and the second set of dynamic configuration parameters to device b.

[0162] Optionally, the front-end server can establish a two-way data channel with the terminal device. Through the two-way channel, dynamic configuration parameters can be pushed to the terminal device, and the terminal device can also send loading results back to the front-end server.

[0163] S202, The fault monitoring application in the terminal device loads dynamic configuration parameters.

[0164] It is understood that after the fault monitoring application loads the dynamic configuration parameters, it will have a dynamic restart function, including but not limited to: the fault monitoring application interface has a function switch and a fault file switch; in response to the function switch and the fault file switch being turned on, the fault monitoring application downloads the fault configuration file and sends the fault configuration file to the subsystem; in response to the function switch or the fault file switch being turned off, the fault monitoring application deletes the fault configuration file in the subsystem, etc.

[0165] 3. Fault configuration file download and saving stage

[0166] The download and saving of the fault configuration file can be triggered by activating a function switch and a fault file switch. In one embodiment, activating the function switch and the fault file switch can be done by the R&D personnel issuing an activation command from the front-end server, which is then sent to the fault monitoring application on the terminal device via a remote server. Upon receiving the activation command, the fault monitoring application activates the function switch and the fault file switch, thereby triggering the download and saving of the fault configuration file.

[0167] In another embodiment, the function switch and fault file switch can also be actively activated by the user. Optionally, after loading the dynamic configuration parameters, the fault monitoring application can proactively pop up an interface for setting the switch status, allowing the user to choose whether to activate the function switch and fault file switch. Of course, the fault monitoring application may also choose not to proactively pop up the interface for setting the switch status, but instead allow the user to activate them voluntarily when needed.

[0168] For example, Figure 9 This is a schematic diagram illustrating the interface changes during a switch state setting process, as provided in an embodiment of this application. Taking the fault monitoring application "Beta" as an example, as... Figure 9As shown in Figure (a), the homepage of the terminal device includes an icon 901 for the Beta application. In response to a user clicking on icon 901, the terminal device displays the homepage interface 902 of the Beta application, as shown... Figure 9 As shown in Figure (b), the homepage interface 902 includes a "My" control 9021. In response to the user's click on the "My" control 9021, the terminal device displays the "My" interface 903, as shown... Figure 9 As shown in Figure (c), the "My" interface 903 includes a "Log Switch" option 9031. In response to the user's selection of the "Log Switch" option 9031, the terminal device displays a "Log Switch" list interface 904 (also known as the first interface), as shown... Figure 9 As shown in Figure (d), the "Log Switch" list interface 904 displays information about relevant log switches in the terminal device, including information about function switches 9041 and fault file switches 9042. The function switch information 9041 includes function switch control 90411, which is in the off state in the figure. Users can turn the function switch on and off by clicking function switch control 90411. The fault file switch information 9042 includes fault file switch control 90421, which is in the off state in the figure. Users can turn the function switch on and off by clicking fault file switch control 90421.

[0169] If the fault monitoring application detects that both the function switch and the fault file are enabled, it triggers the process of downloading and saving the fault configuration file. See details below. Figure 8 Steps S203 to S216 in the process.

[0170] It's understandable that users might activate the function switch first, then the fault file switch, or vice versa. The following explanation will use the example of a user activating the function switch first.

[0171] S203. In response to the user turning on the function switch, the fault monitoring application determines whether the privacy authorization is successful; if the privacy authorization is unsuccessful, proceed to step S204; if the privacy authorization is successful, proceed to step S207.

[0172] Specifically, when the fault monitoring application detects that the user has activated a function switch, it can determine whether an authorization success message (e.g., authorization success message 1 or authorization success message 2) has been saved. If the authorization success message has been saved, step S207 is executed; otherwise, step S204 is executed.

[0173] S204. The fault monitoring application sends a request for authorization instruction to the log collection application. The request for authorization instruction is used to instruct the log collection application to obtain the user's privacy authorization.

[0174] S205. The log collection application responds to the authorization request instruction and displays the authorization request pop-up window 1.

[0175] S206. In response to the authorization grant operation 1, the log collection application sends an authorization success message 1 to the fault monitoring application. The authorization success message 1 indicates that the user's authorization for actively collecting runtime data has been obtained.

[0176] Of course, after receiving the user's consent to the operation 1, the log collection application can further collect logs and report them to the remote server. For details, please refer to steps S106 to S109 in the privacy authorization stage, which will not be repeated here.

[0177] After receiving the authorization success message from the log collection application, the fault monitoring application executes the following step S207.

[0178] S207. The fault monitoring application determines whether the fault file switch is in the on state; if yes, then execute step S208 and subsequent steps; if no, then do not execute S208 and subsequent steps.

[0179] In this step, there are three situations where the fault file switch is in the on state: First, the fault file switch is in the on state by default; second, the fault monitoring application detects that the user has turned on the fault file switch; third, the user did not turn off the fault file switch when it was turned on last time.

[0180] S208. The fault monitoring application parses the switch configuration parameters of the fault file switch and obtains information from the fault configuration file.

[0181] As described in the above embodiment, the switch configuration parameters for the fault file switch include information about the fault configuration file. This information includes the fault configuration file's name, ID, encryption method, etc. Based on this information, the corresponding fault configuration file can be retrieved from the configuration server.

[0182] It is understood that the configuration files and parameters sent from the cloud to the terminal device are formatted data. By parsing this data, information that can be recognized by the terminal device can be obtained. In this embodiment, the name, ID, encoding / decoding method, etc. of the fault file are obtained by parsing the switch configuration parameters of the fault file switch.

[0183] S209. The fault monitoring application sends a file download request to the fault file configuration module in the configuration server. The file download request is used to request the download of the fault configuration file, and the file download request carries the information of the fault configuration file.

[0184] S210, the fault file configuration module in the configuration server responds to the file download request by sending a fault configuration file that matches the information of the fault configuration file carried in the file download request to the fault monitoring application.

[0185] Specifically, the configuration server can pre-configure fault configuration files corresponding to various device models and software versions. Each fault configuration file has a different name, ID, etc. After receiving a file download request, the configuration server queries the fault configuration file with the same name or ID as the fault configuration file in the file download request.

[0186] Optionally, the fault configuration file may include one or more sets of preset error messages. Each set of preset error messages is a collection of key information output when a process in the subsystem crashes. The error messages are used to indicate the generated error. Optionally, the error messages may include the error name or error identifier, the cause of the error, the error type, etc. The error messages can be a piece of code, a log, or a report, etc., without limitation. In a specific embodiment, the error messages may be the final message generated by the crashed process. It should be understood that each set of preset error messages is output by the subsystem under a specific fault condition. When the subsystem crashes due to this fault, the PDR dump file generated by PDR restart cannot locate the root cause of the process crash.

[0187] Taking the ADSP subsystem as an example, here are a few sets of preset error message messages:

[0188] 1. EF: qsh_process:0×4:cbworker0:0×1000002f:sdc_err_handler.c:105:Crash on SDC.

[0189] 2. EF: qsh_process:0×84:UTIMER_CLIENT_1:0×100042e:sns_watchdog.c:102:Priority worker thread exceeded processing time limit.

[0190] 3. EF: qsh_process:0×4:SNS_SEE_P_0_4:0×10000029:sns_es_process.c:263:0.

[0191] Taking the first set of error messages as an example, this error message indicates that the qsh process encountered an error and crashed on the SDC. The cause of the error is a problem on line 105 of the sdc_err_handler.c file. However, research revealed that in this type of failure, because the PDR dump file contains limited information, it is impossible to determine which function in line 105 of the sdc_err_handler.c file was called. Therefore, the root cause of the failure cannot be further determined, and the software cannot be modified or improved.

[0192] Optionally, preset error messages can be stored in a list or other format, without limitation. In addition to preset error messages, the fault configuration file may also include device model information and software version information of the devices to which the fault configuration file applies, as well as a data directory. The data directory is used to record and list the information in the fault configuration file.

[0193] S211. The fault monitoring application performs security and integrity checks on the fault configuration file.

[0194] This step improves the security and reliability of the fault configuration file by verifying its security and integrity, thereby increasing the success rate of subsequent fault handling.

[0195] S212, The fault monitoring application sends the fault configuration file to the end-side parsing module.

[0196] S213. The end-side parsing module parses the fault configuration file to obtain the parsed fault configuration file.

[0197] S214. The end-side parsing module verifies the device model information and software version information in the parsed fault configuration file.

[0198] Optionally, the endpoint parsing module can obtain the device model information and software version information of the current terminal device from a preset storage location or a preset application (such as a settings application). Then, the endpoint parsing module compares the device model information of the current terminal device with the device model information in the parsed fault configuration file (also known as the first device model information), and compares the software version information of the current terminal device with the software version information in the parsed fault configuration file (also known as the first software version information) to determine if they match. If both the device model information and the software version information match, the verification passes, and steps S215 and S216 are executed; if the verification fails, steps S215 and S216 are not executed.

[0199] By verifying the device model and software version, incorrect fault configuration files are prevented from being sent to the subsystem, thereby improving the accuracy and reliability of the algorithm.

[0200] S215, The end-side parsing module sends the preset error message from the parsed fault configuration file to the configuration file receiving module in the ADSP subsystem.

[0201] It is understandable that the edge parsing module can send one or more sets of preset error messages from the parsed fault configuration file to the configuration file receiving module in each subsystem, and the ADSP subsystem will be used as an example for explanation.

[0202] Optionally, the AP side and the ADSP subsystem can communicate via the Qualcomm Messaging Interface (QMI) channel. See details below. Figure 10 When sending preset error messages, the AP, acting as a QMI client, may include a QMI client interface; the ADSP subsystem, acting as a QMI server, may include a QMI server interface. The edge-side parsing module can send the preset error messages to the QMI client interface, which then sends them to the QMI server interface via the QMI communication channel. The QMI server interface then sends the preset error messages to the configuration file receiving module.

[0203] Optionally, before sending the preset error message, the AP can initialize the QMI client interface and wait for the subsystem's QMI server interface to start. After the QMI server interface starts, the preset error message is sent to the ADSP subsystem via the QMI communication channel. Correspondingly, after the ADSP subsystem starts the QMI server interface, it waits to receive QMI messages (or monitors QMI messages). When the QMI server interface receives the preset error message from the AP, it sends the preset error message to the configuration file receiving module, which then saves the preset error message to a circular queue.

[0204] S216, The configuration file receiving module in the ADSP subsystem saves preset error message information to a circular queue.

[0205] Preset error messages are saved to a circular queue, allowing for quick access by the subsystem's root process (root PD) and improving algorithm execution efficiency. Of course, this is just one example of a saving method; the subsystem can also use other methods to save preset error messages.

[0206] Following the above process, the fault configuration file is downloaded and saved to the subsystem, which means that the basic data for the dynamic restart function is pushed. The dynamic restart function can then be implemented based on this data.

[0207] In summary, the conditions for a terminal device to download and save a fault configuration file to the subsystem can include three: 1) the function switch is in the "on" state; 2) privacy authorization is successful; and 3) the fault file switch is in the "on" state. It should be noted that in the above steps, the sequential judgment of the above three conditions is triggered by the user's operation of turning on the function switch. In fact, in some other embodiments, the download of the fault configuration file can also be triggered by the user turning on the function switch, or by other means, such as triggering it after a preset time after the successful execution of dynamic configuration parameters. This application does not limit this. Furthermore, the order of judgment when determining whether the three conditions are met is not limited.

[0208] Another possible implementation is to associate the fault file switch with the function switch. Specifically, if the fault monitoring application detects that the user has enabled the fault file switch, the fault monitoring application will automatically enable the function switch. The user enabling the fault file switch indicates that the user likely needs to enable the dynamic restart function; therefore, associating the fault file switch with the function switch eliminates the need for the user to manually operate the function switch, simplifying the user experience.

[0209] The process of disabling the dynamic restart function for users is described below. In one embodiment, the subsystem fault handling method further includes:

[0210] 1) In response to the user turning off the function switch, the fault monitoring application sends a clear command to the end-side parsing module. The clear command is used to instruct the clearing of the fault configuration file.

[0211] 2) The end-side parsing module sends the clear command to the configuration file receiving module in the ADSP subsystem.

[0212] 3) The configuration file receiving module responds to the clear command and deletes the faulty configuration files in the circular queue.

[0213] Specifically, the configuration file receiving module deletes the fault configuration file, including various error messages and directory data. This way, when a process in a subsequent subsystem crashes, it cannot obtain the fault configuration file and therefore will no longer dynamically restart based on the preset error messages in the fault configuration file; in other words, the dynamic restart function is disabled.

[0214] 4. Troubleshooting Phase

[0215] The fault handling phase follows the privacy authorization and feature push phases. The fault handling phase is triggered by a process crash in the subsystem. In this embodiment, a sensor process crash in the ADSP subsystem is used as an example. It is understood that the ADSP subsystem may include a sensor module. The sensor module can run within a sensor process; in other words, the sensor module can perform services such as sensor data acquisition based on the sensor process. Therefore, the steps performed by the sensor module in the following process can also be understood as the steps performed by the sensor process.

[0216] For example, Figure 11 This is a flowchart illustrating another example of a system fault handling method provided in an embodiment of this application.

[0217] like Figure 11 As shown, in the fault handling phase, the method includes:

[0218] In the S301 ADSP subsystem, the sensor module performs tasks (such as collecting sensor data) through the sensor process.

[0219] S302. When the sensor process crashes, the sensor module obtains and saves the current error message.

[0220] After a sensor process crashes, the sensor module can call the error handling process (function) based on the sensor process to save the error message displayed when the process crashes.

[0221] S303, The sensor module calls the recovery decision module to handle errors.

[0222] Optionally, the recovery decision module can run within the root process; in other words, the recovery decision module can implement its functionality based on the root process. Therefore, the steps performed by the recovery decision module in the following steps can also be understood as the steps being performed by the root process.

[0223] S304. The recovery decision module responds to the call from the sensor module and determines whether there is a preset error message in the circular queue. If there is a preset error message in the circular queue, steps S305 to S313 are executed. If there is no preset error message in the circular queue, step S314 is executed.

[0224] S305. If a preset error message exists in the circular queue, the recovery decision module determines whether there is a preset error message that is consistent with the current error message. If it exists, steps S306 to S309 (SSR process) are executed; if it does not exist, steps S310 to S313 (PDR process) are executed.

[0225] In other words, the recovery decision module compares the current error message with each preset error message to determine if a matching error message exists. If a matching error message exists, it means the PDR dump file generated by process restart cannot accurately locate and analyze the problem. Therefore, a subsystem restart (i.e., PDR to SSR) is selected to resolve the fault while obtaining a more comprehensive dump file, facilitating accurate problem location and analysis by developers. If no matching error message exists, it means the PDR dump file generated by process restart can accurately locate and analyze the problem. Therefore, a process restart (i.e., continuing to use PDR) is selected. This not only quickly restores the faulty process but also prevents impact on other processes in the subsystem. For example, restarting the sensor process without restarting the ADSP subsystem prevents impact on the charger and audio processes, thus preventing disruption to the user's normal use of charging and audio playback functions and improving the user experience.

[0226] S306. Restore the decision module and restart the ADSP subsystem.

[0227] S307, The recovery decision module generates an SSR dump file.

[0228] S308, the recovery decision module sends the SSR dump file to the subsystem management module on the AP side.

[0229] S309. The subsystem management module reports the SSR dump file to the fault analysis server.

[0230] S310, Restore Decision Module restarts sensor process.

[0231] S311, The recovery decision module generates a PDR dump file.

[0232] S312, The recovery decision module sends the PDR dump file to the subsystem management module on the AP side.

[0233] It is understandable that the recovery decision module runs in the root process, and therefore can control the execution, termination, and restart of various processes in the subsystem. For example, Figure 12 The diagram illustrates the relationship between the root process and other processes in the ADSP subsystem. It shows that the root process can interact with the sensor, audio, and charger processes, respectively, and thus can control and manage these processes, including their creation, termination, and restart. Furthermore, the root process can also control its own restart, thereby restarting the subsystem.

[0234] S313, The subsystem management module reports the PDR dump file to the fault analysis server.

[0235] As an optional implementation, after receiving the PDR and SSR dump files, the subsystem management module can further monitor the recovery status of the ADSP subsystem to ensure its normal operation. Specifically, after either SSR or PDR is executed, the recovery decision module in the ADSP can send the recovery result to the subsystem management module on the AP side. The recovery result indicates whether the recovery was successful (i.e., a successful restart) or failed (i.e., a failed restart).

[0236] In the case of PDR (Process Recovery Decision), i.e., after step S310 above, if the subsystem management module receives a process recovery failure message from the recovery decision module, the subsystem management module further sends an SSR (Solution Reset Decision) restart command to the recovery decision module. The recovery decision module responds to the SSR restart command and restarts the subsystem.

[0237] In the case of SSR, i.e. after S306 above, if the subsystem management module receives a subsystem recovery failure message sent by the recovery decision module, the subsystem management module restarts the terminal device, i.e., the entire machine is restarted.

[0238] In other words, the subsystem management module can decide whether to proceed with a further restart process based on the restart result of the subsystem.

[0239] In addition, after the subsystem management module reports the SSR dump file and / or PDR dump file to the fault analysis server, the front-end server can access the SSR dump file and / or PDR dump file and display it to the R&D personnel for analysis and troubleshooting. This allows the R&D personnel to locate technical problems, resolve them, and improve the software program of the terminal device. This is of great significance for software version development, especially for the BETA (β) version troubleshooting phase.

[0240] S314. If there is no preset error message in the circular queue, the recovery decision module determines whether the PDR switch (also known as the third switch) is in the open state. If the PDR switch is in the open state, the PDR process shown in steps S310 to S311 is executed. If the PDR switch is in the closed state, the SSR process shown in steps S306 to S309 is executed.

[0241] It's understandable that as the software program is continuously modified and improved, the dynamic restart function can be removed following the process described in the function rollout phase, or the function switch can be turned off. In short, the dynamic restart function can be disabled. With the dynamic restart function disabled, the subsystem can determine whether to use SSR or PDR restart based on the PDR switch status, ensuring proper handling of subsystem faults.

[0242] In summary, the fault handling method provided in this embodiment, by pre-saving a fault configuration file to the subsystem, includes preset error messages corresponding to faults where PDR cannot accurately locate the problem, allows for comparison of the current error message with the preset error message when a process in the subsystem crashes. Based on the comparison result, SSR is selectively triggered; otherwise, PDR is used. This approach effectively balances the advantages and disadvantages of PDR and SSR, taking into account the convenience of software system improvements and the impact on other processes, thereby enhancing the user experience.

[0243] The foregoing has detailed examples of subsystem fault handling methods provided in the embodiments of this application. It is understood that, in order to implement the above functions, the terminal device includes hardware and / or software modules corresponding to the execution of each function. Those skilled in the art should readily recognize that, based on the units and algorithm steps of the examples described in conjunction with the embodiments disclosed herein, this application can be implemented in hardware or a combination of hardware and computer software. Whether a function is executed by hardware or by computer software driving hardware depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application in conjunction with the embodiments, but such implementation should not be considered beyond the scope of this application.

[0244] This application embodiment can divide the terminal device into functional modules according to the above method example. For example, each function can be divided into a separate functional module, such as a detection unit, a processing unit, a display unit, etc., or two or more functions can be integrated into one module. The integrated module can be implemented in hardware or as a software functional module. It should be noted that the module division in this application embodiment is illustrative and only represents one logical functional division. In actual implementation, there may be other division methods.

[0245] It should be noted that all relevant content of each step involved in the above method embodiments can be referenced from the functional description of the corresponding functional module, and will not be repeated here.

[0246] The terminal device provided in this embodiment is used to execute the above-mentioned subsystem fault handling method, and therefore can achieve the same effect as the above-mentioned implementation method.

[0247] When using integrated units, the terminal device may further include a processing module, a storage module, and a communication module. The processing module is used to control and manage the actions of the terminal device. The storage module supports the execution of stored program code and data by the terminal device. The communication module supports communication between the terminal device and other devices.

[0248] The processing module can be a processor or a controller. It can implement or execute various exemplary logic blocks, modules, and circuits described in conjunction with the disclosure of this application. The processor can also be a combination that implements computing functions, such as a combination of one or more microprocessors, a digital signal processor (DSP), and a microprocessor, etc. The storage module can be a memory. The communication module can specifically be a radio frequency circuit, a Bluetooth chip, a Wi-Fi chip, or other devices that interact with other terminal devices.

[0249] In one embodiment, when the processing module is a processor and the storage module is a memory, the terminal device involved in this embodiment can be a device having... Figure 2 The device with the structure shown.

[0250] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, causes the processor to perform the subsystem fault handling method of any of the above embodiments.

[0251] This application also provides a computer program product that, when run on a computer, causes the computer to perform the aforementioned steps to implement the subsystem fault handling method in the above embodiments.

[0252] In addition, embodiments of this application also provide an apparatus, which may specifically be a chip, component or module. The apparatus may include a connected processor and a memory. The memory is used to store computer execution instructions. When the apparatus is running, the processor can execute the computer execution instructions stored in the memory to cause the chip to execute the subsystem fault handling methods in the above-described method embodiments.

[0253] In this embodiment, the terminal device, computer-readable storage medium, computer program product or chip are all used to execute the corresponding methods provided above. Therefore, the beneficial effects that can be achieved can be referred to the beneficial effects in the corresponding methods provided above, and will not be repeated here.

[0254] Through the above description of the embodiments, those skilled in the art will understand that, for the sake of convenience and brevity, only the division of the above functional modules is used as an example. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above.

[0255] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another apparatus, or some features may be ignored or not executed. Furthermore, the mutual coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0256] The units described as separate components may or may not be physically separate. A component shown as a unit can be one or more physical units; that is, it can be located in one place or distributed in multiple different locations. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0257] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0258] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a readable storage medium. Based on this understanding, the technical solutions of the embodiments of this application, in essence, or the parts that contribute to the prior art, or all or part of the technical solutions, can be embodied in the form of a software product. This software product is stored in a storage medium and includes several instructions to cause a device (which may be a microcontroller, chip, etc.) or processor to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0259] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A subsystem fault handling method, wherein the method is executed by a terminal device, characterized in that, The terminal device includes a first processor, in which a first subsystem runs, and in which a first process runs. The method includes: When the first process crashes, the current error message is obtained; the error message is used to indicate the error that occurred in the process. If a first file exists in the terminal device, it is determined whether a target error message exists in the first file; the first file includes one or more sets of preset error message information, and the target error message information refers to the preset error message information that is consistent with the current error message information; If the target error message exists in the first file, then restart the first subsystem and generate the first dump file; If the target error message is not present in the first file, the first process is restarted to generate a second dump file.

2. The method according to claim 1, characterized in that, The terminal device further includes an application processor (AP), and the method further includes: The AP acquires the first file; The AP sends one or more sets of preset error message information from the first file to the first processor through the QMI communication channel; The first processor stores one or more sets of preset error message information.

3. The method according to claim 2, characterized in that, The AP obtains the first file, including: In response to the first switch being turned on, if it is determined that there is authorization information and the second switch is in the on state, the AP parses the configuration parameters of the second switch to obtain the information of the second file; the authorization information indicates that the user has agreed to obtain the operating data of the terminal device, the configuration parameters of the second switch are pushed to the terminal device by the front-end server, and the second file is an unparsed configuration file that matches the device model and software version information of the terminal device; A download request is sent to the configuration server; the download request carries information about the second file. Receive the second file sent by the configuration server; Perform security and integrity checks on the second file; The second file is parsed to obtain the first file.

4. The method according to claim 3, characterized in that, In response to the first switch being turned on, if it is determined that authorization information exists and the second switch is in the on state, before the AP parses the configuration parameters of the second switch to obtain the information of the second file, the method further includes: The AP receives the target configuration parameters pushed by the front-end server, and the target configuration parameters include the switch configuration parameters of the first switch and the switch configuration parameters of the second switch; The AP loads the target configuration parameters; The AP displays a first interface; the first interface includes the first switch and the second switch.

5. The method according to claim 2, characterized in that, The first file includes first device model information and first software version information; the AP sends one or more sets of preset error message information from the first file to the first processor via the QMI communication channel, including: The AP determines whether the first device model information is consistent with the device model information of the terminal device, and whether the first software version information is consistent with the software version information of the terminal device; If they match, the AP sends one or more sets of preset error message information to the first processor through the QMI communication channel.

6. The method according to claim 2, characterized in that, The first processor stores the one or more sets of preset error message information, including: The first processor saves one or more sets of preset error message information to a circular queue; If a first file exists in the terminal device, determining whether a target error message exists in the first file includes: The first processor retrieves one or more sets of preset error message information from the circular queue. If the one or more sets of preset error message information exist in the circular queue, the first processor determines whether the target error message information exists in the one or more sets of preset error message information.

7. The method according to claim 6, characterized in that, The method further includes: If the circular queue does not contain one or more sets of preset error message information, the first processor determines whether the state of the third switch is on. If the third switch is in the open state, the first processor restarts the first sub-process; If the third switch is in the off state, the first processor restarts the first subsystem.

8. The method according to claim 6, characterized in that, The first subsystem also runs a root process, and the first processor determines whether the target error message exists in one or more sets of preset error message messages, including: The root process determines whether the target error message exists in one or more sets of preset error message messages; The restarting of the first subsystem includes: The first subsystem is restarted via the root process.

9. The method according to any one of claims 1 to 8, characterized in that, The method further includes: Receive log collection commands sent by a remote server; In response to the log collection command, a second interface is displayed. The second interface includes authorization request information, which is used to request the user to authorize the acquisition of the terminal device's operating data. In response to the user's consent to authorization on the second interface, the logs of the terminal device are obtained; The logs are reported to the remote server.

10. The method according to any one of claims 1 to 8, characterized in that, The first processor is an application digital signal processor (ADSP), and the first subsystem is an ADSP subsystem; or, the first processor is a computational digital signal processor (CDSP), and the first subsystem is a CDSP subsystem; or, the first processor is a modem, and the first subsystem is a modem subsystem; or, the first processor is a wireless local area network (WLAN) processor, and the first subsystem is a WLAN subsystem.

11. A terminal device, characterized in that, The terminal device includes: one or more processors, and a memory; the one or more processors include a first processor; The memory is coupled to the one or more processors, the memory being used to store computer program code, the computer program code including computer instructions, the one or more processors invoking the computer instructions to cause the terminal device to perform the method as described in any one of claims 1 to 10.

12. A fault handling system, characterized in that, The fault handling system includes: A front-end server, a configuration server, a remote server, and a terminal device as described in claim 11.

13. A chip system, characterized in that, The chip system is applied to a terminal device, the chip system including one or more processors, the one or more processors including a first processor; the one or more processors are used to invoke computer instructions to cause the terminal device to perform the method as described in any one of claims 1 to 10.

14. A computer-readable storage medium, characterized in that, The computer-readable storage medium includes instructions that, when executed on a terminal device, cause the terminal device to perform the method as described in any one of claims 1 to 10.

Images