We have all been there: a meeting starts, and suddenly your phone rings. I built Muffle to automate silent profiles, but the biggest hurdle wasn't the UI—it was making sure the app didn't destroy the user's battery while monitoring GPS coordinates.

The Trap of Continuous Location Updates

Early prototypes used LocationManager with frequent updates. This is the fastest way to get your app uninstalled. Keeping the GPS radio active in the background forces the device to wake the CPU constantly, leading to significant battery drain. To solve this, I moved away from active polling and shifted to the GeofencingClient API.

Leveraging GeofencingClient for Passive Monitoring

Instead of calculating distance from a point every few seconds, I transitioned to system-level geofencing. By defining circular regions around locations like the office or a mosque, the OS handles the monitoring at the hardware abstraction layer.

kotlin
val geofencingRequest = GeofencingRequest.Builder()
.setInitialTrigger(GeofencingRequest.INITIAL_TRIGGER_ENTER)
.addGeofences(geofenceList)
.build()

This approach allows the OS to do the heavy lifting. The app stays in a dormant state until the location provider signals a transition. The kernel only wakes the app when the device enters or exits the radius.

The Trade-off: Precision vs. Power

Using GeofencingClient means accepting a slightly slower trigger time compared to raw GPS polling. Sometimes, there is a delay of a few seconds as the device wakes from a deep sleep state.

For a utility like Muffle, this is a fair trade-off. Users prefer their phone to silence five seconds after entering a building rather than finding their battery dead by noon. To mitigate the delay, I combined geofencing with a secondary intent service that performs a final check once the geofence trigger hits, ensuring that we aren't just reacting to a momentary GPS jitter.

Final Thoughts

By offloading the monitoring to the platform's native geofencing API, I was able to keep Muffle running 24/7 without a noticeable impact on daily battery usage. Building in public means being honest about these limitations; sometimes, the best engineering decision is to let the operating system handle the complexity rather than trying to write a custom, power-hungry implementation from scratch.