IssueTracker

Some notes from digging into this a bit:

• unexpected wrapping doesn't start until a TextView that line wraps runs it's line breaking logic.
  • style doesn't seem to matter, so long as the line breaker is ran.
  • Moving the TextView below the compose view so that it runs first makes the first draw not wrap in the compose text. Subsequent re-measures will start wrapping.
  • This may require a StaticLayout to run in TextView before StaticLayout runs in Text (BoringLayout doesn't seem to cause this, but that doesn't have line breaking by definition), but I'm not certain.
• Inputs to LineBreaker.computeLineBreaks seem to have consistent arguments for repro and non-repro use cases.
• Couldn't run in demo app, so the layouts/views may also be necessary to repro.
• Used a API 35 Pixel 9 Pro XL emulator to repro. Verified that using API 34 does not repro.
• Moving the TextView from the layout to an AndroidView in our ComposeView still repros.

Able to repro from a blank project with only activity-compose, compose foundation, and the font files.

1. Create new blank compose project. (should be target api 35 already)
2. Replace dependencies in app/build.gradle.kts with the below and sync the dependencies.
3. Delete the ui source dirs (all the material related stuff).
4. Copy the font files from the reprod.zip in the description of this bug into the new project.
5. Replace the MainActivity file with the below code.
6. Run the app on a Pixel 9 Pro XL - API 35 emulator.

dependencies {
    implementation("androidx.activity:activity-compose:1.10.0")
    implementation("androidx.compose.foundation:foundation:1.7.6")
}

import android.os.Bundle
import android.widget.TextView
import androidx.activity.ComponentActivity
import androidx.activity.compose.setContent
import androidx.activity.enableEdgeToEdge
import androidx.compose.foundation.background
import androidx.compose.foundation.layout.Column
import androidx.compose.foundation.layout.fillMaxWidth
import androidx.compose.foundation.layout.padding
import androidx.compose.foundation.layout.safeContentPadding
import androidx.compose.foundation.text.BasicText
import androidx.compose.runtime.Composable
import androidx.compose.ui.Modifier
import androidx.compose.ui.graphics.Color
import androidx.compose.ui.text.TextStyle
import androidx.compose.ui.text.font.Font
import androidx.compose.ui.text.font.FontFamily
import androidx.compose.ui.text.font.FontWeight
import androidx.compose.ui.unit.dp
import androidx.compose.ui.unit.sp
import androidx.compose.ui.viewinterop.AndroidView

class MainActivity : ComponentActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        enableEdgeToEdge()
        setContent { Content() }
    }
}

private val ReproFontFamily =
    FontFamily(
        Font(R.font.noto_ikea_latin_regular, FontWeight.Normal),
        Font(R.font.noto_ikea_latin_bold, FontWeight.Bold)
    )

@Composable
private fun Content() {
    Column(
        modifier = Modifier
            .safeContentPadding()
            .fillMaxWidth()
            .padding(32.dp)
    ) {
        AndroidView(factory = { ctx -> TextView(ctx).apply { text = "Line1\nLine2" } })

        BasicText(
            text = "ALEX",
            style = TextStyle(
                fontWeight = FontWeight.Bold,
                color = Color.Black,
                fontFamily = ReproFontFamily,
                fontSize = 14.sp,
                lineHeight = 22.sp,
            ),
            modifier = Modifier.background(Color.Magenta),
        )
    }
}

This actually does work in the demo app, I just forgot to change the target api. See aosp/3462479 for repro. Still needs Pixel 9 Pro XL emulator on API 35.

Maybe related, but not convinced: b/346918500

Nona, can you take a look?

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.
    }
}

Project: platform/frameworks/support
Branch: androidx-main
Author: Seigo Nonaka <nona@google.com>
Link:      https://android-review.googlesource.com/3461408

Fix unexpected enabling of useBoundsForWidth

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

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.

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.

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?

Looks like it actually went out in beta01.

Do you have some kind of ETA when 1.8 will reach stable? We're currently debating on switching our prod app on the compose-bom-beta:2025.02.00 artifact otherwise which points to 1.8.0-beta02 versions at the moment.

The team just release 1.8.0-rc01 compose-bom-beta:2025.03.00 and I am still seeing the issue happen inconsistently.