走过路过的 GGJJ，帮小弟一个忙

ldk0501

高端手机，中端手机，低端手机是怎么定义的？
另外什么是brew？我查了好多资料，众说纷纭，而且讲得不是很清晰，看起来感觉似懂非懂。
有谁是提供这方面的资料，不胜感激！

lsz7741

高端手机一般指采用arm9芯片，内存在1M以上的。
低端机：
300K<RAM<1M
300K<EFS<1M
MSM6025系列芯片
MSM5100系列芯片
（不是超低端手机的，满足以上任意条件，均认为低端手机）

超低端机：
RAM<300K
EFS<300K
MSM6000系列芯片
（满足以上任意条件均认为超低端手机）

郝宁

作通讯方面测试蛮有前途。。。关注这方面

fafeiboy

工作是找到了,不过要到七月才工作,不知道以后路是怎样

ldk0501

我想问一下，高中低端手机的分类主要是根据芯片来分的吗？
而不是根据手机功能来分的吗？

Evan_ma

专业分法和民间分法吧

lsz7741

主要是根据芯片和手机性能来分的，brew对低端和超低端手机的应用还有具体要求的

xun1206

路过

ldk0501

Introduction to BREW - a mobile handset application development platform
Introduction
As we know, Mobile phones are a wonderful means for communicating with our dear ones in addition to helping us to maintain our contact lists, to do lists etc. As time passed with additional features on these devices piling they made way for Smartphones which in addition to providing phone functionality also provided the functionality of a Personal Digital Assistant (PDA). A Smartphone also allows new applications to be installed on it. To manage these ever increasing list of functionalities, a Smartphone needs a operating system. Currently there are various smartphone operating systems in the market like Symbian, Microsoft Windows Mobile, Palm OS etc. BREW comes in this category.
As a technology hobbyist, I have been exploring BREW for sometime. As such I found resources in the web. But being a impatient reader and lacking in telecom domain knowledge, I found it difficult to understand some aspects of BREW. I also couldn't get the full picture of how BREW works. As a result, I have to look at various sources from which I got a full picture. In this article, I'm just sharing all the information I accumulated to get a full picture of how BREW works. First I will give a overall introduction of BREW and after that I will concentrate on giving introduction to developmental aspects of it.
Objective
At the end of the article you will know
•        What is a application development platform ?
•        How does BREW fit in to the role as a application development platform for Mobile Handsets?
•        What makes BREW different from other handset platforms like Windows Smartphone, Symbian etc?
•        What are the merits and demerits of using BREW to develop applications for Mobile Handsets?
•        What are the various phases of BREW application development life cycle?
•        What type of applications can be developed in BREW platform?
•        What are the basic components of a BREW application and how does it work?
•        How to setup a development environment to start developing applications for BREW platform?
•        What are the steps to develop a basic 'Hello World' application in BREW?
•        Where can I get more information about BREW platform?
Target Audience
•        People interested in Mobile handset application development
Background
The term Platform is used to describe a hardware or software configuration of a computer. In case of hardware configuration we used the term to depicit the processor architecture of the computer. Examples being Intel x86 platform, PowerPC platform etc. In case of software configurations, we use the term 'platform' to depicit the operating system the computer is running. Examples being windows platform, Macintosh platform etc. Operating systems sit on top of the machine hardware. So they must be ported for different hardware platforms which they want to support.
An Application Development Platform or Framework is basically a collection of tools and libraries which enable developers to develop application targetting a hardware of software platform. Some of the well known application development platforms like Java, .NET framework target and get ported on various software platforms or operating systems. BREW is a application development platform or framework which targets and get ported on various hardware platforms. In short unlike Java or .NET framework which sits on top of operating systems, BREW sits on top of hardware layer of the device.
BREW Overview
•        stands for Binary Runtime Environment for Wireless. As the term 'Binary Runtime' suggests, BREW runs on top of hardware platform and can be ported to different hardware platforms.
•        Product of QUALCOMM Internet Services (QIS, a division of Qualcomm Wireless & Internet (QWI) group of QUALCOMM
•        Currently supported on all QUALCOMM handset hardware but like other application development platforms, can be ported to non-QUALCOMM Handsets
•        Can co-exist in a handset with any other mobile operating system
•        Size wise, is about 150k much smaller than most of other handset operating systems available in the market
•        To the telecom domain guys, it is said to be air interface independent ie it can run on CDMA or GSM/GPRS or UMTS handsets. But again currently it is running only on CDMA handsets
•        Enables native application development in C,C++. Applications can also be developed in Java using a Java Virtual Machine (JVM) developed for BREW platform. Recently, IBM has come up with a Java Virtual Machine for BREW
•        Handset manufacturers can integrate BREW into their device by using the BREW Porting kit provided by QUALCOMM
BREW Application Development Cycle
•        Software developers can develop applications in C/C++ using the freely downloadable BREW SDK
•        The SDK comes with a application called BREW Emulator (known as BREW Simulator from version 3.0). This application simulates the look and behavior of a BREW handset device and can be used to test and debug BREW applications during development process.
•        Applications to be executed on BREW Emulator are compiled to native code of the operating system on which the Emulator is running and linked with a compatible x86 BREW runtime library. For instance, if BREW SDK is installed in a windows machine, BREW applications to be executed on BREW Emulator are compiled to windows native code and linked with a x86 compatible BREW runtime library
•        After the application has been tested thoroughtly with Emulator, it has to be compiled and link into ARM binary form to run in BREW handset. For that QUALCOMM provides a GNU Cross compiler which can be freely downloaded and RealView Compilation Tools for BREW which is available for a fee
•        Unlike other mobile handset platforms, BREW applications cannot be directly tested on BREW handsets. QUALCOMM has implemented this feature for reasons of security as BREW gives complete control over handset's hardware
•        Before testing the applications, they should be digitally signed. QUALCOMM provides tools for generating digital signatures only to content providers and Authenticated BREW Developers
•        After digitally signing the applications, they can be uploaded to a BREW handset using a USB or serial cable using a tool called AppLoader. The AppLoader tool is part of the BREW Testing and Commercialization Utilities provided by QUALCOMM which are available only to BREW Authenticated Developers
•        Once the application has been thoroughly internally tested, it must be submitted to QUALCOMM for TRUE BREW Testing. Again True BREW Testing is available only for BREW Authenticated developers
•        After the application passes True BREW testing, it may be offered to Mobile Network operators supporting BREW handsets from which it can be download by subscribers to their handsets
Merits of BREW Platform
•        Since BREW runs directly on top of hardware layer, application execution is fast when compared to other application frameworks like Java Mobile Edition.
•        BREW API is consistent across supported handsets than other application frameworks like Java Mobile Edition API
•        Since BREW from version 2.0 allows direct access to screen buffer, developers have lot of control while creating Graphics intensive applications like Games
•        Handset manufacturers can add new features and fix bugs over-the-air to already deployed BREW handsets by using BREW extensions. BREW extensions are additional code modules written by OEMs and third party software vendors to include additional functionalities in the handsets. Some Examples for BREW extensions are Java Virtual Machine, Game engines etc.
DeMerits of BREW Platform
•        Unlike other handset platforms, applications cannot be directly tested on BREW handsets
•        Only BREW Authenticated Developers can test and deploy applications in handsets. Becoming a BREW Authenticated Developer involves a set of procedures which is not freely available for individuals
•        Testing and debugging of BREW applications difficult and cumbersome due to differences in emulation and actual hardware environments
下续。。。

ldk0501

BREW Application Development Concepts
BREW application environment supports a event driven architecture similar to Microsoft Windows, Macintosh and other opeating systems. There are two types of applications which can be created on BREW. One is Applet and the other is Extension. An Applet is a GUI application having a user interface and reusable code encapsulated in one or more classes if any. An extension is a reusable code module written by OEMs and third party software vendors to include additional functionalities in the handsets. Some examples for extensions are Java Virtual Machine, Game engines etc.Extensions can be loaded or unloaded on needed basis.
Each BREW application is represented by a single Module object and one or more applets and classes. Each Applet or Class must have a unique 32 bit identifier known as a Class ID. Dummy Class IDs can be used during development process. Unique Class IDs have to be inserted before the application is tested in the BREW handset. QUALCOMM provides a Web based tool called BREW ClassID Generator which allows developers to generate unique Class IDs. Note that this tool is only available to BREW Authenticated Developers.
Each BREW application is associated with a corresponding Module Information File (MIF)which is required to ship along with it. The Module Information File contains vital information about a BREW application like
•        Supported classes
•        Supported applets
•        Applet details like title, icon etc
•        Class IDs for each of application's applets and classes
•        Classes exported for use by other applications
The Module Information file for application can be generated using BREW MIF Editor tool which comes with SDK. Language and device specific data for BREW applications can be stored in resource files making localization possible. The application resource files and its corresponding headers can be generated using BREW Resource Editor tool which comes with SDK.
BREW SDK overview
BREW SDK is can be downloaded for free from QUALCOMM site. QUALCOMM has provided detailed instructions on the steps to install the SDK on the pdf document Starting with BREW. The user guide document which comes with the SDK also gives detailed information on the same in addition to many other useful details.
The SDK provides a appwizard addin for Microsoft Visual Studio 6.0 which generates skeletal code for a BREW application making it easy to get started with application development. This addin is available from BREW SDK 1.1 version onwards. Again step by step instructions on using the appwizard to develop a BREW application has been given in the SDK user guide as well as in the pdf document Starting with BREW.
Other development environments like Visual Studio.NET and Visual Studio 2005 can be used to create BREW applications. But developers have manually link the SDK headers and libraries to compile the application code. Again detailed instructions documents are provided by QUALCOMM on this aspects. The SDK also includes a rich set of example application which are very helpful for developers to learn various aspects of BREW development.
Writing our first BREW application
Again lots of documentation in this aspect has been already provided by QUALCOMM. Some of them are as follows:
•        Creating BREW application from scratch
•        Starting with BREW
•        Creating BREW applications using Visual Studio.NET
•        Creating BREW applications with Visual Studio 2005
Conclusion
I thought it would be better for stop this article with these information. I hope by reading this article you guys would have got a general picture of how BREW works and a eagerness to explore it further. On the contrary some of you would also be feeling sleepy or lost or angry or hungry or blank by now. Can't rule out that also. I have also felt like that after reading other's articles :) To those people, I would request them to send their feedback on suggestions to improve this article.

ldk0501

端对端时代已经到来
使用全套 BREW 系统，发行商和开发者可以开发所选语言的应用程序并将它们提供给 BREW 运营商。运营商使用 BREW 虚拟市场采购应用程序并将它们提供给自己的用户。手机制造商使用 BREW 工具快速满足运营商需求。用户在自己的手机上预览和购买应用程序。通过完善该解决方案，BREW 通过 BREW 发布系统来改进用户与发行商、开发者及其合作伙伴之间的结算。

BREW 应用程序平台
完整的 BREW 系统始于无线设备上开放、标准并可扩展的应用程序执行平台。

BREW 体积很小。 BREW 远不只是为 PC 或 PDA 开发的产品的一个小版本，它比其它的应用程序平台或成熟的操作系统要小很多倍。 QUALCOMM 过去曾是手机制造商，悉知无线领域的需求，所以能够从芯片开始设计出 BREW 平台。

BREW 速度很快。 BREW 平台直接运行于芯片系统软件上层，启用了快速 C/C++ 本地应用程序、浏览器简单集成、基于 Java™ 技术的虚拟机和扩展（如 3D 游戏引擎、XML 解析程序和视频播放器）。

BREW 是开放的。 BREW 除了支持基本的 C/C++ 以外，也支持其它执行环境，例如 Java、可扩展标记语言 (XML) 和 Flash。并且因为 BREW 可以在使用任意移动操作系统 (OS) 的手机上运行 － 例如 Palm － 所以为此类操作系统编写的应用程序可像 BREW 应用程序一样，通过 BREW 发布系统 (BDS) 无线下载和收取费用。

BREW 有可扩展性。 因为设备用户界面位于 BREW 上层，所以制造商可以通过 BREW 扩展向已应用手持设备添加新功能。 他们还可通过无线方式修正缺陷，从而避免昂贵的召回费用。 第三方也可为 BREW 平台编写扩展，从而向应用程序提供额外功能。 QUALCOMM 通过发布扩展并提供给开发人员使用，确保 BREW 始终保持其开放性。

BREW 的性价比高。 BREW 降低了设备制造商的开发成本并缩短设备的面市时间。 他们在开发和集成用于不同型号的各种应用程序时花费较少的时间，而在设计产品上花费较多的时间。

BREW 非常安全。 BREW 对基本的电话和无线网络运行提供保护。 除了其它措施之外，BREW 还支持不同设备验证服务以验证请求者是否为已授权的运营商设备。 BREW 还应用了数字签名校验来验证下载和其它无线操作。 QUALCOMM 将继续努力使安全性更高，功能更强。

BREW 移植包灵活且可扩展，可以缩短将 BREW 平台集成到无线设备的过程。此环境与所有 BREW 手机一样采用一套标准的 API。这样，发行商和开发者可用提供出色的应用程序和内容，而不必针对不同手机进行重大返工。因为手机制造商和/或运营商可以直接在 BREW 上移植手机用户界面，所以可以直接通过无线方式更新自己的界面。BREW 执行环境与 BREW 发布系统紧密集成，因此用户可以通过 QUALCOMM 提供的 MobileShop 和应用程序管理器采购，也可以通过手机上的浏览器采购。QUALCOMM 提供 MobileShop 源代码，同时与运营商合作定制采购体验。


BREW SDK&reg;
BREW SDK&reg; 提供了通用的开发工具和调试工具、有源代码的示例应用程序、参考材料、用户指南和手机模拟器（供开发者在开始设备测试之前运行他们自己开发的应用程序），来帮助开发者入门、起步。 有了 BREW SDK&reg;，开发者（甚至是设备制造商的开发小组）无需了解芯片系统软件，就能编写 BREW 设备使用的应用程序。


BREW 发布系统
运营商利用 BDS 与 BREW 应用程序平台，可以在其已提供的无线语音服务基础之上迅速建立无线应用程序业务。 使用 BDS 还有一个更大的优点，即运营商在外购数据解决方案的同时仍能掌握控制权。 拥有这些新功能，运营商可通过安全的应用程序下载增加 ARPU，增强其无线数据零售服务，获得竞争优势。

通过全球虚拟市场将发行商、开发者和运营商连接起来后，BDS 彰显出应用程序发布解决方案的广度。

能更好地体现 BREW 系统灵活性氖牵珺DS 还支持通过可在众多设备操作系统（包括用于 Pocket PC 的 Microsoft Windows 移动软件、Windows 智能电话或 Palm 操作系统）上运行的 BREW 商店应用程序，向智能电话和 PDA 等其它设备发布应用程序。


BREW 增值服务
除了 BREW 应用程序平台、BREW SDK&reg; 和 BDS 以外，QUALCOMM 还与主要合作伙伴及其他倡导者合作提供了一套真正的综合性产品和服务系统，创建了真正的市场。

开发者工具和资源。 ARM、Microsoft 和 IBM 等合作伙伴提供了支持 BREW 应用程序开发的基本工具。 开发者可使用商业化的集成开发环境 (IDE)（如 Microsoft Visual Studio&reg;、IBM WebSphere Studio Device Developer、廉价的 ARM&reg; 编译器或免费 GNU 编译器）。 QUALCOMM 还开发了签名应用程序使用的附加应用程序并将其放置到设备上进行测试。

发行商和开发者还可访问各种商业和技术资源，包括庞大的在线知识库、开发者实验室、销售支持、FAQ、电子邮件支持和在线论坛等。

开发者关系支持。 QUALCOMM 的专门小组将帮助新发行商、开发者和应用程序概念走向市场，包括品牌和应用程序的中介组合，保证为 BREW 运营商提供最先进的应用程序和内容。

BREW 培训。 BREW 为运营商、发行商、开发者和 OEM 提供了多种培训解决方案。 从事培训的专业技术人员包括部分在世界各地协助开发和应用 BREW 和 BREW 工具的工程师。 解决方案包括实战训练、互动课程和涉猎各种主题的会议讲座等。 参加者将学习基础知识、技能和成功进行 BREW 应用或应用程序开发必不可少的先进理念。

BREW 产品支持。 QUALCOMM 的多层支持组织将直接与发行商、开发者、设备制造商和运营商互动沟通技术、运营和业务方面的问题，包括所有发行商和开发者如何进行结算和报告等问题。

TRUE BREW&reg; 测试 (TBT)。 全球的第三方都可应运营商的要求进行 TBT 以保证所有 BREW 应用程序的质量。 在此过程中，这些第三方可以直接和开发者及 QUALCOMM 接触交流。

应用程序签名。 VeriSign&reg; 对所有标准的 BREW 发行商和开发者背景进行筛选验证，并为他们颁发签名证书（数字签名），从而保证每个 BREW 应用程序的完整性。

设备制造商支持。 QUALCOMM 有一个专门小组负责设备制造商的业务，以保证及时地在新推出的电话上统一应用 BREW 功能。

ldk0501

为什么要写这篇文章：
　　接触BREW已经４个多月了，虽然时间不是很长，但是对brew还是有一定的了解，也有一些我自己的见解。我是一个不喜欢单单为了做好工作而只去学习对工作有用的东西，我喜欢刨根问底，喜欢知道一样东西究竟是什么。现在不管是作brew　develop的，还是brew　oem的，其实存在一个问题，就是不是真正理解brew究竟是个什么东西，当然这并不直接影响他们的工作。但是，我个人认为，如果连brew究竟是什么都不知道，而去porting一些接口，用一些接口，是显得很“空虚”，你不能乐在其中。曾经网上看到好多关于误解brew的一些帖子，现在我觉得有必要写一篇阐述brew究竟是什么的文章。当然，我的见解也不是权威，也可能会错。只是将我理解中的brew呈现给大家，如果对你有帮助，我会很开心。如果有错误，请指正，或者相互探讨。

高通对brew的定义：
　　有很多文档中都有对brew的定义，我也不想去查证哪一篇文档上有最权威的关于高通对brew的定义。我只是就我看过的一些高通的文档，总结归纳出高通对brew的定义。简单而言，高通对brew的定义就是：brew是一种无线移动网络中的端到端的解决方案。
BREW－４字母之我见：
　　如上所说，brew是一种解决方案，那brew４个字母究竟是什么意思那。按照我的理解，B是针对j２me的虚拟机（解释）而言，说明brew的目标文件是二进制代码，不是中间解释程序。R说明brew是动态加载机制，只有当需要运行的时候，代码才加载运行。E代表BREW不仅仅是一些接口API，BREW有自身的内核，有自身的执行环境（AEE环境）。W代表BREW是专门针对无线移动的解决方案。
BREW与操作系统：
　　经常看到有人拿BREW和操作系统相比较，最多的莫过于和Symbian作比较。“你觉得BREW和Symbian哪个好？”“我觉得BREW没有Symbian好”等等，诸如此类。其实，这两者根本没有可比性。BREW不是操作系统。本质上来说，BREW仅仅是运行于操作系统上的某个task中的一个软件而已。BREW位于操作系统之上，BREW在手机上的实现需要操作系统服务的支持。从理论上来说，BREW可以在任何操作系统上被支持起来。所以，不能将BREW和操作系统作比较，不具可比性。就好比你拿windows和vc作比较，那是很可笑的。
BREW和编程语言：
　　另外经常看到有人拿BREW和java语言来作比较。这两者也根本不具有可比性。java是一种编程语言，编程语言用来编出软件。而BREW，你可以把它看作是软件，至于是什么编出来的，你无需考虑。　这样的比较，就好比拿bt软件和python语言（bt软件的开发语言）作比较，也是很可笑的。另外补充一点，虽然BREW环境的实现是用C语言，但是BREW应用的开发。“理论”上来说应该可以任何语言，目前主要是c，c＋＋。其实，如果拿BREW和J２me作比较，那才具有可比性。详细见下面一节。
BREW是中间件：
　　更多的人是拿BREW和j2me来作比较，因为他们分别是现在联通和移动所倡导支持的。为什么具有可比性那。因为就我理解，他们都是中间件技术。brew是中间件！
　　中间件位于操作系统（以及native软件）与上层应用之间。通过它，可以使得应用的开发变得可扩展，灵活和“标准”。
　　首先，我们看看没有中间件出现时的手机开发模式。
　　此时，整个手机的开发都是oem厂商完成的。他们在手机的操作系统上编写一个个的task代码，编写一个个特定功能的底层api函数和服务（我们称之为native），然后再利用这些native的代码编写一些手机应用，比如电话簿，短信等等。此时，任何第三方都将无法进入这个行业，因为他们需要了解这个手机的系统，以及这些native的api，才能开发上层应用。但是，通常这些都是保密的。所以，那个时候，几乎没有develop的存在，只有oem。
　　而中间件技术出现后，整个手机开发模式被改变了，我们以brew为例。
　　我们把上面所讲的开发模式称之为纯native开发模式。而一旦handset被porting　brew之后，那么在native之上就多了一个中间层，即中间件。中间件（brew）定义了一套标准的接口（环境），这套标准的接口（环境）是面向上层的，面向develop的。而这套接口（或者环境）的实现则是调用了native（以及操作系统）的服务，我们称之为porting。这样，中间件屏蔽了底层的差异性和具体实现，对上提供标准的接口。从而催生了手机develop这个行业的出现。因为，他们无需考虑具体手机，只需要利用中间件提供的标准接口（环境）来开发可移植的应用。这种可移植性的本质是因为，对于develop所呈现的“共性”是通过oem的“个性”来呈现的，并且通过中间件这样一种模式，屏蔽了这种共性和个性之间的联系。使得使用和实现分离。达到了可移植性！
　　说到中间件技术，其实现在最多提到的就是j２me，brew，mhp。j２me是通过jvm在不同平台上的porting来提供通用的java接口。mhp是机顶盒上现在用的很多的中间件标准，具体的我就不是很清楚。另外，brew和j２me还是有区别的，因为j２me仅仅是一个瘦client型的中间件技术，不涉及端到端的整套方案。而brew不仅仅指handset上的中间件（brew）同时还包括ads（服务器端），所以brew不仅仅是中间件，完整的说，就是高通的定义，是一种端到端的解决方案。
BREW是设计模式：
　　我对设计模式仅仅是初学而已，所以这里仅仅是我的见解而已。我认为，BREW是一种特殊的，可扩展的Facade设计模式。Facade模式的意图是简化现有系统的使用方法，重新定制一种新的接口（或者方式），并呈现给client，使得client更容易的使用现有的系统。在没有brew出现之前，client（上层应用）使用系统（调用系统服务，达到特定功能）的方式是native的方式（直接调用操作系统或者native的api），这种使用系统的方式非常复杂，而且通常对第三者不可用。通过brew，我在native基础上重新定制了一个新的接口（平台，环境，或者方式），并将它呈现给client（上层应用）。这样，client通过这个新的接口（平台，环境，或者方式）同样实现了某种功能，但是却更加的方便。
　　为什么又说是可扩展的Facade设计模式那。因为通常Facade模式中所说的定制的新接口所提供的服务往往是原有系统所能提供服务的子集。BREW也如此，只能通过所有的Interface向client提供服务，当然不能包括整个handset理论上所能提供的所有服务。但是，我们知道BREW本身是可伸缩的，比如可以由oem扩展接口，或者oem裁减掉一些接口，或者随着brew版本的更新也会扩展一些接口。这样，对client所提供的服务也就具有伸缩性，所以我称之具有可扩展性。
　　另外说是特殊的Facade模式，是因为Facade模式没有强迫所定制的新的接口需要是“标准”的接口。但是BREW对外提供的确是标准的接口。它使得cilent（应用）具有了可移植性，所以我称之为特殊。