Telematics SDK - Interface Specification  v1.38.19
Introduction

Purpose

This document describes interface specification of Telematics Software Development Kit (SDK) for applications on Linux based automotive platforms.

Scope

Telematics SDK exposes a rich set of APIs conforming to C++11 standard which form the building blocks to create stand-alone Telematics applications.

This document provides high level overview of Telematics SDK architecture and its APIs. Call flow diagrams are provided for various APIs such as a Phone, Call, SMS, SIM Card Services, Audio, Location, Remote Sim, Modem configuration etc.

This document assumes that the developers are familiar with Linux and C++11 programming.

Conventions

Function declarations, function names, type declarations, and code samples appear in a different font. For example,

#include

Parameter directions are indicated as follows:

Parameters
[in]paramnameindicates an input parameter.
[out]paramnameindicates an output parameter.
[in,out]paramnameindicates a parameter used for both input and output.

Most APIs are asynchronous as underlying sub-systems such as telephony are asynchronous. API names follow the convention of using prefix " get " for synchronous calls and " request " for asynchronous calls. Asynchronous responses such as listener callbacks come on a different thread than the application thread.

SDK Versioning

The following convention is used for versioning the SDK releases

SDK version (major.minor.patch)

SDK_VERSION = 1.0.0

Major version: This number will be incremented whenever significant changes or features are introduced.

Minor version: This number will be incremented when smaller features with some new APIs are introduced.

Patch version: If the release only contains bug fixes, but no API change then the patch version would be incremented, No change in the actual API interface.

NOTE: Use telux::common::Version::getSdkVersion() API to query the current version of SDK or refer the VERSION file in the repository

Public API Status

Public APIs are introduced and removed (if necessary) in phases. This allows users of an existing API that is being Deprecated to migrate. APIs will be marked with note indicating whether the API is subject to change or if it is not recommended to use the API.

as follows:

  • Eval: This is a new API and is being evaluated. It is subject to change and could break backwards compatibility.
  • Obsolete: API is not preferred and a better alternative is available.
  • Deprecated: API is not going to be supported in future releases. Clients should stop using this API. Once an API has been marked as Deprecated, the API could be removed in future releases.