Telegram-канал reddit_androiddev - AndroidDev - Reddit: Unsorted

AndroidDev - Reddit

21 March 2026 23:20

roughly 40% of the time. When it works, subsequent getCurrentLocation(HIGH_ACCURACY) calls start succeeding again.

Solution 4: Explicit outcome type

The original code returned Unit from the location request method. The caller had no way to distinguish a fresh 10-meter GPS fix from a 5-hour-old cached position. I changed the return type to make this explicit:

sealed interface GpsLocationOutcome {

data class FreshGps(val accuracy: Float) : GpsLocationOutcome

data class CellFallback(val accuracy: Float) : GpsLocationOutcome

data class WakeProbeSuccess(val accuracy: Float) : GpsLocationOutcome

data class StaleLastLocation(val ageMs: Long) : GpsLocationOutcome

data object TotalFailure : GpsLocationOutcome

}

Now the caller can make informed decisions. A fresh GPS fix means high confidence. A cell fallback at 3 kilometers is useful but low precision. A stale location from 5 hours ago is a warning, not data.

An important design decision: CellFallback is treated as neutral — GPS hardware is still broken (do not reset the failure counter), but usable data exists (do not trigger aggressive backoff either).

The consumer looks like:

when (outcome) {

is FreshGps, is WakeProbeSuccess -> reportGpsSuccess()

is CellFallback -> { /* GPS broken but we have data */ }

is StaleLastLocation, is TotalFailure -> reportGpsFailure()

}

An unexpected race condition

I had multiple independent trigger paths requesting GPS concurrently. Two of them fired within 33 milliseconds of each other. Both read the same getLastLocation(), both passed the stationarity filter, and both inserted a GPS reading. The result was two identical readings 33 milliseconds apart.

My code uses a minimum-readings-per-cluster filter to discard drive-through locations (a place needs at least 2 GPS readings to count as a real visit). The duplicate entry from the race condition defeated this filter — a single drive-by became a "cluster of 2." The fix was a Mutex around the entire processLocation path:

private val processLocationMutex = Mutex()

suspend fun processLocation(location: Location) {

processLocationMutex.withLock {

val lastLocation = getLastLocation()

// the second concurrent caller now sees the just-inserted

// location and correctly skips as duplicate

}

}

Additional note on dependency versions

I was using play-services-location 21.0.1 for months. Upgrading to 21.3.0 resolved some GPS reliability edge cases I had not yet identified. If you are doing background location work, it is worth checking whether your dependency version is current.

Summary

getCurrentLocation() can hang indefinitely on OEM-throttled devices. Always wrap it in withTimeoutOrNull. Build a priority fallback chain through all available location sources. Consider a brief

wake probe for GPS hardware recovery. Return an explicit outcome type so callers know the quality of data they received. If you have multiple GPS trigger paths, serialize them with a Mutex.

I have only tested this on Honor. I would be interested to hear whether anyone has observed similar GPS hardware suspension on other manufacturers.

https://redd.it/1s028ty
@reddit_androiddev