What is an Android memory leak? Give a Context example and fix.
Tests understanding of Activity Context retention preventing GC. A strong answer defines a leak as unreachable objects, gives a static singleton example, names LeakCanary, and fixes it with Application Context. Red flag: blaming GC or suggesting System.gc().
What's really being asked
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.
The full answer
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.
The mistakes people make
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.
What usually comes next
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.
A 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.
Interview question
A static singleton caches an Activity Context. What is the root cause of the resulting memory leak?
- a.The singleton should call System.gc() after the Activity is destroyed to force immediate cleanup.
- b.The garbage collector fails to run automatically when the screen rotates and the Activity is destroyed.
- c.The leak occurs when the retained Activity consumes all available heap and triggers an OutOfMemoryError.
- d.The singleton keeps the Activity reachable from a GC root, so it cannot be garbage collected.Correct
Why? this is the answer
The singleton's strong reference keeps the destroyed Activity reachable from a GC root, preventing garbage collection. Blaming the garbage collector is a red flag because the GC correctly preserves reachable objects; the problem is accidental retention, not GC failure.
Just read this? Test yourself on what you have been reading.
Read the original → developer.android.com
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on android — each one lists the topics its interview covers.
See open roles