ByteScope

dumpsys battery

読み取りのみ

バッテリーサービスの現在の状態:残量、充電状態、健康度、電圧、温度。

コマンド
adb shell dumpsys battery
コマンド
システムサービス(dumpsys)
リスク
読み取りのみ

構文

dumpsys battery

使用例

  • dumpsys battery

    サービスが知っていることの 1 回分のスナップショット。

  • cat /sys/class/power_supply/battery/current_now

    充電電流をカーネル側と突き合わせます。こちらの単位はメーカーではなく power supply クラスが固定しています。

出力の読み方

出力例

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

字下げされた `key: value` の並びです。罠は単位です。Android には温度の情報源が 3 つあり、それぞれ違う尺度を使います。ここでは摂氏の 10 分の 1 なので `302` は 30.2 °C です。位置ではなく名前でフィールドを読んでください。メーカーは独自の行を並びのどこにでも挿し込みます。

出力フィールド

フィールド意味
level / scale`scale` に対する `level` として表される残量。`scale` は出荷されている端末ではどれも 100 ですが、誰も仮定しなくて済むように印字されています。
status1 不明、2 充電中、3 放電中、4 充電していない、5 満充電。
health2 良好、3 過熱、4 故障、5 過電圧、6 原因不明の故障、7 低温。
voltageミリボルト。`4038` は 4.038 V。
temperature摂氏の 10 分の 1。`302` は 30.2 °C。
Charge counterマイクロアンペア時。`3110000` は 3110 mAh。
Max charging current / voltageそれぞれマイクロアンペアとマイクロボルト。

必要な権限

読み取りに必要なのは `android.permission.DUMP` だけです。`BatteryService` の binder は `DumpUtils.checkDumpPermission` でそれを確認し、Shell パッケージのマニフェストは `DUMP` と `BATTERY_STATS` の両方を宣言しているので、普通の認可済み `adb` 接続で足ります。root も `adb root` も設定画面での許可も不要です。二度見する価値があるのは書き込み側で、しかもそれはまったく同じ経路で手が届きます。`dumpsys battery set …` と `dumpsys battery unplug` は読み取りではなく、バッテリーサービスのシェルサブコマンドです。それぞれ `enforceCallingOrSelfPermission(android.Manifest.permission.DEVICE_POWER)` で守られていますが、Shell のマニフェストは `DEVICE_POWER` も持っています。ケーブルから事故で値を注入してしまうのが簡単なのはそのためで、`(UPDATES STOPPED …)` の行が存在する理由でもあります。どちら側に落ちるかを決めるのは、見て分かるキーワードではなく引数の解析です。`dumpInternal` が人間向けの状態ブロックを印字するのは、引数がまったく無いか `-a` 1 つだけのときで、**それ以外の引数はすべて** バッテリーサービスのシェルコマンドハンドラに渡されます。つまり `dumpsys battery` と `dumpsys battery -a` は読み取り、`dumpsys battery level` は解釈を誤ったサブコマンド、`dumpsys battery set level 5` は何かがリセットするまでシェルセッションより長く生き残る端末の変更です。Android Battery Health が送るのは読み取りの形だけです。

エラーメッセージの読み解き

メッセージ意味
Permission Denial: can't dump BatteryService from from pid=4821, uid=10231 due to missing android.permission.DUMP permission`DumpUtils.checkDumpPermission` が出す行です。`from from` と重なっているのは AOSP の文字列そのもので、書き写しの誤りではないので、直さずにそのまま照合してください。もっと厄介なのはストリームです。これはダンプ自身のライターに書かれる、つまり **標準出力**、バッテリーのフィールドが本来出てくるまさにその場所に届きます。`level:` を探して見つからなかった解析器は、拒否された呼び出しではなく「空のバッテリー」を報告します。
Unknown command: levelフィールド名を尋ねたつもりが、シェルコマンドハンドラに届いています。`dumpsys battery` が「状態ブロックを出せ」と解釈するのは引数なしと `-a` だけで、それ以外は――ダンプに出てくるフィールド名も含めて――すべてサブコマンド扱いです。`dumpsys battery get level` を使うか、素のダンプから `level:` を読んでください。標準出力に出るので、そのまま「読み取った結果」の中に紛れ込みます。
*** SERVICE 'battery' DUMP TIMEOUT (10000ms) EXPIRED ***`dumpsys` バイナリが既定の 10 秒で待つのをやめ、出力ストリームにこれを書きました。この行より上は本物で、サービスがまだ書いていなかった分は単に無いだけです。フィールドは決まった順で印字されるので、欠けるのはいつも末尾から――まず `technology`、次に `temperature` です。切れたブロックを読み直すのではなく、`-t SECONDS` か `-T MILLIS` で待ち時間を伸ばしてください。
Can't find service: batteryサービスマネージャに `battery` の登録が無いときに `dumpsys` バイナリが標準エラーへ出す行で、端末がまだ起動途中のときに起きます。メーカーが名前を変えたわけでも、権限の問題でもありません。そもそもサービスには何も尋ねられていないのです。

バージョンとメーカーに関する注意

  • 素の Android はここに充電電流もサイクル数も表示しません。`current now` や `cycle count` が出る端末はメーカー改変版で、その電流フィールドは符号も、ビルドによっては尺度も揺れます。大きさは疑い、向きは `status` から取ってください。
  • `(UPDATES STOPPED -- use 'reset' to restart)` は誰かが `dumpsys battery set` や `unplug` で値を注入したという意味です。その行より下は `dumpsys battery reset` まで作り物です。
  • ここの温度は 10 分の 1 度、`/sys/class/thermal/*/temp` は 1000 分の 1 度、`dumpsys thermalservice` は浮動小数点の摂氏です。取り違えるとどちらの方向にも 10 倍の誤りになります。
  • `Dock powered:` はこのブロックの中では新しい行で、`BatteryService` が印字するのは tag android-14.0.0_r1 からです。android-11・12・13 には出ません。古い端末に無いのは年式のせいで、ドックが見つかっていないからではありません。
  • ここでの引数はフィルタではありません。状態ブロックが印字されるのは引数がまったく無いか `-a` 1 つだけのときで、それ以外の引数はすべてバッテリーサービス自身のシェルコマンドハンドラに渡されます。その先には `set` と `unplug` が待っています。

これには UI があります

Android Battery Health はこのコマンドを USB 経由で実行し、返ってきたものを解析します。Chromium 系ブラウザだけで、SDK も不要、どこにもアップロードしません。

Android Battery Health を開く

関連コマンド

dumpsys battery と同じ作業で出てくるコマンド。

コマンド何をするか
dumpsys thermalservice端末が発熱で性能を絞っているか、そしてハードウェア層が報告する各温度ゾーンを摂氏で表示します。
top1 回分のプロセス表:CPU 使用率、メモリ、状態、コマンドライン。
dumpsys meminfoどのプロセスがメモリを最も使っているかを、PSS(比例配分したサイズ)で表示します。

他のシステムサービス(dumpsys)コマンド

コマンド何をするか
dumpsys diskstatsパーティションごとの空き容量、ディスク書き込み遅延の実測、そしてキャッシュされたアプリ別の使用量内訳。
dumpsys sensorservice端末にあるすべてのセンサーとそのベンダー、type、レート、バッチング。加えて直近の測定値のバッファ。
dumpsys packageパッケージマネージャが知っているすべて:バージョン、パス、flags、インストール元、ユーザーごとの状態。
dumpsys activity activitiesいまどのアプリが前面にいるか、そしてその背後のタスクとスタックの構造。
dumpsys dropboxクラッシュ、ANR、tombstone を保持するプラットフォームのリングバッファ。root なしで ANR トレースを読む方法です。

Web ADB ツール群のパーサを書きながら、AOSP・toybox・カーネルのソースに突き合わせて確認しています。バージョンやメーカーで本当に挙動が変わるところは、世界の半分の端末で間違いになる数値を出す代わりに、そう書いてあります。

よくある質問

adb shell のコマンドはどう実行しますか?

端末で開発者向けオプションと USB デバッグを有効にし、ケーブルを繋いだうえで、platform-tools を入れた機械から adb shell <コマンド> を実行します。adb shell だけを実行すれば対話プロンプトが出て、接頭辞なしで打てます。スクリーンショットのようにバイナリを出力するコマンドでは adb shell ではなく adb exec-out を使ってください。素のシェルサービスは端末を割り当て、それが改行のバイトを書き換えてデータを壊します。

adb shell のコマンドに root は必要ですか?

このリファレンスにあるものには不要です。すべて shell ユーザーとして動き、自分の Android ユーザー向けのパッケージ管理、ほとんどの dumpsys サービスの読み取り、設定プロバイダへの書き込み、入力の注入、共有ストレージの読み取りができます。root が必要なのはこのリファレンスがあえて避けていること、つまり他のアプリのプライベートデータの読み取り(debuggable なビルドに対する run-as を除く)、システムパーティションへの書き込み、/data/anr の直接読み取りです。

自分の端末では出力が違って見えるのはなぜ?

Android のバージョンか、メーカーのどちらかです。一部のフラグやフィールドは特定のリリースから入ったもので、それはコマンドごとに注記しています。残りはメーカーによる改変で、いちばん影響が大きいのは dumpsys です。ダンプはデバッグ出力で、そのテキストはサービスの作者が最後に印字した内容そのもの、しかもメーカーはそれを変えて自分の変更をバックポートします。フィールドは位置ではなく名前で読み、見慣れない形は失敗ではなく差分として扱ってください。

端末ではなくブラウザから実行できますか?

多くのコマンドは可能です。このサイトの Web ADB ツール群は、Chromium 系のデスクトップブラウザから WebUSB で端末と話し、SDK のインストールも不要、どこにもアップロードしません。各ページは、該当するツールがあればそこへリンクしています。知っておく価値のある制限が 2 つあります。ADB インターフェイスを保持できるプログラムは同時に 1 つだけなので、デスクトップの adb server は先に止める必要があります。そして adb forward と adb reverse はブラウザでは一切動きません。

打つより押したい場合は、Web ADB Toolkit がこの種のコマンドをブラウザから USB 経由で実行します。あるいは全コマンドを見る。