Binary Runtime Environment for Wireless

From Wikipedia, the free encyclopedia

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 between the 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 applications. It debuted in January 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 REX 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.0 and above, the BREW Simulator, which can be used 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. 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 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, 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 discuss this issue on the talk page, or replace this tag with a more specific message. This article has been tagged since January 2007.

[edit] 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 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.
  • Provisioning is a part of the platform, integrating reporting and various forms of billing (one-time/recurring/etc)

[edit] Disadvantages of BREW

Again, this is 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.
  • BREW lacks a counterpart to popular IDEs such as Eclipse or Netbeans, allowing designing J2ME application flow with little or no programming.
  • There are enough incompatibilities among BREW handsets. Addressbooks are implemented so differently in phones of different manufacturers that custom approach is needed to distinguish Motorola from Samsung from Kyocera (field-based vs record-based phonebooks).
  • Motorola's and Nokia's BREW implementations sometimes have to coexist with their native OSes, resulting in poor performance.

[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 some 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 offer easy-to-access purchasing portals.

[edit] External links

[edit] Major Publishers

[edit] Application Development Firms

[edit] See also

Retrieved from "http://en.wikipedia.org../../../b/i/n/Binary_Runtime_Environment_for_Wireless_e73d.html"
In other languages