It happened during a medical appointment. I was sitting in the quiet waiting room, my thoughts occupied by the upcoming consultation, when my phone erupted with a loud, aggressive ringtone. The entire room turned to look at me, and I fumbled to silence it, accidentally hitting the volume up button instead of the mute toggle in my panic. I felt that specific, burning embarrassment that comes from being the person who disrupts a quiet space. I realized then that I had spent years writing code for others, yet I couldn't solve my own basic problem of managing my phone's profile.
We live in a world of constant notifications and persistent demands on our attention. The real friction isn't just that phones ring; it's that we are expected to remember to manually toggle settings in a dozen different contexts every single day. Whether it is a classroom, a house of worship, or a professional meeting, the human element of remembering to flip a switch is the point of failure. I wanted an app that handled this silently, without me having to open an interface or even think about the current state of my device. I needed a system that functioned as an extension of my environment rather than an additional task.
Building Muffle required me to confront the reality of modern Android background execution. Initially, I thought a simple BroadcastReceiver listening for time changes or geofence triggers would suffice. I was wrong. As soon as the phone entered Doze mode—the power-saving state introduced in Android 6.0—my triggers would either be delayed significantly or killed entirely by the system’s restrictive task scheduler. I had to architect a solution that could survive these aggressive optimizations while remaining battery-efficient.
The core of the application resides in a ForegroundService that maintains a persistent notification. While many developers avoid these because of the UI footprint, it is the only way to signal to the OS that your process is performing an essential, user-visible task. To handle the logic, I moved away from relying solely on AlarmManager for everything. Instead, I implemented a custom WorkManager chain for routine scheduling. WorkManager is the recommended way to handle deferrable background work, but for time-sensitive sound changes, I had to ensure the constraints were set to RequiredNetworkType.NOT_REQUIRED and RequiresBatteryNotLow to avoid unnecessary execution blocks.
kotlin
val routineRequest = OneTimeWorkRequestBuilder()
.setInitialDelay(timeUntilTrigger, TimeUnit.MILLISECONDS)
.setConstraints(Constraints.Builder()
.setRequiresDeviceIdle(false)
.build())
.build()
WorkManager.getInstance(context).enqueue(routineRequest)
When it comes to actually changing the audio state, I interfaced directly with the AudioManager class. The challenge here is the NotificationManager.INTERRUPTION_FILTER_ALL and related flags for Do Not Disturb mode. If you attempt to modify these settings without the correct Manifest.permission.ACCESS_NOTIFICATION_POLICY permission, the app crashes. Furthermore, I had to implement a priority system. If two routines overlap—say, a work meeting and a scheduled prayer time—the system needs to know which state to prioritize and, more importantly, how to revert back to the correct state once the first event concludes. This required a local SQLite database, managed via Room, to act as a stack. Every time a routine activates, it pushes the current state to the database, and when it finishes, it pops that state, ensuring the phone doesn't get stuck in a silent profile indefinitely.
What truly surprised me during development was the inconsistency of GPS geofencing across different device manufacturers. I assumed that using the Google Play Services GeofencingClient would provide a standard, reliable experience. However, I quickly discovered that manufacturers like Xiaomi and Oppo have aggressive proprietary battery managers that aggressively kill background location listeners despite what the Android documentation says about Google Play Services. I spent weeks debugging why my location-based triggers were failing specifically on these devices. The fix wasn't in the code; it was in the user education. I had to build a specific settings-check screen that guides users to whitelist the app in their device's "Auto-start" or "Battery Optimization" menus. No amount of clean architecture can overcome a manufacturer that forces a process kill.
Another realization was how much I underestimated the importance of the BootCompleted receiver. If a user restarts their phone, the entire state machine resets. If I didn't have a listener for ACTION_BOOT_COMPLETED that re-registered all active WorkManager tasks and restored the ForegroundService, the app would simply stop working until the user manually opened it again. That is a terrible user experience. I learned that for a background-focused app, persistence must be defensive. You have to assume the OS will kill your app at the worst possible moment, and your data structures must be ready to rebuild themselves from the local database instantly.
If I were starting over, I would put even more effort into the local database architecture. I initially treated the routines as independent objects, but they are actually part of a complex, temporal state machine. I would implement a tighter integration with DataStore for simple flags, reserving the SQLite database strictly for the history logs and complex routine relationships. I would also move away from trying to handle too many complex edge cases in the main thread of the service, instead pushing all calculation logic into a dedicated coroutine scope using Dispatchers.IO to ensure the UI remains responsive, even though it is a background service.
For any developer building a background-heavy Android app, my advice is to embrace the constraints rather than fight them. Do not try to bypass battery optimizations or force your service to run when the OS clearly wants it shut down. Instead, design your application to be "resumable." If your process is killed, can it reconstruct its state within 500 milliseconds of being launched? If the answer is no, you will face bugs that you cannot reproduce in an emulator.
Building Muffle taught me that the most impactful software is often the kind that works invisibly. It shouldn't require a daily interaction to be useful; it should just exist in the background, reliably handling the repetitive tasks of life. If you want to see how this architecture handles routine conflicts or how the foreground service manages state across reboots, you can find the current implementation details here: https://play.google.com/store/apps/details?id=com.muffle.app. Focus on the user's friction point, build for the most restrictive environment, and always keep your persistence layer clean. The best code is the code that the user never has to worry about because it simply works.
Top comments (0)