Android Automotive OS allows users to install apps in the car. In order to reach users on this platform, you need to distribute a driver-optimized app that is compatible with Android Automotive OS. You can re-use almost all of the code and resources in your Android Auto app, but you must create a separate build that meets the requirements on this page.
Development overview
Adding Android Automotive OS support is simple and only requires a few steps:
- Enable automotive features in Android Studio
- Create an automotive module
- Update your gradle dependencies
- Add settings or sign-in activities (Optional)
Design considerations
Android Automotive OS takes care of laying out the media content that it receives from your app's media browser service. This means that your app doesn't draw the UI and your app does not start any of your activities when a user triggers media playback.
If you are implementing Settings or Sign-in activities, these activities must be vehicle-optimized. You should refer to the Design guidelines for Android Automotive OS while designing those areas of your app.
Set up your project
You need to set up several different parts of your app's project to enable support for Android Automotive OS.
Enable automotive features in Android Studio
Use Android Studio 4.0 or higher to ensure that all Automotive OS features are enabled.
Create an automotive module
Some components of Android Automotive OS, such as the manifest, have platform-specific requirements, so you need to create a module that can keep the code for these components separate from other code in your project, such as the code used for your phone app.
Follow these steps to add an automotive module to your project:
- In Android Studio, select File > New > New Module.
- Select Automotive Module, then click Next.
- Provide an Application/Library name. This is the name that users see for your app on Android Automotive OS.
- Provide a Module name.
- Adjust the Package name to match your app.
Select API 28:Android 9.0 (Pie) for the Minimum SDK, and then click Next.
All cars that support Android Automotive OS run on Android 9 (API level 28) or higher, so selecting this value targets 100% of cars that use Android Automotive OS.
Select Add No Activity, and click Finish.
After creating your module in Android Studio, open the AndroidManifest.xml
in
your new automotive module:
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
package="com.example.media">
<application
android:allowBackup="true"
android:icon="@mipmap/ic_launcher"
android:label="@string/app_name"
android:roundIcon="@mipmap/ic_launcher_round"
android:supportsRtl="true"
android:theme="@style/AppTheme" />
<uses-feature
android:name="android.hardware.type.automotive"
android:required="true" />
</manifest>
You'll notice some standard app information in the application
element, but there's also a uses-feature
element that declares support for Android Automotive OS. Also note that there
are no activities declared in the manifest.
If you implement a Settings or Sign-in activities, add them here. These activities are triggered by the system using explicit intents and are the only activities that should be declared within the manifest for your Android Automotive OS app.
After adding any Settings or Sign-in activities, complete your manifest file by
setting the android:appCategory="audio"
attribute in the application
element
and adding the following users-features
elements:
<manifest xmlns:android="http://schemas.android.com/apk/res/android" package="com.example.media"> <application android:allowBackup="true" android:appCategory="audio" android:icon="@mipmap/ic_launcher" android:label="@string/app_name" android:roundIcon="@mipmap/ic_launcher_round" android:supportsRtl="true" android:theme="@style/AppTheme" /> <uses-feature android:name="android.hardware.type.automotive" android:required="true" /> <uses-feature android:name="android.hardware.wifi" android:required:="false" /> <uses-feature android:name="android.hardware.screen.portrait" android:required:="false" /> <uses-feature android:name="android.hardware.screen.landscape" android:required:="false" /> </manifest>
Explicitly setting these features to not required ensures that your app doesn't conflict with available hardware features in Automotive OS devices.
Declare media support for Android Automotive OS
Use the following manifest entry to declare that your app supports Android Automotive OS:
<application>
...
<meta-data android:name="com.android.automotive"
android:resource="@xml/automotive_app_desc"/>
...
</application>
This manifest entry refers to an XML file that declares what automotive
capabilities your app supports. To indicate that you have a media app, add an
XML file named automotive_app_desc.xml
to the res/xml/
directory in your
project. This file should include the following content:
<automotiveApp>
<uses name="media"/>
</automotiveApp>
Intent filters
Android Automotive OS uses explicit intents to trigger activities in your media
app. The manifest file should not contain any activities that have
CATEGORY_LAUNCHER
or ACTION_MAIN
intent
filters.
Activities like the one in the following example usually target a phone, or some other mobile device. These activities should be declared in the module that builds the phone app, not in the module that builds your Android Automotive OS app.
<activity android:name=".MyActivity">
<intent-filter>
<!-- You can't use either of these intents for Android Automotive OS -->
<action android:name="android.intent.action.MAIN" />
<category android:name="android.intent.category.LAUNCHER" />
<!--
In their place, you can include other intent filters for any activities
that your app needs for Android Automotive OS, such as settings or
sign-in activities.
-->
</intent-filter>
</activity>
Update your gradle dependencies
We recommend that you keep your media browser service in a separate module that you share between your phone app and your automotive module. If you're using this approach, you need to update your automotive module to include the shared module, as shown in the following snippet:
my-auto-module/build.gradle
buildscript { ... dependencies { ... implementation project(':shared_module_name') } }
Configure your MediaBrowserService
If your app does not already have a MediaBrowserService
, start here.
You must also allow both the Google Assistant and
Android Automotive OS to connect to your MediaBrowserService
using the onGetRoot()
method.
If you choose to grant access to specific package names, note that the Google
Assistant has a new package name
for Android Automotive OS. Also, the signature of the Android Automotive OS
system app that connects to your MediaBrowserService
might be different
depending on the make and model of a car, so you should allow connections from all
system apps in your onGetRoot()
method. For an example of how to do this, see
isCallerKnown
property in the Universal Android Music Player sample app on GitHub.
Build your content hierarchy
Your content should be sorted into at most four
browsable
first-level children of the root media item returned from your onGetRoot()
method. These media items display as navigation tabs in Android Automotive OS.
Each tab must also have an associated label and monochrome (black or white)
vector icon. Keep labels as short as possible to avoid truncation.
You can apply content styles to adjust how your content displays.
Display media artwork
Artwork for media items must be passed as a local URI either using
ContentResolver.SCHEME_CONTENT
or ContentResolver.SCHEME_ANDROID_RESOURCE
,
This local URI must resolve to either a bitmap or a vector drawable in the
application’s resources. Android Automotive OS retrieves the URI from one of the
following MediaMetadata
values:
Here is an example of how to do this:
Download your file (in the following code snippet it is done with Glide).
Kotlin
val artFile = glide.downloadOnly() .load(imageUri) .submit() .get()
Java
File artFile = glide.downloadOnly() .load(imageUri) .submit() .get()
Build a
content://
URI for the file.Kotlin
fun File.asAlbumArtContentURI(): Uri { return Uri.Builder() .scheme(ContentResolver.SCHEME_CONTENT) .authority(AUTHORITY) .appendPath(this.path) .build() }
Java
public static Uri asAlbumArtContentURI(File file) { return Uri.Builder() .scheme(ContentResolver.SCHEME_CONTENT) .authority(AUTHORITY) .appendPath(file.getPath()) .build() }
Make the file accessible in the
ContentProvider.openFile()
method.Kotlin
override fun openFile(uri: Uri, mode: String): ParcelFileDescriptor? { val context = this.context ?: return null val file = File(uri.path) if (!file.exists()) { throw FileNotFoundException(uri.path) } // Only allow access to files under cache path val cachePath = context.cacheDir.path if (!file.path.startsWith(cachePath)) { throw FileNotFoundException() } return ParcelFileDescriptor.open(file, ParcelFileDescriptor.MODE_READ_ONLY) }
Java
@Nullable @Override public ParcelFileDescriptor openFile(@NonNull Uri uri, @NonNull String mode) throws FileNotFoundException { Context context = this.getContext(); File file = new File(uri.getPath()); if (!file.exists()) { throw new FileNotFoundException(uri.getPath()); } // Only allow access to files under cache path String cachePath = context.getCacheDir().getPath(); if (!file.getPath().startsWith(cachePath)) { throw new FileNotFoundException(); } return ParcelFileDescriptor.open(file, ParcelFileDescriptor.MODE_READ_ONLY); }
Configure your PlaybackState
Compared to phones, cars are frequently stopped and restarted. You should keep
track of a user’s listen state, such as the last played media item, the
PlaybackState
, and Queue
, so that when you receive a resume request, the
user can automatically pick back up where they left off. Note that this does not
mean you should automatically start playback. See the initial PlaybackState
guidance for more information.
Custom actions
If you add custom playback actions, you must fulfill the following requirements:
- Provide different assets for relevant states of custom actions as vector drawables.
- Do not override standard actions (Play, Pause, Stop, Skip to next, Skip to previous) with custom actions that provide the same behaviors.
Implement settings and sign-in activities
In addition to your media browser service, you can also provide vehicle-optimized Settings and Sign-in activities for your Android Automotive OS app. These activities allow you provide app functionality that isn't included in the Android Media APIs.
You should only implement these activities if your Android Automotive OS app needs to allow users to sign in or specify app settings. These activities aren't used by Android Auto.
Activity workflows
The following diagram shows how a user interacts with your Settings and Sign-in activities using Android Automotive OS:
Figure 1. Settings and sign-in activity workflows
Add a settings activity
You can add a vehicle-optimized settings activity so that users can configure settings for your app in their car. Your settings activity can also provide other workflows, like signing in or out of a user's account or switching user accounts. Remember that this activity is only triggered by an app running on Android Automotive OS. Phone apps connected to Android Auto do not use it.
Declare a settings activity
You must declare your settings activity in your app's manifest file, as shown in the following code snippet:
<application>
...
<activity android:name=".AppSettingsActivity"
android:exported="true"
android:theme="@style/SettingsActivity"
android:label="@string/app_settings_activity_title">
<intent-filter>
<action android:name="android.intent.action.APPLICATION_PREFERENCES"/>
</intent-filter>
</activity>
...
</application>
Implement your settings activity
When a user launches your app, Android Automotive OS detects the
settings activity that you declared and displays an affordance, such as an icon.
The user can tap or select this affordance using their car's display to navigate
to the activity. Android Automotive OS sends the ACTION_APPLICATION_PREFERENCES
intent that tells your app to start your settings activity.
The rest of this section shows how you can adapt code from the Universal Android Music Player (UAMP) sample app to implement a settings activity for your app.
To begin, download the sample code:
# Clone the UAMP repositorygit clone https://github.com/android/uamp.git
# Fetch the appropriate pull request to your local repositorygit fetch origin pull/323/head:NEW_LOCAL_BRANCH_NAME
# Switch to the new branchgit checkout NEW_LOCAL_BRANCH_NAME
To implement your activity, follow these steps:
- Copy the
automotive/automotive-lib
folder into your automotive module. - Define a preferences tree as in
automotive/src/main/res/xml/preferences.xml
. Implement a
PreferenceFragmentCompat
(seeSettingsFragment.kt
in UAMP) that your settings activity (seeSettingsActivity.kt
) will display. See the Android Settings guide for more information.
As you implement your settings activity, refer to these best practices for using some of the components in the Preference library:
- Your app should have no more than 2 levels of depth below the main view in your settings activity.
- Do not use a
DropDownPreference
. Use aListPreference
instead. - Organizational components:
PreferenceScreen
- This must be the top level of your preferences tree.
PreferenceCategory
- Used to group
Preference
objects together. - Should have a
title
.
- Used to group
- All of the following components should have a
key
andtitle
and may have asummary
and/oricon
:Preference
- Customize the logic in the
onPreferenceTreeClick()
callback of yourPreferenceFragmentCompat
implementation.
- Customize the logic in the
CheckBoxPreference
- May have
summaryOn
orsummaryOff
instead ofsummary
for conditional text.
- May have
SwitchPreference
- May have
summaryOn
orsummaryOff
instead ofsummary
for conditional text. - May have
switchTextOn
orswitchTextOff
.
- May have
SeekBarPreference
- Should have a
min
,max
, anddefaultValue
.
- Should have a
EditTextPreference
- Should have
dialogTitle
,positiveButtonText
, andnegativeButtonText
. - May have
dialogMessage
and/ordialogLayoutResource
.
- Should have
com.example.android.uamp.automotive.lib.ListPreference
- Derives mostly from
ListPreference
- Used to display a single-choice list of
Preference
objects. - Must have an array of
entries
and correspondingentryValues
.
- Derives mostly from
com.example.android.uamp.automotive.lib.MultiSelectListPreference
- Derives mostly from
MultiSelectListPreference
- Used to display a multiple-choice list of
Preference
objects. - Must have an array of
entries
and correspondingentryValues
.
- Derives mostly from
Add a sign-in activity
If your app requires a user to sign in before they can use your app, you can add a vehicle-optimized sign-in activity that handles signing in and out of your app. You can also add sign-in and sign-out workflows to a settings activity, but you should use a dedicated sign-in activity if your app cannot be used until a user signs in. Remember that this activity is only triggered by an app running on Android Automotive OS. Phone apps connected to Android Auto do not use it.
Require sign in at app start
To require a user to sign in before they can use your app, your media browser service must do the following things:
- In your service's
onLoadChildren()
method, send a null result using thesendResult()
method. - Set the media session's
PlaybackState
toSTATE_ERROR
using thesetState()
method. This tells Android Automotive OS that no other operations can be performed until the error has been resolved. - Set the media session's
PlaybackState
error code toERROR_CODE_AUTHENTICATION_EXPIRED
. This tells Android Automotive OS that the user needs to authenticate. - Set the media session's
PlaybackState
error message using thesetErrorMessage()
method. Because this error message is user-facing, the message must be localized for the user's current locale. Set the media session's
PlaybackState
extras using thesetExtras()
method. Include the following two keys:android.media.extras.ERROR_RESOLUTION_ACTION_LABEL
: A string that is displayed on the button that begins the sign-in workflow. Because this string is user-facing, it must be localized for the user's current locale.android.media.extras.ERROR_RESOLUTION_ACTION_INTENT
: APendingIntent
that directs the user to your sign-in activity when the user taps the button referred to by theandroid.media.extras.ERROR_RESOLUTION_ACTION_LABEL
.
The following code snippet shows how your app can require the user to sign in before using your app:
Kotlin
val signInIntent = Intent(this, SignInActivity::class.java) val signInActivityPendingIntent = PendingIntent.getActivity(this, 0, signInIntent, 0) val extras = Bundle().apply { putString( "android.media.extras.ERROR_RESOLUTION_ACTION_LABEL", "Sign in" ) putParcelable( "android.media.extras.ERROR_RESOLUTION_ACTION_INTENT", signInActivityPendingIntent ) } val playbackState = PlaybackStateCompat.Builder() .setState(PlaybackStateCompat.STATE_ERROR, 0, 0f) .setErrorMessage( PlaybackStateCompat.ERROR_CODE_AUTHENTICATION_EXPIRED, "Authentication required" ) .setExtras(extras) .build() mediaSession.setPlaybackState(playbackState)
Java
Intent signInIntent = new Intent(this, SignInActivity.class); PendingIntent signInActivityPendingIntent = PendingIntent.getActivity(this, 0, signInIntent, 0); Bundle extras = new Bundle(); extras.putString( "android.media.extras.ERROR_RESOLUTION_ACTION_LABEL", "Sign in"); extras.putParcelable( "android.media.extras.ERROR_RESOLUTION_ACTION_INTENT", signInActivityPendingIntent); PlaybackStateCompat playbackState = new PlaybackStateCompat.Builder() .setState(PlaybackStateCompat.STATE_ERROR, 0, 0f) .setErrorMessage( PlaybackStateCompat.ERROR_CODE_AUTHENTICATION_EXPIRED, "Authentication required" ) .setExtras(extras) .build(); mediaSession.setPlaybackState(playbackState);
After the user has successfully authenticated, your app must set the PlaybackState
back to a state other than STATE_ERROR
and then take the user back to Android Automotive OS by calling the activity's finish()
method.
Implement your sign-in activity
Google offers a variety of identity tools that you can use to help users sign in to your app in their cars. Some tools, such as Firebase Authentication, provide full-stack toolkits that can help you build customized authentication experiences. Other tools leverage a user's existing credentials or other technologies to help you build seamless sign-in experiences for users.
We recommend the following tools to help you build an easier sign-in experience for users that have previously signed in on another device:
- Google Sign-in: If you've already implemented Google Sign-in for other devices (such as your phone app), you should also implement Google Sign-in for your Android Automotive OS app to support existing Google Sign-in users.
- Autofill with Google: If users have opted into Autofill with Google on their other Android devices, their credentials are saved to the Google password manager. Then, when the user signs in to your Android Automotive OS app, Autofill with Google suggests relevant saved credentials. Using Autofill with Google requires no application development effort; however, application developers should optimize their apps for better quality results. Autofill with Google is supported by all devices running Android Oreo 8.0 (API level 26) or higher (including Android Automotive OS).
Use AccountManager
Android Automotive OS apps that have authentication must use AccountManager for the following reasons:
- Better UX and ease of account management: Users can easily manage all of their accounts from the accounts menu in the system settings, including sign in and sign out.
- "Guest" experiences: Because cars are shared devices, OEMs can enable
"guest" experiences in the vehicle, where accounts cannot be added. This
restriction is achieved using
DISALLOW_MODIFY_ACCOUNT
forAccountManager
.
Permissions
If you need to request permissions from the user, use the same flow as the authentication activity or the settings activity in the activity workflows diagram.
Error Handling
Errors in media apps on Android Automotive OS are communicated via the media
session’s PlaybackState
. For all errors, you should set an appropriate error
code and error message in the PlaybackState
. This causes a Toast
to appear
in the UI.
When an error occurs but playback can continue, you should issue a non-fatal
error.
For example, a user might be able to play music in an app before signing in, but
they must sign in before they can skip a song. By using a non-fatal error, the
system can suggest that the user should log in without interrupting playback for
the current media item. In this case, you should preserve the rest of the
PlaybackState
as-is (aside from the error code and error message). Using this
approach allows playback for the current media item to continue while the user
decides whether to sign in or not.
When playback is not possible, for example if there is no internet connection
and no offline content, you should set the PlaybackState
state to
STATE_ERROR
.
On subsequent updates to your PlaybackState
, you should clear the error code
and error message to avoid displaying multiple warnings for the same error.
If at any point you are unable to load a browse tree—for example, if you
require authentication and the user is not signed in—you should send an empty
browse tree. To signify this, onLoadChildren()
for the root media node should
return a null result. When this happens the system displays a full-screen
error with the error message set in the PlaybackState
.
Actionable errors
If an error is actionable, additionally set the following two extras in the
PlaybackState
:
android.media.extras.ERROR_RESOLUTION_ACTION_LABEL
: A label for the button to click to resolve the error. Because this string is user-facing, it must be localized for the user’s current locale.android.media.extras.ERROR_RESOLUTION_ACTION_INTENT
: ThePendingIntent
that the button will run to resolve the error (for example, launching your sign-in activity).
Actionable errors appear as a Dialog
and can resolved by users only when
the car is stopped.
Testing error cases
You should verify that your app handles gracefully in all scenarios, including:
- Different tiers of your product: For example, free versus premium or signed in versus signed out.
- Different drive states: For example, parked versus driving.
- Different connectivity states: For example, online versus offline.
Other Considerations
Keep these other considerations in mind when developing your Android Automotive OS app:
Offline content
If applicable, implement offline playback support. Cars with Android Automotive OS are expected to have their own data connectivity, that is to say either a data plan included in the cost of the vehicle or paid for by the user. However, cars are also expected to have more variable connectivity than mobile devices. As such, we recommend thinking about the best offline support strategy for your content. The disk space on the cars will vary but will be reasonable, so ensure that users can delete offline content, for example through an option in your settings activity.
Here are a few things to keep in mind as you consider your offline support strategy:
- The best time to download content is when your app is currently in use.
- Do not assume that WiFi is available. A car might never come into WiFi range or the OEM might have disabled WiFi in favor of a cellular network.
- While it is okay to smartly cache the content that you think users are likely to use, we highly recommend allowing the user to change this behavior through your settings activity.
Commerce support
Android Automotive OS does not currently support any commerce functionality. This means that you can't have a paid app nor any in-app purchases in your app. Users can purchase IAPs outside your Android Automotive OS app, but must not be required to do any additional commerce-related steps once in the car to use any new paid content or features.
WebView support
WebViews are supported in Android Automotive OS but are only allowed for your settings and sign-in activities. Activities that use a WebView must have a close and/or back affordance outside of the WebView.
Here are some examples of acceptable use-cases for WebViews:
- Displaying your privacy policy, terms of service, or other legal-related links in your settings activity.
- A web-based sign-in flow in your sign-in activity.
When using a WebView, you are allowed to enable Javascript.
Secure your WebView
Take all precautions possible to ensure that your WebView does not act as an
entry point into the greater internet. See the code snippet below for an
example on how to lock the WebView to the URL used in the
loadUrl()
call and prevent redirects. It is highly recommended to implement safeguards
such as this when the use-case makes sense (for example, when displaying
legal-related links).
Kotlin
override fun shouldOverrideUrlLoading(webView: WebView, webResourceRequest: WebResourceRequest): Boolean { val originalUri: Uri = Uri.parse(webView.originalUrl) // Check for allowed URLs if (originalUri.equals(Uri.parse(BLANK_URL)) || originalUri.equals(webResourceRequest.url)) { return false } if (webResourceRequest.isRedirect) { logger.w("Redirect detected, not following") return true } setupWizardWebViewClientListener.onUriBlocked(webResourceRequest.url) logger.w( String.format( "Navigation prevented to %s original is %s", webResourceRequest.url, originalUri)) return true }
Java
@Override public boolean shouldOverrideUrlLoading(WebView webView, WebResourceRequest webResourceRequest) { Uri originalUri = Uri.parse(webView.getOriginalUrl()); // Check for allowed URLs if (originalUri.equals(Uri.parse(BLANK_URL)) || originalUri.equals(webResourceRequest.getUrl())) { return false; } if (webResourceRequest.isRedirect()) { logger.w("Redirect detected, not following"); return true; } setupWizardWebViewClientListener.onUriBlocked(webResourceRequest.getUrl()); logger.w( String.format( "Navigation prevented to %s original is %s", webResourceRequest.getUrl(), originalUri)); return true; }
Package names
Because you distribute a separate APK for Android Automotive OS, you have the option to reuse the package name from your mobile app or create a new package name. This is predominantly a business decision. The main difference is that with a different package name your app has two completely separate Play Store listings, whereas if you reuse your current package name then you'll have a single listing across both platforms.
In terms of development, you might want to consider how the distribution process works with your team structure. For example, if you have one team working on the mobile app and a completely separate team working on your Android Automotive OS app, then it might make sense to have separate package names and let each team manage their own Play Store listing. There is not a large difference in the technical effort required to use either approach.
The following table summarizes some of the other key differences between each approach:
Feature | Same package name | New package name |
---|---|---|
Store listing | Single | Multiple |
Mirrored install | Yes. “Fast app reinstall” during the setup wizard | No |
Play Store Review process | Blocking reviews. Currently, if the review fails for one APK, other APKs submitted in the same release are blocked | Individual reviews |
Statistics, metrics, and vitals | Combined. Note: You can filter by device name for automotive-specific data (for example, 2 cars in year 2020) | Separate |
Indexing and search ranking | Build off of current standing | Does not carry over |
Integrating with other apps | Most likely no changes needed, assuming media code is shared between both APKs | Might have to update the corresponding app (for example, for URI playback with Google Assistant) |
Frequently asked questions
See the following sections for answers to some frequently asked questions about Android Automotive OS.
Hardware
Can my app get access to the microphone?
For apps targeting Android 10 (API level 29) or higher, refer to the sharing audio input documentation. This is not feasible prior to API level 29.
Which car APIs can we get access to and how?
You are limited to the APIs that are exposed by the OEM. We are in the process of standardizing how you access these APIs.
Apps can access car APIs using SetProperty()
and GetProperty()
in CarPropertyManager
.
Refer to the source code
or reference documentation to see a
list of all available properties. If the property is annotated
with @SystemApi
, it is limited to System (preloaded) apps.
What types of audio codecs are supported?
Refer to the audio codec details in the Android CDD.
Is Widevine DRM supported?
Yes. Widevine DRM is supported.
Development and testing
Are there any restrictions or recommendations for using third-party SDKs and libraries?
We don’t have any specific guidelines on using third-party SDKs and libraries. If you choose to use third-party SDKs and libraries, you are still responsible for complying with all the car app quality requirements.
Can I use a foreground service?
The only allowed use-case for a foreground service is downloading content for offline use. If you have another use case for a foreground service that you'd like to see support for, get in touch with us using the Android Automotive OS discussion group.
Publishing Android Automotive OS apps
How do I publish my Android Automotive OS app using the Google Play Console?
The app publishing process is similar to publishing your phone app, but you use a different release type. To opt in your app to use the Android Automotive OS release type, follow these steps:
- Open the Play Console.
- Select your app.
- From the left menu, select Release > Setup > Advanced settings > Release types.
- Select Add release type > Android Automotive OS, then follow the instructions in the Play Console.
Additional resources
To learn more about Android Automotive OS, see the following additional resources.
Samples
Guides
- Android Automotive OS app design guidelines
- Using the media controller test app
- Notifications on Android Automotive OS
- Android app quality for cars