FABIAN TAMP: Hi, I'm Fabian.
I'm a software engineer on the Android and Google Maps teams.
My team's been working on getting the Google
Apps that you know and love into your car.
And we're really excited about Android Auto,
because it combines the best of the hardware in your car
with the upgradability, connectivity,
and personalization of your Android smartphone.
Your car is by far the most complicated accessory
that we've ever attached to an Android phone
before, with a vast number of sensors
and some serious audiovisual capabilities.
Let's start with the Android Auto protocol,
which enables your phone to talk to a car.
One of the biggest features of the architecture
is that Android apps and services run entirely
on your phone whilst being controlled using your car.
We run the applications into a compressed video
stream and audio streams and send them
across to the head unit.
Typically, cars are kept for longer
and get software updates less frequently than smartphones.
So by shifting the processing and rendering over
to the phone, we can take advantage of the latest
mobile technology and keep your Android Auto experience
up-to-date over the life of your car.
We wanted to make the Android Auto protocol easy to integrate
with cars, so we provide manufacturers with a portable
C++ library that runs on Linux, Android,
and QNX within the car's head unit.
The core metaphor that the Android Auto protocol uses
is [? one ?] to prioritize channels.
Different channels are open for the different aspects
of your car that the phone needs to communicate with.
Channels are open for audio, for display data, user input
and location data, like GPS and wheel speed.
These channels multiplex together
over the USB connection, which allows
us to give priority to the channels that affect
the experience the most.
We've built this protocol on top of the Android Open Accessory
protocol, but designed it to be transport agnostic.
So we can open it up to other forms of connectivity,
such as Wi-Fi Direct, in the future.
To format data, we use protocol buffers extensively.
Protocol buffers are an open source Google technology
that makes it really convenient to add new features
in the future whilst retaining backwards compatibility.
A key design goal for us was to make
Android Auto feel like it fits in with the rest of your car.
In version one, we've got support
for different input methods, specifically for touch screens
and for hard rotary controllers, in a similar way
to how the standard Android UI supports both touch
and controller modes.
We're also supporting turn instructions
on instrument clusters that can display them and integrate
with the buttons on your steering wheel,
where they're available.
We also support routing audio to different speakers
within the car, based on the type of audio.
For example, navigation instructions in Google
Now can be targeted just to the driver,
whilst music gets played over all the speakers in the car.
There's invariably going to be times when you're listening
to the radio and want to ask Google Now to read a message,
for example.
So the car and the phone negotiate audio focus
in a similar way to how apps negotiate on an Android phone.
The car has the ultimate say on when Android Auto is visible
or playing audio, so it can ensure
that safety critical notifications
and the reversing camera, for example, get priority.
On the phone side, we're building the Android Auto code
into Google Play services, so your experience
can be kept up-to-date.
The Android Auto system uses the Android virtual display API
extensively.
Let's dive in and take a look at the rendering system.
In Android Auto, rendering occurs across app process
boundaries onto a common surface for the car screen.
We use XML to define a layout of windows
to be rendered by different apps.
There is a window for the navigation
rail, for the main content area, for the notification area,
and one for the search space as well.
Each of these windows is actually
an android.view.TextureView.
The Android Auto service takes the TextureViews back
into SurfaceTexture, wraps it in a surface object,
and passes it to the client process over a [? binary ?]
interface.
Within the client library, a private virtual display
is created from that surface, and the applications UI
is inflated into the virtual display.
We then render the XML layout to compress frames using
another virtual display, backed by the phone's hardware video
encoder, and send the output to the head unit.
There's two core principles behind this architecture.
The first is flexibility.
Using TextureViews in an XML layout
allows us to lay out the windows arbitrarily.
That means we can take advantage of the full Android layout
system, including animations.
The second is security and stability.
By keeping clients rendering in their own process,
we can isolate problems from the rest of the system and ensure
the apps don't have access to any data that they shouldn't.
Also, we want to make sure that existing apps on the phone
can take advantage of the improved location signals that
are available from the car.
So we've rolled these signals into Google Play Services'
Fused Location Provider.
The Fused Location Provider combines the different location
technologies available on an Android smartphone--
cellular signal, Wi-Fi, and GPS--
into a single high-level API that allows developers
to specify accuracy requirements and update frequencies,
instead of dealing with individual location sources.
By adding location sources from the car,
we're enhancing the accuracy of location data using APIs
that apps are already using.
So now, I'm going to talk to you about how
we've used Android Auto and the Google Maps app
to enhance the in-car experience.
First of all, Google Maps is so much easier
to use for navigation when it's on a large screen, front
and center, instead of on a tiny phone
screen in a mount on your dashboard.
We've redesigned Maps to work beautifully
in a horizontal aspect ratio, and optimized the UI for use
in car-- for example, by minimizing task completion
times and making the touch targets easy to hit.
One of the biggest advantages of automotive Google Maps
is that using the Fused Location Provider,
we can use the GPS data from your car, which vastly improves
the location quality when city driving, for example.
We can also use your car's compass, gyroscopes, wheel
speed, and other positioning sensors to work out
which way you're facing, and exactly how far you've
traveled through that tunnel.
All of this allows us to give you much more accurate
driving directions to get you to your destination with less
hassle.
So that's an overview of how Android Auto uses
the technology on your Android phone and in your car
together to create a great driving experience.
We're really excited for the potential
that Android Auto has to make in-car entertainment
and navigation more seamless, connected, and safe.
Thanks for watching.