[MUSIC PLAYING]
JAY YOO: Hi, I'm Jay.
STAV RAVIV: And I'm Stav.
We're both engineers on the Android Auto team,
and today we'll be talking about bringing your apps to cars
using the Car App Library.
When we talk about apps for cars,
we're really talking about two things.
The first is Android Auto, which enables
users to connect their Android phones to compatible vehicles
and use their favorite apps and services right
on the car's display.
The second is Android Automotive OS, where Android runs directly
on the car, powering the in-car infotainment system
as well as giving drivers access to their favorite apps
without a connected device.
And lastly, for Android users without a compatible car,
we offer Google Assistant driving mode,
but we won't be focusing on that today.
Android Auto continues to see strong momentum.
It's now available in more than 100 million cars globally,
with support from nearly every major car manufacturer.
Android Automotive OS is seeing great traction as well.
By the end of 2021, Automotive OS with Google built-in
will be available in more than 10 car models
from Volvo, General Motors, and Renault,
and we recently announced partnerships
with Ford and Honda to bring this experience
to millions of future vehicles.
These growing platforms represent
an amazing opportunity for you as a developer,
and that's where the Car App Library comes in.
The Car App Library allows you to write your code once
and make your app available across both Android Auto
and Android Automotive OS.
The interface is designed with driver safety
in mind, which in turn helps you build
apps that are safer without needing to become
an expert on driver safety.
Voice is an important form of input in cars,
so apps built with the Car App Library
enable you to have seamless integrations with voice
assistants.
And version 1.1.0 is now in beta,
which means you can go to production with the most
up-to-date APIs.
Before we jump in, it's important to note
that unlike phones, where you get full access to the screen,
in cars, we are providing you with pre-defined templates that
were carefully built with driver safety considerations.
Our approach is to expose relevant templates to you
according to your app's category,
and over time, build a cohesive library that allows
you to build what you want.
We are starting this journey with navigation, parking,
and charging apps.
Messaging and media apps should keep
using existing Android APIs.
If you're interested in bringing your apps to cars
but don't fall into any of these categories,
please reach out to us and let us
know what you'd like to see in the Car App
Library in the future.
Now that we know what the Car App Library can offer you,
let's have a look at the architecture.
When your app is launched in the car,
a host application running on either Android Auto
or Automotive OS will connect to a CarAppService
that you will extend.
In your CarAppService, you will override onCreateSession,
which returns a session instance corresponding
to the current connection to the host.
The session is responsible for returning the screen instance
to use the first time the app is started
by overriding onCreateScreen.
Then, each of your screen classes
will implement onGetTemplate, which
returns a template object representing
the state of the UI to display in the car screen.
The template will be then fed back
to the host application, which will render the UI for you.
With Android Auto, you will find the same look
and feel across all vehicles, and with Android Automotive OS,
you will find the rendered UI influenced
by OEM customizations so your app will
feel like it belongs in that specific car
without any extra effort on your part.
As I mentioned previously, when using the Car App Library,
you need to declare a category for your app
out of either navigation, charging, or parking, which
will give you access to the corresponding templates
for that category.
All apps have access to the top seven templates,
while navigation and parking and charging apps
have specific templates for their use case.
Again, please do let us know what templates
and categories you'd like to see in the future.
Now, Jay will walk you through the code
and show you an example of a simple car app.
JAY YOO: In this section, we will
learn about the Car App Library by building a simple HelloWorld
app.
We start with the code structure.
Our code base has four components.
The first is our phone app component,
where the code and resources needed for the phone
app will be placed.
Then, we have the common car app component
that contains all the car app code and resources.
This component will be shared between the Android Auto
and Automotive OS build targets.
Next, we have the Android Auto and Automotive OS components,
which just contain the AndroidManifest
and the build.gradle files.
With this structure in mind, let's jump into the code.
Let's define the dependencies in our build.gradle files.
For our app, we will depend on the 1.1.0 beta O1
version of the Car App Library.
These are the dependencies for the Android Auto build target.
We have the shared Car App Library dependency, as well as
the Android Auto specific dependency.
These are the Automotive OS dependencies.
Notice that the shared library dependency stays the same,
but now, we have the Automotive OS specific dependency.
After setting the dependencies, we
can write the main car app logic that works in both Android Auto
and Automotive OS.
First, we create our CarAppService class.
This class is the main bridge of communication
between our app and the host.
In onCreateSession method, we return
a HelloWorldSession object, which we will go over soon.
In our service, we also create a host validator
to check if the host that binds to our service can be trusted.
We use the default host whitelist here,
but you can add new hosts if needed.
Next, we create HelloWorldSession.
Session is the object that returns the first screen
to be shown when the app is opened in the car screen.
Here, we return HelloWorldScreen, which we
will revisit in later slides.
Session also receives intents as well as callbacks on lifecycle
and configuration changes.
Next, we create HelloWorldScreen.
A screen object contains the template and the metadata
that we want to show in the car screen.
We construct and return a template object
in onGetTemplate method.
Also, screen has access to the ScreenManager object
that you can use to push and pop screens.
We will see how ScreenManager works in the next slide.
We will create a very simple list template
with one row of text.
First, we create the row object.
When the user taps on the row, we
use the ScreenManager to push the next screen.
Then, we create the list for the row and create a list template.
For the next few slides, we will show a few things
you can do with the library.
For a comprehensive walkthrough of the library features,
please refer to the Car App Library developer
documentation.
Here, when the user taps on the row, we update the row text.
The invalidate call notifies the host
that the screen needs to be updated.
In order to show a toast, you can use the CarToast class,
as shown here.
The usage pattern is the same as the regular Toast class.
To request permissions, such as the location permission,
you can use carContext.requestPermissions
method.
In Android Auto, calling this method
will show the permission request pop-up in the phone screen.
In Automotive OS, the pop-up will
be shown in the car screen.
In the callback, you will have the list
of approved and rejected permissions
that you can act on.
To send a notification, construct a normal notification
object, optionally extended with CarAppExtender,
and send it with CarNotificationManager.
In Android Auto CarAppExtender allows
you to differentiate the notification style
and content between the phone and the car screen.
In both Android Auto and Automotive OS,
when the notification is displayed in the car screen,
any content set in the CarAppExtender
will override the equivalent notification content.
Congratulations for finishing the code section.
We're almost there.
In the next section, we will go over the Manifest files
for Android Auto and Automotive OS build targets.
In the Android Auto Manifest file,
we add this metadata in our application element.
This metadata allows Android Auto to identify your app
as a car app.
We also place the corresponding XML file
in our Resources directory.
Next, we define the minimum car API level for our app.
Higher minimum API level means that we can use the latest
library features, but some hosts may not support the API level.
When that happens, the host will display a message
to update the host app.
Since we are only using basic library features,
we can leave it at one.
Then, we declare our CarAppService
in the application element.
Notice that, in the intent-filter element,
we declare our service as a CarAppService
and also our car app's category as a parking app.
The category declared here will later
be used in the Play Store app review process
to check if our app meets the category-specific car app
quality guidelines.
The Automotive OS Manifest looks somewhat different.
Here, we declare various features
that we are and are not using in our car app.
Declaring features such as Wi-Fi and camera as false
is important.
Otherwise, our app may not show up
in cars that do not support such features.
As we did for Android Auto, we add the metadata
so Automotive OS can recognize our app as a car app
and also declare the minimum API level.
Again, our car service is declared in the same way.
Lastly, we declare an activity specific to Automotive OS.
Notice the distractionOptimized metadata.
This is needed for our app to work while the user is driving.
That is it.
Now you can build an app that runs in both Android Auto
and Automotive OS.
In addition to the library features,
your car app can benefit from voice integration.
Voice integration allows the driver
to interact with your app without being distracted
and can also extend your app's functionality in many ways.
You can receive intents from the Voice Assistant
in your session objects onCreateScreen
and onNewIntent methods.
If you're building a navigation app and support navigation
intents, you may receive intents from the voice queries.
We will show you how to handle this intent in the next slide.
In addition, your app may receive built-in and custom
intents from Android App Actions,
just like your phone app.
For more information, please refer to the link in the slide.
Here, we are handling the intent that we
receive in onNewIntent method.
The intent received in onCreateScreen method
can be handled in the same manner.
If the intent action is CarContext.ACTION_NAVIGATE,
we parse the query string, which we pass to the constructor
of MyNavigationScreen that we push.
See the car context developer documentation
for the exact format of the intent.
So far, we wrote our HelloWorld app
with the common code, dependencies,
and the Manifest files, and integrated with the Voice
Assistant.
Now is the time to see our app in action.
In the next section, we will explain
how to run a car app in Android Auto and Automotive OS
emulators.
The link in the slide has instructions
on how to download and run the emulators in Android
Auto and Automotive OS.
Make sure you build and install your car app's Android Auto
build target on the phone to run it in the desktop head unit.
Similarly, build and install Automotive OS build target
in automotive emulators.
When you run your app in the emulators,
you can also see the cluster display,
which may show navigation or other relevant information.
Also, you can test the voice commands in the emulators
if your app is integrated with the Voice Assistant.
This last section is about publishing your app.
The process is very similar to the regular app publishing
process, so we will only note the differences.
To submit your car app in the Play Store
console, click Setup, Advanced Settings, and Release Types.
Select Android Auto or Android Automotive OS,
depending on your car app's build target.
When uploading your APK, select Standard Release Type
for Android Auto and Automotive OS Only for Automotive OS.
After submission, there may be additional reviews based
on car app quality guidelines.
When the review is complete, you will receive a notification
email with the result. I hope you
will feel confident about building car apps
and reaching out to millions of users
on the road that need your app.
To help you make great apps, we are working hard
to add more templates and categories.
We're also working on paid app and in-app purchase flows
for Automotive OS car apps.
Please reach out to us and let us
know what you would like to see in the Car App
Library in the future.
Lastly, here are resources that contain
more comprehensive and detailed information
about building a car app.
Thanks for watching.
[MUSIC PLAYING]