Opening hook
It happened during a quiet Friday Jumu'ah prayer. The imam had just reached the most solemn part of the khutbah when a high-pitched, insistent ringtone echoed through the entire hall. Heads turned, whispers started, and the person responsible scrambled to silence their device, only to fumble and drop it in their haste. I sat there, mortified for them, knowing exactly how that sinking feeling felt. It is the universal experience of the modern digital age: the gap between our intentions to be polite and our actual ability to manage our phone's state in public spaces.
The problem
We live in a world of constant notification, yet we lack a standard way to govern our devices based on our physical context. Android provides AudioManager and NotificationManager, but these are reactive tools that require manual input. I tried using standard alarm-based triggers, but they lacked the spatial awareness I needed. If I am at the office, I want my phone on vibrate. If I am at home, I want it back to normal. If I am at a medical clinic, I need it on silent.
Most existing solutions rely on heavy GPS polling, which drains the battery within hours. They treat location services as a raw stream of coordinate data rather than a state-based trigger. I wanted something that functioned entirely in the background, survived system reboots, and operated without a constant drain on the user's battery life. The friction wasn't just about silence; it was about the cognitive load of having to remember to switch profiles. I wanted my phone to handle the context switching for me, autonomously and reliably, without becoming a battery-draining nightmare.
The technical decision / implementation
To solve this, I moved away from manual polling and adopted the GeofencingClient within the Google Play Services location APIs. The decision to use this over raw LocationManager updates was rooted in battery efficiency. The GeofencingClient pushes the heavy lifting to the OS level. It uses a combination of Wi-Fi, cell tower, and GPS data, optimized by the system to wake up my application only when a transition boundary is crossed. This is significantly more energy-efficient than building a custom LocationListener that fires every few seconds.
However, implementing this required a robust IntentService architecture. I needed to ensure that my background worker, which I implemented as a ForegroundService to satisfy Android's background execution limits, could handle the GeofencingEvent correctly even if the application process was killed.
kotlin
val geofenceRequest = GeofencingRequest.Builder().apply {
setInitialTrigger(GeofencingRequest.INITIAL_TRIGGER_ENTER)
addGeofences(geofenceList)
}.build()
val intent = Intent(context, GeofenceBroadcastReceiver::class.java)
val pendingIntent = PendingIntent.getBroadcast(context, 0, intent, PendingIntent.FLAG_UPDATE_CURRENT or PendingIntent.FLAG_IMMUTABLE)
geofencingClient.addGeofences(geofenceRequest, pendingIntent)
By leveraging PendingIntent, I detached the trigger logic from the app process. When the geofence boundary is crossed, the OS sends an intent to my BroadcastReceiver, which then wakes up the ForegroundService to toggle the AudioManager state. This architecture is crucial. It ensures that even if the OS aggressively reclaims memory, the trigger remains active because the registration is held by the Google Play Services process, not mine. I specifically chose FLAG_IMMUTABLE to comply with modern Android security standards, preventing other apps from hijacking the intent extras and potentially triggering silent modes maliciously.
What surprised you / what you'd do differently
What I didn't anticipate was the erratic behavior of GPS on Android devices when they enter 'Doze' mode. I initially assumed that if I registered a geofence, it would fire with high precision regardless of the device state. I was wrong. On certain manufacturers, aggressive battery optimizations would suppress the geofence transition until the user manually woke the screen, effectively defeating the purpose of an automated silent profile.
I spent three weeks debugging why my testing device wouldn't trigger the 'exit' event while in my pocket. It turned out to be the WorkManager interaction. I had to force the app to ignore battery optimizations for the specific use case of the background service. If I were starting over, I would build in a more transparent 'debug log' system for the user. I spent far too much time relying on logcat, but seeing the actual state transitions in a readable list would have saved me days of frustration. Another thing I would change is the dependency on the Play Services location library. While it is efficient, it is a black box. If the system decides to deprioritize your geofence due to low battery, you have no visibility into why. I would implement a fallback mechanism using proximity sensors or Wi-Fi SSID detection to 'double-check' the geofence location in high-stakes environments like a prayer hall or a boardroom.
Practical takeaway
For any developer working on background location services, the biggest lesson is to stop fighting the OS and start working with its limitations. Do not try to implement your own polling loop; you will never beat the system engineers at Google when it comes to power management. Instead, use the high-level APIs like GeofencingClient and focus your energy on the edge cases: what happens when the GPS signal is lost? What happens when the user is in a basement?
Designing for background execution is a exercise in managing state persistence. Always assume your app will be killed at the most inconvenient time. By using PendingIntent and ensuring your state is stored in a local database (I used Room), you can recover your configuration instantly upon a system reboot. If you want to see how I handled these transitions in practice, you can look at the implementation of Muffle, which uses these principles to manage sound profiles without the user ever needing to touch their settings again. You can see the result of this work at https://play.google.com/store/apps/details?id=com.muffle.app. Building for the background is hard, but it is the only way to create tools that truly feel like a natural extension of the phone's hardware.
Top comments (0)