What Android Is

Being an il­lus­trated run through the ba­sics.

What hap­pened was, for our re­cent South Amer­i­can tour I wanted an An­droid ar­chi­tec­ture overview graphic. I ran across, among the An­droid SDK doc­u­men­ta­tion, a page en­ti­tled What is An­droid?, and it’s per­fectly OK. Ex­cept for, I re­ally dis­liked the pic­ture — on purely aes­thetic grounds, just not my kind of let­ter­ing and gra­di­ents and lay­outs — so I de­cided to make an­other one.

I thought I’d run it here and, since I’ve been spend­ing a lot of time re­cently ex­plain­ing What An­droid Is to peo­ple, I thought I’d pro­vide my
ver­sion of that as well, in nar­ra­tive rather than point form.

---

First of all, as Dan Mor­rill mem­o­rably ex­plained in On An­droid Com­pat­i­bil­ity, “An­droid is not a spec­i­fi­ca­tion, or a dis­tri­b­u­tion in the tra­di­tional Linux sense. It’s not a col­lec­tion of re­place­able com­po­nents. An­droid is a chunk of soft­ware that you port to a de­vice.”

Linux · Un­der­neath every­thing is a rea­son­ably up-to-date Linux ker­nel (2.6.32 in my cur­rent Nexus One run­ning Froyo), with some power-sav­ing ex­ten­sions we cooked up; the process of try­ing to merge this stuff into up­stream Linux has been ex­tended and pub­lic and is by no means over.

An­droid runs on Linux, but I’d be ner­vous about call­ing it a dis­tro be­cause it leaves out so much that peo­ple ex­pect in one of those: li­braries
and shells and ed­i­tors and GUIs and pro­gram­ming frame­works. It’s a pretty naked ker­nel, which be­comes ob­vi­ous the first time you find
your­self using a shell on an An­droid de­vice.

If it were a dis­tro it’d be one of the higher-vol­ume ones, ship­ping at 200K units a day in late 2010. But no­body counts these things, and then there are a ton of em­bed­ded fla­vors of Linux ship­ping in un­re­mark­able pieces of con­sumer elec­tron­ics, so there’s a re­fresh­ing ab­sence of any­one claim­ing to be “the most pop­u­lar Linux”. I like that.

Dalvik · The next big piece is Dalvik, com­pris­ing the VM and a whole bunch of basic run­time es­sen­tials. Its de­sign is fairly unique, and judg­ing by re­cent his­tory, seems to be work­ing out pretty well as a mo­bile-de­vice app sub­strate.

All the stan­dard APIs that you use to cre­ate An­droid apps are de­fined in terms of Dalvik classes and in­ter­faces and ob­jects and meth­ods. In fact, some of them are thin lay­ers of Dalvik code over na­tive im­ple­men­ta­tions.

It’s pos­si­ble, and com­mon prac­tice, to call back and forth be­tween Dalvik and na­tive code using the JNI pro­to­col, which is a neat trick since what’s run­ning on Dalvik isn’t any­thing like Java byte­codes on a Java VM.

How It’s Gen­er­ated · Na­tive code is cur­rently pro­duced more or less ex­clu­sively by com­pil­ing C  or C++ code; but there’s no rea­son it has to be that way. Dalvik code is cur­rently pro­duced by gen­er­at­ing Java byte­codes and trans­lat­ing them; but there’s no rea­son it has to be that way.

I want to em­pha­size this point a lit­tle. An­droid apps are de­fined as code that runs on the plat­form and uses the APIs. As long as an app does these things prop­erly, it’s re­ally no­body’s con­cern how it got gen­er­ated.

Spe­cial Apps · The pic­ture is a lit­tle mis­lead­ing, be­cause some of those Dalvik-based apps are pro­vided by Google and some­times are seen as “part of An­droid”. I’m talk­ing about the Di­aler and Con­tacts and Cal­en­dar and Gmail and Chat and so on. Most of them are open-source and re­place­able (and have been re­placed by hand­set mak­ers); a few are closed-source and pro­pri­etary, like Google Maps and An­droid Mar­ket.

That Open-Source Thing · In the big pic­ture above, most of the stuff in green is Apache-li­censed.
The rest is a mix­ture of GPL and LGPL and BSD, with some Apache in there too. This ex­cludes some low-level de­vice dri­vers and of course the ma­jor­ity of non-Google apps, which are closed-source.

The Frame­work · This is the stuff that uniquely de­fines An­droid; more or less every­thing that Google wrote and you wouldn’t ex­pect to find on a rea­son­ably-con­fig­ured GNU/Linux box. Its proper use is the sub­ject of all the many pages on dis­play at developer.​android.​com and of
end­less mail­ing lists, sam­ple sites, and a grow­ing num­ber of books.

I like it; but you al­ready knew that.

Li­braries · The word “stan­dard” here means “gen­er­ally avail­able to pro­gram­mers work­ing in an open-source en­vi­ron­ment”. The pic­ture isn’t com­pre­hen­sive.

Quite a few peo­ple, in­clud­ing me, have over-em­pha­sized the role of the Har­mony li­braries. To start with, the An­droid se­lec­tion ex­cludes lots of stuff, for ex­am­ple
AWT and
Swing and
OMG
CORBA;

all su­per­flu­ous for apps using the An­droid frame­work.

Also, just count­ing roughly by code bulk of all the sort of stuff in this pic­ture, the Har­mony code com­prises less than half the total. I don’t want to diss Har­mony, they’re a won­der­ful pro­ject and I’m a huge fan; but it’s in­ac­cu­rate to give the im­pres­sion that An­droid is just Dalvik plus Har­mony.

What’s In an App? · An An­droid app lives in what’s called an APK, which is sim­ply a ZIP file, with a par­tic­u­lar in­ter­nal file lay­out that al­lows it to be run in place, with­out un­pack­ing.
There’s noth­ing magic about them, you can email them around and drop them on USB keys and ex­tract pieces with unzip.

The An­droid Man­i­fest is the in­ter­face be­tween an app and the An­droid sys­tem, and that’s all I’m going to say here be­cause it’s a key piece of the puz­zle and de­serves lengthy dis­cus­sion if any at all.

The re­source bun­dle con­tains your audio and video and graph­ics and so on, the pieces that come with the app as op­posed to being fetched over the net­work.

Na­tive or Not · Most apps these days are writ­ten for Dalvik. When I say “most apps” I mean “every­thing that isn’t a game”; game de­vel­op­ers typ­i­cally want to code in C/C++ and that’s it. Dalvik of­fers a nice fast gate­way to OpenGL and all the phone’s hard­ware, but game devs just don’t want to hear about vir­tual ma­chines, so they use the An­droid NDK.

If you’re writ­ing code in the Java pro­gram­ming lan­guage you can use Eclipse and a pretty nice tool­chain that makes the bar­rier to entry re­mark­ably low. If you’re cod­ing to the NDK, you’re going to be doing a lot of the build-time ma­chin­ery your­self and liv­ing with­out some of the nice de­bug­ging and pro­fil­ing candy, not to men­tion sign­ing up to port your code to other CPU ar­chi­tec­tures if they run An­droid and have lots of users. But game de­vel­op­ers revel in pain.

And that’s what An­droid is · Hope you liked the pic­tures.

---

My thanks to
Dan Born­stein and
Dan Mor­rill for
san­ity-check­ing this and of­fer­ing sev­eral sig­nif­i­cant im­prove­ments.

[Up­dated:] A cou­ple of fact-checks con­tributed by Brian Swet­land.

---