Android Q privacy change: Restrictions to background activity starts

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

  • Affects your app if you launch activities without user interaction
  • Mitigate by using notification-triggered activities
  • Enable restrictions by turning off the Allow background activity starts developer option

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. In particular, apps running on Android Q can start activities only when one or more of the following conditions are met:

  1. The app has a visible window, such as an activity in the foreground.
  2. A different app that's in the foreground sends a PendingIntent belonging to the app. Examples include a Custom Tabs provider sending a menu item pending intent.
  3. The system sends a PendingIntent that belongs to the app, such as tapping on a notification. Only pending intents where the app is expected to launch a UI are exempt.
  4. The system sends a broadcast, such as SECRET_CODE_ACTION, to the app. Only specific broadcasts where the app is expected the launch a UI are exempt.

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. If you find that your app is affected, send us feedback.

Warning messages

In Beta 2, if your app is running on Android Q and tries to launch an activity from the background, the platform allows the activity to launch, but it sends a warning message to logcat and displays the following warning toast message:

This background activity start from package-name will be blocked in future Q builds.

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 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 and that you optionally 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 allowing 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.

Enable the behavior change

Even though this behavior change doesn't take effect by default in Android Q Beta 2, you can simulate the behavior change by completing one of the following tasks:

  • Navigate to Settings > Developer options, and disable the Allow background activity starts option.
  • In a terminal window, run the following command:

    adb shell settings put global background_activity_starts_enabled 0
    

By testing the behavior change, you can be more confident that users can continue interacting with your app as expected when Android Q is installed on their devices.