Damoov

Posted on Jul 31 • Originally published at damoov.com

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

#mobile #android #ios #telematics

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.

DEV Community