How to Test Mobile App Performance in Battery Saver Mode

Your app will spend a real share of its life on phones with Battery Saver or Low Power Mode switched on, yet most test plans never check it. People turn these modes on when the battery runs low, on long trips, at festivals, during the commute, or simply out of habit. Many Android devices prompt users to turn on Battery Saver at 15% or 20% charge, and iOS offers Low Power Mode at 20%, so a large slice of your users reach this state every single day.

The catch is that battery saver mode does far more than dim the screen. It throttles the CPU, defers background work, limits network access, pauses sync and changes how the operating system treats your app once it leaves the foreground. An app that runs perfectly on a fully charged test device can miss notifications, lose location tracks, stall halfway through uploads or crash on resume as soon as those limits kick in.

This guide walks you through how to test mobile app performance in battery saver mode on Android and iOS, step by step. You will learn what each platform actually restricts, which metrics to capture, how to trigger power saving states on demand with adb and device settings, which scenarios to cover, how to automate the checks in CI, and how to fix the problems you are most likely to find.

What battery saver mode actually changes on Android and iOS

Battery saver is not a single feature. It is a bundle of OS restrictions, and Android and iOS bundle them differently. Once you know exactly what gets restricted, you know what to test.

Android: Battery Saver plus several related power states

On Android, what users think of as “battery saver” behavior actually comes from four mechanisms that often overlap:

• Battery Saver (power save mode). Triggered by the user or by a schedule. It typically restricts background activity for apps that are not in the foreground, defers jobs and alarms, can limit or disable background location, and reduces visual effects. On Android 10 and later it can also switch the device to dark theme. Apps can read the state through PowerManager.isPowerSaveMode() and listen for the ACTION_POWER_SAVE_MODE_CHANGED broadcast.
• Doze. Kicks in when the device is stationary, unplugged and has its screen off. Network access is suspended, wake locks are ignored, and jobs, syncs and standard alarms are batched into short maintenance windows that grow further apart the longer the device sits idle.
• App Standby Buckets (Android 9 and later). The system ranks each app as active, working set, frequent, rare or restricted (restricted arrived in Android 12) based on how recently and how often it is used. Apps in lower buckets get fewer jobs, fewer alarms and a smaller quota of high priority FCM messages.
• Background restrictions and Adaptive Battery. Users can restrict a specific app’s background usage by hand, and Adaptive Battery learns usage patterns to push rarely used apps into stricter buckets automatically.

OEM skins add another layer on top. Samsung’s Power Saving and Maximum Power Saving modes, along with the battery managers on Xiaomi, OPPO, vivo, Huawei and OnePlus devices, are often far more aggressive than stock Android and may kill background services outright. Behavior that looks fine on a Pixel can fail completely on these devices, which is why testing on a single Pixel is never enough.

iOS: Low Power Mode

iOS Low Power Mode is simpler from a tester’s point of view: one switch and one set of system wide limits. When it is on, iOS typically:

• Pauses or reduces Background App Refresh, automatic downloads and mail fetch
• Pauses iCloud Photos sync and reduces some visual effects and animations
• Caps ProMotion displays at 60 Hz and shortens Auto Lock to 30 seconds
• Limits 5G use on supported iPhones, with exceptions for some streaming
• Reduces CPU and GPU performance to save power

Apps can check ProcessInfo.processInfo.isLowPowerModeEnabled and observe the NSProcessInfoPowerStateDidChange notification. Low Power Mode also switches itself off once the battery charges past roughly 80%, which matters a lot if your test devices sit on chargers between runs.

Android Battery Saver vs iOS Low Power Mode at a glance

Why battery saver testing matters

Battery saver bugs reach users at the worst possible moment: when their phone is nearly dead and they need the app to simply work. That timing makes these bugs far more damaging to trust, ratings and retention than their frequency would suggest.

• Silent functional failures. Missed push notifications, stale feeds, failed background uploads and broken location tracking rarely crash the app. They slip past crash dashboards entirely and only surface later as one star reviews and support tickets.
• Performance regressions under throttling. With a slower CPU and a 60 Hz cap, heavy screens start to stutter, cold starts take longer, and timeouts that never fire on a flagship at full charge suddenly do.
• State and lifecycle bugs. Aggressive process killing exposes weak state restoration. Software Mansion found that a React Native boating app got stuck in a restart loop when it moved from Android’s headless background mode back to the UI. Fixing that task handling logic lifted the crash free rate from 95% to roughly 98.5 to 99% (Software Mansion).
• Your app may be the reason users turn battery saver on. The same case study traced heavy drain not to GPS accuracy but to how often location was polled, plus repeated rendering of screens the user could not even see. Stopping that off screen rendering cut CPU usage from 170% to 30% on an iPhone 13.
• Store and platform penalties. Google Play’s Android vitals flags excessive wake locks and background wakeups, and battery complaints in reviews on both stores hurt ranking and install conversion.

In short, testing in battery saver mode protects two things at once. It confirms that your app degrades gracefully when the OS restricts it, and it confirms that your app is not the one draining the battery in the first place.

Key performance metrics to measure in battery saver mode

Measure every metric twice: once in normal mode and once in battery saver mode, on the same device and the same build. The difference between the two runs is the real test result, not the absolute numbers on their own. If you are still choosing tooling, our guide on which tool is best for mobile performance testing compares the main options.

Set your thresholds as a change from the normal mode baseline rather than as fixed numbers. A cold start that is 25% slower in battery saver mode may be perfectly acceptable. A cold start that is 300% slower, or a sync that never completes at all, is a bug worth filing. Agree on these thresholds with product owners up front so that a failed check leads to a clear decision instead of a debate.

Setting up the test environment

Battery saver testing has to happen on real devices. Emulators and simulators do not reproduce real CPU throttling, thermal behavior, radio power states or OEM battery managers, and the iOS Simulator does not support Low Power Mode at all. For a wider view, see which features can only be tested accurately on real devices.

Build a representative device matrix

• Android: at least one stock device (a Pixel), one Samsung, and one device from an OEM with aggressive battery management (Xiaomi, OPPO, OnePlus, vivo or Huawei), across your top two or three Android versions.
• iOS: one current iPhone with a ProMotion display and one older model at the bottom of your support range, on the latest and the previous iOS versions.
• Device tiers: include at least one entry level or midrange Android phone. Throttling hurts most on hardware that has little performance headroom to begin with.
• Prioritize by analytics: weight the matrix by the devices your real users carry, not by whatever happens to be on the lab shelf.

Turn on Battery Saver on Android

Manually: go to Settings > Battery > Battery Saver (the wording varies by OEM), or use the Battery Saver tile in quick settings.

With adb, so tests are repeatable: Battery Saver will not stay on while the device reports that it is charging, so simulate unplugging first.

# Pretend the device is unplugged and at low charge
adb shell dumpsys battery unplug
adb shell dumpsys battery set level 15

# Turn Battery Saver on / off
adb shell settings put global low_power 1
adb shell settings put global low_power 0

# Verify state
adb shell settings get global low_power
adb shell dumpsys power | grep -i "mLowPowerModeEnabled\|mBatterySaverEnabled"

# Restore real battery reporting when done
adb shell dumpsys battery reset

# Pretend the device is unplugged and at low charge
adb shell dumpsys battery unplug
adb shell dumpsys battery set level 15

# Turn Battery Saver on / off
adb shell settings put global low_power 1
adb shell settings put global low_power 0

# Verify state
adb shell settings get global low_power
adb shell dumpsys power | grep -i "mLowPowerModeEnabled\|mBatterySaverEnabled"

# Restore real battery reporting when done
adb shell dumpsys battery reset

Trigger the related power states as well, since real users hit them constantly:

# Force Doze (deep idle); screen should be off
adb shell dumpsys deviceidle force-idle
adb shell dumpsys deviceidle unforce

# Put your app into App Standby / a specific bucket (Android 9+)
adb shell am set-inactive com.your.app true
adb shell am set-standby-bucket com.your.app rare      # active | working_set | frequent | rare | restricted
adb shell am get-standby-bucket com.your.app

# Reset battery stats before a measurement run
adb shell dumpsys batterystats --reset

# Force Doze (deep idle); screen should be off
adb shell dumpsys deviceidle force-idle
adb shell dumpsys deviceidle unforce

# Put your app into App Standby / a specific bucket (Android 9+)
adb shell am set-inactive com.your.app true
adb shell am set-standby-bucket com.your.app rare      # active | working_set | frequent | rare | restricted
adb shell am get-standby-bucket com.your.app

# Reset battery stats before a measurement run
adb shell dumpsys batterystats --reset

OEM modes such as Samsung Maximum Power Saving or Xiaomi’s battery saver usually have no reliable adb switch. Turn them on manually in Settings and record exactly which mode and which options were used, so the run can be reproduced later.

Turn on Low Power Mode on iOS

Manually: go to Settings > Battery > Low Power Mode, or add the Low Power Mode control to Control Center. There is no public API or XCUITest call to toggle it from inside a test, so plan for one of these approaches:

• Toggle it manually, or through your device cloud’s device settings controls, before the session starts.
• Set up a Shortcuts personal automation on dedicated test devices, for example one that turns Low Power Mode on whenever a specific app opens.
• Keep two separate device pools, one with Low Power Mode on and one with it off, and route tests to the right pool.

Remember that Low Power Mode turns itself off once the battery charges past about 80%, so devices kept on chargers can quietly drop out of the mode partway through a run. Have each test check the state at the start (through isLowPowerModeEnabled, exposed on a debug screen or in a log) rather than assuming it is still on.

Control the other variables

A fair comparison changes one thing only: the power mode. Keep everything else fixed.

• Same build, same device and same OS version for the normal and battery saver runs
• Fixed screen brightness, the same choice of Wi-Fi or cellular, and identical Bluetooth and location settings
• Each run starts from a known battery level on a cool device, because heat causes its own throttling
• A fresh install or cleared app data, with the same test account and data set
• Other apps closed and automatic updates disabled on test devices

Step by step: how to test mobile app performance in battery saver mode

The method is a controlled comparison. You establish a baseline, apply each power saving state, repeat the same flows and compare the results. These eight steps take you from planning to a defect report a developer can act on.

1. Map your power sensitive features. List everything that depends on background execution, timing, network or sensors: push notifications, sync, uploads and downloads, location tracking, alarms and reminders, media playback, real time features (chat, live scores, ride tracking), Bluetooth and wearable connections, and widgets. These are your highest risk areas and deserve the most test time.
2. Define expected behavior for each mode. For every feature, decide what “correct” looks like under restriction. A news feed that refreshes the next time the user opens the app is acceptable. A medication reminder that arrives two hours late is not. Write these down as acceptance criteria before you start testing, so results are judged against an agreed standard.
3. Capture a normal mode baseline. On each device, reset battery stats, run your core user journeys and then a 30 to 60 minute background soak, and record the metrics from the table above.
4. Turn on battery saver and repeat. Switch on Android Battery Saver or iOS Low Power Mode, confirm the state, and run the identical journeys and soak. Keep every other variable constant.
5. Test the transitions, not just the steady state. Toggle the mode on and off while the app is in the foreground, while it is in the background, and in the middle of a task, such as during an upload or an active turn by turn route. Many bugs live in the moment of change rather than in the mode itself, because listeners fire, jobs get rescheduled and connections drop all at once.
6. Layer in deeper restrictions on Android. Repeat the key background scenarios with forced Doze, with the app in the rare and restricted standby buckets, with background usage restricted for the app, and with each OEM power saving mode in your matrix.
7. Combine with real world conditions. Run a subset of tests on poor or switching networks, at low battery levels (15% and 5%), at high device temperature and with low storage. Battery saver rarely switches on in ideal conditions, so your tests should not run in ideal conditions either.
8. Compare, triage and report. Diff the battery saver results against the baseline, flag any metric outside your thresholds, and attach logs, video and power traces. File each defect with the exact device, OS version, power mode and steps to reproduce. Then rerun the same suite on every release to catch regressions early.

Battery saver test scenarios checklist

Use this checklist as a starting test suite and tick items off for each device and mode. Then add scenarios that are specific to the core value of your app.

Launch and UI performance

• Cold start and warm start times stay within threshold compared with normal mode
• Scrolling long lists and opening heavy screens stays smooth, with no frozen frames
• Animations degrade gracefully or are reduced, and no feature depends on an animation finishing in order to work
• The dark theme that Battery Saver turns on (Android 10 and later) renders every screen legibly
• Loading states and timeouts behave correctly when operations take longer than usual

Background execution and sync

• Scheduled background sync completes when restrictions lift or during maintenance windows
• Large uploads and downloads resume after being deferred or interrupted
• No duplicate jobs or retry storms occur when the app regains network access
• Data shown on reopen is fresh, or clearly marked as out of date

Notifications

• High priority push messages arrive while the device is in battery saver and in Doze
• Normal priority messages arrive within the agreed delay window
• Tapping a notification after a long delay opens the correct, current content
• Local alarms and reminders fire on time, using exact alarms where justified

Location and sensors

• Foreground route guidance stays accurate with no gaps in the route
• Background tracking behaves as designed, and the app tells the user if tracking is limited
• Geofence events still trigger, or the limitation is handled clearly
• Bluetooth and wearable connections reconnect after the system drops them

Media and real time features

• Audio and video playback continue in the background without stutter
• Streaming quality adapts to reduced bandwidth, for example when iOS limits 5G
• Chat, live tracking and WebSocket connections reconnect cleanly after suspension

Lifecycle and stability

• The app restores its state correctly after the OS kills it in the background
• Toggling the mode during a task causes no crash, data loss or duplicate actions
• In progress forms, carts and drafts survive backgrounding and process death
• No new crashes or ANRs appear compared with the normal mode run

Power consumption

• Idle background CPU is close to zero and no partial wake locks are held
• Battery drain per hour of use is within budget in both modes
• If designed to, the app responds to battery saver itself with fewer refreshes and lighter work

iOS specific checks

• Features that depend on Background App Refresh degrade gracefully when it is paused
• The UI looks correct at 60 Hz on ProMotion devices
• The shorter 30 second Auto Lock does not break long flows such as video calls, checkout or reading

Android OEM specific checks

• Core background features survive Samsung, Xiaomi and other OEM power saving modes
• Onboarding asks users to exempt the app from battery optimization only where it is truly needed

Automating battery saver tests

Automate the parts that are deterministic: switching modes on Android, running the same journeys, collecting metrics and diffing them against a baseline. Keep long soaks and OEM mode checks as scheduled or manual runs, because they are slow and depend on device settings that scripts cannot always reach. For the bigger picture, see our guide to mobile performance testing in CI/CD pipelines.

Android with Appium

Appium’s UiAutomator2 driver can run adb shell commands through mobile: shell, as long as the server is started with the adb_shell insecure feature enabled (for example, appium –allow-insecure=adb_shell, or the equivalent setting on your device cloud). That lets a single test toggle Battery Saver, run a flow and restore the device afterwards:

def shell(driver, cmd, *args):
    return driver.execute_script("mobile: shell", {"command": cmd, "args": list(args)})

def enable_battery_saver(driver):
    shell(driver, "dumpsys", "battery", "unplug")
    shell(driver, "settings", "put", "global", "low_power", "1")
    assert shell(driver, "settings", "get", "global", "low_power").strip() == "1"

def restore_power_state(driver):
    shell(driver, "settings", "put", "global", "low_power", "0")
    shell(driver, "dumpsys", "battery", "reset")

def test_feed_refresh_in_battery_saver(driver):
    enable_battery_saver(driver)
    try:
        driver.background_app(60)          # send app to background for 60 s
        # ...assert feed refresh, notification receipt, sync state...
    finally:
        restore_power_state(driver)

def shell(driver, cmd, *args):
    return driver.execute_script("mobile: shell", {"command": cmd, "args": list(args)})

def enable_battery_saver(driver):
    shell(driver, "dumpsys", "battery", "unplug")
    shell(driver, "settings", "put", "global", "low_power", "1")
    assert shell(driver, "settings", "get", "global", "low_power").strip() == "1"

def restore_power_state(driver):
    shell(driver, "settings", "put", "global", "low_power", "0")
    shell(driver, "dumpsys", "battery", "reset")

def test_feed_refresh_in_battery_saver(driver):
    enable_battery_saver(driver)
    try:
        driver.background_app(60)          # send app to background for 60 s
        # ...assert feed refresh, notification receipt, sync state...
    finally:
        restore_power_state(driver)

The same pattern works for dumpsys deviceidle force-idle and am set-standby-bucket. Always restore the device state in a finally block, so that one failed test does not leave a shared device stuck in battery saver and quietly skew every test that runs after it.

Android with Espresso and instrumentation

For instrumented tests, run the adb commands from your CI script before and after the suite, or call UiDevice.executeShellCommand() from UI Automator inside the test itself. Pair this with Jetpack Macrobenchmark to capture startup and frame timing in both modes, since Macrobenchmark gives you stable, repeatable numbers that are easy to compare across builds.

iOS with XCUITest

Because Low Power Mode cannot be toggled from a test, structure iOS automation around device state rather than test code:

• Run the same XCUITest suite against one device pool with Low Power Mode on and another with it off.
• Check the mode at the start of each test by reading a value your debug build exposes (for example, a hidden label bound to isLowPowerModeEnabled), and fail fast if the device is in the wrong state.
• Use XCTMetric measurements (XCTCPUMetric, XCTMemoryMetric, XCTApplicationLaunchMetric, XCTOSSignpostMetric) inside measure(metrics:) blocks to compare results from both pools.

Wire it into your CI/CD pipeline

• Run a short battery saver smoke suite (launch, login, one core journey, one background sync and one push) on every pull request or nightly build.
• Run the full checklist plus 30 to 60 minute soaks weekly and before each release.
• Store metric baselines per device, and fail the build when the battery saver change exceeds your thresholds.
• Publish logs, video, battery stats and power traces as build artifacts, so failures can be debugged without a rerun.

Tools for profiling and analyzing results

Pair a real device platform for running tests with platform profilers for finding root causes. The table below maps each tool to the question it answers best.

When you analyze results, look for patterns rather than single numbers. Typical warning signs include background CPU spikes that line up with timers, wake locks that never release, bursts of requests right after Doze maintenance windows, and frame drops on specific screens that appear only in battery saver mode.

Common battery saver issues and how to fix them

Most battery saver defects fall into a handful of recurring patterns. Here is what you will typically see, why it happens and the usual fix, so you can hand developers a likely cause along with the bug report.

Best practices for building battery saver resilient apps

The best battery saver test results come from apps that are designed to expect restriction. Share these practices with your development team so that the fixes become defaults rather than one off patches.

• Detect the mode and adapt. Listen for power state changes and lighten the load when battery saver is on: lower the refresh frequency, pause prefetching, reduce animation and drop media quality.
• Use the OS schedulers. WorkManager on Android and BGTaskScheduler on iOS cooperate with Doze, standby buckets and Low Power Mode instead of fighting them, so deferred work still runs at the right time.
• Trigger work by events, not timers. Only poll when something has actually changed. Software Mansion did exactly this by requesting location updates based on user activity rather than continuously.
• Batch and cache network calls. Fewer, larger requests let the radio return to sleep sooner, and cached data keeps the app useful when the network is unavailable.
• Stop work that nobody sees. Pause rendering, timers and listeners for screens that are not visible and for apps in the background.
• Design for process death. Assume the OS can kill your app at any moment, and make every screen restorable.
• Be honest with users. If a feature is limited in battery saver mode, say so in the UI. Ask for a battery optimization exemption only when the core function genuinely needs it, and explain why.
• Audit third party SDKs. Analytics, ads and attribution SDKs often run their own background work. Profile them in battery saver mode with the same rigor as your own code.
• Monitor in production. Track crash, ANR, delivery and energy metrics broken down by power saving state, so you catch what the lab missed.

How Kobiton helps you test battery saver mode at scale

Battery saver testing only produces results you can trust when it runs on real hardware across many device models, and that is exactly where an in house device lab becomes a bottleneck. Buying, configuring and maintaining a Pixel, several Samsungs, a few aggressive OEM devices and a range of iPhones is slow and expensive. Kobiton’s real device testing platform removes that bottleneck.

• Real iOS and Android devices, not emulators. Test on the actual Pixels, Samsungs, Xiaomis and iPhones your users carry, with real CPU throttling, real OEM battery managers and genuine Low Power Mode behavior.
• Manual and automated testing in one place. Investigate power saving scenarios interactively first, then run the same journeys with Appium, Espresso or XCUITest in parallel across your whole device matrix.
• Rich session evidence. Every session captures video, device logs and performance data such as CPU and memory usage, so you can compare normal and battery saver runs side by side and hand developers a defect they can reproduce.
• CI/CD integration. Trigger battery saver smoke suites from your pipeline on every build and release.
• Flexible deployment. Use public cloud devices, dedicated private devices you can keep configured in a power saving state, or on premises options for regulated teams.

Editor’s note: confirm current feature names and links (device settings controls, performance metrics, adb and shell access per plan) with the Kobiton product team before publishing, and add a product screenshot or short GIF of a session here.

Frequently asked questions

Does battery saver mode slow down mobile apps?

Often, yes. Both Android Battery Saver and iOS Low Power Mode can reduce CPU and GPU performance, limit background activity and cap display refresh rates. As a result, heavy screens, app launches and background tasks can run more slowly or be deferred until restrictions lift.

Can I test iOS Low Power Mode on a simulator?

No. The iOS Simulator does not reproduce Low Power Mode behavior or real power throttling. Use physical iPhones, either in your own lab or on a real device cloud.

How do I turn on battery saver with adb?

Run adb shell dumpsys battery unplug, then adb shell settings put global low_power 1. Turn it off with low_power 0, and restore normal battery reporting with adb shell dumpsys battery reset.

What is the difference between Doze and Battery Saver on Android?

Battery Saver is a mode that the user or a schedule turns on, and it applies even while the screen is on. Doze activates automatically when the device is unplugged, stationary and has its screen off; it suspends network access and defers work into maintenance windows. Your app will meet both, so test both.

Can XCUITest turn on Low Power Mode automatically?

Not through a public API. Set the mode on the device beforehand, through device settings, a Shortcuts automation or your device cloud’s controls, and have each test confirm the state when it starts.

How long should a battery drain test run?

Run short functional checks on every build, and 30 to 60 minute background soaks before releases. Run longer soaks for tracking and media apps, where drain builds up over hours. Start each run at the same battery level and temperature so results stay comparable.

Which Android devices matter most for battery saver testing?

A stock Pixel for baseline behavior, a Samsung device because it represents the largest share of Android users, and at least one device from an OEM known for aggressive battery management, such as Xiaomi, OPPO or vivo. Weight the final list by your own user analytics.

Conclusion

Testing mobile app performance in battery saver mode comes down to one discipline: run the same journeys on the same real devices, with and without power restrictions, and treat the difference as a test result. Know what Android Battery Saver, Doze, standby buckets, OEM battery managers and iOS Low Power Mode each restrict. Capture a clear baseline, test the transitions as well as the steady states, and automate the repeatable parts in CI.

Do that consistently, and your app keeps its notifications, syncs, tracking and UI working when users need them most, without becoming the app that drains their battery.