Fixed
Status Update
Comments
ke...@google.com <ke...@google.com>
ma...@google.com <ma...@google.com>
ap...@google.com <ap...@google.com> #2
A couple of questions:
1. Have you saw crash in real device or only in simulators?
2. Do you use dynamic feature for language ID?
1. Have you saw crash in real device or only in simulators?
2. Do you use dynamic feature for language ID?
ma...@google.com <ma...@google.com> #3
Tested on Android 12 Emulator with custom executor, but cannot repro this issue.
pr...@google.com <pr...@google.com> #4
-
Second crash in the description is from a real device. Experienced it myself on two different Xiaomi phones, plus lots of crashes from users in the Google Play console.
-
Dynamic features are not used in the application.
As a wild guess, I have downgraded build tools from 31.0.0 to 30.0.3, compileSdk from 31 to 30, and moved all work with Language ID to the service in a separate process (just to be sure that crash can kill secondary process instead of main). This combination is in beta for 2 days by now and I don't see any SIGSEGV crashes.
Description
Jetpack Compose version: BOM 2024.06.00
Material Library Version (M2, M3 or Both?): M3
Material Compose component used: SearchBar
Android Studio Build: 2024.1.1
Kotlin version: 2.0.0
Steps to Reproduce or Code Sample to Reproduce:
SearchBar
astopBar
and aLazyColumn
of items ascontent
into aScaffold
.SearchBar
.SearchBar
pushes content below away instead of overlaying above it, and closing it pulls back the content below.SearchBar
increasing its layout height in-place, which means thecontent
will be given less height during measurement.This can be seen in blog posts about how to usehttps://medium.com/@shivathapaa/custom-topappbar-using-android-jetpack-compose-f9b33388a125 (disclaimer: I'm not the author of it) has a GIF recording which shows this problem if one observe carefully.
SearchBar
as well, e.g.This isn't a problem in Compose Material Catalog SearchBarSamples because the sample is using a
Box
and a fixed top padding for the list. However, that doesn't work in most real world scenarios e.g. when people need to useScaffold
.I think the material-components-android approach for , which is to offer
SearchBar
SearchBar
andSearchView
separately, is more flexible and will make it possible to handle layout (and window insets) correctly under all scenarios.Stack trace (if applicable): N/A