Well Sync was a Ford thing, not a Microsoft thing and Ford dontated they Sync specs it to GENIVI (see genivi.org). Ironically Sync does not work with Windows Phones -well at least not the app part, the basic stuff over BT does work.
They're not really after apps in embedded processors, are they? Like phones, if anything, I'd expect phone apps to run on separate application processors, They could interact with the car to an extent, but mostly via APIs that block the apos as necessary but never the car computers, even if the app procrssor or bridge go down.
Other than Android and Apple, there are several diverse systems viz QNX, Windows CE, Linux etc. present in available cars which manifests several years of experiences.
In General, Apple and Google are not car Tier-1's so them venturing into this area would be unimaginable as well as little less financially rewarding.
It would be interesting to hear how successful Google/Apple are with their offerings on CES 2014 towards Automotive infotainment. Apps integration into front unit would be a big draw if someone can bring it seemlesly into front.
MirrorLink/Miracast, Speech Integration, hands-free/eyes-free, Drivers assist, Audio/Video and Camera needs are so diverse that it may need different software trees altogether for Automotive Integration but these features would be key for any integrated solution.
We are psychlogically skewed to think smartphone integration into cars but that is little mixing up with overall car experience. We may additionally need to think of realtime part, safety and lifetime of the product.
I'm designing infotainment and digital dashboards for high-end cars. I switched recently (last year) to Linux for that, so switching to Android wouldn't be an issue for me. Smartphone integration is becoming crucial for 2014, but I don't see it as an open platform for anybody to develop apps for our embedded systems, it's just too dangerous.
I see more like something similar to a MirrorLink where the smartphone sends the graphics + sound to the car and the car sends the touch screen coordinates + driver voice to the smartphone. This way we don't have the responsibility of a SW bug/crash from the phone that could disturb the driver while he is drivng, it's all in the hands of the smartphone app developer.
With a mirro link, there's would be also the possibility to send send the phone graphics directly to the digital dashboard (instead of the infotainment display) in lieu and place of the rear-view camera, this is the only way for a smartphone to get to the driver dashboard without impacting too much all the safety issues related to this critical display. The rear-view camera is displayed as an independant graphic layer without impacting the dashboard CPU load. In that particular case, there's no direct user feedback (of course, there's no touchscreen behind the steering wheel).
In 10 years, all today smartphones will be completely obsolete, not the cars. the mirror link feature could still work with future smartphones, only the car display resolution will be somehow bulky.
iOS in our embedded systems is a no-go as of today, it's closed and we have absolutely no experience in iOS real-time SW development. But a mirror link could be compatible with iOS aswell as Android.
What are the engineering and design challenges in creating successful IoT devices? These devices are usually small, resource-constrained electronics designed to sense, collect, send, and/or interpret data. Some of the devices need to be smart enough to act upon data in real time, 24/7. Are the design challenges the same as with embedded systems, but with a little developer- and IT-skills added in? What do engineers need to know? Rick Merritt talks with two experts about the tools and best options for designing IoT devices in 2016. Specifically the guests will discuss sensors, security, and lessons from IoT deployments.