Car Connectivity from an App Developer’s Point of View Revisted
Two years ago, we compared the three car connectivity protocols Android Auto, Apple CarPlay and MirrorLink from an app developer’s point of view. Then, we concluded that there is none of the approaches has yet emerged as “the” standard. Further, we concluded that each approach has its drawbacks and its advantages. Often a trade-off between ease of integration and technical possibilites has to be made. Android Auto and CarPlay are easy to integrate, since the app only has to deliver content. On the other hand, MirrorLink has the most possiblities as the app can take control of the entire user interface. In this post, we want to both revisit the protocols and introduce new approaches.
Evolution of the Protocols
Evolution of Android Auto, CarPlay and MirrorLink
The protocols Android Auto, CarPlay and MirrorLink have only had minor changes since our last blog post on the topic. The main evolution is the availablity of the protocols in new car models. Almost every new model supports at least one major car connectivity protocol as the integration of smartphones into daily life has further increased during the last years.
A New Competitor: Smart Device Link
Smart Device Link (SDL) has originally been developed by Ford under the name “AppLink”. Ford decided to publish the standard and open it to other manufacturers. For this purpose, the Genivi Consortium was founded. The consortium is now the maintainer of both the SDL standard and the SDL reference implementation.
From an app developer’s point of view, SDL offers some great possibilites due to its architectural approach. Similar as Android Auto and CarPlay an SDL-enabled app only transmits content to the head unit, but SDL is not restricted to app types “Messaging” and “Audio”. SDL has a great variety of UI templates to be used by the app such as “Media Player”, “Text with buttons” and many more. The templates are filled with the content provided by the app and rendered on the head unit. The car manufacturer is responsible that the templates are designed in a way that meets all driving restrictions, e.g. sufficient text size. It also allows to seamlessly integrate the app content into the UI of the head unit. Therefore an app developer does not need to concern the specialities of in-car apps. Instead, he can focus on the development of the functionality of his app.
In contrast to MirrorLink, there is no global app certification, but each car manufacturer has to enable the apps for each of his car model separately using a policy table.
There are a couple of other proposals to car connectivity by various suppliers. One of them is Bosch mySPIN. It is the technology behind various car manufacturer’s connectivity solutions each released under a different name. Jaguar Land Rover’s InControl is an example of the use of mySPIN. In the Chinese market, there are some more proposals driven by the major Chinese internet companies such as Tencent and Alibaba.
An important factor in the selection of a car connectivity protocol is the availability of each protocol in the cars. Apple CarPlay and AndroidAuto currently have the greatest market share. Usually, a car model supports either both or none of them, as a manufacturer wants to be open for both Android and iOS users. From the other protocols, MirrorLink is currently supported most, followed by SDL and mySPIN. But – as concluded two years ago – there is still no technology that can be seen as “the” standard.
When evaluating a technology to be used in an app, also the time since the proposal of that technology has to be taken into consideration. MirrorLink, Android Auto and CarPlay are relatively old, i.e. have been proposed and published early after the first smart phones were available. Smart Device Link and mySPIN are relatively new. As the development of a new car generation usually takes a couple of years, it is no surprise that there is a significant delay between the publication of a connectivity protocol and the availablity in car models.
A recommendation what technology shall be used in an app depends on the app requirements. MirrorLink is the only technology that enables the app to take full control of the screen. Therefore MirrorLink is the only choice if an there are restricitve UI design specifications. If the exact screen layout is not of importance, then the decision depends on the functionality of the app. If the functionality can be mapped to one of the app classes provided by AndroidAuto or CarPlay, then this can be a good choice especially due to a high current availablity in various car models. For both apps that would suit AndroidAuto/CarPlay and for more general apps, Smart Device Link is a technology that has to be taken into serious consideration. It has currently a low availabilty in cars but has the high advantage that it comes with a general set of UI templates and the app only has to provide content. Also, it is very open and well documented thus ensuring ease of integration from an app developer’s point of view.
But finally, it is important to stress that no technology has yet emerged as “the” standard. Therefore – also as an app developer – it is important to keep an eye on the various technologies independet of the technology chosen to be supported by an app at the moment.