Abstract: The disclosed technology adjusts hardware settings to map preferences consistently of a user experience across multiple hardware devices, despite there being different hardware capabilities and performance parameters among the different devices. A hardware settings translation engine receives a reference hardware setting of a reference computing device, a set of reference hardware performance parameter values, and a set of target hardware performance parameter values. The hardware settings translation engine then maps the set of target hardware performance parameter values to the set of reference hardware performance parameter values to yield a hardware adjustment map. The hardware settings translation engine determines the target hardware setting based on the reference hardware adjustment map and the reference hardware setting. The hardware settings translation engine sets the target hardware to the target hardware setting.

Abstract: The disclosed technology provides a provides a method for generating a query. The method includes receiving at least sensed data of a first sensor collected from a first sensor on a querying device and sensed data of a second sensor collected from a second sensor on the querying device. One or more numeric parameters are obtained by transforming the sensed data of the first sensor. The sensed data of the second sensor is analyzed to identify one or more features using pattern recognition and the one or more features are extracted from the sensed data of the second sensor. The method further includes generating a query based at least on the numeric parameters obtained from the sensed data of the first sensor and the features extracted from the sensed data of the second sensor.

Abstract: The disclosed technology provides a multiapplication workflow engine. The multiapplication workflow engine includes a request processing engine, a multiapplication workflow configuration manager, and a multiapplication workflow execution engine. The request processing engine is configured to receive instructions to execute a multiapplication workflow. The multiapplication workflow defines two or more operations and provides a functionality definition corresponding to each of the operations and an interface definition corresponding to each of the operations. The interface defintions of each operation are defined so that operations that execute successively have compatible interface definitions. The multiapplication workflow configuration manager is configured to instatiate one or more applications that satisfy the interface definition and the functionality definition for each operation in a protected execution environment, where the applications are configured to communicate via compatible interfaces.

Abstract: The disclosed technology adjusts hardware settings to map preferences consistently of a user experience across multiple hardware devices, despite there being different hardware capabilities and performance parameters among the different devices. A hardware settings translation engine receives a reference hardware setting of a reference computing device, a set of reference hardware performance parameter values, and a set of target hardware performance parameter values. The hardware settings translation engine then maps the set of target hardware performance parameter values to the set of reference hardware performance parameter values to yield a hardware adjustment map. The hardware settings translation engine determines the target hardware setting based on the reference hardware adjustment map and the reference hardware setting. The hardware settings translation engine sets the target hardware to the target hardware setting.

Abstract: A facility for responding to the crash of a computing system subsystem is described. The facility detects a crash of the subsystem. In response to this detecting, the facility provides diagnostic information representing state of the peripheral subsystem to a crash analysis service, and restarts the subsystem without restarting the computing system.

Abstract: Examples for an intelligent watchdog timer for a computing device are described herein. The watchdog timer operates a watchdog counter that repetitively counts a watchdog count interval from an initial value to a final value. The watchdog counter is continually reset if the device is functioning properly. If the watchdog timer is allowed to reach a final count value, a processor reset is initiated. Several components operate to detect the current mode of operation of the processor or an operating system, and predict, in part based on user context, when different power states may occur. The components also forecast when the watchdog timer is scheduled to reach the final count value. Based on the forecasts of when the watchdog timer will reach the final count value and the predictions of future power states of the processor or operating system, the watchdog counter is selectively disabled or reset.

Abstract: In at least one implementation, the described technology provides a method for improving search results. The method includes generating multiple user profiles based on monitored content navigation history associated with a query set. The user profiles are used to modify search results based on a selected user profile. The selected user profile may be used to send re-queries if the received queries do not satisfy a profile-based condition. The selected user profile may be used to filter, rank, and modify the layout of received results to present the modified results to the user.

Abstract: A workbench identifies a plurality of mobile devices that are ready to be flashed and which are tethered to the workbench. The workbench also accesses one or more common payload packets to be flashed to each of the mobile devices from volatile memory of the workbench computing system, as well as one or more uncommon packets that are to be selectively flashed to only a subset of the plurality of mobile devices during the flashing session. Upon accessing and/or formatting the packets, the workbench computing system transmits the common payload packet(s) to the plurality of ready to be flashed mobile devices concurrently, while refraining from making or simultaneously storing a separate copy of the one or more common payload packets in the volatile storage for each of the plurality of mobile devices during the flashing session.

Abstract: Systems, methods and storage devices are configured for facilitating flashing of mobile devices. Some disclosed embodiments include burst flashing mobile devices in such a way as to facilitate a reduction in time required for tethering the mobile devices that are tethered during the flashing session and by transmitting all data required for flashing the device to the volatile memory of the mobile device and de-tethering the mobile device prior to all of the transmitted data being written to the non-volatile memory of the mobile device.

Abstract: A crash dump system in a device includes firmware that determines when an atypical reboot of the device is about to occur and both sets a flag indicating there was an atypical reboot and stores in nonvolatile memory crash dump data based on the type of event that caused the atypical reboot. The crash dump data includes a reboot code indicating the type of event that was detected. When the device is subsequently restarted due to the reboot, the operating system detects that the flag was set, and in response to the flag being set collects and analyzes the crash dump data from the reserved memory. Crash analysis data is generated based on this analysis and sent is to a remote service for possible further action (e.g., analysis, notification of a developer, and so forth).

Abstract: Embodiments relate to a device ecosystem in which devices collect and forward failure data to a control system that collects and analyzes the failure data. The devices record, categorize, transform, and report failure data to the control system. Failures on a device can be counted and also correlated over time with tracked changes in state of the device (e.g., in use, active, powered on). Different types of Mean Time To Failure (MTTF) statistics are efficiently computed in an ongoing manner. A pool of statistical failure data pushed by devices can be used by the control system to select devices from which to pull detailed failure data.

Abstract: A facility for responding to the crash of a computing system subsystem is described. The facility detects a crash of the subsystem. In response to this detecting, the facility provides diagnostic information representing state of the peripheral subsystem to a crash analysis service, and restarts the subsystem without restarting the computing system.

Abstract: Examples for an intelligent watchdog timer for a computing device are described herein. The watchdog timer operates a watchdog counter that repetitively counts a watchdog count interval from an initial value to a final value. The watchdog counter is continually reset if the device is functioning properly. If the watchdog timer is allowed to reach a final count value, a processor reset is initiated. Several components operate to detect the current mode of operation of the processor or an operating system, and predict, in part based on user context, when different power states may occur. The components also forecast when the watchdog timer is scheduled to reach the final count value. Based on the forecasts of when the watchdog timer will reach the final count value and the predictions of future power states of the processor or operating system, the watchdog counter is selectively disabled or reset.

Abstract: A crash dump system in a device includes firmware that determines when an atypical reboot of the device is about to occur and both sets a flag indicating there was an atypical reboot and stores in nonvolatile memory crash dump data based on the type of event that caused the atypical reboot. The crash dump data includes a reboot code indicating the type of event that was detected. When the device is subsequently restarted due to the reboot, the operating system detects that the flag was set, and in response to the flag being set collects and analyzes the crash dump data from the reserved memory. Crash analysis data is generated based on this analysis and sent is to a remote service for possible further action (e.g., analysis, notification of a developer, and so forth).