Disclosed are systems, methods, and articles for determining compatibility of a mobile application and operating system on a mobile device. In some aspects, a method includes receiving one or more data values from a mobile device having a mobile medical software application installed thereon, the data value(s) characterizing a version of the software application, a version of an operating system installed on the mobile device, and one or more attributes of the mobile device; determining whether the mobile medical software application is compatible with the operating system by at least comparing the received data value(s) to one or more test values in a configuration file; and sending a message to the mobile device based on the determining, the message causing the software application to operate in one or more of a normal mode, a safe mode, and a non-operational mode.

Described embodiments include methods and systems for managing client-side services. An intermediary may receive metadata from a first client device of the plurality of client devices. The metadata can include runtime characteristics of a first instance of a service that is incorporated into a client-side application or a web application. The first instance may execute on the first client device and request service data from the at least one server. The intermediary can detect an anomaly in the operation of the first instance of the service. The intermediary can identify an operation of the first instance of the service causing the detected anomaly. The intermediary can, responsive to the detected anomaly, cause delay, removal or modification of operations corresponding to the identified operation, in other instances of the service executing on the plurality of client devices.

A method includes receiving, by an electronic device, an instruction for wiping data or performing a factory reset, setting an identifier according to the instruction, shutting down or restarting electronic device, reading the identifier when the electronic device is powered on or is connected to a network, sending a request to a server to request the server to delete a security service from a secure element (SE), receiving a command from the server, where the command instructs the electronic device to delete a target security service from the SE, and the target security service is based on a security service installed in the SE and a list of deletable security services stored in the server, and deleting, a secure element applet corresponding to the target security service from the SE according to the first command.

An embodiment may involve, in response to determining that a software service satisfies a degradation criterion, generating an alert that indicates the software service and a change request specifying that configuration data used by the software service was changed in a current snapshot of the configuration data; based on the change request, determining a set of configuration changes between the current snapshot and a previous snapshot of the configuration data; and providing a representation of the set of configuration changes indicating one or more parameters that were changed in the current snapshot and one or more paths in a tree-based arrangement of the configuration data that lead to the one or more parameters that were changed in the current snapshot.

A configuration is generated for a software that is to be deployed for providing high service availability to satisfy configuration requirements. One or more configuration patterns are identified, each of which specifies a set of attribute values and an actual recovery action for a failed component as a configuration option of the software. The unchangeable attribute values of the software are matched with the configuration patterns to obtain a matching configuration pattern, whose actual recovery action incurs a smallest component failure recovery impact zone. The matching configuration pattern is selected as at least a portion of the configuration of the software. Then the changeable attribute values of the software are set to the corresponding attribute values of the matching configuration pattern to satisfy the configuration requirements.

An embodiment may involve, in response to determining that a software service satisfies a degradation criterion, generating an alert that indicates the software service and a change request specifying that configuration data used by the software service was changed in a current snapshot of the configuration data; based on the change request, determining a set of configuration changes between the current snapshot and a previous snapshot of the configuration data; and providing a representation of the set of configuration changes indicating one or more parameters that were changed in the current snapshot and one or more paths in a tree-based arrangement of the configuration data that lead to the one or more parameters that were changed in the current snapshot.

An embodiment may involve, in response to determining that a software service satisfies a degradation criterion, generating an alert that indicates the software service and a change request specifying that configuration data used by the software service was changed in a current snapshot of the configuration data; based on the change request, determining a set of configuration changes between the current snapshot and a previous snapshot of the configuration data; and providing a representation of the set of configuration changes indicating one or more parameters that were changed in the current snapshot and one or more paths in a tree-based arrangement of the configuration data that lead to the one or more parameters that were changed in the current snapshot.

Assets to associate to a data protection policy and configuration information for the policy is received. The configuration information includes a data protection job to perform for the assets and a schedule for the job. A shadow policy is generated including the configuration information from the data protection policy and a retry protocol. The data protection job is performed according to the schedule. A failure of the data protection job for an asset is detected. The asset is moved out of the data protection policy and into the shadow policy. The data protection job for the asset is retried according to the retry protocol in the shadow policy.

Electronic devices having limited memory resources cannot function in a reliable manner when the memory resources have run out. In order to manage such a situation and keep the electronic device operating, a mechanism, called Out Of Memory killer, may be implemented in the electronic device. Such an OOM killer, when an out of memory situation arises, randomly selects a program running on the electronic device and terminates it. The disclosure describes associating a weight to a program running on the electronic device which enables it to determine which programs can be terminated because they are not considered essential and those which cannot be terminated without causing a negative impact on the quality of experience of an end-user. Lower weights are associated with programs that can be terminated, higher weights are associated to essential programs.

A method includes identifying a subset of components of a node that should be loaded during the next boot of the node, storing a list of the identified subset of components in a file outside of a basic input output system, and initiating boot of the node. The method further comprises the basic input output system accessing the file and controlling boot of the node to load only the identified subset of components of the node. Another method stores a plurality of such files, wherein each file is associated with maintenance of a target component of the node. After selecting one of the files, the basic input output system may access the selected file and control boot of the node to load only the subset of components that the selected file indicates should be loaded for purposes of a maintaining or testing the target component.