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.
Documentation
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.
Debugging
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.
Market
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.
Summary
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.
