Stop Fighting Android's Battery Management—It's Smarter Than Your App

I was debugging a location-based feature last year when I realized something that should have been obvious: I was asking the operating system to do something it actively didn't want to do. My app was hammering the GPS radio every few minutes, the battery was draining like someone left the tap running, and I was staring at crash logs wondering why the system kept killing my process. The worst part? I was following the documentation. It took reading about someone else's journey through the same mess to understand that the problem wasn't my implementation—it was my fundamental approach to the platform.

This is the core tension of modern Android development: the OS is designed to be stingy with resources, and we keep writing code that assumes abundance. I've spent enough time in production systems to know that fighting the platform is a losing game. So when I came across an article about architecting reliable geofencing without destroying battery life, I recognized myself in every debugging frustration the author described.

The GPS Polling Trap

Here's what I used to do: set up a LocationManager, request updates every few minutes, and hope that was frequent enough. It wasn't. Battery would die by dinner time, and I'd get reviews complaining about drain. The real problem is that GPS is expensive—it's not just the radio, it's the whole power profile shifting whenever location updates start flowing.

The article introduces GeofencingClient from Google Play Services, and honestly, this is the move I should have made three years ago. Instead of polling, you define geofences at the system level and let the OS handle the checking. The system batches these operations, uses lower-power location methods when possible, and only wakes your app when the user actually crosses a boundary. This is what "working with the platform" actually means.

The Reliability Problem Nobody Talks About

But here's where it gets interesting: just using GeofencingClient doesn't guarantee your app will actually do what you want when the boundary crossing happens. If your app gets killed (and it will get killed on modern Android), your PendingIntent might not execute. The author handled this by implementing a BroadcastReceiver that transitions the audio state through a JobIntentService, which is much harder to kill than a regular service.

I've learned this lesson in production too. The number of times I've assumed something would work "because the documentation says so" is embarrassing. Modern Android is genuinely adversarial toward background processes. You have to design for that reality.

Where I Disagree (Slightly)

The article mentions relying solely on GeofencingClient for precision work, and the author would add a secondary verification layer using network-based location. I agree completely, but I'd push further: I'd probably avoid the audio/DND problem entirely by building this as a settings integration or using the NotificationListener approach instead of fighting AudioManager. That said, the author's experience with NotificationManager being the real culprit is valuable—I probably would have spent days trying to fix AudioManager too.

The reboot persistence issue is something I hadn't fully considered. Re-registering geofences after a boot completion event is absolutely necessary, and I appreciate that being called out explicitly.

What This Actually Teaches Us

The real lesson isn't about geofencing specifically. It's about this: every time you want a background task to "just keep running," you're betting against the OS. The OS will win. The OS always wins. The winning strategy is to design your app so it can sleep completely and be woken by system intents exactly when needed.

Here's a rough template for doing this right:

// Define your geofence
val geofence = Geofence.Builder()
    .setRequestId("prayer_room")
    .setCircularRegion(latitude, longitude, 100f) // 100m radius
    .setLoiteringDelay(10000) // Wait 10s before triggering to avoid flicker
    .setTransitionTypes(Geofence.GEOFENCE_TRANSITION_ENTER or Geofence.GEOFENCE_TRANSITION_EXIT)
    .build()

// Add it and let the OS handle the rest
val request = GeofencingRequest.Builder()
    .setInitialTrigger(GeofencingRequest.INITIAL_TRIGGER_ENTER)
    .addGeofence(geofence)
    .build()

geofencingClient.addGeofences(request, geofencePendingIntent)

The PendingIntent should point to a BroadcastReceiver that handles the actual state change. That's it. Don't try to keep anything running.

The Real Question

Here's what I'm still wrestling with: as Android's battery management gets more aggressive (and it will), how do we build location-aware features that actually work across the crazy variety of devices out there? The author hit on manufacturer inconsistencies—my experience confirms that's real. A Pixel and a Samsung OneUI device behave completely differently, even though they're both running Android.

If you're building location features for Android, test on actual hardware early. Don't wait until launch week to discover that some manufacturer's battery optimization kills your geofences.

Source: This post was inspired by "Architecting reliable geofencing in Android without burning battery" by Dev.to. Read the original article