07 – Permissions

Situm SDK needs the user to grant some permissions in order to work properly. This section explains the most important, and how they will affect the positioning experience.

Android #

According to Android docs,  application permissions help support user privacy by protecting access to restricted data and restricted actions. Broadly, permissions can be categorized in “Install-time” and “Runtime”.

Install-time permissions declared by Situm SDK #

These permissions allow access to data and actions that extend beyond your app’s sandbox, but the data and actions present very little risk to the user’s privacy, and the operation of other apps. Situm SDK declares a series of these permissions in its Manifest, that will be granted by the user when he installs the app.

Runtime permissions #

Also known as dangerous, they give the app additional access to restricted data, and/or allow the app to perform restricted actions that more substantially affect the system. Situm may require the following runtime permissions.

Runtime permissions need to be declared in the AndroidManifest.xml file of your app.

//AndroidManifest.xml
<manifest>
...
<uses-permission android:name="android.permission.ACCESS_FINE_LOCATION" />
...
</manifest>

Then, at runtime, you will need to ask the user if they wish to grant your app these permissions. 

//MainActivity.java
...
// Warning! This is a naive way to ask for permissions for the example's simplicity
// Check https://developer.android.com/training/permissions/requesting to know how
// to ask for permissions
ActivityCompat.requestPermissions(MainActivity.this, new String[]{Manifest.permission.ACCESS_FINE_LOCATION},0);

You may follow this Android guide for more details on this topic.

Sensor access #

These are the most common things to take into account that Situm SDK needs to have access to sensors. We recommend the app developer to implement mechanisms to ensure that the user does not disable any option that is critical for its use case (e.g. detecting the state of each sensor and asking the user to change it if required).

iOS #

As in Android, iOS apps running Situm will need certain permissions. These permissions can be configured from XCode tab “Settings/Info”, by creating the following keys:

• NSLocationAlwaysAndWhenInUseUsageDescription. In XCode: “Privacy – Location Always and When In Use Usage Description”.
• NSLocationWhenInUseUsageDescription. In XCode: “Privacy – Location When In Use Usage Description”.
• NSBluetoothPeripheralUsageDescription. In XCode: “Privacy – Bluetooth Peripheral Usage Description”.
• NSBluetoothAlwaysUsageDescription (only if you are targeting iOS 13.0 or superior). In XCode: “Privacy – Bluetooth Always Usage Description”.

You will also need to add a description to each key, which will be shown to the user at the time the app request each specific permission. For example, to ask for Bluetooth usage you can add the key “NSBluetoothAlwaysUsageDescription” with the description “Location and Bluetooth is required to find out where you are”.

Lastly, you need to include the following snippet in your app’s code so the system requests location permissions to the user. If your don’t do this or the user doesn’t grant the permissions, your app won’t receive Situm location information. You will have an example on how to use this function in the Start Positioning Section of our Swift Quickstart Guide.

var coreLocationManager:CLLocationManager = CLLocationManager()
...

func requestLocationAuth(){
   if CLLocationManager.locationServicesEnabled() {
      let status: CLAuthorizationStatus = CLLocationManager.authorizationStatus()
      if status == CLAuthorizationStatus.notDetermined {
          coreLocationManager.requestAlwaysAuthorization()
          //or
          coreLocationManager.requestWhenInUseAuthorization()
      }
   }
}

Sensor access #

Contrary to Android, iOS does not allow to scan WiFi signals. However, BLE and Location are used in iOS, just like in Android. As in Android, the developer should implement the appropriate mechanisms to ensure that the user does not disable any option that is critical for its use case (e.g. detecting the state of each sensor and asking the user to change it if required).