What the interviewer is testing

The interviewer is checking whether you understand what problem Services were designed to solve, not whether you can recite every lifecycle callback.

They want to understand whether you know what problem a Service solves, why Android introduced it, and when it is still the appropriate component in modern Android.

A strong answer explains that a Service gives work a lifetime independent of the current screen, but that it does not decide how the work executes. Senior engineers can then explain why a ViewModel, WorkManager, or a Foreground Service may each be more appropriate depending on the requirement.

❌ Common mistake

If they ask you to elaborate

Why Android introduced Services

Imagine a music player. The user presses Home while a song is playing.

Should the music stop simply because the Activity disappeared?

No. The playback should continue because the work outlives the screen. Android introduced the Service component to model exactly that kind of lifetime.

Start with ownership and lifetime

Imagine a music player.

The user starts playback and then presses Home. Should the music stop simply because the Activity disappeared?

No. The playback should outlive the screen.

Playback screen
      │
      │ starts playback
      ▼
Playback Service
      │
      │ music continues
      ▼
Activity finishes

The Service owns the playback session. The Activity simply controls or observes it while the UI is visible.

Choose the right tool

The work may happen without a visible screen in every row. That alone does not make a Service the right choice. Choose the mechanism by the ownership, lifetime, visibility, and reliability the work requires.

Production considerations

Always start by asking whether the work genuinely needs a lifetime independent of the current screen. If it belongs to a ViewModel, keep it there. If it must eventually complete even after process death, WorkManager is usually a better choice. Reach for a Service only when the work itself must outlive the UI or expose a long-lived capability.

A Service adds another Android component and another lifecycle to reason about, so it should own a genuine responsibility rather than simply wrap slow code.

If the work belongs to the current UI, keep it in a ViewModel. If it must eventually complete after process death, WorkManager is usually the better choice. Reserve Services for work that genuinely owns its own lifetime.

Use the narrowest execution model that satisfies the requirement. A coroutine is simpler when work belongs to an existing lifecycle owner. WorkManager is usually the better fit for persistent, retryable, or constrained work. A foreground Service is justified when work is immediate, ongoing, and clearly noticeable to the user, such as media playback or active navigation.

Using Services indiscriminately increases lifecycle complexity, makes testing harder, consumes system resources, and may conflict with modern Android background-execution restrictions. Even a foreground Service is not immortal; interruption and process death still require deliberate recovery and state handling.

Code example

class PlaybackService : LifecycleService() {

    private val player = PlayerEngine()

    override fun onCreate() {
        super.onCreate()
        startForeground(NOTIFICATION_ID, createNotification())
    }

    fun play(track: Track) {
        player.play(track)
    }
}

The important design decision is not the call to startForeground(). It is that the playback engine is owned by the Service rather than by an Activity, so playback can continue while screens come and go.

In production, the Service should remain a thin Android lifecycle boundary. Playback, storage, networking, and domain rules should live in ordinary collaborators that are easier to test and reuse.

Follow-up questions

What separates a senior answer

Key takeaways

Learn more