When would you choose Foreground Service over WorkManager?

WHAT THIS TESTS: This question checks if you understand the boundary between immediate user-visible work and deferrable background work on Android. The interviewer wants to see that you know Foreground Services are bound to a persistent notification and are meant for tasks the user actively expects to continue, while WorkManager is the API for guaranteed but deferrable background tasks that do not need to run instantly and can wait for optimal conditions.

A GOOD ANSWER COVERS: First, state the core distinction: a Foreground Service runs immediately and must display a persistent notification, whereas WorkManager schedules work that can be deferred and constrained by network or battery conditions. Second, give a specific user-facing use case where the task must start right away and remain ongoing while the user is aware of it, such as a live fitness workout tracking location and heart rate, turn-by-turn navigation providing audio cues, or a music player streaming content. Third, mention that starting a foreground service from the background carries restrictions and requires declaring the service in the manifest and requesting the correct permissions. Fourth, explain why WorkManager is wrong for this scenario because it does not promise immediate execution and could delay the task until constraints are met, breaking real-time user expectations and degrading the experience.

COMMON WRONG ANSWERS: Saying you would use a Foreground Service for periodic data sync or upload jobs that do not need a notification. Claiming WorkManager can handle time-critical or user-interactive tasks. Failing to mention the persistent notification requirement. Ignoring system restrictions on starting foreground services from the background. Suggesting a plain background Service without the foreground designation or dismissing the notification as optional.

LIKELY FOLLOW-UPS: How do you handle the new restrictions on starting foreground services from the background in recent Android versions? What foreground service type would you declare for your specific use case? How do you manage the service lifecycle if the user swipes the app away or the system imposes a service timeout? When would you combine WorkManager with a foreground service, or use expedited WorkManager instead?

ONE CONCRETE EXAMPLE: A fitness app recording an outdoor run should use a Foreground Service. The user starts the workout, expects GPS and heart rate sampling to begin immediately, and needs a persistent notification showing elapsed time and distance. WorkManager cannot guarantee the workout starts the moment the user presses begin, and the user must be able to pause or stop the run from the notification. The service must be declared in the manifest and request the appropriate foreground service type for location, and the app must respect background start restrictions by launching it while the app is in the foreground or by using an approved exemption.