BlackBerry Spark Communications Services Guide

Frequently Asked Questions


What is the sandbox environment?

The sandbox environment is where you develop and test your application in a non-production setting.

The sandbox and production environments are isolated from each other. An application in the sandbox cannot communicate with an application in production.

To learn how to set up the sandbox for your application, see the Download & Configure section of the Getting Started pages.

To learn how to configure your application to use the sandbox instead of production, see the Platform Guides that apply to you.

What is a domain?

Your application is assigned a private domain within the BlackBerry Infrastructure. Everything that your application does within Spark Communications Services is scoped to your domain. Applications from different domains cannot communicate with each other via the SDK.

To learn how to set up the sandbox for your application and get your domain ID, see the Download & Configure section of the Getting Started pages.

What FQDNs are used by the SDK?

The SDK uses different FQDNs for the sandbox and production environments. The complete list of FQDNs used by the SDK is available in a BlackBerry Knowledge Base article.

Can I use a self-signed certificate with my Identity Provider?

No. The BlackBerry Infrastructure can not establish TLS connections with servers that lack a properly signed certificate.

I am concerned about the confidentiality of my end users. Can we host this solution on-site?

Identity management is the responsibility of your application. The BlackBerry Infrastructure identifies your users by their regId, a unique identifier generated by Spark Communications Services for a user. The mapping between regIds and your users' identities (including your users' personally identifiable information) is maintained by you. You can store this information either on or off site, depending on your needs.

The SDK always performs all the cryptographic steps of encrypting and signing data securely before it leaves the endpoint. For most applications, BlackBerry recommends using the SDK's built-in Key Management Service. When your application uses that feature, the SDK synchronizes keys for you automatically.

You can instead choose to use the Cloud Key Storage model, where you are responsible for key distribution. BlackBerry provides guidance and recommendations on how to store and share keys between your users when you use this model. The SDK also comes with example code that demonstrates how to use popular web-storage solutions like Firebase or Azure to securely distribute keys.

Securing communications can be challenging, so the SDK takes care of most steps for you and gives you the tools necessary to securely manage the keys within your application's existing social graph if you choose to do so. Even so, it is important that private key material be kept maximally safe both within your application and when storing it for later recovery or sharing between a user's devices.


Are there any specific ProGuard instructions for using the SDK?

No, there are no specific ProGuard instructions for using the SDK. The SDK AAR contains a set ProGuard rules which will be automatically merged into your application if ProGuard is enabled (usually for a release build).

How can I read the SDK logs?

Make sure your application has configured the SDK to log to files instead of logcat. To do this, add the following to your AndroidManifest.xml.

<meta-data android:name="com.bbm.sdk.LogToFiles" android:value="true" />

Build and deploy a debug version of the application. Then follow the steps below:

  1. Make sure your device is attached to your computer
  2. Open a command prompt or bash shell

Then, to pull the files from the device to your computer:

adb shell rm -rf /sdcard/sdklogs
adb shell run-as com.bbm.example.richchat \
  sh -c "'mkdir /sdcard/sdklogs && cp files/bbm/logs/* /sdcard/sdklogs'"
for /f "usebackq delims=" %x in (`adb shell ls "/sdcard/sdklogs/*"`) do adb pull %x .
adb shell rm -rf /sdcard/sdklogs
adb shell run-as com.bbm.example.richchat sh -c "'mkdir /sdcard/sdklogs && cp files/bbm/logs/* /sdcard/sdklogs'"
adb pull $(adb shell ls '/sdcard/sdklogs/*' |tr '\r' ' ') .

At this point you should have a number of SDK log files.


How can I read the SDK logs?

SDK logs are available in the application sandbox under <sandbox>/Library/bbm/logs.

The application sandbox for local debug builds can be fetched via xCode/Devices selecting your application in the "Installed Apps" section, clicking the "gear" icon and selecting "Download Container".

For production applications, you will need to implement a mechanism for pulling these files from the sandbox via code (copy, zip and emailing them for example). There are some third party utilities that can be used for inspecting the sandbox (iFun Box, etc) though these rely on mechanisms that may not work for all iOS versions.

For the iOS simulator, the sandbox directory can be found on the local filesystem. The simplest way to find this directory for the simulator is to determine the Library folder for your application (via NSSearchPathForDirectoriesInDomains(NSLibraryDirectory, NSUserDomainMask, YES); ) and print that to the console via NSLog when your application starts.

For SDK version R3, some SDK logs are printed directly to the system/debugging console. You can intercept and override the behaviour via the BBMLog.m file, which you must compile into your application.

For SDK version R4+, BBMLog is internal to the SDK framework. All SDK logs can be found in the bbmsdk.txt file in the logs directory.


What MIME types does my web server need to serve?

Please make sure your web server is configured to serve files with the given extensions with the associated MIME type.

File Extension MIME Type
.css text/css
.html text/html
.js application/javascript
.png image/png
.svg image/svg+xml
.wasm application/wasm

Please see the IANA Media Types for appropriate MIME types for serving any other content.

Please see the WebAssembly Web API for more the details on the WebAssembly API expectations, including WebAssembly module MIME type.