Services & Background Work Interview Questions
ANDROID › Components
Walk me through how you'd decide between a started Service, a bound Service, and WorkManager for a given feature. What questions do you ask yourself?
What a strong answer covers: The decision tree is roughly: if the work is deferrable, can tolerate delay, and needs guarantees like surviving reboot or requires constraints such as network or charging, that's WorkManager; if something in-process or in another app needs a live, synchronous connection to call into, like a UI binding to a playback engine, that's a bound Service; if work must start now and keep running independent of any UI, visibly to the user as ongoing, like music or navigation, that's a Service promoted to foreground via startForeground(). Anything that used to be a plain background Service kicked off with startService() for arbitrary async work is almost always wrong today because of Android 8+ background execution limits, and should be WorkManager or a coroutine scope instead.
Foreground services require a persistent notification the user can see. What problem is Android actually solving by forcing that, and what's the tension between that requirement and good UX?
What a strong answer covers: The notification guarantees the user always has visibility into, and a one-tap way to stop, anything running with elevated priority consuming battery or resources while the app isn't in the foreground, which directly counters the abuse pattern of apps silently running indefinitely in the background, like draining battery or tracking location unnoticed. The UX tension is real, for a music player it's an expected, useful notification, but for a rarely-visible background task it can feel like clutter; that tension is exactly why the system nudges you toward WorkManager, which needs no persistent notification, whenever the work doesn't actually need to be foreground-visible.
You've got a music player app. Walk me through the architecture: what's the Service actually for, how does it communicate with the Activity/UI, and what changes if the user swipes the app away from Recents while music is playing?
What a strong answer covers: A foreground Service owns the player instance and the actual playback state so it survives independent of any particular Activity being on screen; the UI communicates with it through a MediaSession/MediaController rather than owning playback itself, which also lets external surfaces like the lock screen or Bluetooth controls drive playback without their own bound connection. If the user swipes the app away, Android can kill the whole process including the Service unless it's a properly declared foreground service with the right foregroundServiceType and, depending on manifest configuration, an explicit opt-out via android:stopWithTask="false"; a strong answer names that combination as what actually keeps music playing after the task is swiped away.