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!

Memory Comparisons - Headless Android vs. Full Android

After some questions on the blog about memory comparisons, I pulled some information together off of my Freescale development board. Here is the information I've pulled together. From what I see the information shows:

MemFree difference = 337320 kB - 265888 kB = 71432 kB saved (21%)

The other interesting one is with the Active in each case:

Active difference = 95892 kB - 44632 kB = 51260 kB saved (53%)

Here is the raw information from the memory usage off of my development board.

Using the standard Android image with no Headless Android changes:

Free shows:

# busybox free
              total         used         free       shared      buffers
  Mem:       442740       177932       264808            0         2000
 Swap:            0            0            0
Total:       442740       177932       264808
Here is the meminfo off of the development board.

# cat /proc/meminfo
MemTotal:         442740 kB
MemFree:          265888 kB
Buffers:            2000 kB
Cached:            79248 kB
SwapCached:            0 kB
Active:            95892 kB
Inactive:          46456 kB
Active(anon):      61140 kB
Inactive(anon):      328 kB
Active(file):      34752 kB
Inactive(file):    46128 kB
Unevictable:           0 kB
Mlocked:               0 kB
HighTotal:             0 kB
HighFree:              0 kB
LowTotal:         442740 kB
LowFree:          265888 kB
SwapTotal:             0 kB
SwapFree:              0 kB
Dirty:                 0 kB
Writeback:             0 kB
AnonPages:         61108 kB
Mapped:            32100 kB
Shmem:               372 kB
Slab:               7888 kB
SReclaimable:       4164 kB
SUnreclaim:         3724 kB
KernelStack:        2056 kB
PageTables:         6276 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:      221368 kB
Committed_AS:     929976 kB
VmallocTotal:    1433600 kB
VmallocUsed:       85784 kB
VmallocChunk:    1320964 kB


With the following process list.

# ps
USER     PID   PPID  VSIZE  RSS     WCHAN    PC         NAME
root      1     0     324    188   800e9ea4 0000875c S /init
root      2     0     0      0     80080268 00000000 S kthreadd
root      3     2     0      0     8006f8b4 00000000 S ksoftirqd/0
root      4     2     0      0     8007cacc 00000000 S events/0
root      5     2     0      0     8007cacc 00000000 S khelper
root      8     2     0      0     80086f80 00000000 S async/mgr
root      9     2     0      0     8007cacc 00000000 S pm
root      12    2     0      0     8007cacc 00000000 S suspend
root      81    2     0      0     800558a0 00000000 S usb_wakeup thre
root      82    2     0      0     800558a0 00000000 S usb_wakeup thre
root      240   2     0      0     800b925c 00000000 S sync_supers
root      242   2     0      0     800b9d3c 00000000 S bdi-default
root      244   2     0      0     8007cacc 00000000 S kblockd/0
root      258   2     0      0     8007cacc 00000000 S mxc_spi.0
root      266   2     0      0     8007cacc 00000000 S otg_switch/0
root      272   2     0      0     80294ca8 00000000 S khubd
root      295   2     0      0     8007cacc 00000000 S kmmcd
root      309   2     0      0     80315228 00000000 S pmic-event-thre
root      373   2     0      0     8007cacc 00000000 S rpciod/0
root      393   2     0      0     800b3904 00000000 S kswapd0
root      441   2     0      0     8007cacc 00000000 S aio/0
root      451   2     0      0     8007cacc 00000000 S nfsiod
root      455   2     0      0     8007cacc 00000000 S crypto/0
root      1073  2     0      0     8022bd8c 00000000 S kapmd
root      1148  2     0      0     802bb8d4 00000000 S file-storage
root      1199  2     0      0     8007cacc 00000000 S kstriped
root      1204  2     0      0     8007cacc 00000000 S kconservative/0
root      1209  2     0      0     8007cacc 00000000 S vpu_wq/0
root      1216  2     0      0     8007cacc 00000000 S esdhc_wq/0
root      1219  2     0      0     8007cacc 00000000 S esdhc_wq/0
root      1228  2     0      0     8007cacc 00000000 S usbhid_resumer
root      1231  2     0      0     8007cacc 00000000 S binder
root      1250  2     0      0     8032eefc 00000000 S mmcqd
root      1289  2     0      0     8007cacc 00000000 S l2cap
root      1290  2     0      0     804517f4 00000000 S krfcommd
root      1302  2     0      0     80315c1c 00000000 S mxc_ts
root      1303  1     300    156   800e9ea4 0000875c S /sbin/ueventd
root      1485  2     0      0     80247e28 00000000 S scsi_eh_0
root      1487  2     0      0     802aef98 00000000 S usb-storage
root      2147  2     0      0     8015a0e4 00000000 S jbd2/mmcblk0p2-
root      2148  2     0      0     8007cacc 00000000 S ext4-dio-unwrit
root      2149  2     0      0     800f9d94 00000000 S flush-179:0
root      2150  2     0      0     8015a0e4 00000000 S jbd2/mmcblk0p5-
root      2151  2     0      0     8007cacc 00000000 S ext4-dio-unwrit
root      2152  2     0      0     8015a0e4 00000000 S jbd2/mmcblk0p6-
root      2153  2     0      0     8007cacc 00000000 S ext4-dio-unwrit
root      2155  1     744    328   8006d5a0 6fd0c3ac S /system/bin/sh
system    2156  1     816    272   80343750 6fd0b6fc S /system/bin/servicemanager
root      2157  1     3872   588   ffffffff 6fd0bdac S /system/bin/vold
root      2158  1     3872   576   ffffffff 6fd0bdac S /system/bin/netd
root      2159  1     820    320   800e9ea4 6fd0b844 S /system/bin/dispd
root      2160  1     676    256   8037b6ac 6fd0c0cc S /system/bin/debuggerd
root      2161  1     83416  27160 800e9ea4 6fd0b844 S zygote
media     2162  1     27572  5492  ffffffff 6fd0b6fc S /system/bin/mediaserver
bluetooth 2163  1     1264   696   800e9ea4 6fd0c59c S /system/bin/dbus-daemon
root      2164  1     824    332   803fd98c 6fd0b45c S /system/bin/installd
keystore  2165  1     1752   424   8037b6ac 6fd0c0cc S /system/bin/keystore
radio     2166  1     5460   700   ffffffff 6fd0bdac S /system/bin/rild
root      2230  2     0      0     80247e28 00000000 S scsi_eh_1
root      2231  2     0      0     802aef98 00000000 S usb-storage
system    2256  2161  192540 38596 ffffffff 6fd0b6fc S system_server
root      2266  2     0      0     8007cacc 00000000 S z1xx_workq
app_17    2410  2161  99260  19152 ffffffff 6fd0c51c S com.android.inputmethod.latin
radio     2417  2161  109916 20816 ffffffff 6fd0c51c S com.android.phone
system    2419  2161  140892 20728 ffffffff 6fd0c51c S com.android.systemui
app_16    2485  2161  98312  22172 ffffffff 6fd0c51c S com.android.launcher
app_1     2498  2161  104776 22132 ffffffff 6fd0c51c S android.process.acore
app_11    2529  2161  105400 17672 ffffffff 6fd0c51c S com.android.mms
app_12    2534  2161  94620  17996 ffffffff 6fd0c51c S android.process.media
app_20    2558  2161  94648  17988 ffffffff 6fd0c51c S com.android.email
app_21    2568  2161  93140  16192 ffffffff 6fd0c51c S com.android.deskclock
app_26    2583  2161  92336  16520 ffffffff 6fd0c51c S com.android.providers.calendar
app_30    2593  2161  92368  16312 ffffffff 6fd0c51c S com.android.bluetooth
app_5     2600  2161  92172  15680 ffffffff 6fd0c51c S com.android.quicksearchbox
app_7     2611  2161  91804  14856 ffffffff 6fd0c51c S com.android.protips
app_10    2623  2161  92340  15004 ffffffff 6fd0c51c S com.android.music
app_19    2630  2161  93468  16588 ffffffff 6fd0c51c S com.cooliris.media
root      2766  2155  904    312   00000000 6fd0b45c R ps
Using the Headless Android image on my development board.

Free shows:

# busybox free
              total         used         free       shared      buffers
  Mem:       442740       105240       337500            0         1464
 Swap:            0            0            0
Total:       442740       105240       337500
Meminfo after five minutes shows:

# cat /proc/meminfo
MemTotal:         442740 kB
MemFree:          337320 kB
Buffers:            1464 kB
Cached:            57140 kB
SwapCached:            0 kB
Active:            44632 kB
Inactive:          35124 kB
Active(anon):      21168 kB
Inactive(anon):      200 kB
Active(file):      23464 kB
Inactive(file):    34924 kB
Unevictable:           0 kB
Mlocked:               0 kB
HighTotal:             0 kB
HighFree:              0 kB
LowTotal:         442740 kB
LowFree:          337320 kB
SwapTotal:             0 kB
SwapFree:              0 kB
Dirty:                 0 kB
Writeback:             0 kB
AnonPages:         21160 kB
Mapped:            21564 kB
Shmem:               220 kB
Slab:               6108 kB
SReclaimable:       3268 kB
SUnreclaim:         2840 kB
KernelStack:         832 kB
PageTables:         1384 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:      221368 kB
Committed_AS:     173048 kB
VmallocTotal:    1433600 kB
VmallocUsed:       69096 kB
VmallocChunk:    1343484 kB

With the following ps list:

# ps
USER     PID   PPID  VSIZE  RSS     WCHAN    PC         NAME
root      1     0     324    188   800e9ea4 0000875c S /init
root      2     0     0      0     80080268 00000000 S kthreadd
root      3     2     0      0     8006f8b4 00000000 S ksoftirqd/0
root      4     2     0      0     8007cacc 00000000 S events/0
root      5     2     0      0     8007cacc 00000000 S khelper
root      8     2     0      0     80086f80 00000000 S async/mgr
root      9     2     0      0     8007cacc 00000000 S pm
root      12    2     0      0     8007cacc 00000000 S suspend
root      81    2     0      0     800558a0 00000000 S usb_wakeup thre
root      82    2     0      0     800558a0 00000000 S usb_wakeup thre
root      240   2     0      0     800b925c 00000000 S sync_supers
root      242   2     0      0     800b9d3c 00000000 S bdi-default
root      244   2     0      0     8007cacc 00000000 S kblockd/0
root      258   2     0      0     8007cacc 00000000 S mxc_spi.0
root      266   2     0      0     8007cacc 00000000 S otg_switch/0
root      272   2     0      0     80294ca8 00000000 S khubd
root      295   2     0      0     8007cacc 00000000 S kmmcd
root      309   2     0      0     80315228 00000000 S pmic-event-thre
root      373   2     0      0     8007cacc 00000000 S rpciod/0
root      393   2     0      0     800b3904 00000000 S kswapd0
root      441   2     0      0     8007cacc 00000000 S aio/0
root      451   2     0      0     8007cacc 00000000 S nfsiod
root      455   2     0      0     8007cacc 00000000 S crypto/0
root      1073  2     0      0     8022bd8c 00000000 S kapmd
root      1148  2     0      0     802bb8d4 00000000 S file-storage
root      1199  2     0      0     8007cacc 00000000 S kstriped
root      1204  2     0      0     8007cacc 00000000 S kconservative/0
root      1209  2     0      0     8007cacc 00000000 S vpu_wq/0
root      1216  2     0      0     8007cacc 00000000 S esdhc_wq/0
root      1219  2     0      0     8007cacc 00000000 S esdhc_wq/0
root      1228  2     0      0     8007cacc 00000000 S usbhid_resumer
root      1231  2     0      0     8007cacc 00000000 S binder
root      1250  2     0      0     8032eefc 00000000 S mmcqd
root      1289  2     0      0     8007cacc 00000000 S l2cap
root      1290  2     0      0     804517f4 00000000 S krfcommd
root      1302  2     0      0     80315c1c 00000000 S mxc_ts
root      1303  1     300    156   800e9ea4 0000875c S /sbin/ueventd
root      1489  2     0      0     80247e28 00000000 S scsi_eh_0
root      1491  2     0      0     802aef98 00000000 S usb-storage
root      2147  2     0      0     8015a0e4 00000000 S jbd2/mmcblk0p2-
root      2148  2     0      0     8007cacc 00000000 S ext4-dio-unwrit
root      2149  2     0      0     800f9d94 00000000 S flush-179:0
root      2150  2     0      0     8015a0e4 00000000 S jbd2/mmcblk0p5-
root      2151  2     0      0     8007cacc 00000000 S ext4-dio-unwrit
root      2152  2     0      0     8015a0e4 00000000 S jbd2/mmcblk0p6-
root      2153  2     0      0     8007cacc 00000000 S ext4-dio-unwrit
root      2155  1     744    340   8006d5a0 6fd0c3ac S /system/bin/sh
system    2156  1     816    252   80343750 6fd0b6fc S /system/bin/servicemanager
root      2157  1     3872   564   ffffffff 6fd0bdac S /system/bin/vold
root      2158  1     3868   572   ffffffff 6fd0bdac S /system/bin/netd
root      2159  1     820    320   800e9ea4 6fd0b844 S /system/bin/dispd
root      2160  1     676    256   8037b6ac 6fd0c0cc S /system/bin/debuggerd
root      2161  1     83412  27140 800e9ea4 6fd0b844 S zygote
media     2162  1     24300  5232  ffffffff 6fd0b6fc S /system/bin/mediaserver
bluetooth 2163  1     1264   564   800e9ea4 6fd0c59c S /system/bin/dbus-daemon
root      2164  1     824    336   803fd98c 6fd0b45c S /system/bin/installd
keystore  2165  1     1752   424   8037b6ac 6fd0c0cc S /system/bin/keystore
radio     2166  1     4444   672   ffffffff 6fd0bdac S /system/bin/rild
root      2230  2     0      0     80247e28 00000000 S scsi_eh_1
root      2231  2     0      0     802aef98 00000000 S usb-storage
system    2255  2161  130548 30352 ffffffff 6fd0b6fc S system_server
root      2381  2155  904    308   00000000 6fd0b45c R ps

Mmmmm... Pie..... Raspberry Pi to be exact

Back in January and early February there was a lot of interesting news on Raspberry Pi. Like every other technology enthusiast (read "geek") I have been watching the stories and been interested in that little piece of hardware.

"Why" you may ask? Considering that it has video output but no touch screen has lead most of the developer community to focus on why it can't (or shouldn't) support Android. However, it's perfect for creating a droid army to rival that of the Trade Federation <insert evil laugh here>.

Seriously though, I can't think of anything better than a low cost, easily accessible hardware platform to put a Headless Android on.

One problem... it's all sold out. Bother.

Stay tuned for some activity in the near future on porting the Android patches to the Raspberry Pi kernel, minus of course the video subsystem. Let's see what we get, shall we? Headless Raspberry Pi anyone, with Gingerbread crust? Mmmmmm, sounds good to me!

From the Archives - 2008 Article on non-phone Android

I'm sure most of you have seen this article from Stephen Shankland of CENT in 2008 on using Android on non-phone devices. He was spot on about Android showing up in a lot more things than phones.

http://news.cnet.com/8301-17938_105-10047551-1.html

 Now, four years later (ish) I find it interesting that many of the concerns that Stephen had about Android have come to the forefront. Issues around fragmentation and compatibility that he calls out in his article are a big deal for Android developers.

While some may think these issues are mostly UI related, even in non-UI based Android systems there will be some compatibility issues from version to version. It was true in 2008 and it's still true today.

As Headless as an Android gets

Minor changes and now it's Headless. See the updated patch page.

Here is my ps of my currently running system:

# ps
USER     PID   PPID  VSIZE  RSS     WCHAN    PC         NAME
root      1     0     324    188   800d4fa4 0000875c S /init
root      2     0     0      0     8006d344 00000000 S kthreadd
root      3     2     0      0     8005cf24 00000000 S ksoftirqd/0
root      4     2     0      0     8008d2cc 00000000 S watchdog/0
root      5     2     0      0     80069bdc 00000000 S events/0
root      6     2     0      0     80069bdc 00000000 S khelper
root      9     2     0      0     80073e50 00000000 S async/mgr
root      10    2     0      0     80069bdc 00000000 S pm
root      13    2     0      0     80069bdc 00000000 S suspend
root      87    2     0      0     80041cf4 00000000 S usb_wakeup thre
root      227   2     0      0     800a5588 00000000 S sync_supers
root      229   2     0      0     800a5ff0 00000000 S bdi-default
root      231   2     0      0     80069bdc 00000000 S kblockd/0
root      241   2     0      0     80069bdc 00000000 S mxc_spi.0
root      249   2     0      0     80069bdc 00000000 S otg_switch/0
root      255   2     0      0     80268948 00000000 S khubd
root      277   2     0      0     80069bdc 00000000 S kmmcd
root      299   2     0      0     80069bdc 00000000 S rpciod/0
root      317   2     0      0     8008d514 00000000 S khungtaskd
root      318   2     0      0     8009fe28 00000000 S kswapd0
root      366   2     0      0     80069bdc 00000000 S aio/0
root      376   2     0      0     80069bdc 00000000 S nfsiod
root      380   2     0      0     80069bdc 00000000 S crypto/0
root      997   2     0      0     80210978 00000000 S kapmd
root      1068  2     0      0     802913c4 00000000 S file-storage
root      1116  2     0      0     80069bdc 00000000 S kstriped
root      1119  2     0      0     80069bdc 00000000 S kconservative/0
root      1126  2     0      0     80069bdc 00000000 S vpu_wq/0
root      1128  2     0      0     802e9fec 00000000 S hwevent
root      1133  2     0      0     80069bdc 00000000 S esdhc_wq/0
root      1136  2     0      0     80069bdc 00000000 S esdhc_wq/0
root      1143  2     0      0     80069bdc 00000000 S usbhid_resumer
root      1146  2     0      0     80069bdc 00000000 S binder
root      1156  2     0      0     802fe5c4 00000000 S mmcqd
root      1197  1     300    156   800d4fa4 0000875c S /sbin/ueventd
root      1958  2     0      0     80143604 00000000 S jbd2/mmcblk0p2-
root      1959  2     0      0     80069bdc 00000000 S ext4-dio-unwrit
root      1961  2     0      0     80143604 00000000 S jbd2/mmcblk0p5-
root      1962  2     0      0     80069bdc 00000000 S ext4-dio-unwrit
root      1963  2     0      0     80143604 00000000 S jbd2/mmcblk0p6-
root      1964  2     0      0     80069bdc 00000000 S ext4-dio-unwrit
root      1966  1     744    268   8005ac1c 6fd0c3ac S /system/bin/sh
system    1967  1     816    176   80313b44 6fd0b6fc S /system/bin/servicemanager
root      1968  1     3872   380   ffffffff 6fd0bdac S /system/bin/vold
root      1969  1     3868   452   ffffffff 6fd0bdac S /system/bin/netd
root      1970  1     820    204   800d4fa4 6fd0b844 S /system/bin/dispd
root      1971  1     676    148   8034ab44 6fd0c0cc S /system/bin/debuggerd
root      1972  1     83412  26312 800d4fa4 6fd0b844 S zygote
media     1973  1     24288  4492  ffffffff 6fd0b6fc S /system/bin/mediaserver
bluetooth 1974  1     1264   184   800d4fa4 6fd0c59c S /system/bin/dbus-daemon
root      1975  1     824    208   803c9edc 6fd0b45c S /system/bin/installd
keystore  1976  1     1752   284   8034ab44 6fd0c0cc S /system/bin/keystore
radio     1977  1     4444   396   ffffffff 6fd0bdac S /system/bin/rild
system    2032  1972  127452 29024 ffffffff 6fd0b6fc S system_server
root      2170  1966  904    308   00000000 6fd0b45c R ps

Almost There -- Sorta Like "Nearly Headless Nick"

I was able to get a headless Android patch that almost removes all the UI elements from running. The com.android.systemui is still hanging around (and taking up 14MB of memory). It reminds me of the ghost in the Harry Potter books by J.K. Rowling - Nearly Headless Nick whose head is almost chopped off, but not quite.

My next effort will be to see if I can completely remove the com.android.systemui from running.

For those interested, I posted my patch to the patches page.

Android Builders Summit Videos

The Linux Foundation has posted the videos for the Android Builders Summit. You can find them all here:

http://video.linux.com/categories/2012-android-builders-summit

OTA Updateing via Android

One of the hardest problems that embedded Linux companies have to solve is updating devices. Given the changing nature of software, and the desire to include new features on existing products, being able to update devices in the field can be a critical feature. While Linux has some great tools (dpkg with apt, rpms, etc) for updating systems, the standard desktop features do not apply very well to embedded systems.

The Android platform is distributed with some great tools to update devices in the field. These tools range from package updates to full system updates. Generally this is called Over The Air (OTA) updates. There isn't a lot of information available on this topic. One of the clearest presentations I have seen on this topic was at the Android Builders Summit. Andrew Boie from Intel gave the presentation and the video and slides are now available. I highly recommend them.

http://video.linux.com/videos/android-ota-software-updates

One of the problems I noticed as I attended this session though was that it appears the update process has at least some dependency on a user interface. Obviously, with headless Android systems that poses a problem. One of the things that needs to be answered from an OTA perspective is what would need to be modified for an OTA process to complete without a user interface.

Building Your Favorite Glibc App for Android

There are a lot of great applications built on glibc that embedded Linux developers have made the mainstay of building embedded Linux systems. Among these are busybox, wget, cron, thttpd, and many others. The question is, can you get these to run under Android?

The answer is yes! (and no). Technically it would be a LOT of work to port these to use bionic, the c library that Android uses. However, nothing in Android restricts you from adding a standard glibc to your distribution and then using it with the standard programs.

Karihm did a great presentation on this at the Android Builders Summit. He showed an example of building busybox and adding glibc to the system. You can download his slides here: (a video of the presentation will be coming soon.)

https://events.linuxfoundation.org/images/stories/pdf/lf_abs12_yaghmour_heritage.pdf

Another option is to statically compile your binaries with the libraries that they would normally find on a glibc based system. The problem with statically compiling is that it pulls in all the code from the libraries that the code needs directly into the binary. If you have more than one program you are going to do this to, however, you would be better off building against the library. Busybox, which is usually just a few hundred K ends up being 2 MB if it's statically linked.

As the post about Ubuntu on Android shows, this is a great way to have your cake and eat it too.

Ubuntu for Android

An interesting new development effort by Canonical has Ubuntu running in parallel with Android on a multi-core phone. When you dock, you get Ubuntu's desktop on a monitor, while the phone still looks and acts like Android.


http://www.ubuntu.com/devices/android

Very cool stuff! Not really headless related, per se, but having Ubuntu fully run on the Android kernel and have glibc and the Ubuntu UI in all it's glory sitting on a phone definitely proves a point that this convergence of technology is where the future is headed.

Slides from Android Builders Summit

The slides from the Android Builders Summit are now available from the Linux Foundation site. You can find them all here:

https://events.linuxfoundation.org/events/android-builders-summit/slides

I recommend the following for anyone interested in Headless Android type applications.

- Leveraging Linux's History With Android by Karim Yaghmour, Opersys
- Customizing Android by Marko Gargenta, Marakana
- Using Android outside the Mobile Phone Space by Jason Krinder & Khasim Syed Mohammed, TI
- Android Device Porting Walkthrough by Benjamin Zores, Alcatel-Lucent
- Android OTA SW Updates by Andrew Boie, Intel

The folks at the Linux Foundation will be posting the videos from those events soon, so stay tuned for more information.

Androgenizer - A tool for converting autotools makefiles

One of the things that Android developers have wanted to do for a while was to take standard C/C++ applications that are generally used in standard embedded Linux systems and use them in Android. There are a couple of ways this can be accomplished, but for those larger systems converting the Makefiles into something that Android can use natively in a build has been a problem.

Some creative folks came up with a solution. Androigenizer. It takes autotools generated infrastructure and creates Android.mk files.

Here is a good write up on it from Igalia's blog.

http://blogs.igalia.com/eocanha/?p=242

It's a good resource for headless Android systems.

Headless Android Website

I just got the Headless Android website up. Check it out. It's mostly a landing page to get back to this blog, but it will be a nice place to post more static data over time.


http://headlessandroid.com

Why Headless Android?

I have been asked several times, “What is the point of headless Android?” It’s not hard to see why the question is asked. Android, in essence, is a specialized user interface for a phone or tablet platform that runs on the Linux kernel. The Android development team has done a fantastic job to create a platform that application developers can build great apps for phones and tablets. Because they focused on the platform under the applications, just as much as they focused on the applications themselves, the Android team also developed a world class platform framework.

For some, using headless Android comes down to commonality. If you have development efforts where you have two products (for example), one with a UI and one without, then keeping those platforms consistent from a development stand point just makes sense. Being able to write code that you can share between the two platforms is essential for maintenance.

While that use case is an interesting one, it is by no means (in my opinion) the biggest reason developers should care about headless Android. I’ll tell you why.

Five years ago, if you asked just about any embedded developer what they were going to use as the operating system for their embedded hardware (with or without a UI), most of them would say Linux. It was a smart choice. Having control of your destiny (so to speak) can be absolutely critical to the success of a project, especially if you aren’t one of the 800 pound gorillas. For smaller companies building embedded devices, Linux offered the freedom to succeed despite the common road blocks that often beset embedded projects. For example, if I have access to the kernel source, I can debug that lousy DMA controller bug that is preventing my audio from working. It was a wonderful world, if you liked that sort of thing.

Fast forward to today. While embedded Linux is still a fantastic choice for embedded devices, more and more companies are looking for ways to improve over the roll-your-own custom Linux environment that most embedded Linux developers work in. Sure, there are companies that build BSPs that have common utilities and libraries, but that can only get you so far.

Enter Android. For phone developers it is like what embedded Linux was to embedded developers ten years ago. A boon! Finally a widely popular development environment that included an Integrated Development Environment (IDE), a great set of debugging tools, a rich set of off-the-shelf libraries, and a killer user interface. PLUS, you can modify it to your hearts content. Power to the programmers!

As a non-phone developer and embedded Linux fanatic, I have to admit that for phones Android is great, but what about all the millions of devices that aren’t phones, and for that matter aren’t tablets, and may not even have a user interface? With a bit of work, those of us not doing phones can have our cake and eat it too...

There are three reasons I believe headless Android will catch on in popularity as more developers begin to use it.

1. Development Tools - Having an IDE and graphical debugger that “just work” with an easy way to deploy, test, debug, and package your software is a huge time saver.

2. The Platform - Leveraging the built in Android system services architecture can save a huge amount of time and effort. Built in IPC, memory management, service “keep-alive” code, and package management also saves a lot of time and effort. Every embedded devices needs most, if not all of these things, so leveraging a system that is already proven has huge advantages.

3. Knowledge - Since Android is a popular platform, there is a growing community of knowledgeable software engineers that understand the in’s and out’s of the system. Training someone on a roll-your-own solution can take months. Leveraging a known platform can dramatically increase productivity. Along with this the number of books and websites devoted to Android is growing all the time.

There are many other reasons for utilizing the platform offered by the Android system. Why reinvent the wheel? Especially when the wheels work so great and come with tires, axles, and a power train?

Cyborgstack

One of the interesting things I picked up from the Android Builders Summit was a project that Karim Yaghmour of Opersys started to make a completely open Android distribution. The point of the project is to open Android up to the many other markets that may want to use it.

I will be sharing the patches for the headless Android work that I've been doing with the Cyborstack project, so there will be a good repository that everyone can get to. Given that I work in an industry that isn't related to phones or tablets in any way, I'm excited to have a group of people looking at what I'm looking at.

Take a look at it and see what you think.

Cyborgstack

Karim's Post on Headless Android

Karim posted on Headless Android. You can see his post here:

http://www.opersys.com/blog/headless-android-1

Karim Yaghmour's Headless Android Presentation

The highlight of the Android Builders Summit (ABS) for me was Karim's session on Headless Android (that was probably pretty obvious.) He gave a great presentation on actually stripping out all the stuff that depends on the UI, like the WindowManager and SurfaceFlinger.

He showed a running system with his modifications with no UI and it was a beautiful thing. When I saw the code running, I got a tear in my eye and started asking if anyone had a tissue!

With Karim's permission, I'm posting a link to his presentation.

Headless Android Slides from ABS

The folks at the Linux Foundation that hosted ABS will have the presentations and videos up by Monday on their site. I'll post links when they show up.

If you want to download the git repository with the headless android changes that Karim did, then here are the commands:

$ repo init -u git://github.com/cyborgstack/android.git -b headless
$ repo sync
 

I wanted to thank Karim for his work on this front! 

New Patches Page

I am hacking my way through the process to develop a good set of patches to disable non-critical UI based (and telephony based) sub-systems. I created a Patches page where I posted my first patch.

http://headlessandroid.blogspot.com/p/gingerbread-android-patches.html

I've got a lot more to do, but I've got some other work for the next couple of weeks that will take a bit of  my time. Stripping out the dependance on the UI is the next piece of work to tackle. I'm hoping to get some tips at the conference in a couple of weeks that will make that job much easier.

Until then...

Debugging Android over a Network

While the ADB debugging option over a USB port is very convenient, sometimes being able to debug over a network connection can not be beat. This is one place where Android and ADB are amazingly easy, once you know the right commands.

You have to have console access to get this to work. First, from the Android console or adb shell, type in these commands:

setprop service.adb.tcp.port 5555
stop adbd
start adbd

Now use the netcfg command to find the IP address on your device. With that IP address, on your host computer you are debugging on, run the command:

adb connect <ip address of target board>

You should get a message that ADB is connected. You can now debug the device just like it was connected via the USB cable. Pretty slick!

Quick Memory Footprint Savings

Following the TI link I mentioned in a previous post, my first pass at cutting out the "fat" for a Headless Android build resulted in a savings of 151 MB of resident memory. My process list went from (bolded processes removed):

system    2222  1     816    272   80343750 6fd0b6fc S /system/bin/servicemanager
root      2223  1     3872   588   ffffffff 6fd0bdac S /system/bin/vold
root      2224  1     3872   576   ffffffff 6fd0bdac S /system/bin/netd
root      2225  1     820    320   800e9ea4 6fd0b844 S /system/bin/dispd
root      2226  1     676    256   8037b6ac 6fd0c0cc S /system/bin/debuggerd
root      2227  1     83416  27164 800e9ea4 6fd0b844 S zygote
media     2228  1     26844  5836  ffffffff 6fd0b6fc S /system/bin/mediaserver
bluetooth 2229  1     1268   700   800e9ea4 6fd0c59c S /system/bin/dbus-daemon
root      2230  1     824    332   803fd98c 6fd0b45c S /system/bin/installd
keystore  2231  1     1752   424   8037b6ac 6fd0c0cc S /system/bin/keystore
radio     2232  1     5460   700   ffffffff 6fd0bdac S /system/bin/rild
system    2287  2227  189828 37796 ffffffff 6fd0b6fc S system_server
root      2297  2     0      0     8007cacc 00000000 S z1xx_workq
app_17    2443  2227  99264  19128 ffffffff 6fd0c51c S com.android.inputmethod.latin
radio     2449  2227  109920 20808 ffffffff 6fd0c51c S com.android.phone
system    2452  2227  129248 20960 ffffffff 6fd0c51c S com.android.systemui
app_16    2511  2227  97820  22068 ffffffff 6fd0c51c S com.android.launcher
app_1     2531  2227  103736 22144 ffffffff 6fd0c51c S android.process.acore
app_11    2555  2227  105400 17684 ffffffff 6fd0c51c S com.android.mms
app_12    2560  2227  93812  18940 ffffffff 6fd0c51c S android.process.media
app_20    2583  2227  94652  17988 ffffffff 6fd0c51c S com.android.email
app_21    2597  2227  93136  16192 ffffffff 6fd0c51c S com.android.deskclock
app_26    2611  2227  92336  16512 ffffffff 6fd0c51c S com.android.providers.calendar
app_30    2623  2227  92372  16300 ffffffff 6fd0c51c S com.android.bluetooth
app_19    2630  2227  93468  16576 ffffffff 6fd0c51c S com.cooliris.media
app_5     2643  2227  92172  15680 ffffffff 6fd0c51c S com.android.quicksearchbox
app_7     2650  2227  91804  14852 ffffffff 6fd0c51c S com.android.protips
app_10    2672  2227  92340  15000 ffffffff 6fd0c51c S com.android.music

To this:

system    2222  1     816    272   80343750 6fd0b6fc S /system/bin/servicemanager
root      2223  1     3872   588   ffffffff 6fd0bdac S /system/bin/vold
root      2224  1     3872   576   ffffffff 6fd0bdac S /system/bin/netd
root      2225  1     820    320   800e9ea4 6fd0b844 S /system/bin/dispd
root      2226  1     676    256   8037b6ac 6fd0c0cc S /system/bin/debuggerd
root      2227  1     83416  27160 800e9ea4 6fd0b844 S zygote
media     2228  1     24364  5320  ffffffff 6fd0b6fc S /system/bin/mediaserver
bluetooth 2229  1     1264   564   800e9ea4 6fd0c59c S /system/bin/dbus-daemon
root      2230  1     824    336   803fd98c 6fd0b45c S /system/bin/installd
keystore  2231  1     1752   424   8037b6ac 6fd0c0cc S /system/bin/keystore
radio     2232  1     4444   672   ffffffff 6fd0bdac S /system/bin/rild
system    2287  2227  183728 38644 ffffffff 6fd0b6fc S system_server
root      2297  2     0      0     8007cacc 00000000 S z1xx_workq
app_1     2355  2227  93116  17356 ffffffff 6fd0c51c S com.android.inputmethod.pinyin
system    2359  2227  146036 20748 ffffffff 6fd0c51c S com.android.systemui
app_16    2365  2227  96320  21116 ffffffff 6fd0c51c S com.android.launcher
app_12    2442  2227  94692  17864 ffffffff 6fd0c51c S android.process.media
app_5     2453  2227  92172  15676 ffffffff 6fd0c51c S com.android.quicksearchbox
app_7     2461  2227  91804  14848 ffffffff 6fd0c51c S com.android.protips

I know, I know, there are still a lot of processes to cut, like mediaserver, inputmethod.pinyin, launcher, media, quqicksearchbox, etc. However, the point I'm making is that with just minor modifications the system footprint can be reduced dramatically.

Nice.

One note to add, if you modify the files recommended in the TI link, which were:

build/target/product/core.mk
build/target/product/generic.mk
frameworks/base/services/java/com/android/server/SystemServer.java

You have to remember to make clean, then make again or the changes won't get picked up in the final build.