Capture Android Allocation Tracker Data Programmatically for Memory Analysis

When optimizing Android app memory, developers need to identify which objects consume large amounts of memory and how they trigger garbage collection. This article introduces several methods for obtaining allocation information.

Allocation Tracker

Allocation Tracker is a built‑in feature of Android Studio. It can be enabled in the Memory Monitor. After starting tracking, the tool records object size, count, and stack trace, which can be dumped for analysis.

However, the UI‑based approach has drawbacks: the data is scattered with unrelated information, it requires manual start/stop, and dumping the data can freeze the device.

Triggering Allocation Tracker from Code

The process can be automated by invoking the same actions programmatically. By cloning the Android Studio source and inspecting

./tools/adt/idea/android/src/com/android/tools/idea/ddms/actions/ToggleAllocationTrackingAction.java

, we see how the IDE starts and stops the tracker.

The workflow involves an asynchronous request: after sending c.requestAllocationDetails, the IClientChangeListener callback notifies when the data is ready.

The involved interfaces ( Client, AndroidDebugBridge, IClientChangeListener) reside in the ddmlib library, which is open‑source and available on Maven.

Using ddmlib, the following steps can be performed:

Initialize AndroidDebugBridge and obtain the first connected IDevice.

Get the Client for the target process (e.g., com.example.ragnarok.allocrecordtest).

Register a callback that receives the allocation data and parses it with AllocationParser.

Start and stop the Allocation Tracker.

The callback yields a list of AllocationInfo objects containing size, type, thread, and stack information, enabling automated analysis without manual UI interaction.

How Dalvik Handles Allocation Tracker Requests (Dalvik only)

When the Dalvik VM receives an Allocation Tracker request, the packet is processed in DdmVmInternal. Two native methods, dvmEnableAllocTracker and dvmDisableAllocTracker, forward to

/dalvik/vm/native/org_apache_harmony_dalvik_ddmc_DdmVmInternal.cpp

, which ultimately calls functions in /dalvik/vm/AllocTracker.cpp.

Enabling the tracker allocates a new memory region referenced by gDvm.allocRecords. The global variable gDvm (defined in /dalvik/vm/Globals.h) holds fields such as allocRecordHead, allocRecordCount, and allocRecordMax (default 65536 on Android 4.4.4, configurable via dalvik.vm.allocTrackerMax).

Each object allocation then records its details into this region via dvmTrackAllocation (defined in /dalvik/vm/alloc/Alloc.cpp and /vm/AllocTracker.h).

The recorded data can be retrieved without dumping, avoiding the UI‑induced freeze.

Accessing Allocation Records Without Affecting Device Performance

Because gDvm is declared as extern, native code can obtain its address via dlsym and read allocRecords directly. A small native module packaged with an app can, after the tracker is enabled, read t_gDvm->allocRecords and print the allocation information.

This approach eliminates the need to stop the tracker and dump data, allowing frequent (e.g., every 10 seconds) reads with negligible impact on the device. However, compatibility varies: the layout of DvmGlobals differs across Dalvik versions, so the symbol may point to an incompatible structure on some devices, leading to null pointers or corrupted data. The method currently works on devices like MX3 with Android 4.4.4 (Flyme OS).

Notes

The analysis above covers only Dalvik; ART’s handling of Allocation Tracker is more complex and still under investigation.

The sample code referenced in this article is available on the author’s GitHub: https://github.com/ragnraok/AllocRecordDemo