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.
Drones are, in essence, flying autonomous vehicles. Pros and cons surrounding drones today might well foreshadow the debate over the development of self-driving cars. In the context of a strongly regulated aviation industry, "self-flying" drones pose a fresh challenge. How safe is it to fly drones in different environments? Should drones be required for visual line of sight – as are piloted airplanes? Join EE Times' Junko Yoshida as she moderates a panel of drone experts.