Analyzing and Resolving Java OutOfMemoryError in Android Apps Using LeakCanary and Eagle

During development and testing, Android applications may throw OutOfMemoryError when the Java heap is exhausted, leading to forced heap reclamation and abrupt app termination. The root causes are typically either memory leaks—objects that are dead but not reclaimed—or genuine heap overflow where all objects must stay alive.

The article introduces two open‑source tools for diagnosing these issues: LeakCanary , a library that monitors objects via RefWatcher.watch() , and Eagle , a custom Eclipse Memory Analyzer (MAT) plugin that compares heap snapshots before and after a leak.

LeakCanary workflow includes creating a KeyedWeakReference , checking references on a background thread, dumping the heap to an .hprof file if the reference persists, analyzing the dump with HeapAnalyzer , locating the shortest strong reference path to GC roots, and displaying the leak chain in the app.

Eagle installation steps: uninstall any existing MAT plugin, install the modified MAT plugin, add the Eagle .jar to Eclipse’s dropins folder, restart Eclipse, and verify the Eagle menu and its Compare and Bitmap sub‑menus.

Manual leak detection involves reproducing the memory issue, capturing an initial .hprof snapshot, capturing a second snapshot when the leak is severe, using Eagle’s Compare function to sort retained heap objects, locating the shortest GC‑root path, and fixing the offending code.

The article recommends the automatic approach with LeakCanary, showing a screenshot of LeakCanary’s detection output, then using Eagle to further analyze the problem: capture start.hprof and end.hprof , run the Compare operation, filter by class name, and examine the resulting table.

An example case demonstrates that an activity’s Context was held instead of applicationContext , causing a leak; after replacing the reference, the leak disappears, as shown by before‑and‑after screenshots.