App development guidelines
There are certain development guidelines that apps for the BlackBerry Tablet OS that you create should adhere to. It is important for apps to behave as "good citizens" on a BlackBerry PlayBook tablet 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 BlackBerry App World.
Recommended App Behavior
Apps must behave in a responsive manner that is consistent with the apps that are included with the BlackBerry Native SDK for Tablet OS. We recommend you follow the following practices:
- Re-orient when the BlackBerry PlayBook tablet rotates.
- Show a menu when the user swipes down from the top bezel.
- Perform clean-up on 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 is not active or when the device enters sleep mode.
- React in a timely manner to minimize and deactivate. In addition, ignore events that are not applicable to your app. This practice if new events are generated in future releases of the OS.
- Handle cases where other apps consume device resources.
- Handle audio buffer under-runs in your app to 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 the block sizes match when audio data is written for playback. It is incorrect to assume that the block size remains static between releases
The above list is not 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 the 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 a good test cases to include in your testing.
Recommended practices before submitting to BlackBerry App World
We recommend that you follow these practices before you submit your apps to BlackBerry App 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 in Security Considerations for Native App Developmentfor 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 before publishing to BlackBerry App World.
- 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 is not exhaustive but provides practices to help your you to 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.
Specifically, we recommend that you do not:
- 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 to the shared directory. Files that should not be stored in the shared directory includes 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 back-light or the device entering sleep mode.
- Show disturbing/adult graphics and playing sounds without user consent.
- Busy looping.
- 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 is not 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 is not exhaustive, but provides prohibited practices that you should avoid.