There's a protobuf-based API for two-way communication between the Android Auto app and the head unit [0]. It depends on what the headunit supports, but this includes data such as GPS location, steering wheel button activation, accelerometer data, parking brake activation, gear selection, touch screen input, dimmer switch position, odometer, and much more.

A lot of this has obvious use within the AA interface; for example, the parking brake position is used to prevent scrolling too far through lists, and the car's GPS is usually much more accurate than the phone's and better on the phone battery.

0: https://github.com/f1xpl/aasdk/tree/development/aasdk_proto (pretty old reverse-engineering effort)

▲

hamburglar 4 hours ago | parent [-]

One of the things I notice CarPlay has access to is the fan speed. In one of my vehicles, when I say “hey siri” it turns the HVAC fan down so it can hear me better. I’ve always wondered if the interface is the phone telling the car “hey make things quieter” or if it’s explicitly turning the fan down. It’s also interesting that this only happens in one of my cars. I assume it’s because the other car is a higher end vehicle and has a quieter fan.

▲

dmitrygr 3 hours ago | parent [-]

In GM cars (as observed in my last few), the logic is in the head unit: "mic on -> hvac lower", while "hotword detect" uses a different "mic on" method that does not

EDIT, previously "does not" above said "doe snot", which explains the reply below

▲

addaon 3 hours ago | parent [-]

I'm sure it's not great, but deer mucus is a bit of an extreme description.

	▲	tadfisher 2 hours ago \| parent \| next [-]
		I appreciate this comment, FWIW.
	▲	dmitrygr an hour ago \| parent \| prev [-]
		I never learned to properly touch type, i have my own method, somehow, which uses two fingers of the left hand and three of the right. Spacebar being pressed too soon or too late is, sadly, common :(