Saturday, August 12, 2006

Hello Friends,
Today we will discuss about "Binary Runtime Environment for Wireless".

BREW is an application development platform created by Qualcomm for mobile phones. It is air-interface independent, i.e. it can support GSM/GPRS, UMTS, and CDMA. However, when BREW was first introduced it was solely developed for CDMA handsets. Standing for Binary Runtime Environment for Wireless, it is a software platform that can download and run small programs for playing games, sending messages, sharing photos, etc. The main advantage of BREW platform is that the application developers can easily port their applications between all the Qualcomm ASICs. The BREW runs in between application and the wireless device's chip operating system; therefore BREW enables a programmer to develop applications without needing to code for system interface or understand wireless application. It debuted in January 2001.

Even though Qualcomm has demonstrated that BREW applications can run in GSM handsets, due to technological restrictions, BREW applications are currently (as of 2005) intended for use solely on CDMA handsets. In the year 2006 Brew was Lunched for 3G on KDDI 3G BREW Handset.

For software people, it is a complete set of APIs that enables software development and applications in C and C++ and is supported (platform) by an ASIC. It has a footprint of about 150 K.

How to develop on BREW Platform
* Software for the BREW-enabled handsets can be developed in C or C++ using the freely downloadable BREW SDK. The SDK includes a BREW Emulator, or starting with BREW Version 3.0 and above, the BREW Simulator, which can be used for testing during development process.
* Unlike Java ME platform, where any developer can upload and execute software on any supported handset, BREW applications must be digitally signed. Because BREW gives complete control over the handset hardware, only content providers or authenticated BREW developers have the tools necessary to create a digital signature.
* Furthermore, developer-signed applications can only execute on test-enabled handsets. Once the application has been developed and internally tested, it must be submitted to NSTL for TRUE BREW Testing (Which cost developer $400 only).
* After the application passes all tests, it may be offered to a mobile operator (content provider) to be accessible for download to general handsets.
* The application is then signed by the content provider, to allow its execution on any supported BREW handset.
* The BREW Emulator (currently called Brew Simulator) does not emulate handset's hardware. Instead, BREW application is compiled to native code and linked with a x86-compatible BREW runtime library. Because of this, obscure platform bugs related to memory alignment and various firmware related glitches make debugging applications without a BREW handset difficult.
* Developers must test their applications on real BREW-enabled handsets. To do that, the handset must be enabled for BREW testing (Qualcomm's development labs can do the service).
* In is said that "Starting from BREW 3.1, test-enable bit functionality was removed, and now all that is needed is a developer's digital signature". But I have seen that some BREW 3.0 phones still require the test-enabling.
* For testing purpose, BREW applications can be transferred using a USB or serial cable to any BREW-compatible handset using AppLoader from Qualcomm.
* A BREW application contains several components which must be present; otherwise it's automatically deleted on reboot. This includes
+ a name.mif file which describes the application, features it uses and permissions requested,
+ a name.mod file which is the actual compiled binary,
+ which contains string and image resources if required, and
+ a name.sig which is the application digital signature. Applications which do not have, or have an invalid or expired digital signature are automatically deleted on reboot.
* 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 Cycle. Saved files are kept intact using Disable/Restore, and it is possible to re-load 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 completely full.
* Once the application passes testing, it's available to the carriers, but this does not guarantee that any carrier will make it available to end users. Carriers have to be persuaded to offer the application to end users.

Dis - Advantages of BREW

* BREW developers are required to register with Qualcomm, to buy a $1500 compiler (else it will cost them $5000). If not concerned with .mod size you can use any GNU free Compilers.
* To submit their source code for TRUE BREW testing at significant additional cost($400). Then the application needs to be signed.
* As of March 2006, the least expensive digital signature for testing costs 400 USD and is limited to a small number of builds. This steep cost of entry excludes hobbyists from developing for phones that use BREW.
* After all these hurdles have been cleared, there is still a high risk that carriers will reject the application as insufficiently profitable, or as a competitor to one of their own applications.
* Again, compared to J2ME
+ In J2ME, the entire source file and resources are compressed by default. To do the same with BREW, you have to roll your own solution. BREW code can never be compressed (the architecture does not support self-modifying code because of security concerns).
+ Profilers for C/C++ are expensive, whereas the J2ME environment comes with a profiler.
* Currently, most developers choose to support both, or only J2ME. J2ME offers less cost to get to market (no testing costs).
* In addition, J2ME is widely used in Europe, while BREW is mostly in the U.S. and Japan. Even in the U.S., the market share for J2ME phones is bigger.
* One of the big classic advantages of BREW was that Verizon made it easy to purchase applications from the phone, but most J2ME carriers did not(any one only matter out side US).
* Now most carriers for J2ME phones also offer easy-to-access purchasing portals.

Advantages of BREW

The following list specifically compares BREW to J2ME. While J2ME is certainly more resistant to crashing than BREW, from a game development point of view, there are several advantages to BREW.

* The testing and development costs and difficulties weed out developers with low budgets and low tolerance for pain, resulting in less market dilution.
* The BREW API is more standard across supported phones than the J2ME API, which can be considerably different depending on the phone model.
* The API tends to be cleaner than J2ME, and many of the recent API changes have made BREW very game friendly.
* Graphics tricks are easier, especially with BREW 2.0 and direct access to the screen buffer.
* J2ME phones often have an artificial limit to the size of the binary (128KB is common). This isn't present with BREW.
* BREW applications can use Object-oriented programming. In J2ME the filesize overhead for extra classes encourages C-like programming. In addition, because arrays of non-primitive types are actually arrays of references, there is significant memory overhead in J2ME for arrays of classes. To get around this, parallel arrays of primitive types are often used in J2ME.

Useful links
* SDK Download:
* Brew Forum:

Coming up
* I will Post Some more posts on BREW in coming days.

Do write comments about this post or write to me at []

Sunil Kumar


Benauto said...

Excellent article, thanks for sharing.

Dr. Brijesh Kumar said...
This comment has been removed by the author.
Dr. Brijesh Kumar said...

Good article on Brew development. But, the problem with BREW is that after going through all the loops through Qualcomm and NSTL, and paying nearly $10K or so in upfront cost of tools and certifications etc.- a developer is still at the mercy of an operator if it wants to distribute an application or not.

BREW is the most closed system ever developed. It only benefits operators and Qualcomm who get to make tons of money at the expense of developers who put hardwork and time in the development.

I would any day take - J2ME and GSM phones.

stats counter