Rediger

Del via


Design Considerations for Custom Devices

This topic describes design considerations that can help you determine whether your device needs a custom driver.

Determining the type of driver to implement

This table describes when you should develop a custom driver for your device and communicate with it by using the Device Access API, and when you should use Windows-provided device stacks instead.

To support Implementation
Well-known devices, including:
  • Sensor
  • Location
  • Webcam
  • Proximity
  • Short message service (SMS)
  • Mobile broadband

For many types of well-known devices, you don't need a custom driver, because Windows includes APIs and class-extension device driver interfaces (DDIs) that manage the communication between the driver and Windows. Sensor, location, and Windows Portable Device (WPD) devices are some examples of device classes that have this support. If you build a driver that uses one of these Windows-provided DDIs to send and receive data and commands, there's no need for your Windows Store app to use the Device Access API to broker access or send input/output (I/O) control codes directly to the driver.
When a Windows Store app requests access to a well-known device by using the Windows Runtime API for its device class, Windows 8 will handle device access based on the type of device. Apps will always get access to some well-known types of devices (such as accelerometers) that don't reveal any personally identifiable information. Other types of well-known devices must be declared in the application manifest before an app can access them. The user must grant permission for an app to access devices that reveal sensitive information, like location, webcam, and microphone devices, or can cost the user money, like mobile broadband devices.
A WPD device that implements MTP services.
You can use the MTP class driver, or you can build a driver by using the WPD DDI.
Windows 8 provides support for MTP device services.And an app can use the Windows.Devices.Portable Windows Runtime API, the Portable Device Component Object Model (COM) API, or WPD Automation to access the device. Your app doesn't need to use the Device Access API.
A device that doesn't have a Windows-provided class extension or class driver.
In this case, consult the UWP device apps for internal devices for specialized devices to determine whether you must implement custom driver access by using the Device Access API.

Security considerations

The following articles provide guidance for writing secure C++ code:

Custom Driver Access Sample, UWP device apps for internal devices, Hardware Dev Center