If you’re an OEM or Tier 1 developer integrating Google Automotive Services (GAS) into your Android Automotive OS (AAOS) stack, compliance isn’t just a formality — it’s a binding agreement with Google. Their guidelines are intentionally strict to preserve platform security, ensure a consistent user experience, and maintain API reliability across the ecosystem.

This article takes a deep dive into what GAS compliance actually entails — offering actionable insights for engineers, system architects, and product owners navigating the AAOS landscape.

Quick Primer: What Is GAS?

Google Automotive Services (GAS) is a proprietary suite of applications running on Android Automotive OS (AAOS). It includes:

• com.google.android.apps.maps (Google Maps)
• com.google.android.googlequicksearchbox (Google Assistant)
• com.android.vending (Play Store)
• com.google.android.gms (Play Services)

Unlike Android Auto, which mirrors from a paired phone, GAS apps run natively on the IVI (In-Vehicle Infotainment) hardware. That requires full-stack integration — kernel to UI.

Licensing GAS (OEM Legal Requirement)

Before any technical work begins, your OEM must sign a GAS License Agreement with Google. This is model-specific, meaning:

• Each vehicle/trim with a different infotainment configuration = separate GAS approval
• Google reserves the right to audit or revoke if compliance slips

As a developer, you’ll typically get access to the GAS Partner Portal after your OEM is approved — where SDKs, sample projects, and certification tools are hosted.

Hardware & OS Prerequisites

To be GAS-compliant, your hardware must meet strict thresholds.

Minimum Hardware Spec

Android Automotive OS

To integrate Google Automotive Services, your IVI system must use a Google-certified build of Android Automotive OS. This typically involves:

• A certified AOSP base, often from a recent LTS (Long-Term Support) branch
• HALs and BSPs tailored for IVI use cases, compliant with VHAL (Vehicle HAL) standards
• A custom UI that respects Google Automotive Services guidelines for system behavior, Assistant integration, and safe navigation

Note: Google prohibits UI customizations that interfere with system-level navigation, Assistant triggers, or driving safety workflows. GAS will not support heavily skinned or fragmented UI shells that break these requirements.

The Test Suites — All Mandatory

Google requires your system to pass a set of test suites to ensure stability and UX consistency.

Compatibility Test Suite (CTS)

Tests Android APIs, permissions, and behavior.

$ run_cts --module CtsAppSecurityHostTestCases
$ run_cts --module CtsMediaTestCases

Failures often involve:

• Custom permission models
• Background activity restrictions
• Missing system apps

Vendor Test Suite (VTS)

Validates hardware interface layers. You’ll need to flash your build and execute these over adb/fastboot.

$ run_vts --plan VtsKernelTest

Typical failures:

• Bad binder transaction handling
• Incomplete HIDL implementation

Automotive Test Suite (ATS)

Tests GAS apps in the context of AAOS.

Key checks include:

• Intent resolution from Assistant (ACTION_NAVIGATE_TO)
• Overlay permission use
• Play Store update flow

Drivable Test Suite (DTS)

DTS evaluates runtime behavior during actual vehicle use. Google may perform this directly or via OEM-conducted telemetry logs.

Integration Tips for GAS Developers

1. Use CarApp API for Custom Apps

If you’re building companion apps, use the androidx.car.app APIs (Jetpack):

class MyCarScreen(carContext: CarContext) : Screen(carContext) {
    override fun onGetTemplate(): Template {
        return MessageTemplate.Builder("Welcome to MyCar App")
            .setTitle("MyCar")
            .setHeaderAction(Action.APP_ICON)
            .build()
    }
}

2. Use MediaBrowserServiceCompat for Media Apps

GAS expects media apps to use Android’s MediaBrowserServiceCompat so that Assistant can control them

class MyMediaService : MediaBrowserServiceCompat() {
    override fun onCreate() {
        super.onCreate()
        // Setup your media session and player
    }
    
    override fun onLoadChildren(parentId: String, result: Result<List<MediaItem>>) {
        // Populate UI content
    }
}

3. Assistant Support = Deep Linking Required

Make sure you support Google Assistant voice intents. This requires implementing App Actions schema or handling common Intents.

<intent-filter>
    <action android:name="android.media.action.MEDIA_PLAY_FROM_SEARCH" />
</intent-filter>

Handle queries like “Play Arijit Singh songs on MyCar App”.

Privacy & Data Handling for GAS Compliance

As a developer, your GAS integration must comply with Google and regional privacy rules.

You must:

• Avoid tracking without user consent
• Route sensitive data via Android Keystore or SafetyNet
• Support user-level account deletion (GDPR/CCPA)
• Never misuse the Location or Microphone data exposed via GAS APIs

Pro Tips for Dev Teams

• Use Emulator Images from AOSP: GAS builds aren’t public, but you can prototype using AAOS emulator images from Google’s android-automotive GitHub.
• Leverage VHAL correctly: Don’t shortcut vehicle HAL integrations — Google’s certification expects clean VehicleProp handling.
• Automate testing with TradeFed: You’ll be running these tests often. Use TradeFederation to orchestrate builds and reports.

Conclusion: Build for Compliance, Not Just Launch

GAS compliance is a high bar. But it’s not just bureaucracy — it’s about delivering a polished, secure, responsive infotainment system users can trust.

As a developer, your role is to make sure the AAOS stack:

• Runs clean, certified builds
• Passes all test suites
• Delivers a user experience aligned with Google’s best practices
• Handles data securely and transparently

Once certified, your GAS integration unlocks the full power of Google’s ecosystem — and keeps your vehicles competitive in a connected world.