Androide the "gPhone" software stack
There was a lot buzz around when
Google launched
Android, there mobile platform. A lot of newspapers write a lot of articles about it, but technical insides are really rare. Even on the official
android-page it's hard to find a good written architectural overview. Probably the best start to understand how
Android works is probably
this video from google. If you don't can or want to watch a video there's also, as I think a bit a short,
explanation on the google code site.
The architecture view
Let me give you a short overview.
Android is basically a layered architecture for mobile phones. At the bottom there's a Linux kernel 2.6 that basically handle the drivers to access the hardware. That's really nothing new there; there are already some phones out there that use Linux as a foundation. The most famous one of the Linux mobile Phones are probably the
Nokia Internet Tablet or the
OpenMoko.
On the next layer there are c-written libraries that bring some basic stuff to the phone. Although this layer is mainly internet-computer and not phone related (Google PC anyone ;-)). There are libraries to display stuff ("Surface Manger", "Open GL|ES", "SGL", "FreeType"),
WebKit to display web pages (the same engine that is used in the iPhone and KDE), a SSL library for secure communication,
SQLite to simple store stuff and
libc as basic c layer.
Then there's the Android runtime, that’s the layer where a programmer can start building there own application on the top. It consists out of a virtual machine that can execute byte code that’s build out of the "Java Programming Language" and a core API that have a very big similar to sun's java package (in fact Google is using part of
Apache Harmony, a open source implementation of the Java class library). Let this be enough for now, we go back to this part later on.
On the application framework is the stuff that makes programming a phone easy with android. There are classes to access resources and creating windows. Some stuff here is still in development, there is no MMS or HSPA support yet.
On the top there are the applications of a phone, they are all written in Java and use exactly the same system, no matter if they are written by Google, the phone company, the network carrier or you.
Java or not to Java
Google always talks and writes about "Java Programming Language" and not Java, why comes that? Well what's running on Dalvik, the virtual machine of android, is not really Java bytcode. You program as every Javaprogram just as usual in Java and compile them to bytecode. After that you need to transform your bytecode with the "dx" tool to a .dex file. What you get is now Dalvik bytecode.
Ok!? Why the hell so complicated? Well there may be a few reasons for that. As you still use Java until just before delivering you App, you can easily use your usual tool chain. Eclipse, JUnit, Cruisecontrol or more exotic stuff - it's all no problem! But why they don't just use Java then, you may ask. Well, for mobile phones you still have not the resources like on a pc. So Dalvik-Bytecode is well optimized for the CPU and hardware you will typically find in a mobile phone. And there's another fact which is no secret: Google don't like to pay license few to Sun. So that's the reason why Google is using the "Java Programming Language" and not "Java". It might be a not too big difference for technical guys, but for the lawyers it definitely is.
Smart decision
After all Android, and therefore also Dalvik looks like a smart idea to me. As Sun tried to run Java with J2ME on every device, Android will never run on today’s low coast phones. You just need some basic CPU power to run it. As J2ME is not really a strong framework, you have a single programming language, but it's up to the vendor which functionality he likes to integrate, every single phone is different. That makes porting J2ME to a real pain. As it looks now, the open handset alliance is putting on some standards on library and functionality that needs to be implemented by every vendor. This will make developing an application for every Android phone easy. As the vendor needs to use the same libraries and framework to develop his own applications it's pretty much
"eat your own dogfood" and this will give a little security that Android will be useful.
Android will hopefully be a strong platform until we have enough CPU power on the mobiles to just run some standard operating systems on them. And yes, Dalvik is the better J2ME for me, less compromise and more technical possibilities to the programmer.
