Welcome to Android 12 Developer Preview! Please give us feedback early and often, and help us make Android 12 the best release yet!

Features and APIs Overview

Android 12 introduces great new features and APIs for developers. The sections below help you learn about features for your apps and get started with the related APIs.

For a detailed list of new, modified, and removed APIs, read the API diff report. For details on new APIs visit the Android API reference — new APIs are highlighted for visibility. Also, to learn about areas where platform changes may affect your apps, be sure to check out Android 12 behavior changes for apps that target Android 12 and for all apps.

User experience

Audio-coupled haptic effect

Android 12 apps can generate haptic feedback derived from an audio session using the phone's vibrator. This provides an opportunity for more immersive game and audio experiences. For example, haptic-enhanced ringtones can help identify callers, or a driving game could simulate the feeling of rough terrain.

See the HapticGenerator reference documentation for more information.

Rounded corner APIs

Android 12 introduces RoundedCorner and WindowInsets.getRoundedCorner(int position), which provide the radius and center point for rounded corners. With these APIs, your app can avoid UI elements being truncated on screens with rounded corners.

When implemented in your app, these APIs have no effect on devices with non-rounded screens.

Image showing a rounded corners with radiuses and a center point

To implement this feature, get the RoundedCorner info through WindowInsets.getRoundedCorner(int position) relative to the bounds of the application. If the app doesn’t take up the whole screen, the API applies the rounded corner by basing the center point of the rounded corner on the window bounds of the app.

The following code snippet shows a simple example for an app to avoid UI truncations by setting a margin of the view based on the info from RoundedCorner. In this case, it is the top right rounded corner.

// Get the top-right rounded corner from WindowInsets.
final WindowInsets insets = getRootWindowInsets();
final RoundedCorner topRight = insets.getRoundedCorner(POSITION_TOP_RIGHT);
if (topRight == null) {

// Get the location of the close button in window coordinates.
int [] location = new int[2];
final int buttonRightInWindow = location[0] + closeButton.getWidth();
final int buttonTopInWindow = location[1];

// Find the point on the quarter circle with a 45 degree angle.
final int offset = (int) (topRight.getRadius() * Math.sin(Math.toRadians(45)));
final int topBoundary = topRight.getCenter().y - offset;
final int rightBoundary = topRight.getCenter().x + offset;

// Check whether the close button exceeds the boundary.
if (buttonRightInWindow < rightBoundary && buttonTopInWindow > topBoundary) {

// Set the margin to avoid truncating.
int [] parentLocation = new int[2];
FrameLayout.LayoutParams lp = (FrameLayout.LayoutParams) closeButton.getLayoutParams();
lp.rightMargin = Math.max(buttonRightInWindow - rightBoundary, 0);
lp.topMargin = Math.max(topBoundary - buttonTopInWindow, 0);

Picture in Picture (PiP) improvements

Android 12 introduces new features for picture-in-picture (PiP) mode. See Picture-in-picture improvements for more information.

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. Apps can still protect from accidental gestures in full-screen gaming experiences so users don't accidentally quit out of their games while playing; all other full-screen or immersive experiences now allow users to navigate their phone with one swipe.

To make this possible, the existing behaviors for non-sticky immersive experiences (BEHAVIOR_SHOW_BARS_BY_TOUCH, BEHAVIOR_SHOW_BARS_BY_SWIPE) are deprecated starting in Android 12. They have been replaced with default behavior (BEHAVIOR_DEFAULT) that allows gestures with one swipe when hiding system bars. This flag exhibits different visual and functional behavior depending on the mode:

  • In three-button mode, visual and functional behavior is the same as immersive mode in versions of Android prior to 12.
  • In gestural navigation mode, the behavior is as follows:
    • Visually, it’s the same as immersive mode in Android 11 and lower.
    • Functionally, gestures are allowed even when the bar is hidden; system back requires only one swipe to invoke instead of the two swipes required for Android 11. No additional swipes are needed to pull down the notification bar or start going Home.

Sticky immersive mode (BEHAVIOR_SHOW_TRANSIENT_BARS_BY_SWIPE) has not changed for Android 12. Note the following backward-compatibility for this feature:

Picture-in-picture behavior improvements

Android 12 introduces behavior improvements for picture-in-picture (PiP) mode. See Picture-in-picture improvements for more information.

New experiences

Rich content insertion

Android 12 introduces a new unified API that lets you receive rich content from any available source: clipboard, keyboard, or drag and drop.

For more information, see Unified API for receiving content.

Graphics and images

AVIF image support

Android 12 introduces support for images that use the AV1 Image File Format (AVIF). AVIF is a container format for images and sequences of images encoded using AV1. It takes advantage of the intra-frame encoded content from video compression. This dramatically improves image quality for the same file size when compared to older image formats, such as JPEG. For an in depth look at the advantages of this format, see Jake Archibald's blog post.

Easier blurs, color filters, and other effects

Android 12 adds the new RenderEffect that applies common graphics effects such as blurs, color filters, Android shader effects, and more to Views and rendering hierarchies. Effects can be combined as either chain effects (which compose an inner and outer effect) or blended effects. Different Android devices may or may not support the feature due to limited processing power.

Effects can also be applied to the underlying RenderNode for Views by calling View.setRenderEffect(RenderEffect).

To implement a RenderEffect:

view.setRenderEffect(RenderEffect.createBlurEffect(radiusX, radiusY, SHADER_TILE_MODE))

Native animated image decoding

Give feedback icon We'd love to hear your feedback about these new features of the NDK ImageDecoder API. Take a short survey to tell us what you think. In particular, let us know what use cases in your app are affected by this change.

In Android 12, the NDK ImageDecoder API has been expanded to decode all frames and timing data from images that use the animated GIF and animated WebP file formats. When it was introduced in Android 11, this API decoded only the first image from animations in these formats.

Use ImageDecoder instead of third-party libraries to further decrease APK size and benefit from future updates related to security and performance.

For more details on the API, refer to the API reference and the sample on GitHub.


Compatible media transcoding

Android 12 can automatically transcode HEVC(H.265) and HDR (HDR10 and HDR10+) videos recorded on the device to AVC (H.264), a format which is widely compatible with standard players. This takes advantage of modern codecs when they are available without sacrificing compatibility with older applications.

See compatible media transcoding for more details.

MediaDrm updates

In order to determine whether a secure decoder component is required with the current MediaDrm APIs, you must follow these steps:

  1. Create a MediaDrm.
  2. Open a session to obtain a session id.
  3. Create a MediaCrypto using the session id.
  4. Call MediaCrypto.requiresSecureDecoderComponent(mimeType).

With the new methods requiresSecureDecoder(@NonNull String mime) and requiresSecureDecoder(@NonNull String mime, @SecurityLevel int level) you can determine this as soon as you create a MediaDrm.


Hide application overlay windows

To give developers more control over what users see when they interact with the developer's app, Android 12 introduces the ability to hide overlay windows for apps that have been granted the SYSTEM_ALERT_WINDOW permission.

After declaring the HIDE_OVERLAY_WINDOWS permission, an app can call setHideOverlayWindows() to indicate that all windows of type TYPE_APPLICATION_OVERLAY should be hidden when the app's own window is visible. Apps might choose to do this when displaying sensitive screens, such as transaction confirmation flows.

Apps that show windows of type TYPE_APPLICATION_OVERLAY should consider alternatives that may be more appropriate for their use case, such as picture-in-picture or bubbles.

Known signers permission protection flag

Android 12 introduces the knownCerts attribute for signature-level permissions. This attribute allows you to refer to the digests of known signing certificates at declaration time.

Your app can declare this attribute and use the new knownSigner flag in the protectionLevel attribute for a given signature-level permission. When your app does this, the system grants the permission to a requesting app if any signer in the requesting app's signing lineage, including the current signer, matches one of the digests that's declared with the permission in the knownCerts attribute.

The knownSigner flag allows devices and apps to grant signature permissions to other apps without having to sign the apps at the time of device manufacturing and shipment.

Device properties attestation

Android 12 expands the set of apps that can verify the device properties that are in an attestation certificate when these apps generate a new key.

As of Android 9 (API level 28), device policy owners (DPOs) that use Keymaster 4.0 or higher can verify the device properties in these attestation certificates. Starting in Android 12, any app that targets Android 12 can perform this verification using the setDevicePropertiesAttestationIncluded() method.

The generated device properties include the following Build fields:


Secure lockscreen notification actions

Android 12 adds the new setAuthenticationRequired flag to Notification.Action.Builder. This flag lets you add an extra layer of security to notifications on locked devices.

When this flag is applied with a value of true to a given notification action, a user invoking that action on a locked device always results in an authentication request. Previously, the system requested authentication on locked devices only if the user’s invoking of a notification action launched an activity or was a direct reply.

To implement this feature, add setAuthenticationRequired to a notification action:

Notification n1 = new Notification.Builder(context, NotificationListenerVerifierActivity.TAG)
.addAction(new Notification.Action.Builder(R.drawable.ic_stat_charlie,
context.getString(R.string.action_test_title), makeBroadcastIntent(context))

// Make sure this notification action will always request authentication when
// invoked from a lock screen 



Bandwidth estimation improvements

Give feedback icon We'd love to hear your feedback about these improvements to the bandwidth estimation APIs. Take a short survey to tell us what you think. In particular, let us know what use cases in your app are affected by this change.

In Android 12, the bandwidth estimation capabilities provided by getLinkDownstreamBandwidthKbps() and getLinkUpstreamBandwidthKbps() are improved for both Wi-Fi and cellular connectivity. The values returned now represent the user’s all-time weighted average throughput per carrier or WiFi SSID, network type, and signal level, across all applications on the device. This can return a more-accurate and realistic estimate of expected throughput, provide estimates on a cold start of your application, and requires fewer cycles when compared to using other throughput estimation methods.

Keeping companion apps awake

To support the need of companion apps to stay running to manage the device, Android 12 introduces APIs that do the following:

  • Enable you to wake an app when a companion device is within range.
  • Guarantee that the process will continue running while the device stays within range.

To use the APIs, your devices must be connected using Companion Device Manager. For more information, see CompanionDeviceManager.startObservingDevicePresence() and CompanionDeviceService.onDeviceAppeared().

Companion Device Manager profiles

Partner apps that target Android 12 and higher can now use companion device profiles when connecting to a watch. Using a profile simplifies the enrollment process by bundling the granting of a device-type-specific set of permissions into one step.

Screenshot of a phone showing a prompt offering to grant

The bundled permissions are granted to the companion app once the device connects, and last only while the device is associated. Deleting the app or removing the association removes the permissions.

For more information, see AssociationRequest.Builder.setDeviceProfile().

Wi-Fi Aware (NAN) enhancements

Android 12 adds some enhancements to Wi-Fi Aware:

  • On devices running Android 12 and higher, you can use the onServiceLost() callback to be alerted when your app has lost a discovered service due to the service stopping or moving out of range.
  • The way that multiple data-paths (NAN Data Paths) are set up is changing to be more efficient. Earlier versions used L2 messaging to exchange peer information of the initiators, which introduced latency. On devices running Android 12 and higher, the responder (server) can be configured to accept any peer—that is, it doesn’t need to know the initiator information upfront. This speeds up datapath bringup and enables multiple point-to-point links with only one network request.
  • To prevent the framework from rejecting discovery or connection requests due to running out of resources, on devices running Android 12 and higher, you can call WifiAwareManager.getAvailableAwareResources(). This method's return value lets you get the number of available data paths, the number of available publish sessions, and the number of available subscribe sessions.

STA+STA connectivity support

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().