Accessing sensors and devices from a background task (Windows Runtime apps)
DeviceUseTrigger lets your Windows Runtime app access sensors and peripheral devices in the background, even when your foreground app is suspended. For example, depending on where your app is running, it could use a background task to synchronize data with devices or monitor sensors. To help preserve battery life and ensure the appropriate user consent, the use of DeviceUseTrigger is subject to policies that are described in this topic.
To access sensors or peripheral devices in the background, create a background task that uses the DeviceUseTrigger. For an example that shows how this is done on a PC, see the Custom USB device sample. For an example on a phone, see the Background Sensors sample.
Device background task overview
When users move your app off-screen, Windows will suspend or terminate your app to reclaim memory and CPU resources. This allows other apps to run in the foreground and reduces battery consumption. When this happens, without the help of a background task, any ongoing data events will be lost. Windows provides the background task trigger, DeviceUseTrigger, to let your app perform long running sync and monitoring operations on devices and sensors safely in the background, even if your app is suspended. For more info about app lifecycle, see Launching, resuming, and multitasking. For more about background tasks, see Supporting your app with background tasks.
Note In a Windows Store app, syncing a device in the background requires that your user has approved background syncing by your app. The device must also be connected to or paired with the PC, with active I/O, and is allowed a maximum of 10 minutes of background activity. More detail on policy enforcement is described later in this topic.
Limitation: critical device operations
Some critical device operations, such as long running firmware updates, cannot be performed with the DeviceUseTrigger. Such operations can be performed only on the PC, and only by a privileged app that uses the DeviceServicingTrigger. A privileged app is an app that the device's manufacturer has authorized to perform those operations. Device metadata is used to specify which app, if any, has been designated as the privileged app for a device. For more info, see Device sync and update for Windows Store device apps.
Protocols/APIs supported in a DeviceUseTrigger background task
Background tasks that use DeviceUseTrigger let your app communicate over many protocols/APIs, most of which aren't supported by system-triggered background tasks. What's supported depends on where your app is running: on a PC in a Windows Store app, or on a phone in a Windows Phone Store app.
Note Windows Phone Store apps include both Windows Runtime apps and Windows Phone Silverlight apps, unless otherwise noted.
| Protocol | DeviceUseTrigger in a Windows Store app | DeviceUseTrigger in a Windows Phone Store app |
|---|---|---|
| USB | .png) |
.png) |
| HID | |
|
| Bluetooth RFCOMM | |
|
| Bluetooth GATT | |
|
| MTP | |
|
| Network wired | |
|
| Network Wi-Fi | |
|
| IDeviceIOControl | |
|
| Sensors API | |
(Windows Runtime apps only) |
Sensors support in Windows Phone Store apps
When running on a phone, a DeviceUseTrigger background task can access the sensors API only from within a Windows Runtime app. Using a DeviceUseTrigger background task to access the sensors API from within a Windows Phone Silverlight app is not supported.
The sensors API that's listed in the previous table includes all APIs in the Windows.Devices.Sensors namespace, with the exception of the members that begin with "SimpleOrientation." The SimpleOrientation sensor is not supported from a DeviceUseTrigger background task.
HID support for Windows Phone Store apps
Windows Phone Store apps can access the Windows.Devices.HumanInterfaceDevice API from within a DeviceUseTrigger background task if the manufacturer supported the HID protocol for specific devices and provided corresponding device-data to app developers. Refer to your manufacturer’s documentation for a list of supported HID devices as well as the data that you’ll need to implement device discovery. For more info about HID, see Human Interface Devices (HID).
Registering background tasks in the app package manifest
Your app will perform sync and update operations in code that runs as part of a background task. This code is embedded in a Windows Runtime class that implements IBackgroundTask (or in a dedicated JavaScript page for JavaScript apps). To use a DeviceUseTrigger background task, your app must declare it in the app manifest file of a foreground app, like it does for system-triggered background tasks.
In this example of an app package manifest file, DeviceLibrary.SyncContent is the entry point for a background task that uses the DeviceUseTrigger.
<Extensions>
<Extension Category="windows.backgroundTasks" EntryPoint="DeviceLibrary.SyncContent">
<BackgroundTasks>
<m2:Task Type="deviceUse" />
</BackgroundTasks>
</Extension>
</Extensions>
Introduction to using DeviceUseTrigger
To use the DeviceUseTrigger, follow these basic steps. For more info about background tasks, see Supporting your app with background tasks.
- Your app registers its background task in the app manifest and embeds the background task code in a Windows Runtime class that implements IBackgroundTask or in a dedicated JavaScript page for JavaScript apps.
- When your app starts, it will create and configure a trigger object of type DeviceUseTrigger, and store the trigger instance for future use.
- Your app checks whether the background task has been previously registered and, if not, registers it against the trigger. Note that your app isn't allowed to set conditions on the task associated with this trigger.
- (Phone only) When your app needs to trigger the background task on a phone, it must first call RequestAccessAsync to check if the app is able to request a background task. This check is not required when your app is running on a PC.
- If the app can request the background task, it calls the RequestAsync activation method on the device trigger object.
- Your background task isn’t throttled like other system background tasks (there's no CPU time quota) but will run with reduced priority to keep foreground apps responsive.
- Windows will then validate, based on the trigger type, that the necessary policies have been met, including requesting user consent for the operation before starting the background task.
- Windows monitors system conditions and task runtime and, if necessary, cancels the task if the required conditions are no longer met.
- When the background tasks reports progress or completion, your app will receive these events through progress and completed events on the registered task.
Important
Consider these important points when using the DeviceUseTrigger:
The ability to programmatically trigger background tasks that use the DeviceUseTrigger was first introduced in Windows 8.1 and Windows Phone 8.1.
Certain policies are enforced by Windows to ensure user consent when updating peripheral devices on the PC.
Additional polices are enforced to preserve user battery life when syncing and updating peripheral devices.
Background tasks that use DeviceUseTrigger might be canceled by Windows when certain policy requirements are no longer met, including a maximum amount of background time (wall clock time). It's important to consider these policy requirements when using these background tasks to interact with your peripheral device.
Tip To see how these background tasks work, download a sample. For an example that shows how this is done on a PC, see the Custom USB device sample. For an example on a phone, see the Background Sensors sample.
User consent (PC only)
When your app uses a DeviceUseTrigger background task on a PC, the user is prompted with a one-time user consent that allows your app to sync/monitor in the background. This consent is stored per-app and per-device model. The user consents to let the app access the device in the background just like they consent to let the app access the device when the app is in the foreground.
Note In a Windows Phone Store app, DeviceUseTrigger does not require user consent. The user can manage all background tasks with the Battery Saver app.
In the following example, an app named Tailspin Toys is getting user permission to sync in the background.
.png)
If users change their minds later, on a PC, they can revoke permissions in Settings. (On a phone, background tasks are managed with the Battery Saver app.)
.png)
Frequency and foreground restrictions
There is no restriction on the frequency with which your app can initiate operations, but your app can run only one DeviceUseTrigger background task operation at a time (this does not affect other types of background tasks), and can initiate a background task only while your app is in the foreground. When your app isn't in the foreground, it is unable to initiate a background task with DeviceUseTrigger. Your app can't initiate a second DeviceUseTrigger background task before the first background task has completed.
Device restrictions
While each app is limited to registering and running only one DeviceUseTrigger background task, the device (on which your app is running) may allow multiple apps to register and run DeviceUseTrigger background tasks. Depending on the device, there may be a limit on the total number of DeviceUseTrigger background tasks from all apps. This helps preserve battery on resource-constrained devices. See the following table for more details.
From a single DeviceUseTrigger background task, your app can access an unlimited number of peripheral devices or sensors - limited only by the supported APIs and protocols that were listed in the previous table. For example, a phone app could use a DeviceUseTrigger background task to collect data from an accelerometer, compass, and inclinometer (when available on the phone).
Background task policies
Windows enforces policies when your app uses a DeviceUseTrigger background task. If these policies aren't met, the background task might be canceled. It's important to consider these policy requirements when using this type of background task to interact with devices or sensors.
Task initiation policies
This table indicates which task initiation policies apply, depending on where your app is running.
Note Windows Phone Store apps include both Windows Runtime apps and Windows Phone Silverlight apps.
| Policy | DeviceUseTrigger in a Windows Store app | DeviceUseTrigger in a Windows Phone Store app |
|---|---|---|
| Your app is in the foreground when triggering the background task. | |
|
| The device is attached to the system (or in range for a wireless device). | |
|
| The device is accessible to the app using the supported device peripheral APIs (the Windows Runtime APIs for USB, HID, Bluetooth, Sensors, and so on). If your app can't access the device or sensor, access to the background task is denied. | |
|
| Background task entry point provided by the app is registered in the app package manifest. | |
|
| Only one DeviceUseTrigger background task is running per app. | |
|
| The maximum number of DeviceUseTrigger background tasks has not yet been reached on the device (on which your app is running). | An unlimited number of tasks can be registered and run in parallel. | Phones with 512MB RAM are limited to 1. Phones with larger memory are limited to 2. |
| The maximum number of peripheral devices or sensors that your app can access from a single DeviceUseTrigger background task, when using the supported APIs/protocols. | unlimited | unlimited |
| Your background task consumes 400ms of CPU time (assuming a 1GHz CPU) every minute when the screen is locked, or every 5 minutes when the screen is not locked. Failure to meet this policy can result in cancellation of your task. | |
|
| The user has given the task permission to continue. | The user is prompted the first time, then permissions are managed in the Settings charm by tapping Permissions. | All background tasks on a phone are managed with the Battery Saver app. |
Runtime policy checks
Windows enforces the following runtime policy requirements while your task is running in the background. If any of the runtime requirements stops being true, Windows will cancel your device background task.
This table indicates which runtime policies apply, depending on where your app is running.
Note Windows Phone Store apps include both Windows Runtime apps and Windows Phone Silverlight apps.
| Policy check | DeviceUseTrigger in a Windows Store app | DeviceUseTrigger in a Windows Phone Store app |
|---|---|---|
| The device is attached to the system (or in range for a wireless device). | |
|
| Task is performing regular I/O to the device (1 I/O every 5 seconds). | |
|
| App has not canceled the task. | |
|
| Wall-clock time limit – the total amount of time your app’s task can run in the background. | 10 minutes | |
| App has not exited. | |
|
Best practices
The following are best practices for apps that use the DeviceUseTrigger background tasks.
Programming a background task
Using the DeviceUseTrigger background task from your app ensures that any sync or monitoring operations started from your foreground app continue to run in the background if your users switch apps and your foreground app is suspended by Windows. We recommend that you follow this overall model for registering, triggering, and unregistering your background tasks:
(Phone only) Call RequestAccessAsync to check if the app is able to request a background task. This must be done before registering a background task on a phone. This step is not required on a PC.
Register the background task before requesting the trigger.
Connect progress and completion event handlers to your trigger. When your app returns from suspension, Windows will provide your app with any queued progress or completion events that can be used to determine the status of your background tasks.
Close any open device or sensor objects when you trigger your DeviceUseTrigger background task so that those devices or sensors are free to be opened and used by your background task.
Register the trigger.
Carefully consider the battery impact of accessing a device or senor from a background task. For example, having the report interval of a sensor run too frequently could cause the task to run so often that it quickly drains a phone's battery.
When your background task completes, unregister it.
Register for cancellation events from your background task class. Registering for cancellation events will allow your background task code to cleanly stop your running background task when canceled by Windows or your foreground app.
On app exit (not suspension), unregister and cancel any running tasks if your app no longer needs them. On resource-constrained systems, such as low-memory phones, this will allow other apps to use a DeviceUseTrigger background task.
When your app exits, unregister and cancel any running tasks.
When your app exits, your background tasks will be canceled and any existing event handlers will be disconnected from your existing background tasks. This prevents you from determining the state of your background tasks. Unregistering and canceling the background task will allow your cancellation code to cleanly stop your background tasks.
Cancelling a background task
To cancel a task running in the background from your foreground app, use the Unregister method on the BackgroundTaskRegistration object you use in your app to register the DeviceUseTrigger background task. Unregistering your background task by using the Unregister method on BackgroundTaskRegistration will cause the background task infrastructure to cancel your background task.
The Unregister method additionally takes a Boolean true or false value to indicate if currently running instances of your background task should be canceled without allowing them to finish. For more info, see the API reference for Unregister.
In addition to Unregister, your app will also need to call BackgroundTaskDeferral.Complete. This informs the system that the asynchronous operation associated with a background task has finished.
Related topics
Background Sensors sample (phone only)
Custom USB device sample (PC only)