How to Inspect Media Codec Instances and Memory Limits on Android Using ADB dumpsys media.resource_manager

Modern Android multimedia applications—ranging from video streaming platforms and camera capture pipelines to video conferencing and real-time gaming—rely heavily on hardware-accelerated video codecs (such as AVC/H.264, HEVC/H.265, VP9, and AV1). However, mobile hardware silicon (such as Qualcomm Snapdragon, MediaTek Dimensity, and Google Tensor) provides a strictly finite number of concurrent hardware codec instances and dedicated Video Processing Unit (VPU) memory buffers.

When multiple applications simultaneously request 4K decoders, Picture-in-Picture (PiP) players, background camera recorders, or high-framerate previews, the system risks hardware codec exhaustion. If an app attempts to instantiate a codec when all hardware slots are saturated, the system must either dynamically reclaim resources from lower-priority background processes or fail with an InsufficientResourcesException. To monitor codec allocations, process reclaim priorities, and hardware memory consumption, Android provides dumpsys media.resource_manager via the Android Debug Bridge (ADB).

Architecture of the Android Media Resource Manager

The Media Resource Manager Service (ResourceManagerService) is a native Android system daemon that coordinates hardware media resources across client applications. Its primary architectural responsibilities include:

• Resource Tracking: Monitors active MediaCodec (hardware and software), MediaExtractor, and DRM cryptographic session allocations across every process ID (PID).
• Reclaim Arbitration: When hardware codec capacity is reached and a high-priority foreground application requests a new codec instance, the Resource Manager evaluates running processes by their Out-Of-Memory (OOM) adjustment scores (oom_adj) and reclaims (force-closes) codecs from lower-priority background processes.
• Capacity Enforcement: Ensures that total simultaneous video instances do not exceed the SoC’s thermal and hardware buffer limits.

Querying media.resource_manager via ADB exposes real-time tracking tables, active process hierarchies, and reclamation histories.

Querying the Resource Manager via ADB

To inspect active codec allocations and client sessions, connect your target Android smartphone, tablet, or emulator with USB debugging enabled.

Open a terminal prompt and execute:

adb shell dumpsys media.resource_manager

This command queries the media.resource_manager service registered with the Android Service Manager and outputs a structured diagnostic report.

To inspect only active video decoding and encoding allocations while running a streaming application (such as YouTube, VLC, or a custom app), filter the output:

adb shell dumpsys media.resource_manager | grep -E "pid|codec|MediaCodec"

Analysing Active Codec Instances and Process Tracking

The output of dumpsys media.resource_manager structures active clients by Process ID (PID) and resource type. A representative snippet appears as follows:

Resource Manager:
  Processes:
    PID: 10452 (Client: com.example.videoplayer)
      Priority: 100 (Foreground)
      Resources:
        Type: MediaCodec, SubType: VideoCodec, ID: 1, Value: 1
        Type: GraphicMemory, ID: 0, Value: 33177600
    PID: 8412 (Client: com.android.camera2)
      Priority: 200 (Visible)
      Resources:
        Type: MediaCodec, SubType: SecureVideoCodec, ID: 2, Value: 1

Key data fields to evaluate include:

• PID and Client: Identifies the application process holding the allocated media resource.
• Priority: The priority assigned by the Activity Manager service. Lower numbers represent higher priority (e.g. active foreground activities hold priority scores near 100, while cached background processes score 900+).
• Resources / SubType: Differentiates standard video codecs (VideoCodec), hardware-secure DRM decoders (SecureVideoCodec), and audio decoders.
• GraphicMemory: The byte footprint of allocated hardware graphics buffers associated with video frames. Large values indicate unreleased frame queues or high-resolution 4K/8K frame buffers.

Inspecting Codec Reclamation Events and Process Evictions

When hardware codec saturation occurs, the Resource Manager logs reclamation actions inside the diagnostic dump. Look for the Reclaim History section:

Reclaim History:
  Reclaimed codec from PID 6120 (com.example.backgroundplayer) for PID 10452 (com.example.videoplayer) at 2026-11-08 05:22:14

If your application experiences sudden video playback terminations or receives MediaCodec.CodecException.ERROR_RECLAIMED, check this history table. It reveals whether your app’s background codec was preempted by another application requesting foreground media resources.

Diagnosing Codec Starvation and Media Leakage

A frequent bug in Android media development is failing to explicitly call codec.release() or player.release() during the onPause() or onStop() lifecycle events of an Activity.

To detect codec leaks:

1. Launch your application and initiate video playback.
2. Check the active codec count in dumpsys media.resource_manager:

   adb shell dumpsys media.resource_manager | grep "MediaCodec" | wc -l

3. Navigate away from the application or rotate the screen several times (triggering Activity recreation).
4. Check the codec count again. If the number of allocated codecs increases on each screen rotation or lifecycle transition without returning to zero, your application is leaking unreleased MediaCodec instances, which will eventually crash the process or starve other system apps.

Optimising Multimedia Applications for Resource Management

To ensure resilience against hardware codec starvation, implement Android media best practices:

• Release in Lifecycle Hooks: Always release media decoders in onStop() or onDestroy():

  override fun onStop() {
      super.onStop()
      mediaPlayer?.release()
      mediaPlayer = null
  }

• Handle Codec Reclaim Gracefully: Implement MediaCodec.Callback.onError() and test whether the exception is transient or indicates resource eviction. When evicted, store the current playback position and re-instantiate the player when the user returns to the foreground.
• Fallback to Software Codecs: If hardware decoders are fully occupied by critical system tasks, configure your player engine (such as ExoPlayer / Media3) to fall back to software decoders (like Google’s built-in software AV1 or VP9 codecs) to maintain continuous playback.