There's a joke in the head‑unit industry: "If you're doing IVI and not touching Android Auto, you're not really doing IVI." That's an exaggeration – but looking at the global front‑load market, Android Auto penetration has reached a point where you simply can't avoid it.

Important: this article covers Android Auto – the phone‑projection protocol – not Android Automotive OS (AAOS – the deeply embedded full operating system). The certification paths, test items, and compliance requirements are completely different – mixing them up sets your project up for failure from the start.

1. What Does Android Auto Certification Actually Certify?

·The nature of the projection protocol

Android Auto is a projection protocol defined by Google. The phone runs navigation, music, and calls – the UI is projected to the head‑unit screen via USB or Wi‑Fi – user interactions happen on the head unit – processing happens on the phone. Certification has one purpose: Google ensures that every link – rendering, touch response, audio path, microphone return – follows their specifications – no display glitches, no audio stutter, no touch dropouts.

After certification, Google assigns a Product ID – pre‑provisioned into the head‑unit's Android Auto protocol stack firmware. Without a valid ID, the local protocol stack refuses to launch Android Auto – the phone connects but the interface won't appear. Note: this is a local head‑unit verification mechanism – not a Google cloud remote switch – there is no Google backend remote disabling of already‑shipped devices.

·Don't confuse with GMS

Android Auto certification is not about in‑vehicle app certification. Pre‑installed YouTube Music and Google Maps on the head unit follow GMS (Google Mobile Services) certification – a separate track. Another common confusion: the Android Auto projection solution relies on the phone‑side GMS – the head unit itself does not need GMS. Many people get this wrong.

  2. Who Needs Android Auto Certification?

·Front‑load vs. aftermarket – the boundary

Front‑load OEMs – absolutely. If the head unit claims Android Auto support, Google certification is mandatory – non‑negotiable.

Aftermarket has two scenarios:

·Legitimate Tier‑1 suppliers providing IVI systems to OEMs – Android Auto certification is required.

·Manufacturers building aftermarket Android head units for retail (generic board solutions) – much more difficult. Google's MADA agreement is typically only signed with vehicle OEMs – ordinary Tier‑1s cannot sign independently – they can only act as OEM suppliers. Retail aftermarket devices have virtually no application channel at the commercial stage – testing capability alone is useless.

·Accessory manufacturers – no

USB hubs, wireless charging pads – hardware that doesn't participate in Android Auto protocol interaction – are not relevant.

  3. Android Auto Certification – Prerequisites

·MADA – commercial first

The OEM must sign the Mobile Application Distribution Agreement (MADA) with Google. Tier‑1 suppliers cannot sign independently – only the OEM can. Start commercial engagement before hardware design is frozen – signing timelines depend heavily on Google's commercial resource scheduling – some overseas OEM projects exceed 3 months – plan accordingly.

·USB and Bluetooth – hard requirements

Wired mode: USB interface must meet USB electrical and protocol specifications – pass Android Auto's internal USB compatibility tests. Certification itself does not mandate a USB‑IF official TID – but in practice, interfaces with TIDs pass more easily. Type‑C USB PD charging protocol must also be separately validated.

Wireless Android Auto relies on Wi‑Fi P2P (Wi‑Fi Direct) – Bluetooth is used only for service discovery and initial handshake – the actual projection data stream runs entirely over Wi‑Fi. Bluetooth modules must have BQB certification. Profiles: A2DP, HFP, AVRCP are mandatory for wireless connection establishment – missing any one causes handshake failure. PBAP (Phone Book Access Profile) is not mandatory for link establishment – missing it only affects contact sync – it does not prevent connection.

Manufacturers receive pre‑test tools – formal certification testing must be performed at a Google‑authorised 3PL lab – the full AATS toolkit is not available to ordinary manufacturers.

  4. Android Auto Test Items – Broken Down

·USB compatibility – the most common failure

The core test item for wired mode. Using Google‑designated reference phones (Pixel series as the mainstay, plus Samsung and some Chinese brands) – test USB connection stability and hot‑plug recovery on each. The most painful case we encountered: a head‑unit USB PHY driver occasionally failed to send VBUS reset signals during hot‑plug – replicated on three Pixel 6 units – resolved only after updating the chip vendor's third‑party driver.

·Video rendering and touch return

Rendering resolution, frame rate, and landscape/portrait switching must meet Google UX specifications. Touch latency must be within specified thresholds – multi‑touch coordinate mapping must be accurate. These run automatically via Google's dedicated test app – rendering frames and touch event logs – little room for subjective judgement.

·Audio path and microphone return

Android Auto audio runs over USB Audio Class or Bluetooth A2DP. Navigation prompts and media audio have independent volume controls – media volume automatically lowers during calls. Latency is tricky – from phone playback to head‑unit speaker output – must stay within Google's specified upper limit – both hardware codec and software DSP chain need tuning.

Microphone return tests voice commands ("OK Google") and uplink during calls. Environmental noise suppression and echo cancellation are not directly assessed – but poor mic return quality degrades voice recognition success rates – indirectly failing the voice command tests.

·Wireless connection – 5 GHz interference is the tough one

Applies only to wireless‑enabled devices. Tests Wi‑Fi Direct pairing time, Bluetooth handshake stability, 5 GHz band interference resistance, and seamless Bluetooth‑to‑Wi‑Fi switching. The biggest challenge: can the device reliably switch to 5 GHz when the 2.4 GHz environment is congested? That's the real test.

  5. Android Auto Certification Process and Timeline

Android Auto certification is performed by Google‑designated 3PL labs. Process:

·Submit hardware/software version info to Google.

·Google assigns a lab.

·Send samples.

·Testing.

·Report submitted to Google for review.

·Google issues certification.

Testing itself: 3–4 weeks. Google review: 2–4 weeks. Including the MADA commercial process – allow 3–5 months from project kick‑off to certification.

  6. Change Exemptions – Know the Conditions

·Cosmetic colour changes – filing only.

·Screen supplier changes – more complex. Even with identical specifications – if the driver, firmware, or display rendering logic changes – video rendering and touch return must be retested. Hardware parameters identical but driver version changed – still requires retesting.

·SoC platform change, USB controller model change, Android major version upgrade – basically full retesting.

For Android Auto certification, contact BlueAsia at 13534225140 (King) or email king.guo@cblueasia.com.