App development guidelines
There are certain development guidelines that apps that you create for the BlackBerry 10 OS should adhere to. It's important for apps to behave as "good citizens" on a BlackBerry 10 device so that they can co-exist with each other and provide the best user-experience possible. Apps that don't follow these guidelines may be removed from the BlackBerry World storefront.
Recommended app behavior
Apps must behave in a responsive manner that's consistent with the apps that are included with the BlackBerry 10 Native SDK. We recommend you follow the following practices:
- Re-orient when the BlackBerry 10 device rotates.
- Show a menu when the user swipes down from the top bezel.
- Perform clean-up upon exiting, such as freeing allocated memory, stopping all processes used by your app, removing temporary files, closing file descriptors, and so on.
- Stop the rendering of graphics when the app isn't active or when the device enters sleep mode.
- React in a timely manner to minimize and deactivate. In addition, ignore events that aren't applicable to your app. This practice will protect your app if new events are generated in future releases of the OS.
- Handle cases where other apps consume device resources.
- Handle audio buffer underruns in your app so as to avoid audio PCM playback issues. Refer to the PlayWav sample.
- Save the state of app in the sandbox, where applicable, so the app can resume from the previous state.
- Handle certain app life-cycle events to ensure a longer battery life. For example, you should handle the WINDOW_INACTIVE event to place the app in a suspended state.
- Use a unique windows group name when using Screen APIs.
- Check the audio hardware block sizes to ensure that block sizes match when audio data is written for playback. Don't assume that the block size remains static between releases.
The above list isn't exhaustive but provides a good base of recommended practices. The closer your app conforms to the guidelines, the more likely your app will provide an optimal experience.
Recommended practices for testing
We recommend that you include the following test cases in your test plans to ensure your app behaves as expected.
- Test your app under high-system load to ensure that it handles the situation correctly.
- Monitor files and devices that your app uses to ensure that the behavior is as expected.
- Test your app under different system states, such as rotation, heavy stress conditions, and minimization, to ensure that its behavior is as expected.
- Capture CPU load and memory usage when your app is running and when deactivated to ensure that its behavior is as expected.
The above list isn't exhaustive but provides some good test cases to include in your testing.
Recommended practices before submitting to BlackBerry World
- Compile the app with relevant compiler defenses, such as PIC/PIE and -fstack-protector flags to enhance security. Refer to Using compiler and linker defenses for more information.
- Compile your apps without debug information before submission. If you compile your app with debug information, degradation in performance can occur.
- Fully sign your apps.
- Specify your own icon for the app.
- Build application binaries for the armle-v7 architecture. The armle-v7 architecture is used by current devices, while the x86 architecture is used only by the simulator.
The above list isn't exhaustive but provides practices to help you successfully submit your app.
Prohibited app behavior
Apps must not disrupt service to, or prevent the operation of, other apps. In addition, apps must not gather information that leads to loss of privacy or exploitation. They must not gain unauthorized access to system resources or otherwise operate in any manner that might be considered intrusive or abusive.
- Write or read files outside of the application sandbox, unless via calls to public APIs.
- Manipulate process information. Process information includes priority, thread priority, process user ID, group ID, process group, parent process, etc.
- Store unnecessary files in the shared directory. Files that shouldn't be stored in the shared directory include executable code (including libraries and interpreted code), temporary files, and app private files (such as files that only your app reads).
- Change the file permissions of files.
- Unnecessarily prevent the dimming of the backlight or prevent the device from entering sleep mode.
- Show disturbing/adult graphics or play sounds without user consent.
- Perform information phishing. For example, asking for device password, PIN, or other confidential information.
- Operate in a manner without user consent or authorization, such as sending information to Internet servers or listening to sockets.
- Manipulate Persistent Publish/Subscribe (PPS) objects directly. The use of PPS objects with the Native SDK isn't supported. Instead, use the BlackBerry Platform Services (BPS) library APIs.
- Statically link apps against system libraries. Statically linked system libraries may cause apps to crash in the OS.
- Use undocumented APIs. The use of undocumented APIs is unsupported. Undocumented APIs can change and can cause your app to crash unexpectedly when users upgrade.
The above list isn't exhaustive, but provides prohibited practices you should avoid.
Last modified: 2013-12-21