Unveiling Android’s dumpsys meminfo: How It Works and Interpreting Its Output

A Part – Detailed Memory Information

The dumpsys meminfo binary located at /system/bin/dumpsys first obtains the ServiceManager, finds the meminfo service (implemented by MemBinder), and invokes its dump(int fd, const Vector<String16>& args) method to write memory statistics to the provided file descriptor.

A.1 Parsing /proc/<pid>/smaps

Each virtual memory area (VMA) of a process is represented as a node in a doubly‑linked list (head at task->mm->mmap). When the smaps file is read, the kernel walks this list, gathers usage statistics for each VMA, and outputs them.

Pss – Proportional Set Size, calculated as private memory plus shared memory divided by the number of mappings.

Private_Dirty – Pages that belong exclusively to the process and have been modified (dirty pages).

Private_Clean – Private pages that are clean (not dirty).

Swap – Typically zram‑compressed anonymous pages swapped out of RAM.

VMA names are matched against known patterns to classify memory (e.g., /dev/ashmem → Ashmem, *.so → Shared libraries, *.apk → APK resources). Anonymous VMA names start with anon: and may include allocator identifiers such as libc_malloc or dalvik-*. The kernel supports naming anonymous VMA areas via the prctl(PR_SET_VMA, PR_SET_VMA_ANON_NAME, …) system call.

A.2 IPC (binder & pipe) Data

Memory information is also obtained through inter‑process communication. The meminfo service opens a pipe, uses asynchronous binder calls to request data, and passes the pipe file descriptor to the Activity Manager Service (AMS), which then returns the requested statistics. mallinfo() – Returns allocation statistics from the underlying allocator (jemalloc or scudo). The wrapper Malloc() selects the appropriate implementation based on compile‑time flags.

#if defined(USE_SCUDO)
#include "scudo.h"
#define Malloc(function) scudo_##function
#else
#include "jemalloc.h"
#define Malloc(function) je_##function
#endif

The fields of struct mallinfo are mapped to meminfo entries, e.g., usmblks → Native Heap Size, uordblks → Native Heap Allocated, fordblks → Native Heap Free.

A.3 memtrack.vendor_xxx.so – GPU Memory

Vendor‑specific libraries expose GPU memory usage. For example, on Qualcomm SDM710 the library reads kernel GPU nodes and parses the data, reporting graphics‑related memory (GfxDev, EGL, GL) as part of the overall meminfo output.

B Part – Aggregated Summary

The second half of the meminfo output aggregates the detailed VMA data into high‑level categories:

Java Heap – Dalvik heap size, free, and allocated memory derived from runtime.totalMemory() and runtime.freeMemory().

Native Heap – Memory allocated via libc_malloc (native private dirty).

Code – Private dirty + clean pages from shared libraries, JARs, APKs, TTFs, DEX, and OAT files.

Stack – Private dirty pages belonging to the thread stacks.

Graphic – GPU‑related memory (GfxDev, EGL, GL) reported by the vendor library.

System – Shared system resources such as fonts and images (total PSS, private dirty, private clean).

By comparing the aggregated summary of two app versions, developers can pinpoint which category increased. In the example, version B shows a higher EGL allocation caused by unreleased hardware_bitmap objects, a new Android O feature.

These visual comparisons illustrate how the meminfo tool helps locate memory regressions and guide targeted optimizations.