Fixed
Status Update
Comments
ky...@bytedance.com <ky...@bytedance.com> #2
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 inTextView
beforeStaticLayout
runs inText
(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 anAndroidView
in ourComposeView
still repros.
rk...@google.com <rk...@google.com>
rk...@google.com <rk...@google.com> #3
Able to repro from a blank project with only activity-compose, compose foundation, and the font files.
- Create new blank compose project. (should be target api 35 already)
- Replace
dependencies
inapp/build.gradle.kts
with the below and sync the dependencies. - Delete the
ui
source dirs (all the material related stuff). - Copy the font files from the
reprod.zip
in the description of this bug into the new project. - Replace the
MainActivity
file with the below code. - 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),
)
}
}
rk...@google.com <rk...@google.com> #4
This actually does work in the demo app, I just forgot to change the target api. See
Description
AutoLock
appears to be a custom implementation ofstd::unique_lock/lock_guard
. It does, however, a method namedisLocked()
. There is only one use of the method at the moment:I believe, that has room for improvement. Firstly, even if we checked
isLock()
in general, asisLock()
is not thread-safe, there is no guarantee (in general) that the same thread can then lock it. It is only useful when there is only one thread that locks/unlocks the givenAutoLock
object and the thread wants know whether thelock
is acquired or not by itself. I don't think that's useful. I think the method being public, it has a good chance to confuse external developers.My belief is that the
AutoLock
should be simply replaced withstd::unique_lock
and/orstd::lock_guard
, as many uses of the class do not calllock
orunlock
. And,isLocked()
should be removed. The only call site should be implemented without that.Aside from all mentioned above, I am trying to compile the code with
--enable-thread-safety-checks
, and the first code that blocked the compilation on Linux was the use ofisLocked()
.