What Android Is

Being an illustrated run through the basics.

What happened was, for our recent South American tour I wanted an Android architecture overview graphic. I ran across, among the Android SDK documentation, a page entitled What is Android?, and it’s perfectly OK. Except for, I really disliked the picture — on purely aesthetic grounds, just not my kind of lettering and gradients and layouts — so I decided to make another one.

I thought I’d run it here and, since I’ve been spending a lot of time recently explaining What Android Is to people, I thought I’d provide my version of that as well, in narrative rather than point form.

First of all, as Dan Morrill memorably explained in On Android Compatibility, “Android is not a specification, or a distribution in the traditional Linux sense. It’s not a collection of replaceable components. Android is a chunk of software that you port to a device.”


Linux · Underneath everything is a reasonably up-to-date Linux kernel (2.6.32 in my current Nexus One running Froyo), with some power-saving extensions we cooked up; the process of trying to merge this stuff into upstream Linux has been extended and public and is by no means over. ¶

Android runs on Linux, but I’d be nervous about calling it a distro because it leaves out so much that people expect in one of those: libraries and shells and editors and GUIs and programming frameworks. It’s a pretty naked kernel, which becomes obvious the first time you find yourself using a shell on an Android device.

If it were a distro it’d be one of the higher-volume ones, shipping at 200K units a day in late 2010. But nobody counts these things, and then there are a ton of embedded flavors of Linux shipping in unremarkable pieces of consumer electronics, so there’s a refreshing absence of anyone claiming to be “the most popular Linux”. I like that.

Dalvik · The next big piece is Dalvik, comprising the VM and a whole bunch of basic runtime essentials. Its design is fairly unique, and judging by recent history, seems to be working out pretty well as a mobile-device app substrate. ¶

All the standard APIs that you use to create Android apps are defined in terms of Dalvik classes and interfaces and objects and methods. In fact, some of them are thin layers of Dalvik code over native implementations.

It’s possible, and common practice, to call back and forth between Dalvik and native code using the JNI protocol, which is a neat trick since what’s running on Dalvik isn’t anything like Java bytecodes on a Java VM.

How It’s Generated · Native code is currently produced more or less exclusively by compiling C or C++ code; but there’s no reason it has to be that way. Dalvik code is currently produced by generating Java bytecodes and translating them; but there’s no reason it has to be that way. ¶

I want to emphasize this point a little. Android apps are defined as code that runs on the platform and uses the APIs. As long as an app does these things properly, it’s really nobody’s concern how it got generated.

Special Apps · The picture is a little misleading, because some of those Dalvik-based apps are provided by Google and sometimes are seen as “part of Android”. I’m talking about the Dialer and Contacts and Calendar and Gmail and Chat and so on. Most of them are open-source and replaceable (and have been replaced by handset makers); a few are closed-source and proprietary, like Google Maps and Android Market. ¶

That Open-Source Thing · In the big picture above, most of the stuff in green is Apache-licensed. The rest is a mixture of GPL and LGPL and BSD, with some Apache in there too. This excludes some low-level device drivers and of course the majority of non-Google apps, which are closed-source. ¶


The Framework · This is the stuff that uniquely defines Android; more or less everything that Google wrote and you wouldn’t expect to find on a reasonably-configured GNU/Linux box. Its proper use is the subject of all the many pages on display at developer.android.com and of endless mailing lists, sample sites, and a growing number of books. ¶

I like it; but you already knew that.


Libraries · The word “standard” here means “generally available to programmers working in an open-source environment”. The picture isn’t comprehensive. ¶

Quite a few people, including me, have over-emphasized the role of the Harmony libraries. To start with, the Android selection excludes lots of stuff, for example AWT and Swing and OMG CORBA; all superfluous for apps using the Android framework.

Also, just counting roughly by code bulk of all the sort of stuff in this picture, the Harmony code comprises less than half the total. I don’t want to diss Harmony, they’re a wonderful project and I’m a huge fan; but it’s inaccurate to give the impression that Android is just Dalvik plus Harmony.


· · ·

What’s In an App? · An Android app lives in what’s called an APK, which is simply a ZIP file, with a particular internal file layout that allows it to be run in place, without unpacking. There’s nothing magic about them, you can email them around and drop them on USB keys and extract pieces with unzip. ¶

The Android Manifest is the interface between an app and the Android system, and that’s all I’m going to say here because it’s a key piece of the puzzle and deserves lengthy discussion if any at all.

The resource bundle contains your audio and video and graphics and so on, the pieces that come with the app as opposed to being fetched over the network.

Native or Not · Most apps these days are written for Dalvik. When I say “most apps” I mean “everything that isn’t a game”; game developers typically want to code in C/C++ and that’s it. Dalvik offers a nice fast gateway to OpenGL and all the phone’s hardware, but game devs just don’t want to hear about virtual machines, so they use the Android NDK. ¶

If you’re writing code in the Java programming language you can use Eclipse and a pretty nice toolchain that makes the barrier to entry remarkably low. If you’re coding to the NDK, you’re going to be doing a lot of the build-time machinery yourself and living without some of the nice debugging and profiling candy, not to mention signing up to port your code to other CPU architectures if they run Android and have lots of users. But game developers revel in pain.

And that’s what Android is · Hope you liked the pictures. ¶

My thanks to Dan Bornstein and Dan Morrill for sanity-checking this and offering several significant improvements.
[Updated:] A couple of fact-checks contributed by Brian Swetland.

Please feel free to contribute a comment on this fragment.

Updated: 2010/11/24
Serif / Sans-Serif