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.â