There needs to be a lot more to it than just screen monitoring, it needs to recognise touch inputs, high-fidelity, low-latency audio (both ways), and importantly the car needs to be able to send information back to the device (is the handbrake on, are the headlights on, etc). That requires integration from the carmaker.
Open source solutions at the moment cannot be used with in-car infotainment, because of that requirement that the car needs to send information to the device. I think there should be an open protocol for this that all cars implement.
the car needs to be able to send information back to the device (is the handbrake on, are the headlights on, etc).
I use Android Auto every single day, and I genuinely don’t know what you’re talking about. I also used it on rental vehicles for years when I was traveling for work, so it’s not that my current daily driver is just old. I have never seen information sent from the vehicle to my phone, and certainly never needed it.
Zooming out a bit, why would my vehicle need to send data to my phone? Even your examples (handbrake, headlights), are those actually necessary? Of course not.
I use android auto every day too, and it absolutely does those things.
When you turn your headlights on (I.e.when it’s dark) the android auto display goes from light mode (so you can see it even in blaring sunshine and wearing sunglasses) to dark mode (so it doesn’t blind you when it’s dark). It doesn’t do this via magic, it does it because the car sends that information to your phone.
Android auto also will not let you perform some functions while driving. It does this by detecting your handbrake. This is a legal requirement in many jurisdictions.
There’s also more minor things like the car telling the phone whether it’s RHD or LHD and altering the UI accordingly.
So respectfully, you are wrong. Not only is it useful, but it’s sometimes a legal requirement. And Android Auto already uses data sent by the car.
There needs to be a lot more to it than just screen monitoring, it needs to recognise touch inputs, high-fidelity, low-latency audio (both ways), and importantly the car needs to be able to send information back to the device (is the handbrake on, are the headlights on, etc). That requires integration from the carmaker.
Open source solutions at the moment cannot be used with in-car infotainment, because of that requirement that the car needs to send information to the device. I think there should be an open protocol for this that all cars implement.
I use Android Auto every single day, and I genuinely don’t know what you’re talking about. I also used it on rental vehicles for years when I was traveling for work, so it’s not that my current daily driver is just old. I have never seen information sent from the vehicle to my phone, and certainly never needed it.
Zooming out a bit, why would my vehicle need to send data to my phone? Even your examples (handbrake, headlights), are those actually necessary? Of course not.
I use android auto every day too, and it absolutely does those things.
When you turn your headlights on (I.e.when it’s dark) the android auto display goes from light mode (so you can see it even in blaring sunshine and wearing sunglasses) to dark mode (so it doesn’t blind you when it’s dark). It doesn’t do this via magic, it does it because the car sends that information to your phone.
Android auto also will not let you perform some functions while driving. It does this by detecting your handbrake. This is a legal requirement in many jurisdictions.
There’s also more minor things like the car telling the phone whether it’s RHD or LHD and altering the UI accordingly.
So respectfully, you are wrong. Not only is it useful, but it’s sometimes a legal requirement. And Android Auto already uses data sent by the car.
That’s why alternative solutions don’t exist.