Fixed
Status Update
Comments
sp...@google.com <sp...@google.com>
yb...@google.com <yb...@google.com> #2
Project: platform/frameworks/support
Branch: androidx-main
commit aa570cc4c23d8aed5f9c704171a6fb58d3f58652
Author: marian <ymarian@google.com>
Date: Wed Aug 30 10:03:42 2023
[ColorScheme] Make color scheme immutable
Test: existing tests
Bug: 297212873
Relnote: """
ColorScheme is now Immutable, making individual color updates less efficient, but making more common usage of colors more efficient
The reasoning behind this change is that the majority of apps wouldn't have updating individual colors as a main use case.
This is still possible but it will recompose more than before, in turn we significantly decrease the amount of state subscriptions through all of material code and will impact initialization and runtime cost of more standard use cases.
"""
Change-Id: Ic447d95734c3399733c49f4b6d018ec296fc251a
M compose/material3/material3/api/current.txt
M compose/material3/material3/api/restricted_current.txt
M compose/material3/material3/src/commonMain/kotlin/androidx/compose/material3/ColorScheme.kt
M compose/material3/material3/src/commonMain/kotlin/androidx/compose/material3/MaterialTheme.kt
https://android-review.googlesource.com/2733678
Branch: androidx-main
commit aa570cc4c23d8aed5f9c704171a6fb58d3f58652
Author: marian <ymarian@google.com>
Date: Wed Aug 30 10:03:42 2023
[ColorScheme] Make color scheme immutable
Test: existing tests
Bug: 297212873
Relnote: """
ColorScheme is now Immutable, making individual color updates less efficient, but making more common usage of colors more efficient
The reasoning behind this change is that the majority of apps wouldn't have updating individual colors as a main use case.
This is still possible but it will recompose more than before, in turn we significantly decrease the amount of state subscriptions through all of material code and will impact initialization and runtime cost of more standard use cases.
"""
Change-Id: Ic447d95734c3399733c49f4b6d018ec296fc251a
M compose/material3/material3/api/current.txt
M compose/material3/material3/api/restricted_current.txt
M compose/material3/material3/src/commonMain/kotlin/androidx/compose/material3/ColorScheme.kt
M compose/material3/material3/src/commonMain/kotlin/androidx/compose/material3/MaterialTheme.kt
yb...@google.com <yb...@google.com>
yb...@google.com <yb...@google.com>
ap...@google.com <ap...@google.com> #3
The following release(s) address this bug.It is possible this bug has only been partially addressed:
androidx.compose.material3:material3:1.2.0-alpha08
androidx.compose.material3:material3-android:1.2.0-alpha08
na...@google.com <na...@google.com> #4
The following release(s) address this bug.It is possible this bug has only been partially addressed:
androidx.datastore:datastore-core:1.1.0-beta02
androidx.datastore:datastore-core-android:1.1.0-beta02
androidx.datastore:datastore-core-iosarm64:1.1.0-beta02
androidx.datastore:datastore-core-iossimulatorarm64:1.1.0-beta02
androidx.datastore:datastore-core-iosx64:1.1.0-beta02
androidx.datastore:datastore-core-jvm:1.1.0-beta02
androidx.datastore:datastore-core-linuxx64:1.1.0-beta02
androidx.datastore:datastore-core-macosarm64:1.1.0-beta02
androidx.datastore:datastore-core-macosx64:1.1.0-beta02
mi...@gmail.com <mi...@gmail.com> #5
Issue still exists.
de...@gmail.com <de...@gmail.com> #6
Comment has been deleted.
Description
DataStore Component used: Preferences DataStore Version used: 1.0.0 Devices/Android versions reproduced on: Pixel 5 API 32
When having nested
.edit {}
calls, execution stops before starting the nested call, we assume due to some sort of deadlock. We ran into this due to an.edit {}
call in a deep function call chain from within another.edit {}
call. The issue was hard to detect so we believe there should be some help from the library by either providing some lint check, or throwing an exception if this happens.Example:
prints