Closed FrikkieSnyman closed 1 year ago
https://issuetracker.google.com/issues/181711691
Android is not planning on changing this behaviour to sendMessageDelayed
:
This is working as intended. The caller shouldn't use the Long.MAX_VALUE as the delay, as it'll guarantee there will be an overflow. And what's the point to schedule a handler with infinity delay?
Overview
On Android, if we call
getCurrentPosition
using the"android"
provider, we default toLong.MAX_VALUE
if notimeout
is passed.In turn, this
timeout
gets passed tomHandler.postDelayed
, which is meant to reject the call once the timeout has been reached.However,
postDelayed
makes use ofsendMessageDelayed
under the hood, which then finally callssendMessageAtTime
- using thedelay
and addingSystemClock.uptimeMillis()
to it.Essentially, using
Long.MAX_VALUE
causes an overflow here, and leads to the reject timeout triggering immediately.It could be argued that having an
infinite
timeout as default does not make sense anyway, and setting it to 10 minutes is much more sensible.Test Plan
Call
getCurrentPosition
with notimeout
specified - it should return a location instead of rejecting withLocation request timed out
.