Status Update
Comments
to...@gmail.com <to...@gmail.com> #2
Thanks for the report!
Could you please confirm for us which version of Compose is your project using? Does it happen if you change the version?
Relevant crash from device:
2022-07-05 03:42:05.712 13983-13983 DEBUG pid-13983 A NOTE: Function names and BuildId information is missing for some frames due
NOTE: to unreadable libraries. For unwinds of apps, only shared libraries
NOTE: found under the lib/ directory are readable.
NOTE: On this device, run setenforce 0 to make the libraries readable.
NOTE: Unreadable libraries:
NOTE: /data/data/com.app.work/cache/androidx.compose.ui-ui-1.2.0-rc03-inspector.jar_unpacked_lib/libcompose_inspection_jni.so
2022-07-05 03:42:05.712 13983-13983 DEBUG pid-13983 A #00 pc 000000000004b5bc /apex/com.android.runtime/lib64/bionic/libc.so (__strncmp_aarch64+252) (BuildId: 058e3ec96fa600fb840a6a6956c6b64e)
2022-07-05 03:42:05.712 13983-13983 DEBUG pid-13983 A #01 pc 00000000000028f4 /data/data/com.app.work/cache/androidx.compose.ui-ui-1.2.0-rc03-inspector.jar_unpacked_lib/libcompose_inspection_jni.so (compose_inspection::analyzeLines(_jvmtiEnv*, int, _jvmtiLineNumberEntry*, int, _jvmtiLocalVariableEntry*, int*, int*)+160) (BuildId: 0990d56fd5c4090102a504def1e5a1657300399e)
2022-07-05 03:42:05.712 13983-13983 DEBUG pid-13983 A #02 pc 0000000000002eb4 /data/data/com.app.work/cache/androidx.compose.ui-ui-1.2.0-rc03-inspector.jar_unpacked_lib/libcompose_inspection_jni.so (compose_inspection::resolveLocation(_JNIEnv*, _jclass*)+840) (BuildId: 0990d56fd5c4090102a504def1e5a1657300399e)
2022-07-05 03:42:05.712 13983-13983 DEBUG pid-13983 A #03 pc 0000000000440154 /apex/com.android.art/lib64/libart.so (art_quick_generic_jni_trampoline+148) (BuildId: 5de55fd6e2a9191dd8c1362ea79ef5f6)
2022-07-05 03:42:05.712 13983-13983 DEBUG pid-13983 A #04 pc 000000000044049c /apex/com.android.art/lib64/libart.so (BuildId: 5de55fd6e2a9191dd8c1362ea79ef5f6)
2022-07-05 03:42:05.730 771-771 tombstoned tombstoned E Tombstone written to: tombstone_09
lp...@google.com <lp...@google.com>
mo...@google.com <mo...@google.com> #3
composeVersion = '1.2.0-beta03'
+ these deps included
debugImplementation "androidx.compose.ui:ui-tooling:$composeVersion"
debugImplementation "androidx.compose.ui:ui-tooling-preview:$composeVersion"
debugImplementation "androidx.customview:customview:1.2.0-alpha01"
debugImplementation "androidx.customview:customview-poolingcontainer:1.0.0-rc01"
also tested 1.2.0-beta02, 1.3.0-alpha01 (with 1.2.0 composeCompiler)..., same crash
to...@gmail.com <to...@gmail.com> #4
I was using Compose 1.2.0-rc03 and Compose Compiler 1.2.0. But this issue was present in previous versions (1.2.0-RCxx) of the compiler too.
Yesterday I was testing how it works with Compose 1.1.1 and Compose 1.3.0-alpha01. It seemed to be working better, I could inspect the app for 5-10 minutes until it crashed. However, fetching view atributes was really unreliable: sometimes instantaneous, other times with a huge delay or not it all. And I believe crashes are related to the attributes section.
Most of the crashes had these messages in the Logcat afterwards: (see the attached file)
mo...@google.com <mo...@google.com> #5
It looks like jvmti->GetMethodName(methodId, &name, nullptr, nullptr)
returns a nullptr
for name without returning an error.
Slightly surprising. I will add a nullptr guard to avoid this.
It would be nice to find out what the kotlin code that causes looks like. It will be a lambda expression.
to...@gmail.com <to...@gmail.com> #6
Okay, I did some testing and found out that this code crashes the app while using Layout Inspector. Once I removed all the parameters of ModalBottomSheetState
(or of my wrapper *UiState
class with ModalBottomSheetState
in constructor) – it began to work fine.
I have other crashes on second screen and there are no functions with parameter ModalBottomSheetState
. That screen has much more functions and I will need more time to find the cause.
At least it's safe to say that this the crash is not caused by ModalBottomSheetState
exclusively
mo...@google.com <mo...@google.com> #7
Great, thanks. I will take a look.
to...@gmail.com <to...@gmail.com> #8
PS: You mention that there are other crashes on the second screen.
If logcat shows the same lines like #2 i.e.
```
.../apex/com.android.runtime/lib64/bionic/libc.so (__strncmp_aarch64+252)
.../libcompose_inspection_jni.so (compose_inspection::analyzeLines(_jvmtiEnv*, int, _jvmtiLineNumberEntry*, int, _jvmtiLocalVariableEntry*, int*, int*)
.../libcompose_inspection_jni.so (compose_inspection::resolveLocation(_JNIEnv*, _jclass*)
```
then it is likely the same bug.
If crash looks different in logcat, it is likely a different bug: Please create a new bug (you could update this bug with a link to the new bug. Then I will see the new bug before the it goes through triaging).
Thank you so much for reporting.
mo...@google.com <mo...@google.com> #9
Tested Compose 1.3.0-alpha03 with my project. Layout inspector works like a charm now Thank you for the fix
to...@gmail.com <to...@gmail.com> #10
Thank you for reporting the bug and about the bug fix.
mo...@google.com <mo...@google.com> #11
I found an issue may related to this.
Detail is here 244376735.
to...@gmail.com <to...@gmail.com> #12
Not at all I always failed at finding the proper window, this works perfectly thanks a lot.
val dialogWindowProvider = findDialogWindowProviderInParent(LocalView.current)
val window = dialogWindowProvider?.window
if (window != null) {
WindowCompat.getInsetsController(window, window.decorView).apply {
hide(WindowInsetsCompat.Type.statusBars())
systemBarsBehavior = WindowInsetsControllerCompat.BEHAVIOR_SHOW_TRANSIENT_BARS_BY_SWIPE
}
}
to...@gmail.com <to...@gmail.com> #13
Returning to the 2nd issue about the lag and your solution.
Using a .fillMaxSize()
breaks the second .fillMaxWidth(0.8f)
. In my case since only the height change I can use a .fillMaxHeight()
but I do not really understand what is happening. See attached screenshots.
I can just return to usePlatformDefaultWidth = true
since your workaround fixes the lag and then it behave as expected.
So just reporting in case there's something else about measurement that changes and was not expected.
to...@gmail.com <to...@gmail.com> #14
Ok and now the memories slowly comes back :(
usePlatformDefaultWidth = true
and dialog resizing issues.
Use the following dialog content with the content from #4 and usePlatformDefaultWidth = true
Surface(
modifier = modifier
.safeContentPadding()
.fillMaxWidth(0.8f),
shape = shape,
color = backgroundColor,
contentColor = contentColor,
) {
dialogNavigator.SaveableState("currentDialog") {
dialogContent(dialogNavigator)
}
}
It gives the result plaformnoanimate.png attached.
With
Surface(
modifier = modifier
.safeContentPadding()
.animateContentSize(),
shape = shape,
color = backgroundColor,
contentColor = contentColor,
) {
dialogNavigator.SaveableState("currentDialog") {
dialogContent(dialogNavigator)
}
}
It gives the result platformanimate.png
Both are wrong as the dialog does not properly resized on content change, strangely I can't find the issue on the tracker but I'm pretty sure there was one opened about that since ages and the reasons we had to migrate to use usePlatformDefaultWidth = false
.
Those hacks are so old on my side that I have an hard time remembering all the details :(
.fillMaxSize()
breaks the dismissOnClickOutside
As per this item title, adding the fillMaxSize prevent click outside to dismiss the dialog so it not really a proper workaround.
All those tests are made with alpha 4 that contains the CL.
to...@gmail.com <to...@gmail.com> #15
Adding a final note if anyone reads and needs a solution.
Box(
modifier = Modifier
.safeDrawingPadding()
.fillMaxSize()
.padding(horizontal = 32.dp)
.clickable {
if (dialogState.canDismiss.value) {
dialogNavigator.hide()
}
}
) {
Surface(
modifier = modifier
.align(Alignment.Center)
.sizeIn(maxWidth = 640.dp)
.clickable(enabled = false) {}
.animateContentSize(),
shape = shape,
color = backgroundColor,
contentColor = contentColor,
) {
dialogNavigator.SaveableState("currentDialog") {
dialogContent(dialogNavigator)
}
}
}
Beware that this still only works properly with usePlatformDefaultWidth = false
See resulting video "works"
With usePlatformDefaultWidth = true
this will give the result "notwork" where the dialog width animate (while it should not, the actual width never changes) but the content does not seems to react so the title is on 2 lines. (The title is a simple Text() present on first display, not a later change)
I think I covered most of the issues with dialogs here. Some very old that where workarounded via usePlatformDefaultWidth=false
and some that are now also present in usePlatformDefaultWidth=false
due to window resizing (But working better than the other case)
ap...@google.com <ap...@google.com> #16
Project: platform/frameworks/support
Branch: androidx-main
Author: George Mount <
Link:
Set default Gravity for Dialogs to CENTER
Expand for full commit details
Set default Gravity for Dialogs to CENTER
Fixes: 373093006
On some devices, the default gravity for dialogs is not CENTER.
This changes the default gravity for Compose dialogs to CENTER.
Test: new test, manual testing on broken device
Change-Id: Ia2ec9f6edc2705cb8a13201d5e05a859a6bb9571
Files:
- M
compose/ui/ui/src/androidInstrumentedTest/kotlin/androidx/compose/ui/window/DialogTest.kt
- M
compose/ui/ui/src/androidMain/kotlin/androidx/compose/ui/window/AndroidDialog.android.kt
Hash: 97468d483b698d637162d50a4549ac0f2d8257ca
Date: Wed Oct 16 15:34:47 2024
to...@gmail.com <to...@gmail.com> #17
Can we discuss the other issues too?
to...@gmail.com <to...@gmail.com> #18
I guess that's a no and I documented all the issues for nothing.
pr...@google.com <pr...@google.com> #19
The following release(s) address this bug.It is possible this bug has only been partially addressed:
androidx.compose.ui:ui:1.8.0-alpha05
androidx.compose.ui:ui-android:1.8.0-alpha05
androidx.compose.ui:ui-jvmstubs:1.8.0-alpha05
androidx.compose.ui:ui-linuxx64stubs:1.8.0-alpha05
Description
Jetpack Compose version: 1.8 SNAPSHOT : 12425984
The CLhttps://android-review.googlesource.com/c/platform/frameworks/support/+/3272334 have broken dialogs shown from BottomSheets on Samsung Android 14 devices at least.
Snapshot 12425888 does not exhibit this behavior.
Repo: Show a Dialog/AlertDialog from a ModalBottomSheet from a recent M3 (So after the popup rewrite).
While this is probably a Samsung Bug (See the SAF confirmation screenshot that have the dialog at the bottom too), this is problematic as the M3 alert dialogs does not allow to pass a modifier to at least set contentSafePadding().
So if you consider that this is fully Samsung bug, it would be nice that this was reaffected to M3 to ensure the dialog can have safe paddings.