Android Studio Memory Profiler: Heap Dump Depth and GC Root Identification

When utilizing the Memory Profiler in Android Studio to diagnose potential memory leaks, the "Capture Heap Dump" feature provides a detailed view of all objects currently residing in the heap. A common objective is to identify why specific Activity or Context instances persist after they should have been destroyed.

While the profiler displays the "Depth" metric and the path to the GC root, there is often ambiguity regarding how the profiler distinguishes between a legitimate long-lived reference and a leak caused by an accidental static reference or an inner class holding onto a context.

Given the overhead associated with heap dumps and the potential for the observer effect in debug builds, what are the specific criteria used by the profiler to determine the shortest path to a GC root? How can a developer verify if a reported path is a primary leak source versus a secondary reference in a complex object graph?