The question comes up on every head-unit project. On 9 January 2026 the certification moved entirely to the 2.0 system, and the 1.0 annual renewal was abolished. The 2.0 rule is clean: the certification ID is valid long-term, with no fixed expiry date. But that is not a free pass — core RF and communication hardware cannot be changed without permission, the mass-produced unit's software and hardware must match the archived certification, and you must keep up with Google's mandatory new CTS-Auto versions, or the qualification is revoked. The detailed device-side test specs remain under NDA in Google's partner channel.
A note: the following is compiled from industry practice and third-party lab interpretation, not an official Google publication. The 2.0 rules follow the current partner-channel documents.
No expiry date does not mean no rules. The logic is not "issue a certificate that expires and must be replaced", but market access plus ongoing compliance: pass the authorised lab test, complete the backend filing, then maintain through change management and production consistency — a completely different road from the traditional five-year type-approval renewal.
Apple CarPlay aftermarket products go through the MFi accessory programme; membership is maintained annually, and the trademark right exists while membership does. Android Auto has no public annual-fee system or fixed-term table; what you can see is the list of compatible vehicles and audio units.
Another concept to separate: Android Auto is a phone-projection scheme; Android Automotive OS is the standalone Android system inside the car. The two are not mutually exclusive. Front-seat cockpit builders take the AAOS line; those with Google services involve GMS authorisation, a different review from the aftermarket projection head unit.
Phone requirements are clear: Android Auto supports phones on Android 9 and above; wireless connection requires Android 11 and up. The 9.0 threshold was only enforced in October 2025 with Android Auto 15.5 — before that it was 8.0, so do not use old material as your basis. The head-unit threshold is in the partner documents; public docs do not list it.
Changes that touch the communication link. Replacing the main platform, changing the Wi-Fi or Bluetooth module model, or a major rewrite of the underlying communication firmware — these basically all require re-submission for evaluation, and most will require compatibility testing. Touching RF and connection fundamentals means going back; changing only the application layer does not.
Antenna changes by degree. Small position tweaks and minor matching-circuit optimisation usually just need before/after comparison data on file; switching from an internal to an external antenna, or a large gain adjustment, falls in the re-evaluate range.
Conversely, these usually do not trigger: unchanged screen size, only appearance and UI interaction changes, same-model memory expansion, non-communication peripheral swaps, same-spec passive-component supplier changes. But a screen-size or display-driver change does require evaluation — display area, resolution adaptation and touch feedback all need re-review. Fixing application-layer bugs, changing sound effects, or updating map data also do not trigger.
Production consistency. The mass-produced unit's hardware and firmware must match the archived sample. Secretly swapping the wireless-module supplier to save cost is a hard hit when pulled for inspection.
Standard versions lock. The compatibility-test suite version at submission is basically locked once passed. When Google later releases a new version, if the hardware and underlying firmware have not changed significantly, the already-granted access stays valid and is not retroactively applied. When a change-triggered retest really happens, you run it on the current latest version.
The AAOS hardware threshold is public, written in the Automotive chapter of the Android Compatibility Definition Document. This is one of the few publicly verifiable car-side hardware bases.
The compatibility list is also public; you can check which cars and audio units are listed. Before starting a project, see whether your category is there to get a sense.
These projects are best handled by treating change evaluation as a routine action, not expecting one test to cover everything forever. At project launch, lock the alternative suppliers for the key items — main controller, wireless module, antenna — because mid-way material swaps hurt most.
For head units doing CarPlay, HiCar and Android Auto together, BlueAsia's one-stop testing and certification merges the test and document schedules of the several ecosystem lines, recording each party's change rules separately rather than mixing them.
The "renew every few years" and "renewal fee at X percent" still circulating outside trace back to the abolished AA 1.0 annual-renewal mechanism — do not use it for budgeting. For the exact wording, check the current partner-channel documents.
Contact: King Email: king.guo@cblueasia.comAddress: Building C, Hongjingda Industrial Park, No. 107 Beihuan Road, Shiyan Street, Bao'an District, Shenzhen, China BlueAsia delivers more than service!
相关新闻
