Why I Now Take Android Background Tasks Personally (And You Should Too)

I had a client call me two weeks ago about their location-based app that was draining phones like it had a personal vendetta against battery life. We spent an hour on the phone while they explained that users were getting maybe six hours before their devices died. That conversation stuck with me—not because it was unusual, but because I realized how often developers treat Android background work like it's someone else's problem. It's not. It's a fundamental design choice that either respects the platform or fights against it.

Reading through this geofencing project made me confront something I've been avoiding: I've shipped production code that assumes Android will just... cooperate. That the OS will keep my timers running, my services alive, my location tracking steady. Spoiler alert: it won't. Not on modern Android, and especially not on devices from manufacturers who treat battery life like it's a competitive sport. This isn't a criticism of Android—it's a reality check I needed.

The Core Problem: Automation That Doesn't Drain Everything

The premise here is elegant: you want your phone to automatically switch to silent mode when you enter a meeting, without constantly asking Google's servers where you are. No telemetry, no cloud dependency, just local logic. It sounds simple until you realize that the naive approach—running GPS constantly, checking your location every second—will turn your phone into a hand warmer within hours.

The real challenge isn't building geofencing. Google's GeofencingClient makes that part straightforward. The challenge is building geofencing that doesn't make the user curse your name every time they charge their device. That requires understanding Android's battery optimization mechanisms and working with them instead of against them.

The Hybrid Approach That Actually Works

The solution here uses what I'd call "smart dormancy." Instead of running a foreground service that's constantly listening to GPS, you register geofences and let Android's kernel wake your BroadcastReceiver only when a boundary transition happens. This is fundamentally different from polling-based approaches, and it's the difference between a useful app and one that gets uninstalled in frustration.

The code pattern is straightforward:

val geofencingRequest = GeofencingRequest.Builder().apply {
    addGeofences(geofenceList)
    setInitialTrigger(GeofencingRequest.INITIAL_TRIGGER_ENTER)
}.build()

val intent = PendingIntent.getBroadcast(
    context, 0, 
    Intent(context, GeofenceBroadcastReceiver::class.java),
    PendingIntent.FLAG_UPDATE_CURRENT or PendingIntent.FLAG_IMMUTABLE
)

geofencingClient.addGeofences(geofencingRequest, intent)

What's clever here is the PendingIntent receiver pattern. Your app only wakes up when the system detects a real boundary crossing, not on a schedule. Combined with a local Room database for state, you've decoupled the trigger from the action entirely. Your phone doesn't need to ask anyone if it should be silent—it already knows.

Where This Gets Real: The OS Will Kill Your Stuff

Here's the part that made me sit back in my chair: the OS will kill your geofences. Especially on aggressive battery managers. Huawei, Xiaomi, older Samsung builds—they've all got settings that silently murder background tasks after a few days of inactivity. The solution is a BOOT_COMPLETED receiver that re-registers everything from your local database, plus a PeriodicWorkRequest that ensures geofences stay alive.

This is the kind of thing that's invisible until it breaks in production. A user installs your app, it works perfectly for three days, then they don't open it and suddenly it stops working. You get one-star reviews. Meanwhile, some engineer on the device manufacturer's team set aggressive pruning thresholds you never knew existed.

My Take: GPS Isn't Everything

I agree with the core philosophy here—minimize wake-locks, work offline first, and assume the OS will be hostile. But I'd push back slightly on GPS as the primary geofencing mechanism for indoor spaces. GPS indoors is genuinely terrible. The hysteresis buffer (requiring sustained transitions for 30 seconds before firing) is a good patch, but it's solving the wrong problem at the wrong layer.

For this specific use case—meeting rooms, offices, prayer times—I'd be experimenting with Bluetooth LE beacons or WiFi fingerprinting from day one. GPS gets you rough geofencing (home, work, specific buildings). For "the user just entered this specific room," you need something better.

What Would You Do?

If you're building location-aware features, especially for offline or privacy-conscious users, have you considered how your solution behaves when the OS gets aggressive? Share your approach—I'm genuinely curious how others are handling this tension between accuracy and respecting the platform's constraints.

Source: This post was inspired by "Architecting a 100% Offline Geofencing Engine for Android" by Dev.to. Read the original article