SmartDeviceLink (SDL) is a standard set of protocols and messages that connect applications on a smartphone to a vehicle head unit. This messaging enables a consumer to interact with their application using common in-vehicle interfaces such as a touch screen display, embedded voice recognition, steering wheel controls and various vehicle knobs and buttons. There are three main components that make up the SDL ecosystem.
- The Core component is the software which Vehicle Manufacturers (OEMs) implement in their vehicle head units. Integrating this component into their head unit and HMI based on a set of guidelines and templates enables access to various smartphone applications.
- The optional SDL Server can be used by Vehicle OEMs to update application policies and gather usage information for connected applications.
- The iOS and Android libraries are implemented by app developers into their applications to enable command and control via the connected head unit.
Pull Requests Welcome!
- Software Architecture Document
- Transport Manager Programming Guide
- Software Detailed Design
- Integration Guidelines
- Evolution Proposals versus Issues
The Core component of SDL runs on a vehicle's computing system (head unit). Core’s primary responsibility is to pass messages between connected smartphone applications and the vehicle HMI, and pass notifications from the vehicle to those applications. It can connect a smartphone to a vehicle's head unit via a variety of transport protocols such as Bluetooth, USB, Android AOA, and TCP. Once a connection is established, Core discovers compatible applications and displays them to the driver for interaction via voice or display. The core component is implemented into the vehicle HMI based on the integration guidelines above. The core component is configured to follow a set of policies defined in a policy database and updated by a policy server. The messaging between a connected application and core is defined by the Mobile API and the messaging between sdl core and the vehicle is defined by the HMI API.
We're ramping up our efforts to get SmartDeviceLink developed and maintained directly in the open. For the Mobile libraries, we're expecting better integration soon, SDL Core is slightly more complicated. We are currently working on generating documentation, creating a developer portal, an open forum, Mobile validation, and everything else that we've been asked for to renew the community's interest in this project. From a technical standpoint, SDL is stable, and the most work is being put into making it a more robust solution for app connectivity. We are, however, definitely looking for and interested in other people and company's contributions to SDL whether it be feature based, bug fixes, healthy conversation, or even just suggestions for improvement.
A quick guide to installing, configuring, and running an instance of the SDL Core on a linux OS.
- Clone this repository
- Create a folder for your build and run
cmake ../sdl_core - If there are any dependency issues, install missing dependencies
- Run the following commands to compile and install smartdevicelink
%make
%make install
Once SDL Core is compiled and installed you can start it from the executable in the bin folder
%cd bin/
%./start.sh
Web HMI is separated from SDL Core and located in another repository. So to make it workable please do next steps.
- Clone http://github.com/smartdevicelink/sdl_hmi.git
- Follow the instruction from readme file in sdl_hmi repository.
The dependencies for SDL Core vary based on the configuration. You can change SDL Core's configuration in the top level CMakeLists.txt. We have defaulted this file to a configuration which we believe is common for people who are interested in getting up and running quickly, generally on a Linux VM.
| Flag | Description | Dependencies |
|---|---|---|
| Web HMI | Use HTML5 HMI | chromium-browser |
| DBus | Use DBus HMI Adapter | dbus-1-dev |
| EXTENDED_MEDIA_MODE | Support Video and Audio Streaming | Opengl es2, gstreamer1.0* |
| Bluetooth | Enable bluetooth transport adapter | libbluetooth3, libbluetooth-dev, bluez-tools |
| USB | Enable USB transport adapter | libusb-dev |
| Testing framework | Needed to support running unit tests | libgtest-dev |
| Cmake | Needed to configure SDL prior to compilation | cmake |
The included sample policy manager (for use with EXTERNAL_PROPRIETARY policy mode) requires the following packages:
- python-pip
- python-dev
- log4cxx - We know that the version of log4cxx on a linux machine can conflict with the one used, which is why it is provided in the repository. To avoid the conflict, we recommend removing liblog4cxx*.
- cmake - on some versions of linux, the included cmake package doesn't have the right version. If apt-get is your package manager, you can find the correct version using
sudo apt-get install cmake
sudo add-apt-repository ppa:kalakris/cmake
sudo apt-get update
sudo apt-get upgrade
There are several RPCs that are "required" to be implemented in order for SDL to work across vehicle manufacturers and applications, listed below. The RPC specification can be found in the Mobile API Spec.
- RegisterAppInterface
- UnregisterAppInterface
- SetGlobalProperties
- ResetGlobalProperties
- AddCommand
- DeleteCommand
- AddSubMenu
- DeleteSubMenu
- CreateInteractionChoiceSet
- PerformInteraction
- DeleteInteractionChoiceSet
- Alert
- Show
- SetMediaClockTimer
- SubscribeButton
- UnsubscribeButton
- ChangeRegistration
- GenericResponse
- SystemRequest
- OnHMIStatus
- OnAppInterfaceUnregistered
- OnButtonEvent
- OnButtonPress
- OnCommand
- OnDriverDistraction
- OnPermissionsChange
- OnLanguageChange
- OnSystemRequest
- Speak
- GCOV - test coverage program.
- LCOV - graphical front-end for GCC's coverage testing tool for gcov.
- codecov.io - service for assembling code coverage and representing it in a clear for reading form.
We test only sources written by us and we don`t need to test external sources(open source libraries).
- '/usr/*' - local libraries shouldn`t be covered by tests.
- '*/test/*' - we don`t need to cover tests.
- '*/src/3rd*' - open source libraries shouldn`t be covered by tests.
You can find it in Coverage report
- Build project with enabled flag -DBUILD_TESTS=on
- Execute command 'make test'
- Execute './tools/Utils/collect_coverage.sh <path_to_build_directory>'
Conversation regarding the design and development of SmartDeviceLink technology should be directed at the GENIVI mailing list, which anyone can join. Public conference calls regarding the SmartDeviceLink technology will be announced to the GENIVI mailing list, we expect to have conversations every other week. We also encourage interested parties to write issues against our software, and submit pull requests right here in the GitHub repository.