App permissions

Apps require permissions to access restricted functions, capabilities, and sensitive information on BlackBerry 10 devices.

Some examples of sensitive information include device information, such as the PIN and serial number, as well as information about contacts, calendar entries, and email messages. An app can also access information about the device's location and position. By using this information, you can develop apps that integrate with other apps that users already have on their devices, which helps you provide an exceptional user experience. However, some of this information is considered sensitive and requires special permission to access.

For example, users might not want just any app to be able to access their contact information, so they must grant your application access to the functionality that it needs.

The image to the right shows an example of a permission request. The BlackBerry 10 OS displays a dialog box automatically when a permission request is required, so you don't need to create it yourself in your app. For example, if your app requests access to use the camera and access to shared files, the dialog box prompts the user to allow the app to run with the specified user-granted permissions.

Screen showing multiple permissions in a dialog box on a device.

When your app starts for the first time, the BlackBerry 10 OS displays a dialog box to ask the user to grant the permissions that your app requires. The user is not asked to grant permission when the app runs the next time or even after upgrades or updates. If the user doesn't want to grant the app a permission, the user can clear the check box beside the permission.

Here are some examples of restricted functions or capabilities that require permissions:

  • Peripheral access, such as the microphone or camera on the device
  • Personal information, such as calendar information
  • Platform features or capabilities, such as BlackBerry Hub integration or headless apps

To help protect against potentially malicious code, if your app uses APIs that access restricted functionality without requesting permission, the API returns errors. For example, if your app tries to access a file in a shared folder and your app doesn't include the access_shared permission, you receive a "permission denied" error.

You specify app permissions in the bar-descriptor.xml file of your project. Each permission is included in a separate <permission> element in the file. There are two ways to specify permissions for your app. You can use the Permissions check boxes on the Application tab of your bar-descriptor.xml file or you can add permission elements manually on the Source tab of your bar-descriptor.xml file. For more information, see Specifying permissions.

Users might not grant certain permissions that your app needs to run correctly. If users don't grant these permissions, your app should handle this situation either by closing (with an appropriate error message so the user understands what's happened) or by continuing to run with limited functionality. To learn more, see Handling ungranted permissions.

Types of permissions

Most permissions fall into one or more of the following categories:

User-granted permissions
The user is prompted when the app is first installed and run on the device. The user must explicitly grant your app permission to use the requested functionality or capability.
Restricted permissions
Permissions that require signing for by your app. You can use restricted permissions when your developer account has been granted access to use them. To be granted access to use a restricted permission, you must request permission from BlackBerry and have a vendor account. When you receive approval to use a restricted permission, you can sign your apps for deployment to the BlackBerry World storefront. For more information about applying for a vendor account, see Managing vendor portal accounts.
Developer-driven permissions
These permissions typically enable platform features that the developer uses to improve the experience of their app, such as the use_gamepad permission. These types of permissions are meant to enable platform features that most apps don't require or use, but that are useful in specific use cases.
 
 

Some permissions need other permissions. You don't need to request each nested permission; you need to request the main permission only. The user can choose whether to give your app access to all the permissions under the main permission or a subset of the permissions.

If the user doesn't grant your app a permission that's nested under the main permission, your app can't use that subset of the functionality. For example, under the Connect to BBM permission, the user can choose whether to grant your app access to use the BBM Contact Invites, Profile Updates, both, or neither.

Screen showing the subpermissions for the Connect to BBM permission in a dialog box.

Working with app permissions

There are a few considerations when you work with functionality that requires permissions:

  • Your app presents a dialog box asking for permissions to be granted when it starts. Your app can't request permission to be granted while it is running.

  • When a user changes the permissions for your app in the Settings app while your app is running, the changes are ignored. The user must restart the app to detect the changes that were made to the permissions.

  • You shouldn't assume that your app has the required permission all the time. Users can change app permissions in the Settings app at any time. Users can also grant you permissions that they didn't grant to your app when it was first installed.

  • 10.3.0 and earlier Permissions persist, even when your app is uninstalled. If a user reinstalls your app, the permissions that the user previously granted to your app are active. The user is not prompted to provide permissions when your app is reinstalled.

  • 10.3.1 and later Permissions do not persist. If a user uninstalls your app, the permissions that the user previously granted to your app are removed. The user is prompted to provide permissions when your app is reinstalled.

  • For Personal Information Management (PIM) permissions, the app can access only data in the perimeter where it was installed. For example, an app that the user installs in the work perimeter has been granted the access_pimdomain_calendars permission. The permission allows the user to access calendar information stored in the work perimeter. However, the app can't access calendar information stored in the user's personal perimeter.

  • Restricted and developer-driven permissions often don't prompt the user to grant access to functionality or capabilities. These types of permissions require your developer account to be enabled to use, and sign apps with, the permission. For example, users aren't prompted if the app requests the Run as Active Frame (run_when_backgrounded) permission.

  • The use of restricted and developer-driven permissions often means that your app is subject to a more rigorous review process for acceptance to the BlackBerry World storefront.

Specifying permissions

When you open the bar-descriptor.xml file in the Momentics IDE for BlackBerry, you can click the Application tab to see the list of permissions that you can add to your app. In the Permissions section, you can select check boxes that are associated with each permission that you want your app to have.

When you select a permission, the appropriate <permission> element is added automatically to the bar-descriptor.xml file. You can verify that the element was added by clicking the Source tab.

Screen showing the permissions check boxes in the bar-descriptor.xml file.

Some permissions are not available as a check box on the Application tab of the bar-descriptor.xml file. If you need to add these types of permissions to your app, you can click the Source tab and add the permission using the <permission> element. You can add only permissions that are available in the API level that your app uses.

<permission>access_notify_settings_control</permission>
<permission>access_wifi_public</permission>
<permission>_sys_run_headless</permission>

If you don't specify a permission that is required for your app, the user isn't prompted to grant your app the permission. If your app uses APIs that access restricted functionality without first requesting permission, the API returns errors. Your app must request permission to access all functionality that your app needs.

Handling ungranted permissions

If you are developing an app that requires a permission, you should make sure that the app can handle the case when the user doesn't grant the permission. When your app has a set of requested permissions specified in the bar-descriptor.xml file, the app asks the user to grant the permissions when the app starts.

The user may deny one or more of the requested permissions. Your app won't know that the user denied the permission until it tries to use the API that requires the permission. When an app tries to use an API without the necessary permissions, an error or error code is returned. This behavior helps to protect against the inadvertent use of functionality and potentially malicious code.

Your app can't check which permissions have been granted while the app is running. Your app can only use the functions that require the permission and handle any errors that it encounters.

When an error that could be the result of an ungranted permission occurs, you can display a dialog box that explains the issue to the user and then directs the user to the Settings app with the Application Permissions screen opened. If the permission is critical to the functionality that your app is offering, a dialog box is a good choice because you can offer the user the option to change the permission immediately.

Screen showing a permissions dialog box in a Cascades app.

If the permission isn't necessary but provides additional functionality, you can provide feedback inline with a toast or you can decide to provide no feedback. For example, if your social media app shares the user's current location but the user hasn't granted the access_location_services permission, you can choose to not interrupt the UI with a dialog box because the functionality is not critical.

It's also important to handle situations where a user may grant only a subset of permissions. For permissions that have subpermissions, you should also handle situations where you don't have all the permissions under a main permission.

The following code sample illustrates a way to check for permissions. The code provides an illustration of how to check the error code when your app doesn't have the proper permissions for the Camera API. The error codes are different for different APIs.

If your app tries to use the camera but your app didn't request the use_camera permission, an error code is returned when you call a function from the Camera library. For this reason, you should always write your application logic to handle situations when the necessary permissions aren't available.

#include <assert.h>
#include <bps/bps.h>
#include <bps/dialog.h>
#include <bps/event.h>
#include <bps/navigator.h>
#include <bps/screen.h>
#include <screen/screen.h>
#include <camera/camera_api.h>
                    
#define APP_ZORDER (100)
                    
typedef enum { STATE_STARTUP = 0,
               STATE_CAMERA_READY,
               STATE_VIEWFINDER,
               STATE_TAKINGPHOTO,
               STATE_NOPERMISSION
               } state_t;
                    
static state_t status = STATE_STARTUP;
static dialog_instance_t alert_dialog = NULL;
static bool shutdown = false;
static screen_context_t screen_ctx;
                    
static const char vf_group[] = "viewfinder_window_group";
static camera_handle_t handle = CAMERA_HANDLE_INVALID;
static int main_bps_chid = -1;
                    
char* messageok = "Good! You have the permissions to use the camera.";
char* messagenopermissions = "Oh no! You do not have permission to use the camera. "
                             "To change the permissions, go to Settings > Security and "
                             "Privacy > Application Permissions and grant the Camera "
                             "permission to this app. Close this app and restart it after "
                             "you have granted the necessary permissions.";
                    
// NOTE: In this code sample, we are purposely ignoring some error return codes
// for the sake of clarity. In production level code, check the return codes for errors
// to help isolate bugs with your app
static void check_permission()
{
   camera_error_t err;
   unsigned int num;
   unsigned int i;
   camera_unit_t cams[CAMERA_UNIT_NUM_UNITS];
   camera_unit_t unit;
                    
   // Select a camera unit
   unit = CAMERA_UNIT_REAR;
   fprintf(stderr, "selecting camera unit %d\n", unit);
   err = camera_open(unit,
                     CAMERA_MODE_RW | CAMERA_MODE_ROLL,
                     &handle);
                    
   if (err == CAMERA_EOK) {
      // Set the message to indicate that you have the required permissions.
      // In production code, an error message isn't necessary
      status= STATE_CAMERA_READY;
   }
                    
   if (err == CAMERA_EACCESS){
      // Set the state to indicate that the required permissions are not available
      fprintf(stderr, "camera_open() - no permission: %d\n", err);
      status=STATE_NOPERMISSION;
   }
   return;
}
                    
// This function is used to show the dialog box with the error messages
static int setAndDisplayDialog()
{      
   // Set the message to display to determine whether you have permissions
   char* displaymessage = "";
   if (status == STATE_CAMERA_READY)
       displaymessage = messageok;
   else if (status == STATE_NOPERMISSION)
       displaymessage = messagenopermissions;
   else
       displaymessage = "Not a permission issue.";
       
   // Create a dialog box to display the error message.
   if (dialog_create_alert(&alert_dialog) != BPS_SUCCESS) {
       fprintf(stderr, "Failed to create alert dialog.\n");
       return -1;
   }
                    
   if (dialog_set_alert_message_text(alert_dialog, displaymessage) != BPS_SUCCESS) {
       fprintf(stderr, "Failed to set alert dialog message text.\n");
       dialog_destroy(alert_dialog);
       alert_dialog = 0;
   }
                    
   if (dialog_add_button (alert_dialog, DIALOG_CANCEL_LABEL, 
                          true, NULL, true) != BPS_SUCCESS) {
       fprintf(stderr, "Failed to add button to alert dialog.\n");
       dialog_destroy(alert_dialog);
       alert_dialog = 0;
       return -1;
   }
                    
   if (dialog_show(alert_dialog) != BPS_SUCCESS) {
       fprintf(stderr, "Failed to show alert dialog.\n");
       dialog_destroy(alert_dialog);
       alert_dialog = 0;
   }
                    
}
                    
int main(int argc, char **argv) {
                    
   const int usage = SCREEN_USAGE_NATIVE;
   status = STATE_STARTUP;
   screen_window_t screen_win;
   screen_buffer_t screen_buf = NULL;
   int rect[4] = { 0, 0, 0, 0 };
   int i = APP_ZORDER;
   
   // Create an application window that acts as a background
   screen_create_context(&screen_ctx, 0);
   screen_create_window(&screen_win, screen_ctx);
   screen_create_window_group(screen_win, vf_group);
   screen_set_window_property_iv(screen_win, SCREEN_PROPERTY_USAGE, &usage);
   screen_create_window_buffers(screen_win, 1);
   screen_get_window_property_pv(screen_win, 
                                 SCREEN_PROPERTY_RENDER_BUFFERS,
                                (void **)&screen_buf);
   screen_get_window_property_iv(screen_win, SCREEN_PROPERTY_BUFFER_SIZE, rect+2);
                    
   // Fill the window with black
   int attribs[] = { SCREEN_BLIT_COLOR, 0x00000000, SCREEN_BLIT_END };
   screen_fill(screen_ctx, screen_buf, attribs);
   screen_post_window(screen_win, screen_buf, 1, rect, 0);
   
   // Position the window at an arbitrary z-order
   screen_set_window_property_iv(screen_win, SCREEN_PROPERTY_ZORDER, &i);
                    
   // Request that navigator, dialog, and screen events are sent
   bps_initialize();
   main_bps_chid = bps_channel_get_active();
   screen_request_events(screen_ctx);
   
   // Request that events are sent. A value of 0 indicates that 
   // all events are requested
   dialog_request_events(0);
   navigator_request_events(0);
 
   // Call the function to check for permissions
   check_permission();
   setAndDisplayDialog();
                    
   while (!shutdown) {
      bps_event_t *event = NULL;
   
       // The value of -1 means that the function waits
       // for an event before returning
       bps_get_event(&event, -1);
   
       // Event loop to receive BPS events. In this scenario,
       // receive an event to display the dialog box
       if (event) {
           if (bps_event_get_domain(event) == dialog_get_domain()) {
               int selectedIndex =
                   dialog_event_get_selected_index(event);
                const char* label =
                   dialog_event_get_selected_label(event);
                 const char* context =
                   dialog_event_get_selected_context(event);
                    
           // Further handle and process dialog event here.
           //...
         }
         //
         // App logic in the event loop
         // ...
         //
     }
     //
     // App logic in the event loop
     // ...
     //
   }
                    
   // Clean up when the app is closed or the main loop exits
   screen_stop_events(screen_ctx);
   bps_shutdown();
   screen_destroy_window(screen_win);
   screen_destroy_context(screen_ctx);
   return 0;
}   

Each API handles permissions differently. You should look at every API your app uses that requires a permission and find out what errors you get when the permission has not been granted.

Available permissions

Be sure to check the API reference for the classes that you're working with to determine which permissions you need to add.

ADARP Extend Data Lock

As part of advanced data at rest protection (ADARP), this permission allows your app to extend the time before the work space switches into data lock state. For more information about ADARP, see Sensitive data in the work space.

This permission is restricted. To use this permission, send an email to ADARPAPIRequests@blackberry.com.

This permission is not available as a check box on the Application tab of the bar-descriptor.xml file.

Element value Prompted Restricted Since
_sys_allow_extend_data_lock No Yes  BlackBerry 10.3.1

ADARP Operational Data Domain

As part of advanced data at rest protection (ADARP), this permission allows your app to access the operational data domain. The operational data domain is the part of the sandbox that is available after the user authenticates with the device initially. The operational data domain continues to be available when the work space is in a data lock state. For more information about ADARP, see Sensitive data in the work space.

This permission is not available as a check box on the Application tab of the bar-descriptor.xml file.

Element value Prompted Restricted Since
access_operational_data_domain No No  BlackBerry 10.3.1

ADARP Request Data Lock

As part of advanced data at rest protection (ADARP), this permission allows your app to request that the work space be put in a data lock state. For more information about ADARP, see Sensitive data in the work space.

This permission is not available as a check box on the Application tab of the bar-descriptor.xml file.

Element value Prompted Restricted Since
allow_request_lock No No  BlackBerry 10.3.1

ADARP Run when Data Locked

As part of advanced data at rest protection (ADARP), this permission allows your app to run when the work space is in a data lock state. For more information about ADARP, see Sensitive data in the work space.

This permission is not available as a check box on the Application tab of the bar-descriptor.xml file.

Element value Prompted Restricted Since
run_when_data_locked No No  BlackBerry 10.3.1

ADARP Startup Data Domain

As part of the advanced data at rest protection (ADARP), this permission allows your app to access the startup data domain. The startup data domain is the part of the sandbox that is always available to the app, even if the user has not authenticated against the device yet or if the work space is in a data lock state. For more information about ADARP, see Sensitive data in the work space.

This permission is not available as a check box on the Application tab of the bar-descriptor.xml file.

Element value Prompted Restricted Since
access_startup_data_domain No No  BlackBerry 10.3.1

BlackBerry Messenger

Connect to BBM. You can use this permission to access contact lists and user profiles, invite BBM contacts to download your app, initiate BBM chats and share content from within your app, and stream data between apps.

Element value Prompted Restricted Since
bbm_connect Yes No BlackBerry 10.0.0

Calendar

Access the calendar on the device. This access includes viewing, adding, and deleting calendar appointments.

Element value Prompted Restricted Since
access_pimdomain_calendars Yes No  BlackBerry 10.0.0

Camera

Access data that's received from the cameras on the device. With this permission, your app can take pictures, record videos, and use the flash.

Element value Prompted Restricted Since
use_camera Yes No  BlackBerry 10.0.0

Capture Screen

Take a screen shot or video of any information visible on the screen of the device. This permission also allows the app to share the user's screen.

Element value Prompted Restricted Since
use_camera_desktop Yes No  BlackBerry 10.2.0

Contacts

Access the contacts that are stored on the device. This access includes viewing, creating, and deleting contacts.

Element value Prompted Restricted Since
access_pimdomain_contacts Yes No  BlackBerry 10.0.0

Device Identifying Information

Access unique device identifiers, such as the PIN or the serial number. This permission also allows you to access SIM card information on the device.

Element value Prompted Restricted Since
read_device_identifying_ information Yes No  BlackBerry 10.1.0

Email and PIN Messages

Access the email and PIN messages that are stored on the device. This access includes viewing, creating, sending, and deleting messages.

Element value Prompted Restricted Since
access_pimdomain_messages Yes No  BlackBerry 10.0.0

Gamepad

Access gamepad functionality. This permission also indicates that the app has official gamepad support in the BlackBerry World storefront.

Element value Prompted Restricted Since
use_gamepad No No  BlackBerry 10.0.0

GPS Location

Read the current GPS location of the device.

This permission is deprecated. Use the Location (access_location_services) permission instead.

This permission is not available as a check box on the Application tab of the bar-descriptor.xml file.

Element value Prompted Restricted Since
read_geolocation Yes No

Deprecated: BlackBerry 10.2.0

Hub Accounts

Create a custom account that’s accessible in the BlackBerry Hub. BlackBerry must allow your developer account to sign your app to use this restricted permission. To use this permission, complete the App Permissions Request form.

This permission is not available as a check box on the Application tab of the bar-descriptor.xml file.

Element value Prompted Restricted Since
_sys__manage_pimdomain_ external_accounts No Yes  BlackBerry 10.2.0

Hub Integration

Integrate with the BlackBerry Hub. With this permission, your app can create and manage data in the BlackBerry Hub. BlackBerry must allow your developer account to sign your app to use this restricted permission. To use this permission, complete the App Permissions Request form.

This permission is not available as a check box on the Application tab of the bar-descriptor.xml file.

If you are developing a C app, see Headless applications and Push Service.

For the best user experience, you should integrate with the BlackBerry Hub in a headless app, preferably integrated with the Push Service. This approach ensures that incoming data is updated in the BlackBerry Hub, even when your app is not running, with minimal impact on battery life.

Element value Prompted Restricted Since
_sys_access_pim_unified No Yes  BlackBerry 10.2.0

Internet

Use the Internet connection from a Wi-Fi, wired, or other type of connection to access locations that are not local on the device.

Element value Prompted Restricted Since
access_internet No No  BlackBerry 10.0.0

Location

Access the current location of the device, as well as locations that the user has saved.

Element value Prompted Restricted Since
access_location_services Yes No  BlackBerry 10.0.0

Microphone

Access the audio stream from the microphone on the device.

Element value Prompted Restricted Since
record_audio Yes No  BlackBerry 10.0.0

My Contact Info

Access user information on the device, such as the first name, last name, and BlackBerry ID username of the user currently associated with this device.

Element value Prompted Restricted Since
read_personally_identifiable_ information Yes No  BlackBerry 10.0.0

Narrow Swipe Up

Reduce the width of the region along the bottom bezel of the device that accepts swipe-up gestures. When you use this permission, swipe-up gestures are recognized in a more narrow area along the bottom bezel.

This behavior allows apps that run in landscape orientation, such as games, to use corner regions for menus and virtual gamepads and prevents the game from being sent to the background inadvertently.

This permission is not available as a check box on the Application tab of the bar-descriptor.xml file.

Element value Prompted Restricted Since
narrow_landscape_exit No No

 BlackBerry 10.0.0

Notebooks

Access the content that's stored in notebooks on the device. This access includes adding entries to, and deleting entries from, the notebooks.

Element value Prompted Restricted Since
access_pimdomain_notebooks Yes No  BlackBerry 10.0.0

Notification Control

Change global notification settings. Apps have permission to read their own notification settings.

Element value Prompted Restricted Since
access_notify_settings_control Yes No  BlackBerry 10.2.0

Personal network

Allows this app to use the personal network.

This permission is not available as a check box on the Application tab of the bar-descriptor.xml file.

Due to the potential for misuse of the functionality associated with this permission, apps that use this permission are rigorously reviewed for acceptance to the BlackBerry World storefront.

Element value Prompted Restricted Since
_sys_gain_personal_networking_ group Yes Yes  BlackBerry 10.3.1

Phone

Determine when a user is on a phone call. This access also allows an app to access the phone number assigned to the device and send Dual Tone Multi-Frequency (DTMF) tones.

Element value Prompted Restricted Since
access_phone Yes No  BlackBerry 10.0.0

Phone Audio Overlay

Add audio to a phone call.

Element value Prompted Restricted Since
_sys_inject_voice Yes Yes  BlackBerry 10.3.0

Phone Call Details

View the status of phone calls that are in progress and the phone number of the remote party.

Element value Prompted Restricted Since
read_phonecall_details Yes No  BlackBerry 10.3.0

Phone Call Logs

View the logs of previous incoming or outgoing phone calls.

Element value Prompted Restricted Since
access_pimdomain_calllogs Yes No  BlackBerry 10.3.0

Phone Control

Control the current phone call. This access includes ending a phone call and sending DTMF tones to the phone.

Element value Prompted Restricted Since
control_phone Yes No  BlackBerry 10.2.0

Post Notifications

Post notifications to the notification area of the device screen. This permission does not require the user to grant your app access.

Element value Prompted Restricted Since
post_notification No No  BlackBerry 10.0.0

Push

Access the Push Service to receive and request push messages.

To use the Push Service, you must register with BlackBerry. When you register, you receive a confirmation email message that contains information that your app needs to receive and request push messages. For more information about registering, visit the Push Service documentation.

If you're using the Push Service with BlackBerry Enterprise Service 10 or BlackBerry Device Service, you don't need to register with BlackBerry and you must not specify the Push permission for your app.

Element value Prompted Restricted Since
_sys_use_consumer_push No No  BlackBerry 10.0.0

Run as Active Frame

Perform background processing. Without this permission, your app stops all processing when the user changes focus to another app.

You should use this permission sparingly and only when your app must perform specific processing in the background. Apps that use this permission are rigorously reviewed for acceptance to the BlackBerry World storefront for their use of device battery power.

This permission is useful for apps that play music or manage downloads.

Element value Prompted Restricted Since
run_when_backgrounded No No  BlackBerry 10.0.0

Run in Background

Perform certain tasks in the background, without opening the app, for a short period of time.

Due to the potential for misuse of the functionality associated with this permission, apps that use this permission are rigorously reviewed for acceptance to the BlackBerry World storefront.

Element value Prompted Restricted Since
_sys_run_headless No No  BlackBerry 10.2.0

Run in Background Continuously

Run in the background as a long-running headless app.

Element value Prompted Restricted Since
_sys_headless_nostop No No  BlackBerry 10.2.0

Shared Files

Read and write files that are shared between all apps on the device. With this permission, your app can access pictures, music, documents, and other files that are stored on the user's device, with a remote storage provider, or on a media card.

Element value Prompted Restricted Since
access_shared Yes No  BlackBerry 10.0.0

Smart Card

Encrypt, decrypt, sign, and verify data using a smart card.

This permission is restricted. To use this permission, send an email to SCRinquiries@blackberry.com.

This permission is not available as a check box on the Application tab of the bar-descriptor.xml file.

Element value Prompted Restricted Since
_sys_access_smartcard_api No Yes  BlackBerry 10.3.0

Smart Card Driver

Allow third-party smart card drivers and smart card reader drivers to integrate with the Smart Card service.

This permission is restricted. To use this permission, send an email to SCRinquiries@blackberry.com.

This permission is not available as a check box on the Application tab of the bar-descriptor.xml file.

Element value Prompted Restricted Since
_sys_smart_card_driver No Yes  BlackBerry 10.3.0

Smart Card Extended

Use Application Protocol Data Unit (APDU) for custom commands.

This permission is restricted. To use this permission, send an email to SCRinquiries@blackberry.com.

This permission is not available as a check box on the Application tab of the bar-descriptor.xml file.

Element value Prompted Restricted Since
_sys_access_extended_smart_ card_functionality No Yes  BlackBerry 10.3.0

Text Messages

Access the text messages that are stored on the device. This access includes viewing, creating, sending, and deleting text messages.

Element value Prompted Restricted Since
access_sms_mms Yes No  BlackBerry 10.0.0

Wi-Fi Connection

Receive Wi-Fi event notifications such as Wi-Fi scan results or changes in the Wi-Fi connection state.

This permission also allows limited Wi-Fi control for hotspot aggregator applications that manage network selection and authentication to a hotspot.

This permission doesn't allow the app to force a connection to a specific network profile when there are other available networks that have a higher priority configured on the device. If you want to retrieve or query information about existing Wi-Fi connections, it's not necessary to configure this permission.

Element value Prompted Restricted Since
access_wifi_public No No  BlackBerry 10.2.0

Last modified: 2014-11-17



Got questions about leaving a comment? Get answers from our Disqus FAQ.

comments powered by Disqus