Binary Runtime Environment for Wireless
From Wikipedia, the free encyclopedia
BREW (Binary Runtime Environment for Wireless) is an application development platform created by Qualcomm for mobile phones. It was originally developed for CDMA handsets, but has since been ported to other air interfaces including GSM/GPRS. BREW is a software platform that can download and run small programs for playing games, sending messages, sharing photos, etc. The main advantage of BREW platforms is that the application developers can easily port their applications between all Qualcomm devices. BREW runs between the application and the wireless device's chip operating system so as to enable a programmer to develop applications without needing to code for system interface or understand wireless applications. It debuted in September 2001.
Contents |
[edit] Software
For software developers, it is a complete set of APIs that enables software development and applications in C, C++ and Java and is supported (platform) by an ASIC. It has a footprint of about 15900 K. BREW is also known as the pseudo OS and it runs on BREW RTOS.
[edit] BREW application development
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.15 and above, the BREW Simulator, for testing during the development process. Unlike the 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 (BREW version 3.1 and newer devices are already "test-enabled") . Once the application has been developed and internally tested, it must be submitted to NSTL for TRUE BREW Testing. 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, the 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). Starting from BREW 3.1, test-enable bit functionality was removed, and now all that is needed is a developer's digital signature.
For testing purpose, BREW applications can be transferred using a USB or serial cable to any BREW-compatible handset using BREW AppLoader from qualcomm. A BREW application contains several components which must be present, otherwise it will be automatically deleted on reboot. This includes a name.mif file which describes the application, the features it uses and permissions requested, a name.mod file which is the actual compiled binary, name.bar 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 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.
[edit] Criticism
BREW developers are required to register with Qualcomm, and to submit their applications for TRUE BREW Testing at significant additional cost. Before submitting for testing, the application needs to be signed. As of March 2006, the least expensive digital signature for testing costs 400 USD and is limited to 100 application submissions [1]. 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.
 |
The remainder of this article may require cleanup to meet Wikipedia's quality standards. Please improve this article if you can. |
[edit] Advantages of BREW
 |
The neutrality of this section is disputed. Please see the discussion on the talk page.(February 2008) Please do not remove this message until the dispute is resolved. |
The following list specifically compares BREW to J2ME. While J2ME is certainly more resistant to crashing than BREW[citation needed], from a game development point of view, there are several advantages to BREW.
- 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.[citation needed]
- 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.[citation needed]
- Provisioning is a part of the platform, integrating reporting and various forms of billing (one-time/recurring/etc)
- The development environment is standardized, comes with free tools, and contains a well integrated emulator that properly reflects the behaviour of the actual device (J2ME emulators vastly differ in reliability, performance, integration, and ease of use. J2ME developers are forced to debug using OEM specific emulators, use a variety of customized build scripts and/or purchase expensive 3rd party solutions[citation needed]).
- Once a BREW application is working in the emulator there is a high probability it will work on all BREW devices. This may offset the additional expense of NSTL testing fees since the debugging cycle may be quicker. That said, however, different phones may implement some aspects of the BREW API and other standards differently and debugging such issues can be difficult since the emulator tends to be more generic.
- BREW applications perform much faster[citation needed]. For common non-computationally intensive tasks the disparity may not be too noticeable. However, J2ME performance is quite poor, in comparison, when attempting time critical tasks[citation needed].
- Being embedded on the chipset and connected to a tight and secure distribution network gives BREW advantages over J2ME’s more generic security model. BREW capabilities and APIs, especially in BREW 3 and above, allow BREW to interact with a broad array of phone functions seamlessly. While available to some J2ME environments as well, BREW is defined to have access to the phone file system, APIs to interact with telephone functions, capabilities to evaluate the phone's "state" in a number of different areas and dimensions[citation needed]. Also, BREW allows foreground and background running of tasks, and applications can run concurrently.
- BREW applications use a predefined model for pricing, revenue shares and financial transactions.
[edit] Disadvantages of BREW
Again, this is compared to J2ME
- In J2ME, the entire source file and resources are compressed by default. To compress resources with BREW, you have to roll your own solution. The same is true of BREW code, it can only be compressed if you devise your own method or buy a commercial solution. However, this may be of little concern since BREW devices lack the tight memory restrictions imposed by J2ME.
- Commercial profilers for C/C++ are expensive, whereas the J2ME environment comes with a profiler. However, free open source C/C++ profilers for Linux are readily available.
- The BREW developer community is fairly small and limited to qualcomm's boards and web sites. There are not many books available either.
[edit] Business model implications
Time to market can take longer with BREW than with J2ME because of BREW's rigorous certification requirements. This certification process may be perceived as an advantage by established software developers because the difficulties associated with testing and development costs create a high cost of entry to developers with low budgets and little time, resulting in less market dilution. Specifically, developers of casual games run less risk of having to compete with freeware workalikes developed and self-published by hobbyists.
- 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.
Currently, most developers choose to support both J2ME and BREW, or only J2ME. J2ME may offer a lower cost to market because most carriers allow non-certified J2ME applications to run on their phones. J2ME is widely used in Europe, while BREW is primarily used in the U.S. and Japan. Even in the U.S., J2ME phones have a larger market share than BREW enabled phones. One of the initial advantages of BREW was that Verizon made it easy to purchase applications from the phone, while most J2ME carriers did not. However, most carriers of J2ME phones now offer easy-to-access purchasing portals.
There are now commercial technologies to fully automate porting from J2ME 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++.
[edit] BREW Developers
- Amiga
- Accuweather
- ACL Wireless Ltd.
- Adobe
- Airplay
- Bluestreak Technology
- Capcom
- Digital Chocolate
- Disney Mobile Studios
- EA Mobile
- eMbience
- Rocket Mobile
- Fun Mobility
- FusionOne
- Gameloft
- Glu
- Hands-On Mobile
- I-play
- Juice Wireless
- Namco
- Networks in Motion
- Namco Wireless
- Obopay
- Pixsense
- PopCap Games
- SEGA
- Sony Online Entertainment
- Vivendi Games Mobile
- Wider Than
- Xringer
[edit] Application Development Firms
- GlobalLogic (www.globallogic.com)
- Innaworks alcheMo
- JeanMartin Inc
- Remoba Inc
- Advanced Mobile Applications
- Econz
- RiffWare
- Rocket Mobile
- Sophia Cradle
- Spaesuvius Mobile Software
- Airsource
[edit] External links
- BREW
- BREW 2008 Conference
- BREW Gaming
- In-depth discussion of BREW and other mobile platforms from European market perspective
- Article - Developing Flash Lite for BREW applications for Verizon Wireless
- Comprehensive List
- cxBrewUnit - BREW Unit Test Framework Harness for C/C++ Unit Test.
[edit] See also
- Smartphone
- platform
- Mobile development — How BREW stacks up against the alternatives on mobile platforms.
- J2ME
- uiOne
