Why GPS tracking stops working on Android
Gaps in field tracking data are usually the operating system doing its job, not an agent avoiding theirs. Here is what actually stops location recording on Android.
8 min read
If your field tracking has holes in it, the first instinct is to suspect the agent. Usually the culprit is Android itself. The platform has spent a decade getting more aggressive about background work, and location tracking is the single most expensive thing an app can do. Understanding what kills it changes both how you evaluate software and how you read your own data.
Three things stop tracking, and only one is the user
1. Doze and App Standby
When a device is stationary and unplugged, Android enters Doze, deferring background work and network access into occasional maintenance windows. An app that requests location on a timer simply stops receiving it. This is standard platform behaviour on every Android device, and it is a feature, not a bug.
2. Battery optimisation and manufacturer task killers
On top of stock Android, several manufacturers layer their own, far more aggressive power management. Devices from a number of popular Chinese and Korean brands will kill background services well before stock Android would, sometimes within minutes of the screen turning off, and often without any user-visible notice.
This is the single biggest cause of tracking gaps in Indian field teams, because it disproportionately affects the affordable handsets that field agents actually carry.
3. The permission the user chose
Since Android 10, location permission is not binary. “Allow only while using the app” means exactly that: minimise the app and location stops. Background location has to be granted separately, and on Android 11 and later the user must go into system settings to do it. Many agents grant the first and never the second, in good faith.
What well-built tracking does differently
The difference between tracking that survives a working day and tracking that does not comes down to a few architectural choices. These are worth asking any vendor about directly.
A real foreground service
Android will preserve a foreground service with a persistent notification far longer than ordinary background work. If location capture runs inside the app process instead, it dies with the app. Ask whether tracking continues after the app is swiped away from the recents screen, and ask them to demonstrate it.
Durable local storage before sync
Points should be written to durable local storage the moment they are captured, not held in memory until the network returns. Anything held in memory is lost when the process dies. A write-ahead approach means a killed app loses at most the last point rather than the last hour.
Recovery after the kill
Being killed is inevitable on some devices. What matters is whether the service restarts and resumes the same route, or whether the agent has to notice and start again. Ask what happens after a reboot mid-route.
A checklist for your own fleet
Most tracking complaints are resolved by four settings. Walk a new agent through these on day one and you will avoid the majority of support tickets.
- Location permission set to Allow all the time, not only while using the app
- Precise location enabled rather than approximate
- Battery optimisation disabled or set to unrestricted for the app
- Any manufacturer auto-start or protected-app setting enabled
- Power saving mode off during working hours
The manufacturer settings are the awkward one, because every brand buries them somewhere different and renames them between versions. It is worth writing a short internal note with screenshots for whichever handsets your team actually uses.
How to test before you commit
Do not evaluate a tracking app on a demo device in an office. Run this instead, on the handsets your agents carry:
- Start a route, swipe the app away, and drive for thirty minutes
- Put the phone in flight mode for an hour mid-route, then reconnect
- Let the battery fall below the level that triggers power saving
- Include your worst-signal territory, not your best
- Compare the recorded distance against the odometer
Any vendor confident in their architecture will encourage this test. It is also the fastest way to find out whether the accuracy claims on a marketing page survive contact with a real beat.
Related guides
- What is sales force automation (SFA) software?SFA software manages what a field sales team does outside the office: who they visit, what they sell and what it costs to get them there. Here is how it differs from CRM, and what to look for in India.
- How to verify field visits without accusing your own teamVisit verification fails when it feels like surveillance. The methods that work verify the work, not the worker, and give agents something back.
- Beat planning for distributors: a practical guideA beat plan decides which outlets get visited, how often, and in what order. Get it wrong and agents quietly rewrite it themselves.
- Fuel and mileage reimbursement for field teamsReimbursement is usually the largest uncontrolled line in a field sales budget, not because people are dishonest, but because nobody can check the number.
- How to choose field sales softwareEvery vendor demos well. The differences show up on a three-year-old handset, in a basement, at four in the afternoon. Design your evaluation around that.