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.
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
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
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
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
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"
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
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
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.
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
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
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. ]
to post comments)