Status Update
Comments
to...@gmail.com <to...@gmail.com> #2
Steps to reproduce
What steps are needed to reproduce this issue?
If required, please provide sample project or apk to reproduce the issue. Also mention the steps to be followed for reproducing the issue with the given sample project or apk.
Expected output
What is the expected output?
Current output
What is the current output?
Android bug report capturing
After reproducing the issue, press the volume up, volume down, and power button simultaneously. This will capture a bug report on your device in the “bug reports” directory. Attach the bug report file to this issue.
Alternate method
After reproducing the issue, navigate to “developer settings”, ensure “USB debugging” is enabled, then enable “Bug report shortcut”. Capture bug report by holding the power button and selecting the “Take bug report” option.
Screen Record of the Issue
Please capture screen record or video of the issue using following steps:
adb shell screenrecord /sdcard/video.mp4
Subsequently use following command to pull the recorded file:
adb pull /sdcard/video.mp4
Attach the file to this issue.
lp...@google.com <lp...@google.com>
mo...@google.com <mo...@google.com> #3
I think it's my mistake, I guess I should not invoke BiometricPrompt from onResume it will cause an infinite loop.
Running on Samsung A50 Android 9 or Emulator Nexus 5X API 27
Android Studio 3.5.1
compileSdkVersion 29
minSdkVersion 21
targetSdkVersion 29
def biometric_version = "1.0.0-rc01"
implementation "androidx.biometric:biometric:$biometric_version"
Scenario 1:
- No biometric or device credentials (PIN, pattern, password) configured
- Biometric prompt not showing
- Tap on Toast button
- Activity is not responding (can't tap on button)
Scenario 2:
- Device credential configured (Pattern)
- Biometric prompt showing pattern authentication
- Tap on Cancel
- Tap on Toast button
- Activity is not responding (can't tap on button)
Expected output : Toast showing when button tapped
to...@gmail.com <to...@gmail.com> #4
Steps to reproduce:
- Fingerprint configured in settings
- Biometric prompt showing
- Tap on cancel
- Tap on Toast button
- Toast is showing
Scenario 2:
- Device credential configured (Pattern)
- Biometric prompt showing pattern authentication
- Tap on Cancel
- Tap on Toast button
- Activity is not responding (can't tap on button)
Behaviour is not the same between biometric and credentials authentication
mo...@google.com <mo...@google.com> #5
to...@gmail.com <to...@gmail.com> #6
mo...@google.com <mo...@google.com> #7
to...@gmail.com <to...@gmail.com> #8
Branch: androidx-master-dev
commit a9cbd7e42fd38c18395c23fd17622c731c60c724
Author: Curtis Belmonte <curtislb@google.com>
Date: Mon Oct 28 11:00:33 2019
Fix leak of biometric credential handler activity
Due to a race condition, which can be triggered by launching
BiometricPrompt immediately after it's dismissed (e.g., by calling
authenticate() in onResume() or onCreate()), it's currently possible for
the transparent DeviceCredentialHandlerActivity to get stuck onscreen.
This results in no visible change but consumes all touch events until
the user presses back or pauses the activity.
This commit fixes the issue of the activity getting stuck onscreen by
ensuring that DeviceCredentialHandlerActivity is finished (without an
explicit authentication result) in this case.
Test: Have sample app call BiometricPrompt#authenticate() in onResume()
Before: After first auth, transparent activity is stuck onscreen
After: After first auth, the prompt launches again successfully
Fixes: 143091227
Change-Id: Id11918662be4634c017094806816a990e84ffd62
M biometric/src/main/java/androidx/biometric/DeviceCredentialHandlerActivity.java
mo...@google.com <mo...@google.com> #9
to...@gmail.com <to...@gmail.com> #10
Perfect.
Just quickly tested the
.fillMaxSize()
.wrapContentHeight()
And it seems to behave correctly for the dialog scrim so works as a solution, may worth a note somewhere as cheating with usePlatformDefaultWidth = false
was often found as solution in a few posts over Internet.
A quick "mostly" related question to the dialog scrim, many users requested an option to hide the status bar in my app to be in full immersive mode, but there's no way to do that with dialogs right now. Is this something that can be requested? I have a fork of M3 BottomSheet to handle that, but handling a fork of the low level dialog requires a full copy and rewrite of everything that depends on it.
mo...@google.com <mo...@google.com> #11
Have you tried using the DialogWindowProvider?
:
fun findDialogWindowProviderInParent(view: View): DialogWindowProvider? {
if (view is DialogWindowProvider) {
return view
}
val parent = view.parent ?: return null
if (parent is View) {
return findDialogWindowProviderInParent(parent)
}
return null
}
@Composable
MyDialogContent() {
val dialogWindowProvider = findDialogWindowProviderInParent(LocalView.current)
dialogWindowProvider?.window?.addFlags(WindowManager.LayoutParams.FLAG_FULLSCREEN)
...
}
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.