Introduction
Automatic trip detection is a core component of any telematics SDK. It improves the user experience by detecting and recording trips in the background, without requiring drivers to open their insurance app before driving.
Behind this simplicity lies a complex engineering challenge: maintaining background monitoring while keeping battery usage extremely low. Very few SDKs on the market achieve this balance with consistent accuracy, as demonstrated by this benchmark.
This article details how automatic detection works and outlines the mechanisms that guarantee its performance in real‑world conditions.
Trip recording lifecycle
The trip analysis process begins with detecting that the vehicle is in motion. Before any driving behaviour can be analysed, the system must first determine that a trip has actually started. This initial detection relies on a combination of several signals.
To keep battery consumption to a minimum, the system uses lightweight sensors and background mechanisms during this phase. The GPS sensor is deliberately not activated while the driver is not moving or before a trip is confirmed, as it is one of the most energy‑intensive components of a smartphone.
Once a trip has been reliably detected, the GPS sensor is activated to validate that the movement corresponds to a motorized vehicle and to enable the detailed analysis of the driver’s behaviour.
Once a trip has been detected and confirmed, the GPS sensor measures the vehicle’s speed throughout the journey, until the vehicle comes to a complete stop. As a general rule, trip recording automatically ends when the vehicle remains stationary for more than four minutes. This automatic stop prevents unnecessary GPS usage after a trip and helps minimize battery consumption.
As soon as recording ends, the collected data is sent to the server for processing. The analysis takes no more than one or two seconds, allowing the policyholder to view their results almost immediately.
A reliable telematics solution relies on multiple mechanisms designed to trigger data recording as soon as a vehicle trip begins. To ensure high‑performance detection, the DriveKit SDK combines several complementary mechanisms.
Activity recognition API on Android
On Android, Google Play services provide an Activity Recognition API that leverages the smartphone’s sensors to collect motion data, which is then interpreted using machine‑learning models.
These models rely on low‑power sensors, and the processing pipeline is optimized to minimize the device’s resource consumption. The list of recognized activities is documented in Google’s public documentation.
The DriveKit SDK listens for changes in the detected activity and triggers trip recording when the API reports a motorized transportation mode (IN_VEHICLE). This mechanism enables fast and energy‑efficient trip detection.
Significant location change on iOS
On iOS, an Activity Recognition API is available but this API cannot be used when the application is running in the background, which limits its usefulness for automatic trip detection.
To compensate for this limitation, iOS provides another mechanism capable of detecting movement that typically corresponds to motorized travel: the Significant Location Change (SLC) service.
SLC events are generated based on the phone’s approximate position, estimated using nearby GSM antennas. While this method does not offer precise location tracking, it is sufficiently reliable to detect meaningful changes in position that occur when a user is traveling in a motorized vehicle.
Because SLC triggers infrequent updates, it significantly reduces battery consumption compared to continuous GPS tracking. The DriveKit SDK uses SLC events as a trigger to start trip recording.
Geozones
The two mechanisms described above are effective, but they do not guarantee instantaneous trip‑start detection:
-
On Android, the performance and latency of the Activity Recognition API can vary depending on the quality of the device’s sensors.
-
On iOS, SLC events are energy‑efficient but relatively infrequent, which can delay the detection of movement.
To overcome these limitations, the DriveKit SDK integrates a reinforcement mechanism based on geo‑zones. The principle is straightforward: after each trip, the SDK creates a geo‑zone centered on the last recorded GPS point, corresponding to the vehicle’s parking location.
When the user moves away from this geo‑zone, the DriveKit SDK interprets this as the start of a new trip. It immediately triggers trip recording. This approach significantly improves detection responsiveness while maintaining low battery consumption.
Beacon
A beacon is a Bluetooth Low Energy (BLE) transmitter whose signal can be detected by both iOS and Android smartphones. When placed inside a vehicle, the beacon immediately triggers trip recording as soon as the policyholder’s smartphone comes into proximity.
Although not strictly required, this device provides two key advantages over the previously described mechanisms:
-
Immediate trip detection — recording begins even before the vehicle starts moving, ensuring that the entire trip is captured. In contrast, motion‑based detection requires the vehicle to be in motion, which can lead to minor data loss at the beginning of a trip.
-
Vehicle identification — the beacon makes it possible to associate the trip with a specific insured vehicle, something that cannot be achieved with motion‑based or location‑based methods alone.
|
The DriveKit SDK supports the iBeacon standard introduced by Apple in 2013. This standard is widely adopted, interoperable, and optimized for reliable detection by smartphones. For a deeper dive into beacon‑based use cases, see Understanding Beacon Technology in Connected Insurance (2026). |
Car infotainment system
Most modern vehicles are equipped with infotainment systems that allow a Bluetooth connection with a smartphone. The DriveKit SDK can detect when the policyholder’s smartphone connects to the vehicle and use this event to trigger trip recording.
Although this method is simple and effective, it comes with a few limitations:
-
Only one smartphone can connect to the vehicle at a time.
-
Drivers do not always connect their phone to the vehicle.
These limitations are not problematic, since this detection mode is not exclusive. If the smartphone is connected, trip recording will start immediately when the trip begins. If not, the trip will still be detected through other mechanisms such as activity recognition, the SLC signal on iOS, or geo‑zones.
Android Auto and CarPlay
Car manufacturers increasingly integrate advanced connectivity features such as CarPlay and Android Auto. The DriveKit SDK can detect a connection to Android Auto and use this event to initiate trip recording. Depending on the vehicle and smartphone, this detection works with either a wired connection or a wireless Bluetooth link.
However, for users with an iPhone and a CarPlay‑equipped vehicle, this functionality is not currently available. Apple does not expose the CarPlay connection event to iOS apps, except for applications explicitly designed for CarPlay. Since connected‑insurance apps are rarely CarPlay‑enabled, this detection method cannot be used on iOS.
Conclusion
This article has outlined the principles behind DriveKit’s automatic trip detection. Its performance comes from the combination of several complementary mechanisms that work together to maximize the detection of policyholders’ trips.
Delivering reliable smartphone telematics also requires deep expertise in the surrounding technological ecosystem (iOS and Android operating systems, connected devices, and in‑vehicle interfaces), as well as a strong understanding of mobility behaviours. These capabilities must be grounded in rigorous engineering practices to ensure accuracy, efficiency, and long‑term reliability.
Ultimately, automatic trip detection is not just a technical feature — it is the foundation of a seamless, reliable connected insurance program. By combining multiple detection mechanisms with deep platform expertise, the DriveKit SDK ensures that insurers can deliver a frictionless user experience.
