Quote:
Originally Posted by MightyBobo
As a software developer, I disagree. If you ship a vehicle with something like that, where it actually has to do more legwork to render and display stuff, you're at the mercy of the manufacturer to keep it updated.
The "best" solution, IMHO, is to provide a ubiquitous API that allows EITHER Android Auto or Apple Car Play to interface with it, that is REGULARLY updated OTA. That way it's simple for either system to: broadcast information to the HUD/DIC, interface with the car's controls, etc. It also offloads the actual processing power and rendering to your phone which is - how convenient! - frequently regularly updated, as most phones now have a 3+ year update commitment from manufacturers, as well as people's own ravenous need to upgrade their phones on a 1-2 year basis.
Put the need to process and render data onto the phone, and simply have the infotainment system be a gateway for the phone to display said data onto it.
Another option to preserve what you describe? Standardize an interface, and make swappable modules that allow you to upgrade your car's infotainment system relatively easily, like upgrading the RAM or HD in your laptop. The problem manufacturers have with this is that it simply lessens your desire to upgrade to the latest and greatest car. They have no desire for you to KEEP your car any longer, so they purposefully make it such that you want to upgrade.
|
As a fellow developer, let me disagree a bit. I see your point about the ubiquitous API, and such an open solution would be very nice, but it's unrealistic from an economic, rather than technical, perspective. As you say, car companies couldn't care less about open APIs that actually allow people to keep their older cars and just swap their phones, which is a fact, although not quite obvious, because keeping people in the dealership's service bay must be pretty lucrative, too, even compared to having them lease or buy once every 3-5 years, so there would be a business model there as well.
What would be realistic, though, is an infotainment where even the development effort is offloaded to the phone OS vendor, because then they can operate as a supplier and entire internal dev teams can be laid off at the car maker ("yay, we're saving $$$"). Now, at this point, is it in Google's or Apple's best interest to create the API you talked about, of course not, they will just want to lock you into their newly broadened ecosystem.
Actually, even AA or Carplay could function as the system you described, if they weren't so incredibly limited, which I'm sure is on purpose, too (okay, there are 2 separate APIs instead of the ubiquitous 1 you asked for, but it's still manageable). One can't even get a Torque for Android Auto app, for example. Instead, they are moving towards supplying the entire infotainment platform.