adb shell dumpsys batteryinfo vs dumpsys batterystats
i get asked some version of this every few months: there are three dumpsys services with “battery” in the name, they all print walls of text, and which one do i run when a test build is eating the battery? i run Android test devices from Singapore, and the short answer is that these two commands answer different questions. dumpsys battery (what most people mean when they type batteryinfo) tells you what the battery is doing right now, and lets you fake it. dumpsys batterystats tells you what happened over time and which app is to blame.
A note on names. as far as i know, batteryinfo was the registered name of the battery statistics service on very old Android releases, before it became batterystats. i have not pinned down the exact release, so do not take my word for it. run adb shell dumpsys -l on your own device and read the service list. if batteryinfo is not in it, the command will just say it cannot find the service. in this article, “Vendor A” is the current-state side (dumpsys battery, the thing people usually want when they say batteryinfo) and “Vendor B” is dumpsys batterystats. both are free, both ship inside Android, and neither has a per-GB price, so i have adapted the comparison axes to fit.
Verdicts by use case, in one paragraph. for debugging battery drain in a test, use batterystats. for simulating low battery, charging states or an unplugged device in a test, use battery. for a quick “what is the charge and temperature right now”, use battery. and the best drain workflow uses both together, because batterystats only accounts for discharge when the device thinks it is unplugged, and battery is how you tell it that.
TL;DR comparison table
| Vendor A: dumpsys battery | Vendor B: dumpsys batterystats | |
|---|---|---|
| pricing | free, part of Android | free, part of Android |
| what it reports | level, scale, status, health, plugged state, voltage, temperature, technology | per-app (UID) usage, wakelocks, estimated power use, battery history, discharge since last reset |
| can it change state | yes: set level, status, ac/usb, unplug, reset | only its own bookkeeping: reset, enable extra history |
| support and docs | thin docs, behaviour read from the AOSP source and help output |
documented on developer.android.com, pairs with Battery Historian |
| output size | a dozen lines | thousands of lines, plus checkin and proto formats |
| target user | test engineers faking battery conditions, anyone checking state | developers and QA chasing drain, power regressions |
Vendor A at a glance: dumpsys battery
adb shell dumpsys battery prints the state held by the framework’s battery service. you get a short block: whether AC, USB or wireless is powering the device, status (charging, discharging, full), health, whether a battery is present, level against scale, voltage, temperature, and the battery technology string. temperature is reported in tenths of a degree Celsius, so a reading of 310 means 31.0 C. that tripped me up the first time.
its second job is the one that matters for testing. it can override what the rest of the system sees. the commands i use most are:
adb shell dumpsys battery set level 15to pretend the charge is 15 percentadb shell dumpsys battery set status 3to set a status code (3 is discharging in the BatteryManager constants)adb shell dumpsys battery set usb 0andset ac 0to say nothing is plugged inadb shell dumpsys battery unplugto simulate unplugging while the cable is still attachedadb shell dumpsys battery resetto put everything back to real values
that last one is the command people forget. if you leave a device in faked state, it stays that way until you reset or reboot, and your next test run will behave strangely. i put reset in the teardown of every harness that touches this. run adb shell dumpsys battery with no arguments after teardown to confirm.
what it does not do: it does not tell you why the charge dropped, and it has no history. it is a snapshot plus a set of overrides. if you want the official background on what dumpsys is and how services are listed, the Android dumpsys documentation covers the basics.
Vendor B at a glance: dumpsys batterystats
adb shell dumpsys batterystats is the one built for the drain question. it dumps the battery statistics service’s accumulated data: time on battery, screen on and off time, per-UID CPU time, network bytes, wakelock time, sensor use, alarms, jobs, and a battery history log with timestamped events. there is also an “estimated power use” section that attributes charge to apps and to hardware components. those figures are estimates built from a device power profile, not meters on the rail, so treat them as a ranking hint rather than as exact milliamps.
the options that matter for tests, all on the same command:
adb shell dumpsys batterystats --resetclears the accumulated stats so your measurement starts cleanadb shell dumpsys batterystats --enable full-wake-historyrecords every wakelock event instead of a summary, which Google’s Battery Historian workflow asks foradb shell dumpsys batterystats <package>narrows the output to one app, which is far easier to readadb shell dumpsys batterystats --checkingives a machine-readable format for scriptsadb shell dumpsys batterystats -hprints the options your build actually supports, which is the source of truth, because OEM and Android versions differ
the official walkthrough lives in Google’s page on setting up Battery Historian, which shows the reset, run, and bugreport loop. Battery Historian turns the bugreport into a timeline you can zoom into, and it is much kinder than reading the raw text.
the catch is the one nobody warns you about: with the phone on a USB cable, the framework thinks it is charging, so discharge-based numbers do not accumulate the way you expect. that is where the battery command comes back in.
head-to-head
data scope (instead of IP pool size)
battery has a tiny scope: one battery, one moment. batterystats has a large scope: every app that ran since the last reset or the last full charge, plus system components. if your question starts with “which app”, only batterystats can answer it. if your question starts with “what is the level”, battery is faster and the output fits on screen.
state control (instead of rotation control)
battery is the one with write access. you can set level, status, plug state, and unplug, and each change broadcasts the same events apps listen for, so you can test your low battery handling or your charging-only job constraints without a drained phone. batterystats only controls its own recording: reset, enable extra history, write out to disk. it will never let you fake a condition. so for conditional logic in your app, battery. for measurement hygiene, batterystats.
version coverage (instead of geo coverage)
battery has been stable for a long time and the main subcommands work across the Android versions i test on. batterystats is where change lives. the service has been reshaped across releases, flags have been added and deprecated, and the way power is attributed has been revised more than once. as of October 2026, i would not paste a batterystats flag from a years-old forum answer without running -h first. and if you are still seeing the batteryinfo name in an old tutorial, that tutorial predates the rename, so expect other things in it to be stale too.
reliability (instead of connection success rate)
i am not going to quote a success percentage, because i have not measured one and it would be made up. what i can say from running these across a handful of test phones: battery rarely surprises me. the exception is leaving a device in faked state. batterystats can surprise me in three ways: the counters reset when the device completes a charge, so a long-lived device may show less history than you assumed; the output differs between OEM builds; and a run on a cable without unplug yields near-empty discharge data. none of these are bugs. they are the behaviour, and they explain most of the “batterystats shows nothing” questions online.
speed and overhead
battery returns instantly and costs nothing. a full batterystats dump is large and can take a moment to pull over adb, and a big history can run to many thousands of lines. i redirect it to a file with adb shell dumpsys batterystats > stats.txt rather than scrolling it in a terminal. if you are pulling it over a slow or remote adb link, the transport matters; i wrote up how the protocol moves bytes in the adb protocol deep dive.
pricing per GB
both commands are free. there is no per-GB price, no licence, no account. the real costs are your time and, for batterystats, storage and parsing if you collect dumps from many devices in CI. Battery Historian is open source but wants a Docker or Go setup, which is an afternoon of work the first time. if you want the cheaper path, a --checkin dump piped into your own script is usually enough for regression checks.
session persistence
battery overrides persist until you reset or reboot, which is a feature when you want a long scenario and a hazard when you forget. batterystats persists differently: its data survives across your adb sessions but is cleared by --reset and by the system after a full charge cycle. so a measurement is a window: reset, run the scenario, dump. don’t dump an hour late and expect only your test in it.
concurrent connections
adb will happily run both commands against many devices at once, one adb server and many serials, and the commands are independent per device. nothing in either command limits concurrency. the practical limit is your host: dumping batterystats from forty phones at once makes a lot of text. for how people structure that at scale, what is an Android device farm covers the shape of it. only run these on devices you own or are authorised to test.
use-case verdicts
debugging battery drain in a test run
winner: batterystats, with battery as the helper. this is the question behind the Stack Overflow thread many people land on from search (question 24402918), so here is the direct answer. dumpsys battery reports the instantaneous state and can fake it. dumpsys batterystats reports accumulated per-app usage and a history timeline. to find what drained the battery, you want the second one. the workflow i use:
adb shell dumpsys batterystats --enable full-wake-historyadb shell dumpsys batterystats --resetadb shell dumpsys battery unplugso the framework counts discharge even though the cable is in- run the test scenario
adb shell dumpsys batterystats <your.package>oradb bugreportfor Battery Historianadb shell dumpsys battery resetto put the device back
if the phone is on a USB cable that is also supplying power, the numbers still come from software accounting and are estimates. for a result you can trust, run the same scenario a few times and compare ranks, not absolute values. if you need to know how an app behaves on a real mobile network rather than wifi, the radio is often the biggest line item, and that is a different test setup, which i cover in testing apps on real carrier networks.
simulating low battery or charging states
winner: battery. you cannot do this with batterystats at all. set the level, set the status, assert that your app defers its sync, then reset. it is the only sane way to test battery-saver-adjacent logic without waiting for a real discharge.
quick health check of a device in a lab
winner: battery. level, temperature, and health in a dozen lines is what you want in a monitoring script. a temperature reading creeping up on a device that has been running tests all day is a useful early sign of a phone that needs a rest. no need to parse a multi-thousand-line dump for that.
power regression check in CI
winner: batterystats. take the --checkin output for your package before and after a change, compare wakelock time and CPU time rather than the estimated mAh, and fail the build on a big jump. keep the threshold loose. i have no benchmark numbers to hand you here and i would not trust anyone who did without knowing your device and workload.
who should pick Vendor A
pick dumpsys battery if you are writing tests that depend on battery state, if you want a fast state check in a script, or if you only need to know the current charge and temperature. it is also the command you need alongside batterystats on a cabled device. if you are a beginner who just wants to know whether a phone is charging, start here, because the output is short enough to read in one glance.
who should pick Vendor B
pick dumpsys batterystats if the question is “who used the battery” or “did this build get worse”. it is the right tool for developers and QA looking at wakelocks, jobs, alarms, and per-app usage, and it is the input format Battery Historian expects. expect to spend some time learning the output, and expect to run -h on every new Android version.
one practical note on hardware. software accounting on a phone sitting on a bench cable is a rough guide. if you want to see how your app drains on a real handset and a real Singapore mobile connection, cloudf.one rents real Android phones in Singapore on dedicated hardware, each with a persistent Singapore mobile IP, controlled from the browser. there is no self-service adb on it: adb and Appium reach a rented phone only through a WireGuard tunnel that we set up on request by emailing [email protected], so check that setup is workable for you before planning a test around it. it is Singapore only, so it will not tell you about other countries’ carriers. the link is cloudf.one and it is only worth a look if that is the problem you actually have.
verdict overall
this is not a contest with one winner, so my verdict is “it depends”, and the dependency is simple. use dumpsys battery to know and to fake the state. use dumpsys batterystats to explain the drain. for the question that brought most people here, debugging drain in tests, the answer is batterystats, preceded by --reset, wrapped in battery unplug and battery reset.
three habits save the most time. always run adb shell dumpsys -l or -h on the target device before trusting a flag from an old post. always reset the battery override in teardown. and compare runs against each other instead of reading a single dump as truth, because the per-app power figures are estimates. there are more of my android automation notes in the blog index.
Written by Xavier Fok
disclosure: this article may contain affiliate links. if you buy through them we may earn a commission at no extra cost to you. verdicts are independent of payouts. last reviewed by Xavier Fok on 2026-10-23.