Understanding Access Denied when working with ISensor::GetState() and ISensor::GetProperty()

In last week’s blog post we provided best practice guidance for Sensor State management in Location Sensors. At the bottom of that post we mention that SENSOR_STATE_ACCESS_DENIED is reserved and should only be used by the Platform. As a follow-on post we wanted to briefly dig into an issue that some customers have reported related to SENSOR_STATE_ACCESS_DENIED.

As mentioned above - this blog topic is actually based on a question from one of our customers. The customer in question, a driver developer, had noticed that if access was denied to their sensor in the Location and Other Sensors Control Panel that they could get different answers for Sensor State depending on where they asked the question in the Sensor API.

Let’s take the following scenario:

1. You have a Sensor Device running on your machine.

2. You know the device is currently reporting a Sensor State of SENSOR_STATE_READY

3. You open the Location and Other Sensors Control Panel.

4. You disable access to your sensor device.

Now here is where it can get interesting. When you call the following two methods you might expect to get the same response for the state of your sensor – but you don’t:

• Calling ISensor::GetState() will return the state of SENSOR_STATE_ACCESS_DENIED.

• Calling ISensor::GetProperty() with an input Property Key of SENSOR_PROPERTY_STATE will return SENSOR_STATE_READY.

The driver partner mentioned above asked the question: Why?

To answer this question we need to briefly discuss where permissions are managed in the Sensor API. I should note that this will be a very brief discussion on permissions management. We expect to have additional posts coming that dig into the subject of permissions in greater detail.

A brief introduction into Permissions:

In an earlier blog post we provided this diagram as an example for how the Sensor Platform is designed:

As you can see in this diagram the Sensors Class Extension and the Sensor API both talk to the Location and Other Sensors Control Panel. The Sensors Class Extension working with the Location and Other Sensors Control Panel provide the permissions infrastructure for the Platform. When you change permissions in the Location and Other Sensors Control Panel the Sensor API, working with the Sensor Class Extension, will stop granting access to that device. In this way the Sensor Class Extension serves as a kind-of “gate keeper” for accessing sensor devices.

In the example scenario above when you asked the Sensor API for the sensors state via a call to ISensor::GetState() you were essentially asking the platform what state it understood the sensor to be in. In this case, because the platform knows the sensor is Access Denied, it will return a state of SENSOR_STATE_ACCESS_DENIED. Because permissions are managed separate from device properties the platform in this case needs supersede the Sensor State from the device and return SENSOR_STATE_ACCESS_DENIED. Alternatively, when you make a call to ISensor::GetProperty() for property SENSOR_PROPERTY_STATE you are requesting a property directly from the sensor. The Sensor Device, which does not know the platform has denied access to the Sensor, will return its current Sensor State.

We understand that this nuance in Platform behavior has caused some confusion. We will evaluate this in the future.

So which method should you use to access Sensor State?

The guidance we have for application developers is that if you need access to Sensor State then request the state from ISensor::GetState(). Calling ISensor::GetState() will insure that you have the most accurate representation of State from a Sensor Platform perspective.

-- Sensor & Location Platform Team

This posting is provided "AS IS" with no warranties and confers no rights.