Brew

Brew OS is used by some mobile phone manufacturers and mobile networks, however most often the end-user does not know this since mobile phones running Brew most often lack any Brew OS branding and Brew runs in the background with the custom "skins" of the mobile phone manufacturer or operator on-top. Brew OS is used by Sprint Nextel, metroPCS, Cricket Wireless, U.S. Cellular, Verizon, Syringa Wireless, and AT&T in the US and by the 3 network in much of Europe, the UK and Australia on many mobile phones produced especially for their network.

An app can register for the following System notifications:

TAPI (Class ID: 0x01001007)

NMASK_TAPI_STATUS

0x0001

TAPI Status change event

NMASK_TAPI_SMS_TEXT

0x0002

Incoming SMS

NMASK_TAPI_SMS_TS

0x0004

SMS message on specific Teleservice ID

INETMGR

NMASK_OPENED

0x0001

Network layer is available

NMASK_CLOSED

0x0002

Network layer is closed

NMASK_IDLE

0x0004

Network layer available and idle

"Undef Inst Exception" stands for "undefined instruction exception," and means that the program pointer has jumped to a code segment that contains an undefined instruction. This can be the result of memory corruption, a stack overrun, or version-related incompatibilities between applet code and the BREW image on the phone.

Memory is tighter on the phone than when running on the emulator. Therefore, memory and stack overrun problems will be more likely to show up on the phone. You should double check memory related areas of your code, especially auto variable arrays and the maximum total size of allocated memory.

To clear the phone, pull the battery out for a few seconds.

The "Re-entrant Data Abort" exception is often caused by stack overrun. When an applet is running on the phone the stack size is small, and you are more likely to see stack overrun problems than when running on the emulator. Solutions to this problem are reducing the size or number of objects on the stack, and using objects allocated on the heap instead of automatic variables.

A "Pref Abort Exception" usually indicates that memory important to the phone operating system has been trashed. The two most common causes of this exception are data corruption (i.e. running off the end of an array), and stack overruns.

An "SWI Exception" is usually related to heap memory mismanagement. The most common causes of heap memory corruption are: overwriting the bounds of your allocated arrays, freeing objects more than once, and writing to wild or NULL pointers.

In addition to the more common causes, stack overrun can also lead to SWI Exceptions.

Problem: When an application exits while running on the emulator, instead of returning to the main menu screen, a blank screen is displayed with the application name in the upper left corner.

This behavior is caused by not freeing all allocated memory before exiting the application. Any buffer you allocate using MALLOC or IHEAP_Malloc() must be freed using FREE or IHEAP_Free(). For any instance of a BREW class that you create, you must call the corresponding release function to free that instance.

BREW device has Flash RAM and Heap RAM. You can treat Flash RAM as a hard drive. Programs are stored there, but not run from it. You can treat Heap RAM as you would always treat a memory heap. Say you have an application that is 35k in size. This will take 35k from the Flash RAM to store on the device. When the application is run, the 35k will be loaded into Heap RAM in its entirety plus however much Heap RAM it needs to allocate. When the applet is released, this Heap RAM is freed. It will still occupy space on the Flash RAM until it is removed from the device.

BREW loads the apps into Heap RAM because files on EFS are stored as non- contiguous blocks.

MALLOC and IHEAP_Malloc() are identical, just as FREE and IHEAP_Free() are identical. In earlier versions of the BREW SDK, malloc was part of the IHEAP Interface, and was later made into a helper function for ease of use. Both are still available for backward compatibility, but it is recommended that, use MALLOC and FREE rather than IHEAP_Malloc() and IHEAP_Free().

An app needs to create IHeap interface only when it wants to get current memory usage statistics (IHEAP_GetMemStats()) or check if a memory block of a certain size can be allocated (IHEAP_CheckAvail()).

In addition to the obvious EVT_APP_START and EVT_APP_STOP, your applet must support EVT_APP_SUSPEND and EVT_APP_RESUME in order to pass True BREW Testing.

Binary Runtime Environment for Wireless (Brew MP, Brew, or BREW) is an application development platform created by Qualcomm, originally for code division multiple access (CDMA) mobile phones, featuring third-party applications such as mobile games. It is offered in some feature phones but not in smartphones. It debuted in September 2001.

This can be achieved by reducing the heap size in the device configurator file (.qsc file) to almost the size of the .mod file. Any run time allocations by the applications should fail and you can test if your application deals with those failures correctly.

Since the size of the mod file a is a lot less then the dll that runs in the emulator, the emulator approximates the size of the mod file to be 10% of dll.

To properly run this test, create a separate directory that contains only the MIF of the application under test and have emulator point to this new directory (File->Change MIF Dir).

Currently, BREW does not expose a means to send SMS messages from within a BREW applet. BREW applications can only receive SMS messages.

Yes, SMS notification events can be delivered to an application, even if it is not currently active. To do so, BREW first loads the applet, and then sends the EVT_APP_MESSAGE event to it. The application may start itself by calling ISHELL_StartApplet(), or can "silently" process the event without calling ISHELL_StartApplet().

To build applications for the phone requires the ARM Developer Suite of tools, which are used to compile and link a project that has been developed using the PC-based BREW SDK, and related tools. Running an application built using the ARM tools requires a BREW-enabled phone, a data cable for establishing a serial connection to the phone, and file copying software such as QUALCOMM's BREW AppLoader application. See How to Build a Downloadable BREW Application for more details.

The device configurator file (.qsc) is used by the BREW Emulator application, and is not required to run applications on the phone.