IssueTracker

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

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

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

commit 46eea23c96f45f0ee1e57d8aef2f1375507b0dec
Author: José Figueroa Santos <serniebanders@google.com>
Date:   Tue Apr 11 14:38:58 2023

    [M3][ModalBottomSheet] Enable edge to edge functionality for ModalBottomSheet
   
    Bug: 274872542
    Bug: 272973615
    Bug: 272334475
    Bug: 268432129
    Bug: 275849044
    Bug: 275486106
    Bug: 268433162
    RelNote: Add window insets parameter to ModalBottomSheet.
    RelNote: Scrim for ModalBottomSheet may now be drawn behind status bar with windowInsets set to zero
    RelNote: Updated default ModalBottomSheet functionality to stay outside of system bars including navigation
    RelNote: Status bar inset handling is provided by drag handle in edge-to-edge mode.
    RelNote: BottomSheetDefaults includes window insets for BottomSheetWindow.
    Test: Parameterizes existing tests to work with and without edgeToEdge enabled.
    Test: Manual EdgeToEdge testing on various devices and android APIs
    Change-Id: I312008e48573ebd21326f77216be0bcd0372aa78

M       compose/material3/material3/api/public_plus_experimental_current.txt
M       compose/material3/material3/samples/src/main/java/androidx/compose/material3/samples/BottomSheetSamples.kt
M       compose/material3/material3/src/androidAndroidTest/kotlin/androidx/compose/material3/ModalBottomSheetTest.kt
M       compose/material3/material3/src/androidMain/kotlin/androidx/compose/material3/ModalBottomSheet.android.kt
M       compose/material3/material3/src/androidMain/kotlin/androidx/compose/material3/Strings.android.kt
M       compose/material3/material3/src/commonMain/kotlin/androidx/compose/material3/SheetDefaults.kt

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

I feel like this change provided in material3:1.1.1 has made the ModalBottomSheet behavior worse. It used to adjust for the bottom navigation bar when the bottom sheet was fully expanded, and now it no longer does.

When I try to replace the default windowInsets value with something like WindowInsets.navigationBars, it doesn't help because the values are zero at the time of calling ModalBottomSheet(). Placing a hard-coded bottom padding value in the windowInsets object does have an effect when the bottom sheet is expanded, but I can't figure out how to determine the correct padding value since the WindowInsets.navigationBars values are zero.

Specifically, I am experiencing the issue when using Compose BOM 2023.06.01, but not with 2023.05.01.

We also experienced the worse behavior (in an Open Source project).

On affected systems the ModalBottomSheet is always aligned to the bottom of the screen.

We see this on Android <= 10 (you can easily see this on an Android 10 emulator, while the Android 13 emulator works).

However, some users report this for Android 13 (only three reports, yet).

I guess it doesn't bother many Android 13 users (most of our users have it), because I think the default is gesture navigation, and while you can see that it overlaps, it doesn't hurt much.

At least with 3-button navigation, you have a hard time to touch the application buttons behind the navigation buttons.

+1 to the 2 comments above. The ModalBottomSheet is drawn behind the nav buttons and specifying the windowInsets parameter doesn't change this behaviour (from 2023.06.01)