How to Inspect Hardware Graphics Memory and DMA Buffers on Android Using ADB dumpsys memtrack

When auditing mobile application performance and debugging low-memory killer (LMK) events on Android, developers standardly rely on dumpsys meminfo to inspect Dalvik heap, native allocations, and anonymous mmap memory. However, mobile games, high-definition camera pipelines, and UI rendering frameworks allocate massive amounts of physical memory that never appear in standard user-space heap dumps. This memory is allocated directly through the kernel graphics drivers, ION memory allocators, DMA-BUF heaps, and hardware video codecs. To measure off-heap hardware allocations, inspect EGL/Vulkan surface consumption, and attribute GPU memory usage to individual process IDs, the Android Debug Bridge (ADB) exposes the dumpsys memtrack diagnostic service.

Understanding the Android Memtrack HAL Architecture

The Android operating system isolates hardware memory accounting within the Memtrack Hardware Abstraction Layer (HAL)—standardized in modern Android releases as android.hardware.memtrack-service:

• Memtrack HAL Daemon: A vendor-implemented AIDL daemon (developed by Qualcomm, MediaTek, ARM, or Samsung) that interfaces directly with proprietary kernel GPU drivers, GEM (Graphics Execution Manager) handles, and DMA-BUF memory frameworks.
• Memory Types Accounted:
  • GL / Vulkan Surfaces: Framebuffers, texture atlases, render targets, and swapchain image buffers allocated on behalf of processes.
  • GRAPHICS / Hardware Bitmaps: Hardware-accelerated Bitmap allocations uploaded directly into GPU memory via HardwareBuffer.
  • DMA-BUF and ION Heaps: Shared kernel memory buffers facilitating zero-copy camera frame streaming, neural processing unit (NPU) tensors, and hardware video decoding pipelines.
  • Kernel GPU Page Tables: Internal driver metadata structures maintained by the graphics hardware memory management unit (MMU).
• Process Attribution: Memtrack maps anonymous physical kernel pages back to the originating process PID, allowing framework accounting tools like ActivityManager to calculate accurate PSS (Proportional Set Size) metrics.

Querying Hardware Memory Diagnostics via ADB

To inspect real-time hardware graphics memory allocations, connect your target Android device with USB debugging enabled and execute:

adb shell dumpsys memtrack

The command queries the active Memtrack HAL provider and outputs memory accounting tables categorized by process PID. A representative output appears as follows:

Memtrack HAL Diagnostics:
  Active Provider: android.hardware.memtrack-service.default (AIDL)
  Tracking Mode: High Precision

  PID: 1042 (com.android.systemui)
    GL:         48256 KB
    GRAPHICS:   32100 KB
    OTHER:       4120 KB
    Total GPU:  84476 KB

  PID: 4192 (com.miHoYo.GenshinImpact)
    GL:        245760 KB
    GRAPHICS:  118240 KB
    OTHER:      12480 KB
    Total GPU: 376480 KB

  PID: 620 (surfaceflinger)
    GL:         18432 KB
    GRAPHICS:   65536 KB
    Total GPU:  83968 KB

Analyzing these categories reveals:

• GL: Total memory consumed by active OpenGL ES and Vulkan contexts, including shader binaries, uniform buffers, and vertex arrays.
• GRAPHICS: Total memory consumed by visible surface composition buffers, display layer swapchains, and android.graphics.Bitmap hardware backings.
• OTHER: Device-specific allocations, such as custom compute buffers, camera ISP pipelines, or DSP tensor memory.

Correlating memtrack Telemetry with dumpsys meminfo

The standard dumpsys meminfo command queries memtrack internally to populate its “EGL mtrack” and “GL mtrack” rows. By executing both commands, engineers can isolate whether an app’s memory spike originates from Dalvik object retention or unmanaged GPU texture caches:

# Query combined process memory metrics
adb shell dumpsys meminfo com.miHoYo.GenshinImpact

In the resulting table, observe the hardware memory breakdown:

                   Pss  Private  Private  SwapPss     Rss
                 Total    Dirty    Clean    Dirty   Total
                ------   ------   ------   ------  ------
  Native Heap   142512   142100        0        0  156200
  Dalvik Heap    24510    24100        0        0   29400
   EGL mtrack   245760   245760        0        0  245760
    GL mtrack   118240   118240        0        0  118240
TOTAL PSS:     531022 KB

Notice that the EGL mtrack and GL mtrack figures match the exact values reported by dumpsys memtrack. In this instance, hardware graphics buffers account for over 68% of the application’s overall RAM footprint.

Auditing DMA-BUF System-Wide Allocations

Modern Android kernels use the DMA-BUF framework for graphics sharing. To audit system-wide DMA-BUF allocations and identify which processes hold open file descriptors to large hardware buffers:

# Inspect DMA-BUF sysfs summary (requires root or userdebug)
adb shell cat /sys/kernel/debug/dma_buf/bufinfo 2>/dev/null || adb shell cat /proc/dma_buf/bufinfo

This command lists buffer sizes, exporter names (e.g., qcom,kgsl-3d0 or mali0), and attached client processes.

Diagnosing Low-Memory Killer (LMK) Triggers

When an application’s combined PSS (including memtrack allocations) causes system memory pressure to cross LMK watermarks, Android’s kernel daemon terminates background processes. If an app fails to recycle large Bitmap instances or leaks Vulkan swapchain textures, dumpsys memtrack will show continuously climbing memory values even when Java heap garbage collection runs cleanly.

Automate memory monitoring during continuous gameplay or video streaming sessions using a shell loop:

# Monitor GPU memory consumption every 5 seconds
while true; do
  adb shell dumpsys memtrack | grep -A 4 "PID: $(adb shell pidof com.example.renderingapp)"
  sleep 5
done

By leveraging dumpsys memtrack, Android developers and performance engineers gain direct visibility into hardware graphics allocations, unmasking hidden GPU memory leaks and ensuring optimal stability across high-performance mobile workloads.