Ensure your WebViews are compatible with Android 16, as Android 16 removes the ability to opt-out of drawing your app edge-to-edge. The way you handle insets for WebViews depends on whether or not your app owns the web content.

This post assumes basic knowledge of handling insets and is applicable if your WebViews are drawing underneath system bars or display cutouts. See the Compose and Views documentation, and the Inset handling tips blog for guidance on handling insets.

If you’re looking for guidance on how to make your webpage edge-to-edge on Chrome, see the Chrome on Android edge-to-edge migration guide instead.

This post covers the following topics:

• How to handle WebViews if your app doesn’t own the web content
• How to handle WebViews if your app owns the web content
• Handling IME insets in WebViews

If your app doesn’t own the web content

WebViews displaying external content cannot easily draw edge-to-edge and should instead be inset to avoid the system bars and display cutout. The implementation is different depending on if you’re using Compose or Views, but generally follows these steps:

1. Wrap the WebView in a container and apply insets as padding on that container.
2. Set the app’s background color in a best-effort attempt to match the webpage.

See the following code samples.

Apply insets to a WebView in a Compose app

To ensure a WebView in Compose avoids overlapping with system bars, display cutout and keyboard, apply Modifier.windowInsetsPadding(WindowInsets.safeDrawing) to its wrapper (e.g. AndroidView). This provides the necessary padding to keep the WebView content within the safe area of the screen.

@Composable
fun WebViewInCompose() {
    AndroidView(
        modifier = Modifier.windowInsetsPadding(WindowInsets.safeDrawing),
        factory = { context ->
            WebView(context).apply {
                // Configure WebView options here
            }
        }
    )
}

Then, update your app’s background so it matches the WebView’s background as much as possible.

Apply insets to a WebView in a Views app

To ensure a WebView in Views avoids overlapping the system bars, display cutout and keyboard, wrap the WebView in a container like a FrameLayout and do one of the following:

• Set android:fitsSystemWindows="true"
• Use ViewCompat.setOnApplyWindowInsetsListener() and apply systemBars, displayCutout, and ime insets on the container. See the Views documentation for a code sample using the listener.

Finally, update android:windowBackground in your themes.xml so it matches the WebView’s background if possible.

If your app owns the web content

If your app owns the web content, either pad the WebView’s parent as described above; or, use JavaScript to inject padding into the web page to draw the page edge-to-edge as described below.

To inject padding into the web page, first add <meta name=”viewport” content=”viewport-fit=cover”> to your HTML.

<meta name="viewport" content="viewport-fit=cover, initial-scale=1" />

Second, define CSS variables for top, right, bottom and left safe area insets, as the env(safe-area-inset-*) variables return 0px on Android at the time of writing this blog.

/* CSS */
body {
  padding-top: var(--safe-area-inset-top);
  padding-right: var(--safe-area-inset-right);
  padding-bottom: var(--safe-area-inset-bottom);
  padding-left: var(--safe-area-inset-left);
}

Instead of applying insets on the WebView’s container, use JavaScript to pass the insets to your CSS variables to pad the webpage. The implementation is different depending on if you’re using Compose or Views, but it generally follows these steps:

1. Retrieve the top, right, bottom and left system bar, display cutout and IME insets as raw pixel values.
2. Convert the raw pixel values to density independent pixels.
3. Inject the density independent pixels into the CSS variables as CSS pixels. When the website renders on the Android device, the WebView converts the CSS pixels back to density independent pixels. See Support different screens in web apps for more information.
4. In Compose, recompose when the software keyboard expands or collapses if applicable.
5. In Views, dispatch insets when the webpage first loads.

See the following code samples.

Using Compose and JavaScript to inject insets into web pages

A code sample showing how to use JavaScript to inject insets into webpages in a Compose app.

import android.webkit.WebView
import android.webkit.WebViewClient
import androidx.compose.foundation.layout.WindowInsets
import androidx.compose.foundation.layout.ime
import androidx.compose.foundation.layout.safeDrawing
import androidx.compose.ui.unit.Dp
...

@Composable
fun MainScreen() {
    Box(modifier = Modifier.fillMaxSize()) {
        
        // Retrieve insets as raw pixels
        val insets = WindowInsets.safeDrawing
        WebViewInCompose(
            initialUrl = "file:///android_asset/example.html",
            insets = insets
        )
    }
}

@SuppressLint("SetJavaScriptEnabled")
@Composable
fun WebViewInCompose(
    initialUrl: String,
    insets: WindowInsets,
    density: Density = LocalDensity.current,
    layoutDirection: LayoutDirection = LocalLayoutDirection.current,
    myWebViewClient: CustomWebViewClient = remember { CustomWebViewClient(
        insets, density, layoutDirection
    ) }
) {
    
    // Don't apply insets to the container 
    AndroidView(
        factory = { context ->
            WebView(context).apply {
                webViewClient = myWebViewClient
                settings.javaScriptEnabled = true
                loadUrl(initialUrl)
            }
        }, update = { view ->
            
            // Updates webpage when software keyboard expands or collapses.
            // If your webpage doesn't have an input field that opens the 
            // software keyboard, remove this line.
            applySafeAreaInsetsToWebView(insets, density, layoutDirection, view)
        }
    )
}

class CustomWebViewClient(
    private val insets: WindowInsets,
    private val density: Density,
    private val layoutDirection: LayoutDirection
) : WebViewClient(){

    override fun onPageFinished(view: WebView?, url: String?) {
        super.onPageFinished(view, url)
        
        // Inject insets into the webpage once the page has fully loaded
        applySafeAreaInsetsToWebView(insets, density, layoutDirection, view)
    }
}

private fun applySafeAreaInsetsToWebView(
    insets: WindowInsets,
    density: Density,
    layoutDirection: LayoutDirection,
    webView: WebView?){

    // Convert raw pixels to density independent pixels
    val top = insets.getTop(density).toDp(density).value
    val right = insets.getRight(density, layoutDirection).toDp(density).value
    val bottom = insets.getBottom(density).toDp(density).value
    val left = insets.getLeft(density, layoutDirection).toDp(density).value

    val safeAreaJs = """
            document.documentElement.style.setProperty('--safe-area-inset-top', '${top}px');
            document.documentElement.style.setProperty('--safe-area-inset-right', '${right}px');
            document.documentElement.style.setProperty('--safe-area-inset-bottom', '${bottom}px');
            document.documentElement.style.setProperty('--safe-area-inset-left', '${left}px');
            """

    // Inject the density independent pixels into the CSS variables as CSS pixels
    webView?.evaluateJavascript(safeAreaJs, null)
}

private fun Int.toDp(density: Density): Dp = with(density) { this@toDp.toDp() }

Using Views and JavaScript to inject insets into web pages

A code sample showing how to use JavaScript to inject insets into webpages in a Views app.

import androidx.core.util.TypedValueCompat.pxToDp
import 
androidx.core.view.WindowInsetsCompat.Type.displayCutout
import androidx.core.view.WindowInsetsCompat.Type.ime
import androidx.core.view.WindowInsetsCompat.Type.systemBars
...

override fun onCreate(savedInstanceState: Bundle?) {
    ...

    val myWebView: WebView = findViewById(R.id.webView)
    myWebView.settings.javaScriptEnabled = true
    myWebView.loadUrl("file:///android_asset/example.html")

    ViewCompat.setOnApplyWindowInsetsListener(myWebView) { _, windowInsets ->
        
        // Retrieve insets as raw pixels
        val safeDrawingInsets = windowInsets.getInsets(
            systemBars() or displayCutout() or ime()
        )
        val displayMetrics = myWebView.context.resources.displayMetrics

        // Convert raw pixels to density independent pixels 
        val top = pxToDp(safeDrawingInsets.top.toFloat(), displayMetrics)
        val right = pxToDp(safeDrawingInsets.right.toFloat(), displayMetrics)
        val bottom = pxToDp(safeDrawingInsets.bottom.toFloat(), displayMetrics)
        val left = pxToDp(safeDrawingInsets.left.toFloat(), displayMetrics)

        val safeAreaJs = """
            document.documentElement.style.setProperty('--safe-area-inset-top', '${top}px');
            document.documentElement.style.setProperty('--safe-area-inset-right', '${right}px');
            document.documentElement.style.setProperty('--safe-area-inset-bottom', '${bottom}px');
            document.documentElement.style.setProperty('--safe-area-inset-left', '${left}px');
            """

        // Inject the density independent pixels into the CSS variables as CSS pixels
        myWebView.evaluateJavascript(safeAreaJs, null)

        windowInsets
    }

    myWebView.webViewClient = object : WebViewClient() {
        override fun onPageFinished(view: WebView, url: String) {
            super.onPageFinished(myWebView, url)
            // dispatch insets because insets aren't applied when the webpage first loads.
            view.requestApplyInsets()
        }
    }
}

Note: If the injected insets look too large, it might be because your website’s Viewport initial-scale is more than 1. In this case, divide the top, right, bottom, and left variables by the scale.

Handling IME insets in WebViews

To ensure your web page correctly adjusts when the on-screen keyboard (IME) appears, you must also account for IME insets. The provided Compose and Views code example already includes this by retrieving WindowInsets.safeDrawing() in Compose or WindowInsetsCompat.Type.ime() in Views:

// Getting IME insets from the above Compose code sample
// safeDrawing includes ime, systemBars, and displayCutout
WindowInsets.safeDrawing


// Getting IME insets from the above Views code sample
val safeDrawingInsets = windowInsets.getInsets(
    systemBars() or displayCutout() or ime()
)

Omitting IME insets will lead to issues where the webpage content is obscured by the keyboard. For example, when the user taps an HTML text input and the IME expands, the webpage won’t resize, preventing the user from seeing content hidden behind the keyboard. By including IME insets, the webpage dynamically adjusts its layout when the IME is displayed, ensuring all content remains accessible to the user.

In summary, ensuring WebViews are compatible with an edge-to-edge display requires different approaches depending on whether the app owns the web content. For external content, wrap the WebView in a container and apply insets as padding. For owned content, either pad the container or inject JavaScript to handle insets within the webpage.

The code snippets in this blog have the following license:

// Copyright 2024 Google LLC. SPDX-License-Identifier: Apache-2.0

Make WebViews edge-to-edge was originally published in Android Developers on Medium, where people are continuing the conversation by highlighting and responding to this story.

This blog post is part of our series: Spotlight Week on Android 15, where we provide resources — blog posts, videos, sample code, and more — all designed to help you prepare your apps and take advantage of the latest features in Android 15. You can read more in the overview of Spotlight Week: Android 15 here, which will be updated throughout the week.

Users prefer edge-to-edge over non edge-to-edge screens for both gesture navigation and three button navigation, according to an internal Google user study.

Android 15 enforces edge-to-edge

Before target SDK 35 (Android 15), your app does not draw edge-to-edge without explicit code changes to intentionally go edge-to-edge. After setting targetSdk=35 or higher, the system will draw your app edge-to-edge by default on Android 15 and later devices. While this change can make it easier for many apps to go edge-to-edge, critical UI elements may also be inaccessible to users. Your app must handle insets to ensure critical UI elements remain accessible.

If your app is already edge-to-edge or in immersive mode, you’re unaffected. However, it’s still worth testing your app for breakages.

Insets handling tips

There are various APIs and attributes you can use to handle insets to avoid the System UI and display cutout.

This article explains the following tips that are applicable to Compose and Views:

1. Use material components to make handling insets easier
2. Draw backgrounds edge-to-edge, and inset critical UI
3. Handle display cutout and caption bar insets
4. Don’t forget the last list item
5. Don’t forget IMEs
6. For backwards compatibility, use enableEdgeToEdge instead of setDecorFitsSystemWindows
7. Background protect system bars only when necessary

It also provides these tips that are specific to Compose:

8. Use Scaffold’s PaddingValues

9. Use high level WindowInset APIs

Finally, it includes these tips specific to Views:

10. Prefer ViewCompat.setOnApplyWindowInsetsListener over fitsSystemWindows=true

11. Apply insets based on app bar height on bar layout

1. Use material components to make handling insets easier

Many material components automatically handle insets, meaning the component’s background draws inside the system bar region and pads critical UI (see tip #2). Some material components do not automatically handle insets, but instead provide methods to make handling insets easier.

Material 3 Components (androidx.compose.material3) that automatically handle insets:

• BottomAppBar
• CenterAlignedTopAppBar
• DismissibleDrawerSheet
• LargeTopAppBar
• MediumTopAppBar
• ModalBottomSheet
• ModalDrawerSheet
• NavigationBar
• NavigationRail
• NavigationSuiteScaffold
• PermanentDrawerSheet
• TopAppBar
• SmallTopAppBar

Material 2 Components (androidx.compose.material) don’t automatically handle insets themselves by default, unlike Material 3 components. Consider updating to Material 3 Components. Otherwise, many Material 2 components support specifying the window insets to apply with the windowInsets parameter, like the BottomAppBar, TopAppBar, BottomNavigation, and NavigationRail. Likewise, use the contentWindowInsets parameter for Scaffold. Otherwise, apply the insets as padding.

Material View Components (com.google.android.material) that automatically handle insets:

• BottomAppBar
• BottomNavigationView
• NavigationRailView
• NavigationView

2. Draw backgrounds edge-to-edge, and inset critical UI.

Oftentimes, apps will set the system bars to the same color as the app bars to appear edge-to-edge, which is an anti-pattern.

Apps using this anti-pattern do not appear edge-to-edge all the time, especially on large screen devices.

To improve this app’s UX after edge-to-edge is enforced, extend the background of the app bars so they draw underneath the transparent system bars, then inset the text and buttons to avoid the system bars. Material 3 components TopAppBars and BottomAppBars do this automatically. For Material 2 components, use the windowInsets parameter. For Views, some Material components handle this automatically. Otherwise, you’ll use fitsSystemWindows or ViewCompat.setOnApplyWindowInsetsListener.

3. Handle display cutout and caption bar insets

While handling insets, account for the display cutouts and caption bars in addition to the status and navigation bars.

Display cutouts

A display cutout often contains the camera. After targeting SDK 35, your app might have important UI under the display cutout, especially when the cutout is on the left or right edges of the device.

For example, prior to targeting SDK 35, your app might have a large white box to account for a camera cutout in landscape.

After targeting SDK 35, the white box disappears and all content moves to the left. Some content draws underneath the camera cutout.

Handling display cutouts in Compose

In Compose, easily handle display cutouts using WindowInsets.safeContent, WindowInsets.safeDrawing, or WindowInsets.safeGestures. Or, use WindowInsets.displayCutout for fine-grained control. Unfortunately, at the time of writing this blog, Scaffold’s PaddingValues does not yet account for the display cutout.

// Shows using WindowInsets.displayCutout for fine-grained control.
// But, it's often sufficient and easier to instead use
// WindowInsets.safeContent, WindowInsets.safeDrawing, or WindowInsets.safeGestures
@Composable
fun ChatRow(...) {
   val layoutDirection = LocalLayoutDirection.current
   val displayCutout = WindowInsets.displayCutout.asPaddingValues()
   val startPadding = displayCutout.calculateStartPadding(layoutDirection)
   val endPadding = displayCutout.calculateEndPadding(layoutDirection)
   Row(
       modifier = modifier.padding(
               PaddingValues(
                   top = 16.dp,
                   bottom = 16.dp,
                   // Ensure content is not hidden by display cutouts
                   // when rotating the device.
                   start = startPadding.coerceAtLeast(16.dp),
                   end = endPadding.coerceAtLeast(16.dp)
               )
           ),
       ...
   ) { ... }

After handling display cutouts, the app looks like this:

You can test various display cutout configurations on the Developer options screen under Display cutout.

Learn more about this example in the codelab, Handle edge-to-edge enforcements in Android 15.

Handling display cutouts in Views

In Views, handle display cutouts using WindowInsetsCompat.Type.displayCutout. See the documentation for a code sample.

Note: If your app has a non-floating window (for example, an Activity) that is using LAYOUT_IN_DISPLAY_CUTOUT_MODE_DEFAULT, LAYOUT_IN_DISPLAY_CUTOUT_MODE_NEVER or LAYOUT_IN_DISPLAY_CUTOUT_MODE_SHORT_EDGES, Android will interpret these cutout modes to be LAYOUT_IN_DISPLAY_CUTOUT_MODE_ALWAYS starting in Android 15, causing your window to draw into the display cutout region. Ensure to test your screens that use DEFAULT, NEVER, or SHORT_EDGES.

Caption bars

When your app appears in a desktop emulator or in a free form window, it has a caption bar instead of a status bar.

While handling insets in Compose, use either Scaffold’s PaddingValues, WindowInsets.safeContent, WindowInsets.safeDrawing, or WindowInsets.systemBars, which all include the caption bar. Don’t use WindowInsets.statusBars.

In your app’s View-based layouts, use WindowInsetsCompat.Type.systemBars. Don’t use WindowInsetsCompat.Type.statusBars.

4. Don’t forget the last list item

After targeting SDK 35, the last item of your lists might be inaccessible, especially if it’s behind three-button navigation or the taskbar.

Handling the last list item in Compose

To handle the last list item in Compose, use LazyColumn’s contentPadding to add a space to the last item unless you are using TextField:

Scaffold { innerPadding ->
    LazyColumn(
        contentPadding = innerPadding
    ) {
        // Content that does not contain TextField
    }
}

For TextField, use a Spacer to draw the last TextField in a LazyColumn. For an in-depth overview of handling insets with lists, see Inset consumption.

LazyColumn(
    Modifier.imePadding()
) {
    // Content with TextField
    item {
        Spacer(
            Modifier.windowInsetsBottomHeight(
                WindowInsets.systemBars
            )
        )
    }
}

Handling the last list item in Views

Adding clipToPadding=”false” can ensure the last list item appears above the navigation bar for RecyclerView or NestedScrollView. Take this app for example. After targeting SDK 35, the app’s list UI shows the last list item underneath the navigation bar.

We can use the window inset listener so that all list items, including the last list item, are padded above the navigation bar.

// Figure 12
ViewCompat.setOnApplyWindowInsetsListener(
    findViewById(R.id.recycler_view)
) { v, insets ->
    val innerPadding = insets.getInsets(
        // Notice we're using systemBars, not statusBar
        WindowInsetsCompat.Type.systemBars()
        // Notice we're also accounting for the display cutouts
        or WindowInsetsCompat.Type.displayCutout()
        // If using EditText, also add 
        // "or WindowInsetsCompat.Type.ime()"
        // to maintain focus when opening the IME
    )
    v.setPadding(
        innerPadding.left,
        innerPadding.top,
        innerPadding.right,
        innerPadding.bottom)
    insets
}

However, now the app looks less immersive. To get the result we want, add clipToPadding=false to ensure the last list item sits above the navigation bar and the list is visible while scrolling behind the navigation bar (and status bar).

<!-- Figure 13 -->
<RecyclerView
    ...
    android:clipToPadding="false" />

5. Don’t forget IMEs

Set android:windowSoftInputMode=”adjustResize” in your Activity’s AndroidManifest.xml entry to make room for the IME (or soft keyboard) on screen.

Handling IMEs insets in Compose

Account for the IME using Modifier.imePadding(). For example, this can help maintain focus on a TextField in a LazyColumn when the IME opens. See the Inset consumption section for a code example and explanation.

Handling IMEs insets in Views

Before targeting SDK 35, using android:windowSoftInputMode=”adjustResize” was all you needed to maintain focus on — for example — an EditText in a RecyclerView when opening an IME. With “adjustResize”, the framework treated the IME as the system window, and the window’s root views were padded so content avoids the system window.

After targeting SDK 35, you must also account for the IME using ViewCompat.setOnApplyWindowInsetsListener and WindowInsetsCompat.Type.ime() because the framework will not pad the window’s root views. See Figure 12's code example.

6. For backward compatibility, use enableEdgeToEdge instead of setDecorFitsSystemWindows

After your app has handled insets, make your app edge-to-edge on previous Android versions. For this, use enableEdgeToEdge instead of setDecorFitsSystemWindows. The enableEdgeToEdge method encapsulates the about 100 lines of code you need to be truly backward compatible.

7. Background protect system bars only when necessary

In many cases, keep the new Android 15 defaults. The status bar and gesture navigation bar should be transparent, and three button navigation translucent after targeting SDK 35 (see Figure 1).

However, there are some cases where you wish to preserve the background color of the system bars, but the APIs to set the status and navigation bar colors are deprecated. We are planning to release an AndroidX library to support this use case. In the meantime, if your app must offer custom background protection to 3-button navigation or the status bar, you can place a composable or view behind the system bar using WindowInsets.Type#tappableElement() to get the 3-button navigation bar height or WindowInsets.Type#statusBars.

For example, to show the color of the element behind the 3-button navigation in Compose, set the window.isNavigationBarContrastEnforced property to false. Setting this property to false makes 3-button navigation fully transparent (note: this property does not affect gesture navigation).

Then, use WindowInsets.tappableElement to align UI behind insets for tappable system UI. If non-0, the user is using tappable bars, like three button navigation. In this case, draw an opaque view or box behind the tappable bars.

class MainActivity : ComponentActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContent {
            window.isNavigationBarContrastEnforced = false
            MyTheme {
                Surface(...) {
                    MyContent(...)
                    ProtectNavigationBar()
                }
            }
        }
    }
}


// Use only if required.
@Composable
fun ProtectNavigationBar(modifier: Modifier = Modifier) {
   val density = LocalDensity.current
   val tappableElement = WindowInsets.tappableElement
   val bottomPixels = tappableElement.getBottom(density)
   val usingTappableBars = remember(bottomPixels) {
       bottomPixels != 0
   }
   val barHeight = remember(bottomPixels) {
       tappableElement.asPaddingValues(density).calculateBottomPadding()
   }

   Column(
       modifier = modifier.fillMaxSize(),
       verticalArrangement = Arrangement.Bottom
   ) {
       if (usingTappableBars) {
           Box(
               modifier = Modifier
                   .background(MaterialTheme.colorScheme.background)
                   .fillMaxWidth()
                   .height(barHeight)
           )
       }
   }
}

Inset handling tips for UIs that use Compose

The following tips apply only for apps that use Jetpack Compose. See additional Compose-related tips in this video: Edge-to-edge and insets | Compose Tips.

8. Use Scaffold’s PaddingValues

For Compose, use Scaffold instead of Surface to organize your app’s UI with TopAppBar, BottomAppBar, NavigationBar, and NavigationRail. Use Scaffold’s PaddingValues parameter to inset your critical UI. In most cases, that’s all you need to do.

However, there are cases where applying Scaffold’s PaddingValues will cause unexpected results. Scaffold’s PaddingValues includes insets for the top, bottom, start and end edges of the screen. You may need values for only certain edges. One approach is to make a copy of the parameter and manually adjust top, bottom, start and end insets so as to not apply too much padding.

Here’s the incorrect code, causing the excess padding seen in the middle image of Figure 14.

// Causes excess padding, seen in the middle image of Figure 14.
Scaffold { innerPadding -> // innerPadding is Scaffold's PaddingValues
    InputBar(
        ...
        contentPadding = innerPadding
     ) {...}
}

Here’s the corrected code that generates proper padding, as seen in the right-side image of Figure 14.

// Function to make a copy of PaddingValues, using existing defaults unless an
// alternative value is specified
​​private fun PaddingValues.copy(
    layoutDirection: LayoutDirection,
    start: Dp? = null,
    top: Dp? = null,
    end: Dp? = null,
    bottom: Dp? = null,
) = PaddingValues(
    start = start ?: calculateStartPadding(layoutDirection),
    top = top ?: calculateTopPadding(),
    end = end ?: calculateEndPadding(layoutDirection),
    bottom = bottom ?: calculateBottomPadding(),
)

// Produces correct padding, seen in the right-side image of Figure 14.
Scaffold { innerPadding -> // innerPadding is Scaffold's PaddingValues
    val layoutDirection = LocalLayoutDirection.current
    InputBar(
        ...
        contentPadding = innerPadding.copy(layoutDirection, top = 0.dp)
    ) {...}
}

9. Use high level WindowInsets APIs

Similar to Scaffold’s PaddingValues, you can also use the high-level WindowInset APIs to easily and safely draw critical UI elements. These are:

• WindowInsets.safeDrawing
• WindowInsets.safeGestures
• WindowInsets.safeContent

See Inset fundamentals to learn more.

Inset handling tips for UIs that use Views

The following apply only for Views-based apps.

10. Prefer ViewCompat.setOnApplyWindowInsetsListener over fitsSystemWindows=true

You could use fitsSystemWindows=true to inset your app’s content. It’s an easy 1-line code change. However, don’t use fitsSystemWindows on a View that contains your entire layout (including the background). This will make your app look not edge-to-edge because fitsSystemWindows handles insets on all edges.

fitsSystemWindows can create an edge-to-edge experience if using CoordinatorLayouts or AppBarLayouts.Add fitsSystemWindows to the CoordinatorLayout and the AppBarLayout, and the AppBarLayout draws edge-to-edge, which is what we want.

<!-- Figure 17 -->
<CoordinatorLayout
    android:fitsSystemWindows="true"
    ...>
    <AppBarLayout
        android:fitsSystemWindows="true"
        ...>
        <TextView
            android:text="App Bar Layout"
            .../>
    </AppBarLayout>
</CoordinatorLayout>

In this case, AppBarLayout used fitsSystemWindows to draw underneath the status bar rather than avoiding it, which is the opposite of what we might expect. Furthermore, AppBarLayout with fitsSystemWindows=true only applies padding for the top and not the bottom, start, or end edges.

The CoordinatorLayout and AppBarLayout objects have the following behavior when overriding fitsSystemWindows:

• CoordinatorLayout: backgrounds of child views draw underneath the system bars if those views also set fitsSystemWindows=true. Padding is automatically applied to the content of those Views (e.g. text, icons, images) to account for system bars and display cutouts.
• AppBarLayout: draws underneath the system bars if fitsSystemWindows=true and automatically applies top padding to content.

In most cases, handle insets with ViewCompat.setOnApplyWindowInsetsListener because it allows you to define which edges should handle insets and has consistent behavior. See tips #4 and #11 for a code example.

11. Apply insets based on app bar height during the layout phase

If you find that your app’s content is hiding underneath an app bar, you might need to apply insets after the app bar is laid out, taking the app bar height into account.

For example, if you have scrolling content underneath an AppBarLayout in a FrameLayout, you could use code like this to ensure the scrolling content appears after the AppBarLayout. Notice padding is applied within doOnLayout.

val myScrollView = findViewById<NestedScrollView>(R.id.my_scroll_view)
val myAppBar = findViewById<AppBarLayout>(R.id.my_app_bar_layout)


ViewCompat.setOnApplyWindowInsetsListener(myScrollView) { scrollView, windowInsets ->
   val insets = windowInsets.getInsets(
       WindowInsetsCompat.Type.systemBars() or WindowInsetsCompat.Type.displayCutout()
   )
   myAppBar.doOnLayout { appBar ->
       scrollView.updatePadding(
           left = insets.left,
           right = insets.right,
           top = appBar.height,
           bottom = insets.bottom
       )
   }
   WindowInsetsCompat.CONSUMED
}

Likewise, if you have scrolling content that should sit above a BottomNavigationView, you’ll want to account for the BottomNavigationView’s height once it is laid out.

Need more time to migrate?

It might take significant work to properly support an edge-to-edge experience. Before you target SDK 35, consider how long you need to make the necessary changes in your app.

If you need more time to handle insets to be compatible with the system’s default edge-to-edge behavior, you can temporarily opt-out using R.attr#windowOptOutEdgeToEdgeEnforcement. But do not plan to use this flag indefinitely as it will be non-functional in the near future.

The flag might be particularly helpful for apps that have tens to hundreds of Activities. You might opt-out each Activity, then — make your app edge-to-edge one Activity at a time.

Here’s one approach to using this flag. Assuming your minSDK is less than 35, this attribute must be in values-v35.xml.

<!-- In values-v35.xml -->
<resources>
    <!-- TODO: Remove once activities handle insets. -->
    <style name="OptOutEdgeToEdgeEnforcement">
        <item name="android:windowOptOutEdgeToEdgeEnforcement">true</item>
    </style>
</resources>

Create an empty style for past versions in values.xml:

<!-- In values.xml -->
<resources>
    <!-- TODO: Remove once activities handle insets. -->
    <style name="OptOutEdgeToEdgeEnforcement">
        <!-- android:windowOptOutEdgeToEdgeEnforcement
             isn't supported before SDK 35. This empty
             style enables programmatically opting-out. -->
    </style>
</resources>

Call the style before accessing the decor view in setContentView:

class MainActivity : AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {

        // Call before the DecorView is accessed in setContentView
        theme.applyStyle(R.style.OptOutEdgeToEdgeEnforcement, /* force */ false)

        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)
        ...
    }
}

Resources

Android 15 AOSP released today. Our team has created blogs, videos, and codelabs to help get your app ready to handle the Android 15 edge-to-edge enforcement. What follows is a list of old and new resources for further learning.

Documentation

• Behavior changes for apps targeting Android 15: Edge-to-edge enforcement
• Window insets in Compose
• Cutouts in Compose
• Display content edge-to-edge in your app (Views)
• Support display cutouts (Views)

Videos

• Edge to Edge & Insets (Compose)
• Insets: Compose edition
• 3 things to improve the user experience of your Android app: Handle edge-to-edge enforcements in Android 15 walkthrough (Compose)

Codelabs

Handle edge-to-edge enforcements in Android 15 (Compose)

Insets handling tips for Android 15’s edge-to-edge enforcement was originally published in Android Developers on Medium, where people are continuing the conversation by highlighting and responding to this story.

Android 15 Beta 3, two Compose case studies, Google AI Studio, Gemini in Android Studio, and lots of stable AndroidX releases.

Welcome to episode 108 of Now in Android: your ongoing guide to what’s new and notable in the world of Android development.

In this episode, we’ll cover Android 15 Beta 3, two Compose case studies, Google AI Studio, Gemini in Android Studio, and lots of stable AndroidX releases.

Most of the content of this post is available in the form of a video or podcast, so feel free to watch or listen rather than read on. (Or do all three to help you remember! There won’t be a quiz.)

The Third Beta of Android 15 🧑‍💻

Android 15 Beta 3 is released, taking Android 15 to Platform Stability. This means the developer APIs and all app-facing behaviors are final for you to review. Also, Apps targeting Android 15 can be published in Google Play.

The Beta 3 post highlights how users will be able to sign-into apps that target Android 15 using passkeys in a single step with facial recognition, fingerprint, or screen lock.

The post also covers how the WebSettings DatabaseEnabled getter and setter, which was used for WebSQL inside of a WebView, is deprecated. The World Wide Web Consortium encourages apps needing web databases to instead adopt Web Storage API technologies like IndexedDB.

The Third Beta of Android 15

Android Developers blog 📝

Tomáš discusses how Max implemented UI changes 30% faster with Jetpack Compose by reducing boilerplate code, increasing the re-usability of UI elements, and boosting overall developer productivity.

Max implemented UI changes 30% faster using Jetpack Compose

Chris discusses how the sample Jetcaster app was enhanced to support additional form factors. He emphasizes code sharing while adding support for Tablets, Desktops, Foldables, TV, Wear OS, and Widgets.

Building Jetcaster on all Form Factors

Robbie highlights several apps from Australia that are improving lives as part of #WeArePlay. One app helps people during natural disasters, another promotes wellbeing through houseplants.

#WeArePlay | Meet the people creating apps and games in Australia

Paris wrote about successful experiments with Android development in Google AI Studio involving turning designs into code, fixing UI, and prompting to add new features.

3 fun experiments to try for your next Android app, using Google AI Studio

Android Developers Backstage🎙️

On episode 207: “AI development assistance”, Tor and Romain invite Kathy from Google’s AI Developer Assistance team to discuss integrating Gemini in Android Studio. You’ll hear inside information about fine-tuning the model for Android, along with how Gemini retrieves information from the internet that is not in the training data to supplement its capabilities. They also discuss future AI possibilities, like providing personalization based off of the users codebase and writing edge test cases.

Listen to it in podcast or video format.

Videos💡

Nick recaps the top three I/O announcements from Google Play including enhanced store listings, expanded payment options, and SDK Console improvements.

At Google I/O Yigit advises developers to start experimenting with Kotlin Multiplatform.

And Zarah shares why they are excited for shared element transitions and screenshot testing.

AndroidX Releases 🚀

There were a lot of stable releases.

Glance 1.1.0 adds unit testing support and more components for building foundational UI elements for your homescreen widgets.

Fragment 1.8.0 includes AndroidFragment — an API for embedding Fragments in Compose.

If you’re seeing ‘LocalLifecycleOwner not present’ when using Compose, try upgrading Lifecycle to Lifecycle 2.8.2, which you can use with any version of Compose without workarounds.

Several testing libraries are stable, including Core-ktx 1.6.0, Espresso 3.6.0, Espresso Device 1.0.0, JUnit Extensions 1.2.0, Truth Extensions 1.6.0, Monitor 1.7.0, Orchestrator 1.5.0, Runner 1.6.0, Rules 1.6.0 and Services 1.5.0.

Several other stable releases dropped, including Camera 1.3.4, Compose Animation 1.6.8, Compose Foundation 1.6.8, Compose Material 1.6.8, Compose Runtime 1.6.8, Compose UI 1.6.8, Concurrent 1.2.0, Core-RemoteViews 1.1.0, Games-Controller 2.0.2.

Recent Release Notes | Android Developers

Now then… 👋

That’s it for this week with Android 15 Beta 3, two Compose case studies, Google AI Studio, Gemini in Android Studio, and lots of stable AndroidX releases.

Check back soon for your next update from the Android developer universe! 💫

Now in Android #108 was originally published in Android Developers on Medium, where people are continuing the conversation by highlighting and responding to this story.

Android 15 Developer Preview 2, #TheAndroidShow, the Google I/O date, the Meta Android OS Readiness Program, Google Play’s enhanced fraud protections and more!

Welcome to Now in Android; your ongoing guide to what’s new and notable in the world of Android development.

In this episode we cover Android 15 Developer Preview 2, The Android Show, the Google I/O date, the Meta Android OS Readiness Program, Google Play’s enhanced fraud protections, and more.

Most of the content of this post is available in the form of a video or podcast, so feel free to watch or listen rather than read on. (Or do all three to help you remember! There won’t be a quiz.)

The Second Developer Preview of Android 15 🧑‍💻

We released the second Developer Preview of Android 15. This developer preview focuses on communications, developer productivity, app flexibility across screens, privacy, app efficiency, and media refinements.

Android 15 Developer Preview 2 improves communication by extending platform support for satellite connectivity and making the tap to pay experience more seamless and reliable. It improves developer productivity with an enhanced PdfRenderer, automatic language switching refinements in speech recognition, granular line break controls to improve readability, and expanded IntentFilter Functionality to help with web-hosted deep links. It improves privacy by allowing apps to detect that they are being recorded. It adds support to improve app efficiency with the ApplicationStartInfo API, APIs for detailed app size information, and new APIs to help you migrate away from the dataSync Foreground Service type. Media refinements include HDR Headroom control, and an API to help you take advantage of audio dynamic range metadata to manage loudness inconsistencies.

Get started today testing your app with Android 15 in the emulator, or by flashing a system image onto a Pixel 6+, Pixel Fold, or Pixel Tablet device.

The Second Developer Preview of Android 15

#TheAndroidShow: the latest from MWC, Gemini Nano, Android 15 and more! 📹

In our quarterly show for Android developers, we unpack the latest Android foldables and large screens coming out of Mobile World Congress ’24 and how to build for these devices leveraging the Wear OS and Large Screen galleries. We learned that Generative AI with Gemini Nano and AICore has reduced latency and robust capability despite its small size. App developers shared their amazing work too. Adidas showed they built features up to 30% faster with Jetpack Compose, TikTok users log in up to 30x faster with Passkeys, and Infinite Painter saw decreased drawing latency using Jetpack Graphic Core and Motion Prediction Library.

#TheAndroidShow: the latest from MWC, Gemini Nano, Android 15 and more!

Google I/O is arriving this year on May 14th

Google I/O is arriving this year on May 14th and you’re invited to join us online! I/O offers something for everyone, whether you are developing a new application or modernizing an existing one.

Tune in for Google I/O on May 14

Videos💡

We released developer guidance for Google Play Protect enhanced fraud protections to explain a new pilot program to block fraudulent apps and offer resources to developers to avoid getting their apps blocked.

Android Developers Blog 📝

Meta created an Android OS Readiness Program to accelerate their apps’ targetSDK adoption to within 1 or 2 months of the AOSP release. Terrance covered Meta’s journey working with the Android betas including, testing apps early, utilizing latest tools like the SDK Upgrade Assistant and the Compatibility Framework Tool.

Embracing Android 14: Meta's Early Adoption Empowered Enhanced User Experience

Wear OS introduced a new lightweight Text to Speech engine, and Ouiam covered how to use it to help with accessibility services, coaching cues for exercise apps, navigation cues, and reading aloud incoming alerts through the watch speaker or Bluetooth connected headphones.

Introducing a new Text-To-Speech engine on Wear OS

Android 14 QPR2 added app screen sharing, so users no longer have to broadcast their entire screen while screen sharing or casting. Francesco covered how Google Meet uses this with the MediaProjection APIs to protect users from sharing private information on the screen — like messages and notifications — while screen sharing.

Enhanced screen sharing capabilities in Android 14 (and Google Meet) improve meeting productivity

Geoffrey covered the Fused Orientation Provider (FOP), a new API in Google Play services that provides quality and consistent device orientation by fusing signals from accelerometer, gyroscope and magnetometer.

Introducing the Fused Orientation Provider API: Consistent device orientation for all

AndroidX Releases 🚀

AndroidX libraries are moving to a default minimum supported Android API level 21 (previously 19) starting with releases in April, 2024. If you are currently supporting a lower minSdkVersion, we recommend bumping up to 21 and cleaning up any code to support prior versions.

There were many new AndroidX Releases including:

• Browser 1.8.0 is stable and allows you to further customize your custom tabs.
• Compose Material 1.7.0-alpha04 allows you to use bottom sheets in Navigation Compose with the androidx.compose:material:material-navigation artifact.
• Compose UI 1.7.0-alpha04 supports stylus handwriting for BasicTextField2 on devices after Android 14.
• Navigation 2.8.0-alpha04 lets you customize the sizeTransform at a destination by destination level to fix issues with resizing content when transitioning between screens.
• Wear Protolayout 1.2.0-alpha01 introduces ProtoLayout Arc to help with right-to-left layouts; APIs to help prevent the primary label, secondary label, and bottom chip from going offscreen; and a CircularProgressIndicator for smaller components.

Recent Release Notes | Android Developers

Now then… 👋

That’s it for this week with Android 15 Developer Preview 2, The Android Show, the Google I/O date, the Meta Android OS Readiness Program, Google Play’s enhanced fraud protections, and more.

Check back soon for your next update from the Android developer universe! 💫

Now in Android #101 was originally published in Android Developers on Medium, where people are continuing the conversation by highlighting and responding to this story.