Status Update
Comments
gr...@google.com <gr...@google.com>
gr...@google.com <gr...@google.com> #2
Should we transform it from
fun <FileTypeT: FileSystemLocation> add(
type: MultipleArtifact<FileTypeT>,
artifact: FileTypeT
)
to
fun <FileTypeT: FileSystemLocation, Appendable> add(
type: MultipleArtifact<FileTypeT>,
artifactProvider: Provider<FileTypeT>
)
should we also share with Artifacts interface: ArtifactsImpl.appendTo ArtifactsImpl.appendAll. They are not in use right now. Maybe part of another ticket?
gr...@google.com <gr...@google.com> #3
I don't think we can just move it to use a Provider<> as the original bug called for adding a file.
plus this add() would become just like to OperationRequest::toAppendTo no ?
gr...@google.com <gr...@google.com> #4
So we somehow need to disallow calling this method if FileSystemLocation is produced by task?
Can we add some validation on build phase - meaning we can call those only during config but not when tasks execute?
plus this add() would become just like to OperationRequest::toAppendTo no ?
it looks like it
gr...@google.com <gr...@google.com> #5
Initial ticket that introduced Artifacts.add is
gr...@google.com <gr...@google.com> #6
Thank you for your patience while our engineering team worked to resolve this issue. A fix for this issue is now available in:
- Android Studio Jellyfish | 2023.3.1 Canary 7
- Android Gradle Plugin 8.4.0-alpha07
We encourage you to try the latest update.
If you notice further issues or have questions, please file a new bug report.
Thank you for taking the time to submit feedback — we really appreciate it!
pa...@partners.mbank.pl <pa...@partners.mbank.pl> #7
fontSize = 12.sp
fontWeight = SemiBold
letterSpacing = 0
lineHeights = 16.sp
pa...@partners.mbank.pl <pa...@partners.mbank.pl> #8
gr...@google.com <gr...@google.com> #9
I don't recommend this, but if you really need a workaround right now, here it is. This is probably quite brittle, slow, and I have not tested it other than checking that it does fix the bug. Use at your own risk. The actual fix for this is expected in 1.8.0-beta02
.
A very hacky workaround would be adding this modifier to the end of your Text
's modifier chain:
/** Intercept pre-layout to manually recycle `StaticLayout.Builder.useBoundsForWidth`. */
private fun Modifier.unexpectedTextWrappingWorkaround(): Modifier =
layout { measurable, constraints ->
if (Build.VERSION.SDK_INT >= 35) {
Api35Helper.resetStaticLayoutBuilderUseBoundsForWidth()
}
val placeable = measurable.measure(constraints)
layout(placeable.width, placeable.height) { placeable.place(0, 0) }
}
@RequiresApi(35)
private object Api35Helper {
@JvmStatic
fun resetStaticLayoutBuilderUseBoundsForWidth() {
StaticLayout.Builder.obtain("a", 0, 1, TextPaint(), 1024)
.setUseBoundsForWidth(false)
.build() // recycles the StaticLayout.
}
}
ap...@google.com <ap...@google.com> #10
Project: platform/frameworks/support
Branch: androidx-main
Author: Seigo Nonaka <
Link:
Fix unexpected enabling of useBoundsForWidth
Expand for full commit details
Fix unexpected enabling of useBoundsForWidth
This fixes a bug where a text may wrap to a second line where it is unnecessary.
Bug: 391378120
Test: Manual tests to ensure the unexpected wrapping stops after the fix is applied
Test: StaticLayoutFactoryTest#create_useBoundsForWidth_disabled
Test: BasicTextUnexpectedWrappingRegressionTest
Change-Id: I1b40c5816f2b4c1e787de05d5332db6fc0efad14
Files:
- A
compose/foundation/foundation/src/androidInstrumentedTest/assets/font/overshoot_test.ttx
- A
compose/foundation/foundation/src/androidInstrumentedTest/kotlin/androidx/compose/foundation/text/BasicTextUnexpectedWrappingRegressionTest.kt
- A
compose/foundation/foundation/src/androidInstrumentedTest/res/font/overshoot_test.ttf
- M
compose/ui/ui-text/src/androidInstrumentedTest/kotlin/androidx/compose/ui/text/android/StaticLayoutFactoryTest.kt
- M
compose/ui/ui-text/src/androidMain/kotlin/androidx/compose/ui/text/android/StaticLayoutFactory.android.kt
Hash: 7d19be04e9c2af237f0605a148605bf52f607497
Date: Thu Jan 23 17:40:54 2025
pa...@partners.mbank.pl <pa...@partners.mbank.pl> #11
gr...@google.com <gr...@google.com> #12
This will be targeting 1.8
, likely landing in beta02
.
1.7.*
targets android API 34, and this fix requires API 35. Upgrading 1.7
to android api 35 is too large of a change for a 1.7.x
version.
gr...@google.com <gr...@google.com> #13
Separate note, an upstream fix in the android platform is expected in api level 36, so this issue should only occur when API level is 35 and compose version is below 1.8.
er...@gmail.com <er...@gmail.com> #14
Saw that beta02
is out but there is no mention of this issue being fixed in the release notes. Were you able to land the fix in beta02 or it got pushed to a future version?
Description
Jetpack Compose version: BOM 2024.12.01
Jetpack Compose component(s) used: Text in Material3
Android Studio Build: Meerkat Canary 9
Kotlin version: 2.1.0
Problem:
Since bumping target SDK to 35 we notice that some strings on some devices receive unintended line breaks even when the Text Composable is allowed to be as wide as it wants. Trying to force single line does not work either as setting
maxLines=1
clip the string rather than join to one line.Examples of problematic strings:
Steps to Reproduce or Code Sample to Reproduce:
Code: Attached minimal reproduction repo including our custom font
Device: Reproduced on Pixel 9 Pro XL real device and emulator using the font/display settings in attached screenshot. Also reported on but not verified: Pixel 8 Pro, Pixel Tablet
Summary of the reprod sample: Activity with the following XML:
...and the following sample code:
This will produce the result in attached screenshots.
Some findings from debugging the issue: