As of Android Q Beta 5, this change has the following properties:
- Affects your app if you launch activities without user interaction
- Mitigate by using notification-triggered activities
- Disable restrictions by turning on 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.
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
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:
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
PendingIntentfrom 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
PendingIntentthat is sent from a different, visible app.
The app receives a system broadcast where the app is expected to launch a UI. Examples include
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
CompanionDeviceManagerAPI. This API allows the app to start activities in response to actions that the user performs on a paired device.
The app has been granted the
SYSTEM_ALERT_WINDOWpermission 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.
If your app is running the latest beta version of Android Q and tries to launch an activity from the background, the platform sends a warning message to logcat and displays the following warning toast message:
Background activity start from package-name blocked.
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.
Disable the behavior change
It's recommended that you keep this behavior change enabled. That way, you can be more confident that users can continue interacting with your app as expected when Android Q is installed on their devices.
If this change prevents you from testing a core workflow in your app, however, you can disable the behavior change during testing by completing one of the following tasks:
- Navigate to Settings > Developer options, and enable the Allow background activity starts option.
In a terminal window, run the following command:
adb shell settings put global background_activity_starts_enabled 1