MIKE CLERON: Hi.
My name is Mike Cleron.
I'm an engineer on the Android Development Team.
Android is an open software platform for mobile
development.
It is intended to be a complete stack that includes
everything from the operating system through middleware and
up through applications.
In the next few minutes, I'm going to be introducing you to
an overview of the architecture of the Android
platform, and I'm also going to talk about some of the key
principles that are underlying its design.
If we're going to talk about architecture, we need to start
with a diagram covered with a lot of little
boxes, and this is ours.
We're going to start at the bottom, work up.
Our architecture is based on the Linux 2.6 kernel.
We used the Linux kernel as our
hardware abstraction layer.
So if you are an OEM trying to bring up Android on a new
device, the first thing you'd do is bring up Linux and get
all your drivers in place.
The reason we're using Linux is because it provides a
proven driver model, and in a lot of
cases, existing drivers.
It also provides memory management, process
management, a security model, networking, a lot of core
operating system infrastructures that are
robust and have been proven over time.
The next level up is our native libraries.
Everything that you see here in green is
written in C and C++.
It's at this level where a lot of the core power of the
Android platform comes from.
I'm just going to go through and describe what some of
these components are.
I'm going to start with the Surface Manager.
The Surface Manager is responsible for composing
different drawing surfaces onto the screen.
So it's the Surface Manager that's responsible for taking
different windows that are owned by different
applications that are running in different processes and all
drawing at different times and making sure the pixels end up
on the screen when they're supposed to.
Below that, we have two boxes.
OpenGL ES and SGL, and these two make up the core of our
graphics libraries.
OpenGL ES is a 3D library.
We have a software implementation that is
hardware accelerateable if the device has a 3D chip on it.
The SGL graphics are for 2D graphics, and that is what
most of our application drawing is based on.
One interesting thing about the Android graphics platform
is that you can combine 3D and 2D graphics in the same
application.
Moving over, we have the media framework.
The media framework was provided by PacketVideo, one
of the members of the Open Handset Alliance, and that
contains all of the codecs that make up the core of the
media experience.
So in there, you'll find MPEG-4, H.264, MP3, AAC, all
the audio and video codecs you need to build a rich media
experience.
We use FreeType to render our fonts.
We have an implementation of SQLite.
We use that as the core of most of our data storage.
We have WebKit which is the open source browser engine.
That's what we're using as the core of our browser.
It's the same browser that's powering Safari from Apple.
And we've worked with that engine to make it render well
on small screens and on mobile devices.
Next is the Android Runtime, and the main component in the
Android Runtime is the Dalvik Virtual Machine.
The Android Runtime was designed specifically for
Android to meet the needs of running in an embedded
environment where you have limited battery, limited
memory, limited CPU.
The Dalvik Virtual Machine runs something called DEX
files, dot D-E-X. And these are byte codes that are the
results of converting, at build time,
.class and .jar files.
So these files, when they are converted to .dex, become a
much more efficient byte code that can run very well on
small processors.
They use memory very efficiently, the data
structures are designed to be shared across processes
whenever possible, and it uses a highly CPU optimized byte
code interpreter.
The end result of that is that it's possible to have multiple
instances of the Dalvik Virtual Machine running on the
device at the same time, one in each of several processes.
And we'll see why that's important a
little bit later on.
The next level up from that is the core libraries.
This is in blue, meaning that it's written in the Java
programming language.
And the core library contains all of the collection classes,
utilities, I/O, all the utilities and tools that
you've come to expect to use.
Moving up again, we now have the application framework.
This is all written in the Java programming language, and
the application framework is the tool kit that all
applications use.
These applications include the ones that come with a phone,
like the home application or the phone application.
It includes applications written by Google and it
includes applications that will be written by you.
So all applications use the same framework
and the same APIs.
Again, I'm going to go through and talk about what some of
the main components are in this layer in
the application framework.
The Activity Manager is what manages the life cycle of
applications.
It also maintains a common back stack so that
applications that are running in different processes can
have a smoothly integrated navigation experience.
Next down from that is the Package Manager.
The Package Manager is what keeps track of which
applications are installed on your device.
So if you download new applications over the air or
otherwise install applications, it's the Package
Manager that's responsible for keeping track of what you have
and what the capabilities of each of your applications are.
The Window Manager manages windows.
It's mostly a Java programming language abstraction on top of
lower level services that are provided
by the Surface Manager.
The Telephony Manager contains the APIs that we use to build
the phone application that's central to the phone
experience.
Content Providers are a unique piece of the Android platform.
That's a framework that allows applications to share their
data with other applications.
We use that in our contacts application so that all of the
information in contacts--
phone numbers, addresses, names--
is available to any application that wants to make
use of them.
And other applications can use that facility as
well to share data.
The Resource Manager is what we use to store localized
strings, bitmaps, layout file descriptions, all of the
external parts in an application that aren't code.
I'm just going to touch lightly on the remaining four
boxes, View System, Location Manager, Notification Manager,
and XMPP Service.
The View System contains things like buttons and lists,
all the building blocks of the UI.
It also handles things like event
dispatching, layout, drawing.
Location Manager, Notification Manager, and XMPP Service are
some APIs that I think will allow developers to create
really innovative and exciting applications.
And the final layer on top is applications.
This is where all the applications get written.
It includes the home application, the contacts
application, the browser, your applications.
And everything at this layer is, again, using the same
application framework provided by the layers below.
Now, if you're going to write an application, the first step
is to decompose it into the components that are supported
by the Android platform.
Here are the four major ones.
We have Activity, IntentReceiver, Service, and
ContentProvider.
An Activity is essentially just a piece of UI, typically
corresponding to one screen.
So if you think of something like the mail application,
that would be decomposed into maybe three major activities,
something that lists your mail, something that shows you
what an individual mail message and a compose screen
to put together an outgoing email.
An IntentReceiver is something different.
An IntentReceiver is a way for which your application to
register some code that won't be running until it's
triggered by some external event.
And the set of external events that triggers your code is
open and extensible.
So you can write some code and, through XML, register it
to be woken up and run when something happens, when the
network connectivity is established, or at a certain
time, or when the phone rings, or whatever trigger make sense
for your application.
The next major component is a Service.
A Service is a task that doesn't have any UI, that's
long-lived, that's running in the background.
A good example is a music player.
You may start playing some music from an activity, from a
piece of UI, but once the music is playing, you'd want
it to keep playing even if you're navigating to other
parts of the user experience.
So the code that's actually running through the playlist
playing songs would be a service.
That's running in the background.
You can connect to it later if you want to from an activity
or some other component by binding to the service and
sending it messages like skip to the next song or rewind.
The last component is a ContentProvider, and again,
that's a component that allows you to share some of your data
with other processes and other applications.
Now, any application can store data in whatever way makes
sense for that application.
They can store it in files, they can store it in our
SQLite database, whatever makes sense.
But if they want to make that data available as part of a
platform so that other applications can make use of
it, then the ContentProvider is a solution for that.
And we've used that for the contacts database that comes
with the Android platform so that any application can make
use of the information in contacts.
Android was designed at a fundamental level to encourage
reusing and replacing components.
I have an example here that shows how that works.
On the left, there are four applications that might want
to take a photo for some reason.
So the home application might want to pick it from
wallpaper, contacts might want to pick a person's face to
associate with a contact card.
Gmail or MNS, you might want to have a photo that you send
to someone in an outgoing message.
Now, on Android, for these applications to make use of
the service of taking a photo, they first need to make a
request. So the client component makes a request for
specific action.
In this case, I'm illustrating that with a talk balloon.
And the Gmail application is requesting
that it picks a photo.
So the talk balloon is actually a representation of a
formal class in our system called an Intent.
What the system does when a request is made is it looks at
all of the installed components and it finds the
best available component that knows how to do
whatever was asked for.
In this case, let's say that the system finds the built in
photo gallery.
Now, what happens is the Gmail application is now connected
to the photo gallery.
When the user in Gmail wanted to pick a photo, he will be
taken to the photo gallery.
The photo gallery will fulfill whatever was
asked for in the Intent.
What makes this interesting is that the picking of the
matching component is late-bound/ It's done very
late, and so you can swap software
components at any time.
So let's say you didn't like the built in photo gallery and
you wanted to replace it with one that went online to find a
richer or bigger set of photos, you could replace our
built in photo gallery with one that, say, goes out to
Picassa, or whatever your favorite online photo site is.
Once you've done that, then any of the applications on the
left will now use the new and better component on the right
to fulfill the task of picking a photo.
And at any time, a new application can come along and
make use of existing functionality.
So if you're writing a blogger application, you don't have to
worry about writing a photo picker yourself.
You can just rely on whichever one the user has configured to
be their preferred photo picking application.
This becomes really important because in Android, it's not
just about picking photos.
Virtually any task has an intent in the middle.
If the user is going from point A to point B, there's an
intent in the middle, and each of those intents is an
opportunity to reuse a component or
to replace a component.
So we have intents for going home, which means you can
replace a home application.
Or we have an intent for sending an email, which means
you can replace the mail application.
All of these are opportunities for replacing and reusing
components.
If you're interested in finding out more about
Android, I encourage you to visit the developer site and
download the SDK.
In the SDK, you'll find a lot more documentation and sample
code, and you'll also be able to try building applications
of your own.
There's also a developer group that you can join to find out
more information.
And I also encourage you to check back frequently because
we'll be posting updates to the SDK as
the platform matures.
Thank you for watching.