BlackBerry — formerly Research In Motion — has been a long-standing player in mobile devices. Their BlackBerry two-way pagers and early smartphones help set the stage for Android, iOS, and those that followed.
BlackBerry and Android have had an interesting history.
In 2011, BlackBerry leapt into the tablet arena with the Playbook, and the 2.0 version of the Playbook OS supported running carefully repackaged Android applications.
While the Playbook itself had modest success, the ability to distribute Android applications to BlackBerry devices continued with their BlackBerry 10 (BB10) platform, where they offered several phones that could run Android apps. Originally, these had to be specially packaged for BB10, and that is still a common course today. However, in concert with offering the Amazon AppStore for Android on BB10, BlackBerry made it possible to install ordinary APK files as well. Many developers have enjoyed success distributing their app through BlackBerry World (the primary distribution channel for apps to BlackBerry products) and Amazon Appstore for Android.
In 2015, BlackBerry continued their Android push with the BlackBerry Priv, a device designed from the outset to run Android. The Priv comes with a full suite of BlackBerry-related software, including the legendary BlackBerry Messenger (BBM). However, much of that software — including BBM itself — is available on the Play Store for ordinary Android devices. In general, from the standpoint of an Android app developer, the Priv is no different than an Android device from any other major manufacturer. The Priv is even part of the Google Play ecosystem and comes with the Play Store and Google Play Services.
Putting the Priv aside, though, getting your app going on BB10 is a bit more of an adventure. This chapter will describe a bit about what is involved in getting your Android app to BB10 devices.
They do.
However, current versions of that OS — this chapter was last updated when version 10.3 was the latest shipping version — contain an Android runtime environment. BlackBerry OS can run Android apps alongside apps written natively for BlackBerry OS or running on other runtimes (e.g., Adobe AIR). This gives developers a wide range of ways to get their app onto modern BlackBerry devices. However, it does mean that our apps may have somewhat less direct access to hardware, as there is another layer between us and that hardware.
At its core, BlackBerry is a device manufacturer, no different than any other manufacturer that you may have dealt with previously. The biggest difference is BlackBerry’s ability to run Android applications that you prepare for their devices.
That being said, the world of BlackBerry is a bit different than what you may be used to.
BlackBerry makes phones with a variety of capabilities, much as do other manufacturers. You should be writing your apps to support a range of device characteristics, such as screen size and density. That will help you with BlackBerry support, just as it helps you with support for other manufacturers’ devices.
Note, though, that BlackBerry has some history which will affect their device designs, and your apps by extension. Notably, BlackBerry has been renowned for their hardware keyboards. While not all BlackBerry devices today have such keyboards, it is likely that BlackBerry will ship keyboard-equipped devices for some time to come.
This has three impacts upon you as a developer:
Beyond the hardware, the BlackBerry OS — and the Android runtime environment that executes our Android apps — puts some limits on what we can do in our apps. Of note:
android:minSdkVersion higher than that will not
be eligible to run on 10.2 devices.SmsManager, for example.SYSTEM_ALERT_WINDOW are unlikely to work.Like most Android tablets, BlackBerry devices offer little in the way of physical or off-screen navigation buttons. For example, there is no BACK button. However, a navigation bar will contain a BACK soft button for users. If your app takes over the full screen, this bar will not be there all the time, but a swipe down from the top of the screen should expose it.
Similarly, your menu will not be accessed via a MENU key, but rather via a downward swipe to expose the menu. This also means that any special MENU-button logic of yours may not work, if you are using the MENU button for things other than displaying the action bar overflow or other form of options menu.
As with other devices cited in this book, the BlackBerry series of devices lack support for Google’s proprietary apps. For app developers, this means that you lack access to Google Play Services and the various APIs exposed by it, such as Maps V2 and Google Cloud Messaging.
BlackBerry does offer its replacement for GCM, in the form of the
BlackBerry Push Service.
However, for maps, they steer you towards using
geo: Intent structure and startActivity().
If you are dependent upon other APIs offered by Google Play Services
(e.g., LocationClient), you will need to reconsider
your use of those APIs if you wish to ship on devices that are outside
the Google ecosystem.
The BlackBerry Android runtime appears to only support package names of 29 characters or less. The build tools will fail if your package name is longer than 29 characters.
Note that this should only pertain to the “application ID” role of a
package name, not the “hey, where does R.java get generated?” role of
the package name. Hence, it should be possible to replace the application
ID of your app via a Gradle for Android product flavor,
to give yourself
a shorter identifier while not breaking your source code references to
resources.
This might seem like an odd question. After all, the point of this chapter is to make an Android application that can run on BlackBerry devices.
Up until early 2014, that meant you had one option: write a BAR.
A BAR (BlackBerry ARchive, presumably) is a repackaged version of an Android APK, designed to be distributed by BlackBerry and installed on BlackBerry devices. Most of the tooling supplied by BlackBerry surrounds this process of validating that an APK should abide by BlackBerry’s requirements and converting that APK into a BAR.
Starting with BlackBerry OS 10.2.1, though, BlackBerry device users can download and install an APK directly. That APK still needs to work within the confines of the BlackBerry Android runtime and must avoid things that will not work there (e.g., replacement home screens). But the user is no longer reliant upon the developer going ahead and creating a BAR file.
So, what you are creating depends a bit on how you want to distribute the app:
By and large, developing an app to run on the BlackBerry OS Android runtime is the same as is developing an app to run on any other Android environment. You have your standard choices of IDEs and other development tools, the ability to use third-party libraries, and so forth.
Where things start to differ is in testing, where BlackBerry OS ships a Simulator that fills a role similar to that of the Android emulator. To use the Simulator, you will need to package your app into a BAR file, and BlackBerry provides tools to assist you in that process as well.
There are two basic technical steps for preparing your app for distribution through the BlackBerry World market.
The first is to validate that your app does indeed stick to APIs that are supported by the BlackBerry Android runtime. This helps prevent apps from appearing on BlackBerry World that are guaranteed to fail.
The second is to convert the APK into a BAR file. BAR files are used for all of the BlackBerry OS runtimes, including ones like Adobe AIR. Your BAR will contain the same stuff that is in your APK, plus some additional metadata, in a format shared by all of the other runtimes, for interpretation and use by the BlackBerry OS. Again, if you are not planning on distributing through BlackBerry world, you will not need to worry about a BAR file.
BlackBerry is distributing an Android Studio plugin to help with preparing Android apps for BlackBerry. Note, though, that this is an Android Studio plugin, not a Gradle plugin. On the plus side, this gives you new BlackBerry-related options in the Android Studio UI. However, since Android Studio evolves frequently, there is a decent chance that the BlackBerry plugin will not work on some newer Android Studio builds, until BlackBerry catches up.
This plugin includes:
adb proxy that allows Android Studio to work with BlackBerry
devices and running simulatorsYou also have the option for doing BlackBerry-related chores from standalone GUIs, independent of any IDE.
Basically, both IDE plugins simply provide menu options and toolbar buttons for launching the standalone GUIs from within the IDE. If you are not using Android Studio, those GUIs are available independently that you can run like any other desktop development tool.
BlackBerry distributes VMWare images that embody a BlackBerry 10 Simulator. You can use these with VMWare Player (Windows and Linux) or VMWare Fusion (OS X), versions 3.1 or higher.
The Simulator fills a role similar to that of the standard Android emulator, allowing you to test your apps for BlackBerry OS without necessarily having a Blackberry OS 10 device, or for testing scenarios that are difficult to test with actual hardware.
In particular, the Simulator offers a wide range of simulated input and output, including:
In addition, the Simulator supports some of the same types of simulated input that you see with the Android emulator, such as simulated GPS fixes and simulated incoming phone calls.
The VMWare image will have its own IP address, which you can obtain
from the Simulator running in the image. You can then deploy
your BAR to it using the adb proxy, which you can launch from your
IDE or the standalone GUI.
A BlackBerry OS 10 device can run either signed or unsigned BAR files. Unsigned BAR files, though, require a one-time upload of a “debug token”, the creation of which requires the same credentials as you would use to sign the BAR in the first place.
As with any environment where the Play Store is not available, developers have to determine how best to get their apps to the users of BlackBerry devices.
As with most non-Play Store ecosystems, there is the official solution… and then there are the other solutions.
BlackBerry’s own “market” is BlackBerry World. This supports native BlackBerry apps, plus those for runtimes like the Android runtime. So long as your app is packaged as a BAR, it should be able to be released through BlackBerry World, much like how you distribute an APK through the Play Store.
BlackBerry World is a curated marketplace, meaning that BlackBerry staff will review your app submissions and may reject them if they violate requirements or other terms.
Beyond that, BlackBerry World has most of the standard capabilities that you would expect from an app market, such as paid apps, in-app purchases, multiple billing options (PayPal and carrier billing), control for distribution to various countries and mobile carriers, etc.
However, many Android developers will probably elect to distribute through Amazon Appstore for Android, now that it ships on new BlackBerry devices.
Partly, it is for improved reach: by distributing through Amazon’s channel, you reach the Kindle Fire and Fire TV series of devices, plus any other Android devices that happen to have the Amazon Appstore for Android installed.
Partly, you can distribute in the form of an APK, rather than having to mess around with registering for BlackBerry World, creating BAR files, and the like.
Starting with BlackBerry OS 10.2.1, you can distribute APK files through your Web site or similar means, and BlackBerry users can download and install them. However, nothing is done to validate that the apps you download will work on BlackBerry OS’s Android runtime, as they may use APIs that are not available.
Also note that the BlackBerry OS settings have an equivalent to the Android “allow apps from other sources” setting that must be enabled for such installation to occur.
As an example, you can install the F-Droid “market” app to download free and open source Android apps to a BlackBerry OS device. How many of the apps distributed through F-Droid will work on BlackBerry OS, besides F-Droid itself, is unknown.