feat(auth): reshape reauthContent into a ReauthContentState content slot

[demolaf]

reauthContent was documented and shaped as a content slot alongside emailContent, phoneContent and the MFA slots, but it received only (AuthState.ReauthenticationRequired, onDismiss) and every API needed to build a reauthentication UI — filterToLinkedProviders, isReauthenticationMode, the federated provider driver — was internal or private. A custom slot could therefore only perform email/password reauthentication and had to dead-end for a Google- or OAuth-only account. The success handoff was also easy to get wrong: onDismiss reset auth state to Idle while retryOperation emitted AuthState.Success, so both orderings a caller would naturally reach either clobbered the success or cancelled the scope the retry ran in, silently dropping the sensitive operation.

reauthContent now receives a single ReauthContentState carrying the user, the reason, the providers already filtered to those linked to that user, and callbacks to select a provider or dismiss. The caller renders a provider chooser; the library owns credential exchange and dismiss/retry sequencing. Selecting AuthProvider.Email or AuthProvider.Phone hands off to the library's own sub-flow, honouring the caller's emailContent / phoneContent, and an MFA-enrolled user now completes the second factor inside the reauth surface rather than having the challenge render beneath it.

Reauthentication is a request-scoped state machine rather than seven independently mutable Compose holders. AuthState.Reauthentication carries a requestId and the pending operation; proof of reauthentication is a reauthenticatedUid stamped on AuthState.Success at the three credential-exchange sites, and the pending operation is consumed only for a library-published success on that same uid, exactly once. Activity recreation resumes the same request; process death reports an interruption rather than dropping it.

⚠️Breaking changes

• reauthContent takes a single ReauthContentState instead of (state, onDismiss).
• AuthState.Success can no longer be constructed outside the library. It records which uid a reauthentication re-proved, and that proof must not be forgeable by app code.
• AuthState.ReauthenticationRequired is now AuthState.Reauthentication.Required, nested with the other reauthentication phases under a new public AuthState.Reauthentication sealed class.
• ReauthContentState moves to com.firebase.ui.auth.ui.screens.reauth.
• MfaChallengeScreen and MfaEnrollmentScreen move to com.firebase.ui.auth.ui.screens.mfa.

While a reauthentication is in progress, authStateFlow() and AuthFlowController.state() emit AuthState.Reauthentication phases, so is AuthState.Error, is AuthState.Loading and is AuthState.Cancelled do not match for that window. The outcome is published as an ordinary state once the request completes. This is documented in auth/README.md.

• ReauthContentState.kt: new public state holder, following the MfaEnrollmentContentState conventions.
• AuthState.kt: Success gains reauthenticatedUid and an internal constructor; the reauthentication phases become a nested sealed hierarchy keyed by requestId.
• FirebaseAuthUI.kt: one guarded transition entry point plus session start/finish; ordinary states are folded into reauthentication phases only while a screen is registered to drain them, so an arming created by public API with no screen composed stays inert.
• FirebaseAuthScreen.kt: the linked-provider list reaches the slot instead of being discarded; provider selection, error-dialog recovery, deep links and the non-terminal navigation branches are inert while a reauthentication is armed.
• EmailAuthProvider+FirebaseAuthUI.kt, OAuthProvider+FirebaseAuthUI.kt: stamp reauthenticatedUid where the reauthenticated identity is known; account creation and credential linking are rejected in reauthentication mode.
• SignInUI.kt: sign-up, password recovery and email-link sign-in are not offered while reauthenticating, and Credential Manager autofill is skipped so a saved password for another account cannot be auto-submitted.
• ui/screens/reauth/, ui/screens/mfa/: reauthentication and MFA UI extracted into their own packages, mirroring the existing ui/screens/email/ and ui/screens/phone/.

Added FirebaseAuthScreenReauthContentStateTest, EmailAuthScreenReauthEmailLockTest and coverage across FirebaseAuthUIAuthStateTest, plus e2e coverage of reauthentication through the slot — every new test verified to be load-bearing by temporarily reverting the fix and confirming it fails.

Usage

FirebaseAuthScreen(
configuration = configuration,
onSignInSuccess = { },
onSignInFailure = { },
onSignInCancelled = { },
reauthContent = { state ->AlertDialog(
onDismissRequest = state.onDismiss,
title = { Text(state.reason ?:"Verify your identity") },
text = {
Column(modifier =Modifier.verticalScroll(rememberScrollState())) {
state.error?.let { Text(it, color =MaterialTheme.colorScheme.error) }
if (state.isLoading) CircularProgressIndicator()
state.providers.forEach { provider ->Button(
onClick = { state.onProviderSelected(provider) },
enabled =!state.isLoading,
) { Text("Continue with ${provider.providerName}") }
}
}
},
confirmButton = {},
dismissButton = { TextButton(onClick = state.onDismiss) { Text("Cancel") } },
)
},
)

[gemini-code-assist]

Code Review

This pull request introduces a robust reauthentication flow in FirebaseUI Auth for Android, separating operation-level cancellations (AuthState.Cancelled) from flow-level aborts (AuthState.Aborted). It adds support for a custom, stateless reauthContent slot in FirebaseAuthScreen while keeping credential exchanges owned by the library, locks the email field to read-only during reauthentication, and resolves several state-resetting edge cases. The review feedback suggests making the OAuth reauthentication path more robust and fail-fast by explicitly throwing an exception if auth.currentUser is unexpectedly null, rather than silently failing with a safe call.

[russellwheatley]

Two suggestions on the reauth config copy and state survival across rotation, nothing blocking otherwise. The uid-matching consumption logic, the internal AuthState.Success constructor, and the inert-while-armed gating all check out.

[russellwheatley]

Re-reviewed after the state-machine refactor and the two follow-up fixes. Both issues from the last round are fixed properly, not just carried over (isCredentialLinkingEnabled/isAnonymousUpgradeEnabled reset now applies at both reauth-config construction sites, and the rememberSaveable gap turned into a proper ReauthPresentationState + Saver that reconciles correctly on both rotation and process death). Two minor items left, neither blocking on their own, flagging so they don't get lost:

• inline comment below on AuthState.Success's constructor going internal
• e2eTest/src/test/java/com/firebase/ui/auth/ui/screens/ReauthFlowTest.kt has no dedicated case for sign-out-during-retry or phone-verification-teardown. Both are already covered at the unit/screen level (FirebaseAuthScreenReauthIdleResetTest.kt, PhoneAuthScreenVerificationLifecycleTest.kt), so this is more of a nice-to-have than something I'd hold the PR on.

[demolaf]

reauthContent was documented and shaped as a content slot alongside emailContent, phoneContent and the MFA slots, but it received only (AuthState.ReauthenticationRequired, onDismiss) and every API needed to build a reauthentication UI — filterToLinkedProviders, isReauthenticationMode, the federated provider driver — was internal or private. A custom slot could therefore only perform email/password reauthentication and had to dead-end for a Google- or OAuth-only account. The success handoff was also easy to get wrong: onDismiss reset auth state to Idle while retryOperation emitted AuthState.Success, so both orderings a caller would naturally reach either clobbered the success or cancelled the scope the retry ran in, silently dropping the sensitive operation.

reauthContent now receives a single ReauthContentState carrying the user, the reason, the providers already filtered to those linked to that user, and callbacks to select a provider or dismiss. The caller renders a provider chooser; the library owns credential exchange and dismiss/retry sequencing. Selecting AuthProvider.Email or AuthProvider.Phone hands off to the library's own sub-flow, honouring the caller's emailContent / phoneContent, and an MFA-enrolled user now completes the second factor inside the reauth surface rather than having the challenge render beneath it.

Reauthentication is a request-scoped state machine rather than seven independently mutable Compose holders. AuthState.Reauthentication carries a requestId and the pending operation; proof of reauthentication is a reauthenticatedUid stamped on AuthState.Success at the three credential-exchange sites, and the pending operation is consumed only for a library-published success on that same uid, exactly once. Activity recreation resumes the same request; process death reports an interruption rather than dropping it.

⚠️Breaking changes

• reauthContent takes a single ReauthContentState instead of (state, onDismiss).
• AuthState.Success can no longer be constructed outside the library. It records which uid a reauthentication re-proved, and that proof must not be forgeable by app code.
• AuthState.ReauthenticationRequired is now AuthState.Reauthentication.Required, nested with the other reauthentication phases under a new public AuthState.Reauthentication sealed class.
• ReauthContentState moves to com.firebase.ui.auth.ui.screens.reauth.
• MfaChallengeScreen and MfaEnrollmentScreen move to com.firebase.ui.auth.ui.screens.mfa.

While a reauthentication is in progress, authStateFlow() and AuthFlowController.state() emit AuthState.Reauthentication phases, so is AuthState.Error, is AuthState.Loading and is AuthState.Cancelled do not match for that window. The outcome is published as an ordinary state once the request completes. This is documented in auth/README.md.

• ReauthContentState.kt: new public state holder, following the MfaEnrollmentContentState conventions.
• AuthState.kt: Success gains reauthenticatedUid and an internal constructor; the reauthentication phases become a nested sealed hierarchy keyed by requestId.
• FirebaseAuthUI.kt: one guarded transition entry point plus session start/finish; ordinary states are folded into reauthentication phases only while a screen is registered to drain them, so an arming created by public API with no screen composed stays inert.
• FirebaseAuthScreen.kt: the linked-provider list reaches the slot instead of being discarded; provider selection, error-dialog recovery, deep links and the non-terminal navigation branches are inert while a reauthentication is armed.
• EmailAuthProvider+FirebaseAuthUI.kt, OAuthProvider+FirebaseAuthUI.kt: stamp reauthenticatedUid where the reauthenticated identity is known; account creation and credential linking are rejected in reauthentication mode.
• SignInUI.kt: sign-up, password recovery and email-link sign-in are not offered while reauthenticating, and Credential Manager autofill is skipped so a saved password for another account cannot be auto-submitted.
• ui/screens/reauth/, ui/screens/mfa/: reauthentication and MFA UI extracted into their own packages, mirroring the existing ui/screens/email/ and ui/screens/phone/.

Added FirebaseAuthScreenReauthContentStateTest, EmailAuthScreenReauthEmailLockTest and coverage across FirebaseAuthUIAuthStateTest, plus e2e coverage of reauthentication through the slot — every new test verified to be load-bearing by temporarily reverting the fix and confirming it fails.

Usage

FirebaseAuthScreen(
configuration = configuration,
onSignInSuccess = { },
onSignInFailure = { },
onSignInCancelled = { },
reauthContent = { state ->AlertDialog(
onDismissRequest = state.onDismiss,
title = { Text(state.reason ?:"Verify your identity") },
text = {
Column(modifier =Modifier.verticalScroll(rememberScrollState())) {
state.error?.let { Text(it, color =MaterialTheme.colorScheme.error) }
if (state.isLoading) CircularProgressIndicator()
state.providers.forEach { provider ->Button(
onClick = { state.onProviderSelected(provider) },
enabled =!state.isLoading,
) { Text("Continue with ${provider.providerName}") }
}
}
},
confirmButton = {},
dismissButton = { TextButton(onClick = state.onDismiss) { Text("Cancel") } },
)
},
)

[gemini-code-assist]

Code Review

This pull request introduces a robust reauthentication flow in FirebaseUI Auth for Android, separating operation-level cancellations (AuthState.Cancelled) from flow-level aborts (AuthState.Aborted). It adds support for a custom, stateless reauthContent slot in FirebaseAuthScreen while keeping credential exchanges owned by the library, locks the email field to read-only during reauthentication, and resolves several state-resetting edge cases. The review feedback suggests making the OAuth reauthentication path more robust and fail-fast by explicitly throwing an exception if auth.currentUser is unexpectedly null, rather than silently failing with a safe call.

[russellwheatley]

Two suggestions on the reauth config copy and state survival across rotation, nothing blocking otherwise. The uid-matching consumption logic, the internal AuthState.Success constructor, and the inert-while-armed gating all check out.

[russellwheatley]

Re-reviewed after the state-machine refactor and the two follow-up fixes. Both issues from the last round are fixed properly, not just carried over (isCredentialLinkingEnabled/isAnonymousUpgradeEnabled reset now applies at both reauth-config construction sites, and the rememberSaveable gap turned into a proper ReauthPresentationState + Saver that reconciles correctly on both rotation and process death). Two minor items left, neither blocking on their own, flagging so they don't get lost:

• inline comment below on AuthState.Success's constructor going internal
• e2eTest/src/test/java/com/firebase/ui/auth/ui/screens/ReauthFlowTest.kt has no dedicated case for sign-out-during-retry or phone-verification-teardown. Both are already covered at the unit/screen level (FirebaseAuthScreenReauthIdleResetTest.kt, PhoneAuthScreenVerificationLifecycleTest.kt), so this is more of a nice-to-have than something I'd hold the PR on.

[demolaf]

reauthContent was documented and shaped as a content slot alongside emailContent, phoneContent and the MFA slots, but it received only (AuthState.ReauthenticationRequired, onDismiss) and every API needed to build a reauthentication UI — filterToLinkedProviders, isReauthenticationMode, the federated provider driver — was internal or private. A custom slot could therefore only perform email/password reauthentication and had to dead-end for a Google- or OAuth-only account. The success handoff was also easy to get wrong: onDismiss reset auth state to Idle while retryOperation emitted AuthState.Success, so both orderings a caller would naturally reach either clobbered the success or cancelled the scope the retry ran in, silently dropping the sensitive operation.

reauthContent now receives a single ReauthContentState carrying the user, the reason, the providers already filtered to those linked to that user, and callbacks to select a provider or dismiss. The caller renders a provider chooser; the library owns credential exchange and dismiss/retry sequencing. Selecting AuthProvider.Email or AuthProvider.Phone hands off to the library's own sub-flow, honouring the caller's emailContent / phoneContent, and an MFA-enrolled user now completes the second factor inside the reauth surface rather than having the challenge render beneath it.

Reauthentication is a request-scoped state machine rather than seven independently mutable Compose holders. AuthState.Reauthentication carries a requestId and the pending operation; proof of reauthentication is a reauthenticatedUid stamped on AuthState.Success at the three credential-exchange sites, and the pending operation is consumed only for a library-published success on that same uid, exactly once. Activity recreation resumes the same request; process death reports an interruption rather than dropping it.

⚠️Breaking changes

• reauthContent takes a single ReauthContentState instead of (state, onDismiss).
• AuthState.Success can no longer be constructed outside the library. It records which uid a reauthentication re-proved, and that proof must not be forgeable by app code.
• AuthState.ReauthenticationRequired is now AuthState.Reauthentication.Required, nested with the other reauthentication phases under a new public AuthState.Reauthentication sealed class.
• ReauthContentState moves to com.firebase.ui.auth.ui.screens.reauth.
• MfaChallengeScreen and MfaEnrollmentScreen move to com.firebase.ui.auth.ui.screens.mfa.

While a reauthentication is in progress, authStateFlow() and AuthFlowController.state() emit AuthState.Reauthentication phases, so is AuthState.Error, is AuthState.Loading and is AuthState.Cancelled do not match for that window. The outcome is published as an ordinary state once the request completes. This is documented in auth/README.md.

• ReauthContentState.kt: new public state holder, following the MfaEnrollmentContentState conventions.
• AuthState.kt: Success gains reauthenticatedUid and an internal constructor; the reauthentication phases become a nested sealed hierarchy keyed by requestId.
• FirebaseAuthUI.kt: one guarded transition entry point plus session start/finish; ordinary states are folded into reauthentication phases only while a screen is registered to drain them, so an arming created by public API with no screen composed stays inert.
• FirebaseAuthScreen.kt: the linked-provider list reaches the slot instead of being discarded; provider selection, error-dialog recovery, deep links and the non-terminal navigation branches are inert while a reauthentication is armed.
• EmailAuthProvider+FirebaseAuthUI.kt, OAuthProvider+FirebaseAuthUI.kt: stamp reauthenticatedUid where the reauthenticated identity is known; account creation and credential linking are rejected in reauthentication mode.
• SignInUI.kt: sign-up, password recovery and email-link sign-in are not offered while reauthenticating, and Credential Manager autofill is skipped so a saved password for another account cannot be auto-submitted.
• ui/screens/reauth/, ui/screens/mfa/: reauthentication and MFA UI extracted into their own packages, mirroring the existing ui/screens/email/ and ui/screens/phone/.

Added FirebaseAuthScreenReauthContentStateTest, EmailAuthScreenReauthEmailLockTest and coverage across FirebaseAuthUIAuthStateTest, plus e2e coverage of reauthentication through the slot — every new test verified to be load-bearing by temporarily reverting the fix and confirming it fails.

Usage

FirebaseAuthScreen(
configuration = configuration,
onSignInSuccess = { },
onSignInFailure = { },
onSignInCancelled = { },
reauthContent = { state ->AlertDialog(
onDismissRequest = state.onDismiss,
title = { Text(state.reason ?:"Verify your identity") },
text = {
Column(modifier =Modifier.verticalScroll(rememberScrollState())) {
state.error?.let { Text(it, color =MaterialTheme.colorScheme.error) }
if (state.isLoading) CircularProgressIndicator()
state.providers.forEach { provider ->Button(
onClick = { state.onProviderSelected(provider) },
enabled =!state.isLoading,
) { Text("Continue with ${provider.providerName}") }
}
}
},
confirmButton = {},
dismissButton = { TextButton(onClick = state.onDismiss) { Text("Cancel") } },
)
},
)

[gemini-code-assist]

Code Review

This pull request introduces a robust reauthentication flow in FirebaseUI Auth for Android, separating operation-level cancellations (AuthState.Cancelled) from flow-level aborts (AuthState.Aborted). It adds support for a custom, stateless reauthContent slot in FirebaseAuthScreen while keeping credential exchanges owned by the library, locks the email field to read-only during reauthentication, and resolves several state-resetting edge cases. The review feedback suggests making the OAuth reauthentication path more robust and fail-fast by explicitly throwing an exception if auth.currentUser is unexpectedly null, rather than silently failing with a safe call.

[russellwheatley]

Two suggestions on the reauth config copy and state survival across rotation, nothing blocking otherwise. The uid-matching consumption logic, the internal AuthState.Success constructor, and the inert-while-armed gating all check out.

[russellwheatley]

Re-reviewed after the state-machine refactor and the two follow-up fixes. Both issues from the last round are fixed properly, not just carried over (isCredentialLinkingEnabled/isAnonymousUpgradeEnabled reset now applies at both reauth-config construction sites, and the rememberSaveable gap turned into a proper ReauthPresentationState + Saver that reconciles correctly on both rotation and process death). Two minor items left, neither blocking on their own, flagging so they don't get lost:

• inline comment below on AuthState.Success's constructor going internal
• e2eTest/src/test/java/com/firebase/ui/auth/ui/screens/ReauthFlowTest.kt has no dedicated case for sign-out-during-retry or phone-verification-teardown. Both are already covered at the unit/screen level (FirebaseAuthScreenReauthIdleResetTest.kt, PhoneAuthScreenVerificationLifecycleTest.kt), so this is more of a nice-to-have than something I'd hold the PR on.

[demolaf]

reauthContent was documented and shaped as a content slot alongside emailContent, phoneContent and the MFA slots, but it received only (AuthState.ReauthenticationRequired, onDismiss) and every API needed to build a reauthentication UI — filterToLinkedProviders, isReauthenticationMode, the federated provider driver — was internal or private. A custom slot could therefore only perform email/password reauthentication and had to dead-end for a Google- or OAuth-only account. The success handoff was also easy to get wrong: onDismiss reset auth state to Idle while retryOperation emitted AuthState.Success, so both orderings a caller would naturally reach either clobbered the success or cancelled the scope the retry ran in, silently dropping the sensitive operation.

reauthContent now receives a single ReauthContentState carrying the user, the reason, the providers already filtered to those linked to that user, and callbacks to select a provider or dismiss. The caller renders a provider chooser; the library owns credential exchange and dismiss/retry sequencing. Selecting AuthProvider.Email or AuthProvider.Phone hands off to the library's own sub-flow, honouring the caller's emailContent / phoneContent, and an MFA-enrolled user now completes the second factor inside the reauth surface rather than having the challenge render beneath it.

Reauthentication is a request-scoped state machine rather than seven independently mutable Compose holders. AuthState.Reauthentication carries a requestId and the pending operation; proof of reauthentication is a reauthenticatedUid stamped on AuthState.Success at the three credential-exchange sites, and the pending operation is consumed only for a library-published success on that same uid, exactly once. Activity recreation resumes the same request; process death reports an interruption rather than dropping it.

⚠️Breaking changes

• reauthContent takes a single ReauthContentState instead of (state, onDismiss).
• AuthState.Success can no longer be constructed outside the library. It records which uid a reauthentication re-proved, and that proof must not be forgeable by app code.
• AuthState.ReauthenticationRequired is now AuthState.Reauthentication.Required, nested with the other reauthentication phases under a new public AuthState.Reauthentication sealed class.
• ReauthContentState moves to com.firebase.ui.auth.ui.screens.reauth.
• MfaChallengeScreen and MfaEnrollmentScreen move to com.firebase.ui.auth.ui.screens.mfa.

While a reauthentication is in progress, authStateFlow() and AuthFlowController.state() emit AuthState.Reauthentication phases, so is AuthState.Error, is AuthState.Loading and is AuthState.Cancelled do not match for that window. The outcome is published as an ordinary state once the request completes. This is documented in auth/README.md.

• ReauthContentState.kt: new public state holder, following the MfaEnrollmentContentState conventions.
• AuthState.kt: Success gains reauthenticatedUid and an internal constructor; the reauthentication phases become a nested sealed hierarchy keyed by requestId.
• FirebaseAuthUI.kt: one guarded transition entry point plus session start/finish; ordinary states are folded into reauthentication phases only while a screen is registered to drain them, so an arming created by public API with no screen composed stays inert.
• FirebaseAuthScreen.kt: the linked-provider list reaches the slot instead of being discarded; provider selection, error-dialog recovery, deep links and the non-terminal navigation branches are inert while a reauthentication is armed.
• EmailAuthProvider+FirebaseAuthUI.kt, OAuthProvider+FirebaseAuthUI.kt: stamp reauthenticatedUid where the reauthenticated identity is known; account creation and credential linking are rejected in reauthentication mode.
• SignInUI.kt: sign-up, password recovery and email-link sign-in are not offered while reauthenticating, and Credential Manager autofill is skipped so a saved password for another account cannot be auto-submitted.
• ui/screens/reauth/, ui/screens/mfa/: reauthentication and MFA UI extracted into their own packages, mirroring the existing ui/screens/email/ and ui/screens/phone/.

Added FirebaseAuthScreenReauthContentStateTest, EmailAuthScreenReauthEmailLockTest and coverage across FirebaseAuthUIAuthStateTest, plus e2e coverage of reauthentication through the slot — every new test verified to be load-bearing by temporarily reverting the fix and confirming it fails.

Usage

FirebaseAuthScreen(
configuration = configuration,
onSignInSuccess = { },
onSignInFailure = { },
onSignInCancelled = { },
reauthContent = { state ->AlertDialog(
onDismissRequest = state.onDismiss,
title = { Text(state.reason ?:"Verify your identity") },
text = {
Column(modifier =Modifier.verticalScroll(rememberScrollState())) {
state.error?.let { Text(it, color =MaterialTheme.colorScheme.error) }
if (state.isLoading) CircularProgressIndicator()
state.providers.forEach { provider ->Button(
onClick = { state.onProviderSelected(provider) },
enabled =!state.isLoading,
) { Text("Continue with ${provider.providerName}") }
}
}
},
confirmButton = {},
dismissButton = { TextButton(onClick = state.onDismiss) { Text("Cancel") } },
)
},
)

[gemini-code-assist]

Code Review

This pull request introduces a robust reauthentication flow in FirebaseUI Auth for Android, separating operation-level cancellations (AuthState.Cancelled) from flow-level aborts (AuthState.Aborted). It adds support for a custom, stateless reauthContent slot in FirebaseAuthScreen while keeping credential exchanges owned by the library, locks the email field to read-only during reauthentication, and resolves several state-resetting edge cases. The review feedback suggests making the OAuth reauthentication path more robust and fail-fast by explicitly throwing an exception if auth.currentUser is unexpectedly null, rather than silently failing with a safe call.

[russellwheatley]

Two suggestions on the reauth config copy and state survival across rotation, nothing blocking otherwise. The uid-matching consumption logic, the internal AuthState.Success constructor, and the inert-while-armed gating all check out.

[russellwheatley]

Re-reviewed after the state-machine refactor and the two follow-up fixes. Both issues from the last round are fixed properly, not just carried over (isCredentialLinkingEnabled/isAnonymousUpgradeEnabled reset now applies at both reauth-config construction sites, and the rememberSaveable gap turned into a proper ReauthPresentationState + Saver that reconciles correctly on both rotation and process death). Two minor items left, neither blocking on their own, flagging so they don't get lost:

• inline comment below on AuthState.Success's constructor going internal
• e2eTest/src/test/java/com/firebase/ui/auth/ui/screens/ReauthFlowTest.kt has no dedicated case for sign-out-during-retry or phone-verification-teardown. Both are already covered at the unit/screen level (FirebaseAuthScreenReauthIdleResetTest.kt, PhoneAuthScreenVerificationLifecycleTest.kt), so this is more of a nice-to-have than something I'd hold the PR on.

[demolaf]

reauthContent was documented and shaped as a content slot alongside emailContent, phoneContent and the MFA slots, but it received only (AuthState.ReauthenticationRequired, onDismiss) and every API needed to build a reauthentication UI — filterToLinkedProviders, isReauthenticationMode, the federated provider driver — was internal or private. A custom slot could therefore only perform email/password reauthentication and had to dead-end for a Google- or OAuth-only account. The success handoff was also easy to get wrong: onDismiss reset auth state to Idle while retryOperation emitted AuthState.Success, so both orderings a caller would naturally reach either clobbered the success or cancelled the scope the retry ran in, silently dropping the sensitive operation.

reauthContent now receives a single ReauthContentState carrying the user, the reason, the providers already filtered to those linked to that user, and callbacks to select a provider or dismiss. The caller renders a provider chooser; the library owns credential exchange and dismiss/retry sequencing. Selecting AuthProvider.Email or AuthProvider.Phone hands off to the library's own sub-flow, honouring the caller's emailContent / phoneContent, and an MFA-enrolled user now completes the second factor inside the reauth surface rather than having the challenge render beneath it.

Reauthentication is a request-scoped state machine rather than seven independently mutable Compose holders. AuthState.Reauthentication carries a requestId and the pending operation; proof of reauthentication is a reauthenticatedUid stamped on AuthState.Success at the three credential-exchange sites, and the pending operation is consumed only for a library-published success on that same uid, exactly once. Activity recreation resumes the same request; process death reports an interruption rather than dropping it.

⚠️Breaking changes

• reauthContent takes a single ReauthContentState instead of (state, onDismiss).
• AuthState.Success can no longer be constructed outside the library. It records which uid a reauthentication re-proved, and that proof must not be forgeable by app code.
• AuthState.ReauthenticationRequired is now AuthState.Reauthentication.Required, nested with the other reauthentication phases under a new public AuthState.Reauthentication sealed class.
• ReauthContentState moves to com.firebase.ui.auth.ui.screens.reauth.
• MfaChallengeScreen and MfaEnrollmentScreen move to com.firebase.ui.auth.ui.screens.mfa.

While a reauthentication is in progress, authStateFlow() and AuthFlowController.state() emit AuthState.Reauthentication phases, so is AuthState.Error, is AuthState.Loading and is AuthState.Cancelled do not match for that window. The outcome is published as an ordinary state once the request completes. This is documented in auth/README.md.

• ReauthContentState.kt: new public state holder, following the MfaEnrollmentContentState conventions.
• AuthState.kt: Success gains reauthenticatedUid and an internal constructor; the reauthentication phases become a nested sealed hierarchy keyed by requestId.
• FirebaseAuthUI.kt: one guarded transition entry point plus session start/finish; ordinary states are folded into reauthentication phases only while a screen is registered to drain them, so an arming created by public API with no screen composed stays inert.
• FirebaseAuthScreen.kt: the linked-provider list reaches the slot instead of being discarded; provider selection, error-dialog recovery, deep links and the non-terminal navigation branches are inert while a reauthentication is armed.
• EmailAuthProvider+FirebaseAuthUI.kt, OAuthProvider+FirebaseAuthUI.kt: stamp reauthenticatedUid where the reauthenticated identity is known; account creation and credential linking are rejected in reauthentication mode.
• SignInUI.kt: sign-up, password recovery and email-link sign-in are not offered while reauthenticating, and Credential Manager autofill is skipped so a saved password for another account cannot be auto-submitted.
• ui/screens/reauth/, ui/screens/mfa/: reauthentication and MFA UI extracted into their own packages, mirroring the existing ui/screens/email/ and ui/screens/phone/.

Added FirebaseAuthScreenReauthContentStateTest, EmailAuthScreenReauthEmailLockTest and coverage across FirebaseAuthUIAuthStateTest, plus e2e coverage of reauthentication through the slot — every new test verified to be load-bearing by temporarily reverting the fix and confirming it fails.

Usage

FirebaseAuthScreen(
configuration = configuration,
onSignInSuccess = { },
onSignInFailure = { },
onSignInCancelled = { },
reauthContent = { state ->AlertDialog(
onDismissRequest = state.onDismiss,
title = { Text(state.reason ?:"Verify your identity") },
text = {
Column(modifier =Modifier.verticalScroll(rememberScrollState())) {
state.error?.let { Text(it, color =MaterialTheme.colorScheme.error) }
if (state.isLoading) CircularProgressIndicator()
state.providers.forEach { provider ->Button(
onClick = { state.onProviderSelected(provider) },
enabled =!state.isLoading,
) { Text("Continue with ${provider.providerName}") }
}
}
},
confirmButton = {},
dismissButton = { TextButton(onClick = state.onDismiss) { Text("Cancel") } },
)
},
)

[gemini-code-assist]

Code Review

This pull request introduces a robust reauthentication flow in FirebaseUI Auth for Android, separating operation-level cancellations (AuthState.Cancelled) from flow-level aborts (AuthState.Aborted). It adds support for a custom, stateless reauthContent slot in FirebaseAuthScreen while keeping credential exchanges owned by the library, locks the email field to read-only during reauthentication, and resolves several state-resetting edge cases. The review feedback suggests making the OAuth reauthentication path more robust and fail-fast by explicitly throwing an exception if auth.currentUser is unexpectedly null, rather than silently failing with a safe call.

[russellwheatley]

Two suggestions on the reauth config copy and state survival across rotation, nothing blocking otherwise. The uid-matching consumption logic, the internal AuthState.Success constructor, and the inert-while-armed gating all check out.

[russellwheatley]

Re-reviewed after the state-machine refactor and the two follow-up fixes. Both issues from the last round are fixed properly, not just carried over (isCredentialLinkingEnabled/isAnonymousUpgradeEnabled reset now applies at both reauth-config construction sites, and the rememberSaveable gap turned into a proper ReauthPresentationState + Saver that reconciles correctly on both rotation and process death). Two minor items left, neither blocking on their own, flagging so they don't get lost:

• inline comment below on AuthState.Success's constructor going internal
• e2eTest/src/test/java/com/firebase/ui/auth/ui/screens/ReauthFlowTest.kt has no dedicated case for sign-out-during-retry or phone-verification-teardown. Both are already covered at the unit/screen level (FirebaseAuthScreenReauthIdleResetTest.kt, PhoneAuthScreenVerificationLifecycleTest.kt), so this is more of a nice-to-have than something I'd hold the PR on.

[demolaf]

reauthContent was documented and shaped as a content slot alongside emailContent, phoneContent and the MFA slots, but it received only (AuthState.ReauthenticationRequired, onDismiss) and every API needed to build a reauthentication UI — filterToLinkedProviders, isReauthenticationMode, the federated provider driver — was internal or private. A custom slot could therefore only perform email/password reauthentication and had to dead-end for a Google- or OAuth-only account. The success handoff was also easy to get wrong: onDismiss reset auth state to Idle while retryOperation emitted AuthState.Success, so both orderings a caller would naturally reach either clobbered the success or cancelled the scope the retry ran in, silently dropping the sensitive operation.

reauthContent now receives a single ReauthContentState carrying the user, the reason, the providers already filtered to those linked to that user, and callbacks to select a provider or dismiss. The caller renders a provider chooser; the library owns credential exchange and dismiss/retry sequencing. Selecting AuthProvider.Email or AuthProvider.Phone hands off to the library's own sub-flow, honouring the caller's emailContent / phoneContent, and an MFA-enrolled user now completes the second factor inside the reauth surface rather than having the challenge render beneath it.

Reauthentication is a request-scoped state machine rather than seven independently mutable Compose holders. AuthState.Reauthentication carries a requestId and the pending operation; proof of reauthentication is a reauthenticatedUid stamped on AuthState.Success at the three credential-exchange sites, and the pending operation is consumed only for a library-published success on that same uid, exactly once. Activity recreation resumes the same request; process death reports an interruption rather than dropping it.

⚠️Breaking changes

• reauthContent takes a single ReauthContentState instead of (state, onDismiss).
• AuthState.Success can no longer be constructed outside the library. It records which uid a reauthentication re-proved, and that proof must not be forgeable by app code.
• AuthState.ReauthenticationRequired is now AuthState.Reauthentication.Required, nested with the other reauthentication phases under a new public AuthState.Reauthentication sealed class.
• ReauthContentState moves to com.firebase.ui.auth.ui.screens.reauth.
• MfaChallengeScreen and MfaEnrollmentScreen move to com.firebase.ui.auth.ui.screens.mfa.

While a reauthentication is in progress, authStateFlow() and AuthFlowController.state() emit AuthState.Reauthentication phases, so is AuthState.Error, is AuthState.Loading and is AuthState.Cancelled do not match for that window. The outcome is published as an ordinary state once the request completes. This is documented in auth/README.md.

• ReauthContentState.kt: new public state holder, following the MfaEnrollmentContentState conventions.
• AuthState.kt: Success gains reauthenticatedUid and an internal constructor; the reauthentication phases become a nested sealed hierarchy keyed by requestId.
• FirebaseAuthUI.kt: one guarded transition entry point plus session start/finish; ordinary states are folded into reauthentication phases only while a screen is registered to drain them, so an arming created by public API with no screen composed stays inert.
• FirebaseAuthScreen.kt: the linked-provider list reaches the slot instead of being discarded; provider selection, error-dialog recovery, deep links and the non-terminal navigation branches are inert while a reauthentication is armed.
• EmailAuthProvider+FirebaseAuthUI.kt, OAuthProvider+FirebaseAuthUI.kt: stamp reauthenticatedUid where the reauthenticated identity is known; account creation and credential linking are rejected in reauthentication mode.
• SignInUI.kt: sign-up, password recovery and email-link sign-in are not offered while reauthenticating, and Credential Manager autofill is skipped so a saved password for another account cannot be auto-submitted.
• ui/screens/reauth/, ui/screens/mfa/: reauthentication and MFA UI extracted into their own packages, mirroring the existing ui/screens/email/ and ui/screens/phone/.

Added FirebaseAuthScreenReauthContentStateTest, EmailAuthScreenReauthEmailLockTest and coverage across FirebaseAuthUIAuthStateTest, plus e2e coverage of reauthentication through the slot — every new test verified to be load-bearing by temporarily reverting the fix and confirming it fails.

Usage

FirebaseAuthScreen(
configuration = configuration,
onSignInSuccess = { },
onSignInFailure = { },
onSignInCancelled = { },
reauthContent = { state ->AlertDialog(
onDismissRequest = state.onDismiss,
title = { Text(state.reason ?:"Verify your identity") },
text = {
Column(modifier =Modifier.verticalScroll(rememberScrollState())) {
state.error?.let { Text(it, color =MaterialTheme.colorScheme.error) }
if (state.isLoading) CircularProgressIndicator()
state.providers.forEach { provider ->Button(
onClick = { state.onProviderSelected(provider) },
enabled =!state.isLoading,
) { Text("Continue with ${provider.providerName}") }
}
}
},
confirmButton = {},
dismissButton = { TextButton(onClick = state.onDismiss) { Text("Cancel") } },
)
},
)

[gemini-code-assist]

Code Review

This pull request introduces a robust reauthentication flow in FirebaseUI Auth for Android, separating operation-level cancellations (AuthState.Cancelled) from flow-level aborts (AuthState.Aborted). It adds support for a custom, stateless reauthContent slot in FirebaseAuthScreen while keeping credential exchanges owned by the library, locks the email field to read-only during reauthentication, and resolves several state-resetting edge cases. The review feedback suggests making the OAuth reauthentication path more robust and fail-fast by explicitly throwing an exception if auth.currentUser is unexpectedly null, rather than silently failing with a safe call.

[russellwheatley]

Two suggestions on the reauth config copy and state survival across rotation, nothing blocking otherwise. The uid-matching consumption logic, the internal AuthState.Success constructor, and the inert-while-armed gating all check out.

[russellwheatley]

Re-reviewed after the state-machine refactor and the two follow-up fixes. Both issues from the last round are fixed properly, not just carried over (isCredentialLinkingEnabled/isAnonymousUpgradeEnabled reset now applies at both reauth-config construction sites, and the rememberSaveable gap turned into a proper ReauthPresentationState + Saver that reconciles correctly on both rotation and process death). Two minor items left, neither blocking on their own, flagging so they don't get lost:

• inline comment below on AuthState.Success's constructor going internal
• e2eTest/src/test/java/com/firebase/ui/auth/ui/screens/ReauthFlowTest.kt has no dedicated case for sign-out-during-retry or phone-verification-teardown. Both are already covered at the unit/screen level (FirebaseAuthScreenReauthIdleResetTest.kt, PhoneAuthScreenVerificationLifecycleTest.kt), so this is more of a nice-to-have than something I'd hold the PR on.

[demolaf]

reauthContent was documented and shaped as a content slot alongside emailContent, phoneContent and the MFA slots, but it received only (AuthState.ReauthenticationRequired, onDismiss) and every API needed to build a reauthentication UI — filterToLinkedProviders, isReauthenticationMode, the federated provider driver — was internal or private. A custom slot could therefore only perform email/password reauthentication and had to dead-end for a Google- or OAuth-only account. The success handoff was also easy to get wrong: onDismiss reset auth state to Idle while retryOperation emitted AuthState.Success, so both orderings a caller would naturally reach either clobbered the success or cancelled the scope the retry ran in, silently dropping the sensitive operation.

reauthContent now receives a single ReauthContentState carrying the user, the reason, the providers already filtered to those linked to that user, and callbacks to select a provider or dismiss. The caller renders a provider chooser; the library owns credential exchange and dismiss/retry sequencing. Selecting AuthProvider.Email or AuthProvider.Phone hands off to the library's own sub-flow, honouring the caller's emailContent / phoneContent, and an MFA-enrolled user now completes the second factor inside the reauth surface rather than having the challenge render beneath it.

Reauthentication is a request-scoped state machine rather than seven independently mutable Compose holders. AuthState.Reauthentication carries a requestId and the pending operation; proof of reauthentication is a reauthenticatedUid stamped on AuthState.Success at the three credential-exchange sites, and the pending operation is consumed only for a library-published success on that same uid, exactly once. Activity recreation resumes the same request; process death reports an interruption rather than dropping it.

⚠️Breaking changes

• reauthContent takes a single ReauthContentState instead of (state, onDismiss).
• AuthState.Success can no longer be constructed outside the library. It records which uid a reauthentication re-proved, and that proof must not be forgeable by app code.
• AuthState.ReauthenticationRequired is now AuthState.Reauthentication.Required, nested with the other reauthentication phases under a new public AuthState.Reauthentication sealed class.
• ReauthContentState moves to com.firebase.ui.auth.ui.screens.reauth.
• MfaChallengeScreen and MfaEnrollmentScreen move to com.firebase.ui.auth.ui.screens.mfa.

While a reauthentication is in progress, authStateFlow() and AuthFlowController.state() emit AuthState.Reauthentication phases, so is AuthState.Error, is AuthState.Loading and is AuthState.Cancelled do not match for that window. The outcome is published as an ordinary state once the request completes. This is documented in auth/README.md.

• ReauthContentState.kt: new public state holder, following the MfaEnrollmentContentState conventions.
• AuthState.kt: Success gains reauthenticatedUid and an internal constructor; the reauthentication phases become a nested sealed hierarchy keyed by requestId.
• FirebaseAuthUI.kt: one guarded transition entry point plus session start/finish; ordinary states are folded into reauthentication phases only while a screen is registered to drain them, so an arming created by public API with no screen composed stays inert.
• FirebaseAuthScreen.kt: the linked-provider list reaches the slot instead of being discarded; provider selection, error-dialog recovery, deep links and the non-terminal navigation branches are inert while a reauthentication is armed.
• EmailAuthProvider+FirebaseAuthUI.kt, OAuthProvider+FirebaseAuthUI.kt: stamp reauthenticatedUid where the reauthenticated identity is known; account creation and credential linking are rejected in reauthentication mode.
• SignInUI.kt: sign-up, password recovery and email-link sign-in are not offered while reauthenticating, and Credential Manager autofill is skipped so a saved password for another account cannot be auto-submitted.
• ui/screens/reauth/, ui/screens/mfa/: reauthentication and MFA UI extracted into their own packages, mirroring the existing ui/screens/email/ and ui/screens/phone/.

Added FirebaseAuthScreenReauthContentStateTest, EmailAuthScreenReauthEmailLockTest and coverage across FirebaseAuthUIAuthStateTest, plus e2e coverage of reauthentication through the slot — every new test verified to be load-bearing by temporarily reverting the fix and confirming it fails.

Usage

FirebaseAuthScreen(
configuration = configuration,
onSignInSuccess = { },
onSignInFailure = { },
onSignInCancelled = { },
reauthContent = { state ->AlertDialog(
onDismissRequest = state.onDismiss,
title = { Text(state.reason ?:"Verify your identity") },
text = {
Column(modifier =Modifier.verticalScroll(rememberScrollState())) {
state.error?.let { Text(it, color =MaterialTheme.colorScheme.error) }
if (state.isLoading) CircularProgressIndicator()
state.providers.forEach { provider ->Button(
onClick = { state.onProviderSelected(provider) },
enabled =!state.isLoading,
) { Text("Continue with ${provider.providerName}") }
}
}
},
confirmButton = {},
dismissButton = { TextButton(onClick = state.onDismiss) { Text("Cancel") } },
)
},
)

[gemini-code-assist]

Code Review

This pull request introduces a robust reauthentication flow in FirebaseUI Auth for Android, separating operation-level cancellations (AuthState.Cancelled) from flow-level aborts (AuthState.Aborted). It adds support for a custom, stateless reauthContent slot in FirebaseAuthScreen while keeping credential exchanges owned by the library, locks the email field to read-only during reauthentication, and resolves several state-resetting edge cases. The review feedback suggests making the OAuth reauthentication path more robust and fail-fast by explicitly throwing an exception if auth.currentUser is unexpectedly null, rather than silently failing with a safe call.

[russellwheatley]

Two suggestions on the reauth config copy and state survival across rotation, nothing blocking otherwise. The uid-matching consumption logic, the internal AuthState.Success constructor, and the inert-while-armed gating all check out.

[russellwheatley]

Re-reviewed after the state-machine refactor and the two follow-up fixes. Both issues from the last round are fixed properly, not just carried over (isCredentialLinkingEnabled/isAnonymousUpgradeEnabled reset now applies at both reauth-config construction sites, and the rememberSaveable gap turned into a proper ReauthPresentationState + Saver that reconciles correctly on both rotation and process death). Two minor items left, neither blocking on their own, flagging so they don't get lost:

• inline comment below on AuthState.Success's constructor going internal
• e2eTest/src/test/java/com/firebase/ui/auth/ui/screens/ReauthFlowTest.kt has no dedicated case for sign-out-during-retry or phone-verification-teardown. Both are already covered at the unit/screen level (FirebaseAuthScreenReauthIdleResetTest.kt, PhoneAuthScreenVerificationLifecycleTest.kt), so this is more of a nice-to-have than something I'd hold the PR on.

[demolaf]

reauthContent was documented and shaped as a content slot alongside emailContent, phoneContent and the MFA slots, but it received only (AuthState.ReauthenticationRequired, onDismiss) and every API needed to build a reauthentication UI — filterToLinkedProviders, isReauthenticationMode, the federated provider driver — was internal or private. A custom slot could therefore only perform email/password reauthentication and had to dead-end for a Google- or OAuth-only account. The success handoff was also easy to get wrong: onDismiss reset auth state to Idle while retryOperation emitted AuthState.Success, so both orderings a caller would naturally reach either clobbered the success or cancelled the scope the retry ran in, silently dropping the sensitive operation.

reauthContent now receives a single ReauthContentState carrying the user, the reason, the providers already filtered to those linked to that user, and callbacks to select a provider or dismiss. The caller renders a provider chooser; the library owns credential exchange and dismiss/retry sequencing. Selecting AuthProvider.Email or AuthProvider.Phone hands off to the library's own sub-flow, honouring the caller's emailContent / phoneContent, and an MFA-enrolled user now completes the second factor inside the reauth surface rather than having the challenge render beneath it.

Reauthentication is a request-scoped state machine rather than seven independently mutable Compose holders. AuthState.Reauthentication carries a requestId and the pending operation; proof of reauthentication is a reauthenticatedUid stamped on AuthState.Success at the three credential-exchange sites, and the pending operation is consumed only for a library-published success on that same uid, exactly once. Activity recreation resumes the same request; process death reports an interruption rather than dropping it.

⚠️Breaking changes

• reauthContent takes a single ReauthContentState instead of (state, onDismiss).
• AuthState.Success can no longer be constructed outside the library. It records which uid a reauthentication re-proved, and that proof must not be forgeable by app code.
• AuthState.ReauthenticationRequired is now AuthState.Reauthentication.Required, nested with the other reauthentication phases under a new public AuthState.Reauthentication sealed class.
• ReauthContentState moves to com.firebase.ui.auth.ui.screens.reauth.
• MfaChallengeScreen and MfaEnrollmentScreen move to com.firebase.ui.auth.ui.screens.mfa.

While a reauthentication is in progress, authStateFlow() and AuthFlowController.state() emit AuthState.Reauthentication phases, so is AuthState.Error, is AuthState.Loading and is AuthState.Cancelled do not match for that window. The outcome is published as an ordinary state once the request completes. This is documented in auth/README.md.

• ReauthContentState.kt: new public state holder, following the MfaEnrollmentContentState conventions.
• AuthState.kt: Success gains reauthenticatedUid and an internal constructor; the reauthentication phases become a nested sealed hierarchy keyed by requestId.
• FirebaseAuthUI.kt: one guarded transition entry point plus session start/finish; ordinary states are folded into reauthentication phases only while a screen is registered to drain them, so an arming created by public API with no screen composed stays inert.
• FirebaseAuthScreen.kt: the linked-provider list reaches the slot instead of being discarded; provider selection, error-dialog recovery, deep links and the non-terminal navigation branches are inert while a reauthentication is armed.
• EmailAuthProvider+FirebaseAuthUI.kt, OAuthProvider+FirebaseAuthUI.kt: stamp reauthenticatedUid where the reauthenticated identity is known; account creation and credential linking are rejected in reauthentication mode.
• SignInUI.kt: sign-up, password recovery and email-link sign-in are not offered while reauthenticating, and Credential Manager autofill is skipped so a saved password for another account cannot be auto-submitted.
• ui/screens/reauth/, ui/screens/mfa/: reauthentication and MFA UI extracted into their own packages, mirroring the existing ui/screens/email/ and ui/screens/phone/.

Added FirebaseAuthScreenReauthContentStateTest, EmailAuthScreenReauthEmailLockTest and coverage across FirebaseAuthUIAuthStateTest, plus e2e coverage of reauthentication through the slot — every new test verified to be load-bearing by temporarily reverting the fix and confirming it fails.

Usage

FirebaseAuthScreen(
configuration = configuration,
onSignInSuccess = { },
onSignInFailure = { },
onSignInCancelled = { },
reauthContent = { state ->AlertDialog(
onDismissRequest = state.onDismiss,
title = { Text(state.reason ?:"Verify your identity") },
text = {
Column(modifier =Modifier.verticalScroll(rememberScrollState())) {
state.error?.let { Text(it, color =MaterialTheme.colorScheme.error) }
if (state.isLoading) CircularProgressIndicator()
state.providers.forEach { provider ->Button(
onClick = { state.onProviderSelected(provider) },
enabled =!state.isLoading,
) { Text("Continue with ${provider.providerName}") }
}
}
},
confirmButton = {},
dismissButton = { TextButton(onClick = state.onDismiss) { Text("Cancel") } },
)
},
)

[gemini-code-assist]

Code Review

This pull request introduces a robust reauthentication flow in FirebaseUI Auth for Android, separating operation-level cancellations (AuthState.Cancelled) from flow-level aborts (AuthState.Aborted). It adds support for a custom, stateless reauthContent slot in FirebaseAuthScreen while keeping credential exchanges owned by the library, locks the email field to read-only during reauthentication, and resolves several state-resetting edge cases. The review feedback suggests making the OAuth reauthentication path more robust and fail-fast by explicitly throwing an exception if auth.currentUser is unexpectedly null, rather than silently failing with a safe call.

[russellwheatley]

Two suggestions on the reauth config copy and state survival across rotation, nothing blocking otherwise. The uid-matching consumption logic, the internal AuthState.Success constructor, and the inert-while-armed gating all check out.

[russellwheatley]

Re-reviewed after the state-machine refactor and the two follow-up fixes. Both issues from the last round are fixed properly, not just carried over (isCredentialLinkingEnabled/isAnonymousUpgradeEnabled reset now applies at both reauth-config construction sites, and the rememberSaveable gap turned into a proper ReauthPresentationState + Saver that reconciles correctly on both rotation and process death). Two minor items left, neither blocking on their own, flagging so they don't get lost:

• inline comment below on AuthState.Success's constructor going internal
• e2eTest/src/test/java/com/firebase/ui/auth/ui/screens/ReauthFlowTest.kt has no dedicated case for sign-out-during-retry or phone-verification-teardown. Both are already covered at the unit/screen level (FirebaseAuthScreenReauthIdleResetTest.kt, PhoneAuthScreenVerificationLifecycleTest.kt), so this is more of a nice-to-have than something I'd hold the PR on.