Apple’s next generation CarPlay allows auto manufacturers to license the OS | Don’t look now but Apple is back to licensing an operating system after decades::undefined
Apple’s next generation CarPlay allows auto manufacturers to license the OS | Don’t look now but Apple is back to licensing an operating system after decades::undefined
Hijacking this somewhat related topic:
There needs to be a standardised set of APIs that automakers comply to for smartphone-powered infotainment.
Right now you have zero choice. iPhone: you can use carplay and nothing else. Android: you can use Android Auto and nothing else.
There can’t be any competition because it’s locked down.
Car infotainment systems need an open protocol for display, sending touch/control knob information back to the phone, sending other info back from the car, like mic audio for voice assistants/calls, whether the headlights are on to switch between light/dark mode, whether the car is LHD/RHD to reorganise the on-display controls, etc.
That would be awesome, but who’s going to push for it?
It’s easy for the opponents to use safety as a case for why users shouldn’t have control of the software in their car.
The manufacturers already want to get rid of ODB because they’d rather control that data themselves.
At least android auto has been reverse engineered, and doesn’t currently require any sort of difficult-to-bypass hardware attestation.
Honestly, it’s probably not happening unless the EU forces it :/
And if the EU forces it apple will find the shittiest way to “comply” just to be dicks. Then the fanboys will still defend them and buy their insanely overpriced bullshit.
Yep , auto manufacturers needs incentive to develop a open protocol such as this. Its not a easy task as this would need to be complaint with many regulations and safety standards. I have some hope for the SDV (software defined vehicle) future like COVESA where the industry is moving towards an opensource architecture but for user softwares you’re right its totally with the manufacturer to allow such open api to users.
Exactly.
The path forward with this kind of thing is for a defacto standard to emerge from out of left field, which is ever more challenging today, since auto manufacturers began integrating the head unit 2 decades ago (they saw what was coming, and took the opportunity to lock out third party stereo systems by integrating everything). Basically a push for vertical integration.
I don’t know how to accomplish this given the vertical integration the manufacturers have developed. I do know regulation is the worst possible way, and should only be used as a last-ditch effort, because that’s when you get malicious compliance and basically garbage results.
Seems CANBUS and OBDII provide an opening to these systems - for years I’ve wanted to utilize this connection to modify some car behaviour. Like the remote start on one car will only run for 7 minutes. That’s a joke, it takes 30 minutes to get the half inch of ice off, and that’s with me out there chipping at it too. Or how the heat/ac controls are fixed on remote start, and I’d like it to go max defrost/max fan immediately, and turn on the rear defroster. If we knew the signaling of this vehicle’s CANBUS for these things, seems we could build a plugin module with wifi/Bluetooth and control it from a phone.
And if we have such a module, the manufacturers would have to react to it.
As a side note, I don’t use or want a car play system. I’ve yet to find a use for it, I dislike massive screens in cars as it is, and those systems age fast anyway (I keep my cars a very long time).
I installed a mapping head unit in my car in 2010. It was alright, but even then the phone was just simpler to use, and the screen was more than sufficient (and a better display too). Since then I’ve had probably 4 phones, numerous OS and app upgrades, with the exact same head unit still in place (my car is now 18 years old, I intend to keep it at least another 10). My current phone blows away that head unit screen (I just recently put the factory, no-screen unit back in).
The fixed nature of car stuff is a major problem, and why I’m pretty indifferent to car play stuff. People need to stop replacing their cars - today’s vehicles can last a very long time - my 18 year old car has 270k miles on it, and I would drive it cross-country right now. Using my phone for GPS, music, podcasts, whatever.
Isn’t this just QNX?
QNX is a real-time operating system, and it is not open. QNX is not a network accessible API.
I don’t know what you’re referring to.
But no, I don’t see an open protocol for car infotainment that any 3rd party dev can utilise to make an alternative to Android Auto/CarPlay
E: by the looks of it, QNX is just a mostly closed source base software that BlackBerry licences out to automakers, and runs entirely on the cars, not phones.
I’m talking phone-powered infotainment that goes on the car display. Like CarPlay/Android Auto.
I’m not sure I follow. Are you looking to add any app to your phone that would fulfill the CarPlay features like maps/music/phone on the car’s display? I’m only using Apple’s OS these days so I can’t speak to Android, but presently you can use any music app, any maps app, and any communications app that supports Apple’s API. Are you saying you want other apps to be able to send that experience to the car, and/or are you looking for a FLOSS system to run on the car itself?
Right now, Apple and Google each have their own proprietary system for communicating with cars and showing their system.
If a new smartphone OS came out, or, say, Samsung wanted an Android Auto alternative, it wouldn’t work on any existing cars, and even for new cars, they’d perhaps struggle to get automakers on board in supporting them.
I want that back end that exists on cars to be replaced with an open, standardised system that Apple, Google and anybody else that wants to can use to provide a CarPlay/Android Auto-like experience.
Gotcha. That kind of thing will have to be mandated by our governments because no automaker has anything to gain from that kind of open system.
Friend…I don’t think you know exactly what you’re talking about here, because you’d want a standardized API running ON THE CAR as an interface for what you describe. Client -> API -> Control.
Also, QNX is a real-time OS bought by Blackberry back in the day. It literally runs the car (most models on the road), so would probably interface with whatever to control things at some point.
With respect, yes I do.
Yes, I know. That’s what I said, see:
“There needs to be a standardised set of APIs that automakers comply to for smartphone-powered infotainment.”
Notice I said automakers. That means on the car…
Then I said:
“Car infotainment systems need an open protocol for [blah blah blah]”
I’m clearly talking about the car…
Yes, which is a completely different thing to Android Auto or CarPlay.
The fact that lots of cars run some BlackBerry software is completely unrelated to my belief that there should be an open set of standards for phone-connected car infotainment to facilitate options from more than just Google and Apple. Because as of right now they hold a captive market.
Nice edits there 😂
My point is you’re using words that you clearly don’t know the context of. You can say open this or that all day long, but you very clearly do not understand what QNX is, how it runs, or what it runs. You therefore don’t understand the comment you replied to, which I explained for you in my reply, which you then replied with the some gibberish you don’t understand, because you don’t understand what an API is or where it should run.
Now, let’s say some uniformity comes into existence by an ISO/ISSA or 20022 group that makes a generic framework of calls clients can make to control whatever in a car. Then automakers need to define the backend controls for direct hardware interfaces, which would not be universal since any car models will have different parts. The translation layer there needs to run on something directly connected to the car hardware. This is what QNX does. If there was a shift away from something like an RTOS as a controller mechanism, you’d still need whatever the control layer runs on to be able to directly interface with the hardware. You can just call something an API and then wave your hands around like you know what you’re saying, but not understanding how it all fits together.
My edits changed a few spellings/grammar. Where there was an addition, I used an “E:” tag.
No, you completely misunderstood my comments then said I don’t understand.
It’s you who isn’t understanding. Trying to pull an umm ackshully☝️🤓 only to get it wrong.
My comments were very clear.
And I’m a full stack web developer who does bits on the side for various Linux-related projects. Yeah, I know what an API is.
Go feign intelligence to somebody else, I can’t be bothered with this useless, unrelated chatter. It’s not what I made my comment for.
Pick one
But really, I actually work on automotive firmware and you’re entirely correct.