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.

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.

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.

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.

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
wget http://www.kernel.org/pub/linux/kernel/v3.0/linux-3.1.9.tar.bz2
tar jxvf linux-3.1.9.tar.bz2

Apply the Raspberry Pi patch

cd $RASP_SRC_BASE/kernel/patches/
wget http://www.cnx-software.com/patch/r-pi_linux_3.1.9.patch.gz
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
wget https://sourcery.mentor.com/sgpp/lite/arm/portal/package9728/public/arm-none-linux-gnueabi/arm-2011.09-70-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2
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/
wget https://dl.dropbox.com/u/24888185/android_3.1.9_patch.tar.gz
gunzip android_3.1.9_patch.tar.gz
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
wget https://dl.dropbox.com/u/24888185/rasp_android_defconfig.gz
gunzip rasp_android_defconfig.gz
mv rasp_android_defconfig .config

Make the kernel

make -k -j6

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.

Networking on a Headless Android System

Android isn't the most intuitive environment for setting up networking on the command line. After playing with several different options here's what I've found.

Summary

# netcfg eth0 dhcp

# route add default gw 192.168.0.1 dev eth0

# setprop net.dns1 208.67.222.222
# setprop net.dns2 208.67.222.220

Details

The Android tools are quite different from the tools found on other embedded Linux systems, so most people I've talked to have had difficulty figuring out what utilities to use and how to use them. The most interesting one is ifconfig. When you type ifconfig on an Android system nothing happens. On a standard busybox or gnu based Linux system you will see the available networking interfaces and their associated settings (ok, technically ifconfig -a will show you that information). Since ifconfig doesn't show anything, most people assume (incorrectly) that it doesn't work.

On my development platform, to set a static IP address, I did the following:

# ifconfig eth0 192.168.0.84 netmask 255.255.255.0

Which didn't give any response, but DID show the following when I did netcfg.
  
# netcfg
lo       UP    127.0.0.1       255.0.0.0       0x00000049
eth0     UP    192.168.0.84    255.255.255.0   0x00001043
usb0     DOWN  0.0.0.0         0.0.0.0         0x00001002
tunl0    DOWN  0.0.0.0         0.0.0.0         0x00000080
gre0     DOWN  0.0.0.0         0.0.0.0         0x00000080
sit0     DOWN  0.0.0.0         0.0.0.0         0x00000080

So what about DHCP you may ask?

# netcfg eth0 dhcp

Which yields the following.

# netcfg
lo       UP    127.0.0.1       255.0.0.0       0x00000049
eth0     UP    192.168.0.227   255.255.255.0   0x00001043
usb0     DOWN  0.0.0.0         0.0.0.0         0x00001002
tunl0    DOWN  0.0.0.0         0.0.0.0         0x00000080
gre0     DOWN  0.0.0.0         0.0.0.0         0x00000080
sit0     DOWN  0.0.0.0         0.0.0.0         0x00000080

Just because you have an IP address now doesn't mean the applications on your Android device can get to the network. For that you have to set a default route and set the DNS resolver addresses.  Again, with route keep in mind it won't show the usual output that a standard busybox or gnu based embedded Linux system would show.

To set the default route:

# route add default gw 192.168.0.1 dev eth0

And to set the DNS (I'm using OpenDNS addresses here):

# setprop net.dns1 208.67.222.222
# setprop net.dns2 208.67.222.220

And that allows the holy grail of a DNS resolved ping to a domain on the Internet.

# ping google.com
PING google.com (74.125.224.134) 56(84) bytes of data. 
64 bytes from nuq04s09-in-f6.1e100.net (74.125.224.134): icmp_seq=1 ttl=57 time=41.5 ms
64 bytes from nuq04s09-in-f6.1e100.net (74.125.224.134): icmp_seq=2 ttl=57 time=43.2 ms

References

I found some great information in the following links.

http://www.anddev.org/advanced_networking_with_android-linux-t155.html

http://elinux.org/Android_Networking

Headless Android on Raspberry Pi - Progress Report

I know you are all dying to know how my progress has been going on the Raspberry Pi Android port. Well, it's coming along. 

The Raspberry Pi currently uses a 3.1.9 ARM Linux kernel. The version of Android I decided to port over uses the 3.0.8 ARM kernel. To patch the 3.1.9 ARM kernel with Android, I had to go a circuitous route.

It would have been pretty easy if there were patches already out there that were JUST Android patches. I couldn't find any. I'm sure there is a way, using Git, to isolate the Android patches from the Git Android repository, but I haven't spent enough time playing with Git to do it. So, I went the old fashioned way.

To create my own isolated Android patch, I first needed to find an Android running on a 3.x.x version of the kernel. Ice Cream Sandwich is running against a 3.0.8 kernel (at the time I did this post) so that is where I started. The trick was to not include any ARM patches with the isolated Android patch because I needed to keep all of the Raspberry Pi ARM changes in tact.

So, starting with an x86 3.0.8 Android kernel I found, I created a patch from stock x86 3.0.8 to Android x86 3.0.8. That gave me an isolated Android patch. Then I applied that isolated Android patch to the 3.1.9 Raspberry Pi kernel. That took my Raspberry Pi kernel to an Android kernel.

Now I need to make the modifications to the Ice Cream Sandwich Android to make it a Headless Ice Cream Sandwich (in the shape of an Android, of course.)

Note:
Why x86? Well, that's a good question.

In order to get a clean isolated Android patch I needed to start with something that I could:
a) get a good clean stock kernel for, and
b) if there were unnecessary changes to the architecture or driver files they wouldn't affect and ARM system.

I could have attempted an ARM 3.x.x kernel but it's pretty hard to find an ARM kernel (of the 3.x.x revision) with an matching ARM kernel with Android that you would have confidence that the ARM portion is all the same. At least the x86 stuff is fairly well known and consistent.

Stay tuned, more to come!