[MUSIC PLAYING] FRANK VAN DIGGELEN:
We're going to show you how recent changes in
hardware and standards make one meter-location
accuracy possible, in some cases, as
soon as this year. I'll give you a
short overview now. Then Roy will introduce
Wi-Fi Round Trip Time technology and standards
and show you a live demo. Then Wei will explain
the Wi-Fi APIs. Then I'll return and talk about
new GPS technology and APIs. At the end, they'll be loading
up for the next session. So we'll take questions
right outside that door. And we'll be available at
office hours at 1:30 PM today. So it's a great time for
location applications because technology, hardware,
standards, and Android API is all evolving
simultaneously to enable accuracy that has not been
possible previously in phones. So eventually this means
high accuracy for everyone. But today we want to take you
under the hood of location because we want to give you
the opportunity to get a head start on the future. We also want to highlight the
need to protect and respect the user. The more people who use
location, the more careful we and you have to be. We'll highlight where you
must get user permissions, and we'll close
with some guidelines for making great location apps. So where are we today with
indoor location accuracy? If you think you've noticed
that your phone seems to be more accurate when
you're inside shopping malls and office blocks than
it was a few years ago, you're not imagining it. With each release of the
Fused Location Provider, we've had steady improvement
of the Android algorithms and machine learning
for Wi-Fi locations. There continues
to be improvement. And you'll see indoor accuracy
of better than 10 meters. But Round Trip Time
is the technology that will take us to
the one-meter level. Meanwhile, what about GPS? Well, in terms of GPS
accuracy in the open sky, there has been not much
change in the last few years. If you're out in the open
sky, your GPS accuracy from your phone is five meters,
and that's been constant. But raw measurements, raw GNSS
measurements from the phones, you can now improve on this. And with changes in satellite
and receiver hardware, the improvements
can become dramatic. Now, everyone's familiar
with the blue dot. But to get the blue dot, you
need the location provider, of course. And to get location, you need
measurements, specifically range measurements from
Wi-Fi access points or from GPS satellites. Today we'll show you how
one-meter measurement accuracy is available in phones. The key technologies are
Wi-Fi Round Trip Time, GPS dual frequency and
carrier phase measurements. And we'll show you how to
use accurate measurements to create accurate location. Now, if you just want
to wait a year or two, this will all find its way
into the worldwide ecosystem and the Fused Location Provider. But we want to give you a chance
for a one-to-two-year lead by taking accurate measurements
and turning them into accurate location. We want to work with
you to accelerate the future, to take it and
bring it closer to the present. So you might wonder, well,
why do I need better location accuracy anyway? Well, let's just
look at two instances where existing apps could use
much better location accuracy. So for indoor
routing or navigation of the kind that you're
used to in your cars, you need much better accuracy
than you have outdoors. You need one-meter accuracy,
because indoor features, like the distance
between cubes or aisles, are only a few meters. And even for the most
loved outdoor applications, such as directions and
especially directions in traffic, we could use higher
accuracy than we have now. For example, when you came
here this morning in a car, you probably had
the time estimated by the average traffic speed. What you really want is the
traffic speed in the lane that you're in so
that you could ask, how fast would it be if I
could take the carpool lane? There are, of course,
many other use cases, and I'll mention a
few before we finish. But the important
thing is that we are sure that you will have
many more ideas than we have, and that's the beauty of
the Open Android ecosystem. So now here's Roy to tell you
about Wi-Fi Round Trip Time. ROY WANT: Thanks, Frank. [APPLAUSE] And I'm very excited
to be here today to tell you about
a new positioning technology in Android P we call
Wi-Fi Round Trip Time, or RTT. You'll hear me say
that acronym a lot, which is basically measuring the
time of flight of RF signals. It has the potential to
estimate your indoor position to an accuracy of
one to two meters. Now, we're going to hit
the ground running today before I tell you about
the details of RTT. And we're going to show you
a video of indoor navigation powered by RTT. I want to emphasize,
first of all, that this is not a product,
but an internal prototype to explore the power
of the technology and how it can also
be used to support a other context-aware
applications. This prototype also
showcases some of the magic that Google could offer
to its employees today. So we're going to
roll the video. And what you should
keep in mind is that this is a bit like car GPS
except we're working indoors. So in a moment, you'll see
there's an application. It's a mapping application. And we're searching
for a conference room. We found that conference room. It's plotted the route. That's the shortest route. And now we're off. We're following the route. And as we make progress, you can
see the route is turning gray. My position from
RTT is the big dot. And I'm deliberately
making an error here. So the system is rerouting,
and it's rerouting again. If I get about 20 feet away, it
starts the rerouting process. And I'm following the route. And you can see the
corridor flying by. And there I'm
coming in, and I've arrived at my destination,
conference room Tepu. So that is the power of RTT. And the thing to think about-- [APPLAUSE] Thank you. The thing to think about here
is that if you didn't have one-to-two-meter accuracy,
then when that system rerouted, it would jump potentially
between aisles that were surrounding me. And it would be a
terrible user experience. So that's why it's so important
to have this kind of accuracy. So before I get into the
details of Wi-Fi RTT, I want tell you about how we
calculate location indoors now. We use Wi-Fi RSSI, which stands
for Received Signal Strength Indication. And basically we can
calculate distance as a function of
signal strength. Now, the figure that you see
on the left-hand side here, the access point,
which is in the center, has a heat map of
signal strength. The green is the
strongest, and the red is the weakest at the edges. And I've placed two
phones on this diagram at the transition between
the weak and the strong. Notice that the
phone on the right is further away from
the access point than the phone on the
left, so same signal strength, different distance. And it's this variability in
distance for signal strength that unfortunately makes it very
hard to get accurate readings from RSSI on a regular basis. But there are lots of
algorithms and tricks that we can pull
to improve this, but it can be improved further. And that's where Wi-Fi
RTT comes into place. So Wi-Fi RTT,
Round Trip Time, it uses time of flight
instead of signal strength. It measures the time it takes
to send a packet, a Wi-Fi RF packet, from an access point
to a phone and back again. And because radio signals
travel at the same speed as visible light, if we
multiply the total time by the speed of light
and we divide by 2, we get distance, round
trip time divided by 2. And we get the range from the
phone to the access point. So that's the basic principle. Now, if you want to
calculate position, we have to use a process called
multilateration, and more on that in a minute. Well, the key thing
to think about here is the more ranges you have,
the more constraints you get, and the more accurate
position you can achieve. And if you can use
at least four ranges, then we think you can get
typically an accuracy of one or two meters in most buildings. So why am I telling you
about Wi-Fi RTT today? Why not last year or before? Well, what I want
you to take away is that 2018 is the year
of Wi-Fi RTT in Android. Your takeaways are that we
are releasing a public API in Android P based on the
IEEE 802.11mc protocol. And furthermore,
we're also integrating aspects of this protocol into
the Fused Location Provider, which is the main
location API that people use to put a location on a map. And any time they're on RTT
access points in the vicinity, the accuracy of that
position will be greater. Now, a little bit of
history, the 802.11 standard was ratified in
2016, the end of it. And in early 2017,
the Wi-Fi Alliance started doing interop
between silicon vendors to make sure the chips
followed the protocol. And that's when we started
doing a lot of work to validate how it could
be integrated into Android. And by the fall of
this year, of course, we will release the
API so that all of you can now have access and
build your own applications around that technology. So now diving into
the principles of how Wi-Fi RTT works. So the ranging process starts
with a standard Wi-Fi scan. The phone discovers the access
points which are around. And based on certain
bits which are set inside the beacons
and the probe responses, we can figure out which of those
access points are RTT capable. And the phone chooses one
of those to range too, and it starts by making a
request to the access point. And as a result,
the access point will start a ping-pong
protocol back. The ping that's
sent to the phone is called an FTM, or Fine
Timing Measurement packet. And the pong that's sent
back to the access point is an acknowledgment
of that packet. The timestamps are
recorded at each end. Each device records them. But for the phone to calculate
the total round trip time, it needs to have all
of those timestamps. So the access point sends one
more packet, a third message, which contains the missing two. The phone, then, simply
calculates the round trip time by subtracting the
timestamps from the AP and its own turnaround time
which are the timestamps that it recorded. So that leaves the
time of flight. We multiply by the speed
of light to get distance. We divided by 2. And we get the range
that we care about. Now, it turns out, if you do
this process multiple times, you will, in fact,
get more accuracy. And so that's what the
protocol allows for. It allows for a burst. In Android, we're typically
during a burst of about eight of these events. And as a consequence,
the system can calculate statistics,
so the mean and the variance, which allows
us to more accurately plot a position on a map. And knowing the accuracy also
allows us to calculate a path more accurately as well. So now you have ranges. How do you get a position? So I just want to give
you a feel for how you go about doing this. Now, there's lots of different
mathematical approaches. And I'm just picking
one because it's relatively easy to explain. But this is where the
power of developers comes in for you to figure
out your own way to do it. So if you know a phone is at
a certain range from an access point, that tells you
that it can be anywhere on the circumference of a circle
of that radius, the radius r. And I've written
the circle equation for that circumference
on the right-hand side at center, x1 y1. Now, if you want
to find a position, you've got to constrain it. So if you take four ranges, the
four separate access points, as shown on the diagram
on the right-hand side, you then can see that if
those ranges were accurate, those circles would
intersect at a single point. How do you find that
point programattically? Well, if you write those four
equations out on the left-hand side-- you see the nasty
circle equations, which may be difficult,
but, in fact, it's actually very straightforward. You pick one of them. You subtract it
from all the others. And you end up with a
set of line equations. The squared terms disappear. And those lines are, in fact,
drawn on this diagram as well. And then it's very easy to find
out where two lines intersect. Now, there's one problem
with what I've just told you. And the problem is
that we're assuming the measurements are perfect. In reality, no
measurements are perfect. Everything has error. And there will be no exact
solution to that equation. So let me give you a
more realistic example. So here we have several access
points which we've ranged to. And I've exaggerated
the problem here. And you can see, some of
those circles don't intersect. How do you solve that? Well, in, fact, you do the
same thing as you did before. You subtract the circles. You get the lines. But this time they don't
intersect in a point. They intersect in a polygon. In this case, it's a triangle. And your phone lies probably
somewhere, maximum likelihood in center of that triangle. And then we can
apply some college math, least squares solution,
and get a maximum likelihood. You can find standard packages
which do this on the net. You can then also refine
this position further by repeating this
process, particularly as the phone moves, and then
you can calculate trajectory and use filtering techniques
like common filters and other things. So that's the basic principles. Now, like any new technology,
there are challenges, and so we've experienced
some of these early on. A little robot, which you can
see on the right-hand side, is used by us to measure the
range from the phone which it's carrying to an access point. And it validates that
range against the marks, which are on the floor, which
provide us with ground truth. What we find is that
sometimes there's a constant range calibration
offset, maybe as much as a half a meter. And sometimes also you
see multi-path effects, where the known line-of-sight
path from the access point to the phone is
actually received rather than the line-of-sight path. That one can be solved by
the vendor using something called antenna diversity. But all of these things
are algorithms which the vendors are improving. And basically we need to
go through a, sort of, teething process of
getting rid of these bugs. And Google can help
in this process by providing reference platforms
and reference applications so that vendors can calibrate
their own platforms before you guys even get to use them, which
would be the ideal situation. Now, I've assumed that you want
to start as an early adopter and start using this API. But as we move into the
relatively near future, we expect you to just use
the Fused Location Provider because we're going
to be putting the RTT capability into it. So at the moment,
Fused Location Provider uses GPS when it's available,
cell, signal strength, Wi-Fi, RSSI, and also fuses
with the on-board sensors inertia navigation from
accelerometer and gyro. Now we're adding Wi-Fi
RTT into that mix. And it will increase
the accuracy whenever RTT cable access
points are available. So the one other
thing to remember is that when you were
doing it yourself, you had to know the position
of the access points. With the Fused
Location Provider, we will know those positions
automatically for you. We'll crowdsource
those positions, and so you won't have
to worry about that. And that would make
life a lot easier for you to write applications. So now we're going
to take it up a notch and we're going to give you a
live RTT demo in collaboration with some of our
colleagues in Geo. What I have over here on
the podium is a phone-- let's bring it back. OK, there we go-- which is running an RTT
system in combination with Google Mobile Maps. And what we're
doing is we're using a number of access points,
which are around the room. So a moment ago you saw the blue
boxes which are on the slide. So these were provided
by one of our partners. And you can see them around
the room towards the back, on the side, and also a couple
in the center over here. Now, the thing to bear in
mind is that you would-- this phone, because
we're just in a tent, would normally
receive GPS signals. So we've disabled GPS. You're only using
RTT with this phone. And what I'm going
to do is I'm going to walk around the aisles. And you can see on this
cast that I've already got a plot of where
I'm going to go. So I'm going to
start moving now. I'm going to start going
towards the corner of the stage. And you should see the
blue dot with my little man inside following me. And of course, we expect an
accuracy of one to two meters. And so I'm walking on the aisle. The aisle here is about-- it's about two meters
across, thereabouts. And you can see it's very nicely
following within that accuracy. I think the demo environment
has been very good to us so far. So we're going along. And there's a little bit of lag. It's going around the back here. And we're approaching a
turnaround point, where I'm going to walk up the aisle. And we're rerouting
as I come back to make my path a
little bit shorter. And you can see we're
going very nicely. It's still well within
the one to two meters. And if you had GPS
shown here as well, I mean, typically you would be
expecting to see five meters. But that's, of course, outdoors. And indoors in a
typical building, you're only going to
have indoor location technology such as this. So now I'm approaching
the corner of the stage. And at this point, I'll
hand back over to Wei. Thank you very much. [APPLAUSE] Thank you. To Wei, he's going to tell you
about the details of the API. WEI WANG: Hey,
thanks a lot, Roy. What a great demo. So now you must be very eager
to try Round Trip Time ranging yourself. Let me walk you through
the RTT API in P to see how you can add RTT
in your own application. So as Roy mentioned, RTT
measures the round-trip time between two Wi-Fi devices. So both your mobile phone and
your the access points need to support 802.11mc protocol. And as you saw, RTT can give
you a very fine location, down to one meter-accuracy. So your application
needs to declare access find location permission. And of course, both
location and a Wi-Fi scan need to be enabled
on a mobile device. OK. So how do you know whether
your mobile phone supports RTT In P, we added a new system
feature called Feature Wi-Fi RTT. So you can simply check
whether this returns true on your mobile device. All Pixel Phones
running P [? DB2 ?] and above will support RTT. So how do you know whether
you access points support RTT? As normal, you will
need to do a Wi-Fi scan and get a list of
Wi-Fi scan results. [INAUDIBLE] run through this
list of Wi-Fi scan results and check whether this method
is 802.11mc [INAUDIBLE] return true. This will tell you whether
the access points support RTT. So after you get a list
of RTT-enabled IPs, simply add them to a
scan request builder to build a scan request. RTT is done by Wi-Fi RTT
Manager, which you can simply get by getting the
system service Wi-Fi RTT ranging service. OK, now we're ready
to start RTT ranging. By sending the RT request
to the RTT Manager with a ranging result
callback, RTT will start. Usually, RTT takes no more
than hundreds of milliseconds. And when it finishes, you would
get a list of the information, including the status,
RTT [INAUDIBLE],, the MAC address, which
IP you have just ranged and also, most
importantly, the distance between the mobile phone
and the access point. So here is the list of
the information you can get from RTT Ranging Results. You can get the distance. You can also get the
distance [INAUDIBLE],, deviation which is a [INAUDIBLE]
deviation from multiple ranges and multiple FTMs. And you also get a number of
attempted FTM measurements and number of
successful measurements. So the ratio of
successful measurements over attempted
measurements would give you an idea of how good the Wi-Fi
environment is for RTT ranging. OK. So I mentioned all Pixel
devices will support RTT. How about access points? We're beginning to
[INAUDIBLE] access points supporting 11mc
protocol in production. And we are very excited to let
you know Google Wi-Fi will soon support 11mc protocol. Thank you. [APPLAUSE] By the end of this
year, off the shelf, Google Wi-Fi will have
RTT enabled by default. And worldwide,
we're also beginning to send the
deployment of RTT IPs. South Korea is actually leading
the deployment of RTT IPs. And, of course, this is just the
beginning of the long journey. We're very eager to see
a larger penetration rate of RTT IPs in upcoming years. With that, I'm going
to hand over to Frank to talk about one meter GPS. FRANK VAN DIGGELEN: Thank you. [APPLAUSE] OK, so let's move to the great
outdoors and speak about GPS. I'm going to show you
some basics of GPS, just enough to explain
what's new to the satellites and what's new in the phones
and how you can exploit these changes to get better
location accuracy from GPS when you're outdoors under open sky. So GPS works like this. It sends a code
from a satellite, and the code encodes the
time at the satellite. Then that travels to you through
space and arrives at you. And your GPS receiver
will compare that time with the time in its clock. The difference between those two
tells you how far you are away. It's kind of like you
have a tape measure, where one end's at the satellite. And you're holding the spool. At any moment, you
can look down and read a number, which is the
difference in these two times. If you move further away,
you read a bigger number. If you move a little bit closer,
you read a smaller number. But now the actual GPS tape
measure's kind of special. First of all, it's really long. Secondly, the tick marks
occur only every 300 meters because these bits
of the code occur at a rate of one microsecond. So 1 microsecond times the speed
of light is about 300 meters. So this is like a
tape measure where instead of having all
these inches on here, you only have a mark
every 300 meters. And your GPS
receiver essentially interpolates
between those marks, and there's your
five-meter accuracy. OK. But there's more
to it than that, because how does that
code get through space in the first place? Well, it's carried on a
carrier wave, a radio wave, which for GPS has
a wavelength that is less than 20 centimeters. And your GPS
receiver can measure where you are on this wave. And as long as it
keeps tracking it, it can measure relative
motion with great precision. And this is because the
receiver will measure the phase, and then as you move,
that phase will change. But now what about getting
your absolute location? The trouble with the carrier
phase ruler, if you like, is that it's kind
of like a ruler with very precise markings
on it but no numbers at all, because one wavelength
looks just like the next. So your receiver can
tell you the phase of the wave you're on,
but it doesn't know are you green dot
or the red dot? So how do you
solve that problem? Well, for that, you need to
introduce a new concept, which is GPS reference stations. So these are GPS receivers
at fixed sites measuring the same thing at the same time. They communicate
that data to you. With well-known algorithms,
you can combine this data. And over some
period of time, you can work out where you are
relative to the reference station with great precision,
with this carrier phase precision. Now you know where the
reference station is. So now you know where you
are with great precision. So this concept is not new. This has been in
commercial GPS receivers since the 1980s for surveying. Hence our little surveyor
there holding the GPS antenna on the stick. What is new is the availability
of these carrier phase measurements from phones and
dual-frequency measurements in phones. Right now all of
your smartphones, all smartphones everywhere,
have GPS or GNSS on one frequency band only. It's known as L1. But there's a new
frequency in town. It's called L5. And it's supported by all these
GNSS systems, GPS, Galileo, BeiDou, QZSS, and IRNSS. And the availability
of a second frequency means that you get much faster
convergence to carrier phase accuracy if you're doing
this kind of procedure. And why? Well, we just went
through the ambiguity that you have on a single wave. Well, now look what happens
if you introduce a second wave at a different frequency. Immediately you can disambiguate
because you could not have the same phase on
that second wave on both of those wavelengths. You could not be on
the red dot if you were at the peak of the red wave. And so you can
disambiguate and get much faster convergence
to the very high accuracy that you want. All right, so what
about hardware? Well, in the last few
months, several companies that produce consumer GPS chips
have announced the availability of dual-frequency
L1, L5 GPS chips, both for the automobile market
and for the phone market. And these chips are now being
designed into cars and phones. Now let's talk about the
measurements themselves and the APIs. The phone must support
the GNSS Measurements API. And your app is going to need
access find location permission and location needs to be on. So these are the
basic requirements. So how do you know if a
particular phone supports these measurements? Well, at a high level, you can
just go to a website that we maintain, g.co/gnsstools. It's part of the
Android Developers site. And there's just
a table there that lists phones that support
the GNSS measurements and also which
characteristics they support. So it'll tell you which phone
support the measurements and which of those support the
carrier phase measurements. Programmatically, you
do this as follows. You need a method
onStatusChanged. And it will return an
integer that tells you the capability of the phone,
either if the phone just does not support the
measurements at all, or if they support it,
but location is off, or if they support it,
and location is on. In that last case,
you're good to go. So now let's get into
some details of the APIs. The most relevant methods for
what we're talking about here are the following three. There's getConstellationType,
which tells you which of the different
GNSS constellations a particular
satellite belongs to. There's
getCarrierFrequencyHertz, which tells you whether you're
on the L1 or the L5 band for a particular signal. And then most
importantly, there's getAccumulatedDeltaRangeMeters,
which is how far along that wave
the receiver has tracked you since it began
tracking the signal. And then there's something
else that I need to explain, which is duty cycling. So right now, when you're
navigating with your phone and you see the blue
dot moving along, for example, maybe when you
navigated here this morning, you might think that the
GPS is on continuously. And it's actually not. What's happening in the phone
is that GPS will, by default, be on for a fraction of a second
and then off for the remaining fraction of a second
and then repeat. And this is to save battery. And so you perceive that
the GPS is on all the time because the blue dot will
move along continually. But actually, it's duty
cycling internally. Now, for this carrier
phase processing, you have to continually
track the carrier wave because, remember, the
carrier wave is the ruler with no numbers on it. So if the GPS was on and your
receiver measured your phase and you get the data from
the reference station, you'd start processing. If the GPS then goes off
for a fraction of a second, well, now you've
lost where you were. It'll start again. You're re-acquire. You'll be a different
phase on the reacquisition. You'll start again. Well, you'll never solve the
problem, [INAUDIBLE],, right? You need the tape
measure to stay out, and you need to process. And to do that, you need
to disable duty cycling. And you can do that in Android
P with a developer option, which I'll talk about some
more in a minute. So now some details of the API. What I've shown
here on the right is a screenshot of an
application that we've put out. It's called GNSS Logger. And this is enables you to
log the raw measurements in the phone. Now, the nice thing about this
app, it's a reference app. The code is open source and
available to you on GitHub. So when you build
your app, please, you could make use of our code. And when you do build an app
that needs raw measurement, you will need the Android
Location Manager API with the method registerGNSSMeas
urementsCallback. And this method requires you to
pass a GNSS measurements event callback, shown here. You construct this
callback and then override the method onStatusChanged. And that will give
you the integer status that we discussed to tell you
if measurements are supported. If they are, you then
override the method onGNSSMeasurementsReceived. And this allows you to
receive a GNSS measurement event every epoch, for
example, every second. And this event
gives you the values we've been talking about,
constellation type, carrier frequency, and
accumulated delta range. Now for duty cycling,
that's a developer option, so you access that through the
Developer Page on your phone, as you see there on
P. And this allows you to disable the duty cycling. Now, keep in mind, this
introduces a trade-off between getting the continuous
measurements and battery life. There will be an
impact on battery life. How much? Well, even when GPS
is on continually, it'll use less than 20% of
the power that screen on uses. So that gives you a
feel for the magnitude. Now, this is a developer
option precisely because it's a trade-off
in battery life. And we're very concerned
about maximizing battery life. But if you and we
together can prove that there's value in this
option and people want it, then it will be upgraded
to a fully supported API in the future. So here's a block diagram that
shows the basic architecture that we expect if you implement
an app for high accuracy. Down on the bottom of the
block diagram on the left, you've got the GPS, GNSS chip. The GNSS measurements
come up through the APIs, as we've just described. And then your app lives at the
top in the application layer. You're going to need access
to a reference network to get the data that the
reference stations are tracking. There are publicly available
reference networks. I've listed one down at the
bottom, the International GNSS Service, igs.org. And you can get
data from them free. Then you need to process that
data in some kind of position library. And that does all this
carrier phase processing. And that too is available
as open source code. There's another
example down there. Rtklib.org has an
open source package for precise positioning. And then you're good to go. Now, I mentioned that
dual frequency gives you a much faster convergence
to the high accuracy. But you don't have to wait
until the dual frequency phones come out. You can start doing this
with single-frequency phones. And here's an example of
someone who's already done that. This is an app created by
the French Space Agency. And they're doing exactly
what we show on the block diagram on the left. And they're achieving
sub-meter to accuracy after a few minutes
of convergence. Here's some more
external analysis that's been done in a similar way. This is from a paper
called "Positioning With Android GNSS." This is using one of
those chips that I showed you, the chip that
goes in cell phones that does dual frequency. And what's been shown here
is the cumulative results over many different
starts of the GPS. And what you see is
that most of the time the accuracy is
better than a meter. You see that on the vertical
axis, which is 0 to 1 meters. And accuracy gets to better than
a meter in less than one minute and then continues to converge
as long as the phone continues to track that carrier
phase continuously. Here's another similar
but different paper. This is using one of the
chips that's meant for cars. And so it was tested in a
car, driving around that track there. And what the plot
here is showing is the accuracy after
the initial convergence while the car was driving. So you see with GNSS alone,
the accuracy is 1 to 2 meters. And with this carrier
phase processing, it's at a couple of decimeters. So for you to build this,
what are you going to need? Well, of course you need the
device location to be enabled, and your app has to have
location permission. So that's going to
come from the user. You need the basic
GNSS measurements. That's been available
since Android N. You also need this
continuous carrier phase I've been talking about,
and that's available in P with the developer option. It would be nice to have dual
frequency for fast convergence, and that's coming soon. You need a reference network,
such as the one I already mentioned. There are also commercial
reference networks out there and commercially
available software to do the same thing. But I recommend you
start with the free stuff and go from there. And then finally,
there's the app from you. So in summary, everything
we've been showing you here, we have indoor and
outdoor technology that's been evolving kind of in
parallel, in each case, we have a new technology. And Android P gives you
something to access it. Let's talk about indoors again. The new technology is Wi-Fi
Round Trip Time and Round Trip Time enabled access point. We give you the public API
to access these measurements. But you need access
point infrastructure. Now, this is where some of
you can do this this year. Because if you have a customer
who owns or controls a venue, they can upgrade their
access point, sometimes just a firmware upgrade. And then you have
the infrastructure. Android P comes out
later this year. And you can implement
something like what Roy just demoed and have indoor
navigation or many other apps. For example, someone
goes in a store. Where's the milk? You can make the world a
better place for all of us by saving us from the tyranny
of having to ask directions from strangers. [APPLAUSE] OK. And if you're not one of those
people who has access to this now, in a few years the
infrastructure will naturally evolve as access points
upgrade to Round Trip Time, and this will be available
from Fused Location Provider, as Roy said. Now, outdoors, OK, for
this carrier phase process, it's not just outdoors,
but outdoors with open sky. And what do you need? Dual frequency and
continuous carrier phase. And we give you the API
and the developer option to make use of that. You will need reference
station access, as I mentioned. And then applica--
well, what can you do outdoors with open sky? Well, we already mentioned
the traffic example. And there's many
other examples that readily come to mind where
existing GPS accuracy doesn't cut it. For example, geocaching, where
people go look for treasures, it would be nice to
have one-meter accuracy. Precision sports monitoring--
imagine a snowboarder who wants to measure her tracks
very precisely after the fact. Five meter's not good enough. One meter would be great. Speaking of sports,
there are more and more drone apps where you can follow
me, and a drone will fly along and video you. Well, it would be nice
if it videos you and not the person next door to you. And I'm sure there
are hundreds of apps, and you're probably
thinking of some right now, and that's the whole point. We want you to do that
and you and us together bend the arc of technology
history closer to the present. And I'm really looking forward
to next year to see some of you back here and see
what you've created. And so finally, I want to leave
you with a couple of pointers. When you build location apps,
please build great location apps. You must have user trust. Please provide the user with
transparency and control. You're going to have to ask for
location permissions for this. Explain to them what you're
doing, how it benefits them. When things go wrong, make
your app recover gracefully. If these measurements are
unavailable for some moment or something goes wrong, you
can fall back to Fused Location Provider location. So think about that. And finally, respect the
battery life trade-offs that we discussed. So I must remind you to
fill out your surveys, please, at that site. And as I mentioned, we'll be
available outside the door here for any questions. So from all three
of us, thank you. [MUSIC PLAYING]
If I enter location “bedroom” then hue lights trigger “mood” mode.