Android Unplugged

  Introduction So far, we’ve explored how LeakCanary detects leaks, analyzes heap dumps with Shark, and categorizes them. But in real teams, leaks often slip through because developers only check them locally. The next step is automation : integrating LeakCanary into your CI/CD pipeline so leaks are caught before release. This transforms LeakCanary from a developer tool into a team safeguard . 🛠️ Configuring LeakCanary for CI LeakCanary is designed for debug builds , but you can configure it to export leak reports for CI. Gradle Setup dependencies { debugImplementation "com.squareup.leakcanary:leakcanary-android:2.12" } Exporting Leak Reports LeakCanary stores reports in: /storage/emulated/0/Download/leakcanary/ You can configure CI to collect these reports after instrumentation tests. 🧑‍💻 Example: CI Script # Run instrumentation tests ./gradlew connectedDebugAndroidTest # Collect LeakCanary reports adb pull /storage/emulated/0/Download/leakcanary ./ci-reports/leaks ...

  Introduction LeakCanary doesn’t just detect leaks — it reports them in a way that developers can act on. But the real power lies in how you, as an engineer and advocate, interpret those reports and communicate their impact. This is the difference between “I fixed a leak” and “I helped my team understand why memory leaks degrade UX and how to prevent them.” That’s advocacy. 🧩 Anatomy of a Leak Report LeakCanary surfaces leaks via: In‑app notifications (quick feedback loop). Detailed LeakTrace UI (reference chains). Exported reports (for CI/CD integration). Example LeakTrace ┬─── │ GC Root: System class │ ├─ android.view.inputmethod.InputMethodManager │ Leaking: NO │ ↓ InputMethodManager.mLastSrvView ├─ com.example.LeakyActivity │ Leaking: YES (Activity was destroyed) │ Retained size: 5 MB This tells you: The GC root holding the leak. The chain of references. Whether the object is leaking. The retained size impact. 📊 Diagram: Leak Report Flow Heap...

  Introduction In Part 1, we saw how LeakCanary detects leaks at a high level. But the real magic begins with ObjectWatcher  — the component that quietly observes destroyed objects and decides whether they’re truly gone or suspiciously retained. Understanding ObjectWatcher is crucial if you want to debug leaks beyond surface level and explain them with authority. 🧩 What is ObjectWatcher? ObjectWatcher is a core utility inside LeakCanary that: Tracks destroyed objects (Activities, Fragments, Views, ViewModels). Holds them via weak references . Periodically checks if they’ve been garbage collected. Flags them as retained if they’re still alive after GC. Think of it as a security guard : once an object leaves the building (destroyed), ObjectWatcher ensures it doesn’t sneak back in. ⚙️ How ObjectWatcher Works 1. Watching Objects objectWatcher.watch( destroyedActivity, "Activity was destroyed but not GC'd" ) LeakCanary calls watch() whenever a lifecycle event signa...

  Every Android engineer has faced the dreaded OutOfMemoryError . It doesn’t happen on day one, but weeks after release, when users have navigated through dozens of screens. Suddenly, the app slows down, GC thrashes, and boom — crash. The silent culprit? Memory leaks. This post kicks off a series where we’ll dissect LeakCanary and its engine Shark , showing you not just how to use them, but how they work internally. By the end, you’ll be able to debug leaks like a pro — and explain them like an advocate. 🧠 What is a Memory Leak? A memory leak occurs when an object that should be garbage collected is still retained in memory because something is holding a reference to it. Example: Leaking Activity class LeakyActivity : AppCompatActivity () { companion object { // ❌ Static reference keeps Activity alive var instance: LeakyActivity? = null } override fun onCreate (savedInstanceState: Bundle ?) { super .onCreate(savedInstanceState) ...

Introduction Over the past few weeks, we’ve gone on a journey through LeakCanary and its engine Shark — from the basics of memory leaks to the deepest internals of heap analysis. This wrap‑up post ties everything together, giving you a single reference point for the entire series. If you’re serious about Android performance, debugging, and advocacy, this is your roadmap. 📚 The Series in Review 1. Why Memory Leaks Matter Defined leaks and their dangers. Showed a leaking Activity example. Explained why leaks silently degrade performance. 2. ObjectWatcher Deep Dive Explored how LeakCanary tracks destroyed objects. Weak references + ReferenceQueue checks. Manual watching for custom objects. 3. Heap Dumping Explaine How LeakCanary freezes the app and writes .hprof . Trade‑offs of heap dumping. Why it’s worth it for accuracy. 4. Shark Heap Analysis Parsing .hprof into HeapGraph. Shortest path finder from GC roots. LeakTrace reports with actionable insights. 5. Dominator Tree & Retai...