Driver location
Why driver apps stop reporting location
A failure-mode inventory for Android ride-hailing. Each entry: what the driver experiences, what is actually happening on the device, and what the build has to do about it.
Written as engineering reality for fleets, not as marketing.
The OS killed the app to save battery
Driver sees: The map on the rider side freezes or the dispatch board shows the car as offline while the driver believes they are still online.
On the device: Android ended the process under memory or power pressure. Without a correct foreground service and persistent notification while on a trip, location work is disposable.
Build must: Keep an explicit foreground service for active trips, survive process death with a recoverable online state, and tell the driver when tracking is no longer running.
Battery optimisation was never whitelisted on that manufacturer's Android skin
Driver sees: Tracking works on a Pixel in the office and dies on the driver's Xiaomi, Oppo, Vivo or Samsung after a few idle minutes.
On the device: OEM power managers throttle or kill background work beyond stock Android. Default battery optimisation keeps the app "healthy" until the next maintenance sweep.
Build must: Detect aggressive OEM skins, guide the driver through manufacturer whitelist steps, and verify location still arrives after idle periods on those devices in field tests.
Background location permission was granted once and later downgraded
Driver sees: Pickup tracking worked last week; today the pin only moves when the app is open.
On the device: The user, or a system prompt after an OS upgrade, moved access from "all the time" to "while in use" or denied it. Android also re-prompts after long unused grants.
Build must: Re-check permission state on every session, block "go online" until the required level is present, and explain why background access is required for paid trips.
The driver force-quit the app between rides
Driver sees: They swipe the app away to "save battery" and still expect to receive new jobs.
On the device: Force-stop ends services and often prevents restarts until the user opens the app again. Push may arrive, but location and job accept flows do not.
Build must: Teach the product rule in onboarding, detect force-stop patterns where possible, and require an explicit online handshake before dispatch sends paid work.
Doze mode throttled updates while the phone sat idle
Driver sees: Waiting at a stand with the screen off; dispatch thinks they have not moved, or job offers arrive late.
On the device: Doze and app standby defer network and location work. High-frequency updates without the right foreground path collapse into maintenance windows.
Build must: Separate on-trip update frequency from idle online presence, use allowable wake paths for job offers, and never design the product as if background polling is free.
GPS drift in dense urban areas and underground pickups
Driver sees: The pin jumps across blocks; the rider thinks the car arrived when it is still on the ramp.
On the device: Multipath GPS, indoor signal loss and delayed fused-location fixes produce noisy coordinates that look like movement.
Build must: Filter impossible jumps, combine sensors carefully, show confidence when accuracy is poor, and avoid auto-completing arrivals on a single bad fix.
The device went offline and updates queued with no expiry
Driver sees: After a tunnel or dead zone, the map suddenly replays an old path or reports a location from minutes ago as current.
On the device: Buffered location points flush when signal returns. Without timestamps and expiry, dispatch treats stale points as live.
Build must: Tag every point with time and accuracy, drop expired buffered points, and show "last known" separately from "live" on rider and admin maps.
Aggressive OEM task killers on certain Android brands
Driver sees: The app closes overnight even with battery whitelist completed on paper.
On the device: Autostart managers, "clean" buttons and vendor security apps still terminate long-running processes. Stock Android documentation does not describe every skin.
Build must: Maintain a device matrix for field testing, document brand-specific setup screens, and monitor silent drop-offs by manufacturer in production analytics.
Location mocking and how to detect it
Driver sees: Nothing unusual; the rider or ops team sees impossible speeds or a pin that never matches the street.
On the device: Mock location apps or developer options feed synthetic coordinates into the location APIs the driver app trusts.
Build must: Detect mock providers where the platform allows it, flag suspicious trails server-side, and escalate rather than silently billing a false trip.
The driver switched to a second phone mid-shift
Driver sees: They log in on a spare handset; jobs and tracking split across devices.
On the device: Two sessions claim the same driver identity. Location streams compete; the last writer wins unless the product forbids it.
Build must: Enforce single active device for online drivers, invalidate the previous session on new login, and keep payout and trip state tied to one authenticated device at a time.
