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.
