DEV Community: Damoov

Crash Detection Algorithms on Smartphones: How to Minimize False Positives in Telematics Apps

Damoov — Mon, 03 Aug 2026 15:47:24 +0000

Detecting a high-G impact on a smartphone accelerometer is straightforward. Knowing whether that impact was a vehicle collision — and acting on it without flooding your claims desk with pothole alerts — is where crash detection algorithms earn or lose integrator trust.

This article is the canonical false-positive reference for Damoov's developer content series. It covers validation pipeline architecture, severity-banded classification, threshold tuning for different deployments, and how to handle accident events in production code. For the full crash-detection pipeline (sensor fusion, high-frequency capture, FNOL), see How Automatic Crash Detection Works. For the business and use-case angle, start with Crash Detection with Mobile Telematics.

Why false positives dominate the engineering problem

A phone in a moving vehicle experiences dozens of high-G events per day that have nothing to do with collisions: drops onto a seat, door slams, speed bumps, hard braking, railway crossings. A naive threshold — "trigger if acceleration exceeds X g" — produces alert volumes that make the feature unusable.

The cost of getting this wrong is asymmetric:

Insurance FNOL. Every false alert creates a claims touchpoint, adjuster time, and policyholder anxiety. Alert fatigue erodes trust in the entire telematics program.
Fleet safety. Managers stop responding when 80% of "crashes" are curb bumps on urban routes.
Emergency services. False positives in SOS workflows have regulatory and liability implications.

The crash detection algorithm that ships in production is therefore a filtering problem layered on top of a detection problem. Detection finds candidate impacts; validation decides which candidates become confirmed accidents.

False positive taxonomy: what triggers look like

False positives fall into predictable categories. Understanding the taxonomy helps you tune thresholds and explain alert volumes to stakeholders — without treating every pothole as a unique mystery.

Device-handling events (no vehicle context)

Phone drop — extreme peak G (50–200 g), near-instant duration, single-axis dominant, no preceding vehicle speed.
Phone toss onto seat — sharp deceleration spike, rotation pattern inconsistent with vehicle impact, no GPS velocity context.

Road-surface events (vehicle moving, sub-collision forces)

Potholes and speed bumps — vertical-axis dominant spike (3–8 g), vehicle continues at speed, no sustained multi-axis deceleration signature.
Railway crossings and expansion joints — rhythmic vertical impulses; duration and frequency distinguish from deformation events.

Driving dynamics (real vehicle, below crash threshold)

Hard braking without collision — sustained longitudinal deceleration (3–6 g) but vehicle continues moving; below crash confirmation gates.
Aggressive cornering — lateral G elevated but no impact discontinuity; gyroscope shows controlled rotation not impact spin.

Post 15100 summarizes these categories in its detection pipeline overview. This article goes deeper on how the algorithm rejects them — the gates, bands, and tuning levers — not the source list itself.

Multi-signal validation pipeline

Reliable crash detection algorithms require convergence across independent signals before confirming an accident. No single gate is sufficient; the pipeline stacks them in sequence:

Velocity gate — device was traveling at vehicle speed (typically >15 km/h) in the seconds before the event. Filters stationary phone drops and parking-lot handling.
Duration gate — high-G persists long enough to reflect vehicle deformation, not a point impulse. A dropped phone peaks and returns in milliseconds; collision energy dissipates over hundreds of milliseconds.
Multi-axis gate — real crashes produce significant force on at least two axes (longitudinal + lateral or vertical). Single-axis dominance flags handling events.
Post-event behavior gate — after a confirmed crash, the vehicle typically stops or moves erratically. Continuing at highway speed after a 40 g spike is a rejection signal.
Rotation correlation gate — gyroscope dynamics must be consistent with vehicle impact, not device rotation in a cup holder.

Each gate is a configurable threshold, not a hardcoded constant. That is what makes the same architecture work for teen-driver monitoring (more sensitive) and long-haul fleet on rough roads (more tolerant).

Severity-banded classification

After validation, confirmed events are classified into severity bands that drive downstream behavior. Treating every confirmed impact as a maximum-severity FNOL is how integrators burn out their operations team.

A practical three-band model:

Band	Typical signature	Recommended action
Low	Passes minimum gates; peak G and duration below high-severity thresholds; reliability score moderate	Log event, include in trip timeline, no automated FNOL
Medium	Strong multi-axis signature; reliability above review threshold; speed context consistent with minor collision	In-app driver prompt ("Were you in an accident?"); queue for manual review
High	High peak G, sustained duration, post-event stop, high reliability score	Trigger FNOL workflow, emergency contact, high-frequency buffer upload

The Damoov platform exposes a Reliability score on accident events (see Crash Data) — a numeric confidence measure integrators can map directly to these bands. An event with low reliability should not trigger the same workflow as one scoring high confidence, regardless of peak G alone.

Threshold tuning by deployment

There is no universal threshold set. The same algorithm architecture supports different sensitivity profiles:

Sensitive (UBI, teen monitoring) — lower velocity gate, shorter duration minimum, more medium-band events. Accepts higher false-positive rate in exchange for catching low-speed parking-lot impacts.
Standard (general insurance) — balanced defaults. Suitable for mixed urban/suburban driving.
Tough (fleet, rough-road routes) — higher G thresholds, stricter multi-axis requirements, longer duration gate. Reduces pothole and speed-bump triggers on degraded surfaces.

Tuning is not a one-time launch task. Monitor false-positive rate per 1,000 trips by road-type segment and adjust quarterly. A fleet operating exclusively in urban cores needs different parameters than long-haul highway logistics.

Handling accident events in code

When the SDK detects a candidate accident, it surfaces through the event callback. Your app should filter by event type and apply reliability-based routing — not treat every callback as a confirmed crash.

Android / Kotlin — filter and route by reliability:

override fun onNewEvents(context: Context, events: Array<Event>) {
    events.filter { it.type == "Accident" }.forEach { accident ->
        when {
            accident.reliability >= HIGH_RELIABILITY_THRESHOLD -> {
                // High band: trigger FNOL / emergency workflow
                triggerFnolWorkflow(accident)
            }
            accident.reliability >= REVIEW_THRESHOLD -> {
                // Medium band: prompt driver or queue for review
                showAccidentConfirmationDialog(accident)
            }
            else -> {
                // Low band: log only, no automated claims action
                logSubThresholdAccident(accident)
            }
        }
    }
}

The accident payload includes peak accelerations, speed at impact, duration, GPS coordinates, and the reliability score. Full field reference: Crash Data documentation. High-frequency sensor buffers (60 Hz iOS / 100 Hz Android, 5 seconds before and after) upload separately for forensic review on high-band events.

Measuring alert fatigue in production

Integrators should track these metrics from launch, not after the claims desk complains:

Confirmed accidents per 1,000 trips — baseline varies by market; sudden spikes often indicate threshold misconfiguration, not more crashes.
FNOL auto-triggers overturned by driver denial — high denial rate = sensitivity too aggressive.
Medium-band events with no user response — may indicate prompt fatigue; consider raising review threshold.
Reliability score distribution — if 90% of events cluster below review threshold, your high-band gate may be too strict (missing real crashes).
Geographic clustering — false positives concentrated on specific routes often indicate road-surface triggers; tune Tough profile for those user segments.

Pair SDK event data with claims outcomes after 90 days to calibrate bands. The goal is a stable precision/recall trade-off documented for actuarial and operations stakeholders.

Common pitfalls

Peak G alone. A 40 g spike without velocity context, duration, and multi-axis confirmation is not a crash. This is the most common DIY implementation mistake.
One global threshold. Urban gig drivers and rural fleet haulers need different profiles. Use segment-level tuning or user-group settings.
Skipping reliability. The platform computes confidence for a reason. Routing all Accident-type events to FNOL ignores it.
No driver confirmation layer. Medium-band prompts reduce false FNOL without sacrificing high-band automation.
Duplicating 15100 §4 in a second article. Keep pipeline context on post 15100; keep false-positive depth here.

Ship crash detection that operations teams trust

False-positive control is what separates a demo from a production crash detection deployment. The Damoov Telematics SDK implements multi-signal validation, severity-banded classification, and reliability scoring — so your team routes high-confidence events to FNOL and filters the rest before they reach a human.

Explore the Telematics SDK or read Crash Data to integrate accident event handling into your claims workflow.

Background Trip Detection Without Killing the Battery: How Telematics SDKs Manage iOS and Android Background Modes

Damoov — Fri, 31 Jul 2026 09:47:26 +0000

Drivers do not uninstall telematics apps because the SDK integration was hard. They uninstall because the app drained their battery. Background location tracking is the highest-cost operation in any smartphone telematics product — and the platforms are explicitly designed to stop you from doing it continuously.

Background location tracking battery drain is the central engineering problem behind every always-on UBI, fleet, or gig-economy app. This article explains how a telematics SDK manages power across motion states, what iOS and Android actually allow in the background, and which configuration choices trade accuracy for battery life.

Already understand trip detection? See How Automatic Trip Detection Works for the motion state machine that drives when sensors spin up. For sensor fundamentals, start with How Your Smartphone Detects Driving.

Why battery is the make-or-break constraint

Continuous GPS at 1 Hz can consume 5–10% of battery per hour on its own. Add accelerometer polling, network uploads, and a foreground service notification on Android, and a naive implementation becomes unusable within a day.

The failure modes are predictable:

User churn. A 1-star review citing battery drain kills adoption faster than a missed crash event.
OEM throttling. Samsung, Xiaomi, Huawei, and OnePlus add battery managers beyond stock Android that kill background services aggressively.
OS policy changes. Every major iOS and Android release tightens background execution. An integration that worked in 2022 may be throttled in 2026 without SDK updates.

The goal is not zero battery cost — it is predictable, acceptable cost (typically 3–5% per day for a well-optimized always-on SDK) while maintaining trip detection reliability.

Power budget by motion state

Efficient SDKs do not run the same sensor profile 24/7. Power consumption maps directly to the trip-detection state machine described in Article 1 — each state uses a different duty cycle:

IDLE — near-zero cost. Activity recognition (iOS Core Motion / Android Activity Recognition API) runs at OS-managed power. No GPS. Accelerometer may sample at low frequency for motion energy only.
CANDIDATE — low cost. OS reports "in vehicle" transition; GPS may warm up briefly to confirm speed but does not record a full track yet.
DRIVING — highest cost. Full GPS at ~1 Hz, accelerometer at 50–60 Hz, gyroscope active, network uploads queued. This is the only state where continuous location is justified.

The design principle: spend GPS budget only in DRIVING. Everything else uses cheaper proxies to decide when to escalate.

Sampling profiles: what runs at what rate

Understanding Hz profiles per state is the difference between a telematics app that survives and one that gets uninstalled:

Sensor / API	IDLE	CANDIDATE	DRIVING
Activity recognition	OS-managed (~0 extra cost)	Active	Active
Accelerometer	Low-rate motion energy	Moderate	50–60 Hz
GPS	Off	Burst / warm-up only	~1 Hz continuous
Gyroscope	Off	Off	Active (cornering, crash)
Network upload	Heartbeat only (~2 hr)	Minimal	Trip chunks + events

This is materially deeper than the "adaptive sampling" summary in consumer explainers. The SDK's job is to enforce these profiles automatically so your app code never holds GPS open during idle hours.

iOS: background modes and GPS cost tiers

iOS offers several location APIs at very different power costs:

Significant location change — OS wakes your app when the device moves ~500 m. Near-zero idle cost. This is the primary wake path into CANDIDATE state.
Region monitoring — geofence entry/exit triggers. Useful for fleet products with depot boundaries; not required for general trip detection.
Continuous location updates — full GPS stream. Required during DRIVING, expensive. Only enabled after activity recognition confirms vehicle motion.
Core Motion activity classification — labels automotive / walking / cycling at minimal power. The cheap trigger before GPS escalation.

Additional iOS constraints that affect battery:

Always authorization is mandatory for background trip detection. "While Using" permission cannot record background trips.
Low Power Mode reduces location update frequency. The SDK should surface a user notification when Low Power Mode is active — trips may be missed or fragmented.
Precise Location (iOS 14+) — reduced accuracy mode degrades trip quality. Monitor accuracyAuthorization and prompt users to enable precise location.

See Permissions in iOS for the two-step Always authorization flow.

Android: foreground services, Doze, and OEM survival

Android's background model is stricter in a different way: the system will kill your process unless you declare why you need to stay alive.

Foreground service trade-off

During an active trip, a FOREGROUND_SERVICE with a persistent notification is the reliable way to keep GPS recording without the system suspending your process. This costs battery (screen-on awareness, process priority) but is the cost of reliable DRIVING-state recording on Android 9+.

Doze and App Standby

When the screen is off and the device is stationary, Doze mode batches network access and defers wake locks. Robust SDKs use activity transition callbacks (not fixed-interval polling) so the app sleeps until the OS reports movement — avoiding wake loops that drain battery without producing trips.

Battery optimization exemption

Stock Android's battery optimizer is the #1 cause of missing trips. Request exemption during onboarding:

val intent = Intent(Settings.ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS)
intent.data = Uri.parse("package:${packageName}")
startActivity(intent)

Manufacturer-specific killers

Samsung Adaptive Battery, Xiaomi MIUI autostart restrictions, and Huawei power management go beyond stock Android. For these devices, guide users to manufacturer settings — reference dontkillmyapp.com for per-brand instructions. The Damoov React Native and Flutter permission wizards handle some of these cases automatically.

Full permission sequence: Permissions in Android.

SDK configuration for power management

Beyond platform APIs, the Damoov SDK exposes settings that directly affect power consumption:

accuracy() — parking radius / location threshold. accuracyHigh (default, 100 m) vs accuracyLow trades GPS precision for fewer wake-ups near trip boundaries.
stopTrackingTimeout() — dwell window before trip end. Shorter = faster trip finalization but more GPS time at low speed; longer = fewer fragmented trips but extended DRIVING-state cost.
autoStartOn() — enables automatic background detection. Disable for on-demand products (taxi, delivery) that only record during active shifts.
passiveDetectionOn() — alternative detection path for specific deployment modes. Evaluate against your accuracy requirements.

Initialize with power-aware defaults (Android / Kotlin):

val settings = Settings()
    .accuracy(Settings.accuracyHigh)
    .stopTrackingTimeout(Settings.stopTrackingTimeHigh)
    .autoStartOn(true)
    .passiveDetectionOn(false)

TrackingApi.getInstance().initialize(context, settings)

// After permissions granted:
TrackingApi.getInstance().apply {
    setDeviceID(deviceId = "YOUR_DEVICE_TOKEN")
    setEnableSdk(true)
}

Initialize (iOS / Swift):

RPEntry.initializeSDK()
RPEntry.instance.application(application, didFinishLaunchingWithOptions: launchOptions)

try RPEntry.instance.setDeviceID(deviceId: "YOUR_DEVICE_TOKEN")
RPEntry.instance.setEnableSdk(true)

For tracking modes beyond automatic (programmatic, on-demand, scheduled, Bluetooth-triggered), see the mode overview in Article 1 — choosing the right mode is often the largest battery win because you stop recording entirely outside business hours.

Measuring battery impact in production

Lab estimates are not enough. Monitor these signals after launch:

Device heartbeats include battery level on each transmission (~every 2 hours). Trend battery drain for active vs inactive users. See Device Status.
Permission + battery optimization state in DataHub — correlate missing trips with users who denied background location or battery exemption.
OS version and manufacturer — segment crash and missing-trip reports by device model. OEM-specific issues show up here first.
User-reported uninstalls — track app store reviews mentioning battery within 30 days of SDK enablement.

A well-tuned deployment should show stable daily battery curves, not a cliff on day three when Samsung's Adaptive Battery kicks in.

Common pitfalls

Holding GPS open in IDLE. The most expensive mistake. If your app requests continuous location updates at init, you will drain battery before the first trip.
Skipping battery optimization on Android. Permissions granted but optimizer enabled = silent trip loss.
Ignoring Low Power Mode on iOS. Trips fragment or disappear; users blame your app, not the OS setting.
One-size-fits-all accuracy. Fleet products with depot geofences may tolerate accuracyLow; UBI programs needing precise mileage should stay on accuracyHigh.
Building it yourself. Duty-cycle management across iOS and Android revisions is ongoing maintenance — the reason teams buy an SDK.

Record trips without draining the battery

Background location tracking battery drain is solvable — but only with state-aware sensor management, platform-native wake paths, and SDK configuration tuned to your product's recording model. The Damoov Telematics SDK handles duty cycles, permission wizards, and OEM survival patterns so your team ships a battery-acceptable experience without rebuilding power management from scratch.

Explore the Telematics SDK or read the permissions documentation to configure background tracking for your app.

Detecting Location Spoofing in Mobile Telematics: How to Identify Fake GPS in Insurance and Fleet Apps

Damoov — Tue, 21 Jul 2026 17:28:33 +0000

Usage-based insurance premiums, fleet compliance dashboards, and gig-economy payout rules all assume one thing: the trips in your database reflect real driving. When a driver can feed your app a fabricated route — or selectively disable tracking in high-risk areas — every downstream score, mileage total, and fraud check becomes unreliable.

Location spoofing detection is the set of techniques telematics platforms use to identify when smartphone location data may have been manipulated. This article walks through what spoofing looks like in mobile telematics, which signals actually indicate fraud, and how to build a practical integrity layer on top of your SDK integration — including Damoov's Trust Score.

Building trip recording first? See How Automatic Trip Detection Works for the sensor-fusion pipeline that produces the trip data you'll be validating here.

Why telematics data integrity matters

Smartphone telematics replaced hardware black boxes because deployment is cheaper and faster. The trade-off is trust: a dedicated OBD device is physically attached to the vehicle; a phone is a general-purpose computer that the driver controls.

That control creates incentives to cheat:

Insurance UBI. A policyholder who can suppress hard-braking events or inflate mileage in low-risk zones directly affects premium calculations.
Fleet compliance. A driver who disables GPS during off-route detours avoids manager visibility without missing payroll hours.
Gig and delivery platforms. Fake GPS routes can simulate completed deliveries or mask location during policy violations.

Detection is not about catching every edge case on day one. It is about building enough signal confidence that business decisions — underwriting, disciplinary action, payout approval — are defensible when challenged.

What location spoofing looks like on smartphones

In mobile telematics, "spoofing" covers a range of behaviors, not just one attack vector:

Mock location apps. Android exposes a developer-level "mock location provider" that replays GPX routes or teleports the device. iOS has no equivalent public API, but jailbroken devices and certain sideloaded tools can inject coordinates.
Permission manipulation. Turning GPS off during specific trips, revoking background location access, or cycling permissions at trip boundaries to create gaps in the record.
Selective recording. Logging out, force-stopping the app, or switching devices so only favorable trips are captured.
Emulators and test environments. Legitimate for QA — problematic when the same credentials record production trips from simulated routes.

The naive defense — "we only accept GPS coordinates" — fails because mock providers deliver coordinates that look valid until you cross-check them against motion sensors and permission state.

Detection signals that actually work

No single flag proves fraud. Reliable location spoofing detection combines platform signals, sensor coherence, and behavioral patterns over time.

1. Mock provider and platform flags

On Android, the OS marks locations from mock providers. Your app or SDK can inspect this at the point of collection:

override fun onLocationChanged(context: Context, location: Location) {
    if (location.isFromMockProvider) {
        // Location originated from a mock provider — flag for review
        // Damoov's Trust Score incorporates this class of signal
    }
    // Normal trip recording continues; backend scoring weighs integrity
}

iOS does not expose an equivalent public flag on every location update, which is why cross-signal validation matters more on Apple devices.

2. Sensor–GPS coherence

A real vehicle trip produces physically consistent data across sources:

Accelerometer and gyroscope show braking, cornering, and vibration patterns that align with GPS speed changes.
A teleport jump — coordinates shifting kilometers in one second while accelerometer energy stays flat — is a strong integrity violation.
Reported speed that exceeds plausible vehicle limits for sustained intervals, without corresponding g-force, suggests injected coordinates.

This is the same sensor-fusion discipline used in crash detection, applied to route plausibility rather than impact detection.

3. Permission and GPS toggling patterns

Permission behavior is often more revealing than any single bad coordinate. Signals that reduce confidence include:

GPS disabled at trip start or end — the windows where manipulation has the highest payoff.
Rapid on/off GPS cycles, especially at different geographic locations (suggesting selective avoidance).
Background location or motion permissions revoked mid-program.

Damoov tracks these patterns through the Permissions Score, which feeds directly into the broader Trust Score.

4. Account and device behavior

Integrity problems often show up in metadata before they show up in a single trip:

Frequent logins and logouts around trip windows.
Multiple device switches on one account in a short period.
Long gaps in uploads followed by bursts of "perfect" trips.
Heartbeat reports showing SDK disabled while trips still appear (or the reverse).

Device status heartbeats — transmitted automatically by the SDK approximately every two hours — include permission state, tracking status, battery level, and connectivity. Monitoring these is the operational backbone of ongoing fraud detection. See Device Status and the Device Status API for field-level detail.

Trust Score: integrity scoring beyond a single trip

Point-in-time checks catch obvious injections. Production telematics needs a rolling assessment of whether a user's entire data stream is trustworthy.

Damoov's Trust Score aggregates three signal categories:

Permission-related activities — GPS toggling, revocations, and background refresh interruptions (via Permissions Score).
Account behavior — login patterns, device switches, and indicators of mock-location tooling.
Telematics consistency — continuity and coherence of location, motion, and sensor data across trips.

The score classifies users into three bands: Healthy (above 90), Moderate (80–90), and Attention required (below 80). Full threshold definitions and use-case guidance are in the Trust Score documentation — this article does not duplicate that reference table.

Trust Score is separate from driving behavior scores. A driver can be a safe driver with unreliable data — or vice versa. Underwriting and fleet compliance workflows should treat them independently.

Implementing an integrity workflow

A practical integration pattern for developers and backend teams:

Record trips normally through the Telematics SDK with automatic detection enabled.
Subscribe to backend notifications for HeartbeatReceived events to monitor permission state without polling. See Data Export / Backend Notifications.
Query latest device status when investigating a flagged user:

curl -X GET "https://api.telematicssdk.com/v1/latest/users/YOUR_DEVICE_TOKEN" \
  -H "Authorization: Bearer YOUR_JWT_TOKEN" \
  -H "Content-Type: application/json"

The response includes current permission states, SDK tracking status, and device metadata — enough context to decide whether a suspicious trip warrants exclusion or manual review.

Apply Trust Score thresholds in business logic. Example policy rules:

Trust Score below 80 → exclude trips from premium calculation until permissions are restored and score recovers.
Trust Score 80–90 → include trips but flag for manual review in DataHub.
Trust Score above 90 → full automated processing.

Trust Score is visible per driver in DataHub alongside safety and eco scores. Tune thresholds per product — insurance actuarial teams typically want a higher bar than gig platforms optimizing for driver retention.

What to do when integrity is low

Detection without a user-facing response creates support debt. A workable playbook:

Notify in-app when permissions drop below required levels — before scores are affected, not after.
Explain the impact in plain language: "We can't verify this trip because location access was disabled."
Offer a remediation path — permission wizard, link to OS settings, or support contact.
Log enforcement actions — excluded trips, manual reviews, premium holds — for regulatory and dispute resolution.

Hard-blocking every low-trust user on day one tends to increase churn without improving loss ratios. Most programs start with flag-and-review, then tighten automation as baseline trust distributions stabilize.

Common pitfalls

Single-trip rejection only. One clean trip does not rehabilitate a user with a pattern of GPS toggling. Use rolling Trust Score, not per-trip binary checks alone.
Ignoring permission UX. Many "fraud" signals are accidental — users who revoked background location during an OS update. Distinguish malice from friction through heartbeat trends.
Building detection from GPS alone. Without accelerometer coherence and permission auditing, mock routes pass basic validation.
Reimplementing platform scoring. Trust Score, Permissions Score, and heartbeat infrastructure exist precisely so integrators do not rebuild integrity models from scratch.

Ship telematics with integrity built in

Location spoofing is an expected adversary in smartphone telematics — not an edge case. The integrators who treat data integrity as a first-class product requirement earn trust from insurers, fleet operators, and compliance teams before a dispute forces the conversation.

The Damoov Telematics SDK records trips with sensor fusion, monitors permissions through device heartbeats, and surfaces integrity through Trust Score — so your team can focus on product logic instead of rebuilding fraud detection.

Explore the Telematics SDK or read the Trust Score documentation to integrate integrity scoring into your workflow.

How Automatic Trip Detection Works: Sensor Fusion, Motion States, and Background Processing in Mobile Telematics SDKs

Damoov — Mon, 13 Jul 2026 14:35:04 +0000

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, 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 location background 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.

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.

DEV Community: Damoov

Crash Detection Algorithms on Smartphones: How to Minimize False Positives in Telematics Apps

Why false positives dominate the engineering problem

False positive taxonomy: what triggers look like

Device-handling events (no vehicle context)

Road-surface events (vehicle moving, sub-collision forces)

Driving dynamics (real vehicle, below crash threshold)

Multi-signal validation pipeline

Severity-banded classification

Threshold tuning by deployment

Handling accident events in code

Measuring alert fatigue in production

Common pitfalls

Related reading

Ship crash detection that operations teams trust

Background Trip Detection Without Killing the Battery: How Telematics SDKs Manage iOS and Android Background Modes

Why battery is the make-or-break constraint

Power budget by motion state

Sampling profiles: what runs at what rate

iOS: background modes and GPS cost tiers

Android: foreground services, Doze, and OEM survival

Foreground service trade-off

Doze and App Standby

Battery optimization exemption

Manufacturer-specific killers

SDK configuration for power management

Measuring battery impact in production

Common pitfalls

Related reading

Record trips without draining the battery

Detecting Location Spoofing in Mobile Telematics: How to Identify Fake GPS in Insurance and Fleet Apps

Why telematics data integrity matters

What location spoofing looks like on smartphones

Detection signals that actually work

1. Mock provider and platform flags

2. Sensor–GPS coherence

3. Permission and GPS toggling patterns

4. Account and device behavior

Trust Score: integrity scoring beyond a single trip

Implementing an integrity workflow

What to do when integrity is low

Common pitfalls

Related reading

Ship telematics with integrity built in

How Automatic Trip Detection Works: Sensor Fusion, Motion States, and Background Processing in Mobile Telematics SDKs

Why automatic trip detection is hard

Sensor fusion, briefly

The motion state machine

Trip start detection

Trip end detection

Background processing: the platform reality

iOS

Android

Tracking modes in practice

Implementing it with the Damoov SDK

Common pitfalls and trade-offs

Related reading

Build on trip detection instead of rebuilding it