to your device. However, this isn't a complete list of the contracts and extensions available to Windows Store device apps, and your app is free to use any other provided capabilities as well. Contract Description Example Uses Search When you participate in this contract, you agree to make your app's content searchable by other participants. Allow the user to search the content on your device from the Search charm. Share Apps that support the sharing contract can automatically share content to and from any other app that also supports the contract. As the source, you can share content from your device with another app, like sending content from your device through another app to a social media site. As the target, you can receive content from another app to store on your device, like pushing a photo from a social media app onto your device. Picking You can help users pick files from one app directly within another app. Users gain freedom and flexibility to choose files that are stored and presented by apps. As the target, you can allow other apps to access data on your device, allow other apps to save data to your device, and notify other apps when the contents of files from your device have been changed. Settings You can provide quick, access to settings that affect the user's experience with your app. Rather than clutter your app, you can allow users to configure advanced device settings or invoke customized Help through the Settings charm. Handling Device Changes and Errors Windows users are accustomed to connecting and disconnecting their devices, and your Windows Store device app should be able to gracefully handle conditions like: The user launches the app before connecting the device. The user unplugs the device in the middle of an operation, or while your app is in the background and suspended. The user has multiple of your device connected to the PC at the same time and needs to be able to choose which one to interact with. The user has your device connected, but for some reason attempts to access it fail. See the Windows.Devices.Enumeration namespace for further information about how to detect some of the listed conditions.
The component supplier submits device driver to the Windows Dev Center hardware dashboard for certification and distribution via Windows Update. The OEM passes the (Windows App Certification Kit) (WACK) tests for their app that incorporates functionality from the component supplier. The OEM submits the app to Windows Store. The OEM submits the device metadata package to the Windows Dev Center hardware dashboard for distribution via Windows Metadata and Internet Services The OEM can now preload the certified and digitally signed device driver, device metadata, and app. When submitting a privileged app for a PC internal device for Windows Store download, follow the instructions in , but remember that the metadata in this case is the device metadata package for the PC, not for your device. If the app comes from a component supplier and not the OEM, the OEM needs to follow the OEM integration workflow, shown previously, before submitting device metadata. Publishing Device Drivers More information about authoring and validating drivers is available in on MSDN®. Your custom drivers must pass the appropriate Windows Hardware Certification Kit tests before submission. Once the drivers pass, they should be submitted to the so they can be preinstalled. The user shouldn't be required to run any desktop installation program before your device driver is available. Custom drivers should be submitted before your app or device metadata. IMPORTANT Device access using custom drivers requires approval from Microsoft. OEMs and IHVs that want to implement device access for a specialized device using a custom driver should first contact their Microsoft contact to discuss their scenario with the Windows Ecosystem team. For more information see the Custom Driver Access Model section. Because your app needs custom access to a restricted device, when submitting device metadata, you need to choose "This device has associated logo or unclassified submissions …" under Bind to logo submissions. This option requires that you provide the submission ID from the driver submission. This allows the dashboard to verify that the custom drivers have passed the Device.DevFundCDA portion of the Hardware Certification Requirements. Updating a Windows Store Device App for a PC internal specialized device The process for updating a Windows Store device app is very similar to the process for initial deployment. And the unique elements described previously for specialized devices apply in both cases. The components that come together to enable a Windows Store device app for a specialized device are loosely coupled – there's no tight version binding between
them. Additionally the different components are distributed through different services, with different policies and latencies: App updates are available sometime after being accepted. Users are notified when app updates are available and can download them through the Windows Store app. Device metadata updates are available 48 hours after being accepted and are downloaded automatically for new devices connected to the PC. Device metadata for the PC is automatically updated by a Windows maintenance task every 14 days. Driver updates are available sometime after being accepted, depending upon Windows Update client settings. Users are notified of these optional updates if they check Windows Update, where they can download and apply the driver. The driver can be available as soon as 24 hours, depending upon those settings. Because of the availability time differences, it's likely that the app, device metadata, and custom driver may be of different versions. Components need to cope gracefully if any companion components are unavailable. Only the OEM can deploy device metadata updates to the PC device container. All parties need to be in close communication about the contents of the privileged app fields and driver functional contracts. The component supplier can submit updates to the app and driver to Microsoft portals, but the OEM governs metadata. It's important to understand that Windows 8.1 doesn't automatically install a new driver over an old driver. Aside from that, the sequence for updating your Windows Store device app is the same as the sequence you used to submit it. Design Patterns for Specialized Devices This table summarizes design patterns for different types of devices. You can choose a design pattern based on the protocol used to communicate with the device and the type of device driver. The table also identifies which design patterns have restricted interfaces. The main steps in the planning and implementation of each design pattern and which Windows Runtime APIs to use are outlined after the table. Summary of PC Internal Specialized Device Design Patterns Design Patterns Pattern: WPD with Custom Driver Summary: Intelligent device with functionality that fits into a well-defined object model with properties.
Windows.Devices.Custom.CustomDevice.FromIdAsync method to open your device and the SendIOControlAsync method to transfer information to and from the device. An app can't simply access any device interface it chooses. The app must declare the device interfaces that it accesses in the capabilities section of the app manifest. For the Windows Store device app associated with the Fx2 device, this looks like: <Package xmlns="http://schemas.microsoft.com/appx/2010/manifest"> … <Capabilities> <DeviceCapability Name="573E8C73-0CB4-4471-A1BF-FAB26C31D384" /> </Capabilities> </Package> Development Lifecycle Authoring This checklist describes what to do when authoring the software components for a Windows Store device app that follows the custom driver access design pattern. Note the testing and validation requirements for each component. Component Item Description Device Driver Provide a functional contract through a device interface. The driver provides a custom device interface class GUID for its functional class. Restrict the device interface. The DEVPKEY_DeviceInterface_Restricted property should be set to TRUE on the interface instance of that class. Implement custom functionality. The driver provides IOCTL commands to transfer information to and from Windows Store apps. Follow security requirements. The driver shouldn't specify a security descriptor that grants the AppContainer access to the device. Instead, the driver should grant normal unelevated users access to the device, and rely on the Device Broker to mediate the App's access. Create a driver package. The driver package contains the driver binaries and the .inf file that lists the hardware IDs of the devices the driver should be installed on, and which driver binaries and/or registry settings are required for each. Test and validate. To submit a custom driver to Windows Update the driver must meet the Certification Requirements for your type of device. For a custom access device, the driver must also pass Device.DevFundCDA. Note that this test requires manual intervention, which may increase the costs of testing. Device Metadata PrivilegedApps This element provides the privileged app info for each app, including the Package Name, Publisher, and Access Custom Driver fields. Each privileged app identified checks the Access Custom Driver checkbox