Many head unit manufacturers encounter Android Auto certification for the first time and struggle to clarify the full document checklist. Missing paperwork leads to back-and-forth revisions that waste 1–2 months before lab testing even starts.This guide categorizes all required documents by application, technical and sample delivery segments, covering updated 2026 AA 2.0 framework requirements in full detail.
The first step is registering an official Google Enterprise Developer Account. Though seemingly straightforward, document rejection and re-sign rates remain high in real practice.Three core mandatory files:
·Business License: Both Chinese original and certified English translated copies are required. Translations must be issued and sealed by officially accredited translation agencies; self-made translations are not accepted by Google.
·Legal Representative Identification Documents
·Corporate Contact Information: Email addresses and phone numbers for technical leads and business coordinators. Google sends audit notifications and deficiency requests exclusively to these contact channels.
Critical Common Pitfall
The registered company name must match the business license wording perfectly, including full-width Chinese brackets vs half-width English brackets; minor discrepancies trigger immediate rejection.
Post account creation, applicants must sign the ADA (Android Distribution Agreement), the standard distribution contract for in-vehicle AA systems. Do not confuse ADA with MADA (Mobile Application Distribution Agreement) designed for handheld mobile devices. Submitting MADA for automotive AA applications results in automatic Google file rejection.
After contract execution, companies fill out Google’s corporate basic information form, covering business scale, R&D team structure, and prior Android certification projects. Submitted data influences the strictness level of Google’s document audit.
2. Hardware Technical Documentation
Hardware files form the thickest segment of the dossier and are the top audit bottleneck.
-Complete BOM ListList full model numbers, brands and specifications for every component, with heavy Google scrutiny focused on core chips: main processor, Wi-Fi module, Bluetooth IC, USB controller, audio DSP.
·For components with multiple supply sources: Core devices (main SoC, Wi-Fi/Bluetooth RF chips, USB communication ICs) require full labeling and filing for every supplier. Future production switches to secondary suppliers trigger re-evaluation and potential retesting.
·Passive auxiliary parts (resistors, capacitors, plastic housings, connectors) allow supplier changes without formal change assessment or retesting, only internal record-keeping is needed.
-Hardware Schematic & PCB Layout FilesInitial submission only needs clear, complete PDF schematics for Google’s cross-verification against BOM component brands and models. Editable source files are only requested for deep technical validation upon audit request, not a first-submission mandate. PCB layout reviews prioritize RF routing zones: antenna feed points, matching network layout, RF shielding structure design.
-Antenna Specification Datasheets (For Wireless-Equipped Units Only)All head units with Bluetooth/Wi-Fi modules need antenna parameter documentation, including antenna type, gain value, radiation pattern and impedance matching data.
·For modules with integrated antennas: Use antenna specs provided by the module manufacturer.
·For custom-designed antennas: Attach anechoic chamber lab test reports.
·Pure wired AA devices without Bluetooth/Wi-Fi require no antenna paperwork.
-Separate USB-C Interface Design DocumentsAA 2.0 enforces stricter standards for USB-C power negotiation, data role switching and OTG compatibility. Submit USB-C circuit design explanations, supported PD protocol versions, and pin definition tables. Wired AA relies entirely on low-level USB communication; flawed USB-C design causes immediate failure in CTS-Auto’s foundational wired connection stability test.
Key Reminder: CTS-Auto acts as Google’s official pass/fail benchmark. PCTS is merely an internal factory pre-check tool and does not qualify units for lab submission—never conflate the two during self-test documentation preparation.
3. Software Technical Documentation
Software paperwork requirements match the volume of hardware files:
-Android OS Version DeclarationA simple line stating “Based on Android 13” is insufficient. Detail full system architecture, kernel version, HAL implementation framework, and depth of system customization.
·For validated Google ecosystem platforms (MediaTek / Qualcomm automotive Android baselines): Directly reference the platform provider’s certified filing ID to eliminate redundant explanatory paperwork.
·For fully in-house developed underlying systems: Document the complete architecture stack, plus integrated AAP (Android Auto Protocol) stack files including protocol version, message channel implementation, and supported screen resolution list. Wireless AA builds additionally require Wi-Fi Direct and Bluetooth pairing communication flowcharts.
-Voice Assistant Adaptation Statement (New 2026 Audit Priority)Overseas English regions default to the Gemini voice engine; multi-language models may retain Google Assistant for compatibility, with both frameworks fully documented.Chinese-market devices need standalone documentation for local voice tuning, custom wake word frameworks and Chinese corpus training sources. Gemini’s Chinese language dataset coverage lags far behind English versions; comprehensive documentation drastically cuts communication friction during VRRT voice testing.
-Mandatory 2-Year OTA System Maintenance Roadmap (AA 2.0 Rule)This document serves as Google’s reference to evaluate corporate R&D operation capacity, not a legally binding performance contract. Google does not enforce full execution of every update milestone post-certification approval.
4. Test Samples & Supporting Sample Documentation
Once paperwork clears preliminary audit, prepare prototypes for lab testing:
·Official baseline sample quantity: 3 complete production-grade units. Minimum one full assembled unit (housing, display, physical buttons/knobs); remaining units can be bare engineering PCBs for targeted debugging.
·Wireless AA builds face more complex retest scenarios for wireless stability; preparing 2 extra engineering boards for backup debugging is practical industry guidance (not a Google hard requirement).
·Attach firmware flashing guides and debug interface manuals so lab engineers can flash varied test firmware versions on demand. If engineering modes or hidden debug menus exist, document access steps, menu hierarchy and parameter definitions.
AA 2.0 allows early SSL security certificate application during development. Certificates can be debugged alongside prototype testing instead of serial issuance post-final testing. Certificates bind to one single product Family; grouped variants under the same Family share one certificate, while new hardware-platform Families require separate certificate and key configuration.
5. Documents for Family Group Reuse & Compliance Exemptions
-Family Group Reuse FilingManufacturers launching multiple SKUs under one product line leverage AA 2.0’s grouping mechanism to reduce testing workload, conditional on complete supporting files.Group applications require a side-by-side variant difference matrix detailing hardware configurations, software versions and functional module gaps, with notations on whether each difference impacts test results. Supplementary full-line BOM and schematic comparison tables enable Google auditors to approve shared passing test data for identical core hardware. Incomplete filing results in rejected group applications, forcing full independent testing for every SKU.
-Compliance Exception ApplicationsIf a test metric falls short with valid technical justification (e.g., low connection success rate only under extreme niche operating conditions that never occur during real driving), submit exception requests paired with raw test data and technical analysis reports. Approved exemptions remain valid long-term across all variants within the identical hardware product Family. Exemptions expire automatically for new models with swapped main processors or RF platforms, requiring fresh application reviews.
Easily Overlooked Edge Case: Minor antenna matching circuit tweaks or RF chip swaps within one Family that alter connection/RF performance invalidate existing exception approvals, requiring re-submission for audit.
Common Document Rejection Root Causes
·Non-certified self-translated business licenses (top rejection trigger; Google only accepts agency-stamped certified translations)
·Incomplete BOM missing critical RF support components such as antenna matching parts for Wi-Fi modules
·Conflicting BOM and schematic component branding (e.g., Murata capacitor listed on BOM, Samsung marked on schematics) – contradictions trigger authenticity scrutiny
·Slight business license name mismatches (e.g., “Limited Liability Company” vs “Limited Company”)
·Accidental MADA contract submission instead of ADA for automotive AA projects
BlueAsia Testing delivers full template provision and line-by-line document pre-audit services for the entire filing cycle, covering enterprise credential validation, BOM cross-checking, schematic alignment and group reuse dossier drafting to maximize first-submission pass rates and eliminate schedule delays from repeated revisions.BlueAsia Testing & Certification Consultant: +86 13534225140 (Benson)
Original content authored by BlueAsia Testing Technical Team, specializing in automotive electronics global certification for years. Reproduction, rewriting or paraphrasing without authorization prohibited.
相关新闻
