What is 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, Android / Java Suite, and JavaScript libraries are implemented by app developers into their applications to enable command and control via the connected head unit.
To suggest new features to SDL, including the iOS library, go to the SDL Evolution github project.
To understand if a contribution should be entered as an iOS Pull Request or Issue, or an SDL Evolution Proposal, please reference this document.

SDL iOS App Library

The mobile library component of SDL is meant to run on the end user’s smart-device from within SDL enabled apps. The library allows the apps to connect to SDL enabled head-units and hardware through Bluetooth, USB, and TCP. Once the library establishes a connection between the smart device and head-unit through the preferred method of transport, the two devices are able to communicate using the SDL defined protocol. The app integrating this library project is then able to expose its functionality to the head-unit through text, media, and other interactive elements.

You can find guides and documentation on how to use this library at the SmartDeviceLink website. You can find the upcoming releases roadmap at the SDL Evolution Github.

Installing

To install this library as a framework in your app, see the Installation Guide. There are instructions on how to install using the dependency managers CocoaPods, Carthage, and Accio, as well as how to install the library framework manually.

Adding a Dynamic Framework

Tagged to our releases is a dynamic framework file that can be drag-and-dropped into the application. Dynamic frameworks are supported on iOS 8+. WARNING: You cannot submit your app to the app store with the framework as is. You MUST strip the simulator part of the framework first. Strip the x64 and i386 portions first like so:

lipo -remove i386 -remove x86_64 -o SmartDeviceLink.framework/SmartDeviceLink SmartDeviceLink.framework/SmartDeviceLink

You can check the current architectures like so:

lipo -info SmartDeviceLink.framework/SmartDeviceLink

Getting Help

If you have questions, first view our guides on the SmartDeviceLink website.

If you see a bug, please post an issue on the appropriate repository. Please see the contribution guidelines before proceeding. If you need general assistance, or have other questions, you can sign up for the SDL Slack and chat with other developers and the maintainers of the project.

Example Apps

This library repository contains two example apps: one written in Objective-C and one in Swift. If you have CocoaPods installed, you can easily run one of the example apps by executing pod try SmartDeviceLink in your terminal. Alternatively, you can clone or download the project, but before attempting to build and run the example apps you must follow the installation steps.

There are additional example apps available in the example organization, these require CocoaPods to install dependencies.

Contributing to the Project

We welcome contributors to the project, but it helps to know a few things about how the project is organized.

All Pull Requests must fix an issue. Before creating a PR for a bug or feature, ensure that there is an open issue for it. If there is not, open one!
We recommend telling the project maintainers that you intend to contribute a PR for an issue. This allows us to internally track what PRs will be contributed and to plan time to review your PR. Furthermore, we may ask you not to work on a PR for that issue for various reasons (see below).
We welcome PRs for bug fixes! If there's a confirmed issue for a bug, we would welcome a bug fix. The PR will require a review from a project maintainer before it can be merged.
PRs for features require additional planning. Features must be approved by the SDLC using the Evolution Process before an issue can be opened. Furthermore, a feature must be approved to be developed for a release by the SDLC before a PR can be opened. Finally, a PR cannot be merged if the underlying feature requires or should have alignment across multiple projects until PRs for all those projects are ready for review.

Preparing for Development

To prepare the library for development, you will need to take a few steps:

Clone this repository.
Install submodules with git submodule init and git submodule update.
Install testing dependencies.
Ensure that you can run the Example test apps.

Creating or Updating an RPC

When creating or updating an RPC, you will need to install and use the RPC generator. The generator must be used to ensure that the content is correct. To use the generator, the RPC must be updated on the RPC spec repository.

Running Tests

To run tests, you will need to bootstrap the Carthage testing libraries. To do so, first install Carthage.

Then, from the root project directory, run:

carthage bootstrap --platform ios
cd ../

At this point, you can run tests from Xcode, or, if you wish to run the tests exactly as they will be run on the CI server, run:

xcodebuild build-for-testing -project SmartDeviceLink-iOS.xcodeproj -destination platform=iOS Simulator,name=iPhone 11,OS=13.5 -scheme SmartDeviceLink

set -o pipefail && xcodebuild test-without-building -project SmartDeviceLink-iOS.xcodeproj -destination platform=iOS Simulator,name=iPhone 11,OS=13.5 -scheme SmartDeviceLink -configuration Debug ONLY_ACTIVE_ARCH=NO RUN_CLANG_STATIC_ANALYZER=NO GCC_INSTRUMENT_PROGRAM_FLOW_ARCS=YES GCC_GENERATE_TEST_COVERAGE_FILES=YES ENABLE_TESTABILITY=YES

Lock Screen Screenshot Tests

We run some additional tests using iOSSnapshotTestCase. These tests generate the lock screen view controller and compare it to generated screenshots. By default, the generated screenshots use the iPhone 11 simulator and if you run the unit tests on that simulator, the tests should pass by default.

Re-Generating Lock Screen Screenshots

If you need to change which simulator is used to generate the screenshots, or if you need to re-generate the screenshots for another reason, you can. Go to SDLLockScreenViewControllerSnapshotTests.m and take the following steps:

Uncomment the following line:

// self.recordMode = YES;

Run unit tests on the simulator that you want to use to generate the screenshots. Tests should fail because record mode is on.
Re-comment out the line.
Run unit tests again; they should pass this time.

codelynx/sdl_ios