Live GPS tracking sounds simple in theory โ the app knows the phone's location, so it just sends it. In practice, two things get in the way constantly: guards don't keep an app open and on screen for an entire 8- or 12-hour shift, and not every site has reliable mobile network coverage. Raksha Kavach's tracking is built to keep working through both.
Tracking without the app being open
Location sharing runs as a genuine background task on the guard's phone, not something that stops the moment they switch to another app or lock their screen. This relies on Android's background location APIs, backed by a foreground-service notification โ a small persistent notification that tells the guard tracking is active. This isn't a design choice specific to Raksha Kavach; Android requires it for any app doing background location work, precisely so a user always knows when they're being tracked in the background.
Tied to duty status, not a manual switch
For a guard, location sharing is automatic โ tied to whether they're currently on duty, based on their attendance punch. There's no separate toggle for a guard to remember to turn on or off; being checked in is what activates it, and checking out stops it.
Supervisors get an explicit toggle
A supervisor doesn't have the same automatic signal a guard's attendance punch provides โ a supervisor overseeing multiple sites might not punch in and out the same way. So supervisor location sharing is controlled by an explicit "share my live location" toggle in their own app, persisted across sessions, giving them direct control over when they're visible on the live map.
What happens without network coverage
A location fix that can't reach the server immediately โ because the guard is somewhere with no signal, common at industrial sites or on the outskirts of smaller towns โ isn't simply lost. It's stored locally on the device in a queue. Once connectivity returns, the queue flushes automatically, both on a regular background interval and whenever the app comes back to the foreground, so a guard doesn't need to do anything for the backlog to catch up.
Timestamps stay honest
A detail that matters more than it sounds: when a queued fix finally syncs, it's recorded with the time it was actually captured, not the time the sync happened to succeed. Without this, a guard's location history after a connectivity gap would show a burst of positions all stamped at the same moment they reconnected โ misleading if anyone ever needs to reconstruct where a guard actually was during that gap.
What shows up on the live map
The admin/HR live map reflects all of this directly โ a guard whose latest fix hasn't updated in a while is shown as stale rather than presented as current, so a supervisor isn't misled into thinking a guard's last-known position is their position right now.
Conclusion
Background tracking that only works with the app open, or that silently loses data whenever a site has poor signal, isn't reliable enough to actually run operations on. Raksha Kavach's tracking is built around the two realities of fieldwork in India โ phones stay in pockets, and coverage isn't universal โ rather than assuming ideal conditions.