Skip to main content

How to Detect and Fix Android Memory Leaks Before They Crash Your App

· 4 min read
Andrea Sunny
Andrea Sunny
Marketing Associate, Appxiom

Have you ever dated someone who just… wouldn't let go?

You break up, move on, start fresh - and boom - they're still texting, still showing up in your life, refusing to be deleted.

That's your app with a memory leak.

It's holding on to screens, data, and objects long after it should've moved on. You've moved past the Activity, but it's still lingering in memory like a clingy ex who didn't get the memo.

The worst part? You might not even know it's happening.

But users will. They will feel it in the slowdowns, the crashes, the app that once felt smooth now feeling… emotionally unavailable.

And in Android, they're not just annoying. They're dangerous. They can slow down your app, cause freezes, and eventually - boom! A crash.

Let's dive into the most common memory leak scenarios in Android. I'll walk you through real-world examples, show you how to spot them, and most importantly, how to fix them.

1. The Retained Reference: "The Ex Who Keeps Your Hoodie"​

You ended the relationship. You moved on. But they still have your hoodie. And every time you walk past them, it's awkward.

In code, this happens when an object that outlives your activity or fragment holds on to it like it's not over yet.

The Leak​

class MainActivity : AppCompatActivity() {
    private val networkManager = NetworkManager(this) // Uh oh
    
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)
    }
}

object NetworkManager(private val context: Activity) {
    private val requestQueue: RequestQueue = Volley.newRequestQueue(context)
}

In this case, NetworkManager is holding onto the activity context. If MainActivity gets destroyed, but NetworkManager is still hanging around. Guess what? Your app's memory is still stuck in the past.

The Fix​

Don't pass the activity context. Pass the application context instead.

NetworkManager(applicationContext) // Much safer

Or if it absolutely must use the activity context? Make sure to release it in onDestroy().

2. Handler and Runnable: "The Text That Was Meant To Be Sent Later"​

You scheduled a message. Something sweet. But then you broke up. And it still got sent. Yikes.

This is what happens when you post a delayed Runnable to a Handler, but forget to cancel it.

The Leak​

class MyFragment : Fragment() {
    private val handler = Handler(Looper.getMainLooper())
    
    override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
        super.onViewCreated(view, savedInstanceState)
        
        val runnable = Runnable { 
            // do something 
        }
        handler.postDelayed(runnable, 5000)
    }
    
    override fun onDestroyView() {
        super.onDestroyView()
        // Missing this line causes the leak!
        handler.removeCallbacksAndMessages(null)
    }
}

If you forget removeCallbacksAndMessages(), that Runnable keeps a reference to the fragment. Like a scheduled message from a number you blocked.

The Fix​

Make sure to clear out any pending tasks in onDestroyView().

override fun onDestroyView() {
    super.onDestroyView()
    handler.removeCallbacksAndMessages(null) // Clean up!
}

3. Static Context: "The Clingy Global Constant"​

This one's dangerous. You gave them a key to your house (context), and now they live there permanently. Even if you move.

Holding a static reference to a context, like in a singleton, is one of the fastest ways to leak memory.

The Leak​

class MySingleton private constructor(private val context: Context) {
    
    companion object {
        private var instance: MySingleton? = null
        
        fun getInstance(context: Context): MySingleton {
            if (instance == null) {
                instance = MySingleton(context) // Danger zone!
            }
            return instance!!
        }
    }
}

If context is an activity context, boom. Memory leak.

The Fix​

Use applicationContext instead:

fun getInstance(context: Context): MySingleton {
    if (instance == null) {
        instance = MySingleton(context.applicationContext) // Safe!
    }
    return instance!!
}

Or better yet, avoid passing context entirely if you don't absolutely need it.

4. Bonus - Bitmap Leaks: "The One Who Moved In With All Their Stuff"​

Bitmaps are heavy. Keep them around when you shouldn't, and they'll fill up your memory fast.

Let's say you have an ImageView loading a high resolution image and you forget to recycle the bitmap or clear the reference when it's no longer needed.

The Fix​

Always clear or recycle unused bitmaps in onDestroy() or when the view is detached.

override fun onDestroy() {
    super.onDestroy()
    imageView.setImageBitmap(null)
    bitmap?.recycle()
    bitmap = null
}

Final Tip: Detecting the Leak Before It Gets Toxic​

You know what's worse than a memory leak? Not knowing it exists.

That's why leak detection tools are a developer's best friend. One of the easiest ways to find leaks is with Appxiom.

Why Appxiom?​

  • Automatically detects memory leaks across activities, fragments, and custom classes.
  • Gives you detailed reports on what's being retained and why.
  • Works silently in the background, without slowing you down.

Fixing bugs is hard. Finding them before users do? That's Appxiom.

Final Thoughts​

You don't have to live with memory leaks. You don't have to let your app's past haunt its present.

By being mindful of what you hold on to - and letting go when it's time - you're not just fixing bugs. You're building something stable. Trustworthy. Healthy.

Because in code, just like in life, the best relationships don't cling.