Input reader state:

• All of the expected input devices are present.

• Each input device is configured correctly. In particular, check that thetouch screen and joystick axes are correct.
  Input dispatcher state:

• All input events are processed as expected.

• After touching the touch screen and running dumpsys at the same time, theTouchStates line correctly identifies the window that you are touching.

adb shell dumpsys gfxinfo package-name

You can also include the framestats option to provide even more detailed frametiming information from recent frames, so that you can track down and debugproblems more accurately, shown below:

adb shell dumpsys gfxinfo package-name framestats

To learn more about using gfxinfo and to integrate UIperformance measurements into your testing practices, go to.

Inspect network diagnostics

Specifying the netstats service provides network usage statistics collected sincethe previous device booted up. To output additional information, such asdetailed unique user ID (UID) information, include the detail option, asfollows:

adb shell dumpsys netstats detail

The output varies depending on the version of Android running on the connecteddevice. The sections below describe the type of information you typically see.

Active interfaces and active UID interfaces

The following sample output lists the active interfaces and active UIDinterfaces of the connected device. In most cases, the information for activeinterfaces and active UID interfaces is the same.

Active interfaces:
  iface=wlan0 ident=[{type=WIFI, subType=COMBINED, networkId="Guest"}]
Active UID interfaces:
  iface=wlan0 ident=[{type=WIFI, subType=COMBINED, networkId="Guest"}]

The following is a sample output for the Dev statistics section:

Dev stats:
  Pending bytes: 1798112
  History since boot:
  ident=[{type=WIFI, subType=COMBINED, networkId="Guest", metered=false}] uid=-1 set=ALL tag=0x0
    NetworkStatsHistory: bucketDuration=3600
      st=1497891600 rb=1220280 rp=1573 tb=309870 tp=1271 op=0
      st=1497895200 rb=29733 rp=145 tb=85354 tp=185 op=0
      st=1497898800 rb=46784 rp=162 tb=42531 tp=192 op=0
      st=1497902400 rb=27570 rp=111 tb=35990 tp=121 op=0
Xt stats:
  Pending bytes: 1771782
  History since boot:
  ident=[{type=WIFI, subType=COMBINED, networkId="Guest", metered=false}] uid=-1 set=ALL tag=0x0
    NetworkStatsHistory: bucketDuration=3600
      st=1497891600 rb=1219598 rp=1557 tb=291628 tp=1255 op=0
      st=1497895200 rb=29623 rp=142 tb=82699 tp=182 op=0
      st=1497898800 rb=46684 rp=160 tb=39756 tp=191 op=0
      st=1497902400 rb=27528 rp=110 tb=34266 tp=120 op=0

UID stats

The following is a sample of detailed statistics of each UID.

UID stats:
  Pending bytes: 744
  Complete history:
  ident=[[type=MOBILE_SUPL, subType=COMBINED, subscriberId=311111...], [type=MOBILE, subType=COMBINED, subscriberId=311111...]] uid=10007  set=DEFAULT tag=0x0
    NetworkStatsHistory: bucketDuration=7200000
      bucketStart=1406167200000 activeTime=7200000 rxBytes=4666 rxPackets=7 txBytes=1597 txPackets=10 operations=0
  ident=[[type=WIFI, subType=COMBINED, networkId="MySSID"]] uid=10007  set=DEFAULT tag=0x0
    NetworkStatsHistory: bucketDuration=7200000
      bucketStart=1406138400000 activeTime=7200000 rxBytes=17086802 rxPackets=15387 txBytes=1214969 txPackets=8036 operations=28
      bucketStart=1406145600000 activeTime=7200000 rxBytes=2396424 rxPackets=2946 txBytes=464372 txPackets=2609 operations=70
      bucketStart=1406152800000 activeTime=7200000 rxBytes=200907 rxPackets=606 txBytes=187418 txPackets=739 operations=0
      bucketStart=1406160000000 activeTime=7200000 rxBytes=826017 rxPackets=1126 txBytes=267342 txPackets=1175 operations=35

To find the UID for your app, run this command: adb shell dumpsys
package your-package-name. Then look for the line labeleduserId.

For example, to find network usage for the app 'com.example.myapp', run thefollowing command:

adb shell dumpsys package com.example.myapp | grep userId

the output should be similar to the following:

    userId=10007 gids=[3003, 1028, 1015]

Using the sample dump above, look for lines that have uid=10007. Two suchlines exist—the first indicates a mobile connection and the second indicates aWi-Fi connection. Below each line, you can see the following information foreach two-hour window (which bucketDuration specifies in milliseconds):

• set=DEFAULT indicates foreground network usage, while set=BACKGROUND indicatesbackground usage. set=ALL implies both.
• tag=0x0 indicates the socket tag associated with the traffic.
• rxBytes and rxPackets represent received bytes and received packets in the corresponding time interval.
• txBytes and txPackets represent sent (transmitted) bytes and sent packets in the corresponding time interval.

Specifying the batterystats service generates interesting statistical dataabout battery usage on a device, organized by unique user ID (UID). To learn howto use dumpsys to test your app for Doze and App Standby, go toTesting with Doze and App Standby.

The command for batterystats is as follows:

To see a list of additional options available to batterystats, include the-h option. The example below outputs battery usage statistics for aspecified app package since the device was last charged:

adb shell dumpsys batterystats --charged package-name

The output typically includes the following:

• History of battery-related events
• Global statistics for the device
• Approximate power use per UID and system component
• Per-app mobile milliseconds per packet
• System UID aggregated statistics
• App UID aggregated statistics
  To learn more about using batterystats and generating an HTML visualization ofthe output, which makes it easier to understand and diagnose battery-relatedissues, read .

Inspecting machine-friendly output

You can generate batterystats output in machine-readable CSV format by usingthe following command:

adb shell dumpsys batterystats --checkin

9,0,i,vers,11,116,K,L
9,0,i,uid,1000,android
9,0,i,uid,1000,com.android.providers.settings
9,0,i,uid,1000,com.android.inputdevices
9,0,i,uid,1000,com.android.server.telecom
...
9,0,i,dsd,1820451,97,s-,p-
9,0,i,dsd,3517481,98,s-,p-
9,0,l,bt,0,8548446,1000983,8566645,1019182,1418672206045,8541652,994188
9,0,l,gn,0,0,666932,495312,0,0,2104,1444
9,0,l,m,6794,0,8548446,8548446,0,0,0,666932,495312,0,697728,0,0,0,5797,0,0
...

Battery-usage observations may be per-UID or system-level; data is selected forinclusion based on its usefulness in analyzing battery performance. Each rowrepresents an observation with the following elements:

• A dummy integer
• The user ID associated with the observation
• The aggregation mode:
  • "i" for information not tied to charged/uncharged status.
  • "l" for —charged (usage since last charge).
  • "u" for —unplugged (usage since last unplugged). Deprecated in Android 5.1.1.
• Section identifier, whichdetermines how to interpret subsequent values in the line.
  The table below describes the various section identifiers you may see:

Note: Prior to Android 6.0, power use forBluetooth radio, cellular radio, and Wi-Fi was tracked in the m (Misc)section category. In Android 6.0 and higher, power use for these components istracked in the pwi (Power Use Item) section with individual labels(wifi, blue, cell) for each component.

View memory allocations

You can inspect your app's memory usage in one of two ways: over a period oftime using procstats or at a particular snapshot in time using meminfo.The sections below show you how to use either method.

procstats makes it possible to see how your app is behaving over time—includinghow long it runs in the background and how much memory it uses during that time.It helps you quickly find inefficiencies and misbehaviors in your app, such asmemory leaks, that can affect how it performs, especially when running onlow-memory devices. Its state dump displays statistics about everyapplication’s runtime, proportional set size (PSS) and unique set size (USS).

To get application memory usage stats over the last three hours, inhuman-readable format, run the following command:

adb shell dumpsys procstats --hours 3

As can be seen in the example below, the output displays what percentageof time the application was running, and the PSS and USS asminPSS-avgPSS-maxPSS/minUSS-avgUSS-maxUSS over the number of samples.

AGGREGATED OVER LAST 3 HOURS:
  * com.android.systemui / u0a20 / v22:
           TOTAL: 100% (109MB-126MB-159MB/108MB-125MB-157MB over 18)
      Persistent: 100% (109MB-126MB-159MB/108MB-125MB-157MB over 18)
  * com.android.nfc / 1027 / v22:
           TOTAL: 100% (17MB-17MB-17MB/16MB-16MB-16MB over 18)
  * android.process.acore / u0a4 / v22:
           TOTAL: 100% (14MB-15MB-15MB/14MB-14MB-14MB over 20)
          Imp Fg: 100% (14MB-15MB-15MB/14MB-14MB-14MB over 20)
  ...
  * com.coulombtech / u0a106 / v26:
           TOTAL: 0.01%
        Receiver: 0.01%
        (Cached): 21% (4.9MB-5.0MB-5.2MB/3.8MB-3.9MB-4.1MB over 2)
  * com.softcoil.mms / u0a86 / v32:
           TOTAL: 0.01%
        (Cached): 0.25%
  * com.udemy.android / u0a91 / v38:
           TOTAL: 0.01%
        Receiver: 0.01%
        (Cached): 0.75% (9.8MB-9.8MB-9.8MB/8.5MB-8.5MB-8.5MB over 1)
  ...
Run time Stats:
  SOff/Norm: +32m52s226ms
  SOn /Norm: +2h10m8s364ms
       Mod : +17s930ms
      TOTAL: +2h43m18s520ms
 
Memory usage:
  Kernel : 265MB (38 samples)
  Native : 73MB (38 samples)
  Persist: 262MB (90 samples)
  Top    : 190MB (325 samples)
  ImpFg  : 204MB (569 samples)
  ImpBg  : 754KB (345 samples)
  Service: 93MB (1912 samples)
  Receivr: 227KB (1169 samples)
  Home   : 66MB (12 samples)
  LastAct: 30MB (255 samples)
  CchAct : 220MB (450 samples)
  CchCAct: 193MB (71 samples)
  CchEmty: 182MB (652 samples)
  Cached : 58MB (38 samples)
  Free   : 60MB (38 samples)
  TOTAL  : 1.9GB
  ServRst: 50KB (278 samples)
 
          Start time: 2015-04-08 13:44:18
  Total elapsed time: +2h43m18s521ms (partial) libart.so

meminfo

You can record a snapshot of how your app's memory isdivided between different types of RAM allocation with thefollowing command:

adb shell dumpsys meminfo package_name|pid [-d]

The -d flag prints more info related to Dalvik and ART memory usage.

The output lists all of your app's current allocations, measured in kilobytes.

When inspecting this information, you should be familiar with thefollowing types of allocation:

• Private (Clean and Dirty) RAM
• This is memory that is being used by only your process. This is the bulk of the RAM that thesystem can reclaim when your app’s process is destroyed. Generally, the most important portion of this is private dirty RAM, which is the most expensive because it is used by only yourprocess and its contents exist only in RAM so can’t be paged to storage (because Android does notuse swap). All Dalvik and native heap allocations you make will be private dirty RAM; Dalvik andnative allocations you share with the Zygote process are shared dirty RAM.
• Proportional Set Size (PSS)
• This is a measurement of your app’s RAM use that takes into account sharing pages acrossprocesses. Any RAM pages that are unique to your process directly contribute to its PSS value,while pages that are shared with other processes contribute to the PSS value only in proportion tothe amount of sharing. For example, a page that is shared between two processes will contributehalf of its size to the PSS of each process.
  A nice characteristic of the PSS measurement is that you can add up the PSS across all processesto determine the actual memory being used by all processes. This means PSS is a good measure for theactual RAM weight of a process and for comparison against the RAM use of other processes and thetotal available RAM.

For example, below is the output for Map’s process on a Nexus 5 device. There is a lot ofinformation here, but key points for discussion are listed below.

adb shell dumpsys meminfo com.google.android.apps.maps -d

Note: The information you see might vary slightly from what is shownhere, because some details of the output differ across platform versions.

** MEMINFO in pid 18227 [com.google.android.apps.maps] **
                   Pss  Private  Private  Swapped     Heap     Heap     Heap
                 Total    Dirty    Clean    Dirty     Size    Alloc     Free
                ------   ------   ------   ------   ------   ------   ------
  Native Heap    10468    10408        0        0    20480    14462     6017
  Dalvik Heap    34340    33816        0        0    62436    53883     8553
 Dalvik Other      972      972        0        0
        Stack     1144     1144        0        0
      Gfx dev    35300    35300        0        0
    Other dev        5        0        4        0
     .so mmap     1943      504      188        0
    .apk mmap      598        0      136        0
    .ttf mmap      134        0       68        0
    .dex mmap     3908        0     3904        0
    .oat mmap     1344        0       56        0
    .art mmap     2037     1784       28        0
   Other mmap       30        4        0        0
   EGL mtrack    73072    73072        0        0
    GL mtrack    51044    51044        0        0
      Unknown      185      184        0        0
        TOTAL   216524   208232     4384        0    82916    68345    14570
 
 Dalvik Details
        .Heap     6568     6568        0        0
         .LOS    24771    24404        0        0
          .GC      500      500        0        0
    .JITCache      428      428        0        0
      .Zygote     1093      936        0        0
   .NonMoving     1908     1908        0        0
 .IndirectRef       44       44        0        0
 
 Objects
               Views:       90         ViewRootImpl:        1
         AppContexts:        4           Activities:        1
              Assets:        2        AssetManagers:        2
       Local Binders:       21        Proxy Binders:       28
       Parcel memory:       18         Parcel count:       74
    Death Recipients:        2      OpenSSL Sockets:        2

Here is an older dumpsys on Dalvik of the gmail app:

** MEMINFO in pid 9953 [com.google.android.gm] **
                 Pss     Pss  Shared Private  Shared Private    Heap    Heap    Heap
               Total   Clean   Dirty   Dirty   Clean   Clean    Size   Alloc    Free
              ------  ------  ------  ------  ------  ------  ------  ------  ------
  Native Heap      0       0       0       0       0       0    7800    7637(6)  126
  Dalvik Heap   5110(3)    0    4136    4988(3)    0       0    9168    8958(6)  210
 Dalvik Other   2850       0    2684    2772       0       0
        Stack     36       0       8      36       0       0
       Cursor    136       0       0     136       0       0
       Ashmem     12       0      28       0       0       0
    Other dev    380       0      24     376       0       4
     .so mmap   5443(5) 1996    2584    2664(5) 5788    1996(5)
    .apk mmap    235      32       0       0    1252      32
    .ttf mmap     36      12       0       0      88      12
    .dex mmap   3019(5) 2148       0       0    8936    2148(5)
   Other mmap    107       0       8       8     324      68
      Unknown   6994(4)    0     252    6992(4)    0       0
        TOTAL  24358(1) 4188    9724   17972(2)16388    4260(2)16968   16595     336
 
 Objects
               Views:    426         ViewRootImpl:        3(8)
         AppContexts:      6(7)        Activities:        2(7)
              Assets:      2        AssetManagers:        2
       Local Binders:     64        Proxy Binders:       34
    Death Recipients:      0
     OpenSSL Sockets:      1
 
 SQL
         MEMORY_USED:   1739
  PAGECACHE_OVERFLOW:   1164          MALLOC_SIZE:       62

In general, be concerned with only the Pss Total and Private Dirtycolumns. In some cases, the Private Clean and Heap Alloc columns alsooffer interesting data. More information about the different memory allocations (the rows) youshould observe follows:

• Dalvik Heap
• The RAM used by Dalvik allocations in your app. The Pss Total includes all Zygoteallocations (weighted by their sharing across processes, as described in the PSS definition above).The Private Dirty number is the actual RAM committed to only your app’s heap, composedof your own allocations and any Zygote allocation pages that have been modified since forking yourapp’s process from Zygote.
  Note: On newer platform versions that have the Dalvik
Other section, the Pss Total and Private Dirty numbers for DalvikHeap do not include Dalvik overhead such as the just-in-time compilation (JIT) and GCbookkeeping, whereas older versions list it all combined under .

The Heap Alloc is the amount of memory that the Dalvik and native heap allocatorskeep track of for your app. This value is larger than Pss Total and Private
Dirty because your process was forked from Zygote and it includes allocations that yourprocess shares with all the others.

• .so mmap and .dex mmap
• The RAM being used for mapped .so (native) and .dex (Dalvik or ART)code. The Pss Total number includes platform code shared across apps; thePrivate Clean is your app’s own code. Generally, the actual mapped size will be muchlarger—the RAM here is only what currently needs to be in RAM for code that has been executed bythe app. However, the .so mmap has a large private dirty, which is due to fix-ups to the nativecode when it was loaded into its final address.
• .oat mmap
• This is the amount of RAM used by the code image which is based off of the preloaded classeswhich are commonly used by multiple apps. This image is shared across all apps and is unaffectedby particular apps.
• .art mmap
• This is the amount of RAM used by the heap image which is based off of the preloaded classeswhich are commonly used by multiple apps. This image is shared across all apps and is unaffectedby particular apps. Even though the ART image containsObject instances, it does not counttowards your heap size.
• .Heap (only with -d flag)
• This is the amount of heap memory for your app. This excludes objects in the image and largeobject spaces, but includes the zygote space and non-moving space.
• .LOS (only with -d flag)
• This is the amount of RAM used by the ART large object space. This includes zygote largeobjects. Large objects are all primitive array allocations larger than 12KB.
• .GC (only with -d flag)
• This is the overhead cost for garbage collection. There is not really anyway to reduce this overhead.
• .JITCache (only with -d flag)
• This is the amount of memory used by the JIT data and code caches. Typically, this is zerosince all of the apps will be compiled at installed time.
• .Zygote (only with -d flag)
• This is the amount of memory used by the zygote space. The zygote space is created duringdevice startup and is never allocated into.
• .NonMoving (only with -d flag)
• This is the amount of RAM used by the ART non-moving space. The non-moving space containsspecial non-movable objects such as fields and methods. You can reduce this section by using fewerfields and methods in your app.
• .IndirectRef (only with -d flag)
• This is the amount of RAM used by the ART indirect reference tables. Usually this amount issmall, but if it is too high, it might be possible to reduce it by reducing the number of local andglobal JNI references used.
• Unknown
• Any RAM pages that the system could not classify into one of the other more specific items.Currently, this contains mostly native allocations, which cannot be identified by the tool whencollecting this data due to Address Space Layout Randomization (ASLR). Like the Dalvik heap, thePss Total for Unknown takes into account sharing with Zygote, and Private
Dirtyis unknown RAM dedicated to only your app.
• TOTAL
• The total Proportional Set Size (PSS) RAM used by your process. This is the sum of all PSS fieldsabove it. It indicates the overall memory weight of your process, which can be directly comparedwith other processes and the total available RAM.
  The Private Dirty and Private Clean are the total allocations withinyour process, which are not shared with other processes. Together (especiallyPrivate Dirty), this is the amount of RAM that will be released back to the system whenyour process is destroyed. Dirty RAM is pages that have been modified and so must stay committed toRAM (because there is no swap); clean RAM is pages that have been mapped from a persistent file(such as code being executed) and so can be paged out if not used for a while.

• ViewRootImpl
• The number of root views that are active in your process. Each root view is associated with awindow, so this can help you identify memory leaks involving dialogs or other windows.

• AppContexts and Activities