Resources | Resources |



Testing guidelines

Qualcomm recommends adhering to the following points to prepare your item for distribution.

Application package requirements

  • MOD and MIF files for all Brew® applications and extensions must be signed with valid signatures. Files that are modified on the device must be unsigned or signed-modifiable.
  • Advanced privileges in MIF settings are reserved; if applications require advanced privilege levels, the developer must receive approval from the commercial channel prior to submission.
  • MIF icons display with your item in the catalog. These icons must conform to the following size requirements:
    • Small: 16 x 16 pixels
    • Medium: 26 x 26 pixels
    • Large: 40 x 40 pixels
    • X-Large: 50 x 50 pixels
  • The application version number listed in the application must match the version entered on the submission website.
  • The application must successfully side-load onto the device, started, terminated and deleted/removed. When the application is removed, all modules created on the device during application download should be removed, including extensions (with the exception of extensions referenced by other applications).

Application functionality/robustness

  • All options of the application must function as advertised by the developer.
  • The application must not crash, freeze, or power cycle the device.
  • The application must provide visual feedback to the user when there are delays longer than three (3) seconds in duration.
  • The application must gracefully suspend during phone events (voice call, SMS) and resume at or near the point of suspension. The application should not interfere with the ability to read the device Caller ID display.
  • The application should make full use of the available display, and must not leave “empty”, undrawn, or cropped areas in the display. The application should gracefully handle multiple screen orientations (if supported).
  • All user interface control elements that require user interaction (e.g., menu options, softkey labels, button labels, etc.) must have properly marked text labels with readable fonts. Touchable areas on the display (touch-screen input) must be large enough for users to easily touch-activate the desired region.
  • Device keys (e.g., End key, navigational keys) should function as expected by the subscriber. The Clear key moves the subscriber up (back) one level in the application menu hierarchy where appropriate. The application gracefully handles handset keypad modifier keys (both sticky and non-sticky).
  • The application must gracefully handle loss of service and low-memory (EFS) scenarios.
  • Networking application establishes, maintains, and tears down a data call. After exiting the application, the data call should end within the linger timeout value.
  • Applications must correctly implement supported licenses. For example, applications that support usage-based license should ensure that the remaining number of uses is decremented. Applications restricting functionality for demonstration price method should not invoke restricted functionality for price methods involving payment.

Value billing applications

  • Applications supporting Application-Value Billing (A-VB) iBilling extension must properly handle A-VB transactions at their purchase/transaction entries along with their corresponding pricing (e.g., price ID).
  • The application must properly handle user interruptions such as the Clear key and End key during A-VB transactions or during content retrieval. If the A-VB application is unable to receive and handle the transaction response due to a server interruption, it must provide a mechanism (e.g., reposting the same transaction) to allow the transaction to be concluded for the subscriber (e.g., a pop-up message confirming the result of the transaction).