In field applications the most insidious bug is code that appears to work and quietly stops. The courier's phone goes into a pocket, the screen locks, and the panel stops sending location without raising a single error. It is discovered in the evening, when deliveries are missing from the map.
Do not assume before you measure
The obvious fix was to shorten the reporting interval. Before doing that we measured the baseline: on the same device under the same conditions, the browser-based panel went completely silent four minutes and forty-three seconds after the screen locked, with no request at all for three hundred and twenty seconds. Shortening the interval would not have shortened that silence — it would only have produced a little more data before it began.
The reason is simple: mobile operating systems suspend a background browser tab along with its timers. That is not a bug; it is a deliberate design decision for battery life. Trying to defeat it from inside the browser is a race against something more stubborn than you are.
The right layer: a foreground service
The fix was to move location reporting out of the browser and into a native foreground service. Because a foreground service shows the user a persistent notification, the system protects it from being killed. The interface can still run in a web view; the only thing that matters is that the web view is not the thing sending location.
Measured on the same device with the same locked screen: forty-three requests over ten minutes and forty-two seconds, with a longest gap of 15.8 seconds. Because the baseline was taken first, we can say the difference is real.
The work is not finished when the measurement is
This result was taken on an emulator. On devices with a vendor layer — brands applying aggressive battery management — behaviour may differ, so the feature is not complete until the same measurement is repeated on real hardware. A gate that shows green on an emulator is no guarantee it stays green in the field.