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

DEVSFLOW Guarding · 2026

GPS tracking is the backbone of modern security guard management. It verifies that patrols are completed, proves guard presence at client sites, and provides the location data that feeds into compliance reports. But GPS accuracy in the real world is far messier than it appears on paper. Guards patrol near high-rise buildings, inside parking structures, along building perimeters where signals reflect off glass and steel. The app reports a location 50 meters from where the guard actually stands, and suddenly the entire patrol record is in question.

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 a GPS signal bounces off a building facade before reaching the device, the receiver calculates a longer travel time than the actual straight-line distance. This is called multipath interference, and it is the primary cause of GPS drift in urban environments. The error can range from 10 to 50 meters depending on the geometry of the surrounding structures.

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

The setInterval() and setSmallestDisplacement() parameters control how frequently the app receives location updates. For patrol tracking, an interval of 10 to 30 seconds with a minimum displacement of 5 meters works well. This captures meaningful movement without flooding the database with redundant points when the 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

Raw GPS data always contains noise. Post-processing on the server side can clean the data before it is presented to supervisors or fed into compliance reports.

• Discard location points with a reported accuracy worse than a defined threshold, typically 50 to 100 meters depending on the environment.
• 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.