DEV Community: Alex Vukovic

Why Android Apps Drain Battery in the Background

Alex Vukovic — Sun, 30 Aug 2026 23:23:36 +0000

Your app isn't open. You're not using it. And somehow it's still one of the biggest battery drains on the phone.

That sounds contradictory, but "not open" only means the app doesn't have a visible activity. It says very little about what the app is doing.

The process might still exist. A worker could be syncing data. An alarm could wake the device. A foreground service might be tracking location. Push messages could trigger network requests. Or the app could be running a coroutine loop that checks a server every few minutes because somebody needed a quick solution six months ago.

The confusing part is that these cases look similar in Android's battery screen. They're not.

Some background work is legitimate. A navigation app needs location while guiding the user. A podcast app needs to finish a download. A messaging app needs to react to incoming messages.

The real problem starts when an app performs work more often, for longer, or with stricter timing than the feature actually requires.

"Running in the Background" Can Mean Several Things

An Android application doesn't have one simple open or closed state.

Its process may remain cached after the user leaves the app. That doesn't mean it's actively burning battery. A cached process can sit in memory without using meaningful CPU time, and Android may remove it later when the system needs memory.

Process lifetime is not an execution contract. A Timer, Handler, thread, or coroutine inside that process isn't guaranteed to keep running. If the process goes away, so does that work.

At the same time, Android provides mechanisms that can schedule or allow work without a visible activity:

WorkManager jobs
Scheduled alarms
Foreground services
Bound or started services
Broadcast handling
Firebase Cloud Messaging delivery
Location callbacks
Media playback
Bluetooth or connected-device communication

A service is also not automatically a background thread. By default, its callbacks run on the application's main thread. More importantly, creating a service doesn't exempt an app from background execution limits.

So when I investigate battery usage, I don't ask, "Was the app running?" I ask:

What work was performed?
What caused it to start?
How often did it wake the CPU?
How long did it run?
Did it use location or the network?
Did the user receive enough value to justify that cost?

Those questions usually point toward the actual bug.

Android Tries to Batch Work for a Reason

Android's power management is built around avoiding many small, scattered wakeups.

When a device enters Doze, the system restricts network access and defers regular jobs, syncs, and standard alarms. It periodically opens maintenance windows so apps can perform deferred work together. App Standby applies additional limits based on how recently and frequently the user interacts with an app.

Exact behavior depends on the Android version, device state, standby bucket, manufacturer, and whether the device is charging. Vendor-specific power management can add another layer.

This is why background code that appears reliable on a developer phone connected to USB may behave completely differently overnight on a real user's device.

It also explains why fighting the scheduler is usually the wrong fix. Requesting battery optimization exemptions, using exact alarms, or keeping a foreground service alive can make work run more often, but it transfers the cost directly to the user's battery.

Battery optimization exemptions should be reserved for cases where the core function genuinely can't work under normal power restrictions. They aren't a general reliability setting.

Polling Is Usually the First Suspect

A common implementation looks harmless:

scope.launch {
    while (isActive) {
        syncWithServer()
        delay(5.minutes)
    }
}

I've also seen the same design built with Timer, Handler.postDelayed(), RxJava intervals, or a sleeping thread.

This has two problems.

First, it's not durable. If the process dies, the loop disappears. If somebody puts it in a foreground service to prevent that, the app now keeps itself active indefinitely.

Second, the schedule ignores device conditions. It may run when there's no useful data, when the battery is low, or when a larger batch could have been sent later.

Frequent network requests are especially expensive. The request's CPU time may be short, but establishing connections, transferring headers, performing TLS work, parsing responses, and activating the cellular radio all add cost. Several tiny requests can be worse than one batched request.

For durable work that can run later, WorkManager is usually a better fit:

val constraints = Constraints.Builder()
    .setRequiredNetworkType(NetworkType.CONNECTED)
    .setRequiresBatteryNotLow(true)
    .build()

val syncRequest =
    PeriodicWorkRequestBuilder<AccountSyncWorker>(6, TimeUnit.HOURS)
        .setConstraints(constraints)
        .setBackoffCriteria(
            BackoffPolicy.EXPONENTIAL,
            30,
            TimeUnit.SECONDS
        )
        .build()

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

This is appropriate when the sync must eventually happen but doesn't need an exact execution time. WorkManager persists scheduled work, cooperates with system scheduling, supports constraints, and applies retry policies.

Periodic WorkManager requests have a minimum interval of 15 minutes, but that doesn't mean they'll run exactly every 15 minutes. Execution can be delayed and batched by the system. If a feature needs second-level timing, periodic work is the wrong abstraction.

Unique work also matters. Without it, opening the app repeatedly can accidentally enqueue several copies of the same sync.

Push Beats Polling When the Server Knows First

If the server already knows when data changes, repeatedly asking it for updates wastes power.

FCM can notify the app that new data is available. The app can then fetch only what it needs. This changes the pattern from hundreds of empty requests to a small number of meaningful requests.

Normal-priority FCM messages may be delayed during Doze. High-priority messages are intended for time-sensitive, user-visible events. They should not be used as a hidden heartbeat. Misusing high priority can lead to delivery being deprioritized, and it still doesn't justify long background execution.

A useful messaging pattern is:

The server sends a push indicating that data changed.
The app performs a small, bounded update.
Longer durable work is handed to WorkManager.
Duplicate updates are collapsed using IDs or timestamps.

If the message isn't time-sensitive, letting Android batch the work is usually fine.

Alarms Are Not a General Background Scheduler

AlarmManager makes sense when time itself is part of the product requirement, such as an alarm clock or a user-created reminder.

It isn't a good replacement for a custom polling loop.

Wakeup alarms can wake the CPU while the device is asleep. Exact alarms are particularly costly because they reduce the system's ability to batch work. Modern Android versions also restrict exact alarm access, and apps should request it only when precise timing is central to the feature.

For a periodic database cleanup, upload, or refresh, use WorkManager. For "notify me at 7:30 AM," an alarm may be appropriate.

The difference is user intent and timing precision, not which API is easiest to call.

Location Can Drain a Battery Fast

Background location has a very visible cost because it can involve GPS, Wi-Fi scanning, cellular positioning, sensors, and CPU processing.

The dangerous configuration is usually some combination of:

High accuracy
Short update intervals
No minimum displacement
Updates continuing after the feature ends
A foreground service that never stops
Uploading every location point immediately

A fitness tracker or active navigation session may justify frequent updates. A weather app usually doesn't.

For less urgent features, developers can lower accuracy, increase intervals, request batched updates, use geofencing, or refresh location only when the user opens the relevant screen. Location callbacks should be removed as soon as they're no longer needed.

Background location access is also restricted and policy-sensitive on modern Android. A permission grant doesn't mean continuous tracking is automatically a good design.

Wake Locks and CPU Wakeups

When the screen is off, the CPU can enter low-power states. A partial wake lock asks the system to keep the CPU running.

That can be valid during a short critical operation, but an unreleased wake lock is one of the fastest ways to produce obvious drain.

Wake locks should be narrowly scoped and have a timeout:

val wakeLock = powerManager.newWakeLock(
    PowerManager.PARTIAL_WAKE_LOCK,
    "${context.packageName}:upload"
)

wakeLock.acquire(2 * 60 * 1000L)

try {
    uploadPendingData()
} finally {
    if (wakeLock.isHeld) {
        wakeLock.release()
    }
}

Even this should prompt a design question. WorkManager and other system-managed components often handle the required wakefulness themselves. Adding another wake lock may be unnecessary.

Also, wake lock duration isn't the only useful metric. An app can cause serious drain through thousands of brief CPU wakeups. A five-second task once per hour may be fine. A 100-millisecond task every ten seconds may prevent the device from spending enough time asleep.

Count wakeups, not just total execution time.

Foreground Services Are for User-Visible Ongoing Work

A foreground service raises the process's importance and displays an ongoing notification. It makes sense for work the user actively expects to continue, including:

Turn-by-turn navigation
Media playback
An active workout
A user-started file transfer
Connected-device communication

It shouldn't exist only to keep a process alive or preserve a polling loop.

Modern Android versions restrict when an app can start a foreground service from the background. They also require appropriate foreground service types and, in some cases, related permissions. These rules have become stricter across releases.

Even when starting one is technically allowed, the service should have a clear lifecycle. Start it because the user began an ongoing operation. Stop it when that operation ends.

A permanent notification saying "App is running" is usually evidence that the service serves the implementation rather than the user.

How I Track Down Background Battery Usage

Android's Battery usage screen is a starting point, not a profiler. Its numbers are estimates attributed over a time window, and presentation varies across devices. A high background percentage tells me where to look, but not which line of code is responsible.

For controlled testing, I reset battery statistics first:

adb shell dumpsys batterystats --reset

Then I unplug the device, run one specific scenario, leave it idle, and collect a bug report:

adb bugreport battery-test.zip

The bug report and batterystats data can reveal wake locks, jobs, alarms, network activity, and periods when the device remained awake. Battery Historian can make long sessions easier to inspect. Android Studio's Power Profiler is useful for correlating device power behavior with app activity on supported devices.

I also inspect the scheduler rather than assuming my code ran when requested:

adb shell dumpsys jobscheduler
adb shell dumpsys alarm
adb shell dumpsys deviceidle

These outputs are noisy, so I search for the package name and compare timestamps with application logs.

To test Doze behavior, I use a physical device, turn off the screen, disconnect power, and force idle when appropriate:

adb shell dumpsys deviceidle force-idle

After the test:

adb shell dumpsys deviceidle unforce

Forced idle isn't a perfect simulation of hours of normal use, but it quickly exposes code that assumes unrestricted networking or exact scheduling.

Useful application metrics include:

Worker starts, finishes, retries, and cancellation reasons
Foreground service start and stop times
Network request counts and transferred bytes
Location request duration and configuration
Wake lock acquisition duration
Push delivery and processing timestamps
Sync triggers and the amount of useful data changed

Logging every five seconds can itself distort a test, so I keep instrumentation lightweight.

Normal Work Versus Real Drain

I don't classify an app as wasteful merely because it does something in the background.

A messaging app processing a few pushes is normal. A navigation app using location during an active trip is normal. A backup app uploading a large file after the user requested it may consume substantial battery, but the work has a clear purpose.

The suspicious cases look different:

A process is kept important without active user-facing work.
The CPU wakes frequently to discover there is nothing to do.
Network requests return unchanged data most of the time.
Location continues after the related feature ends.
Failed jobs retry aggressively without backoff.
A foreground service exists only to avoid process death.
Several schedulers trigger duplicate copies of the same task.

The best metric is often useful work per wakeup. If most wakeups produce no visible state change, no new data, and no completed user request, the schedule is probably too aggressive.

Test the Design, Not Just the Code

Battery testing needs a real device. Emulators are useful for behavior and API testing, but they don't reproduce real radios, thermal conditions, standby behavior, or manufacturer power policies.

I test a release-like build under several conditions:

Screen on and screen off
Wi-Fi and cellular data
Good and poor connectivity
Doze and App Standby
Low battery
Server failures and repeated retries
App opened frequently and left unused overnight
Reboot followed by pending scheduled work

I compare against a baseline with the feature disabled. Battery percentage alone is too coarse for short tests, so I also inspect wakeups, wake lock time, job frequency, network transfers, and foreground service duration.

The fixes are usually straightforward once the trigger is visible: replace polling with push, batch writes, add constraints, use exponential backoff, deduplicate work, lower location accuracy, stop services promptly, and remove wake locks that the platform scheduler already handles.

Android isn't randomly killing apps, and background battery drain isn't caused by one API. The system manages processes and limits execution according to device state, app state, OS version, and manufacturer policy.

Our job is to describe background work honestly. If it can wait, schedule it as deferrable work. If the server knows when something changes, use push. If timing must be exact, make sure the user actually asked for that precision. If work must remain active and visible, use a foreground service with a real stop condition.

And if a five-minute loop feels like the easiest solution, that's usually the moment to step back and rethink the design.

Official Android References

Why Your Android App Stops Working After You Lock the Phone

Alex Vukovic — Sun, 30 Aug 2026 23:03:50 +0000

The app works perfectly while you're looking at it. Data keeps syncing, timers fire, network requests finish, and notifications show up right on time.

Then you lock the phone.

A few minutes later, the sync hasn't happened. A background task appears stuck. Maybe the expected notification never arrives. You turn the screen back on, and suddenly everything wakes up and starts working again.

I've learned not to treat this as one specific Android bug. Locking the screen can expose several different problems that look almost identical from the outside. It could be Doze, background execution limits, a stopped service, an unreliable in-process timer, an OEM battery setting, or simply an incorrect assumption about how long an app process gets to stay active.

The phone usually isn't just "killing the app." What's happening is more specific, and figuring out which restriction you're hitting is the useful part.

Open doesn't mean allowed to run forever

When an app's activity is visible, Android treats it as something the user is actively using. The process has a high priority, network access is generally available, and code started by the UI often keeps running without obvious trouble.

That can create a misleading test environment.

Suppose I start a coroutine, executor task, timer, or regular background service from an activity. While the app is open, it may work every time. But none of those things automatically becomes durable background work just because it was launched successfully.

Once the screen is locked, the activity usually moves through onPause() and onStop(). The process may continue running, but the app is no longer in the foreground from Android's point of view.

That distinction matters:

An app process can still exist without having permission to do unrestricted background work.
An activity being stopped does not guarantee that the process will be terminated.
A process remaining alive does not guarantee that its timers, network access, jobs, or services can run whenever they want.
Work stored only in memory disappears if Android later removes the process.

This is why onStop() should never be treated as a signal that the app has a few more hours to finish something. Android lifecycle callbacks describe component state. They aren't a background execution contract.

What actually changes when the screen turns off

Locking the screen doesn't immediately flip one giant "stop all apps" switch.

Several things can happen, sometimes right away and sometimes after the device has been idle for a while.

First, the activity is no longer visible. If the app has no foreground component, its process importance drops. Android now has more freedom to reclaim that process if the system needs memory.

Second, the CPU may suspend when nothing is holding an appropriate wake lock. A Java or Kotlin timer doesn't keep the hardware awake by itself. If the CPU sleeps, the timer isn't getting regular execution time.

Third, background execution rules start to matter. Depending on the Android version and app state, Android may limit background services, defer jobs, batch alarms, or restrict network access.

After the device remains unused, Doze can apply. App Standby and standby buckets may also affect apps that the user hasn't interacted with recently.

These mechanisms overlap, but they aren't the same thing.

Background execution limits are often the first problem

Android 8.0 introduced major limits on what apps can do with background services. When an app moves to the background, it usually gets a short window in which existing background services can continue. After that window, Android stops those services as if the app had called stopSelf().

That means an old pattern like this is not a reliable way to run indefinitely:

startService(Intent(this, SyncService::class.java))

It might work while the activity is visible. It might continue briefly after the screen is locked. Then it stops.

On newer Android versions, trying to start a normal background service while the app is already in the background can also throw an IllegalStateException.

This still doesn't mean Android has necessarily terminated the entire process. The system may only be restricting or stopping the background service. Other parts of the process might remain around for some time.

That's one reason this bug can feel inconsistent. The process can appear alive in one log while the work you expected is no longer allowed to continue.

Doze is delayed, but it changes a lot

Doze is Android's idle power-saving state. It doesn't usually begin the instant the screen turns off. The device needs to meet idle conditions, and the timing varies by Android version and system behavior.

Once the device enters Doze, Android starts deferring a number of things:

Regular network access is suspended.
Standard alarms are deferred.
Jobs and WorkManager work may be postponed.
Wake locks are ignored.
Background CPU activity is heavily limited.

The device periodically enters maintenance windows where deferred work gets a chance to run. If the phone stays idle, those windows can become less frequent.

This explains a common pattern: the app works for a little while after the phone is locked, then stops making progress, then catches up later.

Doze isn't supposed to block everything forever. It's designed to batch background work so the phone doesn't keep waking up for every app that wants to poll a server or run a timer.

An app being exempt from battery optimization changes some Doze behavior, but asking users for that exemption shouldn't be the default fix. Google Play policy and Android guidance reserve broad exemptions for cases where the app's core function truly can't work under normal power management.

Most apps should adapt their scheduling instead.

App Standby is related, but not triggered by one screen lock

App Standby deals more with apps the user hasn't actively used for a while. Android can defer their network access and background jobs because the system considers them inactive.

Newer Android versions also place apps into standby buckets such as active, working set, frequent, rare, and restricted. The bucket affects how often an app can run jobs, receive alarms, and use background resources.

The exact bucket behavior has changed across Android releases, so I don't build logic around a fixed promise such as "rare apps get exactly this many minutes." The useful point is that Android gives recently used apps more freedom than apps that haven't been opened in a long time.

One screen lock normally isn't enough to make App Standby the immediate cause. But it can explain why the issue only happens after the app hasn't been used for hours or days.

Battery optimization and user restrictions add another layer

Users can usually choose a battery mode for an app. The labels vary by Android version and phone manufacturer, but common choices include unrestricted, optimized, and restricted.

"Optimized" is generally the normal state. It allows Android's standard battery management to apply.

"Restricted" can be much harsher. Background jobs, alarms, services, and other behavior may be limited enough that the app doesn't behave as expected. Android also warns that restricted apps may not work correctly in the background.

There's also the system's general background activity restriction. This is separate from Android's rules about starting an Activity from the background, though the names are easy to confuse.

Background activity launch restrictions control when an app can suddenly place UI on the screen. Starting with Android 10, apps generally can't launch activities from the background unless they meet a documented exception. A notification is usually the correct way to ask the user to open something.

None of these settings is perfectly consistent across manufacturers. Some vendors add their own auto-start controls, sleeping app lists, power modes, or process management policies. An app can behave correctly on one phone and get delayed aggressively on another, even when both report the same Android version.

I still design around Android's documented APIs first. Manufacturer-specific instructions are a fallback for confirmed device-specific behavior, not the foundation of the app.

A foreground service is not a hidden keep-alive trick

A foreground service is meant for work the user can actively notice. Navigation, workout tracking, media playback, and an ongoing file transfer are typical examples.

It must show an ongoing notification and declare an appropriate foreground service type. Recent Android releases also require corresponding permissions for certain service types.

A basic start looks like this:

val intent = Intent(context, TrackingService::class.java)
ContextCompat.startForegroundService(context, intent)

The service then needs to promote itself to the foreground promptly:

override fun onStartCommand(
    intent: Intent?,
    flags: Int,
    startId: Int
): Int {
    startForeground(
        TRACKING_NOTIFICATION_ID,
        createTrackingNotification()
    )

    return START_NOT_STICKY
}

This gives the service a higher-priority execution state. It doesn't make the app immune to every system rule, and it doesn't automatically keep the CPU awake. If the work genuinely requires the CPU while the screen is off, wake-lock handling may still be relevant. That needs to be narrowly scoped because an incorrectly held wake lock can wreck battery life.

There are also restrictions on starting foreground services.

Since Android 12, apps generally can't start a foreground service while already in the background unless one of the documented exceptions applies. Newer Android versions enforce service types, related permissions, and additional time limits for some types. For example, Android 15 introduced time limits for dataSync and mediaProcessing foreground services when an app targets that version.

So the answer isn't "convert every service into a foreground service." If the user can't reasonably tell why the app is running right now, a foreground service is probably the wrong model.

WorkManager is usually right for deferred, durable work

For background work that must eventually happen, WorkManager is usually where I start.

Examples include:

Uploading locally saved data
Syncing when a network connection is available
Retrying a failed API request
Processing data after a push message
Performing periodic maintenance

A one-time request can declare what it needs:

val constraints = Constraints.Builder()
    .setRequiredNetworkType(NetworkType.CONNECTED)
    .build()

val syncRequest = OneTimeWorkRequestBuilder<SyncWorker>()
    .setConstraints(constraints)
    .setBackoffCriteria(
        BackoffPolicy.EXPONENTIAL,
        30,
        TimeUnit.SECONDS
    )
    .build()

WorkManager.getInstance(context).enqueueUniqueWork(
    "account-sync",
    ExistingWorkPolicy.KEEP,
    syncRequest
)

WorkManager stores the request and coordinates with Android's scheduling APIs. If the process disappears, the request isn't just lost with an in-memory coroutine.

The tradeoff is timing. WorkManager guarantees that eligible work will be scheduled, not that it will start at an exact second. Doze, constraints, quotas, standby buckets, and system load can all delay it.

Periodic work is also intentionally inexact, with a minimum repeat interval of 15 minutes. It isn't appropriate for a timer that must fire every minute.

Expedited work can request faster execution, but it has quotas and should be used for genuinely time-sensitive tasks. It isn't an unlimited express lane.

Long-running WorkManager tasks can run with foreground service support, but that still brings foreground service rules into the picture. WorkManager doesn't erase platform restrictions.

Push is better than polling for server-driven events

If the app needs to react when something changes on a server, keeping a process alive and polling every few minutes is usually the wrong design.

Firebase Cloud Messaging gives the server a way to notify the device that something happened.

There are two broad message patterns:

Notification messages can be displayed by the FCM SDK when the app is in the background.
Data messages are delivered to app code through FirebaseMessagingService.

That difference matters. If a notification message works while the screen is off but a data message doesn't complete its processing, the issue may be what the app is doing inside onMessageReceived().

That callback is intended for short work. If the app needs to download files, update a large database, or perform something retryable, it should hand the task to WorkManager.

override fun onMessageReceived(message: RemoteMessage) {
    val request = OneTimeWorkRequestBuilder<MessageSyncWorker>()
        .setInputData(
            workDataOf("messageId" to message.messageId)
        )
        .build()

    WorkManager.getInstance(applicationContext)
        .enqueue(request)
}

FCM priority also matters.

Normal-priority messages can be delayed during Doze. High-priority messages are meant for urgent, user-visible events and can temporarily wake the device. If high priority is repeatedly used for messages that don't produce user-visible results, FCM may deprioritize later messages.

FCM delivery also isn't a precision clock. Messages can be delayed, collapsed, or expire based on their configuration and device connectivity.

If FCM says the message arrived but no notification appears, I check a different set of problems:

Does the app have notification permission on Android 13 or later?
Is the notification channel disabled?
Is the channel importance too low?
Did the app actually create the notification?
Was the message a notification payload or a data-only payload?
Was the app force-stopped?

A force-stopped package is a special case. Android keeps it in a stopped state until the user launches it again or otherwise interacts with it. That can block scheduled work and message delivery. Swiping an app out of the recent apps screen is not normally the same thing as force-stopping it, although manufacturer behavior can complicate the result.

Why in-process timers fail so easily

A lot of screen-lock bugs come from code that assumes the process will keep running.

Examples include:

Handler.postDelayed()
Timer
ScheduledExecutorService
A coroutine with delay()
A loop that sleeps between network requests
An RxJava interval
A JavaScript timer inside a WebView or cross-platform runtime

These tools are fine while the process is alive and getting CPU time. They aren't persistent schedulers.

If Android removes the process, the timer is gone. If the CPU suspends, it doesn't keep ticking normally. If Doze blocks network access, the callback might run later but still be unable to complete its request.

For a short UI-related delay, an in-process timer is fine. For work that must survive the app leaving the screen, I use a platform-backed mechanism.

If exact user-facing timing is genuinely required, an alarm may be appropriate. Exact alarms have their own permission and policy restrictions on modern Android, so they shouldn't be used as a general replacement for background scheduling.

How I diagnose the actual restriction

I try not to guess from the symptom alone. "It stops after the screen locks" isn't enough to identify the mechanism.

First, I log the boundaries of the work:

Log.d(TAG, "Sync requested")
Log.d(TAG, "Worker started")
Log.d(TAG, "Network request started")
Log.d(TAG, "Network request completed")
Log.d(TAG, "Worker finished")

I also log:

Activity lifecycle transitions
Service creation and destruction
onStartCommand() calls
WorkManager attempt counts
FCM receipt times and message IDs
Network failures and timeout causes
Notification creation
Whether the process was started fresh

That tells me whether the work wasn't scheduled, was scheduled but delayed, started and failed, or completed without producing the expected UI.

Then I inspect system state with ADB.

To see Doze and device idle state:

adb shell dumpsys deviceidle

To force the device into idle mode for a controlled test:

adb shell dumpsys battery unplug
adb shell dumpsys deviceidle force-idle

To leave forced idle mode and restore battery reporting:

adb shell dumpsys deviceidle unforce
adb shell dumpsys battery reset

The battery unplug command makes Android treat the device as unplugged, which matters because a USB-connected test phone may otherwise behave like a charging device.

To simulate an inactive app:

adb shell am set-inactive com.example.app true
adb shell am get-inactive com.example.app

On versions that support standby bucket commands, I can also test a restrictive bucket:

adb shell am set-standby-bucket com.example.app rare
adb shell am get-standby-bucket com.example.app

To inspect scheduled jobs:

adb shell dumpsys jobscheduler

To inspect running services:

adb shell dumpsys activity services com.example.app

For alarms:

adb shell dumpsys alarm

And for the full story, I keep Logcat running while the screen is off:

adb logcat

Filtering for the package, ActivityManager, JobScheduler, WorkManager, and Firebase Messaging usually makes the output manageable.

ADB commands and output can vary between Android versions. I treat them as test tools, not behavior that production code should depend on.

Testing with the phone actually locked

A quick screen-off test isn't enough. I test several distinct states because they exercise different paths:

App visible with the screen on
App backgrounded with the screen on
Screen locked for a short time
Device forced into Doze
App placed in a restrictive standby bucket
Device disconnected from power
Network disconnected and restored
Process removed without force-stopping the package
App explicitly force-stopped
Device rebooted before scheduled work runs

I also test more than one Android version. Android 8's background service limits, Android 10's activity launch restrictions, Android 12's foreground service start restrictions, Android 13's notification permission, and newer foreground service requirements can all change what fails.

At least one physical device is useful too. Emulators are great for forced-state testing, but they don't reproduce every manufacturer battery policy.

For delayed work, I don't stare at the UI and assume nothing happened. I collect timestamps from the app and server, then compare when the work was requested, when Android started it, and when the request reached the backend.

That separates a scheduling delay from a notification bug or failed API call.

Picking the mechanism that matches the job

The choice gets easier when I stop asking, "How do I keep my app running?" and ask, "What kind of work is this?"

For durable work that can run later, I use WorkManager.

For continuous, user-visible work that needs to happen now, I use a foreground service with the correct service type and notification.

For server-driven events, I use FCM, then hand longer processing to WorkManager when needed.

For an exact, user-facing event such as an alarm clock, I evaluate the exact alarm APIs and their current permission rules.

For ordinary UI work, I keep it tied to the activity or screen lifecycle and accept that it stops when the UI goes away.

What I don't do is rely on a loop, timer, coroutine, or plain background service to keep an Android app alive forever. It may survive a basic test with the screen on, but that test proves almost nothing about Android background execution.

The practical fix is usually not to fight every battery restriction. It's to make the work durable, schedulable, and honest about how urgent it really is.

Official references

Why Your Android Phone Isn't Showing Notifications Even With Good Internet (Adaptive Battery Is Probably The Culprit)

Alex Vukovic — Sun, 30 Aug 2026 22:22:05 +0000

I almost missed a really important call last month because my phone just... didn't buzz. No notification, nothing. My WiFi was working, my mobile data was fine, and I later found out even the Google push connection was working perfectly. So what was going on?

Turns out the villain here wasn't my internet. It was a setting sitting quietly on my phone the entire time, doing exactly what Google designed it to do: aggressively killing apps to save battery life. That setting is called Adaptive Battery, and if you're on Android 17, it's probably wrecking your notifications too.

The Notifications Are Getting There, Your Phone Just Won't Let Them Through

Here's the thing that took me a while to understand. When people say "I'm not getting notifications," they usually blame their WiFi, their carrier, or the app itself being broken. But in a ton of cases, none of that is the real problem.

The push notification actually arrives at your phone through Google's FCM servers (that's Firebase Cloud Messaging, the system almost every app uses to send you notifications). The connection is solid. The message shows up. And then Android just decides your app doesn't deserve to wake up and show it to you.

That's Adaptive Battery in action. It's a system that learns your usage patterns and decides which apps are "important" enough to run in the background. If it decides an app is low priority, it straight up kills it, or restricts it so hard that even an incoming push notification can't wake it up properly.

Apps I've Personally Seen This Happen With

This isn't some rare edge case. I've seen this mess with notifications on:

WhatsApp
Signal
Telegram
Gmail (yes, even Google's own app sometimes)
Messenger
Slack
Discord

Basically any app that relies on staying alive in the background to instantly show you a notification can get hit by this. And the annoying part is it's inconsistent. Sometimes you get the notification fine, other times it just vanishes into nothing, especially if the app hasn't been opened in a while or your battery optimization decided to "help" you.

The Pixel Paradox Nobody Talks About

Here's what really gets me. Android 17 is still pretty fresh, and right now it's mostly Pixel owners dealing with this since Pixels get the update first. So the people running into this notification nightmare are, ironically, the same people using Google's own phones with Google's own operating system.

You'd think if anyone's notifications would work flawlessly it would be on a Pixel, running stock Android, straight from the source. But nope. The most aggressive battery management is hitting the exact users who should have the smoothest experience. Kind of a wild contradiction if you think about it.

What Adaptive Battery Actually Is

Just to clear this up, Adaptive Battery is a feature Android uses to extend your battery life by limiting background activity for apps it thinks you don't use often, or that it decides shouldn't be running constantly. It sounds great on paper. Save battery, sounds like a win. Except it doesn't always accurately judge which apps you actually need alerts from in real time, and messaging apps get caught in the crossfire constantly.

How To Turn Off Adaptive Battery

If you're tired of missing texts, calls, and important alerts, here's how to shut this thing off:

Open the Settings app on your phone.

Tap on Battery.

Choose Battery Saver or look for Adaptive Preferences.

Tap on Adaptive Battery and toggle the switch to the Off position.

That's it. Takes about ten seconds and it might save you from missing something important down the line.

What You Actually Give Up By Turning It Off

I'll be honest with you, turning this off does mean your battery life probably takes a small hit. Your apps will run more freely in the background, which uses more power throughout the day. If you're someone who's already squeezing every bit of battery life out of your phone, you'll notice the difference.

But here's how I look at it. I'd rather charge my phone a little more often than miss a call from my mom, a message from my kid's school, or something urgent from work because my phone decided an app wasn't "important enough" to stay awake. For me, that trade-off is a no brainer. Battery percentage means nothing if the notification that actually mattered never made it to my screen.

One Last Thing

I want to be upfront that adaptive battery isn't the only reason notifications go missing on Android. Sometimes it's app specific battery restrictions, sometimes it's Do Not Disturb settings, sometimes it's just a buggy app update. But in my experience, and from what I've seen a lot of other people running into, adaptive battery is one of the most common and most overlooked causes, especially right now with Android 17 rolling out on Pixel devices.

If your notifications have been randomly disappearing and you've already ruled out your internet connection, give this a try. Hopefully it saves you the same headache it caused me.

Author’s website