You may have noticed that the emulator images shipped in the WM 6 SDKs have no cellular signal, which is very different from the previous SDKs where all images used to be connected to the Fake Network. We had to make this change to introduce the new Cellular Emulator tool. WM 5.0 SDKs’ images use a technology we call FakeRIL, or the Fake Radio Interface Layer, and although it allowed developers to call and send SMS from within the Device Emulator (see Windows Mobile Device Emulator phone numbers for some examples), Cellular Emulator offers more options and it makes it easier to test your applications.
Here is some information on how to run Cellular Emulator and configure emulator image's network settings to browse to the Internet. Once you configure the emulator images, you can save their states (from Device Emulator) to speed up the process.
Cellular Emulator
Cellular Emulator is a software-based emulator to aid developers and testers in developing and testing their software under the Windows Embedded CE and Windows Mobile platforms. The design goal of Cellular Emulator is to replace the radio module in both development and test environments. The advantage of Cellular Emulator is that it provides not only voice but also data connectivity. Moreover, Cellular Emulator is a powerful tool to test various applications under different wireless network conditions in GSM/GPRS and/or UMTS networks.
Running Cellular Emulator
- Launch the Cellular Emulator (Start/All Programs / Windows Mobile 6 SDK / Tools / Cellular Emulator ) and the Device Emulator.
- Read the COM port configuration from the status bar of the Cellular Emulator main window.
- In the Device Emulator, go to File / Configure and select the Peripherals tab.
- Map the Serial port 0 of Device Emulator to the specific COM number obtained from step 2
- Soft reset the Device Emulator (File / Reset / Soft).
Shutting the Cellular Emulator
The close button of the Cellular Emulator main windows will only send the application to the tray panel. To close the application, right click the tray icon and select Exit.
Cellular Emulator Data Connections
The Cellular Emulator will also provide GPRS connection simulation. Users can create simulated GPRS connections just like common ones. The access point name and user name/password are not checked and thus may be anything. Once the data connection is made, the emulator will just act as if it is connected to the network of the host machine. If some proxy settings are needed for the host machine to set up connections to remote machines, they are also needed on the emulator. Assume a network environment where HTTP proxy is needed to access external web sites. Setting samples on Windows Mobile 6 Standard and Professional are provided in the following sections.
Windows Mobile 6 Standard
- Enter Start-Settings-Connections-GPRS-Menu-Add. Create a GPRS connection using the settings as follows.
- Name: PPP
- Connects to: WAP
- Network Access Point: Some Access Point Name
- User Name: Just leave blank for anonymous configuration
- (Optional) Enter Start-Settings-Connections-Proxy-Menu-Add. Create a proxy using the following settings.
- Description: Proxy
- Connects from: WAP Network
- Connects to: The Internet
- Address: The proxy in the specified user's network
- Enter Start-Settings-Connections-Menu-Advanced.
- Set Internet connection to PPP
- Set WAP connection to PPP
- Leave the others as automatic
- Enter Internet Explorer Mobile, and choose Menu-Tools-Options-Connections, then configure the Internet Explorer Mobile settings:
- Automatically detect settings: CHECKED
- Select network: The Internet
- Choose the Internet Explorer Mobile icon using the arrow key on the keyboard.
- Browse freely using Internet Explorer Mobile.
Windows Mobile 6 Professional
- If the user's computer uses a proxy to access the Internet, then the user needs to setup a Work Connection on the Pocket PC, otherwise the user can setup an Internet Connection.
- Setup a GPRS connection. Access point and user name can be empty.
- (Optional) Setup a proxy. This should be the full name of a working proxy required by the corporate network.
- Open Internet Explorer Mobile and browse to a web site.
Makeover
Out of curiosity, Cellular Emulator went through an extreme makeover from the first time I learned about it as an internal tool, to its release in the Windows Mobile 6 SDK.
I hope you enjoy it and let me know your feedback!
Before:
After:
If you are installing the WM 6 SDK on Windows Vista you may hit an error that blocks the installation. The error message is:
Could not access network location Common7\IDE\ProjectTemplates
This issue is related to a Custom Action (VBScript) we were using to install the Project Templates for Visual Studio - Vista may be blocking VBScript (through security policy, for example) which then causes our installation to fail. If you log the SDK setup, you will see something like:
DEBUG: Error 2738: Could not access VBScript runtime for custom action
While we work on that for the SDK Refresh, here is a simple workaround that will allow you to install the SDKs:
- Click on Start / All Programs / Accessories;
- Right click on Command Prompt and click on Run as administrator;
- Click on Continue in the User Account Control pop-up;
- In the Command Prompt window run the following command: regsvr32 %SystemRoot%\system32\vbscript.dll
- Close the Command Prompt window and install the SDKs normally.
Please, let me know if that works for you (and yes, we don't like VBScript CAs anymore too! :-)
See you at MEDC 2007!
The button was pushed and the Windows Mobile 6 SDKs are now available – you can download both “Windows Mobile 6 Standard SDK” and “Windows Mobile 6 Professional SDK” here!
Please, read carefully the download page details to learn about the new naming and emulator images, requirements and know issues. Make sure to also read the What's New for Developers in Windows Mobile 6 white-paper.
The table shows which SDK must be used when targeting the old Smartphone and Pocket PC categories:
| Previous Categories |
New Categories |
Windows Mobile SDK |
| Windows Mobile for Smartphone |
Windows Mobile Standard |
Windows Mobile 6 Standard SDK |
| Windows Mobile for Pocket PC |
Windows Mobile Classic |
Windows Mobile 6 Professional SDK |
| Windows Mobile for Pocket PC Phone Edition |
Windows Mobile Professional |
What’s new in the Windows Mobile 6 SDK?
Here is a quick overview of the new SDKs.
Better discoverability
Everything is installed (by default) under C:\Program Files\Windows Mobile 6 SDK. We also “share” the common content from both SDKs, for example, there will be only one help collection, only one set of common samples, tools, etc., even if you install both SDKs. Readme files are also better, go to Start Menu, Programs, Windows Mobile SDK and check the main readme file as well as the tools and samples ones.
Help Collection
The help is now integrated with DocExplorer, but you can still access it through the Start Menu if you want/need to.
Samples
We have samples! A lot of them! Check the Samples readme file to learn about all sample collection.
New Tools
There are also a nice number of new tools with this release. Here is a quick list with a brief explanation of each one:
Cellular Emulator v1
Cellular Emulator is a software-based emulator to aid developers and testers in developing and testing their software under the Windows Mobile platforms. The design goal of Cellular Emulator is to replace the radio module in both development and test environments. The advantage of Cellular Emulator is that it provides not only voice but also data connectivity. Moreover, Cellular Emulator is a powerful tool to test various applications under different wireless network conditions in GSM/GPRS and/or UMTS networks.
In other words: it is your own Mobile Operator running on your desktop :-). You can call your device emulator, send and receive SMS, play with AT commands, SIM cards, etc. How cool is that?
Device Emulator v2
Yes, it is here – install the SDK and have Device Emulator v2 up and running on your machine.
Local Server Framework
The Local Server Framework allows users to develop custom server applications running over localhost. Components of Windows Mobile powered devices must communicate with external services running on external servers. Lack of control over the external server inhibits the ability to comprehensively test client side code. Additionally, varying network conditions in build labs introduce multiple points of failure in test code that are often unrelated to code under test. The server framework allows development of test application servers that run locally over localhost on the device, alleviating these problems. The Local (or Fake) Server Framework allows users to develop either full-featured servers or application-specific servers that communicate with their respective clients.
FakeGPS & GPS Settings
Do you want to develop a GPS-enable application but don’t have a real GPS device? FakeGPS is the answer! Just drop and install the FakeGPS.cab file into your emulator or device and you are ready to go. FakeGPS will set the GPS Intermediate Driver to read the NMEA strings from a text file instead of using a real GPS device.
And what happens if you want to sell your GPS-enabled applications to WM 6 Standard users? You can use GPSSettings to enables Windows Mobile 6 Standard users to configure the GPS intermediate driver, it works in the same way as the built-in GPS settings applet on Windows Mobile 6 Professional and Windows Mobile 6 Classic – better yet, you can even redistribute GPSSettings.exe with your applications!
Hopper
Hopper is a software test tool that simulates input stress on Windows Mobile powered devices. Hopper will stress all applications that are available through the menu system by rapidly sending keystrokes and screen taps in a random fashion. By sending a large number of user inputs very rapidly, Hopper can quickly isolate troublesome scenarios and find bugs in your applications.
It works like this: you setup Hopper to test your application and let it run. It keeps clicking around randomly on your application going through “code paths” that you would not usually test, and of course, it finds bugs!
New Emulator Image
A brand new “Windows Mobile 6 Professional Square QVGA (320x320 pixels - 128 dpi)” emulator image!
CabSignTool
CabSignTool signs a .cab file and all its executable content (.exe, .dll) with the specified certificate – it unpacks the .cab file, signs all .exe and .dll files, pack the .cab file again and sign it, in one single pass.
How do you like it? Stick around as I will continue posting about the SDK, tips and tricks, issues, etc. And let me know your comments and feedback.
Enjoy the new Windows Mobile 6 SDKs!
Scott Yost talks about the certificate changes that we made in Windows Mobile 6:
It gives me great pleasure to announce the following changes that we made in WM6:
- Certificate Installer built into the platform
- Installs CER, P7B, and PFX files
- No more Access Denied messages.
- Installs certs to the ROOT, Intermediate, and MY store
- Wildcard Certificate support for SSL
Full post here.
With the Windows Mobile 6 announcement it is time to start talking about the new SDK we put together for this release (and I can finally tell you what I’ve been working with since I arrived here). We have been working hard on it and we all hope you'll enjoy it as much as we do :-)
What’s new for developers?
- Great application compatibility for Windows Mobile 5 applications
- .NET Compact Framework v2 SP1 in the ROM!
- SQL Server Compact Edition in the ROM!
- New APIs
- New Sound APIs
- WISP Lite (Yes, the same WISP technology from the TabletPC!)
- Several new tools:
- Cellular Emulator (kind of having your own Mobile Operator ;)
- Local Server Framework (aka FakeServer)
- FakeGPS
- Hopper
- CabToolSigner
- Security Configuration Manager
- New emulator images
- Platform improvements
- Integrated documentation
Overall Windows Mobile 6 SDK makes it easier to develop, build, test and deploy your applications.
I’ll drill down into the SDK details on my next posts – so stay tuned!
Mel has developed and posted a great library for those of you developing native code - on his own words:
I'm proud to announce ScreenLib, a new library for native Windows Mobile developers. It takes away a lot of the pain of designing user interfaces for multiple screen sizes, orientations, form factors etc. It lets you create a user interface once and have it automatically adapt to whatever the device’s screen size is at runtime. By doing this, it offers basic docking & anchoring support for native development and can do a lot of UI plumbing work with just 1 or 2 lines of code.
ScreenLib works on Pocket PC and Smartphone devices, so it's a great step towards creating single binaries that will run on both platforms.
I highly recommend watching a video tutorial that explains how ScreenLib works and why it should be used. To download the video, please visit:
http://www.microsoft.com/downloads/details.aspx?FamilyID=a908dd7f-71c0-4cea-b97d-b9ffe985f903&displaylang=en.
To download ScreenLib for free, please click: ScreenLib.zip
He has presented it here a couple of weeks ago and I was impressed by its simplicity and how it can increase your productivity when dealing with screen orientation/resolution, etc. And as Mel says, we’d like to hear your feedback!
Thanks Mel!
Network Analyzer for Windows Mobile was released today as a PowerToy:
Overview
Network Analyzer for Windows Mobile runs network utilities, for example ping and ipconfig, on a Windows Mobile powered device. Network Analyzer for Windows Mobile facilitates the troubleshooting of network connectivity issues. You can extend the harness. You can add user-defined tests (DLLs) to the list of tests to be executed. An xml input file defines the list of tests to execute. You can use Network Analyzer to send information about network traffic to a .cap file. You can then view the .cap file with the Network Monitor tool or the Ethereal tool. See the readme file below for more information.
You can download it here.
Enjoy it!
In the case you have missed it, .NET CF team has released v2 SP1! Point your browse to this netcfteam's post to learn more about added features and fixed issues:
Microsoft .NET Compact Framework version 2.0 SP1 release has been completed and is in the process of being released. This service pack was driven customer feedback including improvements in stability, adds new debugging features, extended platform support, and new developer functionality.
The .NET Compact Framework will be delivered to customers through various channels. Each channel and location will be reported on here.
Release Channels
Web Download
http://www.microsoft.com/downloads/details.aspx?FamilyID=0c1b0a88-59e2-4eba-a70e-4cd851c5fcc4&displaylang=en
WCE 4.2 QFE
http://www.microsoft.com/downloads/details.aspx?FamilyID=aeef5159-ecd5-4456-830f-97b6c4893d79&DisplayLang=en
WCE 5.0 QFE
http://www.microsoft.com/downloads/details.aspx?FamilyID=9899f025-cba6-4079-ad4c-24f8c08f1c57&DisplayLang=en
Visual Studio 2005 Patch
http://www.microsoft.com/downloads/details.aspx?FamilyID=7befd787-9b5e-40c6-8d10-d3a43e5856b2&displaylang=en
Cool!
Some people have been experiencing issues when installing/running Windows Mobile 5.0 SDKs on Windows Vista. Most common issues are:
- SDK complains about lack of Activesync
- SDK seems to install but there is no project template available when you try to create a new project
- Unable to create native (C++) projects (you can't to go through the wizard).
- Cannot deploy/debug to a device over Activesync in Vista
We have identified these issues and while teams are working on possible fixes, I would like to purpose workarounds to unblock some scenarios for testing Windows Mobile application development on a Windows Vista machine. Let me try to briefly explain each issue and propose an unsupported workaround:
Workaround 1: Activesync requirement during install & Vista
As you may know, Windows Vista comes with device synchronization technology in the box and it does not require Activesync to be installed to synchronize your device with the desktop - it is called Windows Mobile Device Center (WMDC).
WM 5.0 was designed to be supported only on Windows Server 2003 & Windows XP (no Vista at that time :-), and for those platforms, Activesync is required to allow application deployment to the device. The good thing is that it was implemented as a soft requirement: just click "ok" in the popup window and continue installation. You do not need to install AS on Vista.
Workaround 2: No Windows Mobile 5.0 Project Templates
During SDK installation, one of the scripts is requiring "elevated privileges" to execute correctly. If you have "User Account Control" (UAC) turned on, this script will silently fail and, although installation will apparently finish successfully, the project templates will not get installed.
How to work around it? Simple, just turn off UAC (Control Panel, User Accounts, Change Security Settings) and install or repair the SDK. You can turn UAC back on after installation.
Workaround 3: Unable to Create Native (C++) Projects
VC++ Project Wizards are pretty much HTML files + scripts - Visual Studio uses IE to render and present those "web pages" as a wizard. The problem is that, due to the new security model, IE7 does not trust some of those scripts; as a result you keep getting the "New Project" dialog and can't move forward on the wizard. The workaround here is to let IE know that the smart device VC++ wizard is a nice guy and ok to run.
You will need to open the registry entry: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Ext\PreApproved
And add a new entry named: {D245F352-3F45-4516-B1E6-04608DA126CC}
Workaround 4: Unable to deploy/debug over Activesync
This is the issue I like most :-) As we saw on item 1, Windows Vista comes with WMDC which substitutes Activesync - it acts like AS but it is not AS! That means there is "no information" about AS in a Vista box, in particular, the registry key that identifies Activesync as installed is not present - Visual Studio checks for that registry key before loading the appropriate component to deploy the application to the device, the registry is not there and the deployment fails - all components are ok, we are just missing the registry info...
So guess what? Let's create the missing registry entry!
Open the registry entry: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows CE Services
And add the following entries:
MajorVersion (DWORD) = 4
MinorVersion (DWORD) = 0
These hints will help you on beta testing Vista as a development platform for Windows Mobile. However it is important to note that these are unsupported workarounds to let you test the "Visual Studio 2005 + Windows Mobile 5.0 SDK + Windows Vista Beta" combo. Don’t try them on your production system ;-)
Have fun!
I spent the last 5 years working with mobility at Microsoft Latam - my primary role was to work with Mobile Operators and OEMs on launching and selling WM-based devices, with ISVs/developers on targeting WM and enterprises to adopt it as their mobility solution – that position gave me a huge opportunity to meet the whole ecosystem and work with several partners around Latam.
But it was time to change...
In this case the "change" meant much more than a simple career move, but a complete life change - some months ago I accepted a position in the Windows Mobile product group in Redmond, and since end of June I have been working as Program Manager for the Windows Mobile SDK. Cool, isn't it? :-)
Life Change
As you may recall I was based out of São Paulo's office in Brazil, which means we (family) had to pack our stuff (including my Windows Mobile-based devices :) and move to Redmond. We have been enjoying a very nice and hot summer, visiting parks, outside activities and, off course, looking for houses, schools, etc.
The region is very beautiful and we are trying to settle down as soon as possible.
Career Change
I was looking for a career move that would bring me closer to technical aspects and product development on the Windows Mobile platform . I don't think I could be in a better place! :-)
My team owns the Developer Experience and we are in charge of releasing the Windows Mobile SDK, PowerToys, samples, tools, etc. - right now I'm focused on the SDK for next release of Windows Mobile, its build process, components and the relationship with all other groups that interact with the SDK.
It has been a great first month and I will post more details on all that for you soon. And as default, you can also let me know what you would like to know about the SDK!
Stay tuned!
Have you ever wonder how Device Emulator works?
Wonder no more! Barry Bond just posted about availability of shared source code for Device Emulator v1 on his blog:
This release is the full source to V1 DeviceEmulator.exe, which you can compile yourself using Visual Studio 2005.
We created this release to enable experimentation with the emulator:
- create extensibility points to "plug in" new kinds of hardware
- extend or modify the ARM-to-x86 JIT (hint: my blog on V2 performance at http://blogs.msdn.com/barrybo/archive/2006/05/23/605314.aspx has some "homework assignment" tasks).
- create emulators for whole new CPUs and motherboards
- instrument the emulator to collect performance data on your application or OS image
You can download it here!
Have fun!
Continuing on the Device Emulator, make sure to check "DeviceEmulator V2 - how did we get a 40% improvement in performance?", a great post from Barry Bond, Device Emulator's architect:
The DeviceEmulator V2 is significantly faster than the V1 emulator you're used to. Most of the performance wins come from a small set of optimizations in the ARM-to-x86 JIT and the MMU emulator. These wins improve raw execution of ARM instructions, so all applications and OSes benefit...
Barry goes on describing six "simple optimizations" that provided a "substantial performance win":
- Faster Translation Lookaside Buffer (TLB) implementation.
- Reduce x86 processor stalls due to mixed code and data
- More efficient interrupt polling
- Optimized memcpy() and memset()
- Optimizing "/Od" Code-Gen from the ARM C/C++ Compiler
- Faster Disassembly of ARM Instructions
Enjoy it!
News from the Device Emulator team:
The Microsoft Device Emulator 1.0 is a standalone version of the same ARM based Device Emulator that ships as part of Visual Studio 2005. The standalone emulator is intended for situations when you want to demonstrate or test your application on a computer that does not have Visual Studio 2005 installed. In addition, we are offering the Windows Mobile 5.0 MSFP operating system images that you can use with the Device Emulator.
You can download it here.
My post on Windows CE x Windows Mobile differences generated a lot of interesting comments, more than I had anticipated :-). Thanks to all of you who have posted your comments/questions to the blog, private messages, as well as all discussing on web forums. I thought a new post would be the best option to go through all that, so here we go answering some of them, I intend to touch all questions on next posts.
So what exactly is the difference?
For some reason I thought I had touched that point, but based on the feedback I received it is still not clear to many of you the differences between Windows CE and Windows Mobile. So let’s make sure everybody is on the same page re Windows CE:
Windows CE combines a real-time, embedded operating system with the powerful tools for rapidly creating the next generation of smart, connected, and small-footprint devices. With a complete operating system feature set and comprehensive development tools, Windows CE contains the features developers need to build, debug, and deploy customized Windows CE–based devices.
These devices can have any form-factor, any type of display or no display at all, any proprietary/customized shell; it can be extensible allowing developers to create applications targeting it, or a completely closed solution (like robot-controller).
Assuming we are all fine with this definition, let’s move on to where Windows Mobile came from. A bit of history:
Built on its own code base from the ground up, this operating system [Windows CE] debuted in September 1996. Windows CE originally ran on the Handheld PC but now is used in devices of different shapes, sizes, and degrees of ruggedness, such as mobile handhelds, industrial controllers, gateways, and advanced consumer electronics.
I sounds like WinCE was born to fulfill the need of an OS for the new handheld PC category of devices MS was looking after. I was not at MS at that time, so take this with a grain of salt: my guess is that MS realized it could launch Windows CE, as a product by itself, to partners & hardware providers. At that point the development was forked and WinCE started being developed in a group and, another group (like a device division) began using WinCE to create customized versions of the OS targeting specific form-factors, user interfaces and customer experiences.
One of the points of confusion is that MS used to call “Windows Mobile” (these customized versions of the OS) different names along the history: Handheld PC, Palm-size PC, Microsoft Pocket PC, Microsoft Smartphone and finally… Windows Mobile!
Windows CE was a strong brand on these “customized versions of the OS” until Pocket PC 2000, and started losing power after that (hence the source of confusion). Windows Mobile is now the brand we use to name these “customized versions of the OS”, targeting a PDA-like form-factor and/or a Smartphone-like form-factor.
Wikipedia has this nice image showing Windows CE timeline and the associated PDA/Smartphone OS.
Thus, the difference is: Windows CE is an OS (a real time OS) for embedded devices. Windows Mobile is an incarnation of Windows CE, with pre-built/standard shell, applications, user interface, APIs and user experience in general.
Where does Windows Automotive and Windows Mobile for Automotive fit into all of this?
Pretty much the same approach as described above. Windows CE continues to be the baseline OS, while Windows Automotive is a pre-defined version of this OS specialized for in-car computing scenarios. On February of this year, we announced “Windows Mobile for Automotive”, the new member of the Windows Mobile family. See press release here:
The Industry’s First Standardized Platform
Microsoft® Windows Mobile for Automotive provides the industry with an open, standardized platform for in-car infotainment system development. Automakers developing in-car infotainment systems using the platform can tailor functionality for specific models or desired price points. For example, a navigation system in an economy car might only provide voice prompts and a heads-up display, while a luxury model may offer a full-color LCD display featuring maps and real-time traffic information. As a result, Windows Mobile for Automotive helps the industry achieve the following:
-
Fast time to market. Manufacturers can move quickly to market with a standards-based, ready-to-install electronics gateway that gives consumers hands-free digital access to cell phones, music and information in their cars.
-
Low development costs. Windows Mobile for Automotive frees OEMs from the need to develop proprietary software — with its associated high development costs. This entry-level solution is based on a familiar Microsoft programming model and supports industry standards for reliability, power consumption and temperature variations.
-
Flexible implementation. Available in two versions, Windows Mobile for Automotive can easily be tailored to meet automakers’ needs across a variety of models, vehicle types and price points. Because the software is upgradeable, support for new devices, applications and industry standards can be added to increase functionality for drivers and passengers over the life of the car. Software upgrades can be easily deployed by the dealer via the wireless connection or USB port.
Where can we find the Portuguese original post?
You can find it here.
Following my post regarding the differences between Windows CE and Windows Mobile, I’d like to discuss the responsibility share among the Mobile Operator, device manufacturer and Microsoft on a Windows Mobile-based device, especially when you consider that this device has customizations from each of these companies (This article is also available in Brazilian Portuguese here).
Microsoft (yellow region)
Microsoft, as I mentioned earlier, is in charge of the core Operational System (Windows CE), the shell (user interface), a set of applications (Office Mobile, IE Mobile, WMP Mobile, etc.), RIL, and so on. We also expose several APIs (from both Windows CE as well as those specific to WM) and we include .NET Compact Framework/components to allow developers to extend the Windows Mobile platform.
This is the kit we deliver to the device manufacturer – as you probably have already figured out, at this stage we still don’t have a cell phone or a PDA. In fact, we are far from having a functional device, it is just a bunch of software. It varies a lot among device manufacturers, but I would guess this kit represents only 60 to, no more than, 80% of all software inside a WM-based device. The other 20 to 40% (or even more) are from the device manufacturer and the mobile operator.
Device Manufacturer (red region)
The Device Manufacturer (OEM/ODM) receives the kit and starts integrating the software with their hardware. Most of this integration is done through the development of devices drivers, allowing the hardware to talk to the software – different from the PC model, the hardware is much more specialized (less standardization) and OEMs spend a lot of time in this process.
Beyond drives, the OEM also develops and integrates the cellular technology into WM connected devices – we call it the radio stack. Although the OEM is in charge of developing all the communication with the cellular network, the OS comes with the Radio Interface Layer (RIL) allowing the radio stack (GSM or CDMA) to interact to Windows Mobile. From my point of view, this is one of the most super geek complex areas on developing a connected device.
I’d risk saying that at this point we have a functional device, and it is time to begin adding value to the platform. OEMs are able to add additional software developed by themselves or by their partners, like voice recognition, JVMs, home screen plug-ins, games, media players (other than WMP), MS Office viewers, backup software, etc. Beyond adding value to the end user, these applications allow them to differentiate their products from competitor ones.
We now have working device! In a non-connected word, this device would be ready to hit the retail stores , however, on the connected world, this would be considered a vanilla device and would still need to go through the Mobile Operator for further customizations, test and certification.
Mobile Operator (pink region)
The Mobile Operator (MO) receives the vanilla device, described above, from the OEM and starts two processes: customization and test/certification – these processes can be serialized or run in parallel according to the way the MO works.
These customizations generally are:
-
Visual: branding, colors, screen pictures, water marks, boot screens, sounds, etc.;
-
User Interface: Start Menu look-and-feel, menus position, IE Mobile favorites, speed dial, etc.
-
Applications: extra applications that the MO adds to add value to the device, differentiate it from competitors and best align the device to its current strategy/services;
-
Network: specific cellular network settings like: GPRS/EDEG (APN, user, password), WAP Gateway, SMSC address, proxies, PRI, etc.
After fully configured, the device is submitted to the final test & certification process. Test & certification is used to make sure the device complies to MO’s requirements on usability, network, reliability, etc, and it can be very complex on some MOs. It usually goes between 2 to 6 weeks and, in the case a major issue is found, the whole process is started from scratch (OEMs are in charge of customizing the device and supporting it during certification).
Once certified, the handset is finally ready to be commercialized!
End User (green regions)
Well, the end user is in charge of using the device :-). And, on using it, the user ends up personalizing it, changing the home screen picture, installing applications (business and consumer oriented), creating new network settings (proxies, VPNs), etc. ISVs, developers and enterprises can also develop corporate applications and deploy it to the device; hardware partners can also integrate barcode scanners, card readers, etc…
I hope you have had an idea of ecosystem’s roles and the complexity of making these devices available into the market – please, let me know your comments and questions.
