Battery Optimization for Android Apps

The biggest battery consumers on a phone are the screen, the radios (cellular, Wi-Fi, GPS) and the CPU staying awake. Your app influences the last two directly: how often it wakes the device, uses the network, and requests location. Small design decisions add up to large differences.

How Android protects battery

Background work: let WorkManager decide when

val sync = PeriodicWorkRequestBuilder<SyncWorker>(12, TimeUnit.HOURS)
    .setConstraints(
        Constraints(
            requiredNetworkType = NetworkType.UNMETERED,   // Wi-Fi, avoids mobile data
            requiresBatteryNotLow = true,
            requiresCharging = false,
        )
    )
    .build()

WorkManager.getInstance(context).enqueueUniquePeriodicWork(
    "content-sync", ExistingPeriodicWorkPolicy.KEEP, sync,
)

WorkManager respects Doze and standby, batches work with other apps, and retries with backoff. Choose the longest period your feature tolerates. See Background Work with WorkManager.

Wake locks: avoid them

A partial wake lock keeps the CPU running with the screen off. Android vitals flags excessive wake lock usage. Most apps never need one directly: WorkManager holds wake locks for you while workers run. If you must use one, always set a timeout and release it in finally.

Location and sensors

val request = LocationRequest.Builder(Priority.PRIORITY_BALANCED_POWER_ACCURACY, 60_000L)
    .setMinUpdateIntervalMillis(30_000L)
    .setMinUpdateDistanceMeters(50f)          // skip updates for tiny movements
    .build()
// Start in onStart / LifecycleStartEffect, remove updates in onStop.

• Use the lowest accuracy your feature needs (city weather doesn't need GPS precision).
• Prefer the last known location or a single current-location request over continuous updates.
• Stop updates when the UI isn't visible, unless the user explicitly started a tracking session (then use a foreground service).

Network

• Batch and prefetch: fewer, larger requests let the radio sleep between them.
• Cache aggressively. See Caching Strategies.
• Replace polling with push (FCM) for updates.
• Keep WebSockets open only while the relevant screen is visible.

Foreground services

Foreground services are for ongoing, user-visible tasks (navigation, playback, workout tracking), and they require a notification and a declared type. Don't use them to keep the app alive for convenience. See Foreground Services.

Measuring battery impact

• Android Studio Power Profiler (on supported devices) shows estimated power use by component.
• Background Task Inspector shows WorkManager jobs, alarms and wake locks.
• Battery Historian / bugreports for detailed investigation.
• Android vitals for field data on wake locks and background usage.

Real examples

Common mistakes

• Using AlarmManager exact alarms for routine sync.
• Continuous GPS for features that need coarse location occasionally.
• Retrying failed network calls in tight loops.
• Asking users to disable battery optimisation for the app without a strong, policy-compliant reason.

Frequently asked questions

Conclusion

Battery-friendly apps defer and batch background work with WorkManager, avoid manual wake locks, request only the location accuracy and frequency they need, push instead of poll, and measure with the Power Profiler and Android vitals.

Next step: learn the tools in depth with Android Studio Profiler: A Practical Guide.