Architecting Geofencing for Android: Lessons in Battery Conservation

Opening hook

The silence in the lecture hall was absolute, punctuated only by the professor’s rhythmic pacing. I was deep into a complex algorithm proof when a sudden, jarring marimba riff cut through the room. It was my phone, tucked away in my bag, blaring at maximum volume. I felt the collective eyes of two hundred students turn toward me as I frantically scrambled to mute the device. That moment of visceral embarrassment stayed with me long after I left the room, leaving me wondering why my phone couldn’t simply understand where it was and adjust accordingly.

The problem

We live in a world of context-dependent behavior. When I am at a medical clinic, in a mosque, or sitting in a high-stakes meeting, I need my device to reflect the social environment. Yet, the burden of managing this state is entirely manual. Android offers Do Not Disturb and volume profiles, but toggling these based on location or time requires active intervention. If I forget to silence my phone, I risk disruption. If I remember to silence it but forget to restore the volume later, I miss important calls or notifications for the rest of the day.

I searched for a solution, but most existing apps were heavy, battery-draining monsters that required constant GPS polling or cloud-based server pings. I wanted something that felt like a native OS feature—something that sat quietly in the background, respected the hardware limitations of the device, and actually worked reliably without turning my phone into a space heater. The friction wasn’t just about sound; it was about the cognitive load of constantly monitoring my own device state throughout the day.

The technical decision / implementation

When I started building Muffle, my first instinct was to write a custom LocationListener and poll the GPS coordinates every few minutes. I quickly realized this was a recipe for disaster. Using the raw LocationManager to poll coordinates manually is the fastest way to drain a battery and annoy the Android system’s background execution limits. Instead, I pivoted to the GeofencingClient within the Google Play Services library.

This API allows you to define a circular boundary and let the system handle the heavy lifting. The OS manages the sensor fusion—switching between Wi-Fi, cell tower triangulation, and GPS—to determine when the device crosses the threshold. Crucially, the system batches these requests, meaning my app isn’t constantly waking up the processor. Here is how I registered a basic geofence trigger:

kotlin
val geofence = Geofence.Builder()
.setRequestId(routineId)
.setCircularRegion(lat, lon, radius)
.setExpirationDuration(Geofence.NEVER_EXPIRE)
.setTransitionTypes(Geofence.GEOFENCE_TRANSITION_ENTER or Geofence.GEOFENCE_TRANSITION_EXIT)
.build()

geofencingClient.addGeofences(geofenceRequest, pendingIntent)

The real architectural challenge wasn’t just registering the geofence, but ensuring that the BroadcastReceiver that handles the transition could reliably toggle the AudioManager. Because modern Android is aggressive about killing background tasks, I implemented a Foreground Service as the backbone of the application. By tying the service to a persistent notification, I ensure that the OS classifies the app as a high-priority process. This prevents the system from nuking my background sound-management logic, even when the screen is off. I had to carefully manage the AudioManager.RINGER_MODE_SILENT versus AudioManager.RINGER_MODE_NORMAL states to ensure that when a user leaves a defined location, the volume is restored to its previous user-defined setting rather than just jumping to full volume, which is a common failure point in simpler automation tools.

What surprised you / what you’d do differently

I initially assumed that the Geofence API would be hyper-accurate. I spent weeks refining the radius of my geofences, expecting a tight 50-meter perimeter to trigger consistently. I was wrong. The system frequently buffers the transition events to save battery, meaning the trigger might fire a few minutes after you actually cross the boundary, or sometimes even when you are hovering just outside the radius. Relying on precision-based logic for something like a silent mode is dangerous because the lag can be the difference between a quiet meeting and a loud notification.

If I were starting over, I would build a hybrid trigger system. I would combine the GeofencingClient with a secondary local check using Wi-Fi SSID monitoring. Geofencing is great for broad areas like a building or a neighborhood, but it is notoriously inconsistent in urban canyons where GPS signals bounce off buildings. By adding a rule that checks for a specific Wi-Fi network (like my office or home network), I could create a secondary handshake that confirms the location faster and more reliably.

Another surprise was how much power the Foreground Service consumes if you are performing complex logic inside the onReceive method of the broadcast receiver. I initially did a database query to look up the user’s routine settings every time a transition occurred. That added up to significant latency. I moved the routine data into an in-memory cache managed by a ViewModel and a Room database flow. By caching the active geofences in memory, I reduced the execution time of the transition handler to milliseconds, which kept the battery impact negligible.

Practical takeaway

As an Android developer, the biggest lesson I learned is that the system will always prioritize the user’s battery over your app’s performance. If you are building background tasks, do not fight the OS. Use the high-level APIs like GeofencingClient or WorkManager rather than trying to craft custom listeners that poll hardware sensors. The system is smarter than your code at finding the most efficient way to acquire a location. If your app feels slow, don’t try to hack the power management; optimize your data access patterns and move your logic into memory.

Automation should feel like an extension of the phone itself, not a separate, competing process. When you build with the assumption that the OS might kill your app at any second, you end up writing more resilient code that handles state restoration naturally. It’s about building for the user’s environment, not just the user’s intent. If you’re curious about how I implemented these triggers, you can see Muffle in action here: https://play.google.com/store/apps/details?id=com.muffle.app