This is an overview of how SmartDeviceLink (SDL) works. It will go through higher level discussions about certain aspects of SDL to give an intro level of understanding. For more general information on SmartDeviceLink (SDL) as a technology, there is a white-paper available here.
SmartDeviceLink is a connectivity protocol and set of associated libraries that allow third-party applications to communicate with cars. This allows drivers to safely access the content they want through their vehicle.
There are different components to SDL that make everything work. The following diagram shows how some of those pieces are connected.
This section quickly points out which platforms can be used for the application, Core, and HMI parts of the project.
The first few guides will be centered around getting SDL started.
This section describes the lowest level of SDL. It defines how the byte level data is communicated between the application library and the head unit / Core. It contains information on what protocol level packets are used, basic handshakes, etc.
This section describes the higher level JSON-RPC messages that get sent. These messages are higher-level messages sent using the protocol spec's lower level messages (see above). The majority of messages that get sent between the app and head unit are RPC messages. The RPC messages contain information to perform and respond to actions, notify of events, etc. The RPC spec defines much of what SDL can do.
This section describes how the SDL platforms use a code generating script to create RPC classes from the RPC Spec.
SmartDeviceLink uses policies to enforce rules about which messages can be sent to and from connected apps. This section will give an overview of that functionality and how to update the policy table, which declares these policies for all known apps.
Connected applications can augment a head unit's service offerings (such as navigation and weather) using SDL. Head units can feed the service specific information into their own system as a unified API for that app service type. This includes displaying service data outside the app's template view and makes that app feel integrated directly with the head unit.
This section contains items that aren't hard requirements but are best practices to ensure that the widest variety of apps work properly with your head unit.
This section covers a few of the commonly asked questions around SDL.View on GitHub.com