DEDICATED RECOVERY MODULES FOR RESOLVING ISSUES WITH FAULTY APPLICATIONS

In general, techniques are described by which to enable dedicated recovery modules for resolving issues with faulty applications. A server computing device comprising a memory and a. processor may perform various aspects of the techniques. The memory may store a faulty application indication identifying a faulty application of a plurality of applications hosted for distribution by the server computing device, where the faulty application has an issue occurring during execution of the faulty application by a user computing device. The processor may generate, based on the faulty application indication, a dedicated recovery module dial extends the faulty application, and output, to the user computing device, the dedicated recovery' module to resolve the issue occurring during execution of the faulty application.

BACKGROUND

Software developers may provide one or more application updates or “patches” to improve the functionality of an application. A patch may include one or more application elements, such as compiled source code (which can be executable code or various abstractions thereof, such as byte code), textures, images, animations, video files, audio files, or any other resource referenced by the executable code. In some distributed environments, a user computing device (e.g., a smartphone) may use an application store application (which may be referred to as an “application store”) to obtain and install patches, which are provided by a remote server computing system that supports execution of the application store.

Such patches are often deferred for a number of different reasons. In some instances, the user computing devices executing the applications may have insufficient storage space to accommodate the patch (e.g., due to how patches are applied and may consume significant memory resources during installation). The user computing device may also have limited network access that defers download and application of the patches. In situations in which unpatched applications may be unable to function correctly, such as when the unpatched application “crashes” or “hangs” due to software bugs, or function in violation of various laws and/or regulations (e.g., various copyright issues surrounding use of assets referenced by the executable code), the inability to apply the patch may detract from the user experience or otherwise limit the functionality provided by the user computing device.

SUMMARY

In general, techniques of this disclosure may enable dedicated recovery modules for resolving issues with faulty applications. Rather than deploy a patch that may consume significant computing resources of the user computing device (such as memory, memory bus bandwidth, processing cycles and associated power), the server computing device that hosts distribution of a number of different applications (including a faulty application) may generate a dedicated recovery module that is separate from and extends the faulty application. That is, the dedicated recovery module does not include any program code associated with the underlying faulty application (in comparison to application updates, or in other words, “patches” that reuse at least a portion of the program code from the faulty application) but rather adds functionality to the faulty application that targets the issues occurring during execution of the faulty application. In this sense, the recovery module is targeted at (or in other words dedicated to) resolving the issues of the faulty applications.

The server computing device may deploy this dedicated recovery module to the user computing device, which may execute the dedicated recovery module to resolve the issues occurring during execution of the faulty application. The dedicated recovery module may be linked to execution of the faulty application, which invokes the dedicated recovery module during execution of the faulty application. In some instances, the dedicated recovery module may prompt (e.g., via a user interface) the user to initiate various actions to resolve the issue occurring during execution of the faulty application (where such actions may involve deleting files, clearing caches. modifying data in databases, updating the faulty application to a newer version, etc.)

Accordingly, the described techniques may improve operation of the user computing device as well as a computing system that includes the user computing device and the server. Because the dedicated recovery module only includes program code necessary to resolve the issue (without modifying any underlying code of the faulty application itself in contrast to patches, but only extending the underlying code of the faulty application), the dedicated recovery module may be significantly smaller than the patches (e.g., the dedicated recovery module may be on the order of 100s of kilobytes compared to multiple megabytes or even gigabytes of patches). As a result, the server computing system may more rapidly deploy the dedicated recovery module to resolve the issues in comparison to patches given that limited memory consumption may improve the likelihood of download and execution of the dedicated recovery module in comparison to patches. In this sense, faulty applications may be addressed more quickly and with less overhead (in terms of computing resources consumed) in comparison to patches, which may improve the user experience while potentially facilitating more efficient operation of the user computing device and the server computing device.

In one example, various aspects of the techniques are directed to a method comprising: receiving, by one or more processors of a server computing device hosting distribution of a plurality of applications, a faulty application indication identifying a faulty application of the plurality of applications, the faulty application having an issue that occurs during execution of the faulty application by a user computing device; generating, by one or more processors of the server computing device and based on the faulty application indication, a dedicated recovery module that extends the faulty application; and outputting, by the one or more processors of the server computing device and to the user computing device, the dedicated recovery module to resolve the issue that occurs during execution of the faulty application.

In another example, various aspects of the techniques are directed to a server computing device comprising: a memory configured to store a faulty application indication identifying a faulty application of a plurality of applications hosted for distribution by the server computing device, the faulty application having an issue occurring during execution of the faulty application by a user computing device; and one or more processors configured to: generate, based on the faulty application indication, a dedicated recovery module that extends the faulty application; and output, to the user computing device. the dedicated recovery module to resolve the issue occurring during execution of the faulty application.

In another example, various aspects of the techniques are directed to an apparatus comprising: means for receiving a faulty application indication identifying a faulty application of a plurality of applications, the faulty application having an issue that occurs during execution of the faulty application by a user computing device; means for generating, based on the faulty application indication, a dedicated recovery module that extends the faulty application; and means for outputting, to the user computing device, the dedicated recovery module to resolve the issue that occurs during execution of the faulty application.

In another example, various aspects of the techniques are directed to a non-transitory computer-readable storage medium having instructions stored thereon that, when executed, cause one or more processors of a server computing device to: receive a faulty application indication identifying a faulty application of a plurality of applications hosted for distribution by the server computing device, the faulty application having an issue occurring during execution of the faulty application by a user computing device, generate, based on the faulty application indication, a dedicated recovery module that extends the faulty application; and output, to the user computing device, the dedicated recovery module to resolve the issue occurring during execution of the faulty application.

In another example. various aspects of the techniques are directed to a method comprising: storing, by one or more processors of a user computing device, a faulty application that presents an issue during execution by the one or more processors; receiving, by one or more processors and from a server computing device that hosts distribution of a plurality of applications including the faulty application. a dedicated recovery module that extends the faulty application; and executing, by the one or more processors, the dedicated recovery module to resolve the issue occurring during execution of the faulty application.

In another example, various aspects of the techniques are directed to a user computing device comprising: a memory configured to store a faulty application, the faulty application having an issue occurring during execution of the faulty application by the user computing device; and one or more processors configured to: receive, from a server computing device that hosts distribution of a plurality of applications including the faulty application, a dedicated recovery module that extends the faulty application; and execute, by the one or more processors. the dedicated recovery module to resolve the issue occurring during execution of the faulty application.

In another example, various aspects of the techniques are directed to an apparatus comprising: means for storing a faulty application that presents an issue during execution by one or more processors; means for receiving, from a server computing device that hosts distribution of a plurality of applications including the faulty application, a dedicated recovery module that extends the faulty application; and means for executing the dedicated recovery module to resolve the issue occurring during execution of the faulty application.

In another example, various aspects of the techniques are directed to a non-transitory computer-readable storage medium having instructions stored thereon that, when executed, cause one or more processors of a user computing device to: store a faulty application, the faulty application having an issue occurring during execution of the faulty application by the user computing device; receive, from a server computing device that hosts distribution of a plurality of applications including the faulty application, a dedicated recovery module that extends the faulty application; and execute, by the one or more processors, the dedicated recovery module to resolve the issue occurring during execution of the faulty application.

DETAILED DESCRIPTION

FIG.1is a conceptual diagram illustrating an example computing system in which a computing device may perform various aspects of the dedicated recovery techniques described in this disclosure. As shown inFIG.1, computing system100may include a computing device102and an application provider server104.

Computing device102may represent any type of device capable of executing applications, such as application120B, and supports application of software patches (which may also be referred to as “patches”) to such applications. For example, computing device102may represent a cellular phone or handset (including a so-called “smart phone”), a streaming media device (including those that are inserted directly into a port of a television), a dedicated gaming system, a portable gaming system, a streaming gaming system, a television (including so-called “smart televisions”), a wireless speaker, a smart hub, a watch (including a so-called “smart watch”), smart glasses, a smart ring or other wearable device, an extended reality device (such as a virtual reality—VR—device, an augmented reality—AR—device, etc.), a digital video disc (DVD) player, a Blu-ray™ player, a laptop computer, a desktop computer, a workstation, or any other device capable of executing applications.

As shown in the example ofFIG.1, computing device102includes a user interface component (UIC)112, UI module114, an application installer116, and application120B. UIC112of computing device102may function as an input and/or output device for computing device102. UIC112may be implemented using various technologies. For instance, UIC112may function as an input device using presence-sensitive input screens, such as resistive touchscreens, surface acoustic wave touchscreens, capacitive touchscreens, projective capacitance touchscreens, pressure sensitive screens, acoustic pulse recognition touchscreens, or another presence-sensitive display technology.

UI module114may manage user interactions with UIC112and other components of computing device102. UIC112and UI module114may receive one or more indications of input (e.g., voice input. gesture input, etc.) from a user as the user interacts with a user interface presented by UIC112. Application120B may represent an application that is currently installed on computing device102. While the example ofFIG.1illustrates a single application120B that is currently installed on computing device102, it should be understood that any number of applications may be installed on computing device102, and that computing device102is not necessarily limited to only having a single application installed on computing device102.

Application installer116may represent a module or unit configured to install application120B on computing device102. Application installer116may also present an interface provided by application provider server104with which the user of computing device102may interact via UIC112and/or UI module114to download application120B. Application installer116may communicate with application provider server104to arrange for the download of application120B, where application installer116may, upon receiving application120B, perform various operations to install application120B, such as decompressing (which may be referred to as “unzipping”) application120B, memory management, compilation and/or translation, etc.

UIC112, UI module114, application installer116, and application120B may perform operations described herein using hardware. or a combination of hardware and software and/or firmware residing in and/or executing at computing device102. Computing device102may execute UI module114, application installer116, and application120B with multiple processors or multiple devices. In some cases, computing device102may execute UI module114and/or application installer116as virtual machines executing on underlying hardware. UI module114and/or application installer116may also execute as one or more services of an operating system or computing platform, or as one or more executable programs at an application layer of a computing platform.

Application120B may include one or more assets122A-122N′ (“assets122′”). Assets122′ may refer to resources (e.g., images, textures, files, scripts, video data, audio data, etc.) that are accessed during execution of the application, and the like. It should be understood that assets122′ of application120B may not be accessible by other applications installed on computing device102without explicit permission of application120B. Thus, assets122′ may not include shared libraries or other data that is accessed by multiple different applications. Likewise, application120B may not be able to access assets of a different application. In some examples, computing device102may execute application120B in a sandboxed environment, which isolates assets122′ of application120B from other applications. For example, computing device102may execute application120B as virtual machines or as separate processes within virtual machines, as programs at the application layer of the computing platform.

In some examples, application120B represents a first party application designed and deployed along with an underlying operating system or a third-party application designed and deployed by a developer for execution in an application space of the underlying operating system. That is, an operating system executed by computing device102may include a kernel, which represents a software process integral to the operating system that executes in kernel space. Kernel space grants increased levels of privilege to the kernel (relative to the application space) such that the kernel can negotiate access to underlying hardware of computing device102.

The kernel may perform hypervisor functions to schedule execution of processes according to various priorities and otherwise expose application programming interfaces (APIs) by which applications, such as application120B, executing in the application space may interact with the underlying hardware. Via these APIs, the kernel presents the application space, which may, as noted above, be partitioned for each application executing within the application space. The application space has limited levels of privilege (compared to the kernel space) with respect to accessing the underlying hardware. The kernel enforces these limited privilege levels via the API and other mechanisms. The kernel may partition the application space to grant individual levels of privilege to each application executing within the application space, including granting higher or lower priorities for access to the underlying hardware.

In this sense, the broader operating system, including the kernel (or, in other words, core of the operating system) should not be understood to be the same as or functionally equivalent to either first party applications or third-party applications, although some first party applications may receive higher levels of privileges compared to third party applications. The operating system (OS), while software in a similar manner to applications, including application120B, is a dedicated lower software layer in the software stack (referred to herein as the “OS layer”) that supports execution of applications at a higher layer in the software stack (referred to herein as the “application layer”).

As further shown in the example ofFIG.1, computing device102may communicate with application provider server104via a network106, where network106may represent any public or private communications network, for instance, cellular, Wi-Fi, and/or other types of networks, for transmitting data between computing systems, servers, and computing devices. Network106may include one or more network hubs, network switches, network routers, or any other network equipment, that are operatively inter-coupled thereby providing for the exchange of information (often referred to as “data packets” or “packets”) between application provider server104and computing device102.

Computing device102and application provider server104may transmit and receive data across network106using any suitable communication techniques. Computing device102and application provider server104may each be operatively coupled to network106using respective network links. The links coupling computing device102and application provider server104to network106may be Ethernet or other types of network connections and such connections may be wireless and/or wired connections.

Application provider server104may represent any suitable remote computing system, such as one or more desktop computers. laptop computers, mainframes, servers, cloud computing systems, etc. capable of sending and receiving information both to and from a network, such as network106. Application provider server104hosts (or at least provides access to) applications and presents the above noted interface (such as an application store, which is not shown in the example ofFIG.1for ease of illustration purposes) by which computing device102may access applications for download to computing device102via network106. Application provider server104may, in this respect, represent a server computing device configured to host distribution of a number of different (or, in other words, a plurality of) applications, including application120B.

In the example ofFIG.1, application provider server104may host a number of different versions for the same application120A-120N (including application120B, which may collectively be referred to as “application120”). Application provider server104may host different versions of application120for a variety of reasons.

For example, application provider server104may host different versions of application120for different display sizes of various types of computing devices, different display resolutions of various types of computing devices, different geographical locations in which computing devices reside, different languages of users of computing devices, etc. As another example, application provider server104may host different versions of application120to support different versions of the underlying operating system executed by the computing devices, different processors (including graphical processing units) by which the computing devices execute application120, etc. As a further example, developers may create different versions of application120for experimental purposes in order to test new features (e.g., so-called beta testing).

Different versions of application120may include different assets122(or possibly updated assets122). The different assets122for each version of application120are denoted by the prime notation, where the example ofFIG.1denotes assets122A-122N (“assets122”) of application120A without any prime notation. assets122A′-122N′ (“assets122′”) of application120B with a single prime notation, and assets122A″-122N″ (“assets122″”) of application120N with a double prime notation.

While all of assets122A′-122N′ include the prime notation, it should be understood that only a single asset. multiple but not all, or possibly all of the assets, may be the same as assets122and/or assets122″. In other words, the prime notation should be understood to denote the respective assets of the versions of application120rather than strictly used to denote that assets122′ are all changed relative to assets122and/or assets122″. Similarly, assets122″ may include one or more (and possibly all) unchanged assets relative to assets122and/or assets122′. For purposes of illustration, it is assumed that at least one asset122has changed relative to assets122′ and/or assets122″, at least one asset122″ has changed relative to assets122and/or assets122″, and at least one asset122″ has changed relative to assets122and/or assets122′.

Application provider server104may perform operations described using hardware or a mixture of hardware, software, and firmware residing in and/or executing at application provider server104. Application provider server104may perform various operations described herein with multiple processors or multiple devices. Application provider server104may also execute various modules or units described in more detail below as virtual machines executing on underlying hardware. In some examples, application provider server104may execute the interface by which to access an application as one or more services of an operating system or computing platform, or as one or more executable programs at an application layer of a computing platform.

Application provider server104may include a patch generation system130, which may generate a patch131for application120. Patch generation system130may execute various patching algorithms to generate patch131, such as generic difference (diff) (“Gdiff”). bsdiff, and the like, which may generate and potentially compress (along with other operations performed with respect to) the underlying binary differences between different versions of application120to form patch131.

That is, each version of application120may represent compiled source code (or, in other words, executable binary code or some derivation thereof, such as byte code) that configures or otherwise programs a processor (or other hardware) to perform various operations. Patch generation system130may represent a unit configured to determine a difference between different versions of application120, and output a list of commands for updating a first version of application120(e.g., application120A) to a second version of application120(e.g., application120B) and a difference that both form patch131Commands may identify one or more delete operations, one or more copy operations, and/or one or more of write operations (or any combinations thereof) instructing computing device102how to manipulate the first version of application120to produce the second version of application120.

Upon generating patch131. application provider server104may interface with app installer116executed by computing device102to indicate that patch131is available for download. App installer116may, in some instances, produce, responsive to the indication that patch131is available, an alert or other indication that patch131for the installed version of application120(which, while not shown in the example ofFIG.1, assumed to be application120A) is available for download and installation. The user of computing device102may, in this instance, interface with app installer116via UIC112and/or UI module114to initiate download and install of patch131. In other instances, app installer116may automatically download and install patch131responsive to the indication that patch131is available. The user may specify that automatic patching is enabled in system settings or per application, identifying a time and/or day during which automated patching may occur.

Regardless, computing device102may obtain patch131from application provider server104and install patch131to application120A to produce a second version of application120(e.g., application120B). Patching in this manner may occur to allow developers of application120to add additional functionality, fix software errors (so-called “software bugs”), prevent malicious attacks, update graphical capabilities or other functionality, and the like without having to download an entirely new application (which can be large and therefore consume significant bandwidth—both bandwidth of network106and memory and/or storage bandwidth of computing device102, processor cycles of computing device102, etc.).

While patching may generally improve operation of application120and thereby improve operation of computing device102, patch131may still, in certain instances, be large (on the order of multiple gigabytes—e.g., several to tens of gigabytes, multiple megabytes—e.g., hundreds of megabytes, etc.). For example, developers may update assets122of application120A to improve graphical fidelity, update textures, add or remove video data and/or audio data. or perform other example updates that improve a user experience of application120A (which may also be referred to as “unpatched application120A”).

As such, application120B (which may be referred to as “patched application120B”) may include a different set of assets122′ in which one or more of assets122′ may differ with assets122(although one or more of assets122′ may, in some instances and as noted above. be the same as assets122). In this example, patch generation system130may not determine there is much if any difference between the compiled source code of unpatched application120A and patched application120B, but only note that there are differences between assets122and assets122′, resulting in a diff that mainly includes assets122′ that include assets that replace or that are in addition to assets of assets122.

In some instances, due to the patching process, computing device102may have insufficient storage space (e.g., memory and/or storage space) to store unpatched application120A, patched application120B, and patch131. In other words, to apply patch131, computing device102may download patch131in its entirety and reserve available space in memory and/or storage for patched application120B, all while storing unpatched application120A in its entirety. Computing device102may then iterate through commands of patch131, perform one or more of the above operations to construct patched application120B from unpatched application120A and diff of patch131. While various aspects of the techniques are described with respect to assets. the techniques may be implemented with respect to compiled source code or other types of files, resources, and/or data not described in detail in this disclosure.

To illustrate how memory and/or storage limited computing devices may be impacted by this process, assume computing device102only has 1.4 gigabytes (GB) of memory available and is to install patch117that is of a size of 400 megabytes (MB) with respect to unpatched application120A that is of a size of 1 GB resulting in patched application120B of a size of 1.2 GB. In this example illustration, computing device102may download patch117consuming 400 MB of the 1.4 GB of available memory resulting in only 1 GB of available memory. When computing device102attempts to reserve the 1.2 GB of memory for patched application120B, a memory manager of computing device102(which is not shown for ease of illustration purposes) may deny the request due to insufficient available memory (as 1.2 GB is larger than the 1 GB of available memory). As such, computing device102may not apply patch117to unpatched application120A.

The inability to apply patch131may result in computing device102being unable to execute patched application120B, and thereby potentially deprive the user of added functionality, updated graphics, audio experiences, video experiences, etc., expose computing device102to security vulnerabilities, and the like. As computing devices, such as computing device102, continue to evolve, such computing devices are being employed for increasingly larger amounts of time such that shortages of available memory can often become a barrier to proper patch application (such as in the case of smart phones that store large amounts of personal information in the form of videos, text-including text messages, emails, etc., images—such as photos, and the like).

As such, patches are often deferred due to limited memory but also for a number of different reasons. User computing device102may also have limited network access that defers download and application of the patches. In situations in which unpatched applications may be unable to function correctly, such as when the unpatched application “crashes” or “hangs” due to software bugs, or function in violation of various laws and/or regulations (e.g., various copyright issues surrounding use of assets referenced by the executable code), the inability to apply the patch may detract from the user experience or otherwise limit the functionality provided by user computing device102.

In accordance with various aspects of the techniques set forth in this disclosure, application provider server104may generate a dedicated recovery module140(“recovery module140”) that extends a faulty application (such as application120B) rather than deploy a patch131that may consume significant computing resources of user computing device102(such as memory, memory bus bandwidth, processing cycles and associated power). That is, dedicated recovery module140does not modify any program code associated with underlying faulty application120B (in comparison to application updates. or in other words. “patches” that typically modify at least a portion of the existing program code from the faulty application) but rather adds functionality to (or in other words, extends functionality of) faulty application120B that targets the issues occurring during execution of faulty application120B. In this sense, recover module140targeted at (or in other words dedicated to) resolving the issues of faulty applications120B.

Application provider server104may deploy dedicated recovery module140to user computing device102(via application installer116), which may execute dedicated recovery module140to resolve the issues occurring during execution of faulty application120B. Dedicated recovery module140may be linked to execution of faulty application120B (as described in more detail below), which invokes dedicated recovery module140during execution of faulty application120B. In some instances, dedicated recovery module140may prompt (e.g., via a user interface) a user to initiate various actions to resolve the issue occurring during execution of faulty application120B (where such actions may involve deleting files, clearing caches, modifying data in databases, updating faulty application120to a newer version of application—e.g., application120N, etc.).

In operation, application provider server104may obtain a faulty application indication (FAI)137(“FAI137”) identifying faulty application120B hosted for distribution by application provider server104. As noted above, faulty application120B may have an issue occurring during execution of faulty application120B by user computing device102.

As shown in the example ofFIG.1. application provider server104may include a UI module134and a recovery system136. UI module134may be similar to, and possibly the same as, UI module114in terms of operation to present a user interface, such as a graphical user interface. A developer of application120may interface with UI module134(typically via a remote computing system via a web browser or other application) to initiate a recovery process. Upon initiating a recovery process via UI module134, application provider server104may invoke recovery system136.

Recovery system136may represent a system configured to generate recovery module140via interactions with the developer of application120by way of UI module134. Recovery system136may interface with UI module134to present various user interfaces with which the developer of application120may interact to specify FAI137. The developer may specify FAI137by identifying a particular application (e.g., by name) and version (e.g., by number), which effectively selects one or more versions of application120. FAI137may enable recovery module140to target one or more versions of application120that are faulty, where it is assumed for purposes of example that application120B is the faulty application (and hence may be referred to as “faulty application120B”).

A faulty application may refer to an application that is faulty in any number of different ways. For example, a faulty application may fail to execute in a manner that enables interaction with the faulty application, where the faulty application may “crash” or “hang.” As another example, a faulty application may include assets that violate copyright or other legal requirements/laws. A faulty application may refer to an application that violates safety requirements (e.g., allows excessive interactions while driving). A faulty application may refer to an application that is glitchy or otherwise unstable due to a variety of factors that may be addressed through extension of the functionality of the faulty application. As such, a faulty application should not be limited to only one type of fault, such as crashing or hanging, but may refer to any fault that can be addressed through the addition of extended functionality (but not through alteration of the underlying program code of faulty application).

Recovery system136may further interface with the developer via user interfaces presented by UI module134to identify a type of the issue occurring during execution of faulty application120B. In this respect. FAI137may include an issue indication that identifies the issue experienced during execution of faulty application120B by user computing device102. Recovery system136may next select, based on the issue indication, one of template code139A-139N (“template code139” or “templates139”) that targets the issue occurring during execution of faulty application120B by user computing device102. Recovery system136may next populate, based on the issue indication, the selected one of templates139to obtain populated template code configured to resolve the issue occurring during execution of faulty application120B by user computing device102.

Recovery system136may interface with UI module134to present, via the user interface, the populated template code. The developer may interface with the user interface to confirm or reject populated template code (or, in some instances, make changes to the populated template code). Assuming the developer approves of the populated template code. recovery system136may compile the populated template code to obtain recovery module140. Recovery module140may extend faulty application120B through an enhancement, which is linked to faulty application120B through various mechanisms.

To illustrate, consider that various operating systems allow applications to be dynamically extended during execution of applications, where an initial install of the application may include only a portion of the compiled code (which may occur for games and other applications in which an opening portion of the game or other application is executable prior to downloading and installing the entirety of the game). To link recovery module140to faulty application120B, recovery system136may update a manifest file associated with faulty application120B to add recovery module140as a sub-package.

Each version of application120may represent an application container in which the manifest file defines a list of sub-packages that are either required or optional. The manifest file may define which of the sub-packages are required for the execution of each corresponding version of application120. The application container may be separately signed to verify the authenticity of each corresponding version of application120, which is verified upon execution of each version of application120to ensure that the version of application120is valid.

When recovery system136updates the manifest file associated with faulty application120B to add recovery module140. the updated version of faulty application120B is signed and thereby receives a new signature because the contents of application120B have changed to include recovery module140. This new signature invalidates previous versions of faulty application120B that may be installed at computing devices, such as computing device102, whereupon such computing devices may retrieve the updated manifest file. The updated manifest file may indicate that recovery module140is a required sub-package that is to be executed first before any other sub-package associated with faulty application120B by way of the updated manifest file. In this respect, recovery system136may generate, based on faulty application indication137, a dedicated recovery module140that extends faulty application120B.

User computing device102may, at some point after recovery module140is linked to application120B, attempt to execute faulty application120B. Upon initiating the execution of faulty application120B, app installer116may verify the authenticity of faulty application120B. As noted above, app installer116may verify the signature against the signature of faulty application120B at application provider server104and determine that the signatures do not match. App installer116may then determine that an update has occurred with respect to application120B and interface with application provider server104to download the update to application120B, which in this instance includes an updated manifest file linking recovery module140to application120B.

App installer116may update application120B (which in this instance may include replacing the existing manifest file with the updated manifest file) and verify the authenticity of application120B with the updated manifest file in the manner described above. In this instance. app installer116determines that the signatures of updated application120B having the updated manifest file and the signature of application120B at application provider server104match, whereupon computing device102may execute application120B. Application120B, upon initiation of execution, may determine that recovery module140has been linked to application120B and is to be executed first before any other sub-packages associated with the application container represented by application120B.

Responsive to determining that recovery module140has been linked to faulty application120B, application120B may interface with app installer116to retrieve (or, in this example, download via network106) recovery module140. As such, application provider server104may output, to user computing device102, recovery module140, and user computing device102may receive, from application provider server104, recovery module140.

User computing device102may next execute recovery module140to resolve the issue occurring during execution of faulty application120B by user computing device102. Recovery module140may resolve the issue in a number of different ways depending on the issue identified by issue identification. Recovery module140may, for example, delete or edit a file installed by faulty application120B, such as one of assets122″. Recovery module140may, in some instances, delete or edit a cache associated with faulty application120B (which may be stored to the partition for faulty application120B in the application space discussed above). Recovery module140may, as yet a further example. edit or delete a database associated with faulty application120B.

As noted above, application120B may be installed as an experimental version of application120to test various new functionality (e.g., a beta test). Recovery module140may, in these instances, delete or edit an experimental parameter associated with faulty application120B. In some examples, recovery module140may prompt the user to update faulty application120B to a newer version, such as application120N. As noted above, updates may require significantly more resources than recovery module140, and app installer116may confirm that user computing device102includes sufficient resources (e.g., network connectivity, memory and/or storage space, etc.) prior to updating faulty application120B.

Accordingly, the described techniques may improve operation of user computing device102as well as computing system100that includes user computing device102and application provider server104. Because dedicated recovery module140only includes program code necessary to resolve the issue (without including modifying any underlying code of the faulty application itself in contrast to most patches), dedicated recovery module140may be significantly smaller than the patches (e.g., dedicated recovery module140may be on the order of 100s of kilobytes compared to multiple megabytes or even gigabytes of patches).

As a result, application provider server104of computing system100may more rapidly deploy dedicated recovery module140to resolve the issues in comparison to patches, such as patch131, given that limited memory consumption may improve the likelihood of download and execution of dedicated recovery module140in comparison to patches. In this sense, faulty application120B may be addressed more quickly and with less overhead (in terms of computing resources consumed) in comparison to patches, which may improve the user experience while potentially facilitating more efficient operation of user computing device102and application provider server104.

FIG.2is a block diagram illustrating an example application provider server configured to perform various aspects of the dedicated recovery techniques described in this disclosure.FIG.2illustrates only one particular example of application provider server204, and many other examples of application provider server204may be used in other instances. In other examples. application provider servers may include a subset of the components included in example application provider server204or may include additional components not shown inFIG.2. For example, application provider server204may comprise a cluster of servers, and each of the servers comprising the cluster of servers making up application provider server204may include all, or some, of the components described herein inFIG.2, to perform the techniques disclosed herein. As such, application provider server204represents one example of application provider server104.

As shown in the example ofFIG.2, application provider server204includes one or more processors241, one or more communication units242, and one or more storage devices248. Processors241may implement functionality and/or execute instructions associated with application provider server204. Examples of processors241include application processors, display controllers, auxiliary processors, one or more sensor bubs, and any other hardware configured to function as a processor, a processing unit, or a processing device.

Communication unit242may represent a unit configured to communicate with external devices (e.g. computing device102) via one or more wired and/or wireless networks (e.g., network106) by transmitting and/or receiving network signals via the one or more networks. Examples of communication units242include a network interface card (e.g. such as an Ethernet card), an optical transceiver, a radio frequency transceiver, a global positioning satellite (GPS) receiver, a cellular transceiver, or any other type of device that can send and/or receive data. Other examples of communication units242may include short wave radios, cellular data radios. wireless network radios, as well as universal serial bus (USB) controllers.

Storage devices248may represent one or more memories and/or storage devices configured to store information for processing during operation of application provider server204. In some examples, storage devices248may represent a temporary memory, meaning that a primary purpose of storage devices248is not long-term storage. Storage devices248may be configured for short-term storage of information as volatile memory and therefore not retain stored contents if powered off. Examples of volatile memories include random access memories (RAM), dynamic random-access memories (DRAM), static random-access memories (SRAM), and other forms of volatile memories known in the art.

Storage devices248may, in some examples, also include one or more computer-readable storage mediums. Storage devices248may include one or more non-transitory computer-readable storage mediums. Storage devices248may be configured to store larger amounts of information than typically stored by volatile memory. Storage devices248may further be configured for long-term storage of information as non-volatile memory space and retain information after power on/off cycles. Examples of non-volatile memories include magnetic hard discs, optical discs, floppy discs, flash memories, or forms of electrically programmable memories (EPROM) or electrically erasable and programmable (EEPROM) memories.

Storage devices248may store program instructions and/or information (e.g., data) associated with a patch generation system230, a user interface module234(“UI module234”). a recovery system236. and applications220A-220N (“application220”). Storage devices248may include a memory configured to store data or other information associated with patch generation system230, UI module234, recovery system236, and applications220A-220N.

Application provider server204may obtain a faulty application indication (FAI)137(“FAI137”) identifying faulty application120B hosted for distribution by application provider server204. As noted above, faulty application220B may have an issue occurring during execution of faulty application220B by a user computing device, such as user computing device102.

As shown in the example ofFIG.2, application provider server204may include a UI module234and a recovery system236. UI module234may be similar to, and possibly the same as, UI module234in terms of operation to present a user interface, such as a graphical user interface. A developer of application220may interface with UI module234(typically via a remote computing system via a web browser or other application) to initiate a recovery process. Upon initiating a recovery process via UI module234, processors241may invoke recovery system236, which may be similar to (and possibly the same as) recovery system136.

Recovery system236may represent a system configured to generate recovery module240via interactions with the developer of application220by way of UI module234. Recovery system236may interface with UI module234to present various user interfaces with which the developer of application220may interact to specify FAI237. The developer may specify FAI237by identifying a particular application (e.g., by name) and version (e.g., by number), which effectively selects one or more versions of application220. FAI237may enable recovery module240to target one or more versions of application220that are faulty, where it is assumed for purposes of example that application220B is the faulty application (and hence may be referred to as “faulty application220B”).

Recovery system236may further interface with the developer via one or more user interfaces presented by UI module234to identify a type of the issue occurring during execution of faulty application220B. In this respect, FAI237may include an issue indication that identifies the issue experienced during execution of faulty application220B by the user computing device. Recovery system236may next select, based on the issue indication, one of template code239A-239N (“template code239” or “templates239”) that targets the issue occurring during execution of faulty application220B by the user computing device. Recovery system236may next populate, based on the issue indication, the selected one of templates239to obtain populated template code configured to resolve the issue occurring during execution of faulty application220B by the user computing device.

Recovery system236may interface with UI module234to present, via the user interface, the populated template code. The developer may interface with the user interface to confirm or reject populated template code (or, in some instances, make changes to the populated template code). Assuming the developer approves of the populated template code, recovery system236may compile the populated template code to obtain recovery module240, where recovery module240may represent an example of recovery module140. Recovery module240may extend faulty application220B through an enhancement, which is linked to faulty application220B through various mechanisms.

To illustrate, consider that various operating systems allow applications to be dynamically extended during execution of applications, where an initial install of the application may include only a portion of the compiled code (which may occur for games and other applications in which an opening portion of the game or other application is executable prior to downloading and installing the entirety of the game). To link recovery module240to faulty application220B, recovery system236may update a manifest file223B associated with faulty application220B to add recovery module140as a sub-package.

Each version of application220may represent an application container in which a corresponding manifest file223A-223N (“manifests223”) defines a list of sub-packages that are either required or optional. Each manifest223may define which of the sub-packages are required for the execution of each corresponding version of application220. The application container may be separately signed to verify the authenticity of each corresponding version of application220, which is verified upon execution of each version of application220to ensure that the version of application220is valid.

When recovery system236updates manifest223B associated with faulty application220B to add recovery module240, the updated version of faulty application220B is signed and thereby receives a new signature because the contents of application220B have changed to include recovery module240. This new signature invalidates previous versions of faulty application220B that may be installed at computing devices, such as computing device102(FIG.1), whereupon such computing devices may retrieve the updated manifest file, which in this instance is assumed to be manifest223B. Updated manifest file223B may indicate that recovery module240is a required sub-package that is to be executed first before any other sub-package associated with faulty application120B by way of updated manifest file223B. In this respect, recovery system236may generate, based on faulty application indication237, a dedicated recovery module240that extends faulty application220B (meaning, in other words, extends the functionality of faulty application220B).

Recovery system236may at some later point output, to the user computing device, recovery module240to resolve the issue occurring during execution of faulty application220B. As noted above, recovery system236may output recovery module240to the user computing device upon the user computing device initiating execution of faulty application220B. However, recovery system236may output recovery module240in other ways, such as preemptively outputting recovery module240prior to the user computing device initiating execution of faulty application220B (e.g., in order to reduce time required to download and execute recovery module240). Recovery module240may address a number of different issues. such as a failure to execute faulty application220B in a manner that enables user interaction with faulty application220B (e.g., faulty application220B may hang or crash).

FIG.3is a block diagram illustrating an example computing device that is configured to apply recovery modules in accordance with various aspects of the recovery techniques described in this disclosure.FIG.3illustrates only one particular example of computing device302, and many other examples of computing device302may be used in other instances and may include a subset of the components included in example computing device302or may include additional components not shown inFIG.3. Computing device302may represent one example of computing device102shown in the example ofFIG.1.

As shown in the example ofFIG.3, computing device302includes user interface component (UIC)312, one or more processors341, one or more communication units338, and one or more storage devices328, each of which are interconnected by communication channels330(which may be similar to if not the same as communication channels250shown in the example ofFIG.2). UIC312may be similar to if not the same as UIC112shown in the example ofFIG.1. Processors341may be similar to if not the same as processors241shown in the example ofFIG.2. Communication units338may be similar to if not the same as communication units242shown in the example ofFIG.2. Storage devices328may be similar to if not the same as storage devices248shown in the example ofFIG.2.

As further shown in the example ofFIG.3, user interface component312may include one or more input components332and one or more output components334. One or more input components332of computing device302may receive an input. Examples of inputs are tactile, audio, and video input. Input components332, in one example, includes a presence-sensitive input device (e.g., a touch sensitive screen, a presence-sensitive display), mouse, keyboard, voice responsive system, video camera, microphone or any other type of device for detecting input from a human or machine. In some examples, input components332may include one or more sensor components such as one or more location sensors (GPS components. Wi-Fi components, cellular components), one or more temperature sensors, one or more movement sensors (e.g., accelerometers, gyros), one or more pressure sensors (e.g., barometer), one or more ambient light sensors. and one or more other sensors (e.g., microphone, camera, infrared proximity sensor, hygrometer, and the like). Other sensors may include a heart rate sensor, magnetometer, glucose sensor, hygrometer sensor, olfactory sensor, compass sensor, step counter sensor, to name a few other non-limiting examples

One or more output components334of computing device302may generate output. Examples of output are tactile, audio, and video output. Output components334of computing device302. in one example, includes a PSD, sound card, video graphics adapter card, speaker, cathode ray tube (CRT) monitor, liquid crystal display (LCD), or any other type of device for generating output to a human or machine.

While illustrated as an internal component of computing device302, UIC312may also represent an external component that shares a data path with computing device302for transmitting and/or receiving input and output. For instance, in one example, UIC312represents a built-in component of computing device302located within and physically connected to the external packaging of computing device302(e.g., a display on a mobile phone). In another example, UIC312represents an external component of computing device302located outside and physically separated from the packaging or housing of computing device302(e.g., a monitor, a projector, etc. that shares a wired and/or wireless data path with computing device302).

One or more storage devices328within computing device302may store information for processing during operation of computing device302(e.g., computing device302may store data accessed by a UI module314, an application installer316, a recovery module340, and/or an application320B during execution by computing device302). Storage devices328may store program instructions and/or information (e.g., data) associated UI module314, application installer316(“app installer316”), recovery module340, and/or application320B. Storage components328may include a memory configured to store data or other information associated with UI module314, app installer316, recovery module340, and/or application320B.

As discussed above, app installer316may be executed by processors341to install application320B at computing device302. App installer316may perform the functions of an application marketplace application that allows users to interact with an application store via UIC312to browse, download, and install applications, such as application320B. UIC312may receive an indication indicative of a request to download application320B and user interface component312may forward the request to app installer316. Responsive to the indication of the request to download application320B, app installer316may then send the request to application provider server204.

In response to sending the request for application320B to application provider server204, app installer316may receive application320B and install application320B within computing device302. As time progresses app installer316may update or otherwise modify application320B (e.g., updating assets322A′-322N′ of application320B. which may be similar to assets322′ and/or assets122′ described above). Through updates or even upon initial install, application320B may become faulty, presenting various issues that detract from the user experience. In some instances, application320B may become faulty (and hence may be denoted as “faulty application320B”) to such extent that faulty application320B may fail to execute in a manner that enables user interaction with faulty application320B (e.g., faulty application320B hangs with limited to no user interaction possible or crashes in which faulty application320B unexpectedly quits execution).

Upon recognizing that application320B is faulty (e.g., via manual or automatic reporting functions by way of app installer316, bug reports, user feedback—such as application reviews for application320B, etc.), the developer may generate and link recovery module340to application320B as described above in more detail with respect to application provider server104/204. Although described as being initiated by the developer, generation and linking of recovery module340may be initiated automatically (meaning, without developer oversight) in response to bug reports. crash reports. user reviews, etc.

User computing device102may, at some point after recovery module340is linked to application320B, attempt to execute faulty application320B. Upon initiating the execution of faulty application320B, faulty application320B may reference manifest323B (having been updated to link recovery module320as the first sub-package to be executed) and determine that recovery module340is to be downloaded. Responsive to determining that recovery module340has been linked to faulty application320B, app installer316interfaces with the recovery system236(FIG.2) to retrieve (or, in this example, download via network106;FIG.1) recovery module340. As such, application provider server204may output, to user computing device302, recovery module340, and user computing device302may receive, from application provider server304, recovery module340.

User computing device302may next execute recovery module340to resolve the issue occurring during execution of faulty application320B by user computing device302. Recovery module340may resolve the issue in a number of different ways depending on the issue identified by issue identification. Recovery module340may. for example, delete or edit a file installed by faulty application320B, such as one of assets322′. Recovery module340may, in some instances, delete or edit a cache associated with faulty application320B (which may be stored to the partition for faulty application320B in the application space discussed above). Recovery module340may, as yet a further example, edit or delete one or more entring in a database associated with faulty application320B.

As noted above, application320B may be installed as an experimental version of application320to test various new functionality (e.g., a beta test). Recovery module340may, in these instances, delete or edit an experimental parameter associated with faulty application320B. In some examples, recovery module340may prompt the user to update faulty application320B to a newer version, such as application320N. As noted above, updates may require significantly more resources than recovery module340, and app installer316may confirm that user computing device302includes sufficient resources (e.g., network connectivity, memory and/or storage space, etc.) prior to updating faulty application320B.

FIGS.4A-4Eare diagrams illustrating example user interface for configuring, deploying, and monitoring recovery modules deployed for faulty application recovery in accordance with various aspects of the techniques described in this disclosure. Recovery system236of application provider server204(FIG.2) may generate and present (via communication units242) each of user interfaces (UIs)400A-400E shown in the examples ofFIGS.4A-4E. UIs400A-400E (“UIs400”) may represent example user interfaces with which a software developer of faulty application (e.g., faulty application320B) may interact to specify faulty application information (e.g., FAI137/237) in order to generate recovery module140/240/340, deploy recovery module140/240/340. and monitor deployment/adoption of recovery module140/240/340.

Referring first to the example ofFIG.4A, UI400A may present an interface with which the developer may interact to view an application bundle, which is another way to refer to a bundle of different versions of an application, such as application120/220/320. Further, UI400A may identify various metrics, such as a download size for new installs, a time to download and install, a size for updates, and an install base (e.g., a number of installs across all compatible devices). The software developer may initiate the generation of the recovery module (or, in other words. the recovery process) by selecting a recovery tools dropdown box402and selecting different recovery options404A and404B.

Recovery option404A may initiate generation of a recovery module140/240/340that updates an existing application to a latest version (which may involve application of a patch), and as such may “Migrate users from this version to latest version.” Recovery option404B may initiate generation of a recovery module140/240/340that edits or deletes various aspects of the data associated with faulty application120B/220B/320B. Assuming the software developer, selection recovery option404B (for purposes of illustration), UI400A transitions to UI400B shown in the example ofFIG.4B.

UI400B may include a number of different option radio buttons410A-410C that are associated with templates139/239. Option radio button410A may be associated with one of templates139/239for clearing a cache associated with faulty application120B/220B/320B. Option radio button410B may be associated with one of templates139/239for clearing data associated with faulty application120B/220B/320B. Option radio button410C may be associated with other data fixes defined via a file uploaded via upload frame412. Once the software developer has selected one of option radio buttons410A-410C. UI400B transitions to UI400C shown in the example ofFIG.4C.

UI400C may present an information pane420instructing the software developer on how to test recovery module140/240/340. That is, responsive to selecting one of templates139/239via option radio buttons410A-410C, recovery system136/236may generate recovery module140/240/340as a split from faulty application120B/220B/320B, where such split receives its own signature and signing keys separate from faulty application120B/220B/320B (meaning this split may be separate and linked to faulty application120B/220B/320B). This split may be considered to extend faulty application120B/220B/320B without altering application120B/220B/320B such that faulty application120B/220B/320B may require a new signature.

In any event, the software developer may download recovery module140/240/340via download button423and run the command set forth in the instruction pane420to test recovery module140/240/340. Assuming recovery module140/240/340is successful in resolving the issue with faulty application120B/220B/320B, the software developer may confirm successful testing via test checkbox422, prior to transitioning from UI400C to UI400D shown in the example ofFIG.4D.

UI400D may include a deployment criteria dropdown box430that, when selected, is configured to present deployment criteria432A-432D (“deployment criteria432”). Deployment criteria432may represent different options for filtering deployment of recovery module140/240/340, such as to none/to all users (deployment criteria432A), by country (deployment criteria432B), by software development kit (SDK) versions (deployment criteria432C), and by percentage (deployment criteria432D). While various example deployment criteria432are shown, it should be understood that more or less, including different. deployment criteria may be provided to facilitate limited, reduced. expanded or other types of deployment. Upon selecting one or more of deployment criteria432, UI400D may transition to UI400E shown in the example ofFIG.4E.

UI400E may present an overview of recovery module140/240/340in terms of deployment, e.g., method, targeting criteria, files and instructions, total affected users, and progress of 25% in terms of total affected users. The software developer may also edit recovery module140/240/340or cancel deployment of recovery module140/240/340. UI400E may also present a history of recovery modules over the life of application120/220/320. In this respect, UIs400may enable configuring, deploying, and monitoring recovery module140/240/340deployed for recovery of faulty application120B/220B/320B in accordance with various aspects of the techniques described in this disclosure.

FIG.5is a flowchart illustrating example operation of the application provider server shown in the example inFIG.1in generating the recovery module for application at the computing device in accordance with the recovery techniques described in this disclosure. Application provider server104may initially obtain a faulty application indication (FAI)137(“FAI137”) identifying faulty application120B hosted for distribution by application provider server104(500). As noted above, faulty application120B may have an issue occurring during execution of faulty application120B by user computing device102.

As shown in the example ofFIG.1. application provider server104may include a UI module134and a recovery system136. UI module134may be similar to, and possibly the same as, UI module114in terms of operation to present a user interface, such as a graphical user interface. A developer of application120may interface with UI module134(typically via a remote computing system via a web browser or other application) to initiate a recovery process. Upon initiating a recover process via UI module134, application provider server104may invoke recovery system136.

Recovery system136may interface with UI module134to present various user interfaces with which the developer of application120may interact to specify FAI137(as discussed above with respect to the examples ofFIGS.4A-4E). The developer may specify FAI137by identifying a particular application (e.g., by name) and version (e.g., by number), which effectively selects one or more versions of application120. FAI137may enable recovery module140to target one or more versions of application120that are faulty.

Recovery system136may further interface with the developer via user interfaces presented by UI module134to identify a type of the issue occurring during execution of faulty application120B. In this respect, FAI137may include an issue indication that identifies the issue experienced during execution of faulty application120B by user computing device102. Recovery system136may next select. based on the issue indication, one of template code139A-139N (“template code139” or “templates139”) that targets the issue occurring during execution of faulty application120B by user computing device102. Recovery system136may next populate, based on the issue indication, the selected one of templates139to obtain populated template code configured to resolve the issue occurring during execution of faulty application120B by user computing device102.

Recovery system136may interface with UI module134to present, via the user interface. the populated template code. The developer may interface with the user interface to confirm or reject populated template code (or, in some instances, make changes to the populated template code). Assuming the developer approves of the populated template code, recovery system136may compile the populated template code to obtain recovery module140. Recovery module140may extend faulty application120B through an enhancement, which is linked to faulty application120B through various mechanisms described in more detail above. In this respect, recovery system136may generate, based on FAI137, dedicated recovery module140separate from and that extends faulty application120B (502). In order to output recovery module140, recovery system136may link recovery module140to faulty application120B to enable recovery module140to be output to user computing device102in the manner described above (504). User computing device102may, at some point after recovery module140is linked to application120B, attempt to initiate execution of faulty application120B (506). Upon initiating the execution of faulty application120B. faulty application120B may interface with app installer116(which is a proxy for the application store) to identify linked updates (or, in other words, sub-packages) for faulty application120B, including linked recovery module140(508). Responsive to determining that recovery module140has been linked to faulty application120B, app installer116interfaces with recovery system136to retrieve (or, in this example, download via network106) recovery module140(e.g., transmit a request for linked updates:510). As such, application provider server104may receive the request for linked updates (512) and output, to user computing device102, recovery module140(514).

User computing device102may receive, from application provider server104, recovery module140(516). User computing device102may next execute recovery module140(518) to resolve the issue occurring during execution of faulty application120B by user computing device102. Recovery module140may resolve the issue in a number of different ways depending on the issue identified by issue identification and as described in more detail above.

Various aspects of the techniques may enable various examples set forth below with respect to the following clauses.

Clause 1. A method comprising: receiving, by one or more processors of a server computing device hosting distribution of a plurality of applications, a faulty application indication identifying a faulty application of the plurality of applications, the faulty application having an issue that occurs during execution of the faulty application by a user computing device: generating, by one or more processors of the server computing device and based on the faulty application indication, a dedicated recovery module that extends the faulty application: and outputting, by the one or more processors of the server computing device and to the user computing device, the dedicated recovery module to resolve the issue that occurs during execution of the faulty application.

Clause 2. The method of clause 1, wherein the faulty application indication identifies a name and a version associated with the faulty application, and wherein generating the dedicated recovery module comprises generating the dedicated recovery module to target the faulty application identified by the name and the version associated with the faulty application.

Clause 3. The method of any combination of clauses 1 and 2, wherein the dedicated recovery module is a separate application sub-package added to an application package used to install the faulty application, and wherein the separate application sub-package extends the application package used to install the faulty application.

Clause 4 The method of any combination of clauses 1-3, wherein generating the dedicated recovery module comprises separately compiling the dedicated recovery module from the faulty application.

Clause 5. The method of any combination of clauses 1-4, wherein the dedicated recovery module is configured to delete or edit a file installed by the faulty application.

Clause 6. The method of any combination of clauses 1-4, wherein the dedicated recovery module is configured to delete or edit a cache associated with the faulty application.

Clause 7 The method of any combination of clauses 1-4, wherein the dedicated recovery module is configured to delete or edit a database associated with the faulty application.

Clause 8. The method of any combination of clauses 1-4, wherein the dedicated recovery module is configured to delete or edit an experimental parameter associated with the faulty application.

Clause 9. The method of any combination of clauses 1-4, wherein the dedicated recovery module is configured to prompt an update to the faulty application.

Clause 10. The method of any combination of clauses 1-9, wherein receiving a faulty application indication comprises: presenting a user interface configured to prompt a developer of the faulty application to enter the faulty application indication; and receiving, via the user interface. the faulty application indication.

Clause 11. The method of any combination of clauses 1-10, wherein the faulty application indication includes an issue indication that identifies the issue experienced during execution of the faulty application by the user computing device. and wherein generating the dedicated recovery application comprises: selecting, based on the issue indication, template code that targets the issue occurring during execution of the faulty application by the user computing device; populating, based on the issue indication, the template code to obtain populated template code configured to resolve the issue occurring during execution of the faulty application by the user computing device; and compiling the populated template code to obtain the dedicated recovery module.

Clause 12. The method of any combination of clauses 1-11, wherein the issue occurring during execution of the faulty application by the user computing device includes a failure to execute the faulty application in a manner that enables user interaction with the faulty application.

Clause 13. A server computing device comprising: a memory configured to store a faulty application indication identifying a faulty application of a plurality of applications hosted for distribution by the server computing device. the faulty application having an issue occurring during execution of the faulty application by a user computing device; and one or more processors configured to: generate, based on the faulty application indication, a dedicated recovery module that extends the faulty application: and output, to the user computing device, the dedicated recovery module to resolve the issue occurring during execution of the faulty application.

Clause 14. The server of clause 13, wherein the faulty application indication identifies a name and a version associated with the faulty application, and wherein the one or more processors are, when configured to generate the dedicated recovery module, configured to generate the dedicated recover module to target the faulty application identified by the name and the version associated with the faulty application.

Clause 15. The server of any combination of clauses 13 and 14, wherein the dedicated recovery module is a separate application sub-package added to an application package used to install the faulty application, and wherein the separate application sub-package extends the application package used to install the faulty application.

Clause 16. The server of any combination of clauses 13-15, wherein the one or more processors are. when configured to generate the dedicated recovery module, configured to separately compile the dedicated recovery module from the faulty application.

Clause 17. The server of any combination of clauses 13-16, wherein the dedicated recovery module is configured to delete or edit a file installed by the faulty application.

Clause 18. The server of any combination of clauses 13-16, wherein the dedicated recovery module is configured to delete or edit a cache associated with the faulty application

Clause 19. The server of any combination of clauses 13-16, wherein the dedicated recovery module is configured to perform one or more of delete or edit a database associated with the faulty application, and delete or edit an experimental parameter associated with the faulty application.

Clause 20. A non-transitory computer-readable storage medium having instructions stored thereon that, when executed, cause one or more processors of a server computing device to: receive a faulty application indication identifying a faulty application of a plurality of applications hosted for distribution by the server computing device, the faulty application having an issue occurring during execution of the faulty application by a user computing device; generate, based on the faulty application indication, a dedicated recovery module that extends the faulty application; and output, to the user computing device, the dedicated recovery module to resolve the issue occurring during execution of the faulty application.

Clause 1A. A method comprising: storing, by one or more processors of a user computing device, a faulty application that presents an issue during execution by the one or more processors; receiving, by one or more processors and from a server computing device that hosts distribution of a plurality of applications including the faulty application, a dedicated recovery module that extends the faulty application; and executing, by the one or more processors, the dedicated recovery module to resolve the issue occurring during execution of the faulty application.

Clause 2A. The method of clause 1A, further comprising executing the faulty application which invokes the execution of the dedicated recovery module to resolve the issue occurring during execution of the faulty application.

Clause 3A. The method of any combination of clauses 1A and 2A, wherein the dedicated recovery module is a separate application sub-package from an application package used to install the faulty application, and wherein the separate application sub-package extends the application package used to install the faulty application.

Clause 4A. The method of any combination of clauses 1A-3A, wherein the dedicated recovery module is separately compiled from the faulty application.

Clause 5A. The method of any combination of clauses 1A-4A, wherein executing the dedicated recovery module comprises executing the dedicated recovery module to delete or edit a file installed by the faulty application.

Clause 6A. The method of clause SA. wherein executing the dedicated recovery module comprises executing the dedicated recovery module to delete or edit a cache associated with the faulty application.

Clause 7A. The method of clause 5A, wherein executing the dedicated recovery module comprises executing the dedicated recovery module to delete or edit a database associated with the faulty application.

Clause 8A. The method of clause 5A, wherein executing the dedicated recovery module comprises executing the dedicated recovery module to delete or edit an experimental parameter associated with the faulty application.

Clause 9A. The method of any combination of clauses 1A-4A, wherein executing the dedicated recovery module comprises executing the dedicated recovery module to prompt an update to the faulty application.

Clause 10A. The method of any combination of clauses 1A-9A, wherein the issue occurring during execution of the faulty application by the user computing device includes a failure to execute the faulty application in a manner that enables user interaction with the faulty application.

Clause 11A. A user computing device comprising: a memory configured to store a faulty application. the faulty application having an issue occurring during execution of the faulty application by the user computing device: and one or more processors configured to: receive, from a server computing device that hosts distribution of a plurality of applications including the faulty application, a dedicated recovery module that extends the faulty application; and execute, by the one or more processors, the dedicated recovery module to resolve the issue occurring during execution of the faulty application.

Clause 12A. The user computing device of clause 11A, wherein the one or more processors are further configured to execute the faulty application which invokes the execution of the dedicated recovery module to resolve the issue occurring during execution of the faulty application.

Clause 13A. The user computing device of any combination of clauses 11A and 12A, wherein the dedicated recovery module is a separate application sub-package from an application package used to install the faulty application. and wherein the separate application sub-package extends the application package used to install the faulty application.

Clause 14A. The user computing device of any combination of clauses 11A-13A, wherein the dedicated recovery module is separately compiled from the faulty application.

Clause 15A. The user computing device of any combination of clauses 11A-14A, wherein the one or more processors are, when configured to execute the dedicated recovery module, configured to execute the dedicated recovery module to delete or edit a file installed by the faulty application.

Clause 16A. The user computing device of clause 15A, wherein the one or more processors are, when configured to execute the dedicated recovery module, configured to execute the dedicated recovery module to delete or edit a cache associated with the faulty application.

Clause 17A. The user computing device of clause 15A, wherein the one or more processors are, when configured to execute the dedicated recovery module, configured to execute the dedicated recovery module to delete or edit a database associated with the faulty application.

Clause 18A. The user computing device of clause 15A, the one or more processors are, when configured to execute the dedicated recovery module, configured to execute the dedicated recovery module to delete or edit an experimental parameter associated with the faulty application.

Clause 19A. The user computing device of any combination of clauses 11A-14A, the one or more processors are, when configured to execute the dedicated recovery module, configured to execute the dedicated recovery module to prompt an update to the faulty application.

Clause 20A. A non-transitory computer-readable storage medium having instructions stored thereon that, when executed, cause one or more processors of a user computing device to: store a faulty application, the faulty application having an issue occurring during execution of the faulty application by the user computing device; receive, from a server computing device that hosts distribution of a plurality of applications including the faulty application, a dedicated recovery module that extends the faulty application; and execute, by the one or more processors, the dedicated recovery module to resolve the issue occurring during execution of the faulty application.