Views

BREW: Binary Runtime Environment for Wireless

From Network Dictionary Wiki

(Redirected from BREW)

Jump to: navigation, search

Binary Runtime Environment for Wireless (BREW) is an open system created by Qualcomm for delivering over-the-air applications and data. The hottest use for BREW to date has been downloadable games

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.<ref>https://BREWx.qualcomm.com/BREW/sdk/download.jsp Template:Dead link</ref> 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 provides complete control over the handset hardware, only content providers or authenticated BREW developers.<ref>http://BREW.qualcomm.com/BREW/en/developer/resources/gs/get_auth.html Template:Dead link</ref> 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<ref>https://www.nstl.com/nstl/index.htm</ref> for TRUE BREW testing <ref>http://BREW.qualcomm.com/BREW/en/developer/resources/bd/ext_test.html Template:Dead link</ref> 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.<ref>http://www.verisign.com/products-services/security-services/code-signing/BREW-document-ids/index.html Template:Dead link</ref> 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]

Advantages

Template:POV-section The following list specifically compares BREW to Java ME. While Java ME is certainly more resistant to crashing than BREW Template:Fact, from a game development point of view, there are several advantages to BREW.

The BREW API<ref>https://BREWx.qualcomm.com/bws/content/gi/docs/BREW_api_reference/BREW3.1/en/online/BREW_API_Reference/APIChart/APIChart.htm Template:Dead link</ref> is more standard across supported phones than the Java ME API, which can be considerably different depending on the phone model. Template:Dubious
BREW 2.0 allows direct access to the screen buffer.Template:Fact
Legacy (i.e., pre-2005) Java ME phones often have an artificial limit to the size of the binary (128KB is common). This isn't present with BREWTemplate:Fact.
BREW applications allows more freedom in Object-oriented programming. In Java ME 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 Java ME for arrays of classes. To get around this, parallel arrays of primitive types are often used in Java ME.Template:Fact
Provisioning is a part of the platform, integrating reporting and various forms of billing (one-time/recurring/etc)Template:Fact
The development environment is standardized, comes with free tools, and contains a well integrated emulator that properly reflects the behaviour of the actual device (Java ME emulators vastly differ in reliability, performance, integration, and ease of useTemplate:Fact. Java ME developers are forced to debug using OEM specific emulators, use a variety of customized build scripts and/or purchase expensive 3rd party solutionsTemplate:Fact).
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.Template:Fact
Due to its native nature, BREW applications often perform much fasterTemplate:Fact. For common non-computationally intensive tasks the disparity may not be too noticeable. Other native solutions such as Symbian OS also shares the performance gain over Java ME.
BREW applications use a predefined model for pricing, revenue shares and financial transactions.Template:Fact

[edit]

Disadvantages

BREW is a proprietary standard and only works in a small subset of mobile phones whereas Java ME is an open standard and is supported by most mobile phones.
The centralized and proprietary nature of BREW and the steep cost of getting a digital signature means that it's virtually inaccessible to homebrew and hobbyist developers, as compared to open systems such as Java ME, Symbian OS, or Windows Mobile.
In Java ME, 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.
Commercial profilers for C/C++ are expensive, whereas the Java ME 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.
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.

[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

Image:3 Skypephone.jpg

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]