SmartDeviceLink (SDL)
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!
Documentation
- Software Architecture Document
- Transport Manager Programming Guide
- Software Detailed Design
- Integration Guidelines
- Evolution Proposals versus Issues
SDL Core
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.
Project Status
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.
Getting Started
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 outside of the source folder and run
cmake {path_to_sdl_core_source_folder}from the build folder you created - If there are any dependency issues, install missing dependencies
- Run the following commands to compile and install smartdevicelink
%make
%make install
Start SDL Core
Once SDL Core is compiled and installed you can start it from the executable in the bin folder
%cd bin/
%./start.sh
Start WEB HMI
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.
A quick note about dependencies
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.
Dependencies list
| Flag | Description | Dependencies |
|---|---|---|
| Web HMI | Use HTML5 HMI | chromium-browser |
| 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 |
Sample Policy Manager
The included sample policy manager (for use with EXTERNAL_PROPRIETARY policy mode) requires the following packages:
- python-pip
- python-dev
Known Dependency Issues
- 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
Required RPCs
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
Frequently Asked Questions
If you have any questions regarding the setup of SDL Core or regarding the integration of SDL into an infotainment system, first visit our SDL Core FAQ. If you still have questions, you can post a question in the core-help channel of our Slack group (sign up here)
Test Coverage
Used technologies
- 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.
Excluded folders
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.
Current test coverage
You can find it in Coverage report
How to get Test Coverage locally
- Build project with enabled flag -DBUILD_TESTS=on
- Execute command 'make test'
- Execute './tools/Utils/collect_coverage.sh <path_to_build_directory>'
Contributions
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.