The battery service is one of the more approachable corners of dumpsys, and it's useful for two distinct reasons: reading detailed power diagnostics that don't appear anywhere in the Settings app, and, on devices where it's supported, overriding the reported battery state to test how an app behaves at 5% charge or while unplugged, without actually draining the battery or unplugging the cable.
adb shell dumpsys batteryThis returns a compact block covering charge level as a percentage, charging status (charging, discharging, full, or not charging), the power source currently supplying it (AC, USB, or wireless), battery temperature in tenths of a degree Celsius, voltage in millivolts, and the battery health flag Android currently reports (good, overheat, dead, over voltage, and a few less common states).
The temperature field trips people up most often — a reading of 320 means 32.0°C, not 320 degrees; dividing the raw value by ten gives the actual temperature.
On devices and emulators where the battery service accepts it, a set of subcommands lets you force specific values so an app under development can be tested against edge-case power states on demand rather than waiting for the battery to actually reach that level:
adb shell dumpsys battery set level 5
adb shell dumpsys battery set status 3
adb shell dumpsys battery set ac 0
adb shell dumpsys battery set usb 0The status values follow Android's BatteryManager constants (2 for charging, 3 for discharging, 5 for full), and setting both ac and usb to 0 simulates being fully unplugged even while the cable stays physically connected for the ADB session itself.
Overrides set this way persist until explicitly cleared, which surprises people when the phone continues reporting a fake 5% charge long after the test is done:
adb shell dumpsys battery resetRunning reset restores normal, live battery reporting immediately. It's easy to forget this step at the end of a testing session and be left wondering why the phone's status bar shows an impossible or frozen battery percentage afterward.
Override support depends on the device's power HAL implementation, and some manufacturers' custom power management stacks ignore the override commands entirely, silently reporting real values regardless of what was set. Emulators and Google reference devices reliably support the full override set; heavily customized OEM builds are the least consistent, so confirming an override actually took effect (by immediately reading back with plain dumpsys battery) is worth doing before assuming a test scenario is actually being exercised.
For a broader system health picture beyond just power, the general dumpsys diagnostics guide covers other services worth checking alongside battery, such as memory and activity state. Android's official battery monitoring guide covers the same override commands from the app-development side, useful when the goal is testing an app's own battery-aware code rather than just reading diagnostics.
Beyond simulating states for app testing, plain dumpsys battery output is genuinely useful for diagnosing a phone that charges slowly or not at all, without any override involved. Comparing the reported plugged value (which power source Android thinks is connected) against what's physically plugged in catches cases where a cable or charger is delivering power the phone doesn't correctly identify as AC versus USB, which some devices treat very differently for charging speed purposes. A battery reporting health: 2 (good) but stuck at a status of "not charging" despite being plugged into a known-good charger points toward a software-level charge limit or thermal throttling decision, rather than a hardware fault, since a genuine hardware problem more often shows up as the device not registering any power source at all.
Running adb shell dumpsys battery | grep temperature in a short loop while a phone is under heavy load (a demanding game, a long video export, or extended GPS use) gives a live-ish temperature trace without needing a dedicated monitoring app installed on the device itself. Since the reported figure is in tenths of a degree, watching it climb from a resting value into the high 300s or 400s (37–40°C and beyond) over a testing session is a practical way to correlate a specific workload with thermal throttling behavior a user might otherwise only notice as unexplained slowdown.