Binary Runtime Environment for Wireless

From Wikipedia, the free encyclopedia

"BREW" redirects here. For other uses, see Brew.

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 acts between the application and the wireless device on-chip operating system in order to allow programmers to develop applications without needing to code for system interface or understand wireless applications. It debuted in September 2001.

[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.^[1] The SDK includes a BREW Emulator, or starting with BREW Version 3.1.5 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 provides complete control over the handset hardware, only content providers or authenticated BREW developers^[2] 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^[3] for TRUE BREW testing ^[4] 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.

On May 28, 2008, Qualcomm and Adobe announced a partnership to integrate Adobe Flash Lite as a supported user interface on BREW.

[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. Since March 2006, the least expensive digital signature for testing costs 400 USD and is limited to 100 application submissions.^[5] This steep cost of entry excludes hobbyists from developing for phones that use BREW.

Having passed these hurdles, there is still a high risk that carriers would reject an application due to insufficient profitability, or due to competition with their own applications.

[edit] Business model implications

Time to market can take longer with BREW than with Java ME 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. However this comes as a cost to the end-user as there's less competition to develop the best solution for the cheapest price to the end user.

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 Java ME and BREW, or only Java ME. Java ME may offer a lower cost to market because most carriers allow non-certified Java ME applications to run on their phones. Java ME is widely used in Europe, while BREW is primarily used in the U.S. and Japan. Even in the U.S., Java ME 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 Java ME carriers did not. However, most carriers of Java ME phones now offer easy-to-access purchasing portals.

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++.

[edit] Notable devices using BREW

3 Skypephone Series

There are many notable devices which use Brew, amongst these are the 3 Skypephones which use BREW games as well as Java ME. The BenQ-Siemens EF81 also uses BREW for some of its applications that come included with the device.

[edit] See also

Smartphone
Platform (computing)
Mobile development — How BREW stacks up against the alternatives on mobile platforms.
Java ME
uiOne

[edit] References

https://brewx.qualcomm.com/bws/content/gi/docs/brew_api_reference/brew3.1/en/online/BREW_API_Reference/APIChart/APIChart.htm

[edit] External links

[0] ttps://BREWx.qualcomm.com/BREW/sdk/download.jsp^{[dead link]}

[1] ttp://BREW.qualcomm.com/BREW/en/developer/resources/gs/get_auth.html^{[dead link]}

[2] ttps://www.nstl.com/nstl/index.htm

[3] ttp://BREW.qualcomm.com/BREW/en/developer/resources/bd/ext_test.html^{[dead link]}

[4] ttp://www.verisign.com/products-services/security-services/code-signing/brew-document-ids/index.html

[1]

[2]

[3]

[4]

[5]

Binary Runtime Environment for Wireless

From Wikipedia, the free encyclopedia

Contents

[edit] Software

[edit] BREW application development

[edit] Criticism

[edit] Business model implications

[edit] Notable devices using BREW

[edit] See also

[edit] References

[edit] External links

Views

Personal tools

Navigation

Search

Interaction

Toolbox

Languages