Note: this is a work in progress. I will remove this note when I believe this document is accurate
The SmartDeviceLink protocol specification describes the method for establishing communication between an application and head unit and registering the application for continued communication with the head unit
All transported data is formed with a header followed by an optional payload. The combination of header and payload is referred to as a frame.
| Byte 1 | Byte 2 | Byte 3 | Byte 4 | ||
|---|---|---|---|---|---|
| Version | C | Frame Type | Service Type | Frame Info | Session ID |
| Byte 5 | Byte 6 | Byte 7 | Byte 8 |
|---|---|---|---|
| Data Size | |||
| Byte 1 | Byte 2 | Byte 3 | Byte 4 | ||
|---|---|---|---|---|---|
| Version | E | Frame Type | Service Type | Frame Info | Session ID |
| Byte 5 | Byte 6 | Byte 7 | Byte 8 |
|---|---|---|---|
| Data Size | |||
| Byte 9 | Byte 10 | Byte 11 | Byte 12 |
|---|---|---|---|
| Message ID | |||
| Field | Size | Description |
|---|---|---|
| Version | 4 bit |
Protocol Version 0x1 Protocol version 1 - uses a version 1 Frame Header 0x2 Protocol version 2 - uses a version 2 Frame Header 0x3 Protocol version 3 - uses a version 2 Frame Header 0x4 Protocol version 4 - uses a version 2 Frame Header 0x5 - 0xF Reserved |
| C | 1 bit | Compression Flag 0x0 This packet is not compressed 0x1 This packet is compressed Note: Only available in Protocol Version 1 |
| E | 1 bit | Encryption Flag 0x0 This packet is not encrypted 0x1 This packet is encrypted Note: Only available in Protocol Version 2 |
| Frame Type | 3 bit |
0x00 Control Frame 0x01 Single Frame 0x02 First Frame 0x03 Consecutive Frame 0x04 - 0x07 Reserved |
| Service Type | 8 bit |
0x00 Control Service 0x01 - 0x06 Reserved 0x07 Remote Procedure Call (RPC) Service 0x08 - 0x09 Reserved 0x0A PCM Service 0x0B Video Service 0x0C - 0x0E Reserved 0x0F Bulk Data (Hybrid Service) 0x10 - 0xFF Reserved |
| Frame Info | 8 bit |
Frame Type = 0x00 (Control Frame) 0x00 Heartbeat 0x01 Start Service 0x02 Start Service ACK 0x03 Start Service NACK 0x04 End Service 0x05 End Service ACK 0x06 End Service NACK 0x07 - 0xFD Reserved 0xFE Service Data ACK 0xFF Heartbeat ACK Frame Type = 0x01 (Single Frame) 0x00 - 0xFF Reserved Frame Type = 0x02 (First Frame) 0x00 - 0xFF Reserved Frame Type = 0x03 (Consecutive Frame) 0x00 Last Frame 0x01 - 0xFF Frame Number |
| Session ID | 8 bit | The session identifier |
| Data Size | 32 bit |
Frame Type = 0x00 (Control Frame) 0x0 - 0xFFFFFFFF reserved. Frame Type = 0x02 (First Frame) 0x08 The data size for a first frame is always 8 bytes. In the payload, the first four bytes denote the Total Size of the data contained in all consecutive frames, and the second four bytes denotes the number of consecutive frames following this one Frame Type = 0x01 or 0x03 (Single or Consecutive Frame) The total bytes in this frame's payload |
| Message ID | 32 bit | The message identifier, used to uniquely identify this message |
Required: All Protocol Versions
A physical transport must be established between a head unit and an application.
Required: All Protocol Versions
Once a transport is established, each application must negotiate the maximum supported protocol version with the head unit. To establish basic communication and register with the head unit, the application must start an RPC service (Service Type: 0x07), using a Version 1 Protocol Header.
| Version | C | Frame Type | Service Type | Frame Info | Session Id | Data Size |
| no | Control | RPC | Start Service | |||
| 0b0001 | 0b0 | 0b000 | 0x07 | 0x01 | 0x00 | 0x00000000 |
If the head unit can start the RPC service it will respond with a Start Service ACK containing its maximum supported protocol version. If its maximum supported version is 1, the packet will contain an 8 byte header, otherwise it will contain a 12 byte header. From this point forward, the application is expected to use the minimum of the head unit's maximum supported version, and its maximum supported version. The payload of the Start Service ACK will contain a hash of the service which was started on the head unit if the payload size is greater than 0. This hash should be stored by an application and is needed in the end communication flow.
| Version | E | Frame Type | Service Type | Frame Info | Session Id | Data Size | Message ID |
| no | Control | RPC | Start Service ACK | ||||
| 0b0100 | 0b0 | 0b000 | 0x07 | 0x02 | 0x00 | 0x00000000 | 0x00000000 |
If a session has already been started, or can't be started, a NACK will be sent in response to the Start Service packet.
| Version | E | Frame Type | Service Type | Frame Info | Session Id | Data Size | Message ID |
| no | Control | RPC | Start Service NACK | ||||
| 0b0100 | 0b0 | 0b000 | 0x07 | 0x03 | 0x00 | 0x00000000 | 0x00000000 |
Required: All Protocol Versions
Each application registers for continued communication with the head unit by sending a RegisterAppInterface Request RPC to the head unit via the RPC Service. Additional services can only be started after a successful RegisterAppInterface Response RPC has been sent from the head unit to the application.
Required: Protocol Versions 3 and higher
After an application registers successfully
Messages sent have a priority based on their Service Type. Lower values for service type have higher delivery priority. A message's payload's format is based on the different service types defined below.
Required: All Protocol Versions
The RPC service is used to send requests, responses, and notifications between an application and a head unit. Valid messages are defined in the RPC Specification.
The payload of a message sent via the RPC service, which directly follows the Frame Header in the packet, consists of a Binary Header, and JSON data representing the RPC.
| Binary Header |
| JSON Data |
Available: Protocol Version 2 and greater
| Byte 1 | Byte 2 | Byte 3 | Byte 4 | |
|---|---|---|---|---|
| RPC Type | RPC Function ID | |||
| Correlation ID | ||||
| JSON Size | ||||
| Field | Size | Description |
|---|---|---|
| RPC Type | 4 bit |
0x0 Request 0x1 Response 0x2 Notification 0x3 - 0xF Reserved |
| RPC Function ID | 28 bit | The Function ID of each RPC is specific to each version of the RPC Specification but in general do not change from version to version. |
| Correlation ID | 32 bits | The Correlation ID is used to map a request to its response. In Protocol Version 1, when the Binary Header did not exist, the Correlation ID was included as part of the JSON and has a max value of 65536 |
| JSON Size | 32 bits | The size of the JSON Data following the Binary Header in the RPC Payload |
Required: Protocol Version 2 and greater
The Hybrid Service does not need to be explicitly started, all applications that have successfully registered have access to the Hybrid Service.
The Hybrid Service is similar to the RPC Service but adds a bulk data field. The payload of a message sent via the Hybrid service consists of a Binary Header, JSON Data, and Bulk Data.
The size of the Bulk Data field is the Data Size (Found in the Frame Header) minus the 12 Bytes of the Binary Header minus the JSON Size (Found in the Binary Header).
The Binary Header of a message using the Hybrid Service is the same as the Binary Header of a message using the RPC Service.
| Binary Header |
| JSON Data |
| Bulk Data |
Available: Protocol Version 3 and greater
The application can start the audio service to send PCM audio data to the head unit. The payload for the Audio Service is only PCM audio data.
Available: Protocol Version 3 and greater
The application can start the video service to send H.264 video data to the head unit. The payload for the Video Service is only H.264 video data.
To close out a communication session with the head unit, an application sends