Google I/O 2012 - Up Close and Personal: NFC and Android Beam

ROBERT: So welcome to "Up Close and Personal," with NFC
and Android Beam.
This is Martin, and I'm Robert.
We both work on the NFC and Beam team on Android.
And we're going to tell you about NFC and Beam.
Everyone is in the right session, yeah?
This is a good time to leave if you don't want to get
really excited about NFC.
Cool.
Martin, take it away.
MARTIN: Let's get started.
All right, so a show of hands, how many of you guys actually
know what NFC is?

Wow, that's almost all of you.
Just for the few of you who don't, we're actually going to
go through a few slides to explain what exactly the
technology is, and what it does, what's
so great about it.

So NFC stands for Near Field Communication.
And basically, it's a wireless technology very much like
Bluetooth or Wi-Fi.
However, there are a few key differences to NFC from these
technologies.
So one of the main differences is that NFC
is very short range.
So it just works over a distance of a few centimeters
instead of the meters that you're used to
from Wi-Fi or Bluetooth.
We actually think short range is a great feature of NFC, and
we'll show you more in a moment.
Another difference between NFC and the other wireless
technologies is that it has a fairly low data rate.
So the typical data rates for NFC are a few hundred kilobits
per second, not more.
So you don't want to be sending too much data
over NFC at a time.
A few kilobytes is a good maximum.
And a final thing about NFC that's different from the
other wireless technologies is that it's
really no setup at all.
So over the Bluetooth, when you want to do something, you
always have to enter a PIN, you have to do pairing.
It's really annoying to get stuff set up.
The great thing with NFC is that when you bring devices
into range, immediately, they set up a connection, and they
can start talking to each other.
So you don't need to do any pairing, no PIN setup, it just
immediately works.
So when you have NFC on your device, what can you actually
do with it?
So I think there's two main use cases of NFC.
And the first one you see on the left, which is what we
call passive tags.
Passive tags are small form factor devices.
They come in lots of form factors, but they are
typically the size of a credit card, sometimes a bit smaller.
And they're often stickers, so you can put them onto stuff.
And their main function is really to store a
small amount of data.
Most tags can store a few kilobytes of data.
So what you can typically put into a tag is a simple set of
data like a URL to a website, a link to a YouTube video, a
vCard for a contact that you know about.
Now what makes these tags really special is that they
don't require any power.
And that is where the passive comes from, in the name.
So you don't need to put any battery in these.
Whenever you put an NFC-powered device on top of
this tag, the NFC field in your phone will power the tag,
power it on, and allow it to read the data from the tag.
The other thing about tags is that you can often reprogram
them as well, so they'll write many times.
So you can write it once, and if you decide you want store
something else on it, you can just overwrite it and put
whatever you want on it.
And the second thing about them is that
they're also lockable.
So in case you do really want to finalize the data that you
have on the tag, you can lock them to make sure that nobody
can overwrite your tags, which is great for
a lot of use cases.
Now the second way to interact you see on the right.
So you typically have, like, two powered NFC devices.
So an example is if you have two phones, or a phone and a
tablet, that both have NFC, when you bring these two
devices together, they can immediately start
communicating to each other.
Now the main difference between this and tags is that
with tags, you typically store a set of data on it, and it's
a static amount of data.
Whereas when you put two active devices together, you
can change the data dynamically from the
application that you want.
And that's one of the main use cases of Android Beam that
we'll show you later.
Another use case that you probably all have seen here at
the conference is Google Wallet, where you put your
phone up to a payment reader, and you can do payment.

So I do really want to go into the 5 centimeters thing
because that's something that I really hear a lot.
People think this is a limitation of NFC.
I think this is the greatest feature of NFC and what makes
it really great.
So imagine you're in a room full of smart devices.
Like you have a room with a Nexus Q and a Nexus 7.
And you maybe have a Smart TV in there, even a bottle of
wine which has an NFC tag on it.
How do you determine which device you're going to
interact with?
Well, the easy answer is just by touching it.
So if you want to interact with the Nexus Q, tap your
Nexus Q. If you want to interact or get data from the
bottle of wine, tap the bottle of wine.
And it may show you the manufacturing info about it.
So this allows you to be really specific about the way
you interact with stuff.
So this is one of the main use cases, you know, touching
physical objects for digital interaction.
And the other use case comes from actually having two
active devices.
So if you have two phones, you can have a virtual object on
one of these phones.
A virtual object can be like a URL or a business card.
You can just beam it across.
And you can be really selective about
where you send it to.
And this is really great about short range-- it allows you to
be selective about how you interact
with different devices.
I'll hand it over to Robert to talk a bit more about
different NFC use cases.
ROBERT: Thanks.
So what can you do with NFC?
Well, we've got a list here on the slide which I won't read
because you can all see it.
But these are really just the usual suspects.
Whenever you read a report about the future of NFC, all
of these use cases come up.
But there's going to be lots of new things.
Martin introduced the idea of peer to peer, two active NFC
devices communicating with each other.
And as many new phones come equipped with that capability,
we're going to see lots and lots of new NFC use cases.
Also, applications which use NFC to share are going to
drive this, and it's all going to get much more interesting.
We really think of NFC as being very, very simple.
It is a very simple technology.
It doesn't actually do a whole lot.
When you think about it, HTTP doesn't do a whole lot,
either, but HTTP enabled the web and all of the amazing
things you can do with the web.
So don't be fooled by the simplicity of NFC.
We think that's actually where its raw power comes from.
We want to keep it simple.
It's a very basic technology, but when you start to use it,
then you can start to harness the power, and you can really
get imaginative.
And we really do think the limits of NFC are just the
limits of your imagination.
The other question people often have is, well, when is
NFC going to happen?
We think it's already here.
Don't wait too long, you really should get started.
And it's great to see so many of you here today interested
in NFC and wanting to learn more.
If you were in the keynote yesterday, does anybody
remember what the number was for the number of Android
devices activated with NFC every week?
No, no one remembers, thank you.
OK, a million, thank you.
Yes, it is a million new Android devices, every week,
activated with NFC that have all of these capabilities.
And it's moving into low- and mid-end, low-range and
mid-range devices.
It isn't just the high-end phones that have NFC now.
So let's take a closer look because this is going to come,
now, not just in phones and other devices but in
accessories.
And we're going to show you that later on.
Lots and lots of smart objects, maybe not quite the
bottle of wine that Martin mentioned earlier.
But let's take a closer look at what you can do on Android.
Android provides a framework for NFC so that you can create
whatever your application and your users need.
And as it says on the slide, we support all the common
passive tag types, we have APIs, and you can even launch
an application using NFC, more of which in a little while.
But we think tags are just the start.
NFC, as it becomes more widespread, is going to bring
magic to this platform.
Let's take a look at Android Beam.
Android Beam enables magic sharing.
It makes it really, really easy for you to give your
users a magical experience.
It's deliberately very, very simple, with almost no UI.
There's nothing to it.
And again, we'll show you more about that.
All you have to do is bring the two devices together with
their screens unlocked.
That's important, we want users to stay in control here.
This is a personal device, the screen has to be unlocked, the
phone has to be on for NFC and for Android Beam to work.
Whoever wants to share just taps on the screen to confirm
that they're happy for the information to be sent.
And the context from their application, normally what's
shown on the screen, gets beamed across
to the other device.
It really is that simple.
There are no menus, there are no dialogue boxes.
There's nothing to get in the way.
And that's why we have that "Touch to Beam," just to make
it very, very easy.
So let's take a look at some of this in
action with some demos.
So we'll switch over so we can see our devices here.
So as we've said, it's really, really easy to share content.
On my phone here, I've got an interesting article, which I
probably should share with you because it contains some
fascinating news.
This is from People magazine, one of my favorite websites.
And, as the Wi-Fi loads, you'll see it's an article,
there we go, about Prince William and
his $16 million fortune.
Not sure about his dress sense, but
we'll leave that aside.
No wonder Kate's laughing in the background.
But if I wanted to read this on my tablet, got a Nexus 7
here, it's very easy.
All I would do, put the phone down, Touch to Beam, and, in
just a second or two, it's already open on the tablet.
And once again, as you know, the Wi-Fi's a little bit slow
here, but it's going to bring in the article in People
magazine very, very quickly.
I can do exactly the same-- come on.
You can see the URL's gone across.
It works.
We're now waiting for Wi-Fi, but that's Beam.
It is very, very simple.
This doesn't bode well for the YouTube demo, if we cannot get
a web page to load.
But let's give it a shot anyway.
So I've got YouTube running on this phone, and I was going to
show video from the Android keynotes last year.
But let's keep on rolling.
What YouTube does is it actually starts the video
playing at exactly the same spot on the receiving device.
So if you're halfway through a movie or halfway through
something, it'll take you there.
It's very easy for you to skip back to the start if that's
what you wanted, rather than fiddling around to try to find
the playhead.
So again, we're transferring the context of the app from
one device to the other.
So his demo that doesn't rely on Wi-FI
because we're not stupid--
it is the Moscone Center, and Wi-Fi's always tough here.
So I've got a great app on my Android device called Paper
Camera, which lets me take nice, creative photos.
So I'm going to grab a picture of you guys looking awesome.
Here we go.
And I'm going to change-- we're going to make it look
like you're drawn in aqua pastels.
So that's how I roll.
So I've got my aqua pastel photo.
Martin, oh, you haven't got Paper Camera.
MARTIN: No, it looks pretty cool, though.
ROBERT: It is pretty cool.
Let's see what happens when I beam an app from this device
to a device that doesn't have the app installed.
So I just Tap to Beam, and when Martin flips over, you
see it's gone to the Play store.
[APPLAUSE]
ROBERT: Thank you, so Beam is a distribution
mechanism for your apps.
And that's automatic.
You don't have to write any code.
Every Android app will do that when two Beam-compatible
phones come together.
So what's happening now-- once again, relying
on the Wi-Fi which--
so we'll move on.
A bit like a cookery show, we've got one in the oven we
made earlier.
And so we've now got Paper Camera
installed on another device.
MARTIN: Yep, let's try this one.
ROBERT: And I'm going to snap another photo, but aqua-tint
didn't really work for me.
So I'm going to switch to my favorite, which is Andy Pop.
Now, Paper Camera's a great app, and
it's got lots of settings.
So I can grab this photo, which I've now
played around with.
Let's see what happens when I beam-- so Martin, let's get
your Paper Camera.
Let's just have a look.
Your, so--
MARTIN: I haven't launched it yet, but it'll launch
automatically.
ROBERT: You haven't launched it yet.
OK, so there's my settings.
I've got Andy Pop running.
So I'm going to beam that across.
Put my phone the right way up, sorry.

And what's going to happen now, because the app is
installed, you see Paper Camera has opened in Andy Pop.
So the exact context from this device, the setting-- so if
Martin thinks, "Wow, how do you get that cool effect,"
we've passed the information across, so it makes it really,
really easy.
A lot of games developers are using that to
start two-player games.
So if I'm at the start of a game on my device and want to
play head-to-head against someone else-- just tap the
phones, start a head-to-head connection.
So pretty cool uses of Android Beam for peer-to-peer sharing.
Martin's going to show us, now, some tag behaviors.
MARTIN: Yeah, some really cool stuff you can do with tags is
you can just stick them in all kinds of weird
places that you like.
A really cool use case, if you want to show off something
like, for example, you're holding a representation at a
cool conference like Google I/O. You want to tell
people about it.
So what you can do is you can hang posters all around the
buildings for your presentation, for example, a
poster that looks like this one for our presentation.
And you can put all kinds of data in there.
So in this case, I put a data in there that links along to
the Google I/O application.
So that whenever somebody taps this tag, it will actually
take you to the Google I/O application and immediately
show you the session that we're having right here.
It shows you more information.
You can interact with it, add it to your agenda.
ROBERT: And again, what would have happened there if you
didn't have the app installed?
MARTIN: So if I didn't have the app installed, it would've
taken me to Market first, to install the application.
ROBERT: Cool.
MARTIN: Awesome.
So I'm sure you all saw the really cool keynote yesterday
where they showed off the new Google+ events use case.
I think it was really cool, and it showed different kinds
of events and what you can do with Android Beam.
So let's say we're having a beach barbecue that we're
organizing.
If you go to Google+ events, you probably know the people
you want to invite.
Well, let's say you want to have a surprise party.
For example, I'm not sure if you guys saw the movie Project
X, but it was like--
it really got out of hand because a lot of people showed
up that weren't supposed to show up.
Let's say you put a poster here for a beach barbecue,
somewhere in your dorm room or in a building somewhere.
People can actually tag this poster with their phone.
And wha it does is it just brings you to Google Maps to
show you the actual location of where the
party is going to happen.
Now if the Wi-Fi was actually-- oh,
it's pretty good now.
It's showing it's at Sunside Beach, so this is where you're
going to have the party.
You chose a pretty good location.
ROBERT: Yeah, so we've got the exact location, so we can make
sure the skydivers arrive on time.
[LAUGHTER]
ROBERT: The bar has been raised.
It's not a party without skydivers, guys.

MARTIN: So a really cool final use case about tags that I
want to share with you is, actually, that you can couple
tags to do actions on your device, so for example, on
your phone or your tablet.
Now, for example, you can associate a sticker that you
put on your bedstand with muting the volume or launching
a different application.
Or you can have a sticker in your office that disconnects
the Wi-Fi and does different kinds of settings.
Now there are a few cool applications in Android Market
already that allow you to configure a tag to execute
certain operations on your phone.
And one of the applications I'm going to show you is NFC
Task Launcher, which allows you to do just that.
So in this application, you define a new tag.
And for each tag you can define a number of tasks that
you want to be executed whenever you touch this tag.
So let's say I want to create a task for when I go to Google
I/O. I think one of the things I want to do when I get here
is, you know, launch the Google I/O application to see
what sessions I'm going to go to today.
I probably want to mute the volume to make sure that,
during the sessions, I don't interrupt anything.
Now, so let's add an action.
I can add an action to launch an application.
And for the application, I'm going to select
the Google I/O app.
OK, I can add as many actions as I like.
So I can add another action related to the volume.
I can say the ring tone volume.
I can configure it.
In this case, I'll just set it to mute, all right.
So now I have two actions.
I can press finish.
And the next thing I have to do is I just need to have an
empty tag, like this one.
I can put it under my phone, touch the phone, and it writes
the data to the tag.
So what's going to happen now is that, whenever I touch this
tag, it's going to execute these actions.
So we just to find a good place for this tag.
Why don't we use your badge?
ROBERT: Yeah, sure, so I've got my badge, which has one of
those old-fashioned QR codes on.
[LAUGHTER]
MARTIN: Yeah, it doesn't really work very well.
Let's do it like this.

So now, whenever you touch this tag with any of your
phones, what it's going to do, it's going to launch the
Google I/O application, and it's going to set
the volume to mute.
So you can have all kinds of cool actions associated with
each of these tags.
You just stick them on all the places that you like--
ROBERT: But you programmed that--
that could be a trick.
Because you programmed that.
MARTIN: Oh sure, want to try a real device?
ROBERT: Does it only work on your phone?
There we go.
So I can go in there, and is it going to set my volume?
MARTIN: Let's do it with this phone.
This'll work.
It does the same.
ROBERT: Awesome.
MARTIN: Cool.
ROBERT: And it auto-launches the app, cool.
Now, actually, all of the things we've shown you are
possible today with Ice Cream Sandwich.
But we announced Jelly Bean yesterday, and we've got some
new, exciting NFC features.
We've added new features to J, which we'll be able to tell
you a little bit about today, which we think will be very
exciting for users and for accessory manufacturers, all
of the people who make accessories to work with
phones and devices.
One of the great things about all of these devices is-- you
know, they're wireless, they can connect over Bluetooth--
but every time on Bluetooth, you need a PIN, you've got to
have 1234, you've got to have 0000, and it's a pain.
With NFC you can just tap to pair.
So Martin's got his headphones on ready, and I've got my
phone here.
So I've got some music on here.
So let's see what happens when I tap my phone up here.
And it says it's connecting to the headphones.
And music should start any second.
So Martin's rocking out, but hang on, hang on,
let's bring him back.

And disconnecting, simple as that.
You're a tough--
[APPLAUSE]
ROBERT: Yeah, thank you, yeah.

Tough crowd.

Actually, that is a bit of a cheap demo because Martin is
perfectly capable of pretending to dance.
So we got these speakers, which are just the same,
NFC-powered.
And, you know, after a busy day at Google I/O, I've been
partying, want to come, keep the party rocking.
I just take my phone--

[MUSIC PLAYING - KRISS KROSS, "JUMP"]

ROBERT: All right, really, really easy, and--
[MUSIC STOPS]
ROBERT: --when we've had enough Kriss Kross, easy to
get rid of them.
So once again, NFC making pairing by Bluetooth, that was
creating a Bluetooth connection, completely
transparent to the user.
Taking advantage of that 5 centimeters just so that you
can come and tap and make things happen,
really, really easy.
So we got rid of those horrible PINs that used to
slow you down.
So let's have a look at another area that could be
improved by getting rid of PINs.
Let's talk about the future of file-sharing between devices.
So, quick question, how many of you have transferred a file
between two devices using Bluetooth in the last year?
So about, maybe, I think that's about a fifth, a fifth
of the hands.
In the last month?
Yeah, a few hardcore masochists.
And in the last week?
So kind of no one.
You've been having way too much fun here to be messing
around with Bluetooth file transfer.
And if you look all the steps that it takes to achieve
Bluetooth file transfer, it's not really surprising.
So let's have a look at the future of sharing.
So I'm going to take a quick picture of you.
I'll do this side, just to be fair.
I don't want you feeling left out.
So there we go.
So I've got a picture of you, which is on my phone now.
So let's see what happens.
MARTIN: Switch them on for you?
ROBERT: Yeah, thank you Martin.
So, sorry, you need to be able to see what we're doing.
So I've got that picture here.
And when I tap to beam it over, let's see what's
happening on Martin's phone now.
So he has a notification that there's an incoming beam.
And even though that file is a few hundred k, and the phones
aren't now within NFC range, you can see
it's doing the transfer.
So this is much, much easier.
So as that completes, it may take a few more seconds
because it's quite a big file from a Galaxy Nexus camera.
MARTIN: Yeah, several megabytes from the camera.
ROBERT: Yes, several megs.
So how did that happen?
Well, the good news is, as you saw there, it's absolutely
transparent to the user.
There's no steps, there's no confirmation, just the usual
Beam behavior.
This supports photos and videos.
What we're actually doing is initiating, using NFC, the
Bluetooth file transfer.
So we automatically pair the devices in the background.
We don't need the user to confirm because they've used
Beam to confirm.
And automatically, there we go, it's completed.
So Martin can show that now just to
show we're not cheating.
MARTIN: It's saying "Beam complete."
Just have to tap it.
ROBERT: And there's a photo.
So how easy was that.
And that will work--
[APPLAUSE]
ROBERT: Thank you.

So that's a new public API for you to use.
And it can be any payload.
These are just the payloads that are built in.
So your apps can take advantage of this too.
So we've show you some cool demos.
Let's go on to talk about how we think you might want to use
NFC in your applications.
And we're excited that many of you are already doing that.
Here are some reasons why it can be useful to
add NFC to your app.
Well, users love NFC.
It's so easy and natural, you just tap things together and
stuff starts to happen.
It really feels magical, it's like being in a movie.
You can just walk up to things and make stuff happen.
It really does give you that kind of
Minority Report feeling.
The good news is, you can make users feel good like that in
just a few lines of code.
This isn't a big effort for you guys.
It's really simple to add it.
We're very lucky that we have so many thousands of great
developers like you guys building for Android.
But we know it can be hard to make your app stand out.
Taking advantage of these new features makes life easy for
your users and it can help your app to do well and to
perform and to get users excited.
Let's take a quick look at the opportunities.
We think there's kind of two ways to look at NFC.
When you're doing things with tags, the kind of stuff Martin
showed, you know, putting a poster up, putting a sticker
up by the light switch in your home to change your behaviors,
maybe, of your phone, you're probably thinking about new
applications and new use cases, things that you didn't
necessarily do before.
And there's lots of documentation on the web about
how to do that.
And people think about, you know, games in the real world,
where you have to go around collecting tags to prove
you've been in a place, and things like that.
If you already have a successful app on Android in
the Play store, what we think you should try to think about
is, where in the app do your users have something they
might want to share?
Where might they want to share the context or the content
between two devices?
Because Beam is a great way to do that.
Beam isn't really about new use cases.
We were talking to a developer yesterday, and he said, well,
all it does is share content from one device to another.
Well, yeah.
We thought that was pretty good.
It doesn't have to make the tea.
It just share content from one device to another.
And that, kind of, is the point about it.
So for the rest of the presentation, we're going to
focus on Beam and how to share content and
context between devices.
And at first, you may not think that your app has
anything to share.
Maybe you don't take photos or create new content.
But just like we showed with Paper Camera, almost every app
has some state that might be complex to set up, you know,
there's many settings.

Think about what's useful to move from
one person to another.
But also, just think about the fact that many people have
more than one NFC-enabled device.
All of you now have several.
You might be looking at something on your phone, you
want to look at it on a tablet, you want to make play
on a Nexus Q, for example.
It's very, very natural to beam from
one device to another.
So it isn't always about one person to another.
It could just be the same person who's come into the
room, or changed context, or picked up another device.
So before I hand over to Martin to show you how to make
this magic and add it to your applications, I want to point
out a couple of pitfalls with Android Beam.
We tried to make it really magical, and in a few cases,
we've seen some apps that make us a little bit sad.
Because they've, somehow, managed to break Beam.
And when you break Beam, a kitten dies.
It really is that simple.
So please don't break Beam.
Well, how do you break Beam?
Usually by adding something to it.
And we're not going to name names today, because we
wouldn't do that, because we love all of our developers.
But here are some of the things we've seen done.
We've seen somebody put Beam on a menu.
So over on the right-hand side there, you see, on the slide,
it's like, oh I want to share now.
The user tells your app they want to share using Beam by
putting it next to another device.
They don't go and choose from a menu.
They shouldn't have to do that.
That proximity is your cue to share.
And when Martin comes on to talk about it the APIs, you'll
see how you can even be very late-binding and only declare
your payload at the time when you're in close proximity with
another device.
So please don't put it on a menu.
Please don't add other dialogues.
In the middle there, you've got a pop-up that we've seen
in apps that says "Are you sure you want to share?"
Again, how often do you put your phone within 5
centimeters of someone else's phone?
It's a very deliberate act.
You do not need to click and say, "yes, I'm absolutely
sure."
So those are all ways, we think, you can
chase the magic away.
So please don't do that.
And please just leave Beam be.
It's not perfect.
We're always going to add new things, and we're going to
talk at the end about a few ideas about where we might go.
But for now, just try and keep it simple.
So I don't want to dwell anymore on how to do it wrong.
I'm going to hand it over to Martin to show you how you can
add the magic of Beam sharing into your apps.
MARTIN: Cool.
So let's take a look at how our Beam
share works in detail.
So let's say you have two devices, device A and device
B, and you want to send something across from device A
to device B. Now let's say that your application is the
one that's running on device A.
As you know, Android applications basically consist
of a number of activities.
What you developers have to decide is, for each activity,
does it make sense to share anything over
Beam for this activity?
And if so, what is that?
And once you've determined that, you have to use a few
set of simple APIs to tell the Android operating system about
the data that you want to share from this activity.
So what happens next is that whenever you bring the two
devices in range, the Android operating system is going to
check which activity is running in the foreground now.
Once it has determined that, it'll see that for the
application in the foreground, is there anything registered
that they want to send over Beam?
And in case there is, once you touch the button to send,
it'll automatically send the payload across.
So on the receiving side, you get the data over NFC.
And, basically, what we do with any incoming NFC data is
we try to start an activity to deal with the data.
So we somehow have to resolve the NFC data that's incoming
to an activity.
And we'll go into more detail on each of these steps later.
So first, I want to share more about the data format that you
use for sharing over NFC.
And the data format is called NDEF.
So let's first go a bit more into detail about
NDEF and how it works.

So NDEF stands for the NFC Data Exchange Format.
And it's basically a simple message format that was
defined by the NFC forum, which is like the NFC
standards organization.
And it's backed by all the major industry players.
And NDEF has, really, two basic types.
One type is the NDEF message, and the other entity type is
an NDEF record.
Now an NDEF message is really simple.
It's nothing more or less than one or more NDEF records.
So it's just an encapsulation of multiple NDEF records.
And what is an NDEF record?
An NDEF record consists, basically, of a
single set of data.
So a single NDEF record can be something like a URI.
It can be a vCard, it can be a link to a
place on Google Maps.
You can have multiple of these records in a message.
Now once you go inside a record, let's see what fields
it's composed of.
Now the first field in an NDEF record is called the Type Name
Format or the TNF field.
And all the Type Name Format field does is tell the
interpreter how to interpret the second field in the
message, the Type field.
So there are a few distinct values that you can use in the
TNF field, and each of those changes the way that the type
field is interpreted.
You can see some examples on the right.
If you use a Type Name Format value of 1, which stands for
the WELL_KNOWN type, and for the Type, you can actually use
a few short byte values.
For example, if you specify the Type as 55 hex, that means
it's a URI.
And the reason why this is good is that you only use two
bytes in the process of specifying which type of
record this is.
So this is a lot easier than actually spelling out the MIME
type in text, right?
Remember, NFC is low data rate, so you don't want to
waste too many bytes.
So WELL_KNOWN is what you use to have a few well-known
record types and be able to encode it in one or two bytes.
Now a different Type Name Format is, for example,
MIME_MEDIA.
When you specify Type Name Format as MIME_MEDIA, value 2
in the TNF field, that means that the Type field will be
interpreted as the MIME type of the
packet that you're sending.
So then in the Type field, you can put a string, for example,
saying text/plain, which is a MIME type for your record.
Next, there's an optional identifier.
Most people actually don't use the identifier.
You can put any bytes in there that you want.
But the Android operating system doesn't actually do
anything with it, so it's purely optional.
And the final part is the important
part, that's the payload.
So in the payload, you put the actual data
that you want to share.
So in case you want to share an URI, in the payload would
be the actual data of the URI itself.
So how do you create such a message for the Android APIs
that we have?
Well, there's a few ways to do it.
And the first way is we do the hard way.
So we have the constructor on the NdefRecord, for which you
can specify all for the fields of the NdefRecord.
So the first field is the TNF field, in this case
WELL-KNOWN, the second one is URI, Type URI.
You can specify an ID and get the bytes of it.
And finally, you can get the actual payload in it and put
the bytes in there.
Now, because a lot of people just want to have some
standard records like URIs, we actually created some helper
methods on the NdefRecord clause.
So instead of using this complex constructor, you can
use a lot easier way.
Simply call NdefRecord.createURI.
And as the only argument, you have to specify the
URI that you want.
And it will automatically create a record for you.
So the second statement is equivalent to the first one.
Now another helper that we have is if you want to create
your own custom MIME type.
So NdefRecord.createMime allows you to specify, as a
first argument, the MIME type of your record, and as a
second argument, the payload that you have.
So this way, again, you don't need to use a constructor.
You just have to pass in these two values, and you're done.
Now once you've put in the NdefRecords that you want and
put in the message, all you have to do is call the
NdefMessage constructor, and as an argument, you can
specify one or more NdefRecords.
In this case, I just created a message with a single record,
which is the URI record that I created earlier.

So one of the things you might ask when you see these slides
is, well, how do I know which type I should use?
And I think one of the guidelines is that if you use
an existing type, for example, if you were to use text/plain,
which indicates text type, then any applications on the
receiving device that already have or handle this MIME type
will be able to handle this payload as well.
So this allows you to reuse implications that can deal
with your payload.
On the other hand, you may have some
very specific payloads.
For example, there's something that only
your app can interpret.
In that case, you may want to have to, like, a MIME type
that's specific for your application.

And in some cases, you know, it's a hybrid.
Maybe in some cases, you have an image that you want to
share, or even a text file, but you still want a very
specific applications to handle it.
And we don't think you should be going and hacking around
MIME types.
In that case, we created a special NDEF record for
specifically that use case.
And that record is called the Android Application Record.
So what the Android Application Record does is if
you put in a message, it will guarantee delivery of the
message to the package that you specify.
So you can create an Android Application Record which
specifies package com dot Google dot whatever, and
whenever this message is received on the other side,
the operating system will make sure that that's the package
that handles the message.
Now you can even put multiple records that represent
multiple packages in an NDEF message.
So you can say, well, as a first preference, I want
application A to handle this payload, but if it's not
available, then please do it by application B.
And the other final thing to understand is that even if in
the application that you specify, it doesn't even do
anything with NFC, it doesn't handle NFC intents, it will
still be launched.
So it's still, if you create an NDEF message with an
Android Application Record, it's also an easy way for you
to launch an application on a remote device, even if that
application does not support NFC at all.
And the final thing to know about Android Application
Records is that if the receiving device is not have
the application installed at all, it'll take you to the
Play store, where you can actually install the
application immediately, which is what we saw before.
So just to show you how to build an Android Application
Record, we also have a helper method for that as well.
So all you have to do is, you create a URI record like we
did before.
And initially, you create an Android Application Record by
calling createApplicationRecord.
And the only argument have to give is the package name of
the package that you want to handle the payload on the
receiving side.
And now you simply compose an NDEF message by specifying
these two records.
So the first record is uriRecord, and the second
record this the Android Application Record.
And this'll make sure that the URI payload goes to the
application that you specified, pretty easy.
So once you've built the NDEF message, how, now, do you tell
the Android operating system for which activity you want to
pass this message?
Well, there's two really simple APIs that you can use.
So the one that you see on the top is the
setNdefPushMessage API.
It's a really simple API where you can just pass in any
activity, and as a second argument, you
can pass in the message.
Actually, it's the other way around.
And what this does, basically, is tell the Android operating
system for this activity, share this message.
And this is really great if you have static content for
your activity.
Like your activity is always sharing the same type of data.
So that's when you want to use this API.
Now there's a different set of use cases where the data that
you want your activity to share actually changes
dynamically during whatever you're interacting with in the
application.
So in that case, we actually have a
callback variant as well.
So what you do instead is you call the setNdefPushMessage
callback method.
You register a callback with the NFC service.
And whenever somebody brings the two NFC devices in range,
this callback is called.
You can form the NDEF message that you want to share, return
it, and it gets sent across to the other side.
So the second use case is really easy for dynamic
applications, for example, Gallery, where the activity
stays the same but the actual content changes if you swipe
your finger across the screen.
The important thing to know about the activities that
you're passing into this API is that you can basically call
this in any activity state as long as it hasn't been through
the onDestroy call.
So from whenever the moment you're in onCreate, you can
use this API, until the moment it's been through onDestroy,
and then it won't work anymore.
And even though the APIs allow you to specify multiple
activities, we recommend you don't do that simply because
for an activity that's not currently running, you don't
know if it's already been through onDestroy.
So it's the easiest, in your applications, to just specify
one activity.

So let's see an actual implementation.
I have my activity, X, for which I want to
share an NDEF message.
So in my onCreate, I simply have to get a reference to the
NFC adapter by calling a default adapter.
And all I have to do is call the setNdefPushMessage
callback API, which I just specified.
The first argument is the callback, which is actually
also an interface which is implemented by This clause.
And the second argument is the activity, which is also This,
in this case.
And then you just need to implement the / so the
callback is called createNdefMessage.
And all you need to do in this callback is create the NDEF
message that you want to be shared at this moment.
So whenever you bring the devices together this method
will be called.
You create the NDEF message that you want to share.
You return it.
And it will be sent across as soon as
somebody touches the screen.
One thing to note about this callback is that because it is
called whenever the NFC link comes up, you don't want to
wait too long or block too long on this method.
You just want to get the data ready because the user is
waiting at one point in time to to touch and
send the data across.

So that's all you have to do for the sending side, really.
Just specify the data that you want and tell the Android
operating system, for this activity, I want
to share this data.
So what happens on the receiving side?
Well, the receiving side gets an NDEF message as well in the
NFC service.
And the NFC service somehow has to translate this message
to an activity that can handle it.
So how does that work?

This slide shows a bit of code that's inside the NFC service.
So it's not code that you need to write yourself, but it's
just there to illustrate how the NFC service does this.
So when I receive the NDEF message, it takes a look at
the first record of the message.
Specifically, it takes look at the Type Name Format and the
Type fields.
And basically, from these two fields, it creates a Type that
it sets on intent.
So the first thing it does is creates a new intent, and the
action on that intent is ACTION_NDEF_DISCOVERED, to
indicate that it's found a new NDEF record.
And the second thing it does is set the Type, based on the
Type Name Format and the Type.
And finally, it puts, as an extra, the
entire message in it.
So whatever activity is going to handle the message, it can
actually get the full message by getting the
extra from the intent.
And then the NFC server simply calls start activity, and the
normal Android operating system kicks in to find an
activity that actually matches these constraints.
So let's take a look at how the Type Name Format and Type
fields actually are converted into a Type field in the
intent So we have a few different records here.
The first is a URI record of Type WELL_KNOWN.
It shows all of the NDEF fields.
So the first is TNF, which is WELL_KNOWN, the second is the
Type, which is the URI type, the X value that
I showed you earlier.
And the third is the Payload.
So this is going to be translated to a data field on
the intent.
And the data will be a URI, http://www.google.com.
Another example is a text data.
You can also specify text data by using a TNF of WELL_KNOWN.
Use RTD_TEXT to indicate that it's a text type.
You can put some text in the payload.
So this is going to be translated to an intent type
of text/plain.
And there are a few different examples on there.
You can also use a custom MIME type.
And, in this case, your custom MIME type,
application/vnw.mine, will end up on the intent.
So it is really a straight mapping from the Type Name
Format and the Type fields, to the Type fields, or the Data
field that's in the intent.
So I told you before, also, about
Android Application Records.
How do they tie into this picture?
So basically, the code in the NFC service looks the same for
the first part.
So you will still look at the first record.
You will determine the Type from the Type Name Format and
the Type fields.
You'll put the extra, which has the full NDEF message.
But for each application record that you find in a
message, you're going to call the
setPackage API on the intent.
And basically, this tells Android operating system to
deliver this intent to that package specifically.
So for each package that's in there, we first
try to start it.
If it doesn't work, we try the next one, and so on and so on.
Finally, like I said before, if you don't find any activity
you either launch the first application that's in the AAR,
or even if it's not installed, it takes you to the Play store
to install the application.

Now let's say that you're interested in
receiving such an intent.
What do you need to do?
Well, it's actually really simple.
I showed you how the intents were formed, right?
It's an action with NDEF_DISCOVERED.
It has a certain Type.
All you need to do is write an intent filter for your
activity that actually will filter for this intent and
deal with it.
So in this case, let's say you have and activity Y, for which
I want to receive a specific amount of NDEF data, a certain
amount of NDEF data.
Let's look how it works.
Just in the Android manifest, for the activity Y, I can
specify a few intent filters.
So the first one, for example, is an intent filter for the
MIME type application/vnw.mine
So the action is the action NDEF_DISCOVERED, which is what
the NFC service used.
The category is default, as usual, and you just need to
put in the MIME type that you want to filter for.
Well, the second example is on there as well.
If you want to have a URI, for example, google.com/nfc, you
can put an intent filter.
The action is NDEF_DISCOVERED, but the data is the scheme you
set, HTTP, and you can put in the host and the paths to
match exactly what you want.
You can also use wild cards in there to match different kinds
of patterns.

So once you've done that in the manifest, all you need to
do is, in your activity that's handling it, in activity Y, in
this case, you need to get the actual data and do
something with it.
So in this example, I show you the onCreate method for your
activity Y. This will get called by the NFC service.
And basically, what you do is you just
need to get the intent.
You need to check the action on the intent to make sure
it's an NDEF_DISCOVERED intent and not a different one.
Once you know it's that, you can actually get the payload,
the NDEF message, from it by just getting the extra out of
the intent.
So you can use the intent dot getParcelableArrayExtra to get
the extra out.
And then you have the actual message.
And once you have the message, you can get the first record.
And from the record, you can get the actual payload.
So now you actually have the same payload that the other
side put in into the NDEF record, and you can start
processing it or do with it whatever you like.
If it's some big data, you probably want to do it on a
different thread.

So one of the important things about receiving, and this is
really, really important to understand, is that a design
decision we made is that every NFC interaction that you have
with your device, be it touching a tag or doing an
Android Beam, it will launch the activity
in a new task stack.
And the reason for it is that, you know, we don't really
know, when you tap a tag, was it really part of the previous
activity that you were doing?
Or is it something new altogether?
So this is the default behavior of Android when
launching NFC activities.
It'll just start a new task stack.
Now for some applications, that may not make sense.
It may be that your application always has a
single activity, and you want it to be launched always in
the same existing task stack.

So let's show you how it works.
In that case, you can actually specify for this activity that
the launch mode is single task.
So what this does is this tells the Android operating
systems do not create a new task for this specific NFC
intent but instead to deliver it to the existing task that's
already running in a separate task stack.
And the main difference here is that instead of calling
onCreate and giving you a new activity, this will actually
call the onNewIntent method, which allows you to deal with
the NFC data in the activity while it's already running.

Now there is a final use case that's important that is if
you have multiple NFC interactions with multiple
activities.
So the previous slide, that just showed you one activity,
and you can have multiple NFC interactions with that, and
for each interaction, you get a call to onNewIntent.
Well, what if you have multiple activities?
Well, basically, if multiple activities have the same
intent filter, that will pop up the intent or the Activity
Chooser, right?
You've seen that before, if you open a URL, you choose
between browser and Chrome.
This will also happen for NFC interactions.
So in this case, what you would typically do is, you
would typically have an entry task, where you want to start
interacting with your NFC tag, or maybe with Android Beam.
And this entry task you would typically give launch mode
single task, so you make sure that it routes to an existing
task stack.
Now for all of these subsequent activities you can
use different a different launch mode called Single Top,
which means that if that activity is currently running
on top, your NFC intent will be delivered to that activity.
And you can combine it with a feature we
call Foreground Dispatch.
I won't go into too much detail about it here, but
Foreground Dispatch allows you to bypass the activity chooser
altogether.
You can say to the Android operating system, hey, I want
to deal these kinds of intents or intent filters right now,
and I don't want any other applications to be
able to handle it.
All right, so let's talk about some new stuff in J. I'm
really excited about this API because it brings together a
lot of cool features and technologies.

So as we've seen before, it's really hard to get a file from
one device onto another, right?
As we showed with Bluetooth, there's lots of screens and
confirmations involved.
So let's take a look at how you would do this with the new
NFC API in J, which allows you to share pictures and all
kinds of large data.
So all we have to do is, let's say I have an activity here.
And in this activity, I want to share,
like, a URI to a file.
Or I want to share a URI to a content provider.
I can get a reference to these URIs.
And all I have to do is call a single method on the NFC
adapter calling setBeamPushUris.
And in this API call, I basically specify the URIs
that I want to be sent across to the other device.
There's also a callback function in this case.
And this is really all you need to do.
So once you do this, whenever you bring the devices into
range, and you tap it, Android will actually get the data,
send it across to the other side over Bluetooth, which is
really fast, and it'll deal with it on the other side and
launch an activity to handle it.
This is all you need to do.
It's quite amazing, I mean, five lines of code-- it's so
hard to get a file onto another device.
You just have to write this, and all you get is just
instant transfer without any confirmations or whatever.
It's just like the Gallery demo that
we showed you before.
So how does it work?
It's pretty simple.
In the flow that we had before, you have device A and
device B. So on device A, you just call this API, the
setBeamPushUris API.
And whenever you bring the devices in range, the NFC
service is going to transfer the MAC address of the other
device, device B, to device A. And this allows device A to
set up a background Bluetooth connection, which allows you
to transfer the data.
So once that's done, the data is
actually sent over Bluetooth.
The receiving device stores the data in a file then.
And it launches an ACTION_VIEW intent to actually deal with
the data on the remote device.
So I want to call this out.
This is different from action NDEF_DISCOVERED because action
NDEF_DISCOVERED only works on NDEF data and is specific
specifically to NDEF.
However, there are already a lot of applications that deal
with the ACTION_VIEW intent because it's the main intent
that you use for viewing information.
So that means that whenever you write some code that does
this, if the receiving side already has an application
that handles your data, it will automatically be
launched, which is really great.

So the great thing about this API is that you get all the UI
and Bluetooth handling for free.
So you don't need to write any Bluetooth code or any
confirmations or whatever.
You just really need to write a few lines of
code to make it happen.
And the other thing that's important about it is that you
can use it in combination with the NDEF APIs that I showed
you before.
So the new API will actually only work on devices
that have J or late.
So this is important, right?
You want to have a fallback method in case the device that
you're sending data to doesn't have the newest implementation
that allows you to share large data.
So what you can do is you can use both APIs.
Android will first try to use the new J way of doing things,
which is sending stuff over Bluetooth really fast.
If it finds out the other device doesn't have Bluetooth
or doesn't have the capability, it'll
fall back to the URI.
So you can still have a fallback mechanism in case
things don't work.
All right.

Let's wrap up.
I want to share some things we're thinking
about with you guys.
So what we hear a lot on the developer forums is that Beam
is really only one-way, right?
You bring the two devices together, and one of the two
taps, and then data gets sent across to the other device.
In fact, I think, if you're really careful with timing,
and you touch right at the same time, you can get it
going two-way, but that's not really the way to do it.
So we're really thinking about supporting two-way
communication in Android Beam and making sure that once you
bring the devices together, you can actually ping multiple
messages back and forth and enable, you know,
much cooler use cases.
You can have all kinds of protocols going, then.
The other thing we hear a lot is customizing the Android
Beam animation.
So right now, you see that whenever you bring the devices
together, the screenshot scales down.
There's some nice star field behind it.
Maybe we want to give you some APIs to actually specify the
screen shot that's shown, that's being scaled down.
Or maybe you even want to do your own cool custom
animations.
So that's something we're definitely looking into.
And the final thing we want to do is, you know, we have this
great API which allows you to easily send across large files
over Bluetooth.
And we want to extend it to use Wi-Fi Direct.
The main reason we haven't done so now is that this is
not a standard yet.
So we want to make sure that when we implement it, we want
to implement a standard, so that it actually works across
all of the devices.
So we want to make sure, you know, you don't have to worry
about this, it should just work.
And if we do implement Wi-Fi Direct, we'll just hide it
behind the same API.
So to you guys, it will just be transparent.
It'll just work.

Something else really important, which I hear a lot,
NFC uses a lot of power.
You see this on a lot of forums, or
people say that it does.
So first of all, when you phone is off or when your
phone is locked, the NFC
controller is not even enabled.
So at that point, it's not really consuming
any power at all.
Even when your phone is unlocked, and so we enable the
NFC controller, still, only, power is minimal.
It's like, compared to all the rest, it's, like, 0.5% of
battery usage.
So it doesn't really amount to anything.
You can safely leave it on.
Because if you turn it off, it really breaks the magic
because then you will have to go into the menu settings
again and enable NFC to make stuff happen.
It's much easier to just leave it on.
You really won't notice in your battery usage.
Also, NFC controllers in the future will use less power, so
I think it's getting better and better.
So summarizing what we talked about today.
The first thing is really important,
NFC is here to stay.
A lot of people discussed this also, when are the NFC devices
coming out.
It's happening right now.
We see one million NFC devices activated every week, which is
a huge number.
There is a lot of growth in that number as well.
The second thing we wanted to share with you is that adding
NFC to your applications is very easy.
You just add a few lines of code, and automatically, the
operating system will take care of the rest, sharing it,
sending it across NFC, and dealing with it
on the other side.
It's so easy, and it really adds value to your application
to do stuff like this.
And finally, the new J API is really awesome.
I mean, you just have to write a few lines of code, and you
can automatically send across any file on the file system or
any data from a content provider to the other side,
not having to worry about any pairing or setup or--
just bring the devices together, tap, and the file
automatically gets sent across.
It's awesome.
All right, I'm going to hand off to Robert, who's going to
talk to you about a Beam file.
ROBERT: Yeah so I guess I should add just a quick legal
disclaimer, this is not available if you're watching
the repeat on YouTube.
But for those in the room, who's got the Google I/O app?
Most of you, I hope.
We actually put a little Easter egg-- thank you we've
already got a winner down there--
we put a little Easter egg for you in the app.
So if you grab your app, and you beam, you will add an
item, sorry, there, you will see an extra new item in your
menu which says, show Android Beam Easter egg.
Which looks kind of like that.
And if you come up and see us afterwards, we'll give you a
limited-edition Beam pin.
We have just about enough for everyone, but they are only
available here today, so do come and grab them.
We just wanted to make sure that everyone had tried Beam
and everyone had used it.
So it was just a bit of fun for today, so
sorry YouTube viewers.
Come and find me at my desk, and maybe I'll
have some pins left.
So yeah, that wraps it up.
We want to move on to Q&A. So there we go, there's just a
reminder so that you can see that.
And yeah, let's take any questions about Beam or NFC.
And thanks very much for listening, for those of you
that don't have questions.
There are microphones.
It's probably easier if you come and grab a mic.
And we'll do we can to answer.
Thank you.
AUDIENCE: I have a question about the--
[APPLAUSE]
ROBERT: Thanks.

Oh, very orderly queue-forming, thank you.
OK, first question.
AUDIENCE: Do the Bluetooth radios have to be on for the
Beam APIs to work?
MARTIN: That's a great question.
Actually, we do turn it on for you automatically.
ROBERT: Could you repeat it to make sure everybody can hear?
MARTIN: Yeah.
So the question was, does Bluetooth already need to be
on for the APIs to work?
That's actually not required.
So if Bluetooth is off at the moment of the transfer, we
automatically enable it for you.
When the transfer is done we turn it off again.
So you don't have to worry about turning Bluetooth on
before the transfer.
It just works.
ROBERT: We take care of it.
Next one, hi.
AUDIENCE: Is there any way to have Bluetooth as a backup if
there is not NFC?

ROBERT: So is there any way to have Bluetooth as a backup if
there isn't NFC?
ROBERT: Or use some of the same APIs without having to
recode it for a separate Bluetooth.
MARTIN: Not right now.
I think in case of that, you would have to use the normal
actions and the APIs to get the data across.

ROBERT: Hi, next one.
AUDIENCE: Hi.
Underlying that, are you using the 2.1 insecure pair in the
background?
Or is there some sort of PIN happening in the background?
MARTIN: This is the implementation of the
Bluetooth Secure Simple Pairing setup.
ROBERT: Thanks.
MARTIN: Thank you.
AUDIENCE: The Bluetooth pairing is fantastic.
Is it possible to establish a serial-style connection, and
do you guys provide any example code for
that in the new SDK?
MARTIN: Not with the current API.
So right now we just allow you to automatically set up OBEX
push for file transfer.
But it doesn't allow any other sockets yet.
But it's something we may look into in the future.
AUDIENCE: Thank you.
AUDIENCE: Hi.
We already added NFC in our application.
You can test on Beautiful Widgets and Plume.
But we have to add the intent action, NFC_DISCOVERED.
Is there a way to share a normal ACTION_VIEW intent?
MARTIN: So for NDEF, there isn't because NDEF is a very
specific payload format.
So this just works for the new Bluetooth APIs.
ROBERT: Bless you.

We have rules.

MARTIN: Should we move the Q&A somewhere else?
ROBERT: Yeah keep going with the Q&A. And if you kind of go
this way to do pins because we want to do Q&A. Because this
is important, and we can do pins outside.
So please keep the questions going.
And try and stay quiet down in front, so the
Q&A guys get their--
AUDIENCE: Sure, my question's about Beam and compatibility
with non-Android devices.
Is that possible?
Are those just NDEF messages standard, NDEF messages coming
across to establish the Beam connection?
MARTIN: That's a good question.
So we implemented all of the NFC Forum standards for each
of these things.
So NDEF is one of these standards, but also, for doing
the actual data transfer, there's a protocol called
SNEP, which is Simple NDEF Exchange Protocol, which
allows you to send across NDEF messages.
And this is a standardized protocol as well.
So all of these devices that implement this protocol, it's
an open protocol, will be able to receive beams.
In effect, we've seen Beam already interplay well with,
for example, RIM devices.
And the same goes for the Bluetooth pairing.
There is a standard for that by NFC Forum as well, so, for
example, passing on a Mac address.
So everybody who implements the standard should be able to
get this Bluetooth connection going and send data across.
So it's all based on standards.
AUDIENCE: So a follow-up question to that is, you talk
about the seamless experience of doing a
beam between two devices.
And it's my feeling that tapping the screen is really
an extra piece of friction that's not necessary, from
being that you wouldn't necessarily put two devices
that close in proximity to each other if you didn't
intend to exchange data.
And I'm just wondering if that's something that could be
removed or is being considered to be configurable, at least.
MARTIN: Yeah, I think the short-range
stage is a bit there.
If you play with a Nexus 7 and a different phone, you'll find
that you actually need to be careful with the positioning
to make Beam work.
So in most cases, if you put something on top, you actually
won't see any beam.
You just need to put it in the right spot.
But we could think of more advanced stuff, like if we
detect that there's an NFC connection, we could, for
example, disable the touch screen so it doesn't react
anymore to any input events.
So that's something that we may consider in that case.
But that's not currently done.

AUDIENCE: In one of your demos, you showed, basically,
Beam or NFC muting one of your test devices.
So you had a tag that muted the phones' notifications.
I'm wondering if there's any need security considerations
going into that.
Like, maybe somebody put a tag somewhere that mutes phones,
and you didn't really want that to happen.
Is there going to be an API at some point that says, you
know, do you really want to do this?
MARTIN: I should point out that these tag actions only
work if you have the application installed
to deal with them.
So that's already a bit.
And for this specific application, I know they
actually pop up a notification saying that
they activated something.
So you do have a clue that something is ongoing.
So I think it's a careful trade-off, right.
Maybe you don't want to ruin the magic by allowing people
to confirm.
So I think, in most use cases, the trade-off is right.
You'll see something is going on.
And if it's wrong, I think you'll catch wind of it.
ROBERT: How's the Q&A going, Martin?
I'm a bit tied up here.
MARTIN: Pretty good.
ROBERT: Cool.
MARTIN: Lots of queuing here.
ROBERT: So guys, I'm going to change tacks slightly.
I'm assuming I can trust all of you, right?
Don't take a handful of pins.
Just take one.
And, please, if you do an take more than one, because you
can't be trusted, you must beam someone else who hasn't
beamed and give them one of the pins.
How does that sound for a deal?
Is that fair?
So if you take two, make sure you give one to someone
tonight, spread the love, and let's do Q&A.
So I'm going to put the pins here.
It will be a free-for-all.
Please don't crush each other, we value every one of our
developers, we can't afford to lose you.
MARTIN: There's enough for everybody.

AUDIENCE: Hi, I've got a very related question.
We're working on secure payments and was wondering if
you have any security requirements for NFC
specifically.
MARTIN: Sorry, could you repeat the question?
AUDIENCE: We're working on secure payments and was
wondering if Google has security requirements
pertaining to NFC side.
MARTIN: So I think what we'd have you do is, it depends on
how you implement the payments.
If you wanted to implement it over peer-to-peer, for
example, the Android Beam protocol that we have, you
need to do some encryption of yourself.
Because by default the channel is unencrypted, right?
So if it's your own application, I mean, Google
doesn't set any requirements.
But I think it would be wise to actually encrypt your
traffic yourself and do some form of identification to make
sure that nobody can actually eavesdrop it.
I mean, it's really hard because of the close range,
but still I think it's a good idea to put some kind of
encryption and authentication in these sensitive cases.
AUDIENCE: OK.
MARTIN: Does that answer your question, or--
AUDIENCE: Yep.
MARTIN: OK.
AUDIENCE: Hi, you showed in one of the demos where you
were able to write multiple actions onto a passive tag.
Does that work with passive tags from any manufacturer and
of any type, or is there a specific manufacturer that
supports this?
MARTIN: So the question was, if the task launch demo that I
showed that has multiple actions, if it works will all
of the tags.
So Android supports all of the standard NFC forum tag types,
which is tag type 1 to 4, if you're familiar.
So if you buy any of these tags, it
should work with that.
So they come in different sizes, but most of the popular
tag types are supported.
AUDIENCE: OK, you can write multiple actions to any of the
standards supported.
MARTIN: Any of the standard tags will work.
AUDIENCE: Hi, the Bluetooth pairing, the connection
handover that you just showed, is it NFC Forum
standard-based?
Does it follow the NFC Forum standard?
MARTIN: Yeah so it's based on the NFC Forum connection
handover specification, which standardizes the way the MAC
address and the PIN is exchanged.
ROBERT: We really hope that other platforms will pick up
and do exactly the same thing because that's just going to
make it easy for users.
AUDIENCE: OK, great.
And when are you going to open card emulation to developers,
at any point?
MARTIN: Yeah, it's a popular question still.
We just haven't found the right way to expose card
emulation and APIs to our users.
I think, when we do, we want to have a consistent set of
APIs and experiences.
So one of the issues with card emulation is that not even all
devices have the secure elements.
Which, I think, makes it harder.
And also, it has a limited amount of storage.
So that means, for example, if your storage is full, and you
want to do some exchange, you actually need to remove
something and stuff something new in there.
And it basically destroys the entire interaction.
So I think, for the current use cases that we have,
Android Beam is actually a really promising direction.
And card emulation I see more as something to interact with
the legacy reader infrastructure that we have in
place, right?
That's really what it's good for.
But right now, because the experience you have with card
emulation is very fragmented, it's hard to get it to work,
we don't want to offer any APIs because that would just
get users frustrated that it doesn't work sometimes,
sometimes it does.
It's hard to get it right.
AUDIENCE: All right, thank you.

AUDIENCE: Hi.
We work for a ticketing company, and integrating the
NFC check-in is really something we
are interested in.
The thing is, the Beam checking and this star field
effect is kind of something that is
slowing down the check-in.
So are you guys considering giving us the ability to just
get rid of it, or what are the plans on that?
MARTIN: Good question, it's definitely something we're
looking into.
So the question was, if we can speed up the beam process for
ticketing, or you really just want to tap something and walk
on without having to tap anything.
Yeah, we will definitely look into this
for the next release.
As far as I'm concerned, it's part of the two-way
communication protocol and customizing Beam.
So there may be a use case where, actually, you just tap,
and immediately the data link is established, and your
application can deal with it.
So we know it's an important use case, and we'll definitely
look into future APIs to do just that.
AUDIENCE: Awesome, thanks.

AUDIENCE: Again, sort of a security question.
The 5 centimeters, is that reliable, or are there ways,
you know, the Pringles can, to get around that and read it
more remotely?
AUDIENCE: It's really hard to get around it.
I guess if you have a really sensitive directional antenna,
and you would be able to aim it right at it, then it could
be possible.
But I think it's, in practice, really hard.
And also, most of the use cases, you just have your
phone in your pocket, right?
So at that point NFC is not enabled.
So it's really hard to get the data from it.
So I think, in practice, you could get a larger range if
you have really expensive equipment, but it's not
something to worry about in general.
AUDIENCE: OK, and then sort of a second question.
Bluetooth low energy, do Android phones
also support that?
And maybe the Nordic 2.4 gigahertz protocol
that's used by Fitbit?
MARTIN: I'm not sure about what our
plans are for low energy.
I think it's different, compared to NFC, in the sense
that Bluetooth low energy still has a large range.
So you still pick up multiple devices, or you still have to
select the device that you want to interact with, right?
And the great thing about NFC is you can tap something to
determine that you want to interact with it.
So I think that's the main difference between Bluetooth
LE and NFC at this point.
ROBERT: All of those radio technologies can combine
together to do really interesting stuff.
And I think that's one of the great things about having an
open platform is can weave use cases, and create new things
that no one's ever thought of by using
those things together.
So we don't see one of those technologies prevalent over
the others.
We want them all available to you guys.
We've got an API so that you can make magic.
AUDIENCE: Does or will Chromebug support NFC?
MARTIN: I don't think they do.
ROBERT: I don't think Chromebugs do support--
I don't think there are any that have been announced to
date that support NFC.
But it's great to put a tag on your laptop, and then you can
do all sorts of things you can use that, so it's a
good use for a tag.
Hi.
AUDIENCE: Hi.
For devices to support the Bluetooth pairing via NFC, do
Bluetooth device driver need to be updated?
MARTIN: So what we depend on, basically, is the existing
protocol stack in Android, the OPP protocol stack for
Bluetooth, because it uses the OPP protocol.
I think, actually, most OEMS take the
stack as is from Android.
I don't think they have, like, a custom OPP stack in there.
But OEM vendors that do replace the NFC stack, they
will actually need to write some code that
allows them to do this.
The main thing is basically about bypassing the UI because
normally, when you do Bluetooth OPP file transfer,
you get a lot of confirmations, a lot of
changes that you need to make--
I mean, a lot of confirmations you need to do.
So the main thing, really, that we changed in OPP is that
to determine if the transfer came from NFC and if it was
NFC-initiated, don't do all of this confirmation, but just
make the magic happen.
So those are in there--
ROBERT: Sorry, we're actually out of time.
So we'll take the rest of the questions up here, so we'll
take them offline.
Thanks very much.
MARTIN: We'll also be in office hours, by the way.
ROBERT: Sorry?
MARTIN: We'll be in office hours.
ROBERT: We will be in office hours, yeah and in bars all
over San Francisco.
But yeah, thanks for coming to the "Up Close and Personal"
with Android NFC.
And go make magic with Android Beam.
Thanks, guys.