Android Auto 2.0 Certification Expiry Rules｜Mandatory Maintenance and Hardware‑Change Filing Requirements

Android Auto serves as Google’s vehicle‑projection counterpart against Apple CarPlay. Only certified head‑units can legally carry Android‑Auto branding. Google permanently shut‑down the old AA‑1.0 framework on Jan‑09‑2026 and required all new‑project applications to adopt AA‑2.0 with previous yearly‑renewal rules completely abolished under the updated framework.

1. Validity Rules of AA‑2.0 Certification

AA‑2.0 certification IDs are theoretically permanent without fixed expiry dates, annual re‑testing requirements or yearly maintenance fees, which is a sharp contrast with AA‑1.0 where manufacturers paid annual renewal‑fees every single year.

However, your certification becomes invalid if you break any of these rules: No unapproved changes to core RF‑communication hardware; mass‑produced hardware and firmware must match samples filed with Google; adapt to newly released mandatory CTS‑Auto test suites; fix security vulnerabilities and maintain interoperability compliance consistently.

Products certified before Jan‑09‑2026 under AA‑1.0 still follow old yearly‑audit and fee‑payment rules. Do not accept outdated‑framework quotations for new‑projects; renewal‑fees equal to 60‑70% of initial‑testing costs only applied to AA‑1.0 instead of AA‑2.0.

Compare with Apple Car‑Play: Car‑Play ties trademark‑usage rights to yearly MFi‑membership fees while AA‑2.0 removes annual charges but imposes ongoing compliance and change‑filing duties, narrowing gaps between the two systems after version‑2.0 roll‑out.

  2. Ongoing Maintenance Responsibilities

Zero yearly‑mandatory testing does not mean manufacturers can ignore compliance entirely under AA‑2.0 with three key maintenance‑scenarios below:

·Hardware‑change filingsYou must submit change‑evaluation requests online and re‑run CTS‑Auto tests for major‑hardware adjustments including main‑SoC replacement, Wi‑Fi or Bluetooth module updates, USB communication chip swapping, and modifications to underlying Android Auto casting firmware. Minor adjustments do not need filings or retesting, such as housing restyling, screen‑size changes, UI interface optimization, memory expansion of the same model, and adjustments of non‑communication peripherals. This rule is much more relaxed than AA 1.0, where even screen replacement required prior notification to Google.

·Version iteration adaptationGoogle rolls out updates for mobile‑side Android OS and Android‑Auto App every year. Aftermarket projection‑style head‑units do not need retests to match every smartphone system update. Only AAOS native in‑vehicle systems must complete full CTS‑Auto verification when core Android versions upgrade. During application, manufacturers have to submit an OTA maintenance roadmap covering two or more years as reference for qualification review, but you are not forced to hand in adaptation reports each year.

·High‑risk market spot‑check rulesGoogle randomly inspects products bought from online stores and offline retailers. If RF parameters, firmware versions and casting settings of mass‑produced equipment differ from archived samples, Google will delist your products and cancel certification directly without a revision buffer period. This issue accounts for most AA‑2.0 certification failures in practical projects.

  3. Retest Judgment for System OTA Updates

There are totally different policies for projection‑type head‑units and AAOS native vehicle systems.

·Aftermarket projection‑based head‑units (most replacement head‑units fall into this category): These devices lack a full‑fledged Android operating system and act only as casting peripherals. OTA updates for UI styles and sound‑effect settings do not trigger retesting. If OTA changes the underlying Bluetooth, Wi‑Fi firmware or USB casting protocols, you need to submit change assessments and wait for Google’s decision on whether to carry out retests.

·AAOS factory‑installed native cockpit systems: For small‑scale security patch updates, teams conduct internal compatibility self‑tests and keep reports for archives only. Full‑set CTS‑Auto testing is compulsory when Android core versions upgrade for example from Android 14 to Android 15 before widespread OTA roll‑out.

  4. Five Scenarios That Invalidate Android‑Auto Certification

·Major hardware or underlying firmware changes without prior filings and required retests.

·Mismatched hardware and firmware between mass‑production units and filed samples discovered during market inspections, the top‑ranked reason for AA‑2.0 certificate revocation.

·Expiry or termination of GAS/GMS licences for AAOS native cockpit products; this risk does not apply to aftermarket projection‑type head‑units which do not rely on GMS services.

·Manufacturers refuse long‑term adaptation when Google releases updated mandatory CTS‑Auto test specifications.

·High‑risk vulnerabilities are found in casting links or voice interaction modules and firms miss the fixing deadline set by Google.

The 7‑day SLA for high‑risk vulnerability fixes is only applied to AAOS devices with complete Android systems. Pure casting peripherals without built‑in Android systems are exempt from this strict timeline requirement.

  5. Practical Maintenance Costs and Operation Suggestions

AA‑2.0 has zero fixed annual maintenance fees. Lab retests only happen after major hardware revisions or mandatory specification upgrades. A single CTS‑Auto retest at third‑party labs costs roughly 20,000‑50,000 RMB with price differences between wired and wireless versions.

Follow these four internal management practices:

·Build hardware‑change classification logs to distinguish major revisions and minor adjustments, and consult authorised labs for evaluation before making big‑scale hardware changes.

·Complete internal self‑tests for Android‑Auto casting, voice‑audio links for all OTA firmware versions before gradual roll‑out.

·Keep track of updates from Google developer channels about AA‑Auto and CTS‑Auto revisions.

·Archive self‑test reports and official lab documents for at least two years after product phase‑out to cope with Google’s random audits.

Make sensible hardware selections: Qualcomm and MediaTek automotive‑grade platforms pre‑approved by Google deliver stable compatibility for casting and radio‑frequency functions and reduce later‑stage retest chances significantly. Self‑developed chips and lesser‑known communication modules frequently trigger compatibility faults and push up long‑term maintenance expenses.

If you need Android‑Auto project evaluation, CTS‑Auto testing and change‑filing guidance, get in touch with BlueAsia compliance specialist Benson via +86 13534225140.