Common Location Services Bugs and How to Catch Them

Common Location Services Bugs and How to Catch Them

Common Location Services Bugs and How to Catch Them

Location‑aware features are now a baseline expectation for mobile and web apps. When the underlying location service misbehaves, users see wrong maps, missed check‑ins, broken geofences, or battery drain that leads to uninstalls. This guide walks through the most frequent location‑service defects, explains why they arise, shows how they appear to real people, and gives repeatable steps to reproduce, detect, and fix each one. A test matrix at the end lets you compare manual checks with automated approaches, and a short checklist helps you bake prevention into every release.

1. How Location Services Work on the Platforms You Target

Before hunting bugs, you need a mental model of what the OS actually provides.

1.1 Android Location Architecture

Android abstracts location sources into providers: GPS (satellite), Network (Wi‑Fi/cell tower), and Passive (updates from other apps). The LocationManager API delivers Location objects that contain latitude, longitude, altitude, accuracy (horizontal radius in meters), speed, bearing, and a timestamp. Apps request updates with a combination of interval, fastest interval, priority (PRIORITY_HIGH_ACCURACY, PRIORITY_BALANCED_POWER_ACCURACY, PRIORITY_LOW_POWER, PRIORITY_NO_POWER), and smallest displacement. The system may throttle or stop updates based on battery‑optimization settings, foreground/background state, and user‑granted permissions (ACCESS_COARSE_LOCATION, ACCESS_FINE_LOCATION, ACCESS_BACKGROUND_LOCATION on Android 10+).

1.2 iOS Location Architecture

iOS uses CLLocationManager. Authorization levels are whenInUse, always, and never. The manager delivers CLLocation objects with similar fields (coordinate, altitude, horizontalAccuracy, verticalAccuracy, speed, course, timestamp). You set desiredAccuracy, distanceFilter, and activityType to influence power usage. Background location requires the location background mode and proper usage strings in Info.plist. iOS also imposes deferred updates and pause‑resume behavior when the device thinks the user is stationary.

1.3 Web Geolocation API

In browsers, navigator.geolocation.getCurrentPosition(success, error, options) and watchPosition expose a promise‑based interface. The options object lets you request enableHighAccuracy, timeout, and maximumAge. The API returns a Position object with coords.latitude, coords.longitude, coords.accuracy, coords.altitude, coords.altitudeAccuracy, coords.heading, coords.speed, and a timestamp. Permission prompts are shown by the browser; the site can only receive updates while the page is visible or has a service worker that maintains a background fetch (limited).

Understanding these fundamentals helps you spot where assumptions break: treating accuracy as a guarantee, ignoring provider switches, or forgetting that background behavior differs between platforms.

2. Bug Pattern 1 – Permission Denial Mis‑handling

2.1 Why It Happens

Developers often request location at app start and assume the callback will fire. If the user denies permission, the location manager returns an error (onProviderDisabled on Android, didFailWithError with kCLErrorDenied on iOS, or a PositionError with PERMISSION_DENIED on the web). When the error is ignored or swallowed, the UI shows stale data, a loading spinner that never resolves, or a silent failure that breaks dependent features (e.g., “Find Nearby Stores”).

2.2 User‑Visible Symptoms

• Map stays centered on the last known location or defaults to (0,0).
• “Locate me” button does nothing after a permission denial.
• Features that depend on location silently skip, leading to empty lists or incorrect calculations.

2.3 Reproducing the Bug

1. Install the app on a clean device or emulator.
2. Launch the app and immediately deny the location permission when prompted.
3. Observe whether the UI shows an error message, falls back to a default location, or hangs.
4. Repeat after granting permission to confirm the happy path works.

On the web, open the page in incognito mode, block location in the site settings, then reload.

2.4 Detection Strategies

Manual: Use the device’s settings to revoke location permission while the app is running, then trigger a location‑dependent action.

Automated:

• Android UIAutomator test: call pm revoke android.permission.ACCESS_FINE_LOCATION, then invoke the location request and assert that an error toast or fallback appears within 2 seconds.
• iOS XCTest: use XCUIDevice.shared.locationAuthorization = .denied (available via XCUITest extensions) and verify the error handling block runs.
• Web: Puppeteer script that sets page.setGeolocation(null) and page.evaluate(() => navigator.permissions.query({name:'geolocation'})) to check for denied state, then calls getCurrentPosition and asserts the error callback.

2.5 Fix & Prevention

• Always handle the error callback; show a clear UI message (“Location permission required to show nearby places”) and offer a shortcut to settings (ACTION_APPLICATION_DETAILS_SETTINGS on Android, UIApplicationOpenSettingsURLString on iOS, or a link to browser settings).
• Cache the last known good location only when accuracy meets a threshold; otherwise, treat it as unavailable.
• Add unit tests that mock the location manager to return a denial error and verify UI state transitions.

3. Bug Pattern 2 – Stale Cached Location

3.1 Why It Happens

Location APIs often return a cached location when no fresh fix is available quickly enough (e.g., indoor start‑up, GPS disabled). If the app treats that cached value as current without checking its age or accuracy, decisions based on distance, geofence entry/exit, or weather data become wrong.

3.2 User‑Visible Symptoms

• Weather widget shows forecast for a city you left hours ago.
• “You are here” marker lags behind your actual movement by several blocks.
• Geofence triggers fire late or not at all because the stored location is far from the real boundary.

3.3 Reproducing the Bug

1. Start the app outdoors with a good GPS fix, note the latitude/longitude.
2. Move indoors or turn off GPS/Wi‑Fi, then immediately trigger a location‑dependent action (e.g., refresh a nearby‑places list).
3. Compare the returned location’s timestamp to the current time; if it’s older than a few minutes and the app still uses it, you have reproduced the stale‑cache issue.

3.4 Detection Strategies

Manual: Use a location‑spoofing app (Android: Fake GPS Location; iOS: Xcode’s GPX track) to simulate movement, then disable the spoof and watch the app’s reported position.

Automated:

• Android Espresso test: acquire a location via LocationManager, then use Thread.sleep to simulate delay, call requestLocationUpdates again, and assert that the new Location has a timestamp within the expected maxAge (e.g., < 30 s).
• iOS XCTest: inject a mock CLLocationManager that returns a stale CLLocation with a timestamp set to -500 seconds, then verify the view model discards it.
• Web: Use Playwright to override navigator.geolocation.getCurrentPosition with a function that returns a position whose timestamp is Date.now() - 100000, then check that the UI shows a “location outdated” banner.

3.5 Fix & Prevention

• Always examine Location.getTime() (Android) or timestamp (iOS/Web) and compare against System.currentTimeMillis() (or Date.now()). Discard if older than a configurable threshold (typically 30 s‑2 min depending on use case).
• Pair the timestamp check with accuracy; a location that is both recent and accurate enough (e.g., < 50 m) is safe to use.
• When a cached location is the only data available, UI should indicate uncertainty (“Approximate location based on last known fix”).
• Add integration tests that inject stale locations and verify the UI does not act on them.

4. Bug Pattern 3 – Incorrect Coordinate Conversion

4.1 Why It Happens

Many apps need to display locations on a map that uses a different datum (e.g., converting from WGS84 latitude/longitude to Web Mercator for tile URLs, or to a local grid like UTM for distance calculations). Mistakes in the conversion formulas—mixing radians and degrees, using the wrong earth radius, or forgetting the sign of longitude—lead to placements that are off by kilometers or even placed in the wrong hemisphere.

4.2 User‑Visible Symptoms

• Pins appear in the ocean when they should be on land.
• Distance‑based features (running apps, delivery ETAs) report values that are 2‑3× too large or small.
• Users in the southern hemisphere see locations mirrored across the equator.

4.3 Reproducing the Bug

1. Pick a known coordinate pair (e.g., Statue of Liberty: 40.6892° N, ‑74.0445° W).
2. Feed it into your conversion routine and compare the output to a trusted library (e.g., proj4js, GeographicLib, or Android’s Projection).
3. If the result deviates beyond the expected tolerance (usually < 1 m for projection errors), you have a conversion bug.

4.4 Detection Strategies

Manual: Use a spreadsheet to compute expected values with a trusted formula and compare against your code’s output for a set of edge‑case points (poles, equator, anti‑meridian, extreme latitudes).

Automated:

• Write a parameterized JUnit test that feeds an array of latitude/longitude pairs into your conversion method and asserts that the result matches the reference implementation within a tolerance (e.g., assertEquals(expectedX, actualX, 0.01)).
• In iOS, use XCTest with CLLocationCoordinate2DMake and compare to MKMapPoint.
• For web, use a Jest test that imports your conversion utility and runs against turfjs transformations.

4.5 Fix & Prevention

• Encapsulate all conversion logic in a single, well‑tested module. Use battle‑tested libraries (PROJ, GeographicLib, turfjs) whenever possible instead of rolling your own.
• If you must implement a formula, annotate each constant with its unit (e.g., EARTH_RADIUS_METERS = 6378137.0) and write unit tests that cover quadrants, poles, and the date line.
• Add runtime sanity checks: after conversion, verify that the resulting point lies within the expected bounds of the projection (e.g., Web Mercator X/Y between ‑20037508.34 and 20037508.34).
• Document the datum and projection used in every API contract (e.g., “All latitude/longitude inputs are WGS84; all map tile coordinates are EPSG:3857”).

5. Bug Pattern 4 – Background Location Throttling

5.1 Why It Happens

Both Android and iOS aggressively limit background location to preserve battery. Android may switch from PRIORITY_HIGH_ACCURACY to a passive mode after a few minutes, or stop updates entirely if the app is in a background‑restricted bucket. iOS may deliver deferred locations or pause updates when the system detects the device is stationary. If your app assumes a constant update interval (e.g., every 5 seconds) for tracking a workout, you will see gaps in the recorded trace.

5.2 User‑Visible Symptoms

• Running or cycling apps show straight‑line segments between points, missing turns.
• Location‑based reminders trigger late or not at all when the phone is in a pocket or bag.
• Battery usage spikes because the app keeps re‑requesting updates after being throttled, causing a “ping‑pong” effect.

5.3 Reproducing the Bug

1. Start a location‑tracking session in the foreground, verify you receive updates at the requested interval.
2. Press the home button or switch to another app to move the app to the background.
3. Wait 2‑3 minutes, then bring the app back to the foreground and inspect the location log. You should see a gap or a significant increase in the distance between consecutive points.

On iOS, enable “Background App Refresh” off for the app to exacerbate throttling.

5.4 Detection Strategies

Manual: Use the device’s battery‑usage screen to confirm the app is in a background‑restricted state, then observe location logs.

Automated:

• Android UIAutomator: after starting location updates, call adb shell cmd appops set RUN_IN_BACKGROUND ignore to simulate background restriction, then assert that the interval between two successive Location objects exceeds a threshold (e.g., > 30 s).
• iOS XCTest: use XCUIApplication to press the home button, then invoke XCUICoordinate‑based wait for a location update, and verify the time delta.
• Web: Service workers do not receive geolocation updates when the page is hidden; you can test by opening the page, calling watchPosition, then switching tabs and measuring the callback delay.

5.5 Fix & Prevention

• Respect the system’s hints: on Android, use setPriority(PRIORITY_BALANCED_POWER_ACCURACY) for background work and listen for onProviderDisabled/onStatusChanged to adapt.
• On iOS, enable the location background mode and set allowsBackgroundLocationUpdates = true. Handle didPauseLocationUpdates and didResumeLocationUpdates delegates to pause/resume your tracking logic.
• Instead of relying on a fixed interval, compute distance or time‑based thresholds dynamically; if the system delivers a deferred location, process it as a batch.
• Log the actual interval between locations and alert developers during QA if the observed interval deviates beyond a tolerated margin (e.g., > 2× the requested interval).
• Add a test that forces background throttling (via adb shell am set-inactive on Android) and verifies the app gracefully handles missing updates without crashing or corrupting state.

6. Bug Pattern 5 – Mock Location Interference

6.1 Why It Happens

During development, testers often enable mock locations (Android: Settings > Developer options > Select mock location app; iOS: Xcode GPX simulation) to simulate routes without moving. If the production code does not distinguish real from mock locations, a tester may inadvertently ship an app that trusts fake data, leading to wrong geo‑fences, incorrect weather, or misleading analytics. Moreover, some malicious apps can inject mock locations to spoof a user’s whereabouts (e.g., cheating in location‑based games).

6.2 User‑Visible Symptoms

• A user who never left home appears in a distant city on a friend‑finder map.
• Geofence‑based offers fire when the user is actually far away.
• Leaderboards in a fitness app show impossible speeds (e.g., 200 km/h) because the mock location jumps rapidly.

6.3 Reproducing the Bug

1. Enable mock locations on a test device and select a simple GPX route that moves from point A to point B.
2. Run the app and observe the location stream.
3. Disable mock locations and repeat the same physical movement (or use a real‑world walk).
4. If the app’s behavior differs (e.g., triggers geofences only with mock data), the code is not guarding against mock locations.

6.4 Detection Strategies

Manual: Toggle the mock location setting and watch for changes in UI or analytics events.

Automated:

• Android: Use Location.isFromMockProvider() (API 18+) to check each Location object. In an Espresso test, start a mock location provider via adb shell cmd location set-test-provider-location , then assert that the app either ignores the location or labels it as “simulated”.
• iOS: There is no public API to detect mock locations, but you can monitor the CLLocation property horizontalAccuracy. Mock GPX files often produce implausibly low accuracy (e.g., 0 m). Flag values below a realistic threshold (e.g., < 5 m) as suspicious.
• Web: The Geolocation API does not expose a mock flag, but you can compare the reported timestamp against performance.now(); if the delay is consistently zero (indicating a synthetic immediate response), treat it as untrusted for security‑sensitive features.

6.5 Fix & Prevention

• On Android, always check Location.isFromMockProvider() before using the data for security‑or‑financial decisions. If true, either ignore the location or show a warning (“Location may be simulated”).
• On iOS, enforce a minimum accuracy threshold (e.g., horizontalAccuracy > 10.0) for features that could be abused; log any location with suspiciously low accuracy for review.
• In web applications, treat location data as untrusted for anything that could affect pricing, access control, or leaderboards. Use server‑side validation (e.g., verify IP‑based geolocation approximates the reported coordinates) when possible.
• Add unit tests that feed a mocked location with isFromMockProvider() == true and confirm that the app’s state machine transitions to a “mock‑detected” mode, preventing unintended actions.

7. Bug Pattern 6 – Accuracy Reporting Issues

7.1 Why It Happens

Developers sometimes treat the accuracy field as a guarantee that the true position lies within that radius. In reality, accuracy is an estimate; outliers can occur, especially in urban canyons or indoors where Wi‑Fi‑based fixes jump. If your app draws a fixed‑size circle or triggers an action when the estimated position enters a geofence, you may experience false positives/negatives.

7.2 User‑Visible Symptoms

• A “nearby friends” marker appears inside a building when the user is actually outside, causing confusion.
• A geofence‑based reminder fires while the user is still several blocks away because the reported accuracy was overly optimistic.
• Conversely, a check‑in fails to register because the reported accuracy is large (e.g., 500 m) even though the user is standing exactly at the venue.

7.3 Reproducing the Bug

1. Stand in a known location with a strong GPS signal, note the accuracy value (often < 10 m).
2. Move to a spot with poor reception (e.g., underground parking) and observe the accuracy value increase dramatically.
3. Trigger a location‑dependent action that uses a fixed radius (e.g., “if distance < 50 m then show offer”). If the action fires despite the large accuracy, you have reproduced an accuracy‑trust bug.

7.4 Detection Strategies

Manual: Use a signal‑blocking pouch or move between open sky and indoor areas while watching the accuracy value in logcat (adb logcat | grep Location) or console.

Automated:

• Android Espresso test: use a mock location provider to emit a series of Location objects with varying accuracy (5 m, 50 m, 500 m). Assert that your geofence‑checking logic only returns true when the accuracy is below a configurable threshold (e.g., < 100 m).
• iOS XCTest: inject a CLLocation with horizontalAccuracy set to 0, 20, and 1000, then verify that your decision function behaves as expected.
• Web: Use Playwright to override navigator.geolocation.getCurrentPosition with a custom payload that sets coords.accuracy to different values, then check that the UI displays an “accuracy low” warning when appropriate.

7.5 Fix & Prevention

• Never rely solely on accuracy as a hard boundary. Instead, compute a probabilistic confidence: if accuracy > X, increase the effective geofence radius by that amount (or require multiple consecutive accurate readings).
• Provide UI feedback when accuracy is poor (“Location accuracy low – try moving outdoors”).
• Store a history of recent accuracies and use the median or a weighted average to smooth sudden jumps.
• Add integration tests that simulate low‑accuracy bursts and assert that false triggers stay below an acceptable rate (e.g., < 1 % over 100 simulated points).

8. Bug Pattern 7 – Geofence Trigger Failures

8.1 Why It Happens

Geofences rely on the OS to monitor transitions across a circular region. Common pitfalls include: registering too many geofences (Android limits to 100 per app), using an excessively small radius (less than the minimum detectable distance, often ~ 50 m on Android, ~ 10 m on iOS), failing to handle GEOFENCE_TRANSITION_DWELL correctly, or not accounting for the delay between crossing the boundary and receiving the callback (which can be several seconds to minutes).

8.2 User‑Visible Symptoms

• A retail app never sends a “welcome” push when you enter the store.
• A parental‑control app fails to log when a child leaves a safe zone.
• Users receive duplicate enter/exit events because the dwell time was not configured.

8.3 Reproducing the Bug

1. Register a geofence with a radius of 10 m (below the platform’s practical limit).
2. Walk across the boundary at a normal pace.
3. Observe whether the onGeofenceTransition (Android) or didEnterRegion / didExitRegion (iOS) fires.
4. Increase the radius to 100 m and repeat; the event should now fire reliably.

8.4 Detection Strategies

Manual: Use a GPS‑trace app to record your path, then compare the timestamps of actual crossing with the timestamps of received geofence callbacks.

Automated:

• Android UIAutomator test: use adb shell cmd location add-test-provider-location to inject locations that simulate crossing a geofence, then assert that the broadcast receiver receives the expected intent within a reasonable window (e.g., < 30 s).
• iOS XCTest: use CLLocation simulations via XCUIApplication and XCUICoordinate to drive the location manager, then verify that the delegate methods are called.
• Web: The Geolocation API does not provide native geofencing; if you implement your own, unit‑test the distance‑calculation logic with edge cases (point exactly on the boundary, point just inside, point just outside).

8.5 Fix & Prevention

• Respect platform limits: keep the total number of active geofences below the maximum, and prune unused ones.
• Choose a radius that is at least the platform’s minimum detectable distance plus a buffer for GPS error (e.g., ≥ 50 m on Android, ≥ 15 m on iOS).
• Use the dwell transition type (GEOFENCE_TRANSITION_DWELL) when you need to confirm the user has stayed inside for a minimum time, reducing false positives from brief GPS jitter.
• Always handle the error intent (GEOFENCE_ERROR) and log the error code (GEOFENCE_NOT_AVAILABLE, GEOFENCE_TOO_MANY_GEOFENCES, etc.) to aid debugging.
• Add a test suite that injects location sequences crossing, lingering inside, and exiting each geofence, verifying that the correct transition events are emitted exactly once per crossing.

9. Bug Pattern 8 – Network Provider Fallback Errors

9.1 Why It Happens

When GPS is unavailable, Android may fall back to the network provider (Wi‑Fi/cell tower). This provider is less accurate and can sometimes return a location that is wildly incorrect (e.g., placing you in a neighboring city) if the cell tower database is stale or the Wi‑Fi access point list is outdated. If your app treats the network provider as interchangeable with GPS, you may see sudden jumps in the tracked path.

9.2 User‑Visible Symptoms

• A jogging map shows a straight line from your house to a location miles away, then back, whenever you enter a building with poor GPS.
• Weather widget switches forecast to a distant city when you lose satellite signal indoors.
• Battery drains faster because the app keeps requesting high‑accuracy updates while the network provider cannot satisfy the request, causing repeated retries.

9.3 Reproducing the Bug

1. Start the app outdoors with a solid GPS fix.
2. Move into a location where GPS is blocked (e.g., a metal‑framed elevator) but Wi‑Fi is available.
3. Watch the location updates; if the latitude/longitude jumps to a point corresponding to the Wi‑Fi router’s known location (often the ISP’s headquarters), you have observed a bad network fallback.

9.4 Detection Strategies

Manual: Disable GPS via developer options (Settings > Developer options > Mock GPS off and turn off GPS switches) while keeping Wi‑Fi on, then observe the location stream.

Automated:

• Android Espresso test: use adb shell svc gps disable to turn off GPS, then use a mock network location provider (adb shell cmd location set-test-provider-location) to feed a deliberately erroneous coordinate. Assert that either the app discards the location (based on accuracy) or flags it as low confidence.
• iOS: There is no direct way to force a network‑only fix, but you can disable Location Services for the app, then re‑enable it while the device is in Airplane Mode (which disables GPS but may still allow Wi‑Fi‑based location if Wi‑Fi is on).
• Web: Use Chrome DevTools to override the geolocation with a custom position that simulates a network‑based fix (low accuracy, large radius). Verify that your app treats it appropriately.

9.5 Fix & Prevention

• Always examine the provider field of a Location (Location.getProvider() on Android, CLLocation does not expose provider but you can infer from horizontalAccuracy and timestamp age). If the provider is "network" and the accuracy exceeds a threshold (e.g., > 100 m), consider the location unreliable for high‑precision features.
• For tracking apps, interpolate between the last good GPS fix and the new network location only if the time gap is short (< 30 s) and the distance is plausible given the user’s maximum speed.
• Provide a UI indicator (“Using network location – accuracy may be low”) when the app relies on the fallback.
• Log provider changes and accuracy spikes to your analytics; a sudden increase in network‑provider usage can signal a GPS‑blocking issue worth investigating.
• Add a test that forces the network provider and verifies that the app does not trigger actions that depend on sub‑50 m precision (e.g., NFC‑based check‑ins).

10. Bug Pattern 9 – Timezone/Date‑Time Misalignment from Location

9.1 Why It Happens

Some apps derive the local timezone from the device’s location (e.g., showing event times in the user’s current zone). If the location service returns a stale or incorrect coordinate, the inferred timezone can be wrong, causing schedule displays to shift by an hour or more. This is especially problematic for travel apps, calendar integrations, and financial apps that timestamp transactions.

9.2 User‑Visible Symptoms

• A flight‑tracking app shows departure time as 2 PM local when the airport is actually in a different zone, causing the user to miss the flight.
• A chat app displays message timestamps incorrectly after crossing a border.
• A banking app logs a transaction with a timestamp that does not match the user’s local time, leading to confusion in statements.

9.3 Reproducing the Bug

1. Set the device’s timezone manually to a known value (e.g., America/New_York).
2. Spoof the location to a point in a different timezone (e.g., latitude/longitude in London).
3. Observe whether the app updates its displayed times to match the spoofed location’s timezone or sticks to the device’s manual setting.

If the app follows the spoofed location despite the user’s explicit timezone preference, you have a location‑driven timezone bug.

9.4 Detection Strategies

Manual: Change location via a mock GPX route while watching the clock in the app; compare to the system clock shown in the status bar.

Automated:

• Android UIAutomator test: after setting a mock location, query java.util.TimeZone.getDefault().getID() and compare it to the timezone derived from the location (using a library like TimezoneFinder). Assert that the app’s displayed time matches the user’s chosen timezone, not the location‑derived one, unless the app explicitly states it follows location.
• iOS XCTest: use NSTimeZone.system and compare against the timezone calculated from the spoofed CLLocation via CFTimeZoneCopyDefault.
• Web: Use Jest to mock navigator.geolocation.getCurrentPosition to return a coordinate in a different zone, then check that Intl.DateTimeFormat().resolvedOptions().timeZone remains unchanged if the app is supposed to respect the user’s setting.

9.5 Fix & Prevention

• Make timezone selection an explicit user preference with a clear setting (“Use device timezone” vs “Use location‑based timezone”).
• If you do derive timezone from location, validate the coordinate’s accuracy and recency before applying the change; fallback to the device’s timezone if the location is stale or low accuracy.
• Show a transient notice when the timezone changes due to location (“Detected new location – updating times to local zone”).
• Unit‑test the timezone‑lookup function with edge cases: points near timezone boundaries, locations with low accuracy, and timestamps that cross DST shifts.
• In analytics, log the source of timezone (device vs location) to detect unexpected switches in the wild usage data.

11. Bug Pattern 10 – Battery Optimizer Killing Location Updates

10.1 Why It Happens

Aggressive battery‑saver modes (Android’s Battery Optimization, iOS’s Low Power Mode, or manufacturer‑specific apps) can suspend background services, throttle alarms, or stop location updates altogether to extend battery life. If your app assumes that a started location service will keep running, you may see the tracking stop silently after the device enters a power‑saving state.

10.2 User‑Visible Symptoms

• A fitness tracker stops recording distance after the phone has been in a pocket for a few minutes, showing a flat line on the map.