Android Unplugged | Quality Tools for Developers

Heap Dumping Explained — Why LeakCanary Freezes Your App to Find the Truth Learn what a heap dump is, when LeakCanary triggers one, why it briefly pauses your app, and how the resulting .hprof snapshot enables Shark to find real Android memory leaks. In the previous part of this series, we explored ObjectWatcher , the component that keeps an eye on destroyed Activities, Fragments, Views, and custom objects. But ObjectWatcher does not prove a leak on its own. It only tells LeakCanary that some objects still look suspiciously alive after they should have been garbage collected. That is the moment when LeakCanary makes its boldest move: it captures a heap dump . Heap dumping is the turning point in LeakCanary’s workflow. It briefly freezes the app, records a binary snapshot of memory, writes that snapshot to disk as a .hprof file, and passes it to Shark for analysis. [page:1] Table of Contents 1. What Is a Heap Dump? ...

Shark Heap Analysis — How LeakCanary Turns Heap Dumps into Actionable Leak Traces Learn how Shark parses Android heap dumps, builds a HeapGraph, traces GC-root paths, filters known leaks, and generates actionable LeakCanary reports. In the previous article, we saw how LeakCanary freezes the app briefly to capture a .hprof heap dump. But a heap dump on its own is only raw binary data. To make it useful, LeakCanary needs an analysis engine that can parse memory records, reconstruct object relationships, and explain why retained objects are still alive. That analysis engine is Shark . Shark is where memory leak debugging becomes understandable. It transforms a raw heap snapshot into a structured object graph, finds the most relevant retaining paths, and produces the LeakTrace reports developers use to fix leaks. Table of Contents 1. What Is Shark? 2. Why Shark Matters 3. Parsing the Heap Dump 4. Building t...

Dominator Tree and Retained Size — Measuring the True Cost of Android Memory Leaks Learn how Shark uses dominator trees and retained size to measure leak impact, prioritize fixes, and explain the real cost of retained objects in Android apps. In the previous part of this series, we saw how Shark parses heap dumps and generates leak traces. But one important question still remains: which leaks should you fix first? Not all memory leaks are equally dangerous. A destroyed Activity retaining an entire view hierarchy can be far more expensive than a small isolated object. That is why Shark uses dominator trees and retained size to estimate impact, not just existence. Table of Contents 1. Why Not All Leaks Are Equal 2. What Is a Dominator Tree? 3. What Is Retained Size? 4. How Shark Uses Dominator Trees 5. Example: Leaking Activity with Retained Size 6. Why This Matters in Real Apps 7. Analyze LeakCanary...

LeakCanary Internals: The Complete Guide for Android Engineers A canonical guide to Android memory leak debugging with LeakCanary, ObjectWatcher, heap dumps, Shark, retained size, CI/CD, reporting, and modern prevention workflows. Memory leaks are one of the most deceptive classes of Android bugs. They rarely fail fast, they often hide behind otherwise “working” features, and they slowly degrade user experience through extra garbage collection, UI jank, battery drain, and eventual crashes. The danger is not just that memory is retained — it is that the cost compounds quietly until the app becomes unstable. That is why LeakCanary remains one of the most important tools in Android performance engineering. But to use it well, it is not enough to treat it like a black-box library that throws notifications. The real leverage comes from understanding how it works internally: how objects are watched, when heap dumps are triggered, how Shark reconstr...

   Kotlin/Coroutines 41. CoroutineScope — Types, Usage, and Architectural Pitfalls What is a CoroutineScope (Architect View)? A CoroutineScope defines the lifetime of coroutines .  It answers one critical question : When should this coroutine be cancelled? If you get scopes wrong, you get: memory leaks crashes after configuration change background work running forever UI updates after destruction Scope choice = lifecycle correctness. Core Principle (Must Say in Interview) Never launch a coroutine without knowing who cancels it. Built-in Coroutine Scopes in Android 1. viewModelScope Lifecycle:  ✔ Active while ViewModel exists  ✖ Cancelled when ViewModel.onCleared() is called Threading: Default dispatcher: Dispatchers.Main.immediate Primary Use Case: Business logic Network calls Database operations State management Why it exists:  ViewModels survive configuration changes. If you used lifecycleScope , your network calls would restart on rotation. When to Use...