iOS guides

Get started for Swift

Android guides

Get started for Kotlin and Java

REST API

All services used by DriveKit Mobile SDK are also available through REST services. For each SDK you will find the description of web services in the REST services section.

This documentation is for developers. Follow the simple guideline to install our telematics SDK and access powerful insight and actionable data.

What is DriveKit?

DriveKit is a modularized software suite for creating mobile applications to engage and coach drivers.

DriveKit is composed of SDK available on both iOS and Android platforms and web services (REST API) that are designed to collect, analyze, organize, store and display driving data.

DriveKit is a 100% mobile telematics technology based on smartphone sensors to analyze vehicle trips and evaluate the influence of driving style on safety and energy consumption.

In addition to data analysis, DriveKit allows you to easily and quickly integrate features into your application to help drivers improve and manage their vehicles on a daily basis: coaching, ludic functions, mileage monitoring, car maintenance. All these features can be tested in our demo application (on and ).

How does it work?

The DriveKit SDK transforms any iOS or Android application into a data collection solution to measure and improve driving behavior.

The SDK provides automatic detection of vehicle trips and recording of GPS data locally during the trip.

At the end of a trip, the SDK automatically requests the data analysis services embedded on the DriveQuant platform.

The DriveQuant platform contains the signal processing algorithms and databases where raw data and driving indicators resulting from the analyzes are stored.

The results of a trip analysis are usually returned to the application within seconds after the end of the trip.

The SDK contains a local database that is automatically and continuously synchronized with the DriveQuant platform database.

What are the main features included in the mobile SDK?

The DriveKit SDK is a set of independent features integrated into modules.

Some of these modules include graphical libraries with user interfaces.

The table below summarizes all the modules included in DriveKit:

Not all the DriveKit SDK modules listed in this table are strictly necessary. The key modules for transforming your application into a telematics solution are: Core and Trip Analysis.

If you plan to display the driving analysis results in your mobile application, we strongly recommend that you install the Driver Data module, which synchronizes all a driver's trips, synthesis and historical data.

What are the advantages of DriveKit?

• 100% mobile and high-performance telematics solution.

• Easy and quick integration.

• Automatic trip recording.

• Optimized battery consumption.

The DriveKit Demo App

To better understand how the DriveKit SDK is working, we recommend you to test the DriveKit Demo app. It contains all the DriveKit SDK components and has been developed to guide mobile developers to understand how DriveQuant's telematics solution works. The DriveKit Demo App is available on GitHub for and .

Contact us

You can contact DriveQuant via email at to request a demonstration, to be supported during the integration phase or to get answers to any specific requests.

The Working hours feature sorts the trips according to whether they are made during working hours. The trips are then automatically tagged as "BUSINESS" or "PERSONAL".

The feature also permits to set time slots during which the automatic starting mode is disabled, which offers more privacy control for the driver.

You can get that screen by calling the following method:

The Working hours feature sorts the trips according to whether they are made during working hours. The trips are then automatically tagged as BUSINESS or PERSONAL.

The feature also permits to set time slots during which the automatic starting mode is disabled, which offers more privacy control for the driver.

You can start displaying that screen by calling the following method:

DriveKit Common UI includes configuration options and resources that are shared by all DriveKit UI modules. It allows to configure the colors and fonts of all DriveKit UI modules.

If you use the DriveKit graphical libraries, it is mandatory to set the configurations with the Common UI module.

DriveKit Common UI has several benefits:

• it includes reusable components,

• it simplifies the standardization of all layouts,

• it avoids code duplicates.

Requirements

DriveKit is developed with the Swift 5 language and is compatible with iOS 13.0 and later versions.

Driver synthesis scorecard

The Driver Data component includes a component to visualise the average performance of a driver.

The synthesis scorecard shows as main information the averages of each of the driving scores calculated over a 7 days since the last trip date.

The synthesis scorecard also indicates, over this period, the number of trips performed as well as the total distance and driving duration.

The component allows you to select the scores displayed and the order in which they are displayed. To move from one score to another, simply swipe the scorecards.

To include the scorecards into your app, call the following method:

Last trip widget

The Driver Data component includes a widget to display a short chronological list of the driver's last trips.

With the last trip widget, the driver can get a quick overview of his last 10 trips with a simple swipe.

Each small card corresponds to a trip and the user can access the full details and map view by tapping on the current card.

By selecting the last card, the user can access the list of all the trips.

​​To include the last trip widget into your app, call the following method:

And embed the returned view into your layout.

Set metadata

You can add additional metadata to your trip by calling the following method:

The metadata must be represented as a key/value object where the key and value have a String type.

The metadata can be set any time before the end of a trip.

If metadata is sent, it will also be added to the push data request in the metaData field.

Get metadata

It is possible to get a copy of configured metadata thanks to the following method on DriveKitTripAnalysis:

Update metadata

To update a value in metadata, call the following method:

Delete a specific metadata

To delete a specific value in metadata, call the following method:

Delete all metadata

To delete all values in metadata, call this method:

To automatically record a trip when the application runs in background, the DriveKit SDK must be allowed to access the phone's sensors.

Access to this data is allowed by iOS and Android under certain conditions. It is essential to inform the user and ask him to grant the required permissions to allow the application to access the data measured by the smartphone's sensors.

To help you collect consent from your users, the DriveKit SDK provides a graphical component, Permissions Utils, which displays the appropriate requests after the installation of the application.

The Permissions Utils component also contains a diagnosis functionality that alerts the user if the smartphone settings are not properly set up and guides the user to solve the detected issue.

Location sharing while driving provides peace of mind to family members. The graphical interface helps the user to enable location sharing and create a link that displays his location on a map to a friend or family member while driving.

The feature is implemented across three distinct screens:

1. Introduction Screen: The feature is disabled by default. The first screen explains the location-sharing principle.

2. Duration Selection Screen: On the second screen, the user can choose the duration for sharing his trip location. The available options include one day, one week, or one month.

3. Active Sharing Screen: The last screen confirms that location sharing is active. It includes a button that allows the user to generate and share a link displaying his real-time location. Additionally, it displays the remaining time before the link expires.

To integrate and display this feature within your application, invoke the following method:

The DriveKit Demo App integrates all components of the DriveKit SDK and you can refer to the code before installing the Trip Analysis component in your mobile application.

You can find all resources on .

• Android DriveKit Demo App can be found

Requirements

DriveKit is developed with the Kotlin language and is compatible with Android 8.0 (API 26) and later versions.

The DriveKit SDK version is configured with these attributes:

The Trip Analysis UI module is an open source graphical library created to incorporate a user interface for trip analysis management into your mobile application.

It contains 3 main features :

1. Working hours ;

2. Feedback crash detection ;

Principle

The widget is a button that let the user control the trip recording. Possible actions are:

• Start a trip recording

The trip analysis API transforms GPS data collected by a smartphone or any other telematics system into actionable driver and vehicle analytics.

This API is automatically queried by the mobile SDKs as soon as a trip is completed. The results are returned, after a few seconds, to the SDK and can also be transmitted via a to a third-party server.

The API provides a broad range of indicators that depends on your subscription. DriveKit's trip analysis API provides more than 200 indicators per trip. They are organized by categories so that you can choose the ones that best suit your use case. The categories of driving indicators are listed below.

Data that represent the driver's behavior:

• Eco-driving score.

Principle

Bluetooth wireless technology is a common solution in modern vehicles. Most drivers know that by pairing their Bluetooth smartphone with their car stereo receiver, they will be able to make hands-free calls or to stream their music to the car audio system.

Once the smartphone's paired with the vehicle, it automatically connects to it if the vehicle is started.

Trip Analysis component is capable of detecting this event to start a trip analysis.

A Bluetooth device is identified by a unique MAC address and an optional name. It can be detected by the SDK and used to trigger the trip analysis.

Prerequisite

Before starting DriveKit Permissions Utils UI integration, make sure that you have initialized module, especially if you have .

Prerequisite

Before starting DriveKit Permissions Utils UI integration, make sure that you have initialized module, especially if you have .

Location sharing while driving provides peace of mind to family members. The graphical interface helps the user to enable location sharing and create a link that displays his location on a map to a friend or family member while driving.

The feature is implemented across three distinct screens:

1. Introduction Screen: The feature is disabled by default. The first screen explains the location-sharing principle.

2. Duration Selection Screen: On the second screen, the user can choose the duration for sharing his trip location. The available options include one day, one week, or one month.

The Driver Data component manages the download and display in your mobile application of all trips made by the user.

The Driver Data component continuously performs synchronization between the remote DriveQuant database and the local database of the mobile SDK.

The Driver Data component has been designed to simplify the integration of DriveQuant services into your application and to drastically reduce your development time.

It has several benefits:

• The SDK contains its own database. You do not need to create a local database (or modify the existing one) to persist the user driving data.

Prerequisite

Before starting DriveKit Timeline UI integration, make sure that you have initialized Driver Data and Common UI modules.

Integration

To add the Timeline UI module to your app:

• Swift Package Manager: Add DriveKitDriverDataTimelineUI from repository: https://github.com/DriveQuantPublic/drivekit-ui-ios.git as dependency.

• Cocoapods (deprecation scheduled for the end of 2025): add the following pod to your Podfile

Then, run pod install.

Initialization

If you have , the Timeline UI module must also be manually initialized. In the application's AppDelegate file, import DriveKitDriverDataTimelineUI:

Then, to initialize Timeline UI module in your app, you must call the initialization method in didFinishLaunchingWithOptions method of your AppDelegate:

Configure main screen scores

You can select which scores you want to display on the main screen as well as the scores ordering, by calling the following method:

Default and accepted values:

[ .safety, .ecoDriving, .distraction, .speeding ]

My synthesis screen contains two very interesting insights for the driver:

• His level against a reference scale that tells him whether he needs to make efforts and progress ;

• His level in regard to the performance of other drivers belonging to the same organisation as him. The comparison is an interesting lever to motivate the driver to improve his driving.

For each selectable period, the driver will be able to view his average score computed by services that run on the DriveQuant platform.

The user can easily navigate to consult:

• The evolution of his driving scores by theme compared to the previous active period ;

• His driving score compared to the community thanks to the minimal, median and max community scores ;

• How many trips and total distance he made during the selected period.

​​To include the “My Synthesis” screen into your app, call the following method:

And present the returned view controller using your app’s navigation API.

Configure scores themes to display

You can select which scores you want to display on the screen as well as the scores ordering, by calling the following method:

Default and accepted values are:

Configure Capabilities

1. Go to the Capabilities tab of your target settings.

2. Turn on Background Modes and enable Location updates.

Configure permissions

As DriveKit requires a user's location and motion data, it is required to get permissions from the user.

When the application requests permission for background locations or motion activities, a message will be shown to the user. You must configure this message by changing the value for the following keys in Info.plist

• NSLocationWhenInUseUsageDescription

• NSLocationAlwaysAndWhenInUseUsageDescription

• NSMotionUsageDescription

Ask for location permission

Since iOS 13 and DriveKit SDK 1.1.3, location permission must be requested in two steps because the "Always Allow" option is no longer available in standard iOS location permission alert. You must first request when in use authorization (locationManager.requestWhenInUseAuthorization()) and then ask the user to choose "Always Allow" option in the app settings and redirect user to the app settings page.

To ask for the location permission in a proper way, DriveKit provides the following function:

Motion and Fitness permission

By default, the SDK incorporates the permission request to access Motion and Fitness. This allows for improved transportation mode recognition through the use of based on motion properties.

Therefore, if you install DriveKit in your application, a permission request will be displayed to ask for the user's consent.

If you do not want to use this feature and want to control the user experience related to the Motion and Fitness permission request, it can be disabled.

To deactivate the Motion and Fitness permission request, call:

To verify the DriveKit Trip Analysis component integration into your app, it is recommended to perform tests in real conditions.

Before carrying out driving tests, it may be useful to validate the implementation of the SDK in your application.

However, it is not possible to emulate GPS data from development tools such as Android Studio. It is possible to simulate a trip using the simulator in Xcode, but the trip options are very limited.

For this purpose, DriveQuant provides a trip simulation component based on recorded GPS data.

The Trip Simulator component allows to validate the following features:

• the automatic start;

• the trip recording life cycle;

• graphical display after the end of the trip;

• the application's behaviour in the case of alternative trips;

• crash detection during a trip, with user’s feedback.

This section gives step-by-step instructions for integrating the DriveKit SDK test component into your application.

Hiding the delete trip button

The SDK includes a feature that allows the user to manually delete a trip. Depending on your use case, you can allow or prohibit the deletion of a trip.

Therefore, the SDK contains a setting parameter to show or hide the delete button. The delete trip button is displayed as a "trash can" and appears at the top right of the trip detail screen.

By default delete trip button is enabled. To disable it, call the following method with parameter enable set to true:

Trip list sorting

The analyzed trips are displayed on a list. This list shows the grouped trips by day from the most recent to the oldest one.

If more than one trip have been completed in a day, the trips for a day can be sorted in ascending or descending order of time.

By default, trips are sorted in ascending order, to change it, call the following method with parameter dayTripDescendingOrder set to true:

Trip advice feedback

If trip advice is configured for your DriveQuant account, drivers will receive trip advice at the end of a trip according to their driving.

For this advice, you can enable a feedback screen that allows your drivers to send a feedback about the relevance of the advice.

By default, this screen is enabled but you can disable it by calling the following method withe parameter enable set to false:

Enable alternative transportation modes display

The DriveKit SDK can detect alternative modes of transport such as public transport. In this case, the driver behaviour is not evaluated since he is not in a driving situation.

The Driver Data component automatically splits the rated trips from those that should not be rated in two separate lists.

• The main list contains the trips scored and corresponding to transport modes where the user is in a driving situation (car, motorbike or truck).

• The secondary list displays the trips identified in transportation modes where the user is not in a driving situation.

We have chosen to distinguish these trips and separate them into two independent lists. The list of main trips (i.e. scored) is always displayed by default. The list of alternative trips (i.e. not scored) can be shown or hidden according to your needs. By default, it is not displayed.

When this function is enabled, a filter icon appears in the upper right corner of the trip list screen. By clicking on it, you can select the list of trips made with an alternative mode of transport. To display the list of trips identified as alternative transportation modes, you can use the code below.

Prerequisite

Before starting DriveKit Vehicle UI integration, make sure that TripAnalysis and CommonUI modules are initialized, especially if you have disabled the SDK auto-initialization.

Integration

To add the Trip Analysis UI module to your app, add the following lines to your dependencies in your application build.gradle file:

On a, you can find a demo app and the source code of Permissions Utils UI that you can use as an example.

Initialization

If you have , the Trip Analysis UI module must also be manually initialized.

Then, to initialize the Trip Analysis UI module in your app, you must call the initialization method in onCreate method of your Application class:

My synthesis screen contains two very interesting insights for the driver:

• His level against a reference scale that tells him whether he needs to make efforts and progress ;

• His level in regard to the performance of other drivers belonging to the same organisation as him. The comparison is an interesting lever to motivate the driver to improve his driving.

For each selectable period, the driver will be able to view his average score computed by services that run on the DriveQuant platform.

The user can easily navigate to consult:

• The evolution of his driving scores by theme compared to the previous active period ;

• His driving score compared to the community thanks to the minimal, median and max community scores ;

• How many trips and total distance he made during the selected period.

​​To display the “My Synthesis” screen into your app, call the following method:

Configure scores themes to display

You can select which scores you want to display on the screen as well as the scores ordering, by calling the following method:

Default and accepted values are:

Principle

The widget is a button that lets the user control the trip recording. Possible actions are:

• Start a trip recording

• Check that the current trip is being recorded

• Stop a trip recording

• Cancel a trip recording.

How to display the trip recording widget?

There are two ways to integrate the trip recording widget into your application:

The first one is embedding it in XML layout:

The second way is getting it from DriveKitTripAnalysisUI:

If you need to programmatically display the stop trip confirmation dialog (for example, when the user taps a start trip notification), you can call the public method showConfirmationDialog() of the DKTripRecordingButton instance.

Trip recording widget configurations

The button has 4 configurations to cover all possible scenarios, and its display can be adjusted using the tripRecordingUserMode parameter.

1. NONE: The button is hidden and the trip recording is fully automatic. This is the simplest mode, and the one we prefer.

2. START_STOP: The button is displayed and the user has total control over the trip recording cycle: start, stop and cancel. In this configuration, autostart remains active.

3. START_ONLY: The user can start a trip manually but cannot stop or cancel it under any circumstances. Recording stops automatically. In this configuration, autostart remains active.

The default value is START_STOP.

To set the button mode, call the following method:

The timeline component displays the user's driving score history to help them understand if they are making progress.

The data represents weekly or monthly averages that are calculated periodically by services that run on the DriveQuant platform and automatically synchronised with the DriveKit SDK.

The design is designed to be technical but ergonomic in order to highlight the qualities and weaknesses of the user's driving behaviour.

The user can easily navigate to consult :

• the evolution of his driving scores by theme. The safety score out of 10 for example.

• the evolution of sub-scores or secondary driving indicators that were used to build the main driving scores. The number of hard braking for example.

Main screen

The main screen highlights the scores for each theme. The driver can choose between two types of display:

1. weekly average history

2. monthly average history

Score detail screen

The secondary screens are accessible from the main screen by tapping on "See more details about my score".

They contain the sub-scores of the selected theme. As for the main screens, data is available by week and month.

🛡Safety sub-scores :

• Number of accelerations per 100 km

• number of brakings per 100 km

• Adherence limits per 100 km

🌿 Eco-driving sub-scores:

• Acceleration score

• Deceleration score

• Speed maintain score

• Fuel consumption (in l)

📱Distraction sub-scores:

• Number of phone unlocks per 100 km

• Duration of forbidden calls per 100 km

• Percentage of trips with forbidden calls

🏎 Speeding sub-scores:

• Overspeeding relative duration

• Overspeeding relative distance

Principle

Bluetooth wireless technology is a common solution in modern vehicles. Most drivers know that by pairing their Bluetooth smartphone with their car stereo receiver, they will be able to make hands-free calls or to stream their music to the car audio system.

Once the smartphone's paired with the vehicle, it automatically connects to it if the vehicle is started.

Trip Analysis SDK is capable of detecting this event to start a trip analysis.

A Bluetooth device is identified by a unique MAC address and an optional name. It can be detected by the SDK and used to trigger the trip analysis.

The use of the vehicle Bluetooth detection is a simple and cost-effective solution to identify the trips made with your vehicle.

Configure a Bluetooth device

You can retrieve all Bluetooth devices paired to the smartphone by calling the following method:

You can add Bluetooth devices to Trip Analysis SDK by calling the following method:

A detailed description of BluetoothData class is available .

Bluetooth device required

Pairing the vehicle's Bluetooth system improves the trip detection and analysis. With this feature you can decide to enable or disable the trip recording when the Bluetooth device is not connected. There are two possibilities:

1. the trip can be recorded even if the smartphone is not connected to the Bluetooth device.

2. the trip recording will be cancelled if the smartphone is not connected to the Bluetooth device.

This choice depends on your use case. In general, if you only want to record trips made with the vehicle equipped with the paired Bluetooth system, you must prefer the second choice.

To avoid trip recording when the Bluetooth device is not connected, call the following method:

To enable trip recording regardless of the state of the Bluetooth system (connected or not connected to the smartphone), call the following method:

Prerequisite

Before starting DriveKit Vehicle integration, make sure that you have initialized DriveKit, especially if you have disable the SDK auto-initialization.

Integration

Get framework

To add the Vehicle module to your app:

• Swift Package Manager: Add DriveKitVehicle from repository: https://github.com/DriveQuantPublic/drivekit-sdk-spm.git as dependency.

• Cocoapods: add the following pod to your Podfile:

Then, run pod install.

TripAnalysis configuration overload

The configuration of the Vehicle SDK and its vehicles can overload the auto start configuration of the TripAnalysis SDK. To do this, you should call this method after the SDK Vehicle initialization:

Prerequisite

Before starting DriveKit Trip Analysis UI integration, make sure that you have initialized TripAnalysis and modules, especially if you have .

Configure beacons

The automatic trip detection feature is compliant with iBeacon Bluetooth beacons. A beacon is a Bluetooth low energy (BLE) device that broadcasts a universally unique identifier. This signal can be detected by the SDK and used to trigger the trip analysis.

In addition, the beacon is a smart and cost-effective solution for identifying the vehicle in which the driver is travelling.

The DriveKit SDK is fully compatible with the standard.

You can add beacon identifiers to Trip Analysis module by calling the following method:

Driver synthesis scorecard

The Driver Data component includes a component to visualise the average performance of a driver.

The synthesis scorecard shows as main information the averages of each of the driving scores calculated over a 7 days since the last trip date.

The synthesis scorecard also indicates, over this period, the number of trips performed as well as the total distance and driving duration.

Prerequisite

Before starting DriveKit Timeline UI integration, make sure that you have initialized and modules.

Integration

Driver’s trips

Driver Data component includes an open source graphics library which provides a set of screens to display trip data recorded by the Trip Analysis component and analyzed by DriveQuant services.

The Driver Data component displays the list of trips made by the driver as well as the details of each trip displayed on a map with all driving indicators and driver scores.

Driver Data component gives a direct access to the formatted data on simple and readable screens. This way, you do not need to create specific screens in your application for illustrating driver’s trip analytics.

The DriveKit Vehicle module allows you to select one or more vehicles and to choose the automatic start mode of each vehicle.

The selection of the vehicle is an important step since the driving indicators computed by the application are based on the vehicle characteristics (mass, dimension and powertrain).

There are two types of vehicles that can be added: cars or trucks.

Each declared vehicle is linked to the driver's account.

A start mode can be defined for each vehicle.

Depending on your use case, you can select the type of automatic start mode:

• The natural (GPS) mode which relies on the phone sensors.

Configure beacons

The automatic trip detection feature is compliant with iBeacon Bluetooth beacons. A beacon is a Bluetooth low energy (BLE) device that broadcasts a universally unique identifier. This signal can be detected by the SDK and used to trigger the trip analysis.

In addition, the beacon is a smart and cost-effective solution for identifying the vehicle in which the driver is travelling.

The DriveKit SDK is fully compatible with the Apple iBeacon™ standard.

You can add beacon identifiers to Trip Analysis SDK by calling the following method:

A detailed description of BeaconData class is available .

Beacon required

To avoid the recording of unwanted trips (trips performed outside the vehicle where the beacon is placed), it is possible to automatically cancel the trip if the beacon is not "seen" several times during the trip. Generally, a trip will be cancelled in less than 6 minutes if the beacon is not in the vehicle.

By default, this setting is disabled, but you can enable it by calling the following method:

To disable this settings, call the same method with the parameter set to false

Filter the beacon trigger to start trip recording

In very rare cases, it may be useful to avoid trip detection using the beacon but still need to validate the trip recording only if the beacon is near the smartphone during the trip.

In this case, the beacon is used in trip validation mode but not in trip detection mode.

How does it work ?

By default, if you have configured a beacon, its detection by the SDK will start a trip analysis.

In very rare cases (e.g. beacon in a vehicle and parked in close proximity to a living area), it might be useful to avoid the SDK to start a trip when a beacon is detected to reduce smartphone battery consumption.

Please note that beacon scans checks are always performed during the trip analysis, even if the configuration is called.

To disable the ability to start a trip analysis when a beacon is detected by DriveKit, you can call the following method:

Beacon battery level

DriveKit is able to retrieve the battery level of a beacon and to add this information automatically in (only for the current trip), so that you can know, for instance, if the beacon battery of a user needs to be changed.

For this functionality to work properly, the user must allow access to Bluetooth and you have to configure your project to allow background access to Bluetooth as described below.

• In your target, in the "Signing & Capabilities" tab, you need to check the "Uses Bluetooth LE accessory" box in "Background Modes":

• Ask the user for Bluetooth access authorization if it is not already granted. To do this, you can call this method:

dataExtractionRules property merge issue

If an error message appeared when building your app is something like:

Error: Attribute application@dataExtractionRules value=(@xml/data_extraction_rules) from AndroidManifest.xml:12:9-65 is also present at [com.drivequant.drivekit:drivekit-core:x.x.x] AndroidManifest.xml:13:9-56 value=(@xml/backup_rules). Suggestion: add 'tools:replace="android:dataExtractionRules"' to element at AndroidManifest.xml:9:5-31:19 to override.

It's a backup rules merging issue with DriveKit SDK rules and your app and/or another external library you use.

To resolve this, update your AndroidManifest.xml file:

Then find the related backup rules of your app or the external library and create the file merged_data_extraction_rules.xml in the src/main/res/xmlfolder:

fullBackupContent property merge issue

If an error message appeared when building your app is something like:

Error: Attribute application@fullBackupContent value=(@xml/app_backup_exclusion) from [com.anotherSdk.library:xxx:x.y.z] AndroidManifest.xml:22:18-76 is also present at [com.drivequant.drivekit:drivekit-core:x.x.x] AndroidManifest.xml:11:9-69 value=(@xml/backup_rules_pre_android_12). Suggestion: add 'tools:replace="android:fullBackupContent"' to element at AndroidManifest.xml:42:3-72:17 to override.

It's a backup rules merging issue with DriveKit SDK rules and your app and/or another external library you use.

To resolve this, update your AndroidManifest.xml file:

Then find the related backup rules of your app or the external library and create the file merged_backup_rules.xml in the src/main/res/xmlfolder:

BackupAgent merge issue

If an error message appeared when building your app looks like:

It's because DriveKit SDK is using the BackupAgent to restore some user information when the user has reinstalled the app.

DriveKit is providing two ways to handle the error:

Way 1 - Inherit from DriveKitBackupAgent

The easiest way is to make your BackupAgent class inherits our DriveKitBackupAgent class.

Way 2 - Call DriveKit backup methods

If you cannot inherit from DriveKitBackupAgent class, e.g. when you already inherits from another class, you can still:

1. Add tools:replace="android:backupAgent in your Manifest as suggested in the error message.

2. Call DriveKitBackupAgent.onCreate(BackupAgentHelper) in your overriden onCreate() method

3. Call DriveKitBackupAgent.onRestoreFinished(BackupAgentHelper)

Principle

The crash detection feature includes an interface that informs the driver that a crash has been detected so he can confirm it to automatically call for help if needed.

Enable crash detection feedback

By default, the crash detection feedback is disabled. When this feature is enabled, the crash detection feedback displays a notification or a screen and calls an emergency number when a crash is confirmed by the driver.

To enable crash detection feedback, the following method needs to be called:

With the following parameters:

DKCrashFeedbackConfig

DKCrashFeedbackNotification

DKCrashAlert

Disable Feedback crash detection

To disable crash detection feedback, call the following method:

Test your integration with the crash simulator

In order to check your integration and test the crash detection feature, you can use the trip simulator described in section .

To simulate a car accident, simply install the trip simulator and start a simulation with the configuration TRIP_WITH_CRASH.

Register to the Crash Notification API

Our platform can share a collision report that contains information about the accident.

This information can be used to:

• trigger the intervention of an assistance service,

• and initiate the accident management process.

If you want to know more and if you need to collect crash data on your platform, we invite you to contact us by email at

Principle

Crash detection features, included into the DriveKit Trip Analysis component, is able to collect and analyse smartphone sensors data to automatically detect when a car accident occurs.

DriveKit Trip Analysis analyzes signals from the GPS sensor and also from the motion sensors (accelerometer, gyrometer and magnetometer).

This feature is enabled if the following conditions are fulfilled:

• Your API key has the access rights to use this service;

• You have enabled the feature by following the instructions described in this section;

• A trip has been detected and is being analysed.

• The smartphone's sensors are functional.

• The SDK is able to check the status of the required sensors.

The crash detection steps are:

1. A trip is detected automatically or started manually and the trip recording starts.

2. The crash feature detects a potential collision based on motion sensors.

3. The GPS and motion data are pushed to the backend analysis services in charge of the signal processing and crash confirmation.

4. The SDK receives a crash analysis service response with a status.

Enable crash detection

If the crash detection configuration is enabled for your company, your API key carries out the feature access and the crash detection will be enabled accordingly.

However, you can deactivate and reactivate the function if necessary using a dedicated setting.

A method is available in DriveKitTripAnalysis to enable or disable the feature:

Verify that the feature is available

It is possible to check if the crash detection is available for your configuration by checking the following property:

This property returns true if:

• the required smartphone sensors are available and up and running;

• your API key is allowed to use the feature;

Configure crash detection feedback

Trip Analysis offers a mechanism to ask the user for feedback when an accident is confirmed by the crash analysis service.

Crash confirmation can be used to trigger a notification or display a screen which asks the driver to confirm the accident and whether assistance is required.

To use this function, you need to enable the interface with the following method and a object:

To disable the crash detection feedback, call the following method:

Listening to Crash events

TripListener interface provides two callbacks for crash events:

• crashDetected(crashInfo:), triggered when a crash event is detected

• crashFeedbackSent(crashInfo:, feedbackType: , severity:), triggered when crash feedback is enabled and a confirmed crash is detected. This callback will contain crash information and the feedback from the user.

To receive these callbacks, the smartphone must be connected to a mobile network and the accident detection feature must be enabled for your organisation's API key.

Introduction

My Driver Profile has two main screens:

1. The first screen displays information on driving habits and the main characteristics that define a driver's profile.

2. The second screen highlights the driving conditions that the driver has experienced during his trips.

Main screen

The main screen is divided into three parts:

1. The first describes the different components of the driver profile.

2. The second one displays the estimated and actual distances per period (week, month and year).

3. The third one gives the most common driver’s trip in terms of distance and duration.

Driver’s profile cards

Every driver has a signature that depends on how they use their vehicle. The driver profile function gives an accurate overview of the driver's profile based on an analysis of his driving data.

We have divided the driver profile into 5 characteristics that depends on key variables:

• the annual distance driven per year,

• the mobility area that includes 90% of the driver’s trips,

• the percentage of weeks during which the driver has used his vehicle,

• the regularity based on the relative standard deviations of the weekly distance and trip number,

Distance estimation cards

These cards compare for different periods (week, month and year)the actual distance (ie. recorded) with the estimated distance computed from the driver historical data.

Driver’s usual trip

The purpose of this section is to highlight the driver's most common trip in terms of duration and distance.

​​To include the “Driver Profile” screen into your app, call the following method:

And present the returned view controller using your app’s navigation API.

Driving conditions screen

To visualize the exposure to the external conditions, we have embedded a screen in the graphical component DriverData UI representing the distances covered by the driver in these conditions and per period: week, month and year.

The driver can scroll through cards to visualize the conditions that result from the analysis of his trips:

• the ranges of distances mostly traveled;

• trips made during the week or on weekends;

• the types of roads travelled;

• the weather conditions;

This information helps the driver to be conscious of the inherent risks and is useful to personalize the driving advice.

You can access this screen by clicking on the button “View my driving conditions” in the main screen.

If you want to include the “Driving Conditions” screen into your app as a standalone screen, call the following method:

And present the returned view controller using your app’s navigation API.

Principle

The crash detection feature includes an interface that informs the driver that a crash has been detected so he can confirm it to automatically call for help if needed.

Enable crash detection feedback

By default, the crash detection feedback is disabled. When this feature is enabled, the crash detection feedback displays a notification or a screen and calls an emergency number when a crash is confirmed by the driver.

To enable crash detection feedback, the following method needs to be called:

With the following parameters:

DKCrashFeedbackConfig

DKCrashFeedbackNotification

DKCrashAlert

Disable Feedback crash detection

To disable crash detection feedback, call the following method:

Test your integration with the crash simulator

In order to check your integration and test the crash detection feature, you can use the trip simulator described in section

To simulate a car accident, simply install the trip simulator and start a simulation with the configuration tripWithCrash.

Register to the Crash Notification API

Our platform can share a collision report that contains information about the accident.

This information can be used to:

• trigger the intervention of an assistance service,

• and initiate the accident management process.

If you want to know more and if you need to collect crash data on your platform, we invite you to contact us by email at

Principle

Crash detection features, included into the DriveKit Trip Analysis component, is able to collect and analyse smartphone sensors data to automatically detect when a car accident occurs.

DriveKit Trip Analysis analyzes signals from the GPS sensor and also from the motion sensors (accelerometer, gyrometer and magnetometer).

This feature is enabled if the following conditions are fulfilled:

Analytics tags

Hiding the delete trip button

The SDK includes a feature that allows the user to manually delete a trip. Depending on your use case, you can allow or prohibit the deletion of a trip.

Therefore, the SDK contains a setting parameter to show or hide the delete button. The delete trip button is displayed as a "trash can" and appears at the top right of the trip detail screen.

By default delete trip button is enabled. To disable it, call the following method with parameter enableDeleteTrip set to false:

DriveKitDelegate

DriveKitDelegate is a protocol that can be passed as a parameter during the DriveKit Core module initialization. It gives useful events about the user lifecycle.

UpdateUserIdStatus

UpdateUserIdStatus is an enum that explains the request status after a userId has asked to be changed.

RequestError

RequestError is an enum that describes the error type of a DriveKit request.

DeleteAccountStatus

DeleteAccountStatus is an enum that describes the deletion status. It can have 3 values:

• success: Account deleted successfully

• failedToDelete: Account not deleted, an error has occurred

• forbidden: Account deletion not activated for this team

DKWeather

DKWeather is an enum that describe each category of weather during a trip. It can have these values:

• unknown

• sun

• cloud

The TripListener protocol provides useful information and events about trips analyzed by DriveKit.

For example, you can be informed when a trip analysis has started, finished, canceled, when a crash is detected, etc.

Add a TripListener

You can remove a specific listener using the following method:

To remove all TripListeners objects:

TripListener interface includes several methods to implement:

Get the trip response status (Deprecated)

Once the DriveQuant servers has analyzed a trip, the tripFinished() callback is triggered with the data in the PostGenericResponse object.

It can be useful to check the trip response status in order to check for example if the trip is valid or not with detailed information.

To do this, call the following method:

The model is described in the References part.

The TripListener interface provides useful information and events about trips analyzed by DriveKit.

For example, you can be informed when a trip analysis has started, finished, canceled, when a crash is detected, etc.

Add a TripListener

You can remove a specific listener using the following method:

To remove all TripListeners objects:

TripListener interface includes several methods to implement:

Get the trip response status (Deprecated)

Once the DriveQuant servers has analyzed a trip, the tripFinished() callback is triggered with the data in the PostGenericResponse object.

It can be useful to check the trip response status in order to check for example if the trip is valid or not with detailed information.

To do this, call the following method:

The model is described in the References part.

Pre-requisite

Before starting DriveKit Driver Data UI integration, make sure that you have initialized DriverData and Common UI components, especially if you have disabled the SDK auto-initialization.

Integration

To add Driver Data UI module to your app, add the following line to your dependencies in your application build.gradle file:

Google API Key

Introduction

A Google API Key is mandatory in order to use Driver Data UI. Without it, the trip detail screen will not work because it draws the desired trip using the Google Maps SDK that requires credentials.

According to the , please check that you already have:

• a billing account

• Maps SDK for Android enabled

If you already have a Google API Key that can be used for Maps SDK, directly go to the section

Create an API Key

Please follow the official documentation to create your own Google API Key.

Add the API Key

Please follow the official documentation to add the API Key to your application project.

Initialization

If you have , the Driver Data UI module must also be manually initialized.

Then, to initialize the module in your app, you must call the initialization method in onCreate method of your Application class:

Override colors and texts

To override colors and texts in Driver Data UI SDK, see

Trip list main theme

It is possible to choose the main theme for the trip list. The main theme of the trip list is used to select the score to be displayed on the left side of the trip list. This setting allows you to choose among one of the 6 themes below:

• SAFETY: The driving safety score.

• ECO_DRIVING: The eco-driving score.

• DISTRACTION: The driving distraction score.

The main theme can be configured calling the following method:

The default value is SAFETY.

Trip map items

A trip is analyzed through several dimensions and DriveQuant's services provide multiple categories of scores. Depending on your need, you can highlight the scores of interest and hide some of them. The configuration of the trip detail screen allows to choose the displayed themes and the displaying order. To switch from one theme to another, simply swipe the bottom part of the screen or click on one of the pictograms in the navigation bar at the top of the screen.

The screens that can be displayed are listed below:

• The safety analysis results: SAFETY.

• The eco-driving results: ECO_DRIVING.

• The distracted driving results: DISTRACTION.

Map items can be configured by calling the following method:

The default value is:

[SAFETY, ECODRIVING, DISTRACTION, SPEEDING, INTERACTIVE_MAP, SYNTHESIS]

Display fragment

To show fragment in your activity, you just have to create an instance of TripListFragment with the following method:

and then show it using a FragmentManager.

Introduction

My Driver Profile has two main screens

1. The first screen displays information on driving habits and the main characteristics that define a driver's profile.

2. The second screen highlights the driving conditions that the driver has experienced during his trips.

Main screen

The main screen is divided into three parts:

1. The first describes the different components of the driver profile.

2. The second one displays the estimated and actual distances per period (week, month and year).

3. The third one gives the most common driver’s trip in terms of distance and duration.

Driver’s profile cards

Every driver has a signature that depends on how they use their vehicle. The driver profile function gives an accurate overview of the driver's profile based on an analysis of his driving data.

We have divided the driver profile into 5 characteristics that depends on key variables:

• the annual distance driven per year

• the mobility area that includes 90% of the driver’s trips,

• the percentage of weeks during which the driver has used his vehicle,.,

• the regularity based on the relative standard deviations of the weekly distance and trip number.

Distance estimation cards

These cards compare for different periods (week, month and year)the actual distance (ie. recorded) with the estimated distance computed from the driver historical data.

Driver’s usual trip

The purpose of this section is to highlight the driver's most common trip in terms of duration and distance.

​​To include the “Driver Profile” screen into your app, call the following method:

And present the returned view controller using your app’s navigation API.

Driving conditions screen

To visualize the exposure to the external conditions, we have embedded a screen in the graphical component DriverData UI representing the distances covered by the driver in these conditions and per period: week, month and year.

The driver can scroll through cards to visualize the conditions that result from the analysis of his trips:

• the ranges of distances mostly traveled;

• trips made during the week or on weekends;

• the types of roads travelled;

• the weather conditions;

This information helps the driver to be conscious of the inherent risks and is useful to personalize the driving advice.

You can access this screen by clicking on the button “View my driving conditions” in the main screen.

If you want to include the “Driving Conditions” screen into your app as a standalone screen, call the following method:

And present the returned view controller using your app’s navigation API.

DriveKitListener

DriveKitListener is an interface that can be passed as a parameter during the DriveKit Core module . It gives useful events about the user lifecycle.

Prerequisites

To complete this quickstart, make sure that your development environment meets the following requirements:

• Android Studio (latest version)

Permission management

On iOS, the user must grant access permission to the phone's location in background to enable the trip detection function included in the Trip Analysis component. There are several options for this permission and automatic mode will only work if the user selects the "Always" option.

The Permissions Utils component provides a set of screens to guide the user through the selection of the right options. Once the user has correctly authorized access to the location, you are warned by the closure passed in parameter:

It is also recommended that the user allows access to activity recognition (aka "Motion and fitness"). The Permissions Utils component contains a dedicated screen to help the user:

Integration

The Trip Simulator component includes two modules:

• The first module is used as a testing tool for your debug application.

Prerequisite

Before starting DriveKit Driver Data UI integration, make sure that you have and components, especially if you have .