Embedded Linux is hard to define, but at least we know now that Linux pros say Android is not embedded Linux. (See part 1 in this series, Android vs. Embedded Linux and this week’s Q&A with Mentor Graphics’ John Cherry.) That doesn’t mean, however, that Android isn’t useful in some embedded projects. The question is: How does a developer know which operating system to choose?
While the answer can be complicated, independent embedded engineering consultant Steve Sakoman attempted to simplify the decision-making process for us.
In a few cases the answer is obvious, he said. Both embedded Linux and Android need a reasonably high-end processor to support them. If your project requires a tiny processor either for budget or design reasons, it’s best to go with an alternative OS, Sakoman said.
“Always pick the most cost effective solution hardware-wise, and if it’s good enough to run Linux, that’s your answer,†he said. “If it’s not, use one of the open solutions.â€
Similarly, neither Android nor embedded Linux is the ideal choice for a device with hard real-time requirements, Sakoman said. Use a Real Time Operating System or a distro that includes the PREEMPT-RT real-time kernel patch (see kernel developer Steven Rostedt’s Embedded Linux Conference presentation for an update on the RT patch.)
If the project has a heavy user interface component and it needs downloadable applications and content – use Android, Sakoman said. Also, if you want to do your programming in Java, Android is the right choice, he said.
If you’re more of a C/ C++ developer or your project doesn’t need any of the Google goodies that come with Android and its ecosystem, such as the maps and documents cloud services, stick with embedded Linux. The majority of embedded projects will fare better running Linux, he said.
“When a potential client tells me they want to use Android on their embedded device, my gut reaction is to be “too busy” to take on the work!
“The above is of course tongue-in-cheek. But more often than not this type of client is only asking for Android because their management read an article about how Android is taking over the embedded world.
“When we discuss the product requirements Android often turns out to be a really bad choice,†writes Sakoman.
Pros and Cons of Android on Embedded Devices
So the decision is pretty simple then, right? Not so fast. There’s a huge gray area in between an obvious Android project and a classic, fixed-function device running embedded Linux. As everyday devices take on the features of smartphones or tablets, the choice becomes harder. It pays in this situation to compare some of the pros and cons of Android as an embedded OS.
Below are some considerations raised by Linux pros during a panel discussion at Android Builders Summit last month. For a more in-depth discussion of Android’s features as an embedded OS see The Linux Foundation’s white paper, “The Growth of Android in Embedded Systems” and PlexTek Consulting’s recent white paper “Using Android in your embedded product.â€
PROS
– Android has a familiar UI. By now most users are accustomed to the “pinchy swirly zoomy†nature of the Android touch interface, said David Stewart, Embedded Linux engineering manager at Intel. This allows for more intuitive device designs for the user.
– It’s natively mobile. Android was designed from scratch with embedded systems in mind. “When I first looked at the Android stack it was such a breath of fresh air,†said Tim Bird, senior staff engineer for Sony Entertainment. “Like I wasn’t trying to wedge Unix into the embedded space anymore.†For example, the way it handles crashes and does logging is different from traditional Linux and “it’s way better for the embedded space,†he said.
– Lots of developers know Android and Java. It may be easier to find developers for a project.
– APIs make for easy development of applications. Developers don’t need to know the underlying Android architecture, just the APIs, said Zach Pfeffer, who leads the Android effort at Linaro.
CONS
– Google has ultimate control over Android’s direction. This is fine if the current Android release supports what you need to do, if you can accept the risk that future releases might not, or if can you just stick with that release forever, Sakoman said. Otherwise, “when the next dessert comes out and the middleware has changed all your stuff has to get redone,†David Stewart said.
– Android has a large software stack. This makes it hard to whittle down features without disturbing dependencies. It also hogs memory so the project needs a high-end processor.
– It’s more difficult to add hardware support. For example, “it’s not trivial to add a totally new type of sensor to Android,†said Mike Anderson, chief scientist at The PTR Group, “…unless you dig into the AOSP and understand how it’s all put together.â€
– It requires a different developer skillset. “Once you’re in Android, you’re in Android,†said Anderson. “Because now I’m no longer opening a POSIX pipe to talk between daemons. I’m writing in Java.â€
