Foreground service launch restrictions

We'd love to hear your feedback about these restrictions. Take a short survey to tell us what you think. In particular, let us know what use cases in your app are affected by this change.

Apps that target Android 12 can no longer start foreground services while running in the background, except for a few special cases. If an app tries to start a foreground service while the app is running in the background, and the foreground service doesn't satisfy one of the exceptional cases, the system throws a ForegroundServiceStartNotAllowedException.

Note: If one app calls Context.startForegroundService() to start a foreground service that another app owns, the restrictions described on this page take effect only if both apps target Android 12.

Recommended alternative to foreground services: WorkManager

If your app is affected by this change, it's recommended that you migrate to using WorkManager. When Android 12 beta is released, WorkManager will become the recommended solution for starting higher-priority background tasks.

Starting in WorkManager 2.7.0, your app can call setExpedited() to declare that a Worker should use an expedited job. This new API uses expedited jobs when running on Android 12, and the API uses foreground services on prior versions of Android to provide backward compatibility.

To encourage developers to be intentional about when they request expedited work in their apps, and to better support the ability to extend the length of time that a task can run, the CoroutineWorker.setForeground() and ListenableWorker.setForegroundAsync() methods are deprecated. In particular, on devices that run Android 12, trying to call ListenableWorker.setForegroundAsync() results in an IllegalStateException. It's recommended that developers use setExpedited() instead.

To see a complete example of how WorkManager 2.7.0 uses expedited jobs, look through the WorkManagerSample on GitHub.

Expedited jobs

Expedited jobs, new in Android 12, allow apps to execute important tasks while giving the system better control over access to resources. These jobs have a set of characteristics somewhere in between a foreground service and a regular JobScheduler job:

• They're less affected by some of the system's power management restrictions, including Battery Saver and Doze.
• The system runs them immediately, provided that the system's current workload makes it possible to do so.

Expedited jobs might be deferred

The system tries to execute a given expedited job as soon as possible after the job is invoked. However, as is the case with other types of jobs, the system might defer the start of new expedited jobs if there are too many jobs already running, or if system resources are running low.

In particular, the system defers the execution of expedited jobs when at least one of the following conditions occur:

• The system load is too high.
• The expedited job quota limit has been exceeded. Expedited jobs use a quota system that's based on the App Standby Buckets and limits the maximum execution time within a rolling time window. The quotas used for expedited jobs are more restrictive than the ones used for other types of background jobs.

Effects on Alarm Manager APIs

In general, apps that target Android 12 can't start foreground services using an alarm.

To support use cases in which apps need to send time-sensitive alarms or reminders to users, you can still start foreground services when your exact alarms go off. In order to set exact alarms, your app must declare the SCHEDULE_EXACT_ALARM permission.

Learn more about the exact alarm permission.

Cases where foreground service launches from the background are allowed

In the following situations, your app can start foreground services even while your app is running in the background:

• Your app transitions from a user-visible state, such as an activity.
• Your app can start an activity from the background, except for the case where the app has an activity in the back stack of an existing task.
• Your app receives a high-priority message using Firebase Cloud Messaging.
• The user performs an action on a UI element related to your app. For example, they might interact with a bubble, notification, widget, or activity.
• Your app receives an event that's related to geofencing or activity recognition transition.
• After the device reboots and receives the ACTION_BOOT_COMPLETED, ACTION_LOCKED_BOOT_COMPLETED, or ACTION_MY_PACKAGE_REPLACED intent action in a broadcast receiver.
• Apps with certain system roles or permission, such as device owners and profile owners.

• Your app uses the Companion Device Manager.

  To let the system wake your app whenever a companion device is nearby, implement the Companion Device Service in Android 12.

• Your app uses a "sticky" foreground service by invoking either START_STICKY or START_REDELIVER_INTENT.

  If your app is killed by the system when you have a "sticky" foreground service running, the system restarts it automatically.

• The user has disabled battery optimizations for your app. You can help users find this option by sending them to your app's App info page in system settings. To do so, invoke an intent that contains the ACTION_IGNORE_BATTERY_OPTIMIZATION_SETTINGS intent action.