GPS Tracking Accuracy in Security Guard Apps: What Affects It and How to Fix It

Location can support a patrol record, but it does not by itself prove presence or completed work. The reading includes an accuracy estimate and may be influenced by buildings, indoor environments, device settings, background limits, and the available location providers.

For engineering and IT leaders at security companies, understanding the technical factors that degrade GPS accuracy, and knowing how to mitigate them, is essential for building a platform that clients trust.

Why GPS drifts near buildings

GPS receivers calculate position by measuring the time it takes for signals to travel from multiple satellites. This calculation assumes the signals travel in a straight line from satellite to receiver. Near tall buildings, that assumption breaks down.

Multipath interference

When satellite signals reflect off buildings before reaching the receiver, the longer path can distort the position estimate. This multipath error is common in dense urban environments, but its size varies with geometry, device hardware, sky visibility, and the positioning system's sensor fusion. Use the accuracy estimate and observed track behavior rather than assuming a fixed error range.

Multipath is worst in urban canyons, where tall buildings on both sides of a street create multiple reflection paths. It is also significant near large glass surfaces, metal cladding, and concrete walls. Security guards patrolling commercial office parks, downtown properties, and industrial complexes encounter these conditions routinely.

Reduced satellite visibility

Accurate GPS positioning requires a clear line of sight to at least four satellites. Near buildings, one or more satellites may be occluded by structures. With fewer satellites, the geometric dilution of precision (GDOP) increases, and accuracy degrades. Inside parking garages or building lobbies, satellite visibility may drop to zero, leaving the device with no GPS fix at all.

Doze mode and OEM-specific location restrictions

Even when satellite conditions are perfect, the device's operating system can prevent the app from receiving location updates. This is one of the most frustrating challenges in security app development because the behavior varies across manufacturers and OS versions.

Android Doze mode

Starting with Android 6.0, Doze mode restricts background activity when the device is stationary and the screen is off. During Doze, the system defers GPS updates, network access, and alarms. For a security guard standing at a post with the phone in their pocket, Doze can activate within minutes. The app stops receiving location updates, and the patrol trail goes silent.

The primary mitigation is to use a foreground service with a persistent notification. Foreground services are exempt from Doze restrictions and continue to receive location updates. The notification serves double duty: it keeps the service alive and it signals to the guard that tracking is active.

OEM battery optimization

Android device manufacturers, particularly Samsung, Xiaomi, Huawei, and Oppo, layer their own battery optimization on top of stock Android restrictions. These OEM-specific systems are aggressive and inconsistent. Samsung's "Sleeping Apps" feature, Xiaomi's "Battery Saver" and "MIUI Optimizations," and Huawei's "App Launch" controls can all kill background location tracking even when the app uses a foreground service correctly.

There is no universal programmatic solution to this problem. The practical approach combines several strategies:

• Detect the device manufacturer at runtime and display device-specific instructions guiding the guard to whitelist the app from battery optimization.
• Use the REQUEST_IGNORE_BATTERY_OPTIMIZATIONS permission on Android to prompt the user to exempt the app, though some OEMs ignore this setting.
• Implement a health check that detects gaps in location data and alerts both the guard and the operations center when tracking has been interrupted.
• Maintain an internal database of OEM-specific behaviors, updated as new devices and OS versions are released. The community resource dontkillmyapp.com provides a useful starting reference.

Fused Location Provider tuning

Google's Fused Location Provider (FLP) on Android combines GPS, Wi-Fi, cell tower, and sensor data to produce location estimates. It is significantly more accurate and battery-efficient than using the raw GPS provider directly. However, its default configuration is not optimized for security patrol use cases.

Priority settings

The FLP exposes a priority parameter that controls the tradeoff between accuracy and battery consumption:

• PRIORITY_HIGH_ACCURACY: uses GPS, Wi-Fi, and cell data. Provides the best accuracy but highest battery drain. Appropriate for active patrol tracking.
• PRIORITY_BALANCED_POWER_ACCURACY: uses Wi-Fi and cell data, activating GPS only when needed. Accuracy of approximately 40 meters. Suitable for stationary post monitoring where exact position is less critical.
• PRIORITY_LOW_POWER: relies primarily on cell towers. Accuracy of approximately 1 to 3 kilometers. Not suitable for guard tracking.

A well-designed patrol app should dynamically switch between priority levels based on the guard's current activity. During an active patrol route, use high accuracy. When the guard is stationary at a post for an extended period, drop to balanced power to conserve battery. Detect the transition using the Activity Recognition API or by monitoring the rate of location change.

Interval and displacement tuning

Update interval and minimum displacement affect track detail, battery use, and the volume of stored points. Choose them from the patrol workflow and test them on the deployed devices in representative buildings. A fixed interval that works outdoors may miss meaningful movement indoors or waste power while a guard is stationary.

On iOS, the equivalent tuning is done through CLLocationManager's desiredAccuracy, distanceFilter, and activityType properties. Setting activityType to .otherNavigation tells the system to optimize for continuous movement tracking, which matches patrol behavior.

Geofencing fallbacks and movement detection

GPS-based point tracking is not the only tool available for verifying guard presence. Geofencing provides a complementary approach that is more resilient to accuracy issues.

Hardware Geofencing

Both Android and iOS support hardware-accelerated geofencing, where the device's low-power location processor monitors geofence boundaries without waking the main application processor. On Android, the Geofencing API supports up to 100 active geofences per app. On iOS, the limit is 20 regions per app.

For security applications, set up geofences around each client site and critical checkpoint locations. When a guard enters or exits a geofence, the system delivers an event to the app. This provides a reliable, battery-efficient confirmation of presence even when continuous GPS tracking experiences gaps.

Combining geofences with checkpoint verification

Geofencing alone does not prove the guard walked the full patrol route. It proves presence at defined locations. Combine geofence events with other verification methods for a more complete picture:

• NFC or QR code scans at specific checkpoint locations provide definitive proof that the guard was within arm's reach of a physical tag.
• Wi-Fi fingerprinting can verify indoor location where GPS is unreliable. If the guard's device detects a known Wi-Fi access point at a checkpoint, that serves as a location signal even without GPS.
• Bluetooth beacons placed at patrol checkpoints provide proximity verification with a range of 1 to 10 meters, depending on signal strength configuration.

Movement detection for anomaly flagging

The Activity Recognition API on Android and CMMotionActivityManager on iOS can classify the user's movement as stationary, walking, running, or in a vehicle. This data adds context to location traces. If the GPS trace shows the guard moving between two checkpoints 500 meters apart, but the activity recognition data shows "stationary" during that period, the trace may be the result of GPS drift rather than actual movement. Flagging these anomalies for supervisor review improves data quality without burdening guards with additional verification steps.

Filtering and post-processing location data

Preserve the raw observation and its metadata before deriving a simplified route. Post-processing can flag or classify uncertain points, but silently rewriting the record makes later investigation harder.

• Mark points outside a site-specific accuracy threshold as uncertain. Whether to discard them depends on the use case and whether losing the observation is worse than retaining a low-confidence point.
• Apply a Kalman filter or simple moving average to smooth patrol traces and reduce the visual impact of GPS jitter.
• Detect and remove teleportation artifacts, where a guard's location jumps hundreds of meters between consecutive readings and then returns. These are nearly always GPS errors, not actual movement.

Presenting clean, filtered data builds confidence in the platform. When a client reviews a patrol report and sees a smooth, logical route rather than a scattered cloud of points, they trust the system. That trust is what retains contracts.