DEV Community: Vikas Soni

Why Memory Leak Detection Shouldn't Run on Your Device

Vikas Soni — Sat, 06 Jun 2026 20:03:50 +0000

How I built LeakLens to move heap analysis from Android apps into Android Studio.

You're deep in a refactor when your test device lights up with a familiar notification:

"4 retained objects, dumping heap."

You pick up the phone, inspect the leak trace, try to remember the class names, and then jump back to Android Studio to find the source.

The bug report is useful. The interruption isn't.

That experience led me to ask a simple question:

Why is the tool that finds my memory leaks running inside the application I'm trying to debug?

That question became LeakLens, an Android Studio plugin that performs memory leak analysis directly inside the IDE, without requiring an SDK in the application itself.

The Problem: Leak Detection Comes With a Cost

For years, tools like LeakCanary have been the gold standard for Android memory leak detection. They work exceptionally well, but they also require a runtime dependency, consume device resources, and introduce an extra debugging workflow.

When a leak is detected, the investigation often starts on the device and ends in the IDE. That constant back-and-forth creates friction, especially when you're already focused on solving a different problem.

I wanted a workflow that:

Doesn't require another SDK dependency.
Doesn't consume application resources for analysis.
Doesn't force developers to leave their IDE to investigate leaks.

In short, I wanted leak detection to live where developers already spend their time: inside Android Studio.

Moving Heap Analysis to the Workstation

Instead of embedding analysis inside the application process, LeakLens offloads the heavy lifting to the developer machine.

Using ADB, ddmlib, and Android SDK tooling, the plugin can:

Trigger a native heap dump.
Pull the generated .hprof file from the device.
Analyze it locally using Shark, the same heap analysis engine that powers LeakCanary.

This changes the workflow completely.

Rather than asking a mobile device with limited CPU and memory to analyze a potentially large heap dump, the analysis runs on a workstation with significantly more resources available.

The application remains lightweight, while the IDE performs the expensive work.

The Turning Point: Combining Prevention With Detection

Runtime analysis is powerful, but it's also reactive.

To discover a leak, you first need to run the application, navigate to the right screen, trigger the problematic code path, and generate a heap dump.

The more I worked on LeakLens, the more obvious another opportunity became:

Many memory leaks follow patterns that are detectable long before the application ever runs.

This led to the idea of a dual-layer approach.

Layer 1: Static Analysis with UAST

The first layer focuses on prevention.

Using UAST (Universal Abstract Syntax Tree), LeakLens analyzes source code directly inside the editor and identifies common memory leak patterns in both Kotlin and Java.

Examples include:

Activity references stored in static fields.
Context objects retained in singleton instances.
Lifecycle-aware components used incorrectly.
Common listener and callback retention patterns.

Instead of waiting for a heap dump, LeakLens highlights the issue while you're writing code.

The goal is simple:

Catch obvious leaks before they ever reach a device.

Layer 2: Runtime Heap Analysis

Not every leak can be discovered statically.

Complex object graphs, third-party libraries, asynchronous callbacks, and framework interactions often require runtime inspection.

For those situations, LeakLens uses Shark-powered heap analysis to provide:

Retained object reports.
Leak traces.
Reference chains.
Retained size calculations.
Source navigation directly from the IDE.

By combining static inspections and runtime analysis in a single tool window, developers get a unified view of application memory health.

An Unexpected Challenge: When Kotlin Became the Problem

One of the most interesting engineering challenges had nothing to do with heap dumps.

It came from the IntelliJ Plugin Verifier.

My original implementation followed a fairly standard Kotlin-first approach. The plugin worked correctly, but verification against newer IntelliJ platform releases started producing a surprising number of compatibility violations.

After several rounds of investigation, the issue turned out to be Kotlin-generated bridge methods.

Some IntelliJ interfaces include default members such as methods related to icons, anchors, and extension point metadata. In newer platform versions, several of these APIs are marked as internal.

The plugin wasn't calling those APIs directly.

However, Kotlin-generated bridge methods were.

From the verifier's perspective, the plugin was touching internal APIs and therefore failing compatibility checks.

The solution was unexpectedly simple:

I moved several core extension-point implementations back to Java.

By using a small Java-Kotlin hybrid architecture, I was able to avoid the generated bridge-method issue entirely and restore compatibility across supported IDE versions.

It was a valuable reminder that the most modern solution is not always the most stable one, especially when building against large platform APIs.

Turning Leak Reports Into Actionable Fixes

Finding a leak is only part of the problem.

Understanding why it happened is usually the harder part.

Framework leaks, listener chains, and lifecycle interactions can produce reference graphs that are difficult to interpret, even for experienced developers.

To help with this, LeakLens includes an AI-assisted analysis workflow.

Rather than sending a raw leak trace to an LLM, the plugin builds a structured request that includes:

The reference chain.
Retained object information.
Retained size metrics.
Relevant source code context.

Providing the model with the reasoning path behind the leak significantly improves the quality of the suggestions it generates.

The result is more than generic advice—it often produces actionable explanations and code-level fixes.

Making Leak Detection Practical for Large Codebases

One of the most common concerns I heard from experienced developers was noise.

Imagine introducing a memory analysis tool into a project that already contains hundreds of existing leaks.

Finding leak number 501 is not useful if the first 500 are already known.

To address this, LeakLens includes a VCS-friendly baseline system.

Teams can generate a baseline file, commit it to source control, and treat existing issues as known technical debt.

From that point forward, the plugin only highlights newly introduced leaks and regressions.

This shifts memory management from a cleanup task to a development guardrail.

Instead of being overwhelmed by historical issues, teams can focus on preventing new ones from entering the codebase.

Conclusion

Memory leaks are rarely caused by a lack of tools.

More often, they're caused by friction.

Every context switch, every manual heap dump investigation, and every issue deferred until later increases the likelihood that a leak survives into production.

LeakLens was built to reduce that friction by bringing memory analysis back into the IDE.

Static inspections help prevent common mistakes before code reaches a device. Host-side heap analysis provides the depth needed to investigate complex runtime leaks. Together, they make memory health part of the development workflow rather than an occasional debugging exercise.

If you're interested in trying it, LeakLens is open source and available on the JetBrains Marketplace.

Useful Links

Install LeakLens: https://plugins.jetbrains.com/plugin/32079-leaklens/
Source Code: https://github.com/dev-vikas-soni/leak-lens

I Audited Google’s “Now in Android” Build Architecture (Here is what I found)

Vikas Soni — Mon, 11 May 2026 20:02:33 +0000

The Black Box of Gradle Builds As Android applications grow, they inevitably turn into deeply nested, multi-module mazes. You start with a clean architecture, but fast forward 6 months, and you are staring at a 5-minute build time, wondering where it all went wrong.

Is it a circular dependency? Is a rogue module breaking the Configuration Cache? Are we still running KAPT when we don’t need to?

For a long time, answering these questions required digging through Gradle build scans and manually tracking build.gradle files. Web developers have had "Google Lighthouse" for years to instantly audit their site’s health. I realized Android developers needed the exact same thing for their build systems.

So, I built Gradle Lighthouse — an open-source, zero-configuration build intelligence plugin.

To test if it was truly enterprise-ready, I decided to point it at the gold standard of modern Android architecture: Google’s Now in Android (NIA) repository.

The Experiment: Auditing “Now in Android”
The Now in Android app is Google’s official showcase for modern Android development. It uses Jetpack Compose, a highly modularized architecture, and Kotlin Multiplatform. It is the perfect stress test.

I added the Gradle Lighthouse plugin to NIA’s root build.gradle.kts (it only takes one line) and ran ./gradlew lighthouseAudit.

The engine ran 20+ architectural checks across the entire module graph. I expected a perfect score. I was wrong.

The Results: NIA Scored a 50/100 (“At Risk”)

The NIA project received an overall Architecture Score of 50/100, placing it in the “At Risk” rank.

Wait, how is the official Google showcase app at risk? Lighthouse runs an incredibly strict set of rules. Here are the most fascinating flaws it uncovered in NIA’s build scripts:

Configuration Cache Blockers (allprojects anti-pattern) Lighthouse immediately flagged a critical error: the root build.gradle.kts uses allprojects{} or subprojects{} blocks.

The Impact: This forces Gradle to eagerly configure every single module, even if you are only building one. It actively blocks migration to the Configuration Cache and the upcoming Isolated Projects feature in Gradle 9.x.
The Fix: Replacing this with convention plugins reduces configuration time by 50–90%.

The “Dark Module” Test Lighthouse scans for “Dark Modules” — modules that exist in the graph but have absolutely zero test files. The root nowinandroid module was flagged as a completely untested risk vector. In large enterprise projects, these dark modules accumulate over time and make safe refactoring impossible.

Subscribe to the Medium newsletter

Version Catalog Clutter & Bundle Opportunities NIA uses a modern libs.versions.toml file, but Lighthouse found two major areas for hygiene improvement:

Unused Entries: The catalog defines 103 library entries, but Lighthouse warned that several appear to be unused across the graph, creating unnecessary noise during dependency upgrades.
Missed Bundles: Lighthouse found 9 bundle opportunities. For instance, NIA declares 50 different androidx libraries and 3 coil libraries individually across modules, instead of grouping them into [bundles] for cleaner, safer dependency management.

Security and Reproducibility Blindspots Finally, Lighthouse flagged two easily fixable security and stability issues:

No Dependency Locking: NIA doesn’t use dependencyLocking. This means a transitive dependency could be silently upgraded to a compromised version between builds.
No JDK Toolchain: The build scripts lack a pinned JVM Toolchain (kotlin { jvmToolchain(17) }), which can lead to inconsistent bytecode across different developers' machines.
The Takeaway for Your App
Google’s Now in Android is a fantastic repository, but it proves a crucial point: As a project scales, build hygiene degrades silently.

The difference between a legacy app and a highly scalable one is often just 50ms of build time compounded over 100 modules. But you can’t fix what you can’t measure.

Get Your Lighthouse Score
I built Gradle Lighthouse to be completely free, open-source, and plug-and-play. If you want to see your project’s score and find out exactly why your builds are slow, it takes exactly one line of code.

Add this to your build.gradle.kts:

plugins {
  id("io.github.dev-vikas-soni.lighthouse") version "2.1.1"
}

And run:

./gradlew lighthouseAudit

Check out the repository here, and let me know what score your project gets!

🔗 GitHub: Gradle Lighthouse

(⭐️ If this tool helps you clean up your build graph and save time, I’d deeply appreciate a star on GitHub to help the open-source project grow!)

# Building a Production-Ready Kotlin Multiplatform SDK (Android + iOS)

Vikas Soni — Tue, 05 May 2026 18:42:53 +0000

Kotlin Multiplatform is no longer “experimental curiosity” — it’s a serious choice for production apps.

Companies like Netflix, Cash App, and McDonald's are already using it to share business logic across platforms while keeping native UI experiences intact (LevnTech).

In this post, I’ll walk through how I built a production-ready Kotlin Multiplatform SDK that works seamlessly across Android and iOS — along with the real challenges, trade-offs, and lessons learned.

🤔 Why Kotlin Multiplatform?

Unlike Flutter or React Native, Kotlin Multiplatform doesn’t try to replace native development.

Instead, it lets you:

Share business logic (networking, caching, models)
Keep native UI (Jetpack Compose / SwiftUI)
Avoid code duplication
Maintain near-native performance

This approach is powerful because you’re not forced into an “all-or-nothing” architecture — you can adopt it gradually (InfoQ).

🧱 Project Architecture

A typical KMP setup looks like this:

Android App → Uses shared module
iOS App → Consumes Kotlin framework
Shared Module → Business logic

Kotlin compiles your shared code into:

A native framework for iOS
A standard module for Android

This means no bridges, no JavaScript layer — just native performance (DEV Community).

🚀 What I Built

The goal was simple:

👉 Create a production-grade SDK that:

Can be reused across apps
Is easy to integrate
Handles real-world concerns (networking, error handling, scalability)

⚙️ Key Challenges (and How I Solved Them)

1. API Design for Two Worlds

Designing an SDK that feels “native” on both Android and iOS is harder than it sounds.

Solution:

Keep APIs minimal and platform-agnostic
Use expect/actual wisely
Avoid leaking platform-specific abstractions

2. Dependency Management

Not all libraries are multiplatform-ready.

Solution:

Prefer KMP-compatible libraries (e.g., Ktor)
Abstract dependencies behind interfaces

3. iOS Interoperability

Swift + Kotlin interop can get tricky.

Solution:

Design Swift-friendly APIs
Avoid overly complex generics
Test from Xcode early, not later

4. Build & CI Complexity

KMP builds can become slow and complex.

Solution:

Optimize Gradle configuration
Separate concerns into modules
Cache aggressively in CI

🧪 Production Learnings

After taking this setup closer to production, a few things stood out:

You can realistically share 70–80% of business logic
Debugging is manageable with standard tools
The biggest gains come from team alignment, not just code reuse

📦 When Should You Use KMP?

Kotlin Multiplatform is a great fit if:

✅ You have both Android and iOS apps
✅ Your business logic is complex and shared
✅ You want native UI but shared architecture

Avoid it if:
❌ Your app is UI-heavy with little shared logic
❌ Your team lacks Kotlin experience

💡 Final Thoughts

Kotlin Multiplatform hits a sweet spot:

Not a full abstraction layer
Not fully separate codebases

It gives you shared logic where it matters, without sacrificing native quality.

If you're building something meant to scale across platforms, it’s absolutely worth considering.

🔗 Full Article

If you want the complete deep dive with implementation details, check it out here:

👉 https://medium.com/proandroiddev/building-a-production-ready-kotlin-multiplatform-sdk-for-android-ios-0044cd5d1baf

🙌 Feedback

If you're working with Kotlin Multiplatform or planning to, I’d love to hear your experience.

What’s been your biggest challenge so far?