Binary Runtime Environment for Wireless

Binary Runtime Environment for Wireless (BREW, also known as Brew MP or Qualcomm BREW) is an obsolete application development platform created by
Software
For software developers, Brew MP was a full set of
Version history
BREW 1.0 / 1.1 (2001–2003)

Debuted in 2001, it was the first actual version of BREW. Originally made for the Kyocera QCP-3035 (which was the earliest BREW-enabled phone commercially available) and Sharp Z-800. It made use of personal digital assistant-level features (usually for some applications and the ability to run BREW applications). However, it lacks advanced multimedia features and support for Java ME that were available in subsequent versions. It was the only version of BREW to support monochrome screens as support for monochrome screens was removed in BREW 2.0. BREW 1.1 was the first version of Brew to run Java ME applications. It was available in some BREW-enabled phones in 2002 and early 2003.
BREW 2.0 / 2.1 (2002–2009)
Released in the mid-2002, it was installed for most of the BREW-enabled phones in late-2002 until late-2009. It includes support for advanced multimedia playbacks (the ability to play video and audio files, as well as support for 3GPP multimedia formats), connectivity for EV-DO and Bluetooth support, as well as screen savers, and other improvements. It also supports MIDP 2.0 on BREW 2.1 and it is backward compatible with BREW 1.x applications.
It was installed on most feature phones in Indonesia, China, and other countries since 2004 and was supported by a few carriers until 2017.
BREW 3.0 / 3.1 (2004–2012)

Released in mid-2002, it was installed for most of the BREW-enabled phones in late 2004 until early 2012. It was the first version of BREW to have major changes and it has a vast majority of features for mobile phones, such as WiFi connectivity, OpenGL ES 1.0, support for 3G, GPS, QWERTY-based keypads, and support for mobile screens that are higher than 176x220. It is backward compatible with BREW 2.x applications, but not with BREW 1.x applications.
It is also the first version of BREW to support 3D graphics rendering, although it only uses software rendering (which also supports JSR 184 for Java ME games). Hardware acceleration is also natively supported via OpenGL ES 1.0 (if a 3D acceleration chip is available).
It was installed on most feature phones in the United States and in other countries since 2005 and it is still supported by a few carriers.
BREW 4.0.1 - 4.0.2 (2007–2011)
Released in 2007 until 2011, it was only integrated on very few mobile phones (such as the LG enV Touch and the LG Versa). It has only a few improvements and it was later succeeded by Brew MP. It has additional features that are also available in Brew MP, such as accelerometer support and other changes.
It is also used for the Zeebo console in Mexico and Brazil.
Brew MP 5.0.1 - 5.0.4 (2009–2021)

Brew 5.0 was released in 2009 with several new features (including SVG images) and was backward compatible with BREW 3.x and 4.x. Some legacy APIs were deprecated in this version. This release also marked the move to BREW's own real-time kernel, instead of utilizing Qualcomm's REX OS.
The Brew MP developer page was shut down on July 23, 2021, after eight years of inactivity.
BREW application development
For testing applications during the development process, the SDK includes a BREW emulator, or starting with BREW version 1.1 and above, the BREW Simulator. The BREW environment provides for multiple levels of application signatures. One signature authenticates the developer. Another signature verifies that an application has passed True BREW testing and is bestowed through Intertek. The individual telecommunications operators configure the handsets to either enforce or ignore the presence and verification of this second signature. BREW-enabled handsets have a test mode that allows applications to bypass verification of the signature. Qualcomm makes applications that have passed testing available to BREW-enabled wireless network operators. The operators are then able to choose which of these applications to make available to end-users on their catalog.
BREW's own signatures are protected by an
The BREW emulator, named BREW Simulator, does not emulate handset hardware. Instead, the BREW application is compiled to native code and linked with a compatible BREW runtime library. Because of this, applications cannot be tested for platform bugs related to memory alignment and various firmware-related glitches without a BREW handset operating in test mode.
For testing purposes, BREW applications can be transferred using a
BREW applications may be unloaded from a consumer handset to save handset memory space. This is referred to as "Disable/Restore", and is a requirement of the True BREW Test Process. Saved files are kept intact using Disable/Restore, and it is possible to reload the application without paying for it again. In a "Disable" situation, all .bar, .mod, and .sig files are deleted from the handset, while any other files remain in their original place. During the "Restore" operation, the .bar, .mod, and .sig files are downloaded from the carrier's mobile store, and the previously disabled application will have full functionality remaining. The Disable/Restore process is only available to consumer users once the handset's memory is full.
On May 28, 2008, Qualcomm and Adobe announced a partnership to integrate Adobe Flash Lite as a supported user interface on BREW.
Since March 2006, the least expensive digital signature package for developers costs US$400 for 100 application submissions.[2]
Business model implications/availability
Strictly speaking,
- After an application is written, it takes two weeks per iteration of True BREW testing (each time the application fails the test).
- Next, negotiations with carrier(s) commence.
- Then, (if successful) the carrier will spend time retesting the application with their own tests on their network.
- Finally, rolling out a new version means starting the process over again.
Differences between Java ME and BREW
![]() | This section may require copy editing for grammar, style, cohesion, tone, or spelling. (January 2024) |
Currently, most developers choose to support both Java ME and BREW, or only Java ME.[citation needed] Java ME may offer a lower cost to the market because most carriers allow non-certified Java ME applications to run on their phones. Java ME phones have a larger market share than BREW-enabled handsets. Java ME is widely used in Europe, while BREW is primarily used in the U.S. and Japan.[citation needed] One of the initial advantages of BREW was that Verizon made it easy to purchase applications from the phone, while most Java ME carriers did not. However, most carriers of Java ME phones now offer easy-to-access purchasing portals.
Owing to its different APIs, Java ME relies on Java's virtual machine (interpreter-based code), which is technically slower than BREW, which uses native C/C++ plus and direct hardware access (especially for games).[3] Java ME has limited subset of APIs (both for applications and games). However, 3rd-party APIs and implementations (such as MascotCapsule by HI CORPORATION. (3D rendering API) and DoJa/Star by NTT Docomo) are available, but not popular and successful outside Japan (particularly device adoption). BREW (on the other hand), relies on its own APIs and direct hardware access.
Performance for Java ME applications and games are slower than BREW. For 3D games, Java ME uses JSR 184 (M3G), which 3D games that are developed on Java ME are slower (which results in 10 frames per second on some/most handsets) and have limited graphics, while BREW uses either software rendering (if the BREW handset does not have a 3D acceleration chip) or OpenGL ES (which it can take advantage of its performance).[4]
Unlike the Java ME, when the BREW application crashes, the phone will cause a reboot due to BREW can't handle and recover while the application crashes, it creates "$SYS.EXCEPT_(4-Digit Number)" into the "except" folder on the root of directory, then the phone will automatically reboot by itself, when the Java ME application crashes under BREW, Java ME will handle correctly and recover them from phone rebooting by itself.
Some/few handset manufacturers do not allow to integrate Java ME's virtual machine on a few of their phones.
There are now commercial technologies to fully automate porting from Java ME to BREW. This reduces the entry barrier to produce BREW applications by eliminating the need to develop two versions of the same application in both Java and C/C++.
System failure
System failure in BREW is caused by the components are stopped working properly, a file required for a BREW application is missing, application crash, or some other errors. It creates the "$SYS.EXCEPT_XXXX" file inside the "except" folder on the root of directory. BREW's system failure has 2 variants, the component error and the reboot of death.
Component error (example.c XXXXX)


Component error is an error that will display a black, white, or blue screen with an error text for about 5 seconds if a component stopped working properly, then the phone will reboot by itself. This error may vary depending on your activity, for example:
- fs_dir.c (file system error)
- mdsptask.c (task error)
- oemheap3x.c (heap violation)
- memory.c (memory corruption)
- nvm.c (NVM check violation)
- srch_mdsp.c (index error)
- callheap.c (call error)
The probability of this variant to occur is very rare, as a reboot of death is more common. Here's an example of these activities to trigger this variant:
- Undervolting the phone while it's running, it will cause memory corruption (usually if the battery is near flat, on modern devices, undervoltage protection was added) (e.g. LG VX10,[5] LG VX4400,[6] and LG PM225)
- The phone is at a defective condition. Usually, if this happened, the phone will trigger the reboot of death instead of displaying a component error.
- "brew", "nvm", or ".efs_private" folder is removed. (fs_dir.c or nvm.c)
Reboot of death

A reboot of death is an error that will reboot the phone by itself instead of displaying a black, white, or blue screen with text. The rarity of this variant to occur is much more common. Here's an example of these activities to trigger this variant:
- Crashing an application.
- Removing the R-UIM card.
- The phone is at defective condition.
- Incorrectly entering an SP code.
- Application that requires files are missing.
- Running the exception test on engineering mode.
Device usage and carrier availability
Because BREW is only offered to mobile networks that operates in CDMA, other countries (with the exception of parts of
Manufacturers such as
is the only game console to use BREW. Motorola's own T720 as well as the RAZR V3m also use Qualcomm BREW.See also
- Java ME - BREW's competitor.
- Mobile application development— How BREW stacks up against the alternatives on mobile platforms.
- Platform (computing)
- Remo Sync
References
- ^ SDK & Tools | Brew MP Developer Archived 2012-12-17 at archive.today. Developer.brewmp.com. Retrieved on 2013-07-21.
- ^ Code Signing Certificates for Authentic Document IDs for BREW - Digital Signatures | Symantec Archived February 5, 2009, at the Wayback Machine. Verisign.com. Retrieved on 2013-07-21.
- ^ "Choosing between J2ME and BREW for wireless development - TechRepublic". TechRepublic. Retrieved 2017-06-21.
- ^ "See the graphical difference between Java and BREW games". Pocket Gamer. Retrieved 2017-06-21.
- ^ Steven's Phones (July 14, 2019). "LG VX10 - When the battery is REALLY low". YouTube. Retrieved October 4, 2022.
- ^ Steven's Phones (July 14, 2019). "LG VX4400 - When the battery is REALLY low". YouTube. Retrieved October 4, 2022.