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.

Now I'm going to focus in detail on a few of the APIs

that I think provide fertile ground for innovation.

The first is the location manager.

This is a set of APIs that allows you to get geographic

information.

It will let you find out your current location, and it will

also let you register to receive notifications if you

get close to something interesting.

So you can actually register an intent with the location

manager that will be fired when you get close to a point

that you specify.

And that lets you do things like be notified when you get

close to one of your friends.

Or it lets you be notified when you get close to, say, an

ice cream shop that has particularly good

ice cream in it.

That's kind of interesting innovative application that

this kind of API enables.

The location manager will use GPS if the device comes

equipped with GPS.

If it doesn't, it will make due with whatever information

is available.

That might be getting information from cell tower

IDs, or if there's a WiFi network that has geographic

location information in it, will use that information to

try to at least narrow down where you are.

While building applications for the Android platform, we

found that it was useful to have them always on data

connection so that the server could send notifications to

devices running the Android platform.

It turned out this is such a useful piece of

infrastructure, that we decided to package it up and

make it available as part of the public framework.

And that has been done by creating the

XMPP service APIs.

The XMPP service allows any application to send device to

device data messages to any user who's running Android on

their device.

Now that data can be whatever information makes sense for

the application.

So for a multiplayer game, that might be that I've moved

my knight to a particular location, or whatever makes

sense for the game.

But it could also be something else like geographic

information.

So with appropriate permissions and security, the

user could send their location to their buddies so that their

buddies can actually see where they are at any given time and

plot that information on a map.

Again this works with any Gmail account, so any

application can send this type of peer to peer messages

without having to build any server infrastructure.

The next API is one of my favorites.

It's called the Notification Manager, and it allows any

application to put a notification

into the status bar.

We use the status bar for things like SMS notifications,

voice mail notifications, all of the typical things you'd

expect to see on the phone.

However, we make that same facility available to any

application.

So that means that developers can have the same power to

alert the user to interesting events as what have

traditionally been built in applications.

This has a lot of benefits.

First, it means that all notifications have a

consistent presentation.

The way we do it in the UI, we have a visible preview of what

the notification means.

So, if an icon appears in the status bar, you can click on

it or touch it to make it active.

So you can see a preview of what it means which means you

don't have to figure out what each of 30 different

hieroglyphics means.

Then, if you want to act on that notification, you can

simply touch on it, and you'll be taken to whatever

application is responsible for that notification.

This allows a lot of really interesting scenarios.

It means that applications can notify you of things like,

when an auction is ending, or if someone has invited you to

be their friend on a social network, or if a bus is

coming, and all of those notifications can have the

same level of prominence in the UI as something like

voicemail or the other built in notifications.

And, finally, I'd like to take a minute to talk about the

View System in Android.

Android provides a really rich tool kit of built in views.

You can use those to assemble your applications out of

standard parts.

So we provide things like a list view, a grid view, a

gallery view.

We provide all the standard widgets like

buttons and check boxes.

By combining those things, you can build your applications

really quickly.

We've also done a lot of work in the framework to support

multiple input methods, and multiple screen sizes, and

multiple keyboard configurations in the new

system itself so that you don't have to worry about that

in your application.

So, for example, our list views work with touch, but

they also work if you want to drive them

with a five way ePad.

And that's just a built in

facility of the view framework.

In addition to that sort of views, we also are introducing

two really innovative views.

The first is a map view.

This is and implementation of the same map rendering engine

that's in our maps application.

But we decided to make that available as a view so that

applications can have really tight integration with

geographic data.

So it's, of course, possible to always launch the map

application to display a particular location, but what

the maps you let you do is actually embed a map view in

your application so you can control it from your own code.

So you can set it to a particular location, zoom in,

zoom out, pan the map, control all of that from your own code

to build whatever kind of application you want to build

based on that.

We've done something similar with the browser.

There's a browser application that you can launch to display

a web page, but we also have a web view that enables you to

embed HTML content as a view in your application that you

can then fill with whatever data makes sense for your app.

Personally, what I'm hoping to see come out of the Android

effort is the kind of innovation that comes from,

what I call, the massive effect.

We really had two goals in mind when we set

out to create Android.

The first was to provide developers with a powerful

tool kit for building new types of experiences.

This tool kit includes things like the application

framework, the view system, things like the maps in view,

the web view, that you can get embed in your application.

Device to device messaging through XMPP, location

services notifications, and all the other

pieces of our API.

But the second, and more important, goal was to be

sufficiently open and extensible to allow these

pieces to be combined in ways that we really haven't

imagined yet.

If you're interested in finding out more about

Android, I encourage you to visit the developer site and

download 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.

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.