Opening hook
The silence in the lecture hall was heavy, the kind that only exists right before a professor delivers a final exam prompt. I was three rows from the front, pen hovering over my paper, when my phone vibrated. It wasn't just a buzz; it was a rhythmic, aggressive thrum against the wooden desk that sounded like a jackhammer in the quiet room. Every head in the room turned toward me. I fumbled to silence it, but in my panic, I accidentally toggled the volume up instead. My face burned as I finally muted it, but the distraction was absolute.
The problem
That moment of public humiliation sparked a realization: I was building tools for productivity, but I was failing to manage the basic friction of my own life. We spend our days obsessing over app performance and UI latency, yet we completely ignore the social friction our devices create. I needed a system that understood context. If I am at the office, I want a specific sound profile. If I am at a place of worship, I need complete silence. If I am at the gym, I need volume enabled.
Existing solutions fell into two camps. Either they were manual, requiring me to remember to flip a switch, which I clearly wasn't doing, or they were bloated, battery-draining monsters that requested GPS access every five seconds. I didn't want a background process that scorched my battery life just to track my location. I needed an event-driven system that respected the hardware constraints of modern Android devices. Most developers treat location tracking as a blunt instrument, firing up high-accuracy GPS whenever an app is in the background. That approach is a death sentence for battery health and, ultimately, user retention.
The technical decision / implementation
When I started building Muffle, I knew that relying on a polling mechanism—where the app wakes up periodically to check LocationManager.getLastKnownLocation()—would be an architectural failure. Instead, I leaned into the GeofencingClient API. This is a wrapper provided by Google Play Services that offloads the heavy lifting to the system hardware. By using this API, I don't have to manually monitor GPS coordinates. The system does the monitoring for me at the OS level, using a combination of cell towers, Wi-Fi, and Bluetooth, which are significantly more energy-efficient than raw GPS.
However, the challenge isn't just triggering the event; it's how you handle the transition. I implemented an IntentService that acts as the entry point for geofence transitions. When the system detects a geofence crossing, it sends an Intent to my broadcast receiver. I then determine if the transition is an ENTER or EXIT event. This is crucial for avoiding the "flicker" problem, where a phone might toggle back and forth between modes if the user is standing right on the edge of a geofence boundary.
kotlin
val geofencingRequest = GeofencingRequest.Builder().apply {
setInitialTrigger(GeofencingRequest.INITIAL_TRIGGER_ENTER)
addGeofence(myGeofence)
}.build()
geofencingClient.addGeofences(geofencingRequest, geofencePendingIntent)
.addOnSuccessListener { /* Successfully added / }
.addOnFailureListener { / Handle error */ }
To ensure this doesn't drain the battery, I set the loiteringDelay carefully. I don't want the sound profile to flip the moment a user walks past a building. I added a two-minute buffer. If the user stays within the boundary for more than 120 seconds, only then does the app initiate the AudioManager call to switch to silent or vibrate. This prevents constant, unnecessary profile switching while walking down a city street, effectively turning a noisy data stream into a stable, useful state machine.
What surprised you / what you'd do differently
What I learned the hard way was that the system isn't always as cooperative as the documentation suggests. I assumed that if I set a geofence, the device would report the transition reliably. I was wrong. Android’s battery optimization features, particularly those introduced in newer API levels, are aggressive. If the system decides your app is a "battery hog," it might silently kill your broadcast receiver or delay the intent delivery, rendering your geofence useless.
I spent three days debugging why my routine wouldn't trigger at the office. It turned out that the user (me) had enabled "Battery Saver" mode, which throttles background location access entirely. My initial approach was to just hope the system prioritized my app, but that was naive. If I were building this again from scratch, I would integrate a secondary fallback mechanism. I would use AlarmManager to perform a "heartbeat" check if no geofence triggers have been received in over four hours. This acts as a sanity check. If the geofence event was missed, the heartbeat catches the discrepancy and syncs the sound profile to the correct state.
Another surprise was the complexity of dealing with overlapping geofences. If a user defines a geofence for their home and a separate one for their workplace, and those boundaries accidentally overlap, the onReceive callback can trigger in an unpredictable order. I had to build a priority queue system that evaluates all active routines based on a custom priority integer, ensuring that the "Work" routine always overrides the "Home" routine if the user happens to have them nested. Never assume the OS will deliver events in the order you expect.
Practical takeaway
Building a location-aware app is rarely about the complexity of the math; it is almost always about managing the OS's desire to kill your processes to save power. When you're working with location services, stop thinking about "real-time" and start thinking about "eventual consistency." Assume your triggers will fail, your receivers will be throttled, and the device will run out of power. Build your architecture to be self-healing.
If you are working on a similar feature, always use the system-level APIs provided by Google Play Services rather than trying to roll your own location listener. You cannot beat the OS at its own game when it comes to power management. Embrace the limitations of the background execution model by using a robust state management system that can recover from being killed by the system. If you want to see how I managed these state transitions and handled the priority logic for my own project, you can see how I implemented the logic in Muffle: https://play.google.com/store/apps/details?id=com.muffle.app. It is a constant balancing act between utility and battery longevity, but it is a necessary one for any app that aims to be a daily driver for users.
Top comments (1)
주기적으로 위치를 묻는 방식 대신 진입·이탈 이벤트를 기준으로 잡은 선택이 맥락과 잘 맞네요. 장소 경계에서 여러 번 왕복하거나 사용자가 음량을 직접 바꾼 경우까지 상태 전이 예시로 보여주면, 자동 설정과 사용자의 마지막 선택 중 무엇을 우선할지 이해하기 좋겠습니다.