Foreground Service Activity Start Restrictions

Starting with Android 10 (API 29), apps running foreground services are generally restricted from launching activities directly from the background. Even though a foreground service indicates an ongoing operation the user is aware of, the system treats the app as being in the background for the purpose of starting new activities. The recommended alternative is to use a time-sensitive notification that lets the user choose when to interact. By the end of this lesson, you will be able to:

• Explain why Android restricts background activity starts even from foreground services.
• Describe the user experience problems that unrestricted background activity starts cause.
• Implement the recommended notification-based alternative for foreground service interactions.
• Identify the specific exceptions that allow background activity starts.
• Distinguish between a foreground service's ongoing notification and a time-sensitive interaction prompt.

Why the Restriction Exists

Before Android 10, any app with a foreground service could launch an activity at any time. This meant an app performing a download or tracking location could take over the screen while the user was typing a message, watching a video, or using another app entirely. The interruption was jarring and outside the user's control.

Android 10 introduced background activity start restrictions to give users control over what appears on their screen. The system considers an app with a foreground service to be in the background because the user is not directly interacting with the app's UI. The foreground service is running, but the user has moved on to another activity or the home screen.

The Notification-Based Alternative

Instead of starting an activity directly, a foreground service should display a time-sensitive notification. This notification appears as a heads-up notification when the user is active, providing immediate visibility without taking over the screen. The user can dismiss it, interact with it, or address it when convenient.

For situations where the notification must be seen immediately, such as incoming calls or alarms, the notification can include a full-screen intent. When the device screen is off, the full-screen intent launches the activity directly. When the screen is on, it appears as a heads-up notification.

val fullScreenIntent = Intent(context, CallActivity::class.java)
val pendingIntent = PendingIntent.getActivity(
    context, 0, fullScreenIntent,
    PendingIntent.FLAG_IMMUTABLE
)

val notification = NotificationCompat.Builder(
    context, CHANNEL_ID
)
    .setSmallIcon(R.drawable.ic_call)
    .setContentTitle("Incoming call")
    .setPriority(NotificationCompat.PRIORITY_HIGH)
    .setCategory(NotificationCompat.CATEGORY_CALL)
    .setFullScreenIntent(pendingIntent, true)
    .build()

The notification includes a PendingIntent that, when tapped, starts the desired activity. This approach respects the user's context by letting them choose when to engage with the app. The setFullScreenIntent call ensures the activity launches directly when the screen is off, while showing a heads-up notification when the screen is on.

Foreground Service Types and Android 14+

Starting with Android 14 (API 34), foreground services must declare a type in the manifest using the android:foregroundServiceType attribute. This further restricts what foreground services can do by requiring the developer to declare the service's purpose upfront.

Common types include camera, location, microphone, dataSync, mediaPlayback, and phoneCall. Each type has specific permission requirements and behavioral constraints. For example, a phoneCall type requires the MANAGE_OWN_CALLS permission and is expected to integrate with the telecom framework.

This typing system reinforces the principle behind background activity start restrictions: the system wants to know what each foreground service does and enforce appropriate limitations on each type.