What is an Android memory leak? Give a Context example and fix.

WHAT THIS TESTS: This question tests whether you understand the Android application lifecycle and how improper Context handling causes memory leaks. Interviewers want to see that you know the difference between Activity Context and Application Context, and that you recognize how long-lived objects can pin entire Activity graphs in memory. It also checks your practical debugging skills beyond theory.

A GOOD ANSWER COVERS: First, define a memory leak as an object that is no longer needed but cannot be garbage collected because it remains reachable from a GC root. Second, give the canonical example of a static singleton or background task caching an Activity Context instead of the Application Context. Third, explain detection tools such as LeakCanary for automated detection in debug builds, or the Android Studio Memory Profiler to inspect heap dumps and identify reference chains retaining the Activity. Fourth, describe the fix: pass Application Context to any object that outlives the Activity, unregister listeners in lifecycle callbacks like onDestroy, and prefer WeakReference when a receiver must hold a reference back to UI components.

COMMON WRONG ANSWERS: A major red flag is claiming that memory leaks cannot happen in managed languages like Kotlin or Java. Another is blaming the garbage collector or suggesting System.gc() as a solution. Candidates sometimes confuse memory leaks with high memory usage or OutOfMemoryError symptoms without explaining the root retention cause. Saying you would simply set a reference to null without explaining lifecycle boundaries is also weak.

LIKELY FOLLOW-UPS: The interviewer may ask how you would detect a leak in production since LeakCanary is debug-only. They might probe whether AsyncTask or Handler leaks are still relevant in modern Android, or ask how ViewModel and LifecycleOwner help prevent these issues. Be ready to discuss how Kotlin coroutines and structured concurrency reduce the risk compared to raw threads.

ONE CONCRETE EXAMPLE: Imagine a network manager implemented as a Kotlin singleton with a method setContext that takes a Context to show a Toast on completion. An Activity calls this in onCreate and passes this. The singleton holds that Activity reference in a field. When the user rotates the screen, the old Activity is destroyed but the singleton still references it, so the entire view hierarchy and bitmaps remain in the heap. To fix this, the singleton should take Application Context from getApplicationContext, or better yet, use a non-UI callback and let the Activity observe it with a lifecycle-aware component.