Like earlier releases, Android 12 includes behavior changes that may affect your app. The following behavior changes apply exclusively to apps that are targeting Android 12 or higher. If your app is targeting Android 12, you should modify your app to support these behaviors properly, where applicable.
The following table summarizes the key changes that affect your app if your app targets Android 12. Note that this table doesn't provide the complete set of changes.
Key change | Apps affected |
---|---|
Foreground service
launch restrictions With a few exceptions, apps can no longer start foreground services while running in the background. Attempts to do so throw an exception. |
Apps that start foreground services while the app is running in the background. |
App components containing intent filters must
declare exported attribute App components that include intent filters must explicitly set the android:exported attribute.
Apps that don't set the attribute cannot be installed on
Android 12. |
Apps that declare the <intent-filter> attribute in
their manifest files. |
Unsafe launches of nested
intents Strict mode testing now detects when your app uses nested intents in an unsafe way. |
Apps that launch another app, expecting a callback through an inner intent. |
Be sure to also review the list of behavior changes that affect all apps running on Android 12.
Privacy
Modern SameSite cookie behaviors in WebView
Android’s WebView component is based on Chromium, the open source project that powers Google’s Chrome browser. Over the last year, Chromium has introduced changes to the handling of third-party cookies to provide more security and privacy and offer users more transparency and control. These changes are already rolled out to many Chrome users, and starting with Android 12, the changes are now coming to WebView.
The SameSite
attribute of a cookie controls whether it can be sent with any
requests, or only with same-site requests. The base version of WebView in
Android 12 (version 89.0.4385.0) includes the following
privacy-protecting changes that improve the default handling of third-party
cookies and help protect against unintended cross-site sharing:
- Cookies without a
SameSite
attribute are treated asSameSite=Lax
. - Cookies with
SameSite=None
must also specify theSecure
attribute, meaning they require a secure context and should be sent over HTTPS. - Links between HTTP and HTTPS versions of a site are now treated as cross-site
requests, so cookies are not sent unless they are appropriately marked as
SameSite=None; Secure
.
For developers, the general guidance is to identify the cross-site cookie
dependencies in your critical user flows and ensure that the SameSite
attribute is explicitly set with the appropriate values where needed. You must
explicitly specify the cookies that are allowed to work across websites or
across same-site navigations that move from HTTP to HTTPS.
For complete guidance for web developers on these changes, see SameSite Cookies Explained and Schemeful SameSite.
Test SameSite behaviors in your app
If your app uses WebView, or if you manage a website or service that uses cookies, we recommend testing your flows on Android 12 WebView. If you find issues, you might need to update your cookies to support the new SameSite behaviors.
Watch for issues in logins and embedded content, as well as sign-in flows, purchasing, and other authentication flows where the user starts on an insecure page and transitions to a secure page.
To test an app with WebView, you must enable the new SameSite behaviors for the app that you want to test by completing either of the following steps:
Manually enable SameSite behaviors on the test device by toggling the UI flag webview-enable-modern-cookie-same-site in the WebView devtools.
This approach lets you test on any device running Android 5.0 (API level 21) or higher—including Android 12—and WebView version 89.0.4385.0 or higher.
Compile your app to target Android 12 by
targetSdkVersion
.If you use this approach, you must use a device that runs Android 12 and WebView version 89.0.4385.0 or higher.
For information on remote debugging for WebView on Android, see Get Started with Remote Debugging Android Devices.
Other resources
For more information about the SameSite modern behaviors and rollout to Chrome and WebView, visit the Chromium SameSite Updates page. If you find a bug in WebView or Chromium, you can report it in the public Chromium issue tracker.
ADB backup restrictions
To help protect private app data, Android 12 changes the default
behavior of the adb backup
command. For apps that target
Android 12, when a user runs the adb backup
command, app data is
excluded from any other system data that is exported from the device.
If your testing or development workflows rely on app data using adb backup
,
you can now opt in to exporting your app's data by setting
android:debuggable
to true
in your app's manifest file.
Security
Safer exporting of components
If your app targets Android 12 and contains
activities,
services, or broadcast
receivers that use intent
filters, you must explicitly
declare the
android:exported
attribute
for these app components.
Warning: If an activity, service, or broadcast receiver uses intent
filters and doesn't have an explicitly-declared value for
android:exported
, your app can't be installed on a device that
runs Android 12.
If you attempt to install such an app when using Android Studio, Logcat displays the following error message:
Installation did not succeed. The application could not be installed: INSTALL_FAILED_VERIFICATION_FAILURE List of apks: [0] '.../build/outputs/apk/debug/app-debug.apk' Installation failed due to: 'null'
If your app doesn't declare a value for android:exported
when it needs to do
so, Logcat provides the following error message:
Targeting S+ (version 10000 and above) requires that an explicit value for \
android:exported be defined when intent filters are present
The following code snippet shows an example of a service that contains an intent filter and is configured correctly for Android 12:
<service android:name="com.example.app.backgroundService" android:exported="false"> <intent-filter> <action android:name="com.example.app.START_BACKGROUND" /> </intent-filter> </service>
Pending intents must declare mutability
If your app targets Android 12, you must specify the mutability
of each PendingIntent
object that your
app creates. This additional requirement improves your app's security.
To declare that a given PendingIntent
object is mutable or immutable, use the
PendingIntent.FLAG_MUTABLE
or
PendingIntent.FLAG_IMMUTABLE
flag, respectively. If your app attempts to create a PendingIntent
object
without setting either mutability flag, the system throws an
IllegalArgumentException
, and
the following message appears in Logcat:
PACKAGE_NAME: Targeting S+ (version 10000 and above) requires that one of \
FLAG_IMMUTABLE or FLAG_MUTABLE be specified when creating a PendingIntent.
Strongly consider using FLAG_IMMUTABLE, only use FLAG_MUTABLE if \
some functionality depends on the PendingIntent being mutable, e.g. if \
it needs to be used with inline replies or bubbles.
Create immutable pending intents whenever possible
In most cases, your app should create immutable PendingIntent
objects, as
shown in the following code snippet. If a PendingIntent
object is immutable,
then an app cannot modify the intent to adjust the result of invoking the
intent.
Kotlin
val pendingIntent = PendingIntent.getActivity(applicationContext, REQUEST_CODE, intent, /* flags */ PendingIntent.FLAG_IMMUTABLE)
Java
PendingIntent pendingIntent = PendingIntent.getActivity(getApplicationContext(), REQUEST_CODE, intent, /* flags */ PendingIntent.FLAG_IMMUTABLE);
However, certain apps need to create mutable PendingIntent
objects instead:
- A direct reply action in a
notification requires a
change to the clip data in the
PendingIntent
object that's associated with the reply. Usually, you request this change by passingFILL_IN_CLIP_DATA
as a flag to thefillIn()
method. - If your app places a conversation in a bubble
using a
PendingIntent
, the intent should be mutable so that the system can apply the correct flags, such asFLAG_ACTIVITY_MULTIPLE_TASK
andFLAG_ACTIVITY_NEW_DOCUMENT
.
If your app creates a mutable PendingIntent
object, it's strongly recommended
that you use an explicit
intent and fill in the
ComponentName
. That way, whenever
another app invokes the PendingIntent
and passes control back to your app, the
same component in your app always starts.
Test the pending intent mutability change
To determine whether your app is missing mutability declarations, look for the following lint warning in Android Studio:
Warning: Missing PendingIntent mutability flag [UnspecifiedImmutableFlag]
During the Developer Preview, you can disable this system behavior for testing
purposes by turning off the
PENDING_INTENT_EXPLICIT_MUTABILITY_REQUIRED
app compatibility flag.
Unsafe launches of nested intents
To improve platform security, Android 12 provides a debugging feature that warns you if your app performs an unsafe launch of a nested intent. A nested intent is an intent that is passed as an extra in another intent. If your app performs both of the following actions, a StrictMode violation occurs.
- Your app unparcels a nested intent from the extras of a delivered intent.
- Your app immediately starts an app
component using that nested intent,
such as passing the intent into
startActivity()
,startService()
, orbindService()
.
Configure your app to detect unsafe launches of nested intents
To check for unsafe launches of nested intents in your app, call
detectUnsafeIntentLaunch()
when you configure your VmPolicy
, as shown in the following code snippet. If
your app detects a StrictMode violation, you might want to stop app execution to
protect potentially sensitive information.
Kotlin
fun onCreate() { StrictMode.setVmPolicy(VmPolicy.Builder() // Other StrictMode checks that you've previously added. // ... .detectUnsafeIntentLaunch() .penaltyLog() // Consider also adding penaltyDeath() .build()) }
Java
protected void onCreate() { StrictMode.setVmPolicy(new VmPolicy.Builder() // Other StrictMode checks that you've previously added. // ... .detectUnsafeIntentLaunch() .penaltyLog() // Consider also adding penaltyDeath() .build()); }
Use intents more responsibly
Your app might launch nested intents to navigate between components inside of your app, or to perform an action on behalf of another app. To minimize the chance of encountering a StrictMode violation in either situation, do the following:
- Internal launch of nested intent: Make sure that these components aren't exported.
Cross-app launch of nested intent: Use a
PendingIntent
instead of a nested intent. That way, when thePendingIntent
is unparceled out of its containingIntent
, an app component can launch thePendingIntent
using the identity of the calling process. This configuration allows a provider app to send a callback to any component, including a non-exported component, of the calling app.For more details on how to identify this situation and make changes to your app, read the blog post about Android Nesting Intents on Medium.
Performance
Foreground service launch restrictions
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 attempts to start a foreground service while running in the background, an exception occurs (except for the few special cases). Consider using WorkManager to schedule and start work while your app runs in the background.
To learn more about how your app is affected, and how you can update your app based on these changes, read the guide about foreground service launch restrictions. You can also look through the WorkManagerSample on GitHub.
Notification trampolines cannot be created from services or broadcast receivers
When users interact with notifications, some apps respond to notification taps by launching an app component that eventually starts the activity that the user finally sees and interacts with. This app component is known as a notification trampoline.
To improve app performance and UX, apps that target Android 12
cannot start activities from
services or
broadcast receivers that are used as
notification trampolines. In other words, after the user taps on a notification,
or an action button within
the notification, your app cannot call
startActivity()
inside of a service or broadcast receiver.
When your app tries to start an activity from a service or broadcast receiver that acts as a notification trampoline, the system prevents the activity from starting, and the following message appears in Logcat:
Indirect notification activity start (trampoline) from PACKAGE_NAME, \
this should be avoided for performance reasons.
Update your app
If your app starts an activity from a service or broadcast receiver that acts as a notification trampoline, complete the following migration steps:
Create a
PendingIntent
object that is associated with one of the following activities:- The activity that users see after they tap on the notification (preferred).
- A trampoline activity, or an activity that starts the activity that users see after they tap on the notification.
Use the
PendingIntent
object that you created in the previous step as part of building your notification.
Toggle the behavior
When testing your app during the Developer Preview, you can enable and disable
this restriction using the NOTIFICATION_TRAMPOLINE_BLOCK
app compatibility
flag.
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.
Custom notification changes
Android 12 changes the appearance of fully custom notifications. Previously, custom notifications were able to use the entire notification area and provide their own layouts and styles. This resulted in anti-patterns that could confuse users or cause layout compatibility issues on different devices.
For apps targeting Android 12, notifications with custom content views will no
longer use the full notification area; instead, the system applies a standard
template. This template ensures that custom notifications have the same
decoration as other notifications in all states, such as the notification's icon
and expansion affordances (in the collapsed state) and the notification's icon,
app name, and collapse affordance (in the expansion state). This behavior is
nearly identical to the behavior of
Notification.DecoratedCustomViewStyle
.
In this way, Android 12 makes all notifications visually consistent and easy to scan, with a discoverable, familiar notification expansion for users.
The following illustration shows a custom notification in the standard template:
The following examples show how custom notifications would render in a collapsed and an expanded state:


The change in Android 12 affects apps that define custom subclasses of
Notification.Style
, or which use
Notification.Builder
’s methods
setCustomContentView(RemoteViews)
,
setCustomBigContentView(RemoteViews)
,
and setCustomHeadsUpContentView(RemoteViews)
.
If your app is using fully custom notifications, we recommend testing with the new template as soon as possible and making the necessary adjustments:
Enable the custom notifications change:
- Change your app's
targetSdkVersion
toS
to enable the new behavior. - Recompile.
- Install your app on a device or emulator running Android 12.
- Change your app's
Test all notifications that use custom views, ensuring they look as you expect in the shade.
Be aware of the custom view measurements. In general, the height afforded to custom notifications is less than before. In the collapsed state, the maximum height of the custom content has decreased from 106dp to 48dp. Also, there is less horizontal space.
To make sure that the "Heads Up" state looks as you expect, don’t forget to raise the importance of the notification channel to "HIGH" (Pops on screen).
Connectivity
When devices targeting Android 12 and higher run on devices with
hardware support, using Peer-to-peer
connections will not disconnect your
existing Wi-Fi connection when creating the connection to the peer device. To
check for support for this feature, use
WifiManager.isMultiStaConcurrencySupported()
.