Articles and samples about developing Java applications for BBOS.


    • Error "unable to find valid certification path to requested target" When Installing a BlackBerry Java SDK

      Published Feb 09 2018, 2:18 PM by msohm



      This article applies to the following:

      • BlackBerry® smartphones based on Java® technology




      When attempting install a BlackBerry Java SDK from the update site using the BlackBerry Java Plug-in for Eclipse, the following error is encountered.




      An error occurred while collecting items to be installed
      session context was:(profile=SDKProfile, phase=org.eclipse.equinox.internal.p2.engine.phases.Collect, operand=, action=).
      Unable to read repository at PKIX path building failed: unable to find valid certification path to requested target





      A "man in the middle" appliance exists on the network you are connecting through and is disrupting the connection to the BlackBerry Java update site.




      Connect to a different network to install a BlackBerry Java SDK.

    • Re: Uncaught Illegal State Exception

      Published Feb 09 2018, 2:18 PM by smiley

      You are in the wrong forum. This is BB10.  Post it on the Java forum.


      The problem could be that you can't create your UI object in the thread.

    • RSA Encryption using your Public and Private key how to / example

      Published Feb 09 2018, 2:18 PM by digitalhuman

      Here's a quick sample showing how to encrypt using RSA®. When you encrypt with the public key, only the holder of the private key can decrypt it.


      Remember though - every time you encrypt the same data with the same key - the output will be the same - perfect for an eavesdropper to notice!




      // Get the public key from a PEM encoded RSA certificate
      InputStream stream = getClass().getResourceAsStream("sams.crt");
      byte[] base64bytes = new byte[stream.available()];, 0, base64bytes.length);
      X509Certificate cert = (X509Certificate) CertificateUtilities.readCertificateFile("X509", base64bytes);
      pubKey = (RSAPublicKey) cert.getPublicKey();
      //Initiate the Crypto system
      RSACryptoSystem crypt = crypt = new RSACryptoSystem(2048);  //I used 2048 bits keys


      An now an example method howto encrypt data and return a Base64 string of the encrypted value.


      //Example method to encrypt data with the above objects
      public String encrypt(String data){
        if(data.length() > 0){
         NoCopyByteArrayOutputStream out = new NoCopyByteArrayOutputStream();
         data = data.trim();
         byte[] plain = data.getBytes();  
         RSAEncryptorEngine eng = new RSAEncryptorEngine(this.pubKey);
         PKCS1FormatterEngine fengine = new PKCS1FormatterEngine(eng);
         BlockEncryptor cryptoStream = new BlockEncryptor(fengine, out);
         cryptoStream.write( plain, 0, plain.length );
         byte[] cipherText = out.getByteArray();
         String encMessage = Base64OutputStream.encodeAsString(cipherText, 0, cipherText.length, false, false);
         return encMessage;
         return "";
       catch(Exception err){
        return "";


    • Sample code for listening to and retrieving PIN messages on a BlackBerry device

      Published Feb 09 2018, 2:18 PM by cmy

      //This is just sample code for use as a reference and is in no way optimized and not the only way to achieve this
      // -You could also attach the FolderListener to the entire store and filter messages by type (email vs PIN)
      import net.rim.blackberry.api.mail.Message;
      import net.rim.blackberry.api.mail.Folder;
      import net.rim.blackberry.api.mail.Store.
      public class PINMessaging {
         Store PINStore;
         public PINMessaging(){
            Session session = Session.getDefaultInstance();
            PINStore = session.getStore();
         //Attach FolderListener to all PIN Message folders 
         public void attachListener( FolderListener listener ){
            for( int i=0; i   //Retrieve all messages under a specific folder
         public Message[] retrieveMessages(int folderType){
         for( int i=0; i}


    • Unable to programatically update icon using JDK 5.0

      Published Feb 09 2018, 2:18 PM by royster86


      java.lang error occurs when you try setting the application icon back to the default icon by using BlackBerry® Java® Development Environment 5.0.



      A bug with JDK® 5.0 causes this error to occur.


      Include a copy of the default icon within the project with a different name. Instead of referring to the default icon in the code, refer to the copy of the icon instead.

    • Peer to peer communication with LLCP

      Published Feb 09 2018, 2:18 PM by mwoolley



      This article is another in a series of articles about NFC which are intended to help applications developers exploit NFC from within their own applications for BlackBerry® smartphones such as the BlackBerry® Bold™ 9900 smartphone and the BlackBerry® Curve™ 9360.


      Readers of this article should have some pre-existing knowledge of the fundamental architecture of NFC systems and be familiar with Java®.


      Unless you already have good knowledge of the subjects covered, it’s recommended that you read the earlier articles in this series. Links to these articles can be found at the end of this one.


      As well as covering some of the relevant theory, this article will look at an example application that uses the Logical Link Control Protocol (LLCP) in a peer-to-peer communication scenario. If you don’t know what these terms mean, don’t worry; all will be explained.


      The Authors

      This article was co-authored by Martin Woolley and John Murray both of whom work in the RIM® Developer Relations team. Both Martin and John specialize in NFC applications development (amongst other things).


      About this article


      In a previous article, we looked at peer to peer communications using SNEP, the Simple NDEF Exchange Protocol. That article introduced NFC peer-to-peer mode and the relevant parts of the NFC protocol stack, with SNEP running over LLCP, which is the subject of this article.


      About LLCP


      Whilst SNEP provides a very easy mechanism for pushing a message in NDEF format from one device to another, LLCP gives lower level control over the process and can be used for both one-way and bidirectional exchanges of data. Before we turn our attention to the question of how we can utilize LLCP from a BlackBerry application, let’s review some LLCP theory.

      Like other aspects of NFC, LLCP is defined by the NFC Forum and the full specification is called NFCForum-TS-LLCP_1.0.pdf. The specification explains that the primary responsibilities of LLCP are link activation (establishing an LLCP link between two compatible devices), supervision of the connection and deactivation of the link when required.

      Two transports are defined for LLCP; a connectionless transport and a connection-oriented transport.

      The LLCP connectionless transport operates as an unacknowledged data transmission protocol and doesn’t require any preparatory steps prior to actually sending data. As such, it has a low overhead. The application layer is required to take care of flow control should this be deemed necessary.

      The connection-oriented transport of LLCP offers guaranteed delivery and maintains the sequence of transmitted “service data units”. This transport requires some steps to set it up.

      So in essence, the connectionless and connection-oriented transports each trade reliability against performance.

      LLCP is based upon a client/server model. The client is usually called either the Master or Initiator whilst the server is called the Slave or Target. Service names or service access points can be used to identify endpoints. Service access points include service access point numbers, some of which are reserved by the NFC Forum.

      The NFC Forum attribute a “class” to devices according to the link transport type or types they can offer to remote devices:

      Class 1: Connectionless transport service only
      Class 2: Connection-oriented transport only

      Class 3: both Connectionless and Connection-oriented transports available


      BlackBerry device that support NFC are Class 2 devices in this respect.


      LLCPDemo - the sample application




      To accompany this article, we’ve written a sample application called LLCPDemo and released it in our GitHub repository. In a moment, we’ll dive straight into the code and review the LLCP APIs that were used in this application. Before we do this though, let’s introduce the application.


      app overview.png

      Figure 1 – LLCPDemo UI flow


      As can be seen from Figure 1, LLCPDemo can be used in either of two roles, either to send data or to receive it. So to use LLCPDemo, you should install it on two devices and run one in sender mode and the other in receiver mode.

      Role selection is made from the first screen which is displayed when the application is launched. If the sender role is selected, the next screen allows you to edit the short text message you want to send to the other device over LLCP. Clicking the Continue button causes the activity log screen to be displayed where details of the progression of the LLCP transfer process will be displayed. If the receiver role is selected, we are immediately taken to the activity log screen where we’ll see similar progress information, but from the perspective of the receiver.



      Figure 2 - The LLCPDemo role selection screen


      OK, let’s take a look at some code, starting with the sender role.


      Sending data over LLCP



      Figure 3 – the activity log showing the sender’s progression


      To send data over LLCP, we use the LLCPConnection interface. It extends the interface and as such should be familiar to many developers already.



      Figure 4 – The LLCPConnection interface


      In LLCPDemo, the code for sending data over LLCP is all in the “run ()” method of the nfc.sample.llcp.nfc.LLCPSender class, which implements the Runnable interface. This means the LLCP operation can be executed in a background thread. This is important since IO operations are blocking operations and we do not want to impact the responsiveness of our user interface.

      Here’s what it looks like:


          public void run() {
              _screen.logEvent("LlcpSender starting...");
              LLCPConnection llcp_conn = null;
              OutputStream out = null;
              boolean completed_ok = false;
              try {
                  // note mode=client
                  _screen.logEvent("Obtaining connection");
                  llcp_conn = (LLCPConnection)"urn:nfc:sn:llcpdemo;mode=client");
                  _screen.logEvent("Got LlcpConnection");
                  out = llcp_conn.getOutputStream();
                  _screen.logEvent("Got OutputStream");
                  byte[] data = _message.getBytes("US-ASCII");
                  out.write(data, 0, data.length);
                  _screen.logEvent("Sent " + data.length + " bytes of data");
                  completed_ok = true;
              } catch(Exception e) {
                  _screen.logEvent(e.getClass().getName() + ":" + e.getMessage());
                  _screen.logEvent("LlcpSender is exiting abnormally");
              } finally {
                  // make sure we don't close and interrupt the receiver before the data we sent has been read 
                  _screen.logEvent("Closing resources......");
                  close(llcp_conn, out);
              if (completed_ok) {
                  _screen.logEvent("LlcpSender finished OK");

      Figure 5 – sending data over an LLCPConnection 


      As you can see, this is simple stuff. All we have to do is open a connection, specifying an URN as shown:


      llcp_conn = (LLCPConnection)"urn:nfc:sn:llcpdemo;mode=client");


      The URN format is per the NFC Forum specification and in this case indicates that we want to open a client connection (for sending data) and connect to a service name of “llcpdemo” on the remote device. The “mode=client” parameter indicates that we are going to act as the client end of the connection of course.

      Once we’ve opened a connection, we obtain an OutputStream object from it and can then write our message in a byte representation to it. Note I’ve assumed ASCII characters only will be used in LLCPDemo. You may wish to modify the character to byte array conversion process to support other character sets.

      After writing to the OutputStream, you should flush and then close the connection.


      Make sure you close the connection no matter what happens! In my case, I have ensured this will be the case by catching all Exceptions and placing my call to a method in which I close the OutputStream and LLCPConnection in the finally block. 

      Failure to close an LLCPConnection may result in you being unable to re-open the connection and errors such as “LLCP resource busy” may appear in the event log and in NfcExceptions.

      You may also find it beneficial to include a short delay before closing your connection. This ensures the receiver has time to read all the data you sent across the connection before you close. If you close the connection at the sender end before the receiver has finished reading, you’ll get an IoException with a message such as “connection invalidated while reading”.

       Figure 6 – some important notes about sending data over LLCP


      The code for the delay and close methods are as shown in Figure 7


         private void delay(int delay_ms) {
              try {
              } catch(InterruptedException e) {
          public void close(LLCPConnection llcp_conn, OutputStream out) {
              try {
                  if(out != null) {
                      _screen.logEvent("Stream closed");
              } catch(Exception e) {
                  _screen.logEvent(e.getClass().getName() + ":" + e.getMessage());
                  _screen.logEvent("LlcpSender stream close error");
              try {
                  if(llcp_conn != null) {
                      _screen.logEvent("Connection closed");
              } catch(Exception e) {
                  _screen.logEvent(e.getClass().getName() + ":" + e.getMessage());
                  _screen.logEvent("LlcpSender connection close error");

       Figure 7 – closing the connection


      Receiving data over LLCP

      The way we receive data over LLCP is very similar to the way in which we send it. We use the LLCPConnection class again, this time opening it with “mode=server”. We then use the LLCPConnectionNotifier class which we obtain from the LLCPConnection to “accept and open” connection requests we receive from clients. After that, it’s plane sailing. We obtain an InputStream object and read data from it. At the end of the reading process. we close the connection, taking care per the notes above; to ensure that this always happens. The receiver code is shown in below in Figure 8.


         public void run() {
              _screen.logEvent("LlcpReceiver starting...");
              LLCPConnectionNotifier llcp_conn_notifier = null;
              LLCPConnection llcp_conn = null;
              InputStream in = null;
              boolean completed_ok = false;
              try {
                  // note mode=server
                  _screen.logEvent("Obtaining connection notifier");
                  llcp_conn_notifier = (LLCPConnectionNotifier)"urn:nfc:sn:llcpdemo;mode=server;timeout=120");
                  _screen.logEvent("Got LlcpConnectionNotifier");
                  llcp_conn = llcp_conn_notifier.acceptAndOpen();
                  _screen.logEvent("Got LlcpConnection");
                  in = llcp_conn.getInputStream();
                  _screen.logEvent("Got InputStream");
                  byte[] data = new byte[256];
                  int bytesRead =, 0, 256);
                  _screen.logEvent("Rcvd " + data.length + " bytes of data");
                  String text = new String(data, "US-ASCII");
                  _screen.logEvent("Rcvd text:" + text);
                  completed_ok = true;
              } catch(Exception e) {
                  _screen.logEvent(e.getClass().getName() + ":" + e.getMessage());
                  _screen.logEvent("LlcpReceiver is exiting abnormally");
              } finally {
                  close(llcp_conn_notifier, llcp_conn, in);
              if(completed_ok) {
                  _screen.logEvent("LlcpReceiver finished OK");

       Figure 8 – receiving data over LLCP


      And that is really all there is to it. Sending and receiving data over an LLCP connection is technically and conceptually simple and, if you have experience working with other types of connection based communication APIs, instantly familiar.

      The Sample Application Source


      The LLCPDemo sample application which accompanies this article can be downloaded with its full source code from our blackberry/Samples-for-Java/NFC GitHub® repository:


      You’ll need to install it on two NFC enabled BlackBerry devices to be able to use it of course. On the first device, select the Sender icon and on the second select the Receiver icon. Adjust the text on the next screen on the sender device and click “Continue” and then place both devices back-to-back. You should see the data transfer take place and this illustrated by messages on the activity log screen.




      In this article, we’ve reviewed the Logical Link Control Protocol and the BlackBerry 7 Java APIs which allow it to be used. We hope this has helped make it easy for you to take advantage of LLCP in your own BlackBerry applications.

      The APIs are available today so download the latest BlackBerry Java SDK from


      BlackBerry Java APIs are documented here if you'd like to browse further:


      The NFC Forum Home Page can be found here:

      Other BlackBerry Developer NFC Articles



      Glossary of NFC Terms


      • APDU - Application Protocol Data Unit. A message type which forms part of a protocol and which may be exchanged between peers as either a request or a response message. Applications on a BlackBerry smart phone may communicate with applets in an SE using the ISO 7816-4 APDUs for example.
      • CLF - Contactless Front-end. Part of the NFC Controller. Communicates via RF with an NFC reader.
      • HCI - Hardware Controller Interface. Amongst other things, this component of the NFC system architecture redirects radio communication to appropriate SE.
      • ISO 7816-4 - the specification which defines the protocol which allows applications to communicate with applets installed in an SE or smart card.
      • LLCP - Logical Link Control Protocol
      • NDEF - NFC Data Exchange Format
      • NFC - Near Field Communications
      • PCD - Proximity Coupling Device (also known as “card reader”)
      • PICC - Proximity Integrated Circuit Card
      • SE - Secure Element. A hardware component which can host and act as an execution environment for small software applications known, in this context, as "applets".
      • SIM - Subscriber Identity Module. In 2G modules this used to be synonymous with the SIM *card* i.e. the small smart card inserted in the handset. In 3G networks, the SIM is a software module installed on the UICC.
      • SNEP - Simple NDEF Exchange Protocol
      • SWP - Single Wire Protocol.
      • UICC - Universal Integrated Circuit Card - the smart card used in mobile terminals in GSM and UMTS networks

    • Black Screen Shown Instead of Video During Playback

      Published Feb 09 2018, 2:18 PM by msohm




      This article applies to the following:

      • BlackBerry® smartphones based on Java® technology



      When attempting to play video using the Player class, a black screen is shown instead of the video.




      If you do not call VideoControl.setVisible(boolean visible), passing in a value of true prior to starting playback your video may not be shown.  Some versions of BlackBerry® Device Software contain an issue that allowed video playback to be shown without doing this.




      Ensure that you call VideoControl.setVisible(boolean visible), passing in a value of true prior to starting playback of video to ensure the video is shown on all versions of BlackBerry Device Software.

    • Error "Unable to connect to BBM. [App name] disconnected by RIM" when connecting to BBM

      Published Feb 09 2018, 2:18 PM by msohm



      When BBM™ connected applications instantiate BBMPlatformApplication, they must supply a UUID.  The UUID is a 128-bit universally unique identifier for the application that must be 36 characters long and comply with the Microsoft® 8-4-4-4-12 format.  Those numbers represent the number of characters in each sequence, separated by a dash.  Here is an example of a UUID in the correct format: 4995d07c-13ee-42d1-92bb-90ba6ed33e1d  You can manually create a UUID or use an online UUID generator.


      The UUID is used to uniquely identify an application in the test/pre-production environment.  Once you upload the application to BlackBerry® App World™ storefront it is no longer used.  Changing your UUID allows you to perform tests of your application in isolation of one another.





      Using a UUID that doesn’t comply with the Microsoft 8-4-4-4-12 format can prevent your application from connecting to the BBM test/pre-production environment.  If you do use an incorrect UUID format you could receive an error of “Unable to connect to BBM. [App name] disconnected by RIM.” when trying to connect.  This only affects developers using the test/pre-production environment.  Consumers who have purchased the application from BlackBerry App World will remain unaffected because BlackBerry App World will assign unique identifies to applications when they are put up for sale.





      You can manually create a UUID using the correct Microsoft 8-4-4-4-12 format or use an online UUID generator.

    • NFC Developer FAQ

      Published Feb 09 2018, 2:18 PM by mwoolley


      This article is part of a series intended to help developers wishing to exploit NFC in their BlackBerry® smartphone applications. Here, we’ve collated known issues and tips in the form of an FAQ. We’ll maintain this article going forwards.


      Readers of this article should have some pre-existing knowledge of the fundamental architecture of NFC systems and be familiar with Java®. It would be beneficial to have read the first article in this series entitled: "NFC  Primer for Developers".


      The Authors

      This article was co-authored by Martin Woolley and John Murray both of whom work in the RIM Developer Relations team. Both Martin and John specialize in NFC applications development (amongst other things).


      The BlackBerry NFC Developer FAQ

      Items are presented in no particular order.






      1What tags are supported by BlackBerry smartphones? 

      The following types of tags have been tested by RIM and are known to work. This is not a full and exhaustive list however. Tags which comply with the appropriate NFC Forum standards should work in theory. If in doubt, test.


      NFC Forum Type

      Supported Tags

      Type 1

      • Topaz 96
      • Topaz 512

      Type 2

      • MiFare Ultra Light
      • MiFare Ultra Light C
      • Infineon my-D Move
      • Infineon my-D NFC
      • Kovio 2K

      Type 3

      • FeliCa RC-S965
      • FeliCa RC-S888

      Type 4

      • MiFare DESFire EV1 (2k, 4k, 8k)
      • MicroPass 4101-2K

      Note that MiFare DESFire EV1 tags must be pre-formatted before they can be used with a BlackBerry smart phone.


      See FAQ #17 for guidance on choosing tags.


      Your application encounters the error “ControlledAccessException - Listener belongs to another application module” when attempting to use on of the NFC listener interfaces such as TransactionListener, NDEFMessageListener or DetectionListener.

      This is a known issue with early releases of BlackBerry 7.0 software.

      Workaround: Sometimes implementing the listener in the UiApplication sub-class will result in this issue being avoided. This does not always work however.

      Solution: Affected devices must be upgraded to an OS version in which the problem has been rectified. Details for BlackBerry® Bold9900 and BlackBerry® Curve 9360 are as follows:

      Bold 9900: fixed in OS version (bundle 1603)

      Curve 9360: fixed at (bundle 1699).

      Ref: MKS 1935744


      You suspect NFC is simply not working on your device. You’ve checked that the NFC service is switched on in the Manage Connections screen tags and have tried testing with a contactless smart card reader. Your contactless card reader has an LED which would normally provide a visual indication of an NFC device in proximity but you see no indication that this is the case when you place your BlackBerry on or sufficiently near to it.

      You will not see evidence of activity with a contactless card reader unless the device is in card emulation mode. Early releases of the BlackBerry 7.0 OS did not enable card emulation mode automatically and an application is required to do this by calling the SecureElement.setTechnologyTypes(...) method with suitable parameters. Later 7.0 releases put the device into card emulation mode with routing to the UICC automatically on device start-up (Ref: CL 4373804). It is recommended that you upgrade to the latest OS build available for your device and re-test before taking any other action.


      You are developing a MIDlet that involves card emulation mode. This necessitates the use of both the TransactionListener interface and PushRegistry to enable the receipt of NFC HCI transactions. However when you try to register your TransactionListener implementation or register with the PushRegistry, you receive an Exception which indicates you have already registered.

      This is a known issue which affected earlier releases of the BlackBerry 7.0 OS. The recommended course of action is to upgrade the affected devices.


      The issue is resolved in:

      Curve: bundle 2386 or higher.

      Bold: bundle 2395 or higher.

      Ref: MKS 2377983


      Is it possible to read a MIFARE Classic tag from a BlackBerry application?

      No. The MIFARE Classic does not fully comply with all the relevant NFC standards. It also uses a proprietory cryptographic system which is subject to licencing.


      You’d like to utilise the BlackBerry embedded secure element for your application. How do you go about getting access?

      Use of the BlackBerry embedded secure element is only granted by RIM in certain cases and is dependent on both business and technical criteria. Engage your RIM contact in discussion about this.


      Your application uses Virtual Target Emulation to emulate an NFC tag of some sort. You want to be able to set the UID for your emulated tag so that it is presented to the reader like a real tag.

      Unfortunately the BlackBerry NFC APIs do give the impression that this is possible:


      public VirtualISO14443Part4TypeATarget(
          VirtualISO14443Part4TargetCallback callback,
          String identifier,
          byte[] historicalBytes


      The intention had been that the value provided as the identifier parameter would be used as the UID of the emulated tag. However, we later decided to remove this capability due to security concerns. The API remains so as to not break older application code but the parameter has no effect and is ignored.


      Where can I buy NFC tags?

      We can’t recommend any particular store I’m afraid. The following URL may help however:


      You’re seeing the error “Cannot wait for secure element 1 in PushRegistry - not present” in the event log.

      This may appear in a stack trace generated by an IllegalArticleException such as the example below. It simply means that the UICC in the device does not have a secure element.


      guid:0x9C3CD62E3320B498 time: Fri Jan 20 13:44:14 2012  severity:1 type:3 app:Java Exception data:


      Cannot wait for secure element 1 in PushRegistry - not present

      net_rim_nfc-2(4F06365E)                 SEPushRegistryManager$MyTransactionListener








      You’re getting ‘Error: App will not start. "Error starting : Can't find entry point".’

      There are various possible causes of this error but if you are using the TransactionListener interface it is possible you are running on an OS build which is too old for your code.

      API changes which break binary compatibility are extremely rare on BlackBerry but we did have one relating to TransactionListener registration whereby the signature of SecureElement.addTransationListener was changed to require an array of applet AIDs to be included in the registration request. Consequently there’s a minimum OS version of required to run applications which use TransactionListener. If you run such an application on an earlier OS version you will see this error. Your only recourse is to upgrade the device.


      Whilst testing a card emulation application which works with the secure element on a UICC, you experience issues and are seeing a message similar to “JSR177 SecurityException: ACF bad signature -> disallow” in the event log. You have an ACF (Access Control File) governing applet access on your UICC.

      This is a known issue affecting some early releases of the 7.0 OS. It’s a defect relating to the way that cod file signatures which have been applied using the CodTool tool are checked. The problem is that all certificates in the certificate chain are being checked to see if they are of the right usage to be used for verifying signatures on other certificates (keyUsage=KeyCertSign) but in fact only the root and intermediate certificates should be checked in this way. In the case where you experience this failure, your end entity certificate probably has a keyUsage field where KeyUsage=DigitalSignature is specified.  This means that the Key_CertSign usage is not allowed.

      For a workaround, you have the choice of using a new certificate which has Key_CertSign in the keyUsage field or which does not have a keyUsage field at all.

      Solution. upgrade to a minimum OS version of

      Ref: MKS 2424217


      You’ve been issued with the RESE signing key to allow you to work with the BlackBerry embedded secure element but are having difficulty using it with Eclipse®.

      The Eclipse eJDE cannot tell that RESE is required since essentially the same API is used for EMBEDDED vs SIM. Consequently after building your cod file you need to manually sign it by launching the SignatureTool.jar tool from within:

       \ plugins\net.rim.ejde\vmTools

      The signing tool "knows" what signatures to apply based on the contents of the .csl file in your \deliverables\standard\7.x.x directory

      So before signing, you have to manually edit the file and add the following line:




      Then try to sign the cod with the signing tool. Don't rebuild before signing and after editing the csl as the csl is generated by the build process and so your manually applied change will be lost.


      Calls to secureElement.getUri(appletId) return a strange connection string.

      This is a known issue.

      With an appletId of say "A000000003000000" the URI value returned by the call may be something like "apdu:1;target=ffffffa0.". It should actually be something like "apdu:1;target=a0."

      A workaround is to hard code the connection string rather than obtain it from the SecureElement object.

      14How does NFC behave when the battery is low or dead?

      Devices which support NFC will continue to be able to provide NFC card emulation functionality when in "low battery mode" or in some circumstances, even when the battery is completely dead. 


      Let's explore what we mean by "low battery" vs "dead battery" before we move on.


      Low battery mode starts when the device OS turns off the user interface due to the battery being deemed "low" so that the device appears to be off to the user but internally, the PMIC (Power Management Integrated Circuit) is still on. Dead battery mode by way of contrast, starts when the there is no longer enough power in the battery to keep even the PMIC on.


      How long low battery mode will last before moving into the dead battery state varies from device to device but can be in the region of around 4 or 5 hours.
      In low battery mode, all BlackBerry devices will continue to be able to provide NFC card emulation functionality.  Regarding dead battery mode however, whether NFC card emulation will continue to work or not depends on the device model:
      • Dead battery mode is not supported on the Bold 9900 and Curve 9360.  
      • The Curve 9380 and Bold 9790 do support this feature however.
      The user has no way of knowing just from looking at their device, if they are in low battery mode or have a completely dead battery and so has no way of knowing whether or not NFC transactions in card emulation mode will work or not in a given instance since to the user, the device appears to be shut down in both the low battery and dead battery states.
      Developers have an API function called SecureElementManager.getInstance().setCardEmulationWhenPoweredOff(true|false) which they can call to control whether or not card emulation will work or not when the battery is dead or has been removed by the way.


      You may also have noticed that the Near Field Communication options screen has a setting in the section entitled "Allow NFC Card Transactions" labelled "When Powered Off".  This setting will also affect the behaviour of a device when in low battery or dead battery mode.

      15You'd like to be issued with the NFCR or RESE signing keys to allow NFC card emulation APIs to be used with either a UICC or the embedded secure element.

      Since 25th April 2012 it has been possible to apply for NFC keys using the same form which is used for standard code signing keys. Just fill in the form at the following address and your application will be processed accordingly.






      BlackBerry 10

      You have a BlackBerry 10 "Dev Alpha device" which you were given at one of the BlackBerry 10 Jam events. When you try to build a native application which uses the NFC APIs using the 10.0.4-beta version of the NDK you get compilation errors such as:


      undefined reference to `nfc_request_events'


      undefined reference to `nfc_unregister_tag_readerwriter'


      and more.

      By default, the library containing the NFC APIs is not on the LIBPATH with this version of the NDK. To solve this problem, look for a .pro file in your project's folder. If your app is called HelloWorld then you should find a file called Edit the file with a standard text editor and add the LIBS directive shown below:


      TEMPLATE = app
      TARGET = TagTool

      CONFIG += qt warn_on debug_and_release cascades

      INCLUDEPATH += ../src
      SOURCES += ../src/*.cpp
      HEADERS += ../src/*.hpp ../src/*.h
      LIBS += -lnfcapi





      Save the file and rebuild your application.

      17What tags should you use for your application?

      What follows is an attempt to give some general guidance on this subject.


      The answer depends what you want to use them for and what you want to do with them.


      The key questions are how much space you need for data and whether you want them to be self-adhesive so you can stick them to surfaces or tough, robust plastic things for in your wallet. Or some other physical form.




      Always look for an indication of “NFC Forum Type n” in the description where for your purposes n will be 2 or 4. That tells you the tag is a standards based tag.


      1. For general recording of simple, not too large URLs etc get an “NFC Forum Type 2” tag such as a Mifare Ultralight, Mifare Ultralight C or Kovio 2K.




      Capacity varies from as little as 144 bytes to about 233 bytes. Check the tag details.




      Watch out for apps that use very long URLs like Foursquare. If in doubt get 2K type 4 tags rather than the cheaper, smaller capacity ones.


      2. For larger capacity needs (eg. 2K or more, up to 8K in fact) get a Mifare Desfire EV1. The “EV1” part is critical. They have a “Mifare Desfire” product (no “EV1”) which we do not support on BlackBerry (it's not one of the 4 NFC Forum standard types). Assuming you want to use them as tags e.g. to store large URLs that launch an app/browser then you need to ask the supplier to supply them “formatted for NDEF” otherwise they will not work. Suppliers generally do this and understand what you mean. Their web site should mention this. If not NDEF formatted, basically you would be using the “tag” more like a smart card.






      - Mifare Classic, Mifare 1K, Mifare DESFire. These are not compatible with BlackBerry smart phones. Note that Mifare DESfire EV1 on the other hand are compatible and good.


      - “Anti-Metal” NFC tags. We’ve had problems reading them sometimes and in our lab testing have found that some of them fail the official "ISO tests".


      Be careful with:

      - the small round sticker variety unless you know for a fact they work with BlackBerry devices. Sometimes they’re OK and sometimes they’re not. No way to tell in advance without prior experience of a specific make with specific BlackBerry device models (performace varies due to different antenna size and other factors). Bigger tags will generally perform better, that’s all there is to it.



      Kovio 2K round sticker tags seem to work OK with BlackBerry devices as do some others. Here’s one stuck to a business card so you can see the size. 




      To be clear, there is no *general* problem with using the smaller, round tags.... we've just seen issues with a few of them so are flagging this. The best course of action would be to buy a small sample first, test with your target devices and application and then make your decision.

    • A new security measure when creating SSL connection.

      Published Feb 09 2018, 2:18 PM by naveenan

      A new attack was recently discovered that allows an adversary to decrypt TLS 1.0 and SSL 3.0 traffic using a combination of eavesdropping and chosen plaintext attack when CBC chaining mode is used.


      To combat this, we implemented a change that was compliant with SSL specifications and was widely

      adopted by most browsers such as Mozilla® Firefox® and Google Chrome™.  We have implemented a counter measure where we split TLS records into two records: the first record containing a single byte of the data and the second records containing the rest of the data, which stops an attacker from exploiting this vulnerability.


      The same change was implemented in Google Chrome browser. Our fix should work fine with any server

      compliant with the SSL spec. However, we encountered problems in the past in cases where a server

      does not properly implement the spec.  If you encounter any issues which are related to SSL or TLS,

      here are two ways that you can fix the issue.  We strongly recommend the first solution.


      1. Update your servers to be SSL or TLS compliant and accept records with one byte of data. This is the best  way to fix any server related problems.


      1. In an effort to reduce incompatibility issues with older servers, we added the ability for third party  applications to disable this security countermeasure when creating SSL connections. In order to disable any CBC security countermeasures that are currently being utilized in BlackBerry® 7.1, you need to add a parameter to the URL being connected to. The parameter to be added is: 






      We introduced this work around in BlackBerry so please try it on this version or higher.

    42 pages