This morning, Wind River and Avaya sponsored a Webinar about using the Google Android OS for embedded projects beyond smartphones, tablets, and set-top boxes. The emcee was Wind River’s Senior Director of Product Management for Android Solutions Chris Buerger with speakers Dan Noal, a Senior Director and Solutions Architect at Wind River, and David DeLorenzo, a Senior Product Manager at Avaya. The Webinar opened with remarks from Curt Schwaderer of OpenSystems Media, who provided a brief but interesting background for Android. Although “everyone” knows that Apple’s iOS leads Google’s Android in sheer number of available apps, few know how quickly the gap is closing. Schwaderer presented the following graph to provide some clarity:
According to mobile research firm research2guidance, both the Apple Apps Store and the Google Android Market will have roughly 425,000 apps by August. However, these apps are primarily aimed at smartphones and tablets. Although Google’s Android (and Apple’s iOS) started as a smartphone OS and GUI, there is clear evidence that Google has intended to broaden Android’s horizons for a long time. The Gingerbread and Honeycomb versions of Android expanded the OS into more tablet-like applications and this broadening trend will no doubt continue.
There are many reasons for adopting Google’s Android OS for an embedded project. It’s an open-source OS getting a lot of attention from the development community and increasing levels of support from SoC vendors. It has a fully realized user interface and there’s a large and growing solutions-provider ecosystem for Android, but it’s primarily targeting the high-volume smartphone and tablet markets. Much of what happens in these markets can be applied to other embedded markets…but much cannot. For example, the market dynamics and cadence of embedded markets outside of smartphones and tablets are significantly different with product introductions appearing at a slower pace and support requirements stretching out to five years or more. The rapid release pace for Android can cause problems for embedded designs with longer horizons unless there’s a plan for dealing with this situation.
During the Webinar, the organizers ran a poll to find out what their viewers wanted from Android. The largest percentage was looking to gain competitive product differentiation. Now that’s difficult in the smartphone and tablet spaces. More than a dozen smartphone vendors and close to 100 tablet vendors have already introduced Android-based products. However, there are many embedded applications that can benefit from the user experience (UX) provided by the adoption of the Android OS. Previously, the overhead costs of running a fully graphical OS and user interface on products such as printers, fax machines, and other similar equipment would have been prohibitive. But the requisite 32-bit processor, the megabytes of memory, and the high-resolution display aren’t nearly as dear as they once were and the world is getting very accustomed to the benefits of a self-explaining machine interface as embodied in a full graphical interface with embedded video. In essence, the bar has been raised. Permanently.
First movers that adopt Android interfaces in these spaces can indeed provide real product differentiation.
That’s what Avaya did with the introduction of its Flare ADVD (Avaya Desktop Video Device) for business communications. It’s essentially a tablet on a pedestal with integrated video- and voice-conferencing capabilities. Avaya used Android to get a head start in software development for the product but also modified the OS to provide a unique, differentiated user interface. Apps compatibility was a secondary consideration in this case.
System Realization teams are increasingly choosing Google’s Android as the OS and GUI platform for their designs. It’s very hard to justify striking out on a different path when the development teams can start with a proven entity like Android and then customize it for specific embedded designs. Increasingly, System Realization, SoC Realization, and Silicon Realization design teams are getting the message: advanced process nodes have permanently changed the game with respect to processing power. Ignore these “new rules” at your own risk.