Every telematics feature — driver scoring, crash detection, mileage, usage-based insurance — depends on one unglamorous prerequisite: knowing when a drive starts and when it ends. Get that wrong and everything downstream is wrong. Record a train ride as a car trip and you have garbage in the risk model. Miss the first two minutes of a drive and you lose the hard acceleration that matters most. Drain the battery polling GPS all day and users uninstall the app before you ever score a trip.
Automatic trip detection is the process of recognizing vehicle trips from a smartphone in the background, with no button for the driver to press. This article is a practitioner’s walk-through of how it actually works: the sensors, the motion state machine, the trip start/stop logic, and the platform constraints that make “just track location” much harder than it sounds.
New to the raw sensors themselves? Start with How Your Smartphone Detects Driving for a primer on the accelerometer, gyroscope, magnetometer, and GPS. This article assumes that foundation and focuses on the trip-detection pipeline built on top of it.
Why automatic trip detection is hard
The naive approach — “start recording when speed > 0, stop when speed = 0” — fails immediately in the real world:
- Passenger trips. The phone can’t tell a driver from a passenger on sensor data alone. Business logic and post-trip signals have to disambiguate.
- Other transport. Trains, buses, trams, and even fast cycling produce vehicle-like speed and acceleration. Detecting “in a vehicle” is not the same as “driving a car.”
- Stops mid-trip. Traffic lights, drive-throughs, and gridlock all produce zero speed. Ending a trip at every red light shatters one drive into twenty.
- Parking-lot creep and GPS drift. A stationary phone can report phantom movement from GPS noise, especially between tall buildings (“urban canyon”).
- Battery and OS limits. Neither iOS nor Android will let an app hold GPS at full power indefinitely. Detection has to be cheap when idle and precise only when it matters.
Solving these at once is why trip detection is a sensor-fusion and state-machine problem, not a threshold.
Sensor fusion, briefly
Trip detection combines several independent signals so the weaknesses of one are covered by the strengths of another:
- Accelerometer — motion energy and acceleration/braking signatures; cheap to sample continuously.
- Gyroscope — rotation and cornering; helps separate vehicle dynamics from a phone being handled.
- Magnetometer — heading/orientation context.
- GPS — ground-truth speed and location, but power-hungry and unreliable indoors or in urban canyons.
- OS activity recognition — the platform’s own classifier (iOS Core Motion, Android Activity Recognition) that labels walking / cycling / automotive / still at near-zero power cost.
The important design point: GPS is the expensive confirmation, not the trigger. Cheap sensors (activity recognition + accelerometer) decide probably driving; GPS is spun up to confirm and to record the route. This is the core of keeping battery drain low — a topic we go deeper on in a separate article on background battery management.
The motion state machine
Reliable trip detection is best modeled as a state machine rather than a set of if-statements. A driver moves between a small number of states (IDLE → CANDIDATE → DRIVING → TRIP END), and transitions are debounced so a single noisy reading can’t flip the state:
- IDLE → CANDIDATE: the OS activity classifier reports “automotive” (or accelerometer motion energy crosses a threshold). No GPS yet.
- CANDIDATE → DRIVING: GPS is activated and confirms sustained vehicle speed over a few seconds. This debounce rejects a phone tossed on a seat or a brief bus hop.
- DRIVING → TRIP END: speed stays near zero for a configured dwell window (e.g., several minutes), distinguishing a real trip end from a red light.
- TRIP END → IDLE: the trip is finalized, uploaded, and the pipeline returns to the low-power idle state.
Trip start detection
The goal at the start boundary is to begin recording as early as possible without triggering on non-drives. In practice that means a two-stage gate:
- Cheap trigger: the activity-recognition classifier transitions to in-vehicle, or accelerometer energy indicates transport. This costs almost no battery and can run 24/7.
- Confirmation: GPS activates and must observe sustained speed above a walking/cycling threshold for a short window before the state commits to DRIVING.
Because the cheap trigger fires first, a good implementation back-fills the first seconds of the trip from a short rolling buffer, so the early acceleration isn’t lost while GPS is warming up.
Trip end detection
Ending a trip is where naive implementations fall apart. The rule is not “speed = 0” but “speed ≈ 0 and stays there.” A dwell timer holds the DRIVING state through stops; only when the vehicle has been stationary for the full window does the trip finalize. Set the window too short and one drive becomes many fragments; too long and a quick errand and the drive home merge into one. This is deliberately configurable per deployment because a rideshare product and a long-haul fleet want different behavior.
Background processing: the platform reality
All of this has to run when the app is backgrounded or the screen is off — under OS rules explicitly designed to stop apps from doing exactly this.
iOS
- Always authorization for location is required for background trip detection; the SDK must handle the permission wizard and the “provisional always” prompt.
- Significant-location-change and region monitoring let the app stay dormant and be woken by the OS when the device moves meaningfully — the low-power path into the CANDIDATE state.
- Core Motion provides activity classification without holding GPS.
- The
locationbackground mode keeps updates flowing during an active trip.
Android
- A foreground service with a persistent notification is the reliable way to record an active trip without the system killing the process.
- The Activity Recognition API provides the cheap in-vehicle trigger;
ACCESS_BACKGROUND_LOCATION(Android 10+) is required for detection while backgrounded. - Doze mode and OEM battery managers aggressively suspend background work; robust SDKs use activity-transition callbacks (not fixed polling) so the app sleeps until the OS reports movement.
The pattern on both platforms is the same: stay asleep, let the OS wake you cheaply on movement, and only then escalate to GPS. Fighting the platform’s power model is how you end up with a battery-draining app that gets throttled anyway.
Tracking modes in practice
“Automatic” is the right default, but real products need control over when the SDK records. The Damoov Telematics SDK exposes five tracking modes:
- Automatic — runs in the background and detects trip start/stop with no user action. The default for continuous UBI and driver-safety products.
- Programmatic — your app starts and stops tracking through its own flow. Best for taxi and delivery apps where only on-duty trips should be recorded.
- On-demand — you control exactly when tracking begins and ends, for time-bound scenarios like rentals.
- Scheduled — calendar-based windows, ideal for corporate drivers with fixed shifts.
- Bluetooth device — tracking is tied to a specific vehicle’s Bluetooth device, so recording starts only when the driver is in that car — useful when a driver has multiple vehicles but only one should be tracked.
Implementing it with the Damoov SDK
In automatic mode, you initialize the SDK once, enable it after permissions are granted, and subscribe to the trip lifecycle. Detection runs from there without further app involvement.
Initialize (Android / Kotlin):
// In Application.onCreate()
val settings = Settings()
.accuracy(Settings.accuracyHigh)
.autoStartOn(true) // enable automatic trip detection
TrackingApi.getInstance().initialize(context, settings)
// After the location/motion permission wizard completes:
val trackingApi = TrackingApi.getInstance()
trackingApi.setDeviceID(deviceId = "YOUR_DEVICE_TOKEN")
trackingApi.setEnableSdk(true)
Subscribe to the trip lifecycle (Android / Kotlin): the SDK reports trip boundaries through listener callbacks — you don’t poll for them.
override fun onStartTracking(context: Context) {
// A trip has started - DRIVING state entered
}
override fun onStopTracking(context: Context) {
// A trip has ended and been finalized - safe to read the recorded trip
}
override fun onLocationChanged(context: Context, location: Location) {
// Streamed waypoints during an active trip
}
override fun onNewEvents(context: Context, events: Array<Event>) {
// Driving events for the trip (harsh braking, acceleration, accidents, ...)
val accidents = events.filter { it.type == "Accident" }
}
Initialize (iOS / Swift):
// AppDelegate - didFinishLaunchingWithOptions
RPEntry.initializeSDK()
RPEntry.instance.application(application, didFinishLaunchingWithOptions: launchOptions)
// After the permissions wizard completes:
try RPEntry.instance.setDeviceID(deviceId: "YOUR_DEVICE_TOKEN")
RPEntry.instance.setEnableSdk(true)
The autoStartOn(true) flag is the switch that turns on automatic trip detection: with it set, the state machine described above runs inside the SDK, and your app just reacts to onStartTracking / onStopTracking. For the full callback reference, see the Callbacks & Listeners documentation.
Common pitfalls and trade-offs
- Chasing zero false-negatives. Making the start trigger too sensitive catches every short walk and bus ride. Tune for precision first; a missed 30-second parking-lot move matters less than a corrupted risk profile.
- Trip fragmentation. Too-short a dwell window splits one commute into many trips and wrecks per-trip scoring. Validate the end-of-trip window against real driving data for your market.
- Under-provisioned permissions. Background detection simply cannot work without “Always” (iOS) and background location (Android). Design the permission flow as a first-class part of onboarding, not an afterthought.
- Building it yourself. Every item above — activity transitions, GPS warm-up buffering, dwell tuning, Doze survival, permission wizards — is months of platform-specific work that has to be re-validated with every OS release. That’s the maintenance cost an SDK absorbs.
Related reading
- How Your Smartphone Detects Driving — the underlying sensors, explained.
- How Automatic Crash Detection Works — the same sensor-fusion foundation applied to detecting collisions.
Build on trip detection instead of rebuilding it
Automatic trip detection is deceptively deep: a state machine over fused sensors, tuned against the messy reality of passengers, red lights, and OS power limits. The Damoov Telematics SDK ships all of it — automatic detection, five tracking modes, and a clean callback API — so you can start from recorded, scored trips instead of from an empty accelerometer buffer.
Explore the Telematics SDK or head straight to the developer documentation to integrate trip detection into your app.