What's the Android Adb Shell "Dumpsys" Tool and What Are Its Benefits

What's the Android ADB shell dumpsys tool and what are its benefits?

What's dumpsys and what are its benefit

dumpsys is an android tool that runs on the device and dumps interesting information about the status of system services.

Obvious benefits:

1. Possibility to easily get system information in a simple string representation.
2. Possibility to use dumped CPU, RAM, Battery, storage stats for a
   pretty charts, which will allow you to check how your application
   affects the overall device!

What information can we retrieve from dumpsys shell command and how we can use it

If you run dumpsys you would see a ton of system information. But you can use only separate parts of this big dump.

to see all of the "subcommands" of dumpsys do:

dumpsys | grep "DUMP OF SERVICE"

Output:

DUMP OF SERVICE SurfaceFlinger:
DUMP OF SERVICE accessibility:
DUMP OF SERVICE account:
DUMP OF SERVICE activity:
DUMP OF SERVICE alarm:
DUMP OF SERVICE appwidget:
DUMP OF SERVICE audio:
DUMP OF SERVICE backup:
DUMP OF SERVICE battery:
DUMP OF SERVICE batteryinfo:
DUMP OF SERVICE clipboard:
DUMP OF SERVICE connectivity:
DUMP OF SERVICE content:
DUMP OF SERVICE cpuinfo:
DUMP OF SERVICE device_policy:
DUMP OF SERVICE devicestoragemonitor:
DUMP OF SERVICE diskstats:
DUMP OF SERVICE dropbox:
DUMP OF SERVICE entropy:
DUMP OF SERVICE hardware:
DUMP OF SERVICE input_method:
DUMP OF SERVICE iphonesubinfo:
DUMP OF SERVICE isms:
DUMP OF SERVICE location:
DUMP OF SERVICE media.audio_flinger:
DUMP OF SERVICE media.audio_policy:
DUMP OF SERVICE media.player:
DUMP OF SERVICE meminfo:
DUMP OF SERVICE mount:
DUMP OF SERVICE netstat:
DUMP OF SERVICE network_management:
DUMP OF SERVICE notification:
DUMP OF SERVICE package:
DUMP OF SERVICE permission:
DUMP OF SERVICE phone:
DUMP OF SERVICE power:
DUMP OF SERVICE reboot:
DUMP OF SERVICE screenshot:
DUMP OF SERVICE search:
DUMP OF SERVICE sensor:
DUMP OF SERVICE simphonebook:
DUMP OF SERVICE statusbar:
DUMP OF SERVICE telephony.registry:
DUMP OF SERVICE throttle:
DUMP OF SERVICE usagestats:
DUMP OF SERVICE vibrator:
DUMP OF SERVICE wallpaper:
DUMP OF SERVICE wifi:
DUMP OF SERVICE window:

Some Dumping examples and output

1) Getting all possible battery statistic:

$~ adb shell dumpsys battery

You will get output:

Current Battery Service state:
AC powered: false
AC capacity: 500000
USB powered: true
status: 5
health: 2
present: true
level: 100
scale: 100
voltage:4201
temperature: 271 <---------- Battery temperature! %)
technology: Li-poly <---------- Battery technology! %)

2)Getting wifi informations

~$ adb shell dumpsys wifi

Output:

Wi-Fi is enabled
Stay-awake conditions: 3

Internal state:
interface tiwlan0 runState=Running
SSID: XXXXXXX BSSID: xx:xx:xx:xx:xx:xx, MAC: xx:xx:xx:xx:xx:xx, Supplicant state: COMPLETED, RSSI: -60, Link speed: 54, Net ID: 2, security: 0, idStr: null
ipaddr 192.168.1.xxx gateway 192.168.x.x netmask 255.255.255.0 dns1 192.168.x.x dns2 8.8.8.8 DHCP server 192.168.x.x lease 604800 seconds
haveIpAddress=true, obtainingIpAddress=false, scanModeActive=false
lastSignalLevel=2, explicitlyDisabled=false

Latest scan results:

Locks acquired: 28 full, 0 scan
Locks released: 28 full, 0 scan

Locks held:

3) Getting CPU info

~$ adb shell dumpsys cpuinfo

Output:

Load: 0.08 / 0.4 / 0.64
CPU usage from 42816ms to 34683ms ago:
system_server: 1% = 1% user + 0% kernel / faults: 16 minor
kdebuglog.sh: 0% = 0% user + 0% kernel / faults: 160 minor
tiwlan_wq: 0% = 0% user + 0% kernel
usb_mass_storag: 0% = 0% user + 0% kernel
pvr_workqueue: 0% = 0% user + 0% kernel
+sleep: 0% = 0% user + 0% kernel
+sleep: 0% = 0% user + 0% kernel
TOTAL: 6% = 1% user + 3% kernel + 0% irq

4)Getting memory usage informations

~$ adb shell dumpsys meminfo 'your apps package name'

Output:

** MEMINFO in pid 5527 [com.sec.android.widgetapp.weatherclock] **
                    native   dalvik    other    total
            size:     2868     5767      N/A     8635
       allocated:     2861     2891      N/A     5752
            free:        6     2876      N/A     2882
           (Pss):      532       80     2479     3091
  (shared dirty):      932     2004     6060     8996
    (priv dirty):      512       36     1872     2420

 Objects
           Views:        0        ViewRoots:        0
     AppContexts:        0       Activities:        0
          Assets:        3    AssetManagers:        3
   Local Binders:        2    Proxy Binders:        8
Death Recipients:        0
 OpenSSL Sockets:        0

 SQL
               heap:        0         MEMORY_USED:        0
 PAGECACHE_OVERFLOW:        0         MALLOC_SIZE:        0

If you want see the info for all processes, use ~$ adb shell dumpsys meminfo

dumpsys is ultimately flexible and useful tool!

If you want to use this tool do not forget to add permission into your android manifest automatically android.permission.DUMP

Try to test all commands to learn more about dumpsys. Happy dumping!

android dumpsys batteryinfo vs android dumpsys batterystats

If you take a look at the source code for dumpsys, you can see that it simply requests a instance of the service from the default service manager and then calls the service dump() method (which is an interface of IBinder) passing STDOUT and the command line args:

sp<IServiceManager> sm = defaultServiceManager();
...
sp<IBinder> service = sm->checkService(services[i]);
...
int err = service->dump(STDOUT_FILENO, args); 

In your example above, the service in question would appear to have been renamed from batteryinfo to batterystats

Is there a generalized man page or documentation for the Android `adb shell dumpsys [service]` command?

I was looking for the very same, without much luck. But I found a bunch of pieces which I'll glue together in an answer here – without the claim of completeness or „absolute correctness“: I'm not an Android dev, just an enthusiast (power) user. Find my sources at the end (Footnotes) and referred to from the snippets. I will go by the output of dumpsys backup and comment what I found.

---

BackupManager Status

Backup Manager is enabled / provisioned / not pending init
Auto-restore is enabled
Last backup pass started: 0 (now = 1575271089047)
  next scheduled: 1575281388106

This part should be rather clear. One can use bmgr enable 0|1 to (de)activate backup manager. When deactivated, no backups are taking place (unless triggered via adb backup). Values in lines 3+4 are Unix timestamps, with the exception of the 0 which simply means no backup has been taken yet at all.

Transports

Transport whitelist:
    android/com.android.internal.backup.LocalTransportService
    com.google.android.gms/.backup.component.D2dTransportService
    com.google.android.gms/.backup.BackupTransportService

These are system whitelisted transports ([2]) – though the source does not explain what this means. They seem to correspond to the „available transports“ from the next block.

Available transports:
    android/com.android.internal.backup.LocalTransport
       destination: Backing up to debug-only private cache
       intent: null
  * com.google.android.gms/.backup.BackupTransportService
       destination: *****@gmail.com
       intent: Intent { cmp=com.google.android.gms/.backup.SetBackupAccountActivity }
       @pm@ - 3794 state bytes
       com.google.android.dialer - 124 state bytes
       com.google.android.videos - 72 state bytes
       com.android.providers.settings - 76 state bytes
       ...

List of transports available for backups. Google cloud's BackupTransportService is default (marked by the *), but requires an account set up on the device([1]) (as does the device-to-device transport D2dTransportService it seems to me). As I understand, one can change the default using bmgr transport <transportName> – and run a backup using bmgr run (for all pending backups to default transport?).

Note that this list corresponds to the output of bmgr list transports. Local backups (LocalTransport) seems to be what gets triggered by adb backup.

Tokens

Pending init: 0
Ancestral: 0
Current:   39b423cbcb6862e5

Quoting from source [5]:

To look up backup tokens, run adb shell dumpsys backup. The token is the hexidecimal string following the labels Ancestral: and Current:.
The ancestral token refers to the backup dataset that was used to restore the device when it was initially setup (with the device-setup wizard). The current token refers to the device's current backup dataset (the dataset that the device is currently sending its backup data to).

This should also explain what „Ancestral packages“ (further down in the output) means.

Applications that can request backup

Participants:
  uid: 1000
    com.android.providers.settings
    android
  uid: 1027
    com.android.nfc
  uid: 10004
    com.android.providers.userdictionary
    com.android.providers.blockednumber
    com.android.calllogbackup
  ...

Participants are applications that can request backup, sorted by AID. ([1])

Backup statistics

Ancestral packages: none

For Ancestral packages, please also see above. I don't know how this would look if there were any (but I assume similar to ever backed up below); I myself run my Android devices „Google free“ (LineageOS, no Google Apps) and thus never used this part. Some more notes on these: they seem to come from a backup set that wasn't created on the same device (or at least not from the same „iteration“, i.e. if they came from the same physical device, it was since factory-reset). In line 481 of the [2] source code we find the note:

The ancestral work profile corresponds to the profile that was used to restore to the callers profile.

Further, in the [3] BackupManager reference:

The ancestral serial number will have a corresponding UserHandle if the device has a work profile that was restored from another work profile with serial number ancestralSerialNumber.

Finally, in the [4] backup guide:

During the initial device setup wizard, the user is shown a list of available backup datasets and is asked which one to restore the data from. Whichever backup dataset is selected becomes the ancestral dataset for the device. The device can restore from either its own backups or the ancestral dataset. The device prioritize its own backup if backups from both sources are available. If the user didn't go through the device setup wizard, then the device can restore only from its own backups.

Ever backed up: 66
    com.android.cellbroadcastreceiver
    com.allrecipes.spinner.free
    com.google.android.youtube
    ...

This seems pretty much self-explaining: the number and the list of apps that are already part of a backup set.

Pending key/value backup: 47
    BackupRequest{pkg=com.google.android.dialer}
    BackupRequest{pkg=com.google.android.videos}
    BackupRequest{pkg=com.android.cellbroadcastreceiver}
    ...

I found no reference on this, but a good guess from the above is these are „Participants“ having requested a backup, and their requests have not yet been processed.

Full backup queue:68
    0 : com.jb.gokeyboard.langpack.ja
    0 : com.Splitwise.SplitwiseMobile
    1575154802432 : com.google.android.gsf.login
    1575156372751 : com.google.android.backuptransport
    1575159051168 : com.google.android.ext.services
    ...

On this [1] comments it is a list of Last backup : package name (with Last backup most likely again being a Unix timestamp or 0 when it was never backed up yet). On device, the backup queue is located on-device in /data/backup.

---

I hope I was able to shed some light, and above information is useful to you (and others). You might find out more details going by the sources mentioned below – especially when scanning the source code ([2]), I might have missed some.

Sources

1. Android Internals::A Confectioner's Cookbook - WikiLeaks by Jonathan Levin. The relevant part is available as an excerpt: Application Backup & Restore; find details on the book's website
2. Source code for BackupManagerService.java
3. BackupManager Reference Manual
4. Developer's guide on auto-backup
5. Developer's guide on backup testing

android dumpsys permission denial

Why does android OS still deny me access to the dump service ?

Because that permission is flagged as android:protectionLevel="signature|system|development" (or signatureOrSystem using the old syntax) on Android 2.3+, and therefore cannot be held by ordinary Android SDK applications.

---

Related Topics