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.
Table of Contents
- 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
- SDK configuration for power management
- Measuring battery impact in production
- Common pitfalls
- Related reading
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
accuracyAuthorizationand 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) vsaccuracyLowtrades 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 onaccuracyHigh. - Building it yourself. Duty-cycle management across iOS and Android revisions is ongoing maintenance — the reason teams buy an SDK.
Related reading
- How Automatic Trip Detection Works — motion state machine and background APIs.
- How Your Smartphone Detects Driving — sensor primer.
- Permissions in iOS — Always authorization flow.
- Permissions in Android — background location and battery exemption.
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.