Provide application error data for use by third-party library development systems

Abstract

An example method includes: receiving, by an application server system from one or more client computing devices, application error data associated with at least one error that occurred during execution of at least one application; receiving mapping data that provides a mapping between (i) library-related source code of the application(s) and (ii) at least one third-party library from which the library-related source code was loaded during execution of the application(s); determining, based on the application error data and the mapping data, a match between the library-related source code and at least a portion of the application error data; attributing the at least one error to the at least one third-party library; generating library error data associated with the at least one third-party library; and sending the library error data to at least one third-party library development system.

Description

Background Art

[0001] Existing computing devices, including mobile computing devices, are configured to execute any number of different applications (e.g., mobile applications, games) over time. Various application developers may develop and distribute these applications using one or more application development systems, and these applications may then be executed by client computing devices associated with end users. In many cases, one or more centralized application servers may store the applications and corresponding metadata after they have been developed, and end users may download and use the applications on their respective client computing devices. Unfortunately, in some cases, any given application may encounter errors during its execution, and in some cases may even crash or abort execution based on the severity or type of error that occurred. Summary of the Invention

[0002] The present disclosure relates to providing one or more parts of application error data based on one or more errors occurring during the execution of one or more applications, for use by a third-party library development system that develops a third-party library used by these applications. According to the technology of the present disclosure, an application server system can be configured to process application error data associated with such errors occurring during the execution of at least one application on one or more client computing devices, and output at least a portion of such data included in library error data to the third-party library development system. In this way, library developers of one or more third-party libraries can receive and audit such library error data, which can be related to the execution of code related to the corresponding library used by the application or during execution. By auditing and analyzing the library error data, the third-party library developer and / or the third-party library development system can attempt to identify any coding faults or other problems in the third-party library that may cause runtime errors during the execution of the application.

[0003] In one example, a method includes receiving, by an application server system comprising one or more processors, application error data associated with at least one error occurring during execution of at least one application on the one or more client computing devices, the at least one error occurring during execution of at least one application on the one or more client computing devices, receiving, by the application server system, mapping data providing a mapping between (i) library-related source code of the at least one application and (ii) at least one third-party library from which the library-related source code was loaded during execution of the at least one application, determining, by the application server system, a match between the library-related source code and at least a portion of the application error data based on the application error data and the mapping data. The example method further includes, in response to determining the match, attributing, by the application server system, the at least one error occurring during execution of the at least one application to the at least one third-party library, generating, by the application server system, library error data associated with the at least one third-party library, wherein the library error data includes at least a portion of the application error data, and transmitting, by the application server system, the library error data to at least one third-party library development system that developed the at least one third-party library.

[0004] In another example, an application server system includes at least one processor and at least one computer-readable storage device configured to store instructions executable by the at least one processor to: receive application error data associated with at least one error from one or more client computing devices, the at least one error occurring during execution of at least one application on the one or more client computing devices; receive mapping data that provides a mapping between (i) library-related source code of the at least one application and (ii) at least one third-party library from which the library-related source code is loaded during execution of the at least one application; determine a match between the library-related source code and at least a portion of the application error data based on the application error data and the mapping data; in response to determining the match, attribute at least one error occurring during execution of the at least one application to the at least one third-party library; generate library error data associated with the at least one third-party library, wherein the library error data includes at least a portion of the application error data; and send the library error data to at least one third-party library development system that develops the at least one third-party library.

[0005] In another example, a computer-readable storage device stores instructions that, when executed, cause at least one processor to perform operations. The example operations include receiving application error data associated with at least one error from one or more client computing devices, the at least one error occurring during execution of at least one application on the one or more client computing devices; receiving mapping data that provides a mapping between (i) library-related source code of the at least one application and (ii) at least one third-party library from which the library-related source code is loaded during execution of the at least one application; determining a match between the library-related source code and at least a portion of the application error data based on the application error data and the mapping data. The example operations further include, in response to determining the match, attributing at least one error that occurred during execution of the at least one application to the at least one third-party library; generating library error data associated with the at least one third-party library, wherein the library error data includes at least a portion of the application error data; and sending the library error data to at least one third-party library development system that develops the at least one third-party library.

[0006] The details of one or more examples are set forth in the accompanying drawings and the description below. Other features, objects, and advantages of the disclosure will be apparent from the description and drawings, and from the claims. BRIEF DESCRIPTION OF THE DRAWINGS

[0007] Figure 1 is a block diagram illustrating an example distributed system including an application server system configured to process application error data for use by a third-party library development system in accordance with one or more aspects of the present disclosure.

[0008] Figure 2 is a block diagram illustrating another example distributed system including an application server system configured to process application crash report data for use by a third-party software development kit (SDK) development system in accordance with one or more aspects of the present disclosure.

[0009] Figure 3 is a block diagram illustrating an example application server system according to one or more aspects of the present disclosure.

[0010] Figure 4 is a conceptual diagram illustrating example stack trace data including library-related source code and application-related source code according to one or more aspects of the present disclosure.

[0011] Figure 5 is a conceptual diagram illustrating example mapping data that provides a mapping between one or more portions of library-dependent source code of an application and at least one third-party library from which the library-dependent source code is loaded during execution of the application, according to one or more aspects of the present disclosure.

[0012] Figure 6 is a conceptual diagram illustrating example stack trace data included in an SDK crash report provided to one or more SDK development systems according to one or more aspects of the present disclosure.

[0013] Figure 7 is a conceptual diagram illustrating another example of stack trace data included in an SDK crash report provided to one or more SDK development systems according to one or more aspects of the present disclosure.

[0014] Figure 8 is a conceptual diagram illustrating another example of stack trace data included in an SDK crash report provided to one or more SDK development systems according to one or more aspects of the present disclosure.

[0015] Figure 9 are screen shots illustrating example graphical user interfaces that may be displayed at one or more third-party library development systems based on data provided by an application server system in accordance with one or more aspects of the present disclosure.

[0016] Figure 10 is a screen shot illustrating another example graphical user interface that may be displayed at one or more third-party library development systems based on data provided by an application server system in accordance with one or more aspects of the present disclosure.

[0017] Figure 11 is a flow diagram illustrating example operations of an application server system according to one or more aspects of the present disclosure. DETAILED DESCRIPTION

[0018] Figure 1 is a block diagram illustrating an example distributed system 100 including an application server system configured to process application error data for use by a third-party library development system 132 according to one or more aspects of the present disclosure. Figure 1 In the example of FIG, system 100 includes an application server system 102, one or more application development systems 128, one or more third-party library development systems 132, and one or more client computing devices 140. Application server system 102, application development systems 128, third-party library development systems 132, and client computing devices 140 can be communicatively coupled to one another via one or more networks 126, which can include one or more wireless and / or wired networks.

[0019] The application server system 102, the application development system 128, and the third-party library development system 132 may each include one or more computing devices or servers, wherein each computing device or server includes one or more processors. The client computing device 140 may also include one or more processors. Examples of client computing devices 140 include, but are not limited to, mobile phones, tablet computers, personal digital assistants (PDAs), laptop computers, portable gaming devices, portable media players, wearable computing devices (e.g., watches, wrist-mounted computing devices, head-mounted computing devices), television platforms, or other types of computing devices. The application server system 102, the application development system 128, the third-party library development system 132, and the client computing device 140 may each include one or more communication units (such as Figure 3 ). These communication units can send data to and / or receive data from one or more other computing devices or systems. In some examples, the communication units support wireless and / or wired communication, and they can use any type of communication protocol to send and / or receive data.

[0020] As previously described, the client computing device 140 is configured to execute any number of one or more applications 104 (e.g., mobile applications, games) over time. Various application developers can use the application development system 128 to develop and distribute such applications 104, which can then be executed by the client computing device 140. In many cases, the application development system 128 can store local copies of the applications 104 and can also distribute copies of the applications 104 for storage on the application server system 102, such as Figure 1 As shown, an end user of the client computing device 140 can then download and execute an application 104 on the client computing device 140, where such an application 104 can be developed by any number of different application developers using the application development system 128. The application 104 can perform various functions or access one or more services for the client computing device 140. An email application, a camera application, a calendar application, a messaging application, a social media application, a travel application, a game application, a stock application, and a weather application are all examples of applications 104.

[0021] In some cases, one or more of the applications 104 may encounter an error during execution on the client computing device 140, and in some cases may even crash or abort execution based on the severity or type of error that occurred. In these cases, when an error or crash occurs during execution of an application on one or more client computing devices, the runtime system(s) of the client computing device 140 may generate an error report that is transmitted to one or more of the application server system 102 and / or application development system 128 associated with the application. In this manner, application developers of the application may receive and review these error reports via the application development system 128 in an effort to identify any coding glitches or other issues in the application that may have caused the runtime error on the client computing device 140.

[0022] In many cases, an application 104 includes both application-related source code and library-related source code. Application-related source code is typically source code developed specifically for the application 104 (e.g., by an application developer using the application development system 128). Library-related source code is typically library-based code that has been developed (e.g., by a library developer using the third-party library development system 132) to be incorporated into a third-party library 138, which can be incorporated into or otherwise used by various applications of the application 104. Therefore, a large portion of the source code for an application 104 may actually include library-related source code. Therefore, source code that causes an application 104 to encounter errors and crashes during execution may potentially include one or more portions of library-related source code included within the application 104.

[0023] Faults present in source code associated with such libraries may cause any application 104 that includes such code to encounter errors or even crash. Traditionally, and as described above, application error data 122 associated with any errors or crashes in applications 104 has only been provided to the application development system 128 on which these applications 104 are developed. However, this application error data 122 has not traditionally been provided to third-party library development systems 132 so that library developers can access this application error data 122 and evaluate whether any third-party libraries 138 developed by the library developers may be the cause of the application error or crash.

[0024] Thus, in accordance with the techniques of this disclosure, the application server system 102 can be configured to process application error data 122 associated with errors that occur during execution of one or more applications 104 on one or more client computing devices 140 and output at least a portion of this data, included in library error data 124, to a third-party library developer using the third-party library development system 132. In this manner, library developers of one or more third-party libraries 138 can receive and review such library error data 124, which may relate to the execution of library-related code from the third-party libraries 138 that is included for execution in the applications 104. By reviewing and analyzing the library error data 124, the third-party library developers and / or the third-party library development system 132 can attempt to identify any coding glitches or other problems in the third-party libraries 138 that may cause runtime errors during execution of the applications 104 on the client computing devices 140.

[0025] like Figure 1 As shown, and as described in further detail below, the application server system 102 includes various functional modules. These functional modules include a library error data generator 110, an application error handling module 120, and a library error reporting module 121. The library error data generator 110 includes a library attribution module 114, a cleaning module 116, a clustering module 118, and an optional deobfuscation module 112. These modules can perform the operations described herein individually or collectively using any combination of software, hardware, and / or firmware resident in and / or executed at the application server system 102. The application server system 102 can use one or more processors to execute these modules. In some cases, the application server system 102 can execute these modules as one or more virtual machines executing on the underlying hardware. In some cases, one or more of these modules can be executed as a service of the operating system or computing platform.

[0026] As will be described in further detail below, application error handling module 120 of application server system 102 may receive application error data 122 associated with at least one error that occurred during execution of one or more applications 104 on client computing device 140 from application error reporting module 142 of client computing device 140. Accordingly, application error reporting module 142 is configured to send such application error data 122 associated with the execution of one or more applications 104 to application error handling module 120 of application server system 102.

[0027] If one or more of the applications 104 experience a crash or other unexpected termination, the application error data 122 may include application crash report data associated with at least one error that caused the crash of one or more of the applications 104. The application crash report data may include stack trace data representing nested function calls of the applications 104, wherein at least a portion of the application crash report data includes at least a portion of the stack trace data. The nested function calls of the stack trace data are those calls that can lead, for example, from a program loader to a location where a crash occurred during the execution of the corresponding one or more applications 104. Figure 4 An example of such stack trace data is shown in FIG.

[0028] The application server system 102 also receives (e.g., from the application development system 128) mapping data 108 that provides a mapping between (i) library-related source code of the application 104 and (ii) at least one of the third-party libraries 138 from which the library-related source code is loaded during execution of the application 104. In some cases, the application development system 128 can provide application data 106 to the application server system 102, where the application data 106 can include metadata associated with the application 104. For example, the application data 106 can include mapping data 108. The application data 106 can also include other information associated with the application 104, such as application version number information, information associated with supported operating systems for the application 104 (e.g., version numbers of one or more operating systems), information associated with supported device type(s) of client computing devices, deobfuscation data or files associated with the application code 104, and the like.

[0029] The application server system 102 determines a match between library-related source code and at least a portion of the application error data 122 based on the application error data 122 and the mapping data 108. For example, the library attribution module 114 of the library error data generator 110 on the application server system 102 can determine the match. When the application error data 122 provided by the application error reporting module 142 includes stack trace data, the library attribution module 114 can be configured to determine the match based on the stack trace data and the mapping data 108 by matching one or more patterns of the library-related source code to one or more code locations in at least a portion of the stack trace data. As a result, the library attribution module 114 can identify a mapping between code in the application 104 and any third-party libraries 138 from which the code was loaded. This mapping provides a mechanism by which the library attribution module 114 determines whether the stack trace traverses any third-party library-related source code, enabling the library attribution module 114 to attribute one or more errors (e.g., application crashes) to the identified third-party libraries 138.

[0030] In response to determining a match, library attribution module 114 may attribute at least one error that occurred during execution of application 104 to at least one third-party library included in third-party libraries 138. Library attribution module 114 may then generate library error data 124 associated with the at least one third-party library, where library error data 124 includes at least a portion of application error data 122. For example, if application error data 122 includes application crash report data, library error data 124 may include library crash report data that includes at least a portion of the application crash report data.

[0031] After the library attribution module 114 generates the library error data 124, the library error reporting module 121 of the application server system 102 then sends the library error data 124 to one or more of the third-party library development systems 132 that develop at least one third-party library via the network 126. The at least one third-party library is included in the third-party libraries 138. For example, the library error reporting module 121 can send the library error data 124 to one or more library console interfaces 134 of or associated with the third-party library development system 132. In some examples, the library console interface 134 can store the library error data 124 locally on the third-party library development system 132. The library console interface 134 can also output the library error data 124 for display on one or more display devices 130, such as Figures 9 to 10 In some examples, display device 130 may include one or more of a liquid crystal display (LCD), a dot matrix display, a light emitting diode (LED) display, an organic light emitting diode (OLED) display, a micro light emitting diode (microLED) display, an active matrix organic light emitting diode (AMOLED) display, electronic ink, or a similar monochrome or color display capable of outputting visible information to a third party developer using third party library development system 132.

[0032] In some examples, library error reporting module 121 may include or provide an application programming interface (API) called by library console interface 134 to output library error data 124 for display at display device 130. Application server system 102 may be configured to transmit library error data 124 to third-party library development system 132 via library error reporting module 121. Third-party library development system 132 may execute library console interface 134 to provide a graphical user interface (e.g., in a browser) that can output library error data 124 for display to one or more developers using display device 130. In some cases, library console interface 134 may include executable code that is provided by application server system 102 to third-party library development system 132 for execution.

[0033] In some cases, the third-party library development system 132 may also store library data 136, which may include metadata associated with the third-party library 138. For example, as will be seen in FIG. Figure 2 As further described, library data 136 may include deobfuscated data that may be used by optional deobfuscation module 112 of application server system 102 to deobfuscate one or more portions of application error data 122 (e.g., stack trace data) received from client computing device 140, and this deobfuscated data may then be used by library error data generator 110 to generate library error data 124. This deobfuscated data is associated with library-related source code of application 104. In some cases, application data 106 provided to application server system 102 by application development system 128 may also include deobfuscated data that may be used by deobfuscation module 112 to deobfuscate one or more portions of application error data 122, where this deobfuscated data is associated with application-related source code of application 104.

[0034] In many cases, the application error data 122 (e.g., stack trace data) provided by the application error reporting module 142 may include application-specific data of the application 104 and / or sensitive internal data associated with the application 104. In addition, the application error data 122 may have variability associated with execution errors of multiple different ones of the applications 104, because different applications may utilize the potentially faulty library-related source code in different contexts. Furthermore, in some cases, the application error data 122 may include indications of multiple different third-party library-related source code of a third-party library. Therefore, in these cases, the library error data generator 110 may determine to remove one or more portions of the application error data 122 when generating the library error data 124 that is provided to the third-party library development system 132.

[0035] For example, the cleanup module 116 of the library error data generator 110 can be configured to remove all application-related information (e.g., application-related source code) from the application error data 122 when generating the library error data 124. As a result, the third-party library development system 132 does not receive any such application-related information in the library error data 124 for use or display by the library console interface 134.

[0036] For situations where the application error data 122 includes library-related source code for a plurality of different third-party libraries of the third-party libraries 138 developed by the third-party library development system 132, the cleanup module 116 may also be configured to remove one or more portions of such library-related source code when generating the library error data 124, such as source code related to any library that is not associated with the identified third-party library that the library attribution module 114 attributes to the current error. For example, the application error data 122 may have at least a portion of data including source code related to a first library associated with a first third-party library in the third-party libraries 138, and may also have at least a portion of data including source code related to a second library associated with a second third-party library in the third-party libraries 138. If the library attribution module 114 attributes at least one error associated with the application error data 122 to the first third-party library, the cleanup module 116 may remove the second library-related source code from the application error data 122 (e.g., stack trace data) when generating the library error data 124. Figures 7 to 8 As shown in the picture.

[0037] like Figure 1 As shown, library error data generator 110 also includes a clustering module 118. As will be described in further detail below, in various examples, clustering module 118 can be configured to cluster portions of application error data 122 (e.g., stack trace data) that may be generated by a plurality of different applications 104 developed by application development system 128. These applications 104 may be developed by different application developers. The clustered portions of application error data 122 may include clusters or aggregated groups of different application error reports, e.g., having similar characteristic features. Because application error reporting modules 142 of client computing devices 140 are each configured to provide application error data 122 to application server system 102, application server system 102 may be able to aggregate and cluster such data into library error data 124 when the application error data 122 is associated with errors that occurred during the execution of potentially multiple different applications 104 developed by different application developers. Thus, library developers developing third-party libraries 138 can view such aggregated and / or clustered information regarding the libraries they develop via library console interface 134.

[0038] For example, if multiple different applications 104 developed by multiple different application developers each include a potentially faulty third-party library included in a third-party library 138 provided by a third-party library development system 132, one or more of these applications 104 may experience similar errors or crashes during execution. Consequently, when errors occur in such applications 104, similar application error data 122 may be generated, and the clustering module 118 of the application server system 102 may identify similar library-related source code in the portion of the application error data 122 corresponding to each error that occurred during the execution of these applications 104. The library attribution module 114 may then generate library error data 124 that includes clustered error data (e.g., stack trace data) identifying the library-related source code associated with the potentially faulty third-party library. The library error reporting module 121 may send this library error data 124 to the third-party library development system 132 so that the library developer of the library can view the library error data 124 using the library console interface 134. The library error data 124 may also include additional information that may be useful to developers, such as the number of different applications that encountered errors when using the library, the type of client computing device 140 used during application execution, the operating system(s) of the client computing device 140, application or library version numbers, etc.

[0039] As outlined in further detail below, the scrubbing module 116 can first remove application-related and / or other library-related source code information from the application error data 122, as described above, and then the clustering module 118 can cluster similar application error data 122 for one or more applications into the library error data 124. In some cases, to identify similar features or characteristics of application error data 122 generated for different applications, the clustering module 118 can generate fingerprint identifiers (e.g., hash identifiers) for portions of the application error data 122 (generated for different applications 104 in which errors occurred), where these portions of the application error data 122 can be stored or included in the library error data 124. The clustering module 118 can then cluster the application error data 122 as the library error data 124 is generated (e.g., in real time, at batch processing of the application error data 122 once or multiple times a day) based on the matching fingerprint identifiers of these portions of the application error data 122. For example, using the example outlined above, each of the plurality of different applications 104 that includes a potentially faulty third-party library can be associated with a portion of application error data 122 that includes or identifies a similar portion of the library-related source code for that library. The clustering module 118 can generate similar or matching fingerprint identifiers for these portions of the application error data 122, where the fingerprint identifier can identify or be associated with that portion of the library-related source code. The clustering module 118 can then include the portion of the application error data 122 that includes or matches the library-related source code within the library error data 124. The library error data 124 can also include information indicating the number of applications that include the code and that encountered the error.

[0040] For example, clustering module 118 may determine a first fingerprint identifier associated with at least a portion of the application error data included in library error data 124. This at least a portion may include source code associated with the library. Clustering module 118 may also determine a match between the first fingerprint identifier and a second fingerprint identifier associated with previously generated library error data included in library error data 124, wherein the previously generated library error data is associated with at least one third-party library. The previously generated library error data also includes at least a portion of application error data associated with at least one error that occurred during execution of one or more applications 104 on client computing device 140 (e.g., source code associated with the same or similar library). In response to determining a match, clustering module 118 may cluster the library error data with the previously generated library error data to generate clustered library error data within library error data 124, wherein the clustered library error data is associated with at least one third-party library. In some cases, and as will be described in further detail below, the clustered library error data indicates at least the number of applications affected by the at least one error. Library error reporting module 121 may then send the clustered library error data to third-party library development system 132.

[0041] In some cases, clustering module 118 can perform one or more application anonymization functions with respect to application developers of applications and application development system 128. For example, when including library error information within library error data 124 associated with one or more applications 104, clustering module 118 can avoid including any specific or identifying information about the plurality of applications 104 associated with the library error data 124. Instead, clustering module 118 can include only general information about such applications 104, such as the number of applications overall. In some cases, depending on the type and detail of information included in the application error data 122 provided by client computing device 140 (e.g., by application error reporting module 142) to application server system 102, clustering module 118 can include further information, such as the type of application, one or more version numbers of one or more third-party libraries 138, application information, at least one version number of at least one operating system executed by client computing device 140, information about client computing device 140 (e.g., operating system or device type information), and the like. Additionally, as will be described in further detail below, the clustering module 118 may also include one or more of the following in the library error data 124: the number of applications 104 affected by at least one error within a time period (e.g., 30 days, 60 days, all cumulative occurrences, etc.), the number of users affected by at least one error within the time period, or the number of occurrences of at least one error within the time period.

[0042] In some cases, clustering module 118 can perform one or more application threshold functions. For example, clustering module 118 can include only the error data that affects more than a threshold number of applications in library error data 124 to further potentially protect the anonymity of the application that encountered the error. In some cases, only those errors (e.g., crashes) observed in applications that exceed this threshold number can be reported to third-party library development system 132. These errors may relate to common problems or vulnerabilities that are of particular interest to library developers of one or more third-party libraries associated with library error data 124. Therefore, in one or more examples, application server system 102 can determine that the number of applications 104 affected by at least one error exceeds a threshold number, and library error reporting module 121 can only be configured to send clustered library error data 124 in response to determining that the number of applications affected by at least one error exceeds a threshold number. In some cases, this threshold number can be a predetermined or default number of applications.

[0043] According to the techniques disclosed herein, the storage of certain data, such as application data 106, library data 136, application error data 122, and / or library error data 124, may, in various examples, occur only in response to a computing device or system (e.g., client computing device 140 and / or systems 102, 128, 132) receiving affirmative consent or a response from one or more users (e.g., one or more application or library developers, or an end user). Controls may be provided to the user that allow the user to select whether and when the systems, programs, or features described herein may enable the collection and / or storage of information, and / or whether and when the systems, programs, or features described herein may enable the transfer or communication of content between devices. Additionally, and as described above, certain data (e.g., library error data 124) may be processed in one or more ways before it is stored or used such that identifiable information associated with application 104 is removed.

[0044] Figure 2 is a block diagram illustrating another example distributed system 200 according to one or more aspects of the present disclosure, the distributed system 200 including an application server system 202 configured to process application crash report data 222 for use by a third-party software development kit (SDK) development system 232. The system 200 is an example of the system 100, wherein Figure 2 The various components shown in FIG provide similar Figure 1 The functionality of like numbered components is shown in FIG.

[0045] For example, the system 200 includes one or more application server systems 202 that are communicatively coupled to one or more application development systems 228, one or more SDK development systems 232, and one or more client computing devices 240 via one or more networks 226. The application server system 202 is Figure 1 The application server system 102 shown is an example; network 226 is an example of network 126; application development system 228 is an example of application development system 128; SDK development system 232 is an example of third-party library development system 132; and client computing device 240 is an example of client computing device 140.

[0046] Figure 2 An example is shown in which a third-party library includes an SDK 238 developed by a third-party SDK developer using an SDK development system 232. In various examples, an SDK includes a collection of software development tools or components provided in an installable library. Figure 2 As shown, the SDK development system 232 includes one or more SDKs 238, which can be developed by one or more third-party SDK developers using the SDK development system 232. Various applications, such as the application 204 developed using the application development system 228, can include one or more SDKs 238. Figure 1 Third-party library development system 132, Figure 2 The SDK development system 232 in the SDK 238 includes an SDK 238, SDK data 236, SDK crash report data 224, one or more SDK console interfaces 234, and one or more display devices 230. The SDK crash report data 224 is an example of library error data 124, where one or more errors associated with the execution of the application 204 include one or more application crashes. In some cases, the SDK data 236 provided to the application server system 202 by the SDK development system 232 may include deobfuscation data, as previously described, which is associated with source code associated with the libraries of the SDK 238. The application server system 202 may store such data locally in the deobfuscation data 209. The deobfuscation module 212 of the SDK crash report generator 210 may use such deobfuscation data 209 to deobfuscate one or more portions of the application crash report data 222 (e.g., source code associated with the libraries) so that the SDK crash report generator 210 generates the SDK crash report data 224.

[0047] Similar to Figure 1 The application development system 128 shown, Figure 2Application development system 228 includes application 204 and corresponding application data 206, including mapping data 208. One or more application developers can use application development system 228 to create application 204. In some cases, application data 206 provided to application server system 202 by application development system 228 can also include deobfuscation data associated with application-related source code of application 204. Application server system 202 can store such data locally in deobfuscation data 209.

[0048] Similar to Figure 1 The client computing device 140 is shown, Figure 2 The client computing device 240 includes applications 204. One or more of the applications 204 may crash or otherwise terminate execution, and the application crash report data 222 may include data associated with these crashes. Figure 1 An example of application error data 122 is shown. One or more application crash reporting modules 242 are configured to send application crash reporting data 222 to the application server system 202 .

[0049] Application server system 202 includes application 204 and corresponding application data 206. Application data 206 includes mapping data 208 and optional deobfuscation data 209. Application server system 202 also includes SDK crash report generator 210, application error handling module 220, SDK crash reporting module 221, application crash report data 222, and SDK crash report data 224 (which are examples of library error data generator 110, application error handling module 120, library error reporting module 121, application error data 122, and library error data 124, respectively).

[0050] Similar to the library error data generator 110, the SDK crash report generator 210 includes an SDK attribution module 214, a cleanup module 216, a clustering module 218, and an optional deobfuscation module 212. The SDK crash report generator 210 is configured to generate SDK crash report data 224 based on application crash report data 222 sent by the application crash reporting module 242 and processed by the application error processing module 220 of the application server system 202. The application crash report data 222 may include stack trace data 223 provided by the application crash reporting module 242, and the SDK crash report data 224 generated by the SDK crash report generator 210 may also include stack trace data 225. The stack trace data 225 may include one or more portions of the stack trace data 223, as previously described with reference to FIG. Figure 1The SDK crash reporting module 221 of the application server system 202 may send the SDK crash reporting data 224 to the SDK development system 232, which may then display one or more portions of the display at the display device 230.

[0051] Figure 3 is a block diagram illustrating an example application server system 302 according to one or more aspects of the present disclosure. The application server system 302 may be the application server system 102 ( Figure 1 ) and / or application server system 202 ( Figure 2 ). Figure 3 Only one particular example of an application server system 302 is illustrated, and many other examples of application server systems 302 may be used in other instances. In various cases, the application server system 302 may include Figure 3 A subset of the components shown in or may include Figure 3 Additional components not shown.

[0052] exist Figure 3 In the example of FIG, application server system 302 includes a display device 348, one or more processors 344, one or more input components 346, one or more communication units 350, one or more output components 354, and one or more storage devices 358. Communication channels 347 can interconnect each of components 344, 346, 348, 350, 354, and / or 358 for inter-component communication (physically, communicatively, and / or operationally). In some examples, communication channels 347 can include a system bus, a network connection, an inter-process communication data structure, or any other method for transferring data between hardware and / or software.

[0053] One or more input components 346 of the application server system 302 can receive input, such as input from a user. Examples of input are touch / tactile, presence-sensitive, and audio input. Examples of input components 346 include a presence-sensitive screen, a touch-sensitive screen, a touch screen, a mouse, a keyboard, a trackpad, a voice response system, a camera, a microphone, or any other type of device for detecting input from a person or machine.

[0054] One or more output components 354 of the application server system 302 can generate output. Examples of output are tactile, audio, and visual output. Examples of output components 354 include a presence-sensitive screen, a touch-sensitive screen, a touch screen, a sound card, a video graphics adapter card, a speaker, a liquid crystal display (LCD), an organic light-emitting diode (OLED) display, a micro-light-emitting diode (microLED) display, an active-matrix organic light-emitting diode (AMOLED) display, a haptic device, or any other type of device for generating output to a person or machine.

[0055] The one or more communication units 350 of the application server system 302 can communicate with external devices via one or more networks (e.g., one or more wired and / or wireless networks) by transmitting and / or receiving network signals on the one or more networks. For example, the application server system 302 can use the communication unit 350 to transmit and / or receive radio signals on a radio network such as a cellular radio network. Similarly, the communication unit 350 can transmit and / or receive satellite signals on a satellite network such as a global positioning system (GPS) network. Examples of the communication unit 350 include a network interface card (e.g., such as an Ethernet card), an optical transceiver, a radio frequency transceiver, a GPS receiver, or any other type of device capable of sending and / or receiving information. Other examples of the communication unit 350 can include a shortwave radio, a cellular data radio, a wireless Ethernet network radio, and a universal serial bus (USB) controller.

[0056] In some cases, the application server system 302 may include a display device 348. In some examples, the display device 348 may provide output to the user using tactile, audio, or visual stimulation as described above with reference to the output component 354. For example, the display device 348 may provide a display or video output as described with reference to the output component 354. The display device 348 may also provide input capabilities, such as those described above with reference to the input component 346. In some cases, the application server system 302 may not include a display device 348.

[0057] One or more storage devices 358 can store information for processing during operation of application server system 302. In some examples, storage devices 358 include temporary storage, meaning that the primary purpose of storage devices 358 is not long-term storage. Storage devices 358 on application server system 302 can be configured for short-term storage of information as volatile memory and therefore do not retain stored contents if power is lost. Examples of volatile memory include random access memory (RAM), dynamic random access memory (DRAM), static random access memory (SRAM), and other forms of volatile memory known in the art.

[0058] In some examples, storage device 358 includes one or more computer-readable storage media. Storage device 358 can be configured to store larger amounts of information than volatile memory. Storage device 358 can be further configured to store information long-term as non-volatile memory space and retain the information after power on / off cycles. Examples of non-volatile memory include magnetic hard disks, optical disks, floppy disks, flash memory, or forms of electrically programmable memory (EPROM) or electrically erasable programmable (EEPROM) memory. Storage device 358 can store program instructions and / or data associated with one or more of application 304, application data 306, mapping data 308, library error data generator 310, application error handling module 320, library error reporting module 321, application error data 322, and library error data 324, which may include Figures 1 to 2 The library error data generator 310 includes a deobfuscation module 312 , a library attribution module 314 , a cleansing module 316 , and a clustering module 318 .

[0059] One or more processors 344 may implement functionality and / or execute instructions within the application server system 302. For example, a processor 344 on the application server system 302 may receive and execute instructions stored by the storage device 358 that implement functionality of the application 304, the library error data generator 310 (including the deobfuscation module 312, the library attribution module 314, the cleansing module 316, and the clustering module 318), the application error handling module 320, and / or the library error reporting module 321. Execution of these instructions by the processor 344 may cause the application server system 302 to store information within the storage device 358 during program execution.

[0060] Figure 4 is a conceptual diagram illustrating example stack trace data 423 including library-related source code and application-related source code according to one or more aspects of the present disclosure. Figure 2 An example of stack trace data 223 is shown in FIG, which may be included in application crash report data 222 provided by client computing device 240 to application server system 202. Stack trace data 423 is associated with the application crash report data 222 provided by client computing device 240 to application server system 202. Figure 2 For illustrative purposes only, reference will be made to at least one error that occurs during one of the applications 204 shown. Figure 2 The system 200 is shown to describe Figures 4 to 8 Related examples are shown in the figure.

[0061] like Figure 4, stack trace data 423 includes an error identifier (e.g., exception identifier) ​​460 that identifies one or more errors associated with stack trace data 423. Stack trace data 423 also includes multiple code portions: library-related source code 461, application-related source code 462, and library-related source code 463. Stack trace data 423 can represent nested function calls with a calling sequence 464, which can lead, for example, from a program loader to one or more applications (e.g., Figure 2 The location where the crash occurred during the corresponding execution of the application 204 shown in FIG. Figure 4 In the example of , the calling order 464 of function calls that may lead to a possible crash is from bottom to top (eg, the order of library-related source code 463, application-related source code 462, and library-related source code 461).

[0062] In various examples, Figure 4 Each line of the stack trace data 423 shown in can be referred to as a frame or code location of the stack trace. In some cases, each frame or code location of the stack trace can indicate information associated with the source code of the frame of the stack trace (e.g., library-related or application-related source code). For example, the information may include a library name or identifier. In some examples, the name or identifier may include a package name, a namespace name, a module name, etc. In some examples, the information for each frame or code location may include additional information, such as one or more of a class name, a method name, and / or a function name, alone or in any combination. In some cases, each frame or code location of the stack trace may further indicate the file name of the file in which the source code is included, and / or the line number of the source code for the frame.

[0063] Application-related source code 462 is associated with code specific to an application, such as application 204. Library-related source code 461 is associated with code from, for example, Figure 2 The illustrated SDK 238 is associated with code from a first SDK (named "examplehttp"). The library-related source code 463 is associated with code from a second SDK (named "OS.app"), for example, from SDK 238, where "OS" in this particular example may represent the name of an operating system.

[0064] Figure 5 is a conceptual diagram illustrating example mapping data 508 that provides a mapping between one or more portions of library-related source code of an application and at least one third-party library from which the library-related source code is loaded during execution of the application, in accordance with one or more aspects of the present disclosure. The mapping data 508 may be Figure 2An example of mapping data 208 is shown, which is included in application data 206 provided by application development system 228 to application server system 202. In various cases, use of such mapping data may enable SDK crash report generator 210 to determine whether stack trace data, such as stack trace data 423, traverses any library code of an application in application 204, such that SDK attribution module 214 may attribute a crash to a library corresponding to such code.

[0065] In some cases, application developers and / or application development system 228 may develop or create mapping data 508 that is relevant to the application being deployed to Figure 2 The application development system 228 may provide such mapping data 508 (which is a Figure 2 ) for use by SDK crash report generator 210. In some cases, application server system 202 can obtain one or more portions of mapping data 508 from one or more external sources or repositories (e.g., publicly accessible repositories that provide such information about application 204).

[0066] like Figure 5 As illustrated, mapping data 508 provides a mapping between one or more portions of library-related source code of application 204 and at least one third-party library (e.g., SDK) from which the library-related source code is loaded during execution of the application. Figure 5 , example mappings are shown between identified portions or patterns of library-related source code and a first SDK ("examplehttp").

[0067] For example, the mapping data 508 maps a first portion or pattern 570 of the source code associated with the library of the application to an SDK identifier 571 of the first SDK. Figure 5 As shown, pattern 570 identifies library-related source code with a package name of "okttp3" and a class name of "ExampleHttpClient". The "*" wildcard in pattern 570 indicates that any function / method with the package and class name in the library-related source code is mapped to SDK identifier 571. Mapping data 508 maps pattern 570 of the library-related source code to a first SDK with SDK identifier 571. SDK identifier 571 identifies the first SDK ("examplehttp"), where SDK identifier 571 can identify the SDK name and version number ("4.8.1").

[0068] Mapping data 508 also maps a second portion or pattern 572 of the library-related source code to an SDK identifier 571 of the first SDK. Pattern 572 identifies the library-related source code having a package name of "examplehttp" and a class name of "ExampleHttpClient$Builder." The "*" wildcard character in pattern 572 indicates that any function / method in the library-related source code having the package and class name is mapped to SDK identifier 571.

[0069] Mapping data 508 also maps a third portion or pattern 573 of the library-related source code to an SDK identifier 571 of the first SDK. Pattern 573 identifies library-related source code having a package name of "examplehttp" and associated with platform code having a class name of "OSPlatform." The "*" wildcard character in pattern 573 indicates that any function / method in the library-related source code having that package and class name is mapped to SDK identifier 571.

[0070] The mapping data 508 also maps a fourth portion or pattern 574 of the library-related source code to the SDK identifier 571 of the first SDK. Pattern 574 identifies the library-related source code having the package name "examplehttp" and associated with the platform code having the class name "Platform". The "*" wildcard character in pattern 574 indicates that any function / method in the library-related source code having the package and class name is mapped to the SDK identifier 571. Thus, in Figure 5 In the example of , all portions or patterns 570 , 572 , 573 , 574 of library-related source code are mapped to the same first SDK (“examplehttp”).

[0071] Figure 6 is a conceptual diagram illustrating example stack trace data 625 included in an SDK crash report provided to one or more SDK development systems 232 according to one or more aspects of the present disclosure. In various examples, the SDK crash report generator 210 (e.g., using the SDK attribution module 214) can generate SDK crash report data 224 that includes Figure 6 The SDK crash reporting module 221 may then send the SDK crash reporting data 224 to the SDK development system 232 for output to the display device 230 .

[0072] In various examples, and as previously described, the SDK attribution module 214 can attribute the crash to one or more SDKs included in the SDK 238. These SDKs can include source code related to the library that is the cause of the crash. The SDK attribution module 214 can attribute the crash to one or more SDKs included in the SDK 238 based on the stack trace data 423 ( Figure 4 ) and mapping data (including Figure 5 ) to determine a match between the source code associated with the application's libraries and at least a portion of the stack trace data 423. For example, based on the mapping data 508 and the stack trace data 423, the SDK attribution module 214 may identify the first SDK ("examplehttp") as a possible cause of the crash. Additionally, based on the stack trace data 423 and the source code associated with the application's libraries, the SDK attribution module 214 may identify the first SDK ("examplehttp") as a possible cause of the crash. Figure 5 Because the SDK attribution module 214 may identify the second SDK as another possible cause of the crash, the SDK attribution module 214 may identify the first and second SDKs as possible SDK candidates 678 that may have caused the crash. In some examples, one or more of these SDK candidates may be responsible for any given crash. Figure 4 As shown at the top of the stack trace data 423 , in some cases, the SDK attribution module 214 may list the first SDK as the first or potentially stronger candidate responsible for the crash relative to the second SDK.

[0073] To identify these SDK candidates 678, in various examples, the SDK attribution module 214 can analyze the mapping data and attempt to match portions or patterns in such data (e.g., patterns 570, 572, 573, 574 in the mapping data 508) with source code included in frames or code locations of the stack trace data 423 received from the client computing device 240. Upon finding one or more matches, the SDK attribution module 214 can then identify the third-party library corresponding to the library identifier in the mapping data (e.g., the first SDK "examplehttp" associated with the SDK identifier 571 in the mapping data 508) as a library that may be a potential cause of the crash.

[0074] In one or more specific non-limiting examples, the SDK attribution module 214 may perform such a process to identify SDK candidates 678 based on the following pseudo code:

[0075]

[0076] In this pseudo-code, input_stack_trace may correspond to stack trace data 423, where input_stack_trace.code_locations corresponds to each frame or code location of stack trace data 423. Mapping.library_patterns of the pseudo-code may correspond to patterns 570, 572, 573, 575 of mapping data 508. As described above, the SDK attribution module 214 may analyze the mapping data and attempt to match portions or patterns in such data (e.g., patterns 570, 572, 573, 574 in mapping data 508) with source code included in frames or code locations of stack trace data 423 received from the client computing device 240. Upon finding such a match, the SDK attribution module 214 may add each identified library (e.g., library identifier) ​​to a set of matched_libraries (e.g., SDK candidates 678).

[0077] After performing the matching operation, the SDK crash report generator 210 may generate Figure 6 , which is associated with the first SDK ("examplehttp") and the second SDK ("OS.app"), and is included in SDK crash report data 224. Stack trace data 625 may include one or more portions of stack trace data 423. SDK crash reporting module 221 may send SDK crash report data 224, including stack trace data 625, to SDK development system 232.

[0078] For example, Figure 6 As shown, stack trace data 625 includes an error identifier 660, source code 661 associated with a library associated with a first SDK ("examplehttp") of SDK 238, and source code 663 associated with a library associated with a second SDK ("OS.app"). Error identifier 660 corresponds to Figure 4 Error identifier 460 in stack trace data 423 , library-related source code 661 corresponds to library-related source code 461 , and library-related source code 663 corresponds to library-related source code 463 .

[0079] However, if Figure 6 As shown, the stack trace data 625 does not include the application-related source code 462. Instead, the stack trace data 625 includes a generic or unified placeholder 676. Figure 6 One or more "-" or "_" characters are illustrated as placeholders 676, but in other examples any other form of symbols or alphanumeric characters (e.g., " <private>”). As previously described, in various cases, the cleanup module 216 may be configured to remove certain information from the stack trace data 423 when generating the library error data, such as Figure 6 Stack trace data 625 is shown.

[0080] For example, after identifying SDK candidate 678, cleanup module 216 can erase sensitive or specific information associated with the identity or internal details of the crashed application. Thus, in various cases, cleanup module 216 can be configured to remove all application-related information (e.g., application-related source code 462) from stack trace data 423 when generating stack trace data 625 and replace that information with placeholders 676. As a result, SDK development system 232 does not receive any such application-related information in SDK crash report data 224 for use or display by SDK console interface 234.

[0081] The SDK crash report generator 210 (e.g., using the SDK attribution module 214 and / or clustering module 218) can, in some cases, be configured to generate a unique fingerprint identifier (ID) 677, such as a unique hash identifier, that is associated with the contents of the stack trace data 625. The fingerprint ID 677 can be used to aggregate and / or cluster the stack trace data 625 with other similar stack trace data that may be associated with other application crashes, as described in further detail below. The SDK crash report module 221 can send the SDK crash report data 224 (including the stack trace data 625) to an SDK development system 232 associated with a first SDK ("examplehttp") and a second SDK ("OS.app") included in the SDK 238. SDK developers of these first and / or second SDKs can then use the SDK console interface 234 to review the SDK crash report data 224.

[0082] However, in other cases, the cleanup module 216 may also be configured to remove information associated with other SDKs from the stack trace data 625. Figure 6 In an example where the SDK attribution module 214 has identified a first SDK and a second SDK as SDK candidates 678, the cleanup module 216 can generate two separate instances of stack trace data associated with the first SDK and the second SDK. The first stack trace data can include only source code associated with the libraries associated with the first SDK, and the second stack trace data can include only source code associated with the libraries associated with the second SDK. Both the first stack trace data and the second stack trace data can be stored in the SDK crash report data 224. The SDK crash reporting module 221 can send the portion of the SDK crash report data 224 including the first stack trace data to one or more SDK development systems 232 that developed the first SDK 238, and the SDK crash reporting module 221 can send the portion of the SDK crash report data 224 including the second stack trace data to one or more SDK development systems 232 that developed using the second SDK. The respective SDK developers of the first and second SDKs can then review the respective first stack trace data and second stack trace data associated with the application crash. Figures 7 to 8 Examples of such first stack trace data and second stack trace data are provided. By utilizing this method, the cleaning module 216 is configured to remove SDK information about the second SDK when providing the first stack trace data to the developer of the first SDK, and to remove SDK information about the first SDK when providing the second stack trace data to the developer of the second SDK.

[0083] Figure 7 is a conceptual diagram illustrating another example of stack trace data 725 included in an SDK crash report (e.g., SDK crash report data 224) provided to one or more SDK development systems 232 according to one or more aspects of the present disclosure. Figure 4 The stack trace data 423 includes the stack trace data generated by the third-party library development system 232 ( Figure 2 ), the cleanup module 216 may be configured to remove one or more portions of such library-related source code when generating the stack trace data 725, such as any library-related source code that is not associated with the identified third-party library that the library attribution module 114 attributes to the current error.

[0084] Therefore, in Figure 7 In the example shown in FIG4 , the cleanup module 216 removes all frames of the stack trace data 423 provided by the client computing device 240 that include application-related source code 462 and any library-related source code not associated with the first identified SDK (library) candidate “examplehttp”. Therefore, the cleanup module 216 removes the library-related source code 463 associated with the second identified SDK (library) candidate “OS.app” when generating or updating the stack trace data 725. Figure 7 As shown, stack trace data 725 includes an error identifier 760 and source code 761 related to a library associated with the first SDK candidate "examplehttp." Clustering module 218 can also generate a unique fingerprint identifier 777 for stack trace data 725, which can be used to cluster stack trace data 725 with other similar stack trace data associated with other application crashes, as described in more detail below.

[0085] Figure 8 is a conceptual diagram illustrating another example of stack trace data 825 included in an SDK crash report (e.g., SDK crash report data 224) provided to one or more SDK development systems 232 according to one or more aspects of the present disclosure. Figure 4 The stack trace data 423 includes the stack trace data generated by the third-party library development system 232 ( Figure 2 ), the cleanup module 216 can again be configured to remove one or more portions of such library-related source code when generating the stack trace data 825, such as any library-related source code that is not associated with the identified third-party library that the library attribution module 114 attributes to the current error.

[0086] Therefore, in Figure 8 In the example shown in FIG4 , the cleanup module 216 removes all frames of the stack trace data 423 provided by the client computing device 240 that include application-related source code 462 and any library-related source code that is not associated with the second identified SDK (library) candidate “OS.app”. Therefore, the cleanup module 216 removes the library-related source code 463 associated with the first identified SDK (library) candidate “examplehttp” when generating or updating the stack trace data 825. Figure 8 As shown, stack trace data 825 includes an error identifier 860 and source code 863 related to a library associated with the second SDK candidate "OS.app." Clustering module 218 can also generate a unique fingerprint identifier 877 for stack trace data 825, which can be used to cluster stack trace data 825 with other similar stack trace data associated with other application crashes.

[0087] Thus, the cleanup module 216 can generate two separate instances of stack trace data associated with these first and second SDKs. The first stack trace data can include only source code associated with the libraries associated with the first SDK, and the second stack trace data can include only source code associated with the libraries associated with the second SDK. In one or more specific non-limiting examples, the cleanup module 216 can perform a process to generate such stack trace data for different candidate SDKs for inclusion in the SDK crash report data 224 sent to the SDK development system 232, similar to or based on the following pseudo code:

[0088]

[0089] In this pseudo-code, matched_libraries are those SDK candidates 678, namely the first SDK ("examplehttp") and the second SDK ("OS.app"). The pseudo-code creates separate first and second stack trace data instances for the first SDK and the second SDK in the list of library_stack_traces. For example, the cleanup module 216 creates and adds a first library stack trace data 725 (library_stack_trace) to the list of library_stack_traces, which includes the library-related source code 761 of the first SDK within the stack trace data 725, which is generated from the input stack trace data 423 (input_stack_trace). The cleanup module 216 traverses each frame or code_location of the stack trace data 423 to identify the library-related source code 461 of the first SDK. After identifying such code, the cleanup module 216 adds or appends the code as the library-related source code 761 to the first library stack trace data 725 (library_stack_trace) in the list. For any other library-related source code (e.g., library-related source code 463) or any application-related source code (e.g., application-related source code 462), as Figure 7 As shown, the cleanup module 216 completely removes the code in the stack trace data 725, or replaces it with one or more uniform placeholders (e.g., "_" characters) ( Figure 7 ) to replace the code.

[0090] Similarly, the cleanup module 216 creates a second library stack trace data 825 (library_stack_trace) and adds it to the list of library_stack_traces, which includes the library-related source code 863 of the second SDK within the stack trace data 825, and the stack trace data 825 is generated from the input stack trace data 423 (input_stack_trace). The cleanup module 216 traverses each frame or code_location of the stack trace data 423 to identify the library-related source code 463 of the first SDK. After identifying such code, the cleanup module 216 adds or appends the code as the library-related source code 863 to the first library stack trace data 825 (library_stack_trace) in the list. For any other library-related source code (e.g., library-related source code 461) or any application-related source code (e.g., application-related source code 462), as Figure 8 As shown, the cleanup module 216 completely removes the code in the stack trace data 825, or replaces it with one or more uniform placeholders (e.g., "_" characters) ( Figure 8 ) to replace the code.

[0091] As described above, clustering module 218 can also generate a unique fingerprint identifier 777 for stack trace data 725, which can be used to cluster stack trace data 725 with other similar stack trace data associated with other application crashes. Clustering module 218 can similarly generate a unique fingerprint identifier 877 for stack trace data 825, which can be used to cluster stack trace data 825 with other similar stack trace data associated with other application crashes. In various cases, clustering module 218 can store fingerprint identifiers 777 and 877 (e.g., in SDK crash report data 224 or in an associated data store).

[0092] Each of the stack trace data 725 and 825 can be processed and clustered into groups of similar data or reports based on the identified fingerprint identifiers 777, 877, respectively. By performing one or more clustering operations using the clustering module 218, the SDK crash report generator 210 can be configured to process application crash report data 222 associated with any number of different applications 204 developed by any number of different application developers on the application development system 228, and then aggregate and cluster similar errors and crashes that have occurred during the execution of these applications 204. The SDK crash reporting module 221 can then output the clustered SDK crash report data 224 associated with the particular identified SDK 238 to the SDK development system 232, which can then be displayed on the display device 230 via the SDK console interface 234 for review by the corresponding SDK developer.

[0093] In various cases, to perform such aggregation or clustering, the SDK crash report generator 210 and / or the SDK crash report module 221 may store current and historical stack trace data within stack trace data 225 of the SDK crash report data 224, indexed or grouped according to fingerprint identifiers associated with such stack trace data, respectively. Thus, as an example, the SDK crash report generator 210 may store stack trace data 725 within the stack trace data 225. The clustering module 218 may also store one or more other portions of the application crash report data 222 received from the application crash report module 242 associated with the particular crash that caused the stack trace data 725 within the SDK crash report data 224. For example, if the application crash report data 222 includes version number information of the operating system used by the application 204, the version number of any SDK included in the application 204, the device type of the client computing device 240, etc., the clustering module 218 may store such information within the SDK crash report data 224. In some cases, the clustering module 218 may also obtain SDK version information from the mapping data 208. All of this information in SDK crash report data 224 and stack trace data 225 can be indexed or grouped according to fingerprint identifier 777. In some cases, clustering module 218 can also obtain SDK version information and / or SDK name information from mapping data 208, which it can then store in SDK crash report data 224.

[0094] Similarly, the SDK crash report generator 210 can store the stack trace data 825 in the stack trace data 225. The clustering module 218 can also store one or more other parts of the application crash report data 222 received from the application crash report module 242 associated with the specific crash that caused the generation of both the stack trace data 725 and the stack trace data 825 (e.g., the version number of the operating system used by the application 204, the version number of any SDK included in the application 204, the device type(s) of the client computing device 240, etc.) in the SDK crash report data 224. This information in the SDK crash report data 224 and the stack trace data 225 can be further indexed or grouped according to the fingerprint identifier 877. In addition, as will be described in further detail below, the clustering module 218 can also include one or more of the following in the SDK crash report data 224: the number of applications 204 affected by the at least one error within a time period (e.g., 30 days, 60 days, all cumulative occurrences, etc.), the number of users affected by the at least one error within the time period, or the number of times the at least one error occurred within the time period.

[0095] Over time, the SDK crash report generator 210 can process further application crash report data 222 associated with additional errors or crashes encountered during execution of the application 204. These can include one or more of the applications 204 developed by one or more different application developers using the application development system 228. The SDK crash report generator 210 can generate additional stack trace data associated with these errors or crashes. The clustering module 218 can generate corresponding fingerprint identifiers for such stack trace data and can compare these fingerprint identifiers with previously generated fingerprint identifiers associated with the stack trace data and other data previously stored in the SDK crash report data 224. If there is a match in the fingerprint identifiers, the clustering module 218 can perform one or more clustering operations to aggregate or cluster the current error or crash data with the previously collected data, where such clustering can indicate similarities between errors or crashes that occur over time in one or more applications 204 that utilize similar SDKs 238 in the SDK 238. The SDK crash reporting module 221 can then output the SDK crash reporting data 224 to the SDK development system 232, so that individual SDK developers can view, via the SDK console interface 234, portions of the SDK crash reporting data 224 that correspond to one or more SDKs 238 that they developed and that may be the cause of one or more application errors.

[0096] The clustering module 218 can store various forms of clustering information within the SDK crash report data 224 based on the clustering operations performed. For example, the clustering module 218 can include one or more of the following types of information within the SDK crash report data 224 associated with the clustering data: the number of times similar errors (e.g., reports, issues, crashes) occurred within a time period, the number of applications (and / or application users) that experienced similar errors, the name(s) of the library (e.g., SDK) associated with the error, the library version(s), the operating system(s) and / or operating system version(s) of the computing device on which the error occurred, and / or the type(s) of the client computing device(s) on which the error occurred. Upon receiving such aggregated and / or clustered data within the SDK crash report data 224, the SDK development system 232 can output one or more portions of such data at the display device 230 using the SDK console interface 234, which can be reviewed by the corresponding SDK developer of the SDK in question. Figures 9 to 10 An example of this output is provided.

[0097] As previously described, in some cases, the clustering module 218 can perform one or more application anonymization functions with respect to application developers of applications and application development systems 228. For example, when error information (e.g., clustering information) is included within SDK crash report data 224 associated with one or more applications 104, the clustering module 218 can avoid including specific or identifying information about multiple applications 204 associated with the SDK crash report data 224. Instead, the clustering module 218 can include only general information about such applications 204, such as the number of applications overall. In some cases, depending on the type and detail of the information included in the application crash report data 222 provided by the client computing device 240 (e.g., by the application error reporting module 242) to the application server system 202, the clustering module 218 can include further information, such as the type of application, information about the client computing device 140 (e.g., operating system or device type information), etc.

[0098] In some cases, clustering module 218 can perform one or more application threshold functions as another form of anonymization, for example. For example, clustering module 218 can include only error data that affects more than a threshold number of applications in SDK crash report data 224 to further potentially protect the anonymity of one or more applications 204 that encountered the error. In some cases, only those errors (e.g., crashes) observed in more than the threshold number of applications can be reported to SDK development system 232. These errors may involve common problems or vulnerabilities that are of particular interest to library developers of one or more SDKs 238 associated with SDK crash report data 224. In some cases, the threshold may include a predetermined or default number of applications.

[0099] Figure 9 is a screen shot illustrating an example graphical user interface 980 that may be displayed at one or more third-party library development systems based on data provided by an application server system in accordance with one or more aspects of the present disclosure. Figure 2 The SDK development system 232 and the application server system 202 shown in FIG are described Figure 9 .

[0100] As previously described, the SDK crash reporting module 221 can send SDK crash report data 224 to the SDK development system 232. One or more SDK console interfaces 234 of the SDK development system 232 can output one or more portions of such SDK crash report data 224 (e.g., in one or more graphical user interfaces) for display at one or more display devices 230. Thus, one or more SDK library developers can review the information output by the SDK console interface 234 to determine any issues with a corresponding one of the SDKs 238 that they have developed or maintained. Figure 9 The graphical user interface 980 illustrated in FIG. 9 is an example of such a graphical user interface.

[0101] The graphical user interface 980 includes various information provided by the clustering module 118. Also as previously described, the clustering module 118 can generate clustered library error data 124 and can similarly generate clustered SDK crash report data 224. For example, when generating such clustered SDK crash report data 224 for one or more errors (e.g., crashes) that occurred during one or more periods of execution of the application 204, the clustering module 118 can include various forms of clustering information with the SDK crash report data 224. For example, depending on the type and detail of information included in the application crash report data 222 provided by the client computing device 240 to the application server system 202, the clustering module 118 can include information such as the type of application 204, one or more version numbers of at least one of the corresponding SDKs 238, at least one version number of at least one operating system executed by the client computing device 240, information about the client computing device 240 (e.g., operating system or device type information), and the like. In addition, the clustering module 218 may also include one or more of the following in the SDK crash report data 224: the number of applications 204 affected by at least one error within a time period (e.g., 30 days, 60 days, all cumulative occurrences), the number of users affected by at least one error within the time period, and / or the number of occurrences of at least one error within the time period.

[0102] Figure 9 The graphical user interface 980 shown in FIG includes various examples of such information. The top portion of the graphical user interface 980 includes curves 981, 982, and 983 associated with specific errors or crashes that occurred in the past 30 days. In some cases, the SDK console interface 234 can output these curves based on input received from one or more SDK developers provided at the SDK development system 232. For example, when the SDK console interface 234 requests information for the last 30 days within the graphical user interface, the SDK developer can provide user input. In other examples, the SDK developer can request information for other time periods (e.g., 60 days, all cumulative time).

[0103] Curve 981 shows a graphical representation of the number of reports (e.g., occurrences) of a specified crash plotted over time. For curve 981, the x-axis represents time in days, and the y-axis on the left represents the number of reports. Curve 982 shows a graphical representation of the number of users affected by the crash over time. For curve 982, the x-axis represents time in days, and the y-axis on the left represents the number of users affected. Curve 983 shows a graphical representation of the number of applications affected by the crash over time. For curve 983, the x-axis represents time in days, and the y-axis on the right represents the number of applications affected (e.g., the number of applications affected in applications 204).

[0104] like Figure 9 As illustrated, the graphical user interface also includes further crash details 984, which may include one or more unresolved issues. Figure 9 In the example of , crash details 984 may include information at one or more different time points or days. For example, regarding a specific crash that occurred a certain number of times (represented by curve 981) in the past 30 days, affecting a certain number of users (represented by curve 982) and / or applications (represented by curve 983), each row of crash details 984 may include detailed information at a time point (e.g., one day) represented by curves 981, 982, and 983. For example, Figure 9 As illustrated, for each corresponding row corresponding to a particular date, crash details 984 can identify or indicate the name or identifier of the SDK associated with the crash, the first affected version number of the SDK, the number of affected users (a point on curve 982), the number of affected applications (a point on curve 983), and the number of reports of the crash occurring (a point on curve 981).

[0105] Figure 10 is a screen shot illustrating another example graphical user interface 1090 that may be displayed at one or more third-party library development systems based on data provided by an application server system according to one or more aspects of the present disclosure. For illustrative purposes only, reference will be made to Figure 2 The SDK development system 232 and the application server system 202 shown in FIG are described Figure 10 .

[0106] Graphical user interface 1090 is another example of an interface that may be output by SDK console interface 234 for display at display device 230 of SDK development system 232. SDK console interface 234 may output graphical user interface 1090 for display upon receiving SDK crash report data 224, which may include clustering data generated by clustering module 218, as described above.

[0107] The top portion of the graphical user interface 1090 includes graphs 1091, 1092, and 1093 associated with occurrences of a particular error or crash over the past 30 days. Different occurrences of the particular crash during the execution of one or more applications 204 over time can be associated with one or more version numbers of a particular SDK included in or used by the application 204, one or more version numbers of an operating system (OS) executed by the client computing device 240 during execution of the application 204, and / or one or more device types of the client computing device 240 (e.g., a device type based on manufacturer and / or model, a device type based on physical characteristics of the client computing device 240, etc.).

[0108] Curve 1091 is a bar graph showing the percentage of occurrences of these specific crashes or crash types clustered by SDK version, where each bar represents a different SDK version number. The SDK developer of that specific SDK can review curve 1091 to identify the details of the (multiple) different versions of the SDK associated with different occurrences of the same or similar crashes in the past 30 days. Curve 1092 is a bar graph showing the percentage of occurrences of specific crashes or crash types clustered by OS version, where each bar represents a different OS version number. The SDK version can review curve 1092 to identify the details of the different versions of the OS executed by the client computing device 240 that are associated with different occurrences of the same or similar crashes in the past 30 days.

[0109] Graph 1093 is a bar graph that displays the percentage of occurrences of a particular crash or crash type clustered by device type of client computing device 240, where each bar represents a different device type. SDK releases can review graph 1093 to identify a breakdown of different device types of client computing device 240 associated with different occurrences of the same or similar crashes over the past 30 days.

[0110] Graphical user interface 1090 also includes stack information 1094. In various cases, stack information 1094 may include a graphical representation of stack trace data 225 included in SDK crash report data 224. Figure 10 , the stack information 1094 may include identifiers of the OS version and SDK version associated with the displayed stack trace. For example, the stack trace may be associated with a specific version number of the SDK included in or used by the crashed application, and a specific version number of the OS executed by one or more client computing devices 240 during the execution of the application. The stack information 1094 also includes a textual representation of one or more portions of the stack trace data 225. For example, the textual representation may be one of the error identifier 760 and the source code 761 associated with the library included in the stack trace data 725, such as Figure 7 In this example, the particular SDK in SDK 238 that may be associated with the occurrence of the crash is the "examplehttp" SDK.

[0111] Figure 11 is an illustration of a system according to one or more aspects of the present disclosure such as Figures 1 to 3 A flowchart of example operations of a process 1100 performed by an application server system of any of the illustrated application server systems. For illustrative purposes only, reference is made to Figure 1 The application server system 102 shown describes Figure 11 .

[0112] like Figure 11 As shown, process 1100 includes receiving (1102), by application server system 102 (e.g., using application error handling module 120) and from client computing device 140, application error data 122 associated with at least one error that occurred during execution of at least one of applications 104 on client computing device 140. Process 1100 includes receiving (1104), by application server system 102, mapping data 108 that provides a mapping between (i) library-related source code of at least one application and (ii) at least one third-party library from which the library-related source code was loaded during execution of the at least one application. The at least one third-party library can be included in third-party libraries 138.

[0113] Process 1100 also includes determining (1106), by application server system 102 and based on application error data 122 and mapping data 108, a match between source code associated with a library and at least a portion of application error data 122, and, in response to determining the match, attributing (1108), by application server system 102 (e.g., using library attribution module 114 of library error data generator 110), at least one error that occurred during execution of at least one application to at least one third-party library. Process 1100 also includes generating (1110), by application server system 102 (e.g., using library attribution module 114 and / or clustering module 118 of library error data generator 110), library error data 124 associated with the at least one third-party library, wherein the library error data 124 includes at least a portion of application error data 122, and sending (1112), by application server system 102 (e.g., using library error reporting module 121), the library error data 124 to one or more third-party library development systems 132 that developed the at least one third-party library.

[0114] In one or more examples, the functions described may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions may be stored on or transmitted through a computer-readable medium as one or more instructions or codes and executed by a hardware-based processing unit. Computer-readable media may include computer-readable storage media, which corresponds to tangible media such as data storage media, or communication media, which includes any media that facilitates the transfer of a computer program from one place to another, for example, according to a communication protocol. In this manner, computer-readable media may generally correspond to (1) tangible computer-readable storage media that is non-transitory or (2) communication media such as signals or carrier waves. Data storage media may be any available media that can be accessed by one or more computers or one or more processors to retrieve instructions, codes, and / or data structures to implement the techniques described in this disclosure. A computer program product may include computer-readable media.

[0115] As an example and not limitation, such computer-readable storage media can include RAM, ROM, EEPROM, CD-ROM or other optical disk storage, disk storage or other magnetic storage devices, flash memory or any other storage medium that can be used to store the required program code that exists in the form of instructions or data structures and can be accessed by a computer. In addition, any connection is properly referred to as a computer-readable medium. For example, if a coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL) or wireless technologies such as infrared, radio and microwaves are used to transmit instructions from a website, server or other remote source, then coaxial cable, fiber optic cable, twisted pair, DSL or wireless technologies such as infrared, radio and microwaves are included in the definition of medium. However, it should be understood that computer-readable storage media and data storage media do not include connections, carrier waves, signals or other transient media, but rather relate to non-transient, tangible storage media. Disks and optical disks as used herein include compact disks (CDs), laser optical disks, optical optical disks, digital versatile disks (DVDs), floppy disks and blue-ray discs, wherein disks typically reproduce data magnetically, while optical disks use lasers to reproduce data optically. The above combination should also be included in the scope of computer-readable media.

[0116] Instructions can be executed by one or more processors, such as one or more digital signal processors (DSPs), general-purpose microprocessors, application-specific integrated circuits (ASICs), field-programmable logic arrays (FPGAs), or other equivalent integrated or discrete logic circuits. Therefore, the term "processor" as used herein may refer to any of the aforementioned structures or any other structure suitable for implementing the techniques described herein. Additionally, in some aspects, the functionality described herein may be provided within dedicated hardware and / or software modules. Furthermore, these techniques may be fully implemented in one or more circuits or logic elements.

[0117] The techniques of this disclosure can be implemented in a variety of devices or apparatuses, including a wireless handset, an integrated circuit (IC), or a set of ICs (e.g., a chipset). Various components, modules, or units are described in this disclosure to emphasize functional aspects of devices configured to perform the disclosed techniques, but do not necessarily need to be implemented by different hardware units. Instead, as described above, the various units can be combined in a hardware unit or provided by a collection of intraoperative hardware units, including one or more processors as described above, together with appropriate software and / or firmware.

[0118] It should be appreciated that, depending on the embodiment, certain actions or events of any method described herein can be performed in a different order, can be added, combined, or omitted entirely (e.g., not all described actions or events are necessary to practice the method). Furthermore, in some embodiments, actions or events can be performed simultaneously, for example, through multithreading, interrupt handling, or multiple processors, rather than sequentially.

[0119] In some examples, computer-readable storage media include non-transitory media. The term "non-transitory" means that the storage medium is not embodied in a carrier wave or propagating signal. In some examples, non-transitory storage media can store data that changes over time (e.g., in RAM or cache).

[0120] Various examples have been described. These and other examples are within the scope of the following claims.< / private>

Claims

1. A method for providing one or more portions of application error data, comprising: receiving, by an application server system including one or more processors, from one or more client computing devices, application error data associated with at least one error, the at least one error occurring during execution of at least one application on the one or more client computing devices; receiving, by the application server system, mapping data providing a mapping between library-related source code of the at least one application and at least one third-party library from which the library-related source code is loaded during execution of the at least one application; determining, by the application server system, a match between source code associated with the library and at least a portion of the application error data based on the application error data and the mapping data; In response to determining the match, attributing, by the application server system, the at least one error occurring during execution of the at least one application to the at least one third-party library; generating, by the application server system, library error data associated with the at least one third-party library, wherein the library error data includes the at least a portion of the application error data; as well as The application server system sends the library error data to at least one third-party library development system that develops the at least one third-party library.

2. The method according to claim 1, in, the application error data comprising application crash report data associated with the at least one error that caused the at least one application to crash on the one or more client computing devices; wherein the at least a portion of the application error data includes at least a portion of the application crash report data; and The library error data includes library crash report data, and the library crash report data includes the at least a portion of the application crash report data.

3. The method according to claim 2, in, The application crash report data includes stack trace data representing nested function calls of the at least one application; and The at least part of the application crash report data includes at least part of the stack trace data.

4. The method according to claim 3, wherein: Determining the match includes matching, by the application server system, one or more patterns of the source code associated with the library to one or more code locations in the at least a portion of the stack trace data based on the stack trace data and the mapping data.

5. The method according to claim 3, further comprising: receiving, by the application server system, deobfuscation data associated with source code related to the library from the at least one third-party library development system that developed the at least one third-party library; as well as The at least a portion of the stack trace data is deobfuscated by the application server system based on the deobfuscation data.

6. The method according to claim 3, wherein: Generating the library error data includes removing application-related source code from the stack trace data by the application server system to generate the library error data.

7. The method according to claim 6, in, The at least one third-party library includes at least a first third-party library and a second third-party library; The library-related source code includes source code related to a first library associated with the first third-party library and source code related to a second library associated with the second third-party library; wherein said at least a portion of said application error data includes source code related to said first library; and The generating of the library error data further includes removing, by the application server system, source code related to the second library from the stack trace data to generate the library error data.

8. The method according to any one of claims 1 to 7, wherein: The library error data further indicates one or more of: at least one version number of the at least one third-party library, at least one version number of at least one operating system executed by the one or more client computing devices, at least one device type of the one or more client computing devices, a number of applications affected by the at least one error during a time period, a number of users affected by the at least one error during the time period, and a number of occurrences of the at least one error during the time period.

9. The method according to any one of claims 1 to 7, further comprising: determining, by the application server system, a first fingerprint identifier associated with the at least a portion of the application error data included in the library error data; determining, by the application server system, a match between the first fingerprint identifier and a second fingerprint identifier associated with previously generated library error data, wherein the previously generated library error data is associated with the at least one third-party library, and wherein the previously generated library error data includes at least a portion of application error data associated with the at least one error occurring during execution of the at least one application on the one or more client computing devices; and In response to determining the match between the first fingerprint identifier and the second fingerprint identifier, clustering, by the application server system, the library error data with the previously generated library error data to generate clustered library error data associated with the at least one third-party library, wherein the clustered library error data indicates a number of applications affected by at least the at least one error; The sending of the library error data includes sending, by the application server system, the clustered library error data to the at least one third-party library development system.

10. The method according to claim 9, further comprising: determining, by the application server system, that a number of the applications affected by the at least one error exceeds a threshold number; Wherein, sending the clustered library error data occurs in response to determining that the number of the applications affected by the at least one error exceeds the threshold number.

11. The method according to any one of claims 1 to 7, wherein: Receiving the mapping data includes receiving, by the application server system, the mapping data from at least one application development system that develops the at least one application.

12. An application server system, comprising: at least one processor; as well as at least one computer-readable storage device configured to store instructions executable by the at least one processor to: receiving, from one or more client computing devices, application error data associated with at least one error, the at least one error occurring during execution of at least one application on the one or more client computing devices; receiving mapping data providing a mapping between library-related source code of the at least one application and at least one third-party library from which the library-related source code is loaded during execution of the at least one application; determining, based on the application error data and the mapping data, a match between source code associated with the library and at least a portion of the application error data; responsive to determining the match, attributing the at least one error occurring during execution of the at least one application to the at least one third-party library; generating library error data associated with the at least one third-party library, wherein the library error data includes the at least a portion of the application error data; as well as The library error data is sent to at least one third-party library development system that develops the at least one third-party library.

13. The application server system according to claim 12, wherein: The instructions stored on the at least one computer-readable storage device are further executable by the at least one processor to perform the method according to any one of claims 2 to 11.

14. A computer-readable storage device storing instructions that, when executed, cause at least one processor to perform operations comprising: receiving, from one or more client computing devices, application error data associated with at least one error, the at least one error occurring during execution of at least one application on the one or more client computing devices; receiving mapping data providing a mapping between library-related source code of the at least one application and at least one third-party library from which the library-related source code is loaded during execution of the at least one application; determining, based on the application error data and the mapping data, a match between source code associated with the library and at least a portion of the application error data; responsive to determining the match, attributing the at least one error occurring during execution of the at least one application to the at least one third-party library; generating library error data associated with the at least one third-party library, wherein the library error data includes the at least a portion of the application error data; as well as The library error data is sent to at least one third-party library development system that develops the at least one third-party library.

15. The computer-readable storage device of claim 14, wherein: The instructions cause the at least one processor to further perform the method according to any one of claims 2 to 11.

Images