IssueTracker

The internal systemBarsForVisualComponents right now only uses systemBars, which doesn't include the display cutout: https://cs.android.com/androidx/platform/frameworks/support/+/androidx-main:compose/material3/material3/src/androidMain/kotlin/androidx/compose/material3/internal/SystemBarsDefaultInsets.android.kt;l=24;drc=dcaa116fbfda77e64a319e1668056ce3b032469f

Updating to systemBars.union(displayCutout) should fix this, if that's a change we can make.

Thank you for looking into this! It would be crucial to get this right soon as the edge2edge project depends on handling this properly :)

Not taking the display cutout into account will impact cars heavily, since some have very large display cutouts:

https://developer.android.com/codelabs/build-a-parked-app#10

Project: platform/frameworks/support
Branch: androidx-main
Author: Alex Vanyo <vanyo@google.com>
Link:      https://android-review.googlesource.com/3422569

Add displayCutout to default Material insets

Add displayCutout to default Material insets 
 
Relnote: "Adds displayCutout to the group of insets that Material 
components take into account by default, to avoid content overlapping 
with the display cutout. 
 
This is a behavior change that will impact how inset-aware 
components behave around a display cutout. This includes the default 
value of the WindowInsets parameter for inset-aware Material 3 
components, and the WindowInsets values provided in the component 
Defaults objects for both Material 2 and Material 3. 
If this change causes undesirable behavior, 
manually specify the WindowInsets parameter on a per-component basis." 
 
Fixes: 362508045 
 
Change-Id: I43ee9ad12db0450ebb9c65ce10d5c39d12628b6c

The following release(s) address this bug.It is possible this bug has only been partially addressed:

• androidx.compose.material:material:1.8.0-alpha08
• androidx.compose.material:material-android:1.8.0-alpha08
• androidx.compose.material:material-jvmstubs:1.8.0-alpha08
• androidx.compose.material:material-linuxx64stubs:1.8.0-alpha08
• androidx.compose.material3:material3:1.4.0-alpha06
• androidx.compose.material3:material3-android:1.4.0-alpha06
• androidx.compose.material3:material3-jvmstubs:1.4.0-alpha06
• androidx.compose.material3:material3-linuxx64stubs:1.4.0-alpha06

Maybe it helps. LeakCanary indicates leak after screen rotation:

                                                    ┬───
                                                    │ GC Root: Global variable in native code
                                                    │
                                                    ├─ android.os.ResultReceiver$MyResultReceiver instance
                                                    │    Leaking: UNKNOWN
                                                    │    Retaining 274.0 kB in 5254 objects
                                                    │    ↓ ResultReceiver$MyResultReceiver.this$0
                                                    │                                      ~~~~~~
                                                    ├─ androidx.credentials.playservices.controllers.BeginSignIn.CredentialProviderBeginSignInController$resultReceiver$1
                                                    │  instance
                                                    │    Leaking: UNKNOWN
                                                    │    Retaining 273.5 kB in 5253 objects
                                                    │    Anonymous subclass of android.os.ResultReceiver
                                                    │    ↓ CredentialProviderBeginSignInController$resultReceiver$1.this$0
                                                    │                                                               ~~~~~~
                                                    ├─ androidx.credentials.playservices.controllers.BeginSignIn.CredentialProviderBeginSignInController instance
                                                    │    Leaking: UNKNOWN
                                                    │    Retaining 273.5 kB in 5251 objects
                                                    │    activity instance of com.ownid.demo.firebase.ui.activity.MainActivity with mDestroyed = true
                                                    │    ↓ CredentialProviderBeginSignInController.activity
                                                    │                                              ~~~~~~~~
                                                    ╰→ com.ownid.demo.firebase.ui.activity.MainActivity instance
                                                    ​     Leaking: YES (ObjectWatcher was watching this because com.ownid.demo.firebase.ui.activity.MainActivity received
                                                    ​     Activity#onDestroy() callback and Activity#mDestroyed is true)
                                                    ​     Retaining 273.1 kB in 5238 objects
                                                    ​     key = 1c3d91c7-c738-4bc5-8dba-95247ac05760
                                                    ​     watchDurationMillis = 41713
                                                    ​     retainedDurationMillis = 36712
                                                    ​     mApplication instance of com.ownid.demo.firebase.DemoApp
                                                    ​     mBase instance of androidx.appcompat.view.ContextThemeWrapper
                                                    ====================================

Thank you for your help @dimitriy@ownid.com. You are right in that we don’t properly handle the configuration changes. Thank you for identifying this bug. What our upcoming changes can do is consistently ensure that upon rotation, our system stays consistent. I think the expected behavior here should depend upon the app - so possibly but not necessarily always will there be a cancellation. At the moment, the 'cancellation' will look strange, but is effectively doing a cancellation.

However, the application that our system runs on must also account for a configuration change. This can be done by matching the configuration consistency shown here. The application should also handle default/expected configuration changes via adding this line to the manifest under the <activity> tag:

<activity
        android:name=".ExampleMainActivity"
        android:configChanges="keyboardHidden|orientation|screenSize" // This line
        ......>

If the underlying application does not account for the configuration change, then the expected response will never make it to the designated receiver, because the underlying application is no longer in the same state as our system. Thus, the bottom sheet will remain up, but the credentials will land no-where when clicked or closed. It is, effectively, ‘canceled’, but it will look strange.

This may be worth following up so that both cases are handled (ensuring those who have set the most widely used configuration changes still get a consistent experience and ensure those who do not get a complete cancellation rather than the strange 'UI-still-up' version that exists today). However, for now, the former is the targeted solution and hopefully it can help avoid the strange behavior you experienced once the next version is released.

The videos below showcase the now expected behaviour. The 'AppConfigured' assumes the underlying app is properly configured to handle these core changes. The 'NonConfiguredDefaultCanceled' shows the 'UI-still-up' version of cancellation. In all cases, the repeating bottom-sheets have been fixed, and in the case when the underlying app is properly configured, the final credential is properly returned to the application as expected.

Thanks for reply. I see the proposed changes as a temporal workaround and not as proper library behavior on configuration changes. Even more - the proposed changes "fix" only some cases for configuration changes, not all of them.

In addition to that, proposed fix requires changes to be introduced to the customers application, in particular how activity handles configurations changes. This may not be acceptable way to fix the issue, especially in my case as SDK developer. I cannot ask customer to do such changes as it may break many things in there production app.

Bottom line - proposed solution does not solve the problem.

Ok

F

I hope you can excuse me for the delayed response. We have put up a new solution that should contain the expected behavior. If the calling application uses a cancellable scope as @helenqin@google.com mentioned above, a proper JobCancellationException will be thrown. If a non cancellable scope is used, even on configuration change, our library will ensure proper return of credentials. You can expect this change to arrive in the next release, around May.

In the meantime, to try this out you can use a snapshot SDK from https://androidx.dev/. Any buildId >= 9928302 works. Here's an example of using the 9928302 snapshot:

Step 1: Add the following maven url line to your build.gradle file.

allprojects {
    repositories {
        google()
        jcenter()
        maven { url 'https://androidx.dev/snapshots/builds/9928302/artifacts/repository' }
    }
}

Step 2: Depend on the snapshot version artifact:

dependencies {
    def work_version = '1.0.0-SNAPSHOT'
    implementation "androidx.credentials:credentials-play-services-auth:$work_version"
    ...
}

Thank you for your patience, and please let us know if there are any other issues. We appreciate your help in making Credential Manager better prior to the final launch.

I confirm that issue is fixed. Thanks! However memory leak is still present. Will open another issue for that.

The following release(s) address this bug.It is possible this bug has only been partially addressed:

• androidx.credentials:credentials-play-services-auth:1.0.0-alpha07

This looks like a different issue, could you please open a new bug with more details about which version of jetpack you're using, which version of android you're running, a bug report and etc.