Android Auto Removal Guide

Overview

Some apps do not actually provide Android Auto functionality but still include Android Auto–related components due to:

• Temporary or test-purpose library inclusion

• Misunderstanding of dependencies while implementing media, notifications, or navigation

• Legacy configurations that were never removed

Even if Android Auto features are not used, the app may still be recognized as an Android Auto–supported app by the system or app stores, which can lead to unnecessary behaviors such as service binding or policy misclassification.

This guide explains what must be removed if your app does NOT support Android Auto.

---

How an App Is Recognized as an Android Auto App

Android Auto does not rely solely on whether a library is included. Instead, it determines Android Auto support based on Manifest declarations and services.

Your app may be treated as Android Auto–compatible if any of the following are present:

• androidx.car.app (Android for Cars App Library) dependency

• CarAppService declaration

• Android Auto–specific intent-filter or meta-data

• Automotive / Android Auto–related uses-feature

Android Auto and Android Automotive OS overview: https://developers.google.com/cars/

---

Components That Must Be Removed If Android Auto Is Not Used

1. Remove Gradle Dependencies (Required)

If your project includes Android Auto Jetpack libraries, they must be removed.

Gradledependencies {
    implementation "androidx.car.app:app:..."
    implementation "androidx.car.app:app-projected:..."
}

These libraries are specifically designed for Android Auto and Android Automotive OS apps. If you do not support Android Auto, they should not be included.

Official library documentation: https://developer.android.com/training/cars/apps/library

---

2. Remove CarAppService from AndroidManifest.xml (Critical)

If the following service exists, Android Auto will automatically attempt to bind to your app, even if no UI is shown.

Must not exist in apps without Android Auto support

<service
    android:name=".MyCarAppService"
    android:exported="true">
    <intent-filter>
        <action android:name="androidx.car.app.CarAppService" />
    </intent-filter>

    <meta-data
        android:name="androidx.car.app.category"
        android:value="navigation" />
</service>

• Android Auto detects apps via service declarations

• Lifecycle callbacks may be triggered even without actual functionality

Android Auto service binding model: https://developers.google.com/cars/

---

3. Remove Android Auto Category Meta-data

The following meta-data explicitly categorizes your app as a car app:

<meta-data
    android:name="androidx.car.app.category"
    android:value="navigation | media | communication" />

• These values correspond to official Android Auto app categories

• Presence alone marks the app as an Android Auto app

Supported categories and requirements: https://developer.android.com/training/cars/apps/library

---

4. Remove Automotive / Android Auto uses-feature

Check for the following feature declaration:

<uses-feature
    android:name="android.hardware.type.automotive"
    android:required="false" />

• Used by Google Play and the system to determine vehicle-related apps

• Should be removed if Android Auto is not supported

Manifest uses-feature behavior: https://developer.android.com/guide/topics/manifest/uses-feature-element

---

5. Remove Android Auto–Only Services and Components

If added solely for Android Auto support, the following should be removed:

• MediaBrowserService for in-car use only

• Android Auto–specific notification integrations

• Automotive messaging / reply intent handling

Android Auto discovers apps primarily via service declarations: https://developers.google.com/cars/