Which assistant owns the steering-wheel voice button?

The same button can reach a different assistant

Connect an iPhone to a car, open CarPlay, and hold the steering-wheel voice button. The button still belongs to the car. The assistant answering the request can belong to the phone.

Volvo makes that distinction in its Canadian V60 Cross Country 2025 manual: with CarPlay active, a long press invokes Siri instead of the vehicle's built-in assistant. Its Android Auto instructions assign a long press to Google Assistant while Android Auto is active. These are two documented destinations for the same physical control under different conditions. [1][2]

For a cockpit integration team, the useful acceptance criterion is whether the intended assistant receives the request in the current connection state. Hearing a listening tone establishes much less. A test must identify the responding assistant before it judges the command that follows.

This is a reading of Volvo's Canadian support documentation, checked on 19 October 2026, not a vehicle test. The Android Auto page was updated on 22 July 2026; the CarPlay page on 1 August 2025. Those dates describe documentation revisions. They do not establish which software an individual vehicle has installed.

Three routes, with different evidence

The built-in voice-control documentation describes an assistant that handles media, phone, navigation and climate tasks. It also warns that availability and behavior can change with region and over time, and that connectivity can limit functions. It supplies no command-by-command guarantee for every installed media service. [3]

The two phone-projection pages are more specific about the button:

The last row is a gap in the cited instructions, not evidence of a defect. A team still needs an explicit product decision for that state.

Both projection pages retain access to the vehicle's own interface through bars around the projection view. A driver therefore has more context than a binary “phone connected” flag. An integration test should distinguish a paired phone, an active projection session and the interface currently visible. The manual ties the long-press behavior to active projection; Bluetooth pairing alone is not the stated condition. [1][2]

The separate Bluetooth instructions allow several saved pairings but describe only one connected phone at a time. That is a Bluetooth connection rule, not an arbitration rule for two simultaneous projection sessions. Record the active transport and session rather than inferring them from the saved-device list. [4]

The steering-wheel controls page also identifies voice control among the right-hand controls and says that button functions depend on context. That overview locates the input; the projection-specific pages establish the long-press destination. A test specification needs both levels of detail. [5]

A disconnect during a long press

Consider a proposed bench test: start with CarPlay active, begin holding the voice button, then disconnect the phone before releasing it. This scenario is hypothetical. Volvo's cited pages do not specify what the vehicle does.

A team could route the gesture according to the state at button-down, at the long-press threshold, or at release. Each choice requires different recovery behavior. If the implementation selects the phone at the threshold and that session disappears, forwarding the same request to the built-in assistant could give the driver a different service than the one they invoked.

My proposed rule is to select a destination once per invocation and cancel with explicit feedback when that destination becomes unavailable. The feedback must work without requiring the driver to read a screen; its exact sound or wording needs a separate usability review. Let the driver start a new invocation after the system communicates the changed connection state. This adds an interruption, but avoids a silent handover to another assistant. It is a design recommendation, not a description of Volvo's implementation.

For that test, record the press and release times, projection-session changes, selected destination and first visible or audible response. Then check whether one invocation reached more than one assistant. A generic “voice succeeded” result would conceal that distinction.

Separate routing from media execution

After confirming the destination, test the requested action. Opening a media app, resuming playback and selecting a named channel are different operations. A successful first operation does not establish support for the others.

That separation also limits what an engineer can conclude from a driver report. If a driver hears an acknowledgement but the channel does not change, several parts of the transaction remain unobserved: which assistant responded, which player received the request, and whether that player supports the requested selection. The acknowledgement alone cannot locate the failure.

Keep the two acceptance records separate: one for reaching the intended assistant, another for the resulting media state. Add the exact car and phone software versions to both. That gives a regression team a reproducible boundary when a phone update changes behavior without changing the steering-wheel hardware.