Scaffold's PaddingValues should account for the display cutout [362508045]

Fixed

Feature Request

Status Update

No update yet.

Description

as...@google.com

created issue #1

Aug 27, 2024 05:14PM

Jetpack Compose version:

Compose BOM 2024.08.00

Material Library Version (M2, M3 or Both?):

Tested with M3, 1.2.1

Material Compose component used:

androidx.compose.material3.Scaffold

Steps to Reproduce:

Create a new "Empty Activity" project from Android Studio. Observe in MainActivity.kt, (a) enableEdgeToEdge is called and (b) Scaffold's PaddingValues (called innerPadding here) is applied to the entire content.

enableEdgeToEdge()
setContent {
    ScaffoldDisplayCutoutsTheme {
        Scaffold(modifier = Modifier.fillMaxSize()) { innerPadding ->
            Greeting(
                name = "Android",
                modifier = Modifier.padding(innerPadding)
            )
        }
    }
}

Run app on a handheld test device (e.g. tested on a Pixel 7 Pro).
Rotate to landscape. ==> Issue: Composable draws under the display cutout region. Expectation is for content to avoid both the system bar region and display cutout region.

See attached image (Scaffold_DisplayCutout.png). I've modified the sample code to make the issue more apparent. Notice the Composable, which is using innerPadding, avoids the system bars region but does not avoid the display cutout region.

Severity: To ensure Scaffold's PaddingValues makes going edge-to-edge easy, it should account for display cutouts. Otherwise, developers shouldn't use Scaffold's PaddingValues and should instead use alternatives like WindowInsets.safeDrawing, WindowInsets.safeGestures, or WindowInsets.safeContent. This is especially important as edge-to-edge is enforced in Android 15.

Scaffold_DisplayCutout.png

23 KB

View

Download

Comments

va...@google.com <va...@google.com> #2Aug 27, 2024 05:25PM

Project: platform/frameworks/support
Branch: androidx-main

commit a330c0d3bcdd41326f37968a60e6084ad4a2e32c
Author: Chet Haase <chet@google.com>
Date: Wed Jul 05 07:26:46 2023

Convert APIs using PointF to use Float instead

PointF is a convenient mechanism for passing around x.y values
representing 2D points. But there are downsides, including:
- Converting to PointF: You may not have the data in PointF form
to begin with, so using an API which takes PointF requires converting
the data to that form (including allocating a PointF object every time)
- Mutability: Point structures can be mutated internally, causing
unpredictability in what that mutation means. Should the library
react to those changes? Ignore them? Do defensive copies (requiring
even more allocations)? Using primitive types like Float make the
behavior more obvious (by making the data inherently immutable).
- Allocations: Whenever we use object types, there are necessarily
allocations on the Java heap for them. This puts pressure on the GC
at both allocation and collection time. Given the amount of points
being passed around (especially at morph creation time, when curves
are being split and created), this causes a lot of PointF objects to
be allocated (even temporarily). Using Float avoids that problem.

Also fixed bug with unclosed paths causing discontinuity at the
start/end point.

Bug: 276466399
Bug: 290254314
Test: integration and unit tests pass
Relnote: PointF parameters changed to Float pairs
Change-Id: Id4705d27c7be31b26ade8186b99fffe2e2f8450e

M graphics/graphics-shapes/api/current.txt
M graphics/graphics-shapes/api/restricted_current.txt
M graphics/graphics-shapes/src/androidTest/java/androidx/graphics/shapes/CubicShapeTest.kt
M graphics/graphics-shapes/src/androidTest/java/androidx/graphics/shapes/CubicTest.kt
M graphics/graphics-shapes/src/androidTest/java/androidx/graphics/shapes/PolygonMeasureTest.kt
M graphics/graphics-shapes/src/androidTest/java/androidx/graphics/shapes/PolygonTest.kt
M graphics/graphics-shapes/src/androidTest/java/androidx/graphics/shapes/RoundedPolygonTest.kt
M graphics/graphics-shapes/src/androidTest/java/androidx/graphics/shapes/ShapesTest.kt
M graphics/graphics-shapes/src/androidTest/java/androidx/graphics/shapes/TestUtils.kt
M graphics/graphics-shapes/src/main/java/androidx/graphics/shapes/Cubic.kt
M graphics/graphics-shapes/src/main/java/androidx/graphics/shapes/CubicShape.kt
M graphics/graphics-shapes/src/main/java/androidx/graphics/shapes/FeatureMapping.kt
M graphics/graphics-shapes/src/main/java/androidx/graphics/shapes/FloatMapping.kt
M graphics/graphics-shapes/src/main/java/androidx/graphics/shapes/Morph.kt
M graphics/graphics-shapes/src/main/java/androidx/graphics/shapes/PolygonMeasure.kt
M graphics/graphics-shapes/src/main/java/androidx/graphics/shapes/RoundedPolygon.kt
M graphics/graphics-shapes/src/main/java/androidx/graphics/shapes/Shapes.kt
M graphics/graphics-shapes/src/main/java/androidx/graphics/shapes/Utils.kt
M graphics/integration-tests/testapp-compose/src/main/java/androidx/graphics/shapes/testcompose/DebugDraw.kt
M graphics/integration-tests/testapp-compose/src/main/java/androidx/graphics/shapes/testcompose/ShapeEditor.kt
M graphics/integration-tests/testapp/src/main/java/androidx/graphics/shapes/test/MaterialShapes.kt

https://android-review.googlesource.com/2649119

ci...@google.com <ci...@google.com> #3Sep 3, 2024 06:03PM

PointF was the main (possibly only) mutability issue, marking this as fixed

va...@google.com <va...@google.com> #4Oct 7, 2024 07:36PM

The following release(s) address this bug.It is possible this bug has only been partially addressed:

androidx.graphics:graphics-shapes:1.0.0-alpha04

ap...@google.com <ap...@google.com> #5Dec 19, 2024 10:36PM

Marked as fixed.

Project: platform/frameworks/support
Branch: androidx-main
Author: Alex Vanyo <vanyo@google.com>
Link: https://android-review.googlesource.com/3422569

Add displayCutout to default Material insets

Expand for full commit details

Add displayCutout to default Material insets 
 
Relnote: "Adds displayCutout to the group of insets that Material 
components take into account by default, to avoid content overlapping 
with the display cutout. 
 
This is a behavior change that will impact how inset-aware 
components behave around a display cutout. This includes the default 
value of the WindowInsets parameter for inset-aware Material 3 
components, and the WindowInsets values provided in the component 
Defaults objects for both Material 2 and Material 3. 
If this change causes undesirable behavior, 
manually specify the WindowInsets parameter on a per-component basis." 
 
Fixes: 362508045 
 
Change-Id: I43ee9ad12db0450ebb9c65ce10d5c39d12628b6c

Files:

M compose/material/material/src/androidMain/kotlin/androidx/compose/material/SystemBarsDefaultInsets.android.kt
M compose/material3/material3/src/androidInstrumentedTest/kotlin/androidx/compose/material3/MaterialComponentsInsetSupportTest.kt
M compose/material3/material3/src/androidMain/kotlin/androidx/compose/material3/internal/SystemBarsDefaultInsets.android.kt

Hash: 692b440ac97b1831d5b35aafff241a98aeeacb93
Date: Wed Dec 18 19:49:15 2024

va...@google.com <va...@google.com> Dec 19, 2024 10:59PM

Reassigned to va...@google.com.

pr...@google.com <pr...@google.com> #6Jan 15, 2025 06:30PM