When and why use a Foreground Service on API 26+?

WHAT THIS TESTS: This question probes your understanding of Android's power management evolution and the boundary between acceptable background work and work that must be visible to the user. Interviewers want to see that you know why foreground services exist, when they are legally startable under modern restrictions, and what contractual obligations they impose on the app. It also surfaces whether you keep up with recent platform changes around service types and background start limitations.

A GOOD ANSWER COVERS: First, the why: a foreground service is appropriate for long-running work that the user actively notices and would expect to survive, such as music playback, turn-by-turn navigation, or a phone call. Second, the API 26 restrictions: starting a foreground service from the background is generally prohibited unless the app is in the foreground or qualifies for a specific exception like receiving a high priority FCM message or a broadcast. Third, the requirements: you must declare the FOREGROUND_SERVICE permission in the manifest, call startForeground within the service timeout after the service starts, and supply a persistent notification so the user is always aware of the ongoing work. Fourth, modern types: on newer releases you should declare a foregroundServiceType in the manifest and request the corresponding permission, such as location or microphone, aligning the service with the exact resource it uses.

COMMON WRONG ANSWERS: A major red flag is suggesting a plain background service or WorkManager for user-noticeable continuous tasks, because WorkManager is designed for deferrable work and background services are heavily throttled on API 26 and above. Another mistake is forgetting the notification requirement or claiming the service can run silently; the platform requires a notification precisely because the work is user-facing. Candidates also stumble by not mentioning the manifest permission or the background-start restrictions, which suggests they have not shipped code on modern Android versions.

LIKELY FOLLOW-UPS: The interviewer may ask how to handle the service timeout, what happens if startForeground is not called promptly, or how to stop the service correctly. They might also dig into the specific foregroundServiceType values, how to start a foreground service from a BroadcastReceiver, or the differences between startForegroundService and startService on pre-O and post-O devices. Be ready to discuss the user-stopped state and how to detect that the service was killed by the user swiping away the notification.

ONE CONCRETE EXAMPLE: Suppose you are building a fitness tracker that records a GPS route while the screen is off. You would declare FOREGROUND_SERVICE and foregroundServiceType location in the manifest. When the user presses start, because your activity is in the foreground you call startForegroundService, then inside the service you immediately promote it via startForeground with a notification showing elapsed time and distance. On API 26 and above this keeps the process alive under background restrictions, whereas a plain background service would be killed by the system shortly after the activity stops.