When and why to use a Foreground Service?
Tests your grasp of Android's background execution limits. A great answer explains they're for user-visible tasks like music playback, requires startForegroundService(), and must show a notification within 5 seconds.
What's really being asked
This question probes your knowledge of Android's lifecycle and background processing limitations. Interviewers want to see if you understand why these restrictions exist (to save battery and system resources) and how to correctly implement a user-visible, long-running task that the system won't kill. It separates candidates who just know the API from those who understand the underlying system design principles.
The full answer
A strong answer has four parts. First, define the 'why': use a foreground service for operations the user is actively aware of and would be disrupted if the app process were killed, such as playing music, tracking a run, or handling a call. Second, explain the modern startup procedure for API 26+: you must call startForegroundService() instead of startService(). This signals intent to the system. Third, detail the critical follow-up: within 5 seconds of the service starting, you must call startForeground() inside the service itself, passing it a unique integer ID and a Notification object. Failure to do so results in an ANR (Application Not Responding) error and the system killing your app. Fourth, mention the required permissions and declarations: you need the FOREGROUND_SERVICE permission in your AndroidManifest.xml and, for API 29+, you must also declare a specific foregroundServiceType (e.g., mediaPlayback, location).
The mistakes people make
A major red flag is describing the pre-Oreo (API 26) behavior of simply calling startService() and assuming it will run indefinitely. Another weak answer is forgetting the 5-second window to call startForeground(), which is the most common failure point in implementation. Candidates also lose points for not knowing about the mandatory, non-dismissible notification that must be shown to the user, or failing to mention the foregroundServiceType requirement on newer APIs, which shows their knowledge is outdated. Treating it as a way to just "keep my app alive" without a valid user-facing reason is a conceptual red flag.
What usually comes next
Be ready for "What happens if the user dismisses the notification?" (The service is stopped unless it's a media session). Another is "How do you choose the right foregroundServiceType and why is it important?" (It's for system transparency and resource management; some types have different restrictions). Also, "Compare a Foreground Service to WorkManager for a long-running download." (WorkManager is for deferrable, guaranteed execution; Foreground Service is for immediate, user-visible tasks).
A concrete example
For a music player app, when the user hits 'play', you would call context.startForegroundService(intent). Inside the MusicPlayerService's onStartCommand(), you would build a Notification showing the current track. You then call startForeground(NOTIFICATION_ID, notification). This ensures the music continues playing even if the user switches apps or locks their screen, and the system knows not to kill the process because it's performing a user-visible task. The notification provides the user with playback controls and a way back into the app.
Interview question
On a modern Android device, an app starts a service for a user-visible task but is terminated with an ANR shortly after. What is the most likely cause?
- a.The service failed to call `startForeground()` with a Notification within the required time limit.Correct
- b.The `FOREGROUND_SERVICE` permission was missing from the app's manifest.
- c.The service was started using `startService()` instead of `startForegroundService()`.
- d.A specific `foregroundServiceType` was not declared in the service's manifest tag.
Why? this is the answer
The system requires a service started with `startForegroundService()` to call `startForeground()` within about 5 seconds; failure to do so results in an ANR. Missing permissions or using the wrong start method would cause different, more immediate exceptions.
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