Abstract: A computer-implemented method comprises executing a first application package in a runtime having a first application security context, identifying a dependency element in a second application package, and if the dependency element is associated with the first application package, then executing the second application package within the runtime and security context for the first application package.

Abstract: Systems, methods, and computer-readable storage media are provided for brokering access to peripheral devices and/or device models associated with a computing system. An access broker evaluates requests for access to peripheral devices/models on behalf of a plurality of applications. The access broker evaluates requests for access to peripheral devices including scanners, point-of-sale devices, and devices using ubiquitous device protocols (e.g., USB, HID, Bluetooth, and Bluetooth LE) utilizing application declarations and user consents based upon device model identifiers and/or device-specific identifiers associated with the various devices. Applications may be notified of consent changes at runtime and/or application firmware updates for peripheral devices may be conducted upon receipt of user consent, for instance, to ensure adequate battery power before performing a peripheral device firmware update.

Abstract: Various embodiments initialize a communication link associated with data transfer to a connected state between participants in the communication link. In some cases, the communication link is paired with a first Input/Output (I/O) completion port effective to enable the data transfer. Some embodiments disassociate the communication link with the first I/O completion port and re-initialize the communication link while retaining the connected state. Alternately or additionally, the communication link is paired with at least a second I/O completion port. In some cases, the second I/O completion port utilizes an I/O model that differs from an I/O model associated with the first I/O completion port. Alternately or additionally, the communication link can be reconfigured to follow a IO model that does not utilize an IO completion port at all.

Abstract: Systems, methods, and computer-readable storage media are provided for brokering access to peripheral devices and/or device models associated with a computing system. An access broker evaluates requests for access to peripheral devices/models on behalf of a plurality of applications. The access broker evaluates requests for access to peripheral devices including scanners, point-of-sale devices, and devices using ubiquitous device protocols (e.g., USB, HID, Bluetooth, and Bluetooth LE) utilizing application declarations and user consents based upon device model identifiers and/or device-specific identifiers associated with the various devices. Applications may be notified of consent changes at runtime and/or application firmware updates for peripheral devices may be conducted upon receipt of user consent, for instance, to ensure adequate battery power before performing a peripheral device firmware update.

Abstract: Various embodiments initialize a communication link associated with data transfer to a connected state between participants in the communication link. In some cases, the communication link is paired with a first Input/Output (I/O) completion port effective to enable the data transfer. Some embodiments disassociate the communication link with the first I/O completion port and re-initialize the communication link while retaining the connected state. Alternately or additionally, the communication link is paired with at least a second I/O completion port. In some cases, the second I/O completion port utilizes an I/O model that differs from an I/O model associated with the first I/O completion port. Alternately or additionally, the communication link can be reconfigured to follow a IO model that does not utilize an IO completion port at all.

Abstract: Various embodiments provide a mechanism by which a driver writer can describe the operation set of a particular driver using an intermediary representation, such as an XML. A generation tool can then process the intermediary representation and generate client code and device driver code to support these operations. In one or more embodiments, driver operation and associated elements that support the driver operation can be described according to a customized schema that is specific to the operation of the particular device driver.

Abstract: Embodiments include processes, systems, and devices for brokering application access to capabilities, such as device capabilities. An access broker receives requests from applications to access capabilities. The access broker determines whether to grant access based at least in part on whether the application manifest declares the capability. The access broker also may cause a user interface element to be displayed requesting user consent to the access request. Also, an in-application user interface element is provided that displays capability access settings for a particular application. The in-application user interface element includes selectable options for changing those settings. Changes in those settings via the user interface update the settings in the access broker.

Abstract: Installation data associated with a hardware device is obtained (e.g., at the time the device is installed on a computing device). Identifiers of applications that are allowed to access a capability of the hardware device are identified from the installation data and stored in a device permissions record as being allowed to access the capability of the hardware device. Subsequently, a request to access the capability of the hardware device is received from an application. A check is made as to whether the application is identified in a device permissions record as being allowed to access the capability of the hardware device. The application is allowed to access the capability of the hardware device if the device permissions record indicates the application is allowed to access the capability of the hardware device, and otherwise the request from the application is denied.

Abstract: Various embodiments provide a mechanism by which a driver writer can describe the operation set of a particular driver using an intermediary representation, such as an XML. A generation tool can then process the intermediary representation and generate client code and device driver code to support these operations. In one or more embodiments, driver operation and associated elements that support the driver operation can be described according to a customized schema that is specific to the operation of the particular device driver.