Muffle settled on a 150-metre geofence after smaller radii missed the entry event

Call addGeofences and the app stops measuring anything. You hand Play Services a GeofencingRequest and a broadcast PendingIntent, and the system monitors proximity from then on, which is cheaper than a foreground service recomputing Location.distanceTo() on every update ^[3]. The snippet in the post sets INITIAL_TRIGGER_ENTER and builds the intent with FLAG_UPDATE_CURRENT or FLAG_MUTABLE ^[15]. What you give up is control over when the intent arrives, because the system fuses Wi-Fi, cell towers and GPS and batches the updates ^[4].

The 100-metre finding follows from that batching. "I found that setting a radius smaller than 100 meters was essentially useless," the developer wrote ^[6]. The entry event would often not fire, since the device confirmed its position only after the user had already walked past the boundary ^[7]. He shipped a 150-metre default, which he says gives the radio enough time to triangulate without consuming excessive power ^[8]. Area scales with the square of the radius, so 150 squared over 100 squared is 2.25: the working geofence covers about 70,700 square metres against 31,400 ^[18].

Two of the fixes he describes sit outside the geofencing API entirely. Doze throttles location updates further when the device is stationary and deep in power saving ^[9]. So he added a check against Wi-Fi BSSIDs where they were available, a soft confirmation of location that does not need a high-drain GPS lock ^[10].

"I had assumed that the GeofencingClient would behave identically on a Google Pixel and a heavily skinned device from a budget manufacturer. I was wrong," he wrote ^[11]. Some manufacturers aggressively kill background processes even when they are properly registered as a ForegroundService ^[12]. On one device the triggers were not firing because the system had put the PendingIntent into a suspended state after the app went unopened for a while, and he spent days finding it ^[13]. His answer was a periodic AlarmManager task to keep the service warm enough for the system to respect the registration: an alarm whose only job is to remind the OS the app still exists ^[14].

In my view the radius is the least interesting number in the account. This is one developer's experience report, and it does not include battery figures, measured trigger latency, or the names of the handsets tested ^[17]. For 150 metres to transfer, your users would have to arrive on foot, into buildings with comparable Wi-Fi and cell density, on a device mix like his. The fused provider stays a black box that sometimes relies on cell tower handoffs, and those can be wildly inaccurate ^[16].