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 and , 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 within the Google Play Services location APIs.
The decision to use this over raw updates was rooted in battery efficiency.
The 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 that fires every few seconds.
However, implementing this required a robust architecture.
I needed to ensure that my background worker, which I implemented as a to satisfy Android's background execution limits, could handle the 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 , I detached the trigger logic from the app process.
When the geofence boundary is crossed, the OS sends an intent to my , which then wakes up the to toggle the 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 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 t