A method, system and terminal device for analyzing subsystem crash

Abstract

The present invention belongs to the field of mobile terminals. The present invention provides a method, system and terminal device for analyzing a subsystem crash. The method includes the following steps: burying points in the kernel layer of the subsystem so as to obtain burying point data when the subsystem crashes; receiving attribute data packets, selecting corresponding dump files for saving, and analyzing the subsystem crash. By obtaining the memory file when the subsystem crashes, the cause of the subsystem crash is analyzed, and some subsystem anomalies that are difficult to reproduce in user devices are solved. At the same time, the terminal device does not need to be sent back for recurrence, which reduces the after-sales maintenance cost.

Description

Technical Field

[0001] The present invention relates to the field of mobile terminals, and in particular to a method, system and terminal equipment for analyzing a subsystem crash. Background Art

[0002] For Android devices with more and more functions, in addition to the often mentioned CPU, DDR, Disk and TP, there are also various subsystem modules, such as Wifi-related modules (wcnss subsytem), communication-related modules (modem subsytem) and Sensor-related modules (adsp subsytem). When analyzing Android system crashes, we inevitably encounter kernel panics caused by the crash of these subsystems. Generally, the proportion of such subsystem crashes in user devices is higher because the use of these subsystems is more easily affected by user usage scenarios. For example, the three commonly used subsystems, wcnss, modem and adsp, are easily affected by factors such as the complex local network and communication environment.

[0003] There are currently two methods for analyzing such subsystem crash problems: one is that when the user device reports such anomalies, since there is no on-site testing, the only way is to send the machine back and arrange testers to reproduce it according to the user's usage scenario, but such subsystem crash problems are generally difficult to reproduce after being sent back; the other is to remotely obtain the DDR ramdump of the user device through the network when such anomalies occur on the user device, but as the DDR of Android devices is getting larger and larger (the DDR of mobile phones has reached 12G), if all ramdumps on the DDR of the user device are directly captured remotely (equivalent to the size of DDR), obtaining such a large amount of data will inevitably have a great impact on the user's data traffic, and the overhead of obtaining it through the network platform is relatively large. Therefore, it is very necessary to solve the above problems. Summary of the invention

[0004] The invention provides a method, system and terminal equipment for solving the problem of analysis subsystem crash.

[0005] The technical solution provided by the present invention is as follows:

[0006] In one aspect, the present invention provides a method for analyzing a subsystem crash, comprising the following steps:

[0007] Tracking at the kernel layer of the subsystem to obtain tracking data when the subsystem crashes;

[0008] Receive the attribute data packet, select the corresponding dump file to save, and use it to analyze the subsystem crash.

[0009] Further preferably, before the embedding point in the kernel layer of the subsystem so that the terminal device obtains the embedding point data when the subsystem crashes, the method further includes the following steps:

[0010] Set the restart level of each subsystem in the user version of the terminal device to related.

[0011] Further preferably, after setting the restart level of each subsystem of the user version in the terminal device to related, the method further includes the following steps:

[0012] When the restart level of the subsystem is set to related and a crash occurs, the subsystem restarts.

[0013] Further preferably, after setting the restart level of each subsystem of the user version in the terminal device to related, the method further includes the following steps:

[0014] When the restart level of each subsystem is set to related and the subsystem crashes, a dump file of the subsystem is generated.

[0015] Further preferably, the embedding point at the kernel layer of the subsystem so that the terminal device obtains the embedding point data when the subsystem crashes comprises the steps of:

[0016] The embedded point of the kernel layer is transmitted to the interface function of the framework layer through the Android JNI communication;

[0017] Inserting the buried point data into the launcher database through the frawork layer interface function;

[0018] The embedded point data is sent to the web page in real time through the launcher database.

[0019] Further preferably, the receiving of the attribute data packet and the selection of the corresponding dump file for saving for analyzing the subsystem crash include the steps of:

[0020] Utilize the attribute data packet to parse and obtain attributes and attribute values;

[0021] According to the attribute and the attribute value, select and save the dump file of the subsystem;

[0022] The dump file includes a memory file when the subsystem crashes.

[0023] Further preferably, the receiving of the attribute data packet and the selection of the corresponding dump file for saving for analyzing the subsystem crash include the steps of:

[0024] Receiving the attribute data packet, the terminal device turns on the dump file collection switch of the subsystem;

[0025] When the subsystem crashes again, the dump file of the subsystem is automatically collected based on the attribute data packet for analyzing the crash of the subsystem.

[0026] Further preferably, after receiving the attribute data packet and selecting the corresponding dump file to save for analyzing the subsystem crash, the method includes the following steps:

[0027] After the dump files are collected, the dump files are compressed to generate a compressed dump file;

[0028] Save the dump compressed file and delete the dump file.

[0029] A terminal device is applied to the method for analyzing the crash of the subsystem.

[0030] A system for analyzing a subsystem crash, comprising the terminal device and a web page;

[0031] The web page is used to send an attribute data packet for turning on the dump file collection switch of the subsystem according to the buried data, so that the terminal device selects the corresponding dump file to save for analyzing the subsystem crash.

[0032] The present invention provides a method, system and terminal device for analyzing a subsystem crash, which have at least the following beneficial effects:

[0033] 1) By setting the restart level of the subsystem to related, when a subsystem crashes, the system will not crash. The corresponding subsystem will restart automatically in the background. When a subsystem fails, it will not affect the user's daily use.

[0034] 2) After setting the restart level to related, an elf file of the corresponding subsystem will be generated when a crash occurs. These elf files can also be used to analyze the cause of the subsystem crash and solve some difficult-to-reproduce subsystem anomalies in the user's device. The device does not need to be sent back for recurrence, reducing after-sales maintenance costs. BRIEF DESCRIPTION OF THE DRAWINGS

[0035] The present invention is further described in detail below in conjunction with the accompanying drawings and specific embodiments:

[0036] Figure 1It is a flow chart of an embodiment of a method for analyzing a subsystem crash of the present invention;

[0037] Figure 2 It is a flow chart of another embodiment of a method for analyzing a subsystem crash in the present invention;

[0038] Figure 3 It is a flow chart of another embodiment of a method for analyzing a subsystem crash in the present invention;

[0039] Figure 4 It is a flow chart of another embodiment of a method for analyzing a subsystem crash in the present invention. DETAILED DESCRIPTION

[0040] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative work.

[0041] In order to simplify the drawings, only the parts related to the present invention are schematically shown in each figure, and they do not represent the actual structure of the product. In addition, in order to simplify the drawings and facilitate understanding, in some figures, only one of the parts with the same structure or function is schematically drawn or marked. In this article, "one" not only means "only one", but also means "more than one".

[0042] It should be further understood that the term “and / or” used in the specification and appended claims refers to any combination and all possible combinations of one or more of the associated listed items, and includes these combinations.

[0043] In this document, it should be noted that, unless otherwise clearly specified and limited, the terms "installed", "connected", and "connected" should be understood in a broad sense, for example, it can be a fixed connection, a detachable connection, or an integral connection; it can be a mechanical connection or an electrical connection; it can be a direct connection, or it can be indirectly connected through an intermediate medium, or it can be the internal communication of two components. For ordinary technicians in this field, the specific meanings of the above terms in the present invention can be understood according to specific circumstances.

[0044] In addition, in the description of the present application, the terms "first", "second", etc. are only used to distinguish the description and cannot be understood as indicating or implying relative importance.

[0045] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the specific implementation methods of the present invention will be described below with reference to the accompanying drawings. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings and other implementation methods can be obtained based on these drawings without creative work.

[0046] like Figure 1 As shown, the present invention provides an embodiment of a method for analyzing a subsystem crash, comprising the following steps:

[0047] In one aspect, the present invention provides a method for analyzing a subsystem crash, comprising the following steps:

[0048] S100 embeds points at the kernel layer of the subsystem so as to obtain embedding data when the subsystem crashes.

[0049] Specifically, the terminal device includes user devices such as mobile phones and watches for Android systems, and the subsystem includes Wifi-related modules (wcnss subsytem), communication-related modules (modem subsytem) and Sensor-related modules (adspsubsytem).

[0050] For example, when a subsystem crash occurs, a big data point report is performed, that is, when a subsystem crash occurs, it will be reported to the big data platform on the web side.

[0051] S200 receives the attribute data packet, selects a corresponding dump file to save, and is used for analyzing the subsystem crash.

[0052] Specifically, the web platform, that is, the big data platform on the web side, pushes an attribute value to the user device and turns on a switch for collecting the subsystem dump file.

[0053] For example, through the attributes and attribute values ​​set by the web platform, the web platform sends the set fields (attributes and attribute values) through the network, and the terminal device receives the fields sent by the web end using the server through the network, and then parses the received fields, and selects the corresponding subsystem dump file by corresponding attributes and attribute values. The dump file here refers to the memory file when each subsystem is abnormal when analyzing the subsystem crash problem.

[0054] In this embodiment, some subsystem anomalies that are difficult to reproduce in user devices are resolved. At the same time, the user device does not need to be sent back for reproduction, reducing after-sales maintenance costs. When a subsystem anomaly occurs, it does not affect the user's daily use.

[0055] Embodiment 2

[0056] The present invention provides a method for analyzing a subsystem crash, such as Figure 2 As shown, the following steps are included:

[0057] Before the step S100 of burying points in the kernel layer of the subsystem so as to obtain buried point data when the subsystem crashes, the step S100 further includes:

[0058] S000 sets the restart level of each subsystem of the user version in the terminal device to related.

[0059] Specifically, the restart level of the subsystem is set to related. The purpose of this is to prevent the system from crashing when the subsystem is abnormal. The corresponding subsystem will restart automatically in the background. After setting the restart level to related, an elf file of the corresponding subsystem will be generated when a crash occurs. These elf files can also be used to analyze the cause of the subsystem crash.

[0060] The system itself sets two levels (system and related) for subsystem restart. The default subsystem restart level is system, but we need to set the level to related here. The purpose is to collect only the elf files when the corresponding subsystem crashes.

[0061] After the system level is set, when a subsystem is abnormal, the entire system will be abnormal, and the subsystem elf file cannot be collected, and users will not be able to use the system normally. Although in this case, the ramdump of the entire memory can be collected (when the entire system crashes at a certain point in time, the information of this part of the software when it crashes is saved in the memory), the size is consistent with the DDR size of the corresponding device, and the memory data is very large. When analyzing the abnormality of the subsystem, the entire ramdump file needs to be analyzed, which is very inefficient.

[0062] In this embodiment, the restart level of each subsystem is set to the related level. When an exception occurs in a subsystem in the system, only the subsystem will restart itself, and the entire system will not be abnormal and cause a restart, so it will not affect the user's normal use of this system. At the same time, the elf file of the subsystem with abnormality can be collected, and the size of the collected file is much smaller than the size of the ramdump.

[0063] In this case, this embodiment sets the restart level to the related level to ensure that when a subsystem crashes, only the corresponding subsystem is restarted, and the entire system will not be restarted. On the one hand, the normal operation of the system can be guaranteed, and the user experience is improved; on the other hand, the size of the collected files in this case is much smaller than the size of the ramdump file generated when the entire system is restarted, making the subsequent subsystem abnormality analysis more efficient and faster.

[0064] Preferably, the step S100 of burying points at the kernel layer of the subsystem so as to obtain buried point data when the subsystem crashes comprises the steps of:

[0065] The buried point data of the kernel layer are transmitted to the interface function of the framework layer through the android JNI communication; the buried point data are inserted into the launcher database through the framework layer interface function; the buried point data are sent to the web page in real time through the launcher database.

[0066] Preferably, the receiving of the attribute data packet and the selection of the corresponding dump file for saving for analyzing the subsystem crash include the following steps:

[0067] Utilize the attribute data packet to parse and obtain attributes and attribute values; select and save the dump file of the subsystem according to the attributes and the attribute values; wherein the dump file includes the memory file when the subsystem crashes.

[0068] Preferably, the receiving of the attribute data packet and the selection of the corresponding dump file for saving for analyzing the subsystem crash include the following steps:

[0069] The terminal device receives the attribute data packet and turns on the dump file collection switch of the subsystem; when the subsystem crashes again, the dump file of the subsystem is automatically collected based on the attribute data packet for analyzing the crash of the subsystem.

[0070] Specifically, after the subsystem crash occurs for the first time, the web platform has provided the attribute data packet, i.e., the attributes and attribute values, to the terminal device, so that the collection switch of the subsystem elf file is turned on. When the subsystem of the Android system in the terminal device crashes again, the dump file in the elf format can be directly collected.

[0071] In this embodiment, the dump file collection switch is turned on by generating an attribute data packet in advance, so that the dump file can be automatically collected when a subsystem crashes later, thereby improving the efficiency of analyzing the cause of the subsystem crash.

[0072] Preferably, after receiving the attribute data packet and selecting the corresponding dump file to save for analyzing the subsystem crash, the method includes the following steps:

[0073] After the dump files are collected, the dump files are compressed to generate a compressed dump file; the compressed dump file is saved, and the dump file is deleted.

[0074] In this embodiment, by compressing the dump file, the storage space can be reduced, and the cache space is saved, so as to avoid the dump file being unable to be completely saved due to insufficient cache space.

[0075] Embodiment 3

[0076] The present invention provides a method for analyzing a subsystem crash, such as Figure 3 As shown, the following steps are included:

[0077] When a subsystem crash occurs, set the restart level of the user version to related.

[0078] Specifically, before a subsystem crash occurs, the restart level setting for the user version is set to related by default, and the default setting for the debug version is set to system.

[0079] Among them, the User version generally refers to the software version officially released to users; debug generally refers to the informal software version used for development and debugging.

[0080] For example, after the User version subsystem restart level is set to related, when the subsystem crashes, it will not affect the entire Android system. The system will still run normally, and the subsystem will restart itself in the background without causing the entire system to restart. In terms of user experience, the user is completely unaware of the machine abnormality, and the subsystem restart process generally does not affect the user's use of other functions. The purpose of setting the relate level is to restart only some subsystems when the system crashes, rather than restarting all subsystems.

[0081] When a subsystem crash occurs, big data point reporting is performed, that is, when a subsystem crash occurs, it will be reported to the big data platform on the web.

[0082] Specifically, when a subsystem crash occurs, the kernel layer of the Android system is usually used to track the crash, and the kernel layer tracking is transmitted to the framework layer interface function of the Android system through Android JNI communication. The framework layer interface function inserts the uploaded data into the launcher database, and finally the launcher sends it to the web end in real time through the network (wifi or data traffic).

[0083] The web platform pushes a property value to the user device and turns on the switch for collecting the subsystem dump file (elf file).

[0084] Specifically, through the attributes and attribute values ​​set by the web platform, the web platform sends the set fields (attributes and attribute values) through the network, and the terminal device receives the fields sent by the web end through the network, and then parses the received fields, and selects the corresponding subsystem dump file by corresponding attributes and attribute values. The dump file here refers to the memory file when each subsystem is abnormal when analyzing the subsystem crash problem. The file format is elf file.

[0085] When the subsystem crashes again on this machine, the subsystem dump file will be automatically collected. In order to reduce the user space occupied, the elf file will be compressed before saving.

[0086] The compression mechanism is as follows: after each dump file is collected, it will be compressed and the original file will be deleted immediately, leaving only the compressed file.

[0087] Developers use the web client to pull the subsystem dump file through the network and then analyze it.

[0088] Since there is a list of devices reporting subsystems on the web platform every day, when a subsystem crash occurs again, you can use the anonymous account of the web platform to pull the dump file through the network. Because this method is mainly based on user devices, it is usually pulled through the network. Of course, you can also obtain it by local adb pull file.

[0089] In this embodiment, the present invention can analyze subsystem crash devices that are difficult to reproduce on the market, solve the difficulties currently encountered in analyzing such problems, and can meet the key dump logs required by developers to analyze crashes without excessively wasting user data traffic.

[0090] The default subsystem restart level of a general device is system. When a subsystem crashes, it will cause kernel panic and the entire machine will be suspended. The user device will experience a complete machine restart. In addition to all ramdumps through DDR, the elf file of a specific subsystem can also be used for analysis. The method of the present invention is to set the restart level of each subsystem in the Android system to related when a subsystem crashes, so that when a subsystem is abnormal, it will not cause a system crash, and the corresponding subsystem will automatically restart in the background. After setting the restart level to related, an elf file of the corresponding subsystem will be generated when a crash occurs. The cause of the subsystem crash can also be analyzed through these elf files.

[0091] Embodiment 4

[0092] Based on the above embodiments, Figure 4 As shown, the parts in this embodiment that are the same as those in the above embodiment will not be described one by one. This embodiment provides an embodiment of a method for analyzing a subsystem crash, which specifically includes the following steps:

[0093] Before the step S100 of burying points in the kernel layer of the subsystem so as to obtain buried point data when the subsystem crashes, the step S100 further includes:

[0094] S000 sets the restart level of each subsystem of the user version in the terminal device to related.

[0095] Specifically, the restart level of the subsystem is set to related. The purpose of this is to prevent the system from crashing when the subsystem is abnormal. The corresponding subsystem will restart automatically in the background. After setting the restart level to related, an elf file of the corresponding subsystem will be generated when a crash occurs. These elf files can also be used to analyze the cause of the subsystem crash.

[0096] Preferably, after setting the restart level of each subsystem of the user version in the terminal device to related in step S000, the method further includes the following steps:

[0097] S001: When the restart level of the subsystem is set to related and a crash occurs, the subsystem restarts.

[0098] Preferably, after setting the restart level of each subsystem of the user version in the terminal device to related in step S000, the method further includes the following steps:

[0099] S002: When the restart level of each subsystem is set to related and the subsystem crashes, a dump file of the subsystem is generated.

[0100] Specifically, since the system includes many subsystems, the restart level of the subsystem is set to related. When a subsystem crashes, that is, when a subsystem is abnormal, it will not cause all subsystems to crash. Only the corresponding subsystem will restart automatically in the background. After setting the restart level to related, the elf file of the corresponding subsystem will be generated when a crash occurs. These elf files can also be used to analyze the cause of the subsystem crash.

[0101] S100 embeds points at the kernel layer of the subsystem so as to obtain embedding data when the subsystem crashes.

[0102] Specifically, the terminal device includes user devices such as mobile phones and watches for Android systems, and the subsystem includes Wifi-related modules (wcnss subsytem), communication-related modules (modem subsytem) and Sensor-related modules (adspsubsytem).

[0103] For example, when a subsystem crash occurs, a big data point report is performed, that is, when a subsystem crash occurs, it will be reported to the big data platform on the web side.

[0104] S200 receives the attribute data packet, selects a corresponding dump file to save, and is used for analyzing the subsystem crash.

[0105] Specifically, the web platform, that is, the big data platform on the web side, pushes an attribute value to the user device and turns on a switch for collecting the subsystem dump file.

[0106] For example, through the attributes and attribute values ​​set by the web platform, the web platform sends the set fields (attributes and attribute values) through the network, and the terminal device receives the fields sent by the web terminal through the network, and then parses the received fields, and selects the corresponding subsystem dump file by corresponding attributes and attribute values. The dump file here refers to the memory file when each subsystem is abnormal when analyzing the subsystem crash problem.

[0107] In this embodiment, some subsystem anomalies that are difficult to reproduce in user devices are resolved. At the same time, the user device does not need to be sent back for reproduction, reducing after-sales maintenance costs. When a subsystem anomaly occurs, it does not affect the user's daily use.

[0108] Embodiment 5

[0109] The present invention provides a terminal device, which is applied to the method for analyzing the crash of the subsystem.

[0110] Specifically, the terminal device includes user devices such as mobile phones, watches, and tablets that use the Android system.

[0111] The terminal device is used to set the restart level of each subsystem of the user version in the terminal device to related, so that the subsystem that crashes is restarted.

[0112] The terminal device is used to transmit the buried point of the kernel layer to the interface function of the framwork layer through the android JNI communication; insert the buried point data into the launcher database through the framwork layer interface function; and send the buried point data to the web page in real time through the launcher database.

[0113] The terminal device is used to parse the attribute data packet to obtain attributes and attribute values; according to the attributes and the attribute values, a dump file of the subsystem is selected and saved; wherein the dump file includes a memory file when the subsystem crashes.

[0114] The terminal device is used to receive attribute data packets, and the terminal device turns on the dump file collection switch of the subsystem; when the subsystem crashes again, the dump file of the subsystem is automatically collected based on the attribute data packets for analyzing the subsystem crash.

[0115] Specifically, after the subsystem crash occurs for the first time, the web platform has provided the attribute data packet, i.e., the attributes and attribute values, to the terminal device, so that the collection switch of the subsystem elf file is turned on. When the subsystem of the Android system in the terminal device crashes again, the dump file in the elf format can be directly collected.

[0116] In this embodiment, the dump file collection switch is turned on by generating an attribute data packet in advance, so that the dump file can be automatically collected when a subsystem crashes later, thereby improving the efficiency of analyzing the cause of the subsystem crash.

[0117] In the receiving attribute data packet, a corresponding dump file is selected to be saved for analyzing the subsystem crash, and the terminal device is used to compress the dump file to generate a dump compressed file after collecting the dump file; save the dump compressed file, and delete the dump file.

[0118] In this embodiment, by compressing the dump file, the storage space can be reduced, and the cache space is saved, so as to avoid the dump file being unable to be completely saved due to insufficient cache space.

[0119] Embodiment 5

[0120] The present invention provides a system for analyzing a subsystem crash, comprising the terminal device and the web page end.

[0121] The web page is used to send an attribute data packet for turning on the dump file collection switch of the subsystem according to the buried data, so that the corresponding dump file can be selected for saving for analyzing the subsystem crash.

[0122] In this embodiment, a property data packet for turning on the dump file collection switch of the subsystem is sent through the web page according to the embedded data sent by the terminal device, so that the terminal device turns on the dump collection of the subsystem and selects the corresponding dump file to save for analyzing the subsystem crash.

[0123] For example, when a subsystem crash occurs, the restart level of the user version is set to related.

[0124] Specifically, before a subsystem crash occurs, the restart level setting for the user version is set to related by default, and the default setting for the debug version is set to system.

[0125] Among them, the User version generally refers to the software version officially released to users; debug generally refers to the informal software version used for development and debugging.

[0126] For example, after the User version subsystem restart level is set to related, when the subsystem crashes, it will not affect the entire Android system. The system will still run normally, and the subsystem will restart itself in the background without causing the entire system to restart. In terms of user experience, the user is completely unaware of the machine abnormality, and the subsystem restart process generally does not affect the user's use of other functions. The purpose of setting the relate level is to restart only some subsystems when the system crashes, rather than restarting all subsystems.

[0127] When a subsystem crash occurs, big data point reporting is performed, that is, when a subsystem crash occurs, it will be reported to the big data platform on the web.

[0128] Specifically, when a subsystem crash occurs, the kernel layer of the Android system is usually used to track the crash, and the kernel layer tracking is transmitted to the framework layer interface function of the Android system through Android JNI communication. The framework layer interface function inserts the uploaded data into the launcher database, and finally the launcher sends it to the web end in real time through the network (wifi or data traffic).

[0129] The web platform pushes a property value to the user device and turns on the switch for collecting the subsystem dump file (elf file).

[0130] Specifically, through the attributes and attribute values ​​set by the web platform, the web platform sends the set fields (attributes and attribute values) through the network, and the terminal device receives the fields sent by the web end through the network, and then parses the received fields, and selects the corresponding subsystem dump file by corresponding attributes and attribute values. The dump file here refers to the memory file when each subsystem is abnormal when analyzing the subsystem crash problem. The file format is elf file.

[0131] When the subsystem crashes again on this machine, the subsystem dump file will be automatically collected. In order to reduce the user space occupied, the elf file will be compressed before saving.

[0132] The compression mechanism is as follows: after each dump file is collected, it will be compressed and the original file will be deleted immediately, leaving only the compressed file.

[0133] Developers use the web client to pull the subsystem dump file through the network and then analyze it.

[0134] Since there is a list of devices reporting subsystems on the web platform every day, when a subsystem crash occurs again, you can use the anonymous account of the web platform to pull the dump file through the network. Because this method is mainly based on user devices, it is usually pulled through the network. Of course, you can also obtain it by local adb pull file.

[0135] In this embodiment, the present invention can analyze subsystem crash devices that are difficult to reproduce on the market, solve the difficulties currently encountered in analyzing such problems, and can meet the key dump logs required by developers to analyze crashes without excessively wasting user data traffic.

[0136] The default subsystem restart level of a general device is system. When a subsystem crashes, it will cause kernel panic and the entire machine will be suspended. The user device will experience a complete machine restart. In addition to all ramdumps through DDR, the elf file of a specific subsystem can also be used for analysis. The method of the present invention is to set the restart level of each subsystem in the Android system to related when a subsystem crashes, so that when a subsystem is abnormal, it will not cause a system crash, and the corresponding subsystem will automatically restart in the background. After setting the restart level to related, an elf file of the corresponding subsystem will be generated when a crash occurs. The cause of the subsystem crash can also be analyzed through these elf files.

[0137] In this embodiment, the present invention can analyze subsystem crash devices that are difficult to reproduce on the market, solve the difficulties encountered in analyzing such problems at present, and can not only meet the key dump logs required by developers to analyze crashes, but also not excessively consume user data traffic. The default subsystem restart level of general devices is system. After the subsystem crashes, it will cause kernel panic, the entire machine will be hung, and the performance of the user device end is the restart of the entire machine. In addition to all ramdumps through DDR, it can also be analyzed through the elf file of a specific subsystem. The method of the present invention is that when a subsystem crashes, the restart level of the subsystem is set to related, so that when the subsystem is abnormal, it will not cause a system crash, and the corresponding subsystem will restart automatically in the background. After the restart level is set to related, the elf file of the corresponding subsystem will be generated when a crash occurs. The cause of the subsystem crash can also be analyzed through these elf files.

[0138] Those of ordinary skill in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented with electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed with hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of this application.

[0139] In the embodiments provided in the present application, it should be understood that the disclosed devices and methods can be implemented in other ways. Exemplarily, the system embodiments described above are merely schematic. Exemplarily, the division of the modules or units is only a logical function division. There may be other division methods in actual implementation. Exemplarily, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be an indirect coupling or communication connection through some interfaces, devices or units, which can be electrical, mechanical or other forms.

[0140] The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0141] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The above integrated unit may be implemented in the form of hardware or in the form of software functional units.

[0142] It should be noted that the above embodiments can be freely combined as needed. The above is only a preferred embodiment of the present invention. It should be pointed out that for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the principle of the present invention, and these improvements and modifications should also be considered as the protection scope of the present invention.

Claims

1. A method for analyzing a subsystem crash, characterized in that: The following steps are involved: Tracking is performed at the kernel layer of the subsystem, so that tracking data can be obtained and reported to the big data platform on the web side when the subsystem crashes; the subsystem includes Wifi-related modules, communication-related modules, and Sensor-related modules; The receiving big data platform pushes the attribute data packet based on the received tracking data, and selects the corresponding dump file to save for analyzing the subsystem crash; The attribute data packet is used to turn on the dump file collection switch of the subsystem; Before embedding data in the kernel layer of the subsystem so that the terminal device can obtain embedding data when the subsystem crashes, the step further includes: Set the restart level of each subsystem in the user version of the terminal device to related; After setting the restart level of each subsystem of the user version in the terminal device to related, the method further includes the following steps: When the restart level of the subsystem is set to related and a crash occurs, the subsystem restarts.

2. The method for analyzing a subsystem crash according to claim 1, characterized in that: After setting the restart level of each subsystem of the user version in the terminal device to related, the method further includes the following steps: When the restart level of each subsystem is set to related and the subsystem crashes, a dump file of the subsystem is generated.

3. The method for analyzing a subsystem crash according to claim 1, characterized in that: The method of embedding points in the kernel layer of the subsystem so that the terminal device can obtain embedding data when the subsystem crashes includes the following steps: The embedded point of the kernel layer is transmitted to the interface function of the framework layer through the androidJNI communication; Inserting the buried point data into the launcher database through the framwork layer interface function; The embedded point data is sent to the web page in real time through the launcher database.

4. The method for analyzing a subsystem crash according to claim 1, characterized in that: The receiving big data platform selects a corresponding dump file to save based on the attribute data packet pushed by the received tracking data, so as to analyze the subsystem crash, including the steps of: Utilize the attribute data packet to parse and obtain attributes and attribute values; According to the attribute and the attribute value, select and save the dump file of the subsystem; The dump file includes a memory file when the subsystem crashes.

5. The method for analyzing a subsystem crash according to claim 1, characterized in that: The receiving big data platform selects a corresponding dump file to save based on the attribute data packet pushed by the received tracking data, so as to analyze the subsystem crash, including the steps of: Receiving the attribute data packet returned by the web page, the terminal device turns on the dump file collection switch of the subsystem; When the subsystem crashes again, the dump file of the subsystem is automatically collected based on the attribute data packet for analyzing the crash of the subsystem.

6. The method for analyzing a subsystem crash according to any one of claims 1 to 3, characterized in that: After the receiving big data platform selects a corresponding dump file to save based on the attribute data packet pushed by the received tracking data for analyzing the subsystem crash, the steps include: After the dump files are collected, the dump files are compressed to generate a compressed dump file; Save the dump compressed file and delete the dump file.

7. A terminal device, characterized in that: A method for analyzing a subsystem crash as claimed in any one of claims 1 to 6.

8. A system for analyzing a subsystem crash, characterized in that: comprising the terminal device as claimed in claim 7; The web page is used to send an attribute data packet for turning on the dump file collection switch of the subsystem according to the buried data, so that the terminal device selects the corresponding dump file to save for analyzing the subsystem crash.

Images