Before starting an Android Auto project, manufacturers ask: “How long does it really take?” Answers vary widely – from months to over two years. The differences come from individual stages. This article breaks down each phase. Note: the timelines below assume a first‑time, from‑scratch development. If you use a proven commercial module or reference design, overall time can be significantly compressed.
1.1 Differences by Product Type
·Aftermarket wired – smooth projects: 10–12 months total.
·Aftermarket wireless – add 4–6 months due to Wi‑Fi/Bluetooth RF validation and connection stability testing.
·Front‑load OEM – most time‑consuming: wired at least 12–14 months; wireless 16–24 months+. Front‑load involves vehicle‑platform integration work far beyond aftermarket standalone devices. Some front‑load projects stretch to 3 years due to platform delays or hardware redesigns.
If you do both wired and wireless on the same hardware platform, development can be shared, but official testing runs full cases for both – the reduction is limited; don’t expect a 50% cut.
1.2 Lab Scheduling Realities
Google‑authorised labs queue samples in order of receipt.
·Peak season: 4–8 weeks
·Off‑peak: 2–4 weeks
There is no official priority/fast‑track channel. Third‑party claims of “priority scheduling” are not lab rules – don’t include them in your project plan.
Official full‑test baseline: 2–4 weeks – with complete documents and clean samples, ~3 weeks for results. Each remediation round adds 2–3 weeks.
2. Pre‑Qualification Preparation Phase
2.1 Agreement Signing
Aftermarket projection‑type Android Auto does not require signing MADA – that is for native‑Android automotive (AAOS) projects with pre‑installed GMS. Many aftermarket manufacturers waste time initiating MADA negotiations unnecessarily.
Aftermarket head units and dongles only need to sign Google’s NDA and Compatibility Programme Agreement. Register a corporate developer account with your business licence, submit a technical solution description – Google review takes 2–3 weeks.
Common rejection points: incorrect translation format of the business licence, company English name mismatch with filed records. Prepare according to Google’s backend field requirements.
2.2 RF Certifications – Not a Prerequisite for AA Testing
BQB, CE‑RED, etc., are market‑access requirements for different countries – they are not prerequisites for Google AA lab sample acceptance. Labs will not reject your AA sample for missing RF reports.
However, without RF compliance you cannot export. RF and AA certification should run in parallel to save overall time – doing them serially adds 2–3 months to product launch.
3. Development and Self‑Testing Phase
3.1 Protocol Stack Integration
Integrating the latest AAP (Android Auto Protocol) stack is the core development work.
Clarification: The rumour that Gemini voice is mandatory from 2025 applies to AAOS (native Android Automotive) – not projection‑type Android Auto. Aftermarket head units and dongles are not required to integrate Gemini – don’t let this add unnecessary work.
Vehicle speed signal – another common misunderstanding: for projection‑type AA, vehicle speed is provided by the connected phone – the head unit does not need to actively collect CAN speed data. If a front‑load vehicle wants speed‑linked UI, that’s a custom OEM feature – not a Google‑mandated test item.
3.2 PCTS Self‑Test
PCTS (Projection Compatibility Test Suite) is the official self‑test tool for projection‑type AA – note: not CTS (Android Compatibility Test Suite). Submitting with the wrong name gets your application returned.
Self‑test coverage: audio latency, echo cancellation, wireless connection success rate, high/low‑temperature stability, USB‑C connector endurance.
Voice: The voice‑recognition algorithm runs on the connected phone, not the head unit. AA certification does not evaluate recognition accuracy – it evaluates audio‑path quality (latency, echo suppression). Many manufacturers mistakenly focus on head‑unit recognition algorithms – this is the wrong direction.
3.3 Self‑Test Duration – Most Variable
This phase has the highest variability – smooth teams finish in 1 month, struggling ones take 8 months. The difference is experience – experienced teams have existing code frameworks and debug toolchains; new teams spend 2 weeks just setting up the environment.
4. Pre‑Testing and Official Submission
4.1 Third‑Party Pre‑Testing
Use a Google‑recognised third‑party lab for full pre‑testing – covering RF performance, audio quality, interface endurance, and temperature stability. Run at least two rounds before official submission – the first round almost always finds issues.
Pre‑testing saves time by catching problems early – fixing them before official submission avoids double the remediation cycles. Products that pass pre‑testing often pass official submission in one round – saving 2–3 months overall.
Pre‑test fees vary by lab and scope – ballpark in the tens of thousands RMB – don’t treat as a fixed budget line.
4.2 Official Testing and Remediation
Official testing: 2–4 weeks per round. Missing documents – Google returns them; resubmission re‑queues.
There is no official limit on remediation rounds – the “3 rounds = forced re‑submission” rumour is unfounded. Repeated remediation just consumes time.
Control remediation rounds through thorough pre‑testing. Each remediation round adds 2–3 weeks.
5. Key Variables Affecting Timeline
5.1 Team Experience
First‑time AA teams take 4–6 months longer than experienced teams – difference in stack integration, PCTS toolchain setup, and remediation efficiency. Experienced teams know which test items are prone to failure and fix them during self‑test.
5.2 Product Complexity
Wireless adds 4–6 months vs. wired; front‑load adds 2–6 months vs. aftermarket. Dual‑mode can share hardware development, but official tests for wired and wireless run separately – reduction is limited.
5.3 Hardware Maturity
Projects using proven commercial modules have much shorter cycles than self‑developed solutions – the saving comes from reduced stack integration and debugging time. The actual compression depends on module readiness.
6. Optimisation Recommendations
6.1 Run in Parallel
Hardware finalisation, document preparation, and pre‑testing should run concurrently. RF certification can also start early – don’t wait for AA to begin. Many teams run sequentially, adding 3–4 months unnecessarily.
6.2 Invest in Pre‑Testing
Pre‑testing is a small cost that saves big time. Direct official submission with failures means 4–8 weeks for re‑queuing. Two rounds of pre‑testing to clear issues can achieve a single official pass.
6.3 Build Self‑Test Toolchain Early
Set up PCTS, audio test suite, USB‑C endurance jig, and temperature chambers early. These are one‑time investments – costs average down over subsequent projects.
For Android Auto certification timelines, contact BlueAsia at 13534225140 (King) or king.guo@cblueasia.com.
Related News
