Head-unit teams should clarify at project kickoff exactly what Android Auto tests. Knowing the test items tells you whether the hardware is sufficient and the architecture correct — do not wait until a lab failure forces a redesign.
What is public
Android Auto's external materials are two types. The CDD (Compatibility Definition Document) lists all mandatory requirements; the CTS (Compatibility Test Suite), derived from the CDD, is called CTS-Auto in its automotive version and runs automated. AOAP (Android Open Accessory Protocol) is the wired-connection underlying communication protocol — not a downloadable public document.
What you cannot get
The full test suite, pass thresholds and internal tools live inside Google's authorised framework and are released only on signing. Posts online that list internal suite numbers and case counts exactly are mostly fabricated. The reliable sources are the authorised documents after signing plus your own first-hand submission data.
What you can read from the CDD
The CDD defines Android Automotive as an Android implementation running on the head-unit host and handling infotainment. The physical screen diagonal is at least 6 inches, it declares android.hardware.type.automotive, and supports uiMode=UI_MODE_TYPE_CAR and all publicly available android.car.* APIs. Bluetooth and audio output are mandatory per the configuration table. The CDD keeps updating; the screen threshold follows the latest version at signing.
2. What the wired link tests
AOAP protocol is the foundation
Wired uses the AOAP channel, defining accessory identification, handshake with the phone and how the data channel opens. Wrong USB enumeration order, handshake timeout and mis-mapped HID touch coordinates are the top three wired failure points. One state-machine step astray and everything downstream breaks.
USB physical layer is a hidden pit
It is not just external HUB chips that cause trouble. If the head-unit's onboard USB controller (USB PHY) timing does not match the reference design, the handshake also fails. This pit is invisible at the design stage and only shows when you plug in a phone.
Touch-coordinate mapping
The point on the head-unit screen and the phone's response position must correspond. Resolution scaling, rotation switching and portrait/landscape adaptation all trip here. Portrait head units are especially prone — many apps default to landscape rendering.
3. The wireless extras
Tested only if wireless is claimed
Stated plainly: wireless-related testing applies only to products that claim wireless Android Auto support. A pure wired solution is exempt from this part — do not be led by "must support wireless".
The added dimensions
The wireless link is more complex than wired; verification splits into three blocks:
① Wi-Fi Direct connection stability.
② Bluetooth discovery and pairing completeness.
③ Wired-to-wireless link connectivity.
Switch drops, reconnect failures and audio/video stream breaks all count as failures.
Bluetooth is its own line
The head-unit side has its own Bluetooth certification; BQB listing is the precondition for using the Bluetooth trademark and is separate from Android Auto — they do not substitute, and schedules must be synchronised.
4. Audio-link judgement
Three channels do not fight
Call, media and navigation-prompt channels must each establish, switch and mix independently. Priority is call above navigation prompt above media; wrong pre-emption logic fails outright.
Decoding is on the phone side
In projection mode the audio is decoded on the phone; the head unit only handles the path and playback. Some projects treat the head unit's own surround-sound player as a certification item — that is the head unit's own capability, outside projection certification scope.
Notification sound is a separate channel
Notification prompts use an independent channel, not mixed with media. Incoming-call or navigation announcements auto-ducking volume are all tested.
5. Safety and driving restrictions
Speed-linkage is a hard gate
Functions that must be disabled while driving must be disabled. On the speed signal, video restriction must trigger correctly and the UI must switch to simplified mode. The Sensor Log block tests how the system degrades on anomalies like speed and gyroscope — fault tolerance is extremely low.
Voice over touch
In driving scenarios voice takes priority over touch — not a suggestion, a mandatory pass. Voice-trigger latency and microphone pickup quality are both assessed.
Notification display format
Notification display format must meet driving-safety rules. Implementations like group-chat spam filling the screen fail.
6. Stability and experience
Long continuous run
Four to eight hours of continuous projection, watching for memory leaks, CPU throttling and crash-reboot. Occasional reboots cannot hide in this long test.
Plug and disconnect loops
Wired runs heavy USB plug/unplug loops; wireless runs disconnect/reconnect loops. Frequent freezes, black screens and reconnect failures all fail. Insufficient power and out-of-spec cable impedance are the frequent root causes here.
Extreme conditions
(1) Hot parked cabin, cold start. (2) Voltage dip at engine crank, frequent ACC on/off. No disconnect is allowed under these conditions.
Noisy-environment voice
Wake rate, false-wake suppression, multi-turn understanding and response latency are all on this board. Noise recognition is done by the phone-side voice engine; the head unit handles microphone pickup and front-end processing — beamforming and echo cancellation directly affect pickup quality.
7. A few things before submission
Self-test and formal are different
The vendor's PCTS self-test tool runs 300-plus internal cases, which is a different thing from the CTS-Auto used for formal judgement — not a lite vs full version. AA 2.0 formal testing splits into seven blocks (CTS-Auto, Sensor Log, Qsuite, VRRT, Performance, Plugbot, AOAP), over 180 items combined; the 2026 CTS-Auto exceeds 200 automated cases, all must run in an authorised lab with a veto result. Do not treat a passing self-test as a tranquiliser — the two judgement scopes are not fully identical.
Freeze the firmware
Formal testing cannot change firmware mid-course; revision voids all data. The mass-production firmware must be finalised before submission.
How to configure test phones
Pixel is Google's designated reference test device and must keep the Google-specified GMS and Android Auto app versions. For broader compatibility, formal testing usually also brings Samsung, Xiaomi and other models for supplementary validation, also run in an authorised lab — not optional.
BlueAsia works on automotive infotainment and wireless certification and helps clients align Android Auto, BQB and national approvals in one schedule so rework at the test gate is avoided.
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!
相关新闻
