ABS: Android beyond the phone

The first Android Builders Summit (ABS) was held April 13-14 as part of the Linux Foundation's "two weeks of conferences" in San Francisco. ABS overlapped the last day of the Embedded Linux Conference (ELC), so many of the ELC attendees sat in on ABS talks, at least for the first day. On the second day, Marko Gargenta of Marakana gave a keynote that looked at uses of Android beyond its traditional consumer mobile phone (and now tablet) niche. He also outlined some of the reasons that device makers are turning to Android.

Advantages of Android

Gargenta is the author of Learning Android and has worked with various companies to help them with their Android plans. There are three main advantages that Android brings to the table which are important to device makers, he said. First that it is an open platform and it is relatively easy to get the source code and customize it. Second that it has "apps" and lots of developers are embracing the platform. And third that it is a "complete stack" that provides nearly all of the services that are required to create a product.

While Android is an open platform, as evidenced by Andy Rubin's famous tweet—though the tweet is missing two important steps (envsetup.sh and lunch) as Gargenta and audience members pointed out—it isn't much like other open source projects. There is no Git tree that contains "whatever was checked in the night before"; instead there are somewhat infrequent code drops. With Honeycomb (Android 3.0), even those have stopped, which is something that concerns some companies who are basing their products on Android. It may eventually cause them to reconsider using it.

Applications for Android are important, but it's not really the existing applications that are interesting, rather it is the "model for developing applications" that attracts the device makers. Many existing applications may run on a modified Android, but that is just a "bonus", he said. When you look at Android as a whole, it has all of the pieces from the hardware up, including the Linux kernel, libraries for many of the things the device vendors need to be able to do, Java, and the application development model, which is what makes it a complete stack. This stands in contrast to standard embedded Linux or Java ME, which aren't a complete stack.

Case studies

Gargenta then launched into several case studies of devices using Android. The projects were ones that he had worked on, though some were not public (or not public yet), so he didn't reveal the company behind them.

The first was a multi-function printer/scanner/copier device where the user interface would be built with Android. The application development framework was one of the most attractive parts of Android, not because they would be putting Market applications on the device, but because they could have independent developers work on the interface. There are lots of developers out there who can write to the Android APIs.

The complete stack approach of Android was also appealing because the system already has support for graphics, touchscreen interaction, and networking. There were some missing pieces, of course, including drivers and C libraries to talk to the proprietary printer/scanner hardware, Java interfaces for that hardware, and a new "home" application. Instead of the usual Android user interface, a custom application was written that didn't include things like an application drawer or status bar. In fact, users of the device may never know that they are using Android, he said.

Two different device types that Gargenta described had similar requirements and had many of the same reasons for going with Android. The first was a "public safety solution" for handling communications during catastrophes that was developed by a major OEM, while the other was a device for the US Department of Defense (DoD). In both cases, the availability of "off the shelf" hardware that runs Android was attractive. For the public safety application, it's important that multiple kinds of hardware can be used, as various different agencies need to be able to coordinate their efforts.

Once again, the application framework provided by Android is appealing because it allows multiple developers to work on various parts of the problem, more or less simultaneously. The large developer base is attractive as well. Both projects were concerned with stopping installation of "unapproved" applications, either from the Market, or by restricting which repositories the devices could access.

As might be guessed, the DoD project had further security concerns. It is important to ensure that the device is being used by an authorized person, so attaching a USB device as part of the authentication process is required. The existing Android code did not support application access to the USB ports, so that was added. In addition, device management was added so that devices could be tracked or remotely wiped, and so that password policies could be enforced.

Both projects had an interest in the priority of Android services. In general, radio communications should not be interrupted by text messages or a game, so the assumptions needed to be tweaked from those of a consumer device. Determining which services are critical can be difficult, Gargenta said. For example, "are media services that critical in a life or death situation?", he asked. They may or may not be, depending on the media in question.

The Cisco Cius was another example that Gargenta presented. It is meant to be an "iPad for business" that looks something like a desktop video phone, but the video screen part can be removed to become a mobile tablet device. [PULL QUOTE: The "open and portable" nature of Android was one of its selling points, but the company is rethinking Android because of the Honeycomb availability issue. END QUOTE] The "open and portable" nature of Android was one of its selling points, but the company is rethinking Android because of the Honeycomb availability issue. Google is also not helping adoption in the enterprise market because it is not telling anyone what its plans are for things like device management and security, he said.

The Cius has its own Market where applications are much more carefully vetted and generally have higher quality. The Cius also adds multi-user support, which is not something that Android does, but is, of course, available in the underlying Linux kernel. The device also provides video conferencing and Voice over IP telephony support; the latter was added before Google released Gingerbread with SIP support, because there is no Android roadmap.

Android set-top boxes were another use that Gargenta described. Google TV is not available as an API, so it can't be used for television applications. Android is attractive for the usual reasons, but has some drawbacks as well. Appeasing content providers with DRM solutions is one area that needed to be addressed in the two projects he worked on. The Android user interface is also not usable for TVs, but it is relatively straightforward to create one, partly because Android was designed to support multiple devices.

The last case study from Gargenta's talk was for "networked cars". Visteon has created a prototype of a Android-based dashboard for cars. One of the more interesting characteristics of such a device is that it requires multi-screen support, which is not something that comes out of the box with Android. But it does make a good platform for doing user interface development quickly, he said.

He listed a number of other Android-based products that he knew of, including home security systems, scientific calculators, microwaves, and washing machines. One thing that Gargenta didn't mention was whether any of the changes being made by these device makers were being pushed back to Google for possible inclusion into Android. One gets the sense that, in keeping with the secrecy that often shrouds the embedded world, those changes may well be held back. It's also not clear if the custom Linux drivers for various hardware devices are being released in source form, as Gargenta didn't really address the kernel in his response to an audience question about licensing.

It certainly was interesting to hear where Android is being used, especially in devices that stray far from its roots. In many ways it is just an extension of the enormous penetration that Linux has made into the embedded world. Whether other "full stack" solutions, like MeeGo or WebOS, can make inroads into devices over the next few years will be interesting to watch.

The conference

While ABS definitely had some interesting talks, some of which I hope to write up in coming weeks, it was rather different than one might have expected. The first two keynotes were essentially extended advertisements for the speakers' companies (Motorola and Qualcomm), which is not at all the norm at technical conferences. In addition, it was rather surprising to see a complete lack of Google speakers—and sponsorship. Some noted that the Google I/O conference was scheduled a few weeks after ABS, but that doesn't seem like reason enough for that level of non-participation. If the LF plans to reprise the conference next year, fixing the keynotes and working with Google would likely result in an even better conference.