ABS: Is Android the new embedded Linux?

The second day of this year's Android Builders Summit started off with a panel discussion of a provocative question: Is Android the new embedded Linux? As moderator Karim Yaghmour noted, it is not really a "yes or no" question, rather it was meant as a "conversation starter". It certainly had that effect and led panel members to explain how they saw the relationship between "traditional" embedded Linux and Android.

The panel

Four embedded Linux experts were assembled for the panel, with each introducing themselves at the outset. David Stewart is an engineering manager at the Intel Open Source Technology Center where he is focused on the company's embedded Linux efforts, in particular the Yocto project. Mike Anderson has been doing embedded work for 37 years and is now the CTO for The PTR Group, which does embedded Linux consulting and training. Tim Bird is a senior staff software engineer at Sony Network Entertainment as well as being involved with the Linux Foundation's Consumer Electronics Working Group. Linaro's Android lead Zach Pfeffer rounded out the group. He has been working on Android "since it was a thing" and in embedded Linux for twelve years.

What is "embedded Linux"?

Defining the term "embedded Linux" and whether it describes Android was Yaghmour's first query to the panel. Bird said that he didn't think that Android qualifies as embedded Linux. Embedded means a "fixed function device" to him, so while Sony wants to make a platform out of its TVs and other devices, which is "great stuff", he doesn't see it as "real embedded". Real embedded systems are typified by being "baked at the factory" for set functionality "and that's what it does".

Pfeffer disagreed, noting that Android had helped get Linux into some kinds of devices where it had been lacking. The Android model is a "particularly efficient way" to support new systems-on-chip (SoCs), so it provides a way for new systems to be built with those SoCs quickly. While phones and other Android devices might not fit the profile of traditional embedded devices, the Android kernel is providing a base for plenty of other devices on new SoCs as they become available.

What were the driving forces behind the adoption of embedded Linux, Yaghmour asked. Anderson had a "one word" answer: royalties, or really the "lack thereof". Bird agreed that the lack of royalties was a big deal, but the availability of the source code may have been even more important. It meant that the user didn't have to talk to the supplier again, which was important, especially for smaller device makers, because they were never able to get much support from vendors. With the source, they could fix their own problems.

Stewart noted that people tend to make the assumption that embedded means that a realtime operating system is required. Often that's not the case and Linux is perfectly suited to handling embedded tasks. There is also a certification ecosystem that has built up around embedded Linux for areas like safety and health, which helps with adoption.

In addition to the other reasons mentioned, Pfeffer noted that "Linux is fun". Often disruptive technology comes about because an engineer wants to do something fun. With a manager who is "more enlightened or maybe just cheap", they can pull their Linux hobby into work. It is much more fun to work on embedded Linux than something like Windows Mobile, and he has done both, he said.

Yaghmour then asked: what is it in Android that is attracting device makers in that direction? Stewart said that he is "not an Android guy", but he thinks it is the user interface familiarity that is drawing manufacturers in. It is not so much the app store, apps, or services, but that users are now expecting the "pinchy, zoomy, swirly" interface. Anderson agreed, noting that it makes it much easier to drop a new device onto a factory floor if users already understand how to interact with it.

Bird pointed to the silicon vendors as a big part of the move to Android. The big silicon vendors do an Android port before anything else, he said. Stewart (from Intel) noted that not all silicon vendors had that Android-first strategy, to a round of chuckles. While there is the "thorny issue" of free video driver support, Bird continued, many people are "coattailing" on the Android support that the silicon vendors provide. On the other hand, Android has been the "club" to bring some vendors to the table in terms of open source drivers, Anderson said, using Broadcom as an example.

But Pfeffer believes that the app ecosystem is the big draw. It is a "clear value proposition" for a vendor who can build a platform that can be monetized. The APIs provided by Android either won't change or will be backward compatible, so vendors can depend on them. In fact, Google doesn't document how the platform is put together because it doesn't want vendors to depend on things at that level, he said. But for vendors who are putting Android on their own hardware, they are going to have to understand and adapt the platform, Bird said. Stewart noted that he heard that early Android tablets had to just hide the phone dialer because there was no way to get rid of it. There was much agreement that customizing Android to make it smaller or faster was difficult to do.

Drawbacks to Android

That led to the next question: what are the drawbacks for Android? Bird said that it has a "really big footprint" and that "JITted code is slower than native". That is a classic tradeoff, of course. As an example he noted the first video ad in a print magazine, which used an "inexpensive" Android phone board in the magazine page. That board was around $50, so it only appeared in the first 1000 issues of the magazine. Because of the size of Android, you will not see a $5 board that can run the whole stack, he said.

Pfeffer countered that you can get Android to fit in 64M on certain classes of devices. Android doesn't prevent you from "going low", he said. Bird noted that his camera project only has 32M. Anderson described the Android platform as having "seven layers that keep you from the hardware", which adds to the complexity and size. In addition, you need a high-end GPU in order to run Ice Cream Sandwich reasonably, he said. Pfeffer said that there was the possibility of using software rendering, but there was skepticism expressed about the performance of that option.

Beyond just the footprint and complexity, are there drawbacks in how the Android community is put together and works, Yaghmour asked. Bird mentioned that there isn't really a community around "headless Android" and that there isn't really any way for one to spring up. Because "you get whatever Google puts out next", there is little a community could do to influence the direction of headless Android. If, for example, you wanted to add something for headless Android that Google has no interest in, you have to maintain that separately as there isn't much of a path to get it upstream.

There are devices that are difficult to add to Android, Anderson said. Adding a sensor that "Google never thought of" to libsensors is "not trivial". Making a headless Android system is also not easy unless you dive deeply into the Android Open Source Project (AOSP) code. Stewart noted that Android adoption is generally a one-way street, so it is difficult to switch away from it. Pfeffer agreed, noting that the companies that do adopt Android reap a lot of benefits, but "it is a one-way trip".

When he started looking at Android, Yaghmour thought it would be "easy", as it was just embedded Linux. There was a lot more to it than that, with various pieces of the Linux stack having been swapped out for Android replacements. But that's a good thing, Bird said. His "strong opinion" was that Android is a "breath of fresh air" that didn't try to force Unix into the embedded space. Android was able to discard some of the Unix baggage, which was a necessary step, he said. There are some really good ideas in Android, especially in the app lifecycle and the idea of intents, all of which added up to "good stuff".

Android was in the right place at the right time, Anderson said. For years, embedded Linux couldn't make up its mind what the user interface would be, but Android has brought one to the table. Android also takes into account the skill set of programmers that are coming out of school today. Constrained environments are not often taught in schools, so the "infinite memory" model using Java may be appropriate.

Stewart noted that HTML5 still has the potential for cross-platform user interfaces, and doesn't think the door should be closed on that possibility. Yocto is trying to support all of the different user interface possibilities (Qt, GTK, EFL, HTML5, ...). There is also the question of the future of Java, Anderson said. The security issues that Oracle has been slow to fix is worrisome, and no one really knows where Oracle plans to take Java.

While embedded Linux has nothing to learn from Android on the technical level, it could take some higher-level lessons, Pfeffer said. Focusing on creating an ecosystem from the app developer to the user is extremely important. Beyond that, reducing the time to market, as Android has done, so that a new widget using a new SoC can be in the hands of app developers and users quickly should be a priority. Existence proofs are very powerful, so a system which has a billion users that a device maker can just plug into is compelling, he said.

Licensing

For the most part, Android started with a clean slate for licensing reasons, Yaghmour said; what are the pros and cons of that decision? The licenses do have an effect, Bird said, and the BSD/Apache license nature of Android changes how companies perceive their responsibilities with respect to the open source communities. Companies like BSD licenses, but it doesn't encourage them to push their changes upstream—or to release them at all. That means we don't really know how much interesting technology is getting lost by not being shared, which "is a worry", he said.

Stewart noted that the BSD license seemed to remove the "multiplicative effect" that you see in code bases that are licensed under the GPL. He pointed out that the BSDs themselves seem to suffer from that because sharing the code is not required. Anderson said that the vendors hiding their code make it hard for his company to help its customers. If a codec the customer wants doesn't work with the PowerVR GPU drivers, there is little he can do to help them. Some of those vendors are just "hiding behind the license", he said.

The license situation is a "red herring", according to Pfeffer, because "market pressure will trump any licensing issues". If a GPLv3-licensed component will help a device maker beat their competitor to market, "it will ship".

Embedded Linux and Android can coexist both in the community and in the same devices, the panel agreed. The key is the kernel, Anderson said, as long as that is present one could run the Android user interface atop a realtime kernel, if you understand the architecture of both sides. Another possibility would be to use virtualization, Stewart said, perhaps in an automotive setting with Android games and apps in the back seat running in a VM on a more traditional embedded Linux system to control the critical systems.

Yaghmour's final question asked whether we will eventually see Android "wipe embedded Linux off the map". All except Pfeffer had short "no" answers. Pfeffer said he would hate to see traditional embedded Linux go away, but that we may see it eventually. He likened Android to the invention of the loom. Prior to that invention, textiles were crafted by hand, but the loom standardized how you create textiles, and Android may do the same for Linux devices. Anderson and Bird were quick to point out SoCs and platforms where Android will never run as counter-examples. Stewart had the last word on that question when he described Pfeffer's answer as something like what "Bill Gates would have said"—to a round of laughter from participants and audience alike.

[ Thanks to the Linux Foundation for assisting with travel costs to San Francisco for ABS. ]

---

(Log in to post comments)