Android gets boxed in

As an analyst who regularly covers pay-TV technologies, I was surprised to find that some of the biggest set-top box (STB) news at this January’s Consumer Electronics Show concerned the U.S. subsidiary (Western Mediabridge) of a mid-level Korean STB maker (Celrun), demonstrating a product based on Google’s Android platform.

I had expected to hear more about multi-room DVR services or maybe the addition of 3D TV capability. After all, either of these feature sets will bring much more value to viewers than Android in itself.

But the truth was that I had badly underestimated the role of brand power. Right now, really all that Android represents for the STB market is another Linux build. While there are good technical reasons to use Android instead of the common ‘roll-your-own’ builds, a more obvious driver of adoption is the Google name.

Look at it another way. Android-in-STB advocates have been playing up ‘interactive features’ that Google’s technology can bring to the market. However, those of us with a pay-TV background tend to respond wearily. I often hear from people who have forgotten lessons in the failure of Microsoft’s WebTV technology (or hope that their listeners have). Despite claims to the contrary, Microsoft built WebTV & MSN TV well: the user interface (UI) was nearly perfect for the application as was the hardware. However, the technology simply did not connect with the fundamental value proposition for television. Television is essentially a passive experience. It delivers entertainment, and storytelling.

If a consumer wants an active experience (other than gaming), then a single-viewer, high-resolution screen (i.e., a PC) is the right tool for the job. Even someone with 20/20 vision still views a 47-inch screen from 10 feet at an effective resolution of 720p, regardless of the display’s actual resolution. The television is therefore far from ideal as the carrier of an information-rich UI.

Given that, the vast majority of ‘interactive’ TV features that have proven commercially successful have been those that make it easier for a viewer to get at the entertainment they want whenever they have time and wherever they happen to be: video on demand (VoD), single and multi-room DVRs, interactive programming guides. You can even argue that only two profit-making interactive TV features do not fit that template—gambling and custom advertisement placement. Even very basic TV-based e-commerce, such as the UK’s trials of press-to-buy ‘red button’ advertising, has failed. Consumers preferred to pick up the phone or use a separate PC to complete a purchase.

In this context, some of Android’s evangelists are taking a more practical approach. At processor specialists MIPS and ARM, and at STB system-on-chip developer Sigma Designs, staff instead say that Android’s primary technical merit is as a standardized embedded Linux build for the box market, one that is available for both of the leading IP cores. It thereby brings some needed conformity to a messy market.

STBs transitioned to Linux from various RTOS environments over the course of 2006 and 2007 as the processor cores passed the 250 Dhrystone MIPS mark for applications processing power.  However, the transition occurred one chipset at a time and was in no way coordinated or organized. As a result, the current technological landscape is made up of a hodgepodge of bespoke builds, and accommodating them adds substantial cost to STB development and testing. A standardized build is badly needed. As an embedded Linux build with major backers, Android is in the right place at the right time.

Indeed, some believe this uniformity could be taken quite some way. Ken Lowe, Sigma’s vice president of strategic marketing, also cites Android’s use of the WebKit browser engine as valuable for middleware development on boxes for the IPTV market. Many of the IPTV middleware APIs are based on JavaScript or Adobe Flash. Lowe says WebKit again represents an opportunity to minimize the number of client implementations needed for each of those.

However, this is not so attractive a model for the broader cable and satellite STB market. There, both WebKit and the Dalvik Virtual Machine (on which Java applications run on Android devices), face security concerns on the part of major network operators when it comes to pay-TV services, severely limiting the value of applications developed in these frameworks. Instead, the dominant APIs for interactive pay-TV development are likely to remain NDS’ MediaHighway and OpenTV Core. Together, these two middleware APIs are estimated to be active on 69% of pay-TV boxes. IMS Research expects each of these stacks to ultimately run themselves in Android.

We need to bear in mind that there are two fundamentally separate box markets: pay-TV and free-to-air (FTA). Pay-TV STBs support one or more of the proprietary encryption systems and must pass individual interoperability and security tests for each major operator. FTA set-top boxes are sold at retailers, do not need to support advanced encryption, and need to be tested only once. FTA boxes generally struggle to differentiate themselves from each other technologically, and often compete on price alone.

IMS Research estimates that at the end of 2009, there were just less than 400 million active pay-TV and 300 million active FTA boxes. However, pay-TV is growing much more quickly and its active installed base is forecast to rise to 730 million by the end of 2014, with the FTA market rising to only 450 million (Figure 2, p.8).

In the FTA market, the Google brand may prove a key differentiator in itself. At almost no additional cost, a FTA box maker can put Android’s Robot logo on its packaging and increase sales. Its STB will probably never be connected to the Internet, but that is not important—consumers will buy the Android box (at the same price as a competitor’s) because it “might be.”  Indeed, many of these STBs will be for standard definition MPEG-2 video, unable to support Web video, and if they have a Web browser, it will be only for basic surfing with the ability to run some casual games.

Other box providers may seek to offer a much more compelling hybrid Internet-broadcast video experience. The model here would be similar to that already emerging for Internet TVs and Blu-ray Disc (BD) players, both of which are arguably better-placed markets for taking advantage of Android’s full capabilities.

A further complication here is that while adding Web video to an STB sounds attractive on the surface, there are some commercial tensions. To the consumer, access to the on-demand streaming video already offered by companies such as Netflix, Blockbuster and Hulu can add a great deal of value. However, these services are at a very early stage in their global deployment, so there is as yet no uniform international demand for such options. Perhaps more pertinently though, a pay-TV/broadband operator may not wish to allow access to such services from its box, on the basis that such access will ‘devalue’ any on-demand services it markets itself.

Pay-TV operators are much more protective of their user experience branding than mobile operators, and only the most maverick (e.g., Free in France) have shown any willingness to open up their platforms—they still favor the traditional ‘walled garden’ model. While such operators will use Android’s capabilities to implement what they can comfortably control, and enjoy the benefits of reduced STB qualification costs thanks to the uniform software platform, they will be very hesitant to let Google or any other entity co-opt the branding of the TV experience itself.

Android is likely to help enable the launch of low-cost IP-video/Web-server-based VoD rollouts by smaller IPTV and cable operators. However, its wider value in the pay-TV STB market will come down to its technical merits as a standardized Linux build—with the brand (and thereby Google’s association with the services offered) kept ‘under the hood’.

One thing that could add a great deal of value for Android in pay-TV is the ability to emulate Java-for-TV, the Open Cable Application Platform (OCAP), Europe’s Multimedia Home Platform (MHP), Globally Executable MHP, BD Java, Ginga) in the Dalvik VM.  Dalvik VM environments that mirror the various GEM flavors should be a priority for this ecosystem. A royalty-free OCAP stack will give Android a unique value proposition for the lucrative U.S. cable market, and the other GEM flavors would be very valuable in Korea, Italy and Brazil.

Finally, a word of caution. Fragmentation could kill Android in the STB space—especially as the standard Google builds of Android must be modified. The Open Embedded Software Foundation lacks the means on its own to prevent fragmentation, leaving the task to MIPS and ARM—both of whom are working hard to create and maintain standardized builds for each environment. However, without some willingness on the part of Google to at least tacitly acknowledge the importance of the STB market by creating a build for it that runs without modification, box makers could simply go back to the chip-specific Linux builds they have been using. Froyo, the platform’s next version, is rumored to meet this need, but that has yet to be confirmed.