Android Q privacy change: Restrictions to background activity starts

As of Android Q Beta 6, this change has the following properties:

  • Affects your app if you launch activities without user interaction
  • Mitigate by using notification-triggered activities

We're interested in hearing your feedback! Report issues you find when using this feature during the Android Q beta program.

Android Q places restrictions on when apps can start activities. This behavior change helps minimize interruptions for the user and keeps the user more in control of what's shown on their screen.

This behavior change applies to all apps running on Android Q, even those that target Android 9 (API level 28) or lower. In addition, even if your app targets Android 9 or lower and is originally installed on a device running Android 9 or lower, the behavior change still takes effect after the device is upgraded to Android Q.

As long as your app starts activities as a direct result of user interaction, however, your app most likely isn't affected by this change. In fact, the majority of apps are unaffected by this change.

Conditions that allow for activity starts

Apps running on Android Q can start activities only when one or more of the following conditions are met:

  • The app has a visible window, such as an activity in the foreground.

  • The app has an activity in the back stack of the foreground task.

  • The app has an activity that was started very recently.

  • The app called finish() on an activity very recently. This applies only when the app had either an activity in the foreground or an activity in the back stack of the foreground task at the time finish() was called.

  • The app has a service that is bound by the system. This condition applies only for the following services, which might need to launch a UI: AccessibilityService, AutofillService, CallRedirectionService, HostApduService, InCallService, TileService, VoiceInteractionService, and VrListenerService.

  • The app has a service that is bound by a different, visible app. Note that the app that is bound to the service must remain visible for the app in the background to start activities successfully.

  • The app receives a notification PendingIntent from the system. In the case of pending intents for services and broadcast receivers, the app can start activities for a few seconds after the pending intent is sent.

  • The app receives a PendingIntent that is sent from a different, visible app.

  • The app receives a system broadcast where the app is expected to launch a UI. Examples include ACTION_NEW_OUTGOING_CALL and SECRET_CODE_ACTION. The app can start activities for a few seconds after the broadcast is sent.

  • The app is associated with a companion hardware device through the CompanionDeviceManager API. This API allows the app to start activities in response to actions that the user performs on a paired device.

  • The app is a device policy controller running in device owner mode. Example use cases include fully managed enterprise devices, as well as dedicated devices like digital signage and kiosks.

  • The app has been granted the SYSTEM_ALERT_WINDOW permission by the user.

If the app doesn't meet any of the above conditions but has an existing task on the Recents screen, the system still provides support for starting activities. When such an app attempts to start a new activity, the system places that activity on top of the app's existing task but doesn't navigate away from the currently-visible task. When the user later returns to the app's task, the system starts the new activity instead of the activity that had previously been on top of the app's task.

Warning messages

If your app is running the latest beta version of Android Q and tries to launch an activity from the background, the platform no longer shows a warning toast. You can, however, view a warning message in logcat. The message contains the following format:

Background activity start [callingPackage: package-name, ...]

The restrictions associated with starting activities in the background in Android Q are similar to how the system blocks activity launches after the device has entered a screen pinning state.

Create notifications for time-sensitive events

In nearly all cases, apps that are in the background should create notifications to provide information to the user instead of directly starting an activity.

In specific cases, your app might need to get the user's attention urgently, such as an ongoing alarm or incoming call. You might have previously configured your app to launch a background activity for this purpose. To provide the same behavior on a device running Android Q, complete the steps shown in the following sections.

Create a high-priority notification

When creating the notification, make sure that you include a descriptive title and message. Optionally, you can also provide a full-screen intent.

An example notification appears in the following code snippet:

val fullScreenIntent = Intent(this, CallActivity::class.java)
val fullScreenPendingIntent = PendingIntent.getActivity(this, 0,
    fullScreenIntent, PendingIntent.FLAG_UPDATE_CURRENT)

val notificationBuilder = NotificationCompat.Builder(this, CHANNEL_ID)
    .setSmallIcon(R.drawable.notification_icon)
    .setContentTitle("Incoming call")
    .setContentText("(919) 555-1234")
    .setPriority(NotificationCompat.PRIORITY_HIGH)
    .setCategory(NotificationCompat.CATEGORY_CALL)

    // Use a full-screen intent only for the highest-priority alerts where you
    // have an associated activity that you would like to launch after the user
    // interacts with the notification. Also, if your app targets Android Q, you
    // need to request the USE_FULL_SCREEN_INTENT permission in order for the
    // platform to invoke this notification.
    .setFullScreenIntent(fullScreenPendingIntent, true)

val incomingCallNotification = notificationBuilder.build()

Display the notification to the user

When displaying your notification to the user, they can then choose, based on their current context, whether to acknowledge or dismiss your app's alert or reminder. For example, the user can choose whether to accept or reject an incoming phone call.

If your notification is an ongoing one, such as an incoming phone call, associate the notification with a foreground service. The following code snippet shows how to display a notification that's associated with a foreground service:

// Provide a unique integer for the "notificationId" of each notification.
startForeground(notificationId, notification)

Benefits of notifications

This notification-based alert and reminder system provides several advantages for users:

  • When using the device, the user is shown a heads-up notification that allows them to answer or reject the call, or to dismiss the alarm. The user maintains their current context and has control over the content that they see on the screen.
  • Your incoming call or alarm respects the user's Do Not Disturb rules. For example, users might permit calls only from specific contacts, or repeat callers, when Do Not Disturb is enabled.
  • When the device's screen is off, your full-screen intent is launched immediately.
  • In the device's Settings screen, the user can see which apps have recently sent notifications, including from specific notification channels. From this screen, the user can control their notification preferences.