How do I run an adb shell command?

Switch on developer options and USB debugging on the phone, plug it in, then run adb shell from a machine with platform-tools installed — or run adb shell on its own to get an interactive prompt and type the command without the prefix. If the command produces binary output, such as a screenshot, use adb exec-out instead of adb shell: the plain shell service attaches a terminal, which rewrites newline bytes and corrupts the data.

Do adb shell commands need root?

Not the ones on this reference. They run as the shell user, which can manage packages for its own Android user, read most dumpsys services, write the settings provider, inject input and read shared storage. Root is only needed for things this reference deliberately avoids — reading another app's private data (except through run-as on a debuggable build), writing system partitions, or reading /data/anr directly.

Why does the output look different on my phone?

Either the Android version or the manufacturer. Some flags and fields arrived in a specific release, and those are noted per command. The rest is OEM patching, which hits dumpsys hardest: a dump is debug output whose text is whatever the service author last printed, and manufacturers change it and backport their changes. Read fields by name rather than by position, and treat an unfamiliar shape as a difference rather than as a failure.

Can I run this from a browser instead of a terminal?

For many commands, yes — the Web ADB tools on this site talk to a phone over WebUSB from a Chromium-based desktop browser, with no SDK installed and nothing uploaded. Each page links to the tool that runs its command, when one exists. Two limits are worth knowing: only one program can hold the ADB interface at a time, so a desktop adb server has to be stopped first, and adb forward and adb reverse cannot work in a browser at all.

dumpsys battery

read-only

The battery service's live state: level, status, health, voltage and temperature.

Command: adb shell dumpsys battery
Commands: System services (dumpsys)
Risk: read-only

Syntax

dumpsys battery

Examples

```
dumpsys battery
```
One snapshot of everything the service knows.
```
cat /sys/class/power_supply/battery/current_now
```
Cross-check the charge current against the kernel, whose unit is fixed by the power-supply class rather than by the OEM.

Reading the output

Sample output

Current Battery Service state:
  AC powered: false
  USB powered: true
  Charge counter: 3110000
  status: 2
  health: 2
  level: 71
  scale: 100
  voltage: 4038
  temperature: 302

An indented `key: value` list. The units are the trap, because three different Android sources report temperature on three different scales: here it is tenths of a degree Celsius, so `302` is 30.2 °C. Read fields by name, never by position — OEMs insert their own lines anywhere in the list.

Output fields

Field	Meaning
level / scale	Charge as level out of scale. `scale` is 100 on every shipping device, and it is printed so nobody has to assume it.
status	1 unknown, 2 charging, 3 discharging, 4 not charging, 5 full.
health	2 good, 3 overheat, 4 dead, 5 over-voltage, 6 unspecified failure, 7 cold.
voltage	Millivolts, so `4038` is 4.038 V.
temperature	Tenths of a degree Celsius: `302` is 30.2 °C.
Charge counter	Microamp-hours: `3110000` is 3110 mAh.
Max charging current / voltage	Microamps and microvolts respectively.

What access it needs

Reading needs `android.permission.DUMP` and nothing else. `BatteryService`'s binder checks it through `DumpUtils.checkDumpPermission`, and the Shell package's manifest declares both `DUMP` and `BATTERY_STATS`, so an ordinary authorised `adb` connection is enough — no root, no `adb root`, no Settings grant. The write side is the part that deserves a second look, because it is available to you by exactly the same route. `dumpsys battery set …` and `dumpsys battery unplug` are not reads at all: they are shell subcommands of the battery service, each guarded by `enforceCallingOrSelfPermission(android.Manifest.permission.DEVICE_POWER)`, and the Shell manifest holds `DEVICE_POWER` too. That is why an accidental injection is so easy from a cable, and why the `(UPDATES STOPPED …)` line exists. Which half you land in is decided by argument parsing rather than by any keyword you would recognise: `dumpInternal` prints the human-readable state block only when there are no arguments at all or the single argument `-a`, and hands **every other argument** to the battery shell command handler. So `dumpsys battery` and `dumpsys battery -a` are reads; `dumpsys battery level` is a mis-parsed subcommand; and `dumpsys battery set level 5` is a change to the device that outlives your shell session until something resets it. The Android Battery Health tool only ever sends the read form.

Failure messages, decoded

Message	Meaning
Permission Denial: can't dump BatteryService from from pid=4821, uid=10231 due to missing android.permission.DUMP permission	From `DumpUtils.checkDumpPermission`. The doubled `from from` is in the AOSP string, not a transcription slip, so match on it rather than correcting it. The nastier detail is the stream: this is written to the dump's own writer, which means it arrives on stdout, exactly where the battery fields normally are. A parser that looks for `level:` and finds nothing will report an empty battery rather than a refused call.
Unknown command: level	You asked for a field and got the shell command handler. `dumpsys battery` recognises no arguments and `-a` as "print the state block"; anything else, including every field name printed in the dump, is treated as a subcommand. Use `dumpsys battery get level`, or read `level:` out of the plain dump. Printed on stdout, so it can end up inside a captured "reading".
* SERVICE 'battery' DUMP TIMEOUT (10000ms) EXPIRED *	The `dumpsys` binary gave up waiting after its default ten seconds and printed this in the output stream. Everything above it is real; whatever the service had not written yet is simply absent, and because the fields are printed in a fixed order the missing ones are always the tail — `technology` first, then `temperature`. Raise the wait with `-t SECONDS` or `-T MILLIS` rather than re-reading a truncated block.
Can't find service: battery	Printed to stderr by the `dumpsys` binary when the service manager has no `battery` entry, which happens while the device is still booting. It is not an OEM having renamed anything, and it is not a permission problem — nothing was asked of the service at all.

Version and vendor notes

Stock Android prints neither a charge current nor a cycle count here. A phone that shows `current now` or `cycle count` has an OEM-patched dump, and both the sign and, on some builds, the scale of that current field vary — so treat its magnitude with suspicion and get the direction from `status` instead.
`(UPDATES STOPPED -- use 'reset' to restart)` means somebody injected values with `dumpsys battery set` or `unplug`. Everything below that line is fiction until `dumpsys battery reset`.
Temperature here is tenths of a degree, `/sys/class/thermal/*/temp` is thousandths, and `dumpsys thermalservice` prints plain degrees as a float. Mixing them up is a factor-of-ten error in either direction.
`Dock powered:` is newer than the rest of the block — `BatteryService` prints it at tag android-14.0.0_r1 and not at android-11, 12 or 13 — so its absence on an older phone is age, not a missing dock.
Arguments here are not filters: the state block is printed only for no arguments at all or the single argument `-a`, and every other argument is handed to the battery service's own shell command handler, where `set` and `unplug` are waiting.

We have a UI for this

Android Battery Health runs this command over USB and parses what comes back — a Chromium browser, no SDK, nothing uploaded.

Open Android Battery Health

Related commands

Commands that turn up in the same session as dumpsys battery.

Command	What it does
dumpsys thermalservice	Whether the phone is throttling, and every thermal zone the hardware layer reports, in degrees Celsius.
top	A one-shot process table: CPU share, memory, state and command line.
dumpsys meminfo	Which processes are using the most memory, measured as proportional set size.

More System services (dumpsys) commands

Command	What it does
dumpsys diskstats	Free space per partition, a disk write latency check, and a cached per-app breakdown of what is using storage.
dumpsys sensorservice	Every sensor the phone has, with its vendor, type, rates and batching — plus a buffer of recent readings.
dumpsys package	Everything the package manager knows about one app: version, paths, flags, install source and per-user state.
dumpsys activity activities	Which app is in the foreground, and the task and stack structure behind it.
dumpsys dropbox	The platform's ring buffer of crashes, ANRs and tombstones — how you read ANR traces without root.

Checked against AOSP, toybox and kernel sources while writing the parsers behind our Web ADB tools. Where a behaviour genuinely varies by Android version or manufacturer, this page says so instead of giving a number that would be wrong on half the phones out there.