How to Inspect Pinned Application Files and System Memory Locks on Android Using ADB dumpsys pinner

The Android operating system manages volatile memory aggressively through the low-memory killer daemon (lmkd) and page frame eviction mechanisms. Under heavy multitasking or high memory pressure, cached application processes and background framework files are purged from physical RAM to make room for foreground tasks. However, certain system services, runtime jars, framework binaries, and essential application resources are so critical to perceived system responsiveness that evicting them would trigger severe UI stutter and long app cold-start latencies.

To prevent eviction of these critical assets, the Android system server runs the PinnerService. This service locks designated executable files, shared libraries, and application packages directly into resident RAM using the kernel mlock() system call. Using Android Debug Bridge (ADB), system engineers and developers can query dumpsys pinner to inspect locked files, analyse memory consumption footprints, and monitor kernel pinning states.

Understanding PinnerService Architecture in Android

The Android PinnerService initializes during early system server boot. It parses device configuration overlays defined in frameworks/base/core/res/res/values/config.xml (specifically config_defaultPinnerServiceFiles) and queries dynamic device properties to determine which assets must remain pinned in memory.

Typically, the pinned assets include:

• Core Android Framework Binaries: Core runtime bytecode such as /system/framework/framework.jar and /system/framework/services.jar.
• System UI & Default Launcher: Bytecode and assets for com.android.systemui and OEM launcher applications to ensure instant task switching and smooth notification shade pulldowns.
• Camera Services: Camera application packages and hardware abstraction binaries to enable zero-lag camera launching from the lock screen.
• Pre-compiled Odex and Oat Files: Ahead-Of-Time (AOT) compiled native code to eliminate JIT compilation overhead during critical user interactions.

Connecting via ADB and Executing dumpsys pinner

Ensure your Android device has Developer Options and USB Debugging enabled, connect it to your workstation via USB or wireless debugging, and confirm connectivity in a terminal session:

adb devices -l

To inspect the complete status of the Pinner Service, execute the following command:

adb shell dumpsys pinner

A typical diagnostic output displays the list of currently pinned files, memory ranges, and exact byte counts locked into physical memory:

Pinned Files:
  /system/framework/framework.jar: 16777216 bytes pinned
  /system/framework/services.jar: 8388608 bytes pinned
  /system/framework/arm64/boot-framework.oat: 33554432 bytes pinned
  /system/priv-app/SystemUI/SystemUI.apk: 12582912 bytes pinned
  /system/priv-app/NexusLauncherRelease/NexusLauncherRelease.apk: 10485760 bytes pinned
Total bytes pinned: 81788928 (78.0 MB)

Analysing Pinned Assets and Memory Allocation Footprints

The summary metric Total bytes pinned indicates the exact physical RAM footprint reserved exclusively for pinned assets. Because these memory pages are locked with mlock(), the Linux kernel virtual memory subsystem cannot reclaim them under any circumstances, even when available free memory drops below the low watermark.

To verify the kernel-level impact of these locked pages, inspect the system-wide memory metrics using /proc/meminfo:

adb shell grep -i "mlock" /proc/meminfo

The Mlocked field in /proc/meminfo directly correlates with the total pinned byte count reported by dumpsys pinner:

Mlocked:           80128 kB

If the device has OEM camera pinning configured, you can inspect whether camera binaries are pinned dynamically upon camera activity or statically pinned at boot:

adb shell dumpsys pinner | grep -i "camera"

Monitoring Dynamic App Pinning and Device Configurations

Modern Android versions allow dynamic pinning of the active camera app or home app based on user activity or device state. When an application is launched or switched, the PinnerService can unpin the previous instance and lock the newly active app.

To inspect the device configuration overlay values governing pinning behaviour, query the global device settings and build properties:

# Check system properties related to pinner service
adb shell getprop | grep -i "pinner"

# Inspect device config flags for runtime memory pinning
adb shell cmd device_config get runtime_native_boot pin_camera

You can also check whether camera pinning is enabled in the runtime configuration:

adb shell cmd device_config get runtime_native_boot pin_camera_qualcomm

Correlating Pinner Memory Locks with Process Dumps

To understand how pinned framework files affect individual processes, cross-reference the output of dumpsys pinner with process memory usage reported by dumpsys meminfo.

For example, inspect memory usage for the System UI process:

adb shell dumpsys meminfo com.android.systemui

Look for the .apk mmap and .jar mmap sections within the proportional set size (PSS) and private dirty metrics. Pinned memory files show as clean memory maps that remain guaranteed in resident memory (RSS) without page thrashing.

To observe memory stress behaviour while keeping pinned assets locked, simulate memory pressure using the am send-trim-memory command:

# Send TRIM_MEMORY_COMPLETE to background apps
adb shell am send-trim-memory com.android.systemui COMPLETE

# Verify that pinned files remain locked after memory trim
adb shell dumpsys pinner

Troubleshooting PinnerService Anomalies

When debugging high memory consumption on entry-level Android devices or custom ROM builds, evaluate these diagnostic steps:

• Excessive Mlocked Memory: If Total bytes pinned exceeds 200 MB on a 3 GB or 4 GB RAM device, foreground apps will experience aggressive background app killing. Review OEM configuration overlays in config_defaultPinnerServiceFiles to remove non-essential APKs.
• Unpinning Failures on App Updates: If a pinned system app is updated via the Play Store, the updated APK is stored in /data/app/ while the original base APK remains in /system/priv-app/. The PinnerService must unpin the outdated system file to prevent duplicate RAM reservation. Verify updated pinning paths:

  adb shell dumpsys pinner | grep -E "data/app|system/priv-app"

• Service Unresponsive: If dumpsys pinner returns an empty response or timed-out error, confirm the system_server is operating normally and inspect logcat for PinnerService exceptions:

  adb logcat -d -s PinnerService:*