Wednesday, January 22, 2014

Android and Embedded Linux - Can't we just live together in peace?

I was watching my news feed today and ran across this article. It is an interesting discussion about whether Android can challenge Embedded Linux as an operating system for embedded devices.

Can Android Challenge Embedded Linux

I can easily see areas where Embedded Linux will continue to have a strong hold. As the article mentions, if you have a single purpose built device, why use something as flexible as Android?

However, there are two points I think are still important that weren't mentioned in the article.
  1. Developers - Any one who has had the task of hiring good Embedded Linux Engineers can tell you that it can be a difficult market. Getting good Android (mostly Java) developers can be easier.
  2. Extensibility - If you aren't building a single purpose built device, then choosing a good application framework is absolutely critical. Android is a pretty good application framework.
In essence it comes down to what you are trying to do with your device. If it's a purpose built golf ball cleaning machine, you are pretty safe not using a high level application framework like Android. If your golf ball cleaning machine has a fancy UI that lets you choose just how your golf balls are washed, dried, and teed up for you, then maybe Android would be your OS of choice.

In the grand scheme of things though, my pick is to use Embedded Linux as your OS and if you have need of a higher level application framework, then pick Android. Best of both worlds - it's not an either/or.

Thursday, October 24, 2013

A "look but don't touch" kind of open

I saw an article today on Ars Technica that has a really good write up on how Google is controlling open source Android. In a world where Android has 80% of the market, I can certainly see why Google is itching for more control. I can't fault them.

In a Headless Android world, many of the points in the article don't hold much sway. It's mostly about apps and Google Play services. However, some of the APIs that have been tied in to some of Google apps, like location services, could be very relevant to Headless Android.

Here is the link. It's worth the time to read.

Google's iron grip on Android: Controlling open source by any means necessary

Wednesday, June 19, 2013

Presentation - The Growth of Android in Embedded Systems

I was watching my Google alerts today and an interesting presentation by Benjamin Zores he gave at Droidcon 2013 in Paris this week came up. I would have loved to have seen the actual presentation, but the slides give a pretty good summary of what he talked about.

The Growth of Android in Embedded Systems

He certainly raised some valid points in his conclusions, that (as I read it) Android isn't for everyone. Ice Cream Sandwich pushes the resource limits pretty high, generally due to graphics requirements. Benjamin's final conclusion states that Android is good for devices featuring an LCD screen and are primarily app-driven.

For non-UI focused devices, Android is only beneficial if you can turn off all that UI stuff and still maintain the power of the platform. It remains to be seen whether Google will see the vision in a Headless Android port (doubtful) so in the mean time, the heavy lifting is left up to individual companies.

Tuesday, December 18, 2012

OSGi and Android - A Comparison

When you think about Headless Android the logical market for the technology is in a headless router or gateway. When you compare technologies, and specifically software stacks, on these products there are a couple of big front runners when it comes to actual deployments. Unfortunately Headless Android isn't one of them... yet.

However, if you look at the landscape of gateways, one of the predominant technologies running on many of them is OSGi. Over the past several months I've been digging into OSGi and how it relates to Headless Android (which is why the Blog has been somewhat silent since July). Here are some interesting things I've found so far.

OSGi is the Open Software Gateway Initiative. If you aren't familiar with it, Google is your friend.


The Android documentation, as many of you are aware, is very well done. I have found there is ample, easy to use documentation on the API's, how they are supposed to be used, and usually some very easy to understand examples.

OSGi on the other hand... doesn't. If you know the specification well enough that you don't need the documentation, then the documentation is fine though. (Yes, that's sarcasm). 

Multiple JVM Instances

One of the biggest differences I've seen between the two is the choice of Android to use multiple JVM instances, one for each process running. I have often wondered over the past few months if they guys at Android had used OSGi and asked themselves if there was a better way. I'm a HUGE fan of the Android multiple JVM approach now that I've spent some quality time with OSGi.

For example, I was doing a demo on OSGi with a huge customer at the International Broadcasters Convenction in Amsterdam a few months ago and there was a problem with the implementation of XMPP we were using. About 80% of the time it when the client code would attempt to log in to an XMPP server it would hit a race condition in the framework and the application would crash. Unfortunately it would crash the entire JVM so the OSGi framework would also crash. The JVM vendor had to get involved to get the issue resolved (which took several months). Very painful.

JVM Support

Dalvik is a great JVM. I've been impressed with it when running Android. Since OSGi is a framework, it will run on just about any JVM. To the novice OSGi implementor (me) that actually caused a lot of confusion. The OSGi vendors I was working with couldn't answer questions about the JVM. None of the documentation covered both the JVM and the OSGi framework, so you end up having to dig in two places to find answers.

I realize that having multiple JVM support can be a really good thing. It's just painful because it's so decoupled.

Standard versus Open

The OSGi framework is a standard. In essence it's a big document that describes how the OSGi framework should work. Several vendors have implemented this standard so there are various flavors of the framework. Some of these implementation are open, some are not. That certainly gives the market choice.

Android, on the other hand, is open but not a standard. You could argue that because of it's popularity it's quickly becoming a standard (which I would agree with), but there is really only one Android implementation (officially). Google supports and maintains it, along with the JVM.


One of the biggest strengths that Android has over OSGi is in the ability to debug an application. Following any one of several "How To" web pages will get you debugging a hello world application in Android on a device in just an hour or two. Trying to do the same on OSGi is at best an exercise in frustration and at worst impossible (from my experience). It's easier to go back to the days of print debugging.


In general terms, the markets for OSGi and Android have not overlapped. OSGi has been mainly adopted in the telco/cable world and has a rich infrastructure for managing a device in a home. Another area that OSGi is strong is in the Enterprise realm. It certainly never made a big splash in mobile phones or tablets.

As with most technology, convergance is happening though. Mostly from the Android world creeping in to the traditional OSGi markets. At IBC I saw several prototypes of Android based set top boxes. I expect this trend to continue.


Overall OSGi has some nice features and the idea of a framework is really beneficial. OSGi certainly has been around long enough to be pretty solid and reliable. It also has back-end management capabilities that Android is still coming up to speed on (quickly).

Having used the two now for a bit, my opinion, for what it's worth, is that Android is a much better system to write and debug code with. Long live the robotic human analog.

Tuesday, September 11, 2012

Android Set Top Box

I had the opportunity to attend the International Broadcasting Convention last week and I was pleasantly surprised to find a few set top boxes (STB) running Android.

Echostar Europe Android STB

Engadget Writeup of the Echostar Android STB

I also saw a demonstration in the Intel booth of an Android STB. It looked like all of them were running ICS.

While they aren't headless, Android on a STB is pretty cool.

Tuesday, July 3, 2012

Android Raspberry Pi Kernel Build Walkthrough

I've had some queries on the blog about building the Raspberry Pi kernel I hacked together. Here are the instructions on how to compile the Android kernel for the Raspberry Pi environment.

This kernel should work with the headless Android filesystem.

NOTE: Since I have not been able to get my hands on the hardware I haven't tried it myself. You are on your own with this. I doubt it works right out of the box...

Build Instructions

All build instructions reference the base directory where you want to put the source files. For me I used:
export RASP_SRC_BASE=~/work/raspberry-pi

Get the kernel sources for linux-3.1.9

mkdir -p $RASP_SRC_BASE/kernel/patches
cd $RASP_SRC_BASE/kernel
tar jxvf linux-3.1.9.tar.bz2

Apply the Raspberry Pi patch

cd $RASP_SRC_BASE/kernel/patches/
gunzip r-pi_linux_3.1.9.patch.gz
cd $RASP_SRC_BASE/kernel/linux-3.1.9
patch -p1 < ../patches/r-pi_linux_3.1.9.patch

Get the Toolchain

cd $RASP_SRC_BASE/toolchain
tar jxvf arm-2011.09-70-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2 

Set up the environment variables

export PATH=$PATH:$RASP_SRC_BASE/toolchain/arm-2011.09/bin
export CROSS_COMPILE=$RASP_SRC_BASE/toolchain/arm-2011.09/bin/arm-none-linux-gnueabi-
export ARCH=arm
export CCACHE_DIR=~/.ccache/
export USE_CCACHE=1

Make sure the build works

At this point, configure and build the Raspberry Pi kernel.

Configure the kernel

cd $RASP_SRC_BASE/kernel/linux-3.1.9
cp arch/arm/configs/bcmrpi_cutdown_defconfig .config
make oldconfig

Make the kernel

make -k -j6

Apply the Android kernel patch

cd $RASP_SRC_BASE/kernel/patches/
cd $RASP_SRC_BASE/kernel/linux-3.1.9
patch -p1 < ../patches/linux-3.1.9-stock-to-android.patch

patch -p1 < ../patches/linux-3.1.9-fs-proc-base.patch
patch -p1 < ../patches/linux-3.1.9-yaffs2.patch
patch -p1 < ../patches/linux-3.1.9-power.patch

Build Raspberry Pi Android

You are ready to build the Raspberry Pi Android kernel now.

Configure the kernel

cd $RASP_SRC_BASE/kernel/linux-3.1.9
gunzip rasp_android_defconfig.gz
mv rasp_android_defconfig .config

Make the kernel

make -k -j6

Tuesday, June 26, 2012

Android and Emerging Markets

I recently read an article in The Register by a friend of mine, Matt Asay. He has a pretty good point about Android being the dominant player in the BRIC market. I can remember going to CES and being surprised ten years ago how many odd cheap devices were using Linux, but had really terrible interfaces. Thanks to Android, now those devices have a compelling interface and access to the Android application market.

Matt's point though is about revenue. If you can't charge people for apps because you don't have a credit card on file, and advertising isn't targeting them necessarily, how do application developers make money in those emerging markets?

For that matter, what about devices without a UI at all? Is there a way to monetize services without an interface? If you have a smart phone that can connect to a headless device in your home where the headless device is doing some "work" for you, like keeping track of energy usage for example, would the money be made on the secondary device and the application on the smartphone is just a way to connect to it to get at the information?

There are certainly many questions left to answer on this topic. It will be really interesting to see where the market goes, especially in the BRIC countries.