The Android 12 platform includes behavior changes that may
affect your app. The following behavior changes apply to all apps when they
run on Android 12, regardless of
targetSdkVersion. You should
test your app and then modify it as needed to support these properly, where
Make sure to also review the list of behavior changes that only affect apps targeting Android 12.
Foreground service notifications UX delay
To provide a streamlined experience for short-running foreground services on Android 12, the system can delay the display of foreground service notifications by 10 seconds for certain foreground services. This change gives short-lived tasks a chance to complete before their notifications appear.
If a foreground service has at least one of the following characteristics, the system shows the associated notification immediately after the service starts:
- The service is associated with a notification that includes action buttons.
- The service has a
The service provides a use case related to phone calls, navigation, or media playback, as defined in the notification's category attribute.
The service has opted out of the behavior change by calling
setShowForegroundImmediately()when setting up the notification.
Immersive mode improvements for gesture navigation
Android 12 simplifies immersive mode to make gesture navigation easier and more consistent with the rest of the experience of activities such as watching a video and reading a book. To learn more, see the corresponding entry on the features page.
Web intent resolution
To provide a more streamlined user experience for web links, Android 12 opens a web intent in the user's default browser if that intent contains an unverified domain. Your app can get approved for the domain using one of the following approaches:
- Verify the domain using Android App Links.
- Request that the user allows the system to open a web domain in your app.
Learn more about the changes to web intent resolution.
Restrictive App Standby bucket
App Standby Buckets help the system prioritize an app's resource requests based on how recently and how frequently the app is used.
Each bucket represents a priority. A low priority means the system imposes more restrictions on running your app.
Starting in Android 12, there is a new bucket named restricted. The restricted bucket has the lowest priority (and the highest restrictions) of all the buckets. The buckets in order of priority from high to low are:
- Active: App is currently being used or was very recently used
- Working set: App is in regular use
- Frequent: App is often used, but not every day
- Rare: App is not frequently used
The system considers your app's behavior, in addition to usage patterns, to decide whether to place your app in the restricted bucket. Your app is less likely to be placed in the restricted bucket if your app uses system resources more responsibly.
The system places your app in a less restrictive bucket if the user interacts directly with your app.
Power management restrictions
If the system places your app in the restricted bucket, the following restrictions apply:
- You can run jobs once per day, in a 10-minute batched session. During this session, the system groups your app's jobs with other apps' jobs.
- Your app's inexact alarms are delivered once
per day. You create an inexact alarm when you call the
- Your app can receive five high-priority Firebase Cloud Messaging (FCM) messages per day in a timely manner. All subsequent FCM messages are delivered with normal priority, so the messages might be delayed if the device is in a power-saving mode.
Foreground services allowance
If the system places your app in the restricted bucket, your app can still run foreground services. However, if your app targets Android 12, it's still affected by the foreground service launch restrictions.
Check whether your app is in the restricted bucket
To check whether the system has placed your app in the restricted bucket, call
If the return value of this method is
STANDBY_BUCKET_RESTRICTED, then your app
is in the restricted bucket.
Test the restricted bucket behavior
To test how your app behaves when the system places your app into the restricted bucket, you can manually move your app to that bucket. To do so, run the following command in a terminal window:
adb shell am set-standby-bucket PACKAGE_NAME restricted
Graphics and images
Improved refresh rate switching
In Android 12, refresh rate changes using
can happen regardless of whether the display supports a seamless transition to
the new refresh rate; a seamless transition is one that doesn't have any visual
interruptions, such as a black screen for a second or two. Previously, if the
display did not support a seamless transition, it would typically continue using
the same refresh rate after
setFrameRate() is called. You can determine in
advance whether the transition to the new refresh will likely be seamless by
Generally, the callback
is called after the refresh rate switch completes, but for some
externally-connected displays, it is called during a non-seamless transition.
Here’s an example of how you might implement this:
// Determine whether the transition will be seamless. // Non-seamless transitions may cause a 1-2 second black screen. val refreshRates = this.display?.mode?.alternativeRefreshRates val willbeSeamless = Arrays.asList<FloatArray>(refreshRates).contains(newRefreshRate) // Set the frame rate even if the transition will not be seamless. surface.setFrameRate(newRefreshRate, FRAME_RATE_COMPATIBILITY_FIXED_SOURCE, CHANGE_FRAME_RATE_ALWAYS)
// Determine whether the transition will be seamless. // Non-seamless transitions may cause a 1-2 second black screen. Display display = context.getDisplay(); // API 30+ Display.Mode mode = display.getMode(); float refreshRates = mode.getAlternativeRefreshRates(); boolean willbeSeamless = Arrays.asList(refreshRates).contains(newRefreshRate); // Set the frame rate even if the transition will not be seamless. surface.setFrameRate(newRefreshRate, FRAME_RATE_COMPATIBILITY_FIXED_SOURCE, CHANGE_FRAME_RATE_ALWAYS);
Untrusted touch events are blocked
To preserve system security and a good user experience, Android 12 prevents apps from consuming touch events where an overlay obscures the app in an unsafe way. In other words, the system blocks touches that pass through certain windows, with a few exceptions.
This change affects apps that choose to let touches pass through their windows,
for example by using the
flag. Several examples include, but aren't limited to, the following:
- Overlays that require the
SYSTEM_ALERT_WINDOWpermission, such as windows that use
TYPE_APPLICATION_OVERLAY, and use the
- Activity windows that use the
In the following cases, "pass-through" touches are allowed:
- Interactions within your app. Your app shows the overlay, and the overlay appears only when the user is interacting with your app.
Trusted windows. These windows include (but aren't limited to) the following:
Completely transparent windows. The
alphaproperty is 0.0 for the window.
Sufficiently translucent system alert windows. The system considers a set of system alert windows to be sufficiently translucent when the combined opacity is less than or equal to the system's maximum obscuring opacity for touches. In Developer Preview 3, this maximum opacity is 0.8, but this value might change later in the Developer Preview.
Detect when an untrusted touch is blocked
If a touch action is blocked by the system, Logcat logs the following message:
Untrusted touch due to occlusion by PACKAGE_NAME
Test the change
Untrusted touches are blocked by default on devices that run Android 12 Developer Preview 3. To allow untrusted touches, run the following ADB command in a terminal window:
# A specific app adb shell am compat disable BLOCK_UNTRUSTED_TOUCHES com.example.app # All apps # If you'd still like to see a Logcat message warning when a touch would be # blocked, use 1 instead of 0. adb shell settings put global block_untrusted_touches 0
To revert the behavior to the default (untrusted touches are blocked), run the following command:
# A specific app adb shell am compat reset BLOCK_UNTRUSTED_TOUCHES com.example.app # All apps adb shell settings put global block_untrusted_touches 2
Apps can't close system dialogs
To improve user control when interacting with apps and the system, the
intent action is deprecated as of Android 12. Except for a few
special cases, when your app tries to invoke
an intent that contains this action, the
system does one of the following based on your app's target SDK version:
- If your app targets Android 12, a
If your app targets Android 11 (API level 30) or lower, the intent doesn't execute, and the following message appears in Logcat:
E ActivityTaskManager Permission Denial: \ android.intent.action.CLOSE_SYSTEM_DIALOGS broadcast from \ com.package.name requires android.permission.BROADCAST_CLOSE_SYSTEM_DIALOGS, \ dropping broadcast.
In the following cases, an app can still close system dialogs on Android 12:
- Your app is running an instrumentation test.
Your app targets Android 11 or lower and is showing a window that is on top of the notification drawer.
Your app targets Android 11 or lower. In addition, the user has interacted with a notification, possibly using the notification's action buttons, and your app is processing a service or broadcast receiver in response to that user action.
Updated non-SDK interface restrictions
Android 12 includes updated lists of restricted non-SDK interfaces based on collaboration with Android developers and the latest internal testing. Whenever possible, we make sure that public alternatives are available before we restrict non-SDK interfaces.
If your app does not target Android 12, some of these changes might not immediately affect you. However, while you can currently use some non-SDK interfaces (depending on your app's target API level), using any non-SDK method or field always carries a high risk of breaking your app.
If you are unsure if your app uses non-SDK interfaces, you can test your app to find out. If your app relies on non-SDK interfaces, you should begin planning a migration to SDK alternatives. Nevertheless, we understand that some apps have valid use cases for using non-SDK interfaces. If you cannot find an alternative to using a non-SDK interface for a feature in your app, you should request a new public API.
To learn more about the changes in this release of Android, see Updates to non-SDK interface restrictions in Android 12. To learn more about non-SDK interfaces generally, see Restrictions on non-SDK interfaces.