The Gmail app-password setup screen (AppPasswordSetupScreen.kt) already warns the user that Gmail
requires 2-Step Verification before an app password can be created — app_password_intro_gmail
(strings.xml:149): "To connect Gmail, create an app password in your Google Account. Gmail requires
2-Step Verification to be turned on before you can create one." But the screen gives the user no way to
act on that if it isn't already on. The only outbound link on the screen is the "Create an app password
for Gmail" button (AppPasswordSetupScreen.kt:148-157), which opens MailProvider.GMAIL.appPasswordHelpUrl
= https://myaccount.google.com/apppasswords (MailProvider.kt:40) — the page that itself rejects/bounces
the user if 2-Step Verification isn't enabled yet.
So a user without 2FA already on gets stuck: the in-app text names the prerequisite, but the only link
provided is to the page that requires it, not one that explains how to satisfy it.
This is Gmail-specific — neither Yahoo's nor iCloud's intro string (app_password_intro_yahoo / app_password_intro_icloud, strings.xml:150-151) mentions a 2FA prerequisite, so only the Gmail path
needs to change.
Suggested approach
Add a second, conditional action on the Gmail app-password screen that opens Google's official 2-Step
Verification setup help article, reusing the same LocalUriHandler + runCatching pattern already used
for the app-password button (AppPasswordSetupScreen.kt:148-153) rather than introducing a new one.
MailProvider.appPasswordHelpUrl (MailProvider.kt:31) is a per-entry enum field; the simplest fit is
another nullable field (e.g. twoFactorHelpUrl: String?), null for Yahoo/iCloud, set for Gmail to
Google's 2-Step Verification article (e.g. https://support.google.com/accounts/answer/185839 —
reconfirm the exact current URL when implementing).
Surface it as a second OutlinedButton (or plain text link) directly under the existing "Create an app
password" button (AppPasswordSetupScreen.kt:147-157), shown only when the field is non-null, with a
new string resource (e.g. app_password_2fa_help) following the existing app_password_* naming.
Route failures (no browser handler installed) through the same inline-snackbar plumbing already in
place (AppPasswordSetupScreen.kt:80,150-152) instead of duplicating it.
Acceptance criteria
From the Gmail app-password setup screen, a user without 2-Step Verification enabled has an in-app
link to Google's official setup instructions (not just the app-passwords page, which will reject
them).
Yahoo and iCloud setup screens are unaffected — no new link shown for either.
Failure to open the browser is surfaced the same way as the existing app-password link (inline
snackbar, not a crash).
New string(s) added to strings.xml following the existing app_password_* naming convention.
## Problem
The Gmail app-password setup screen (`AppPasswordSetupScreen.kt`) already warns the user that Gmail
requires 2-Step Verification before an app password can be created — `app_password_intro_gmail`
(`strings.xml:149`): *"To connect Gmail, create an app password in your Google Account. Gmail requires
2-Step Verification to be turned on before you can create one."* But the screen gives the user no way to
act on that if it isn't already on. The only outbound link on the screen is the "Create an app password
for Gmail" button (`AppPasswordSetupScreen.kt:148-157`), which opens `MailProvider.GMAIL.appPasswordHelpUrl`
= `https://myaccount.google.com/apppasswords` (`MailProvider.kt:40`) — the page that itself rejects/bounces
the user if 2-Step Verification isn't enabled yet.
So a user without 2FA already on gets stuck: the in-app text names the prerequisite, but the only link
provided is to the page that *requires* it, not one that explains how to *satisfy* it.
This is Gmail-specific — neither Yahoo's nor iCloud's intro string (`app_password_intro_yahoo` /
`app_password_intro_icloud`, `strings.xml:150-151`) mentions a 2FA prerequisite, so only the Gmail path
needs to change.
## Suggested approach
Add a second, conditional action on the Gmail app-password screen that opens Google's official 2-Step
Verification setup help article, reusing the same `LocalUriHandler` + `runCatching` pattern already used
for the app-password button (`AppPasswordSetupScreen.kt:148-153`) rather than introducing a new one.
- `MailProvider.appPasswordHelpUrl` (`MailProvider.kt:31`) is a per-entry enum field; the simplest fit is
another nullable field (e.g. `twoFactorHelpUrl: String?`), `null` for Yahoo/iCloud, set for Gmail to
Google's 2-Step Verification article (e.g. `https://support.google.com/accounts/answer/185839` —
reconfirm the exact current URL when implementing).
- Surface it as a second `OutlinedButton` (or plain text link) directly under the existing "Create an app
password" button (`AppPasswordSetupScreen.kt:147-157`), shown only when the field is non-null, with a
new string resource (e.g. `app_password_2fa_help`) following the existing `app_password_*` naming.
- Route failures (no browser handler installed) through the same inline-snackbar plumbing already in
place (`AppPasswordSetupScreen.kt:80,150-152`) instead of duplicating it.
## Acceptance criteria
- [ ] From the Gmail app-password setup screen, a user without 2-Step Verification enabled has an in-app
link to Google's official setup instructions (not just the app-passwords page, which will reject
them).
- [ ] Yahoo and iCloud setup screens are unaffected — no new link shown for either.
- [ ] Failure to open the browser is surfaced the same way as the existing app-password link (inline
snackbar, not a crash).
- [ ] New string(s) added to `strings.xml` following the existing `app_password_*` naming convention.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Problem
The Gmail app-password setup screen (
AppPasswordSetupScreen.kt) already warns the user that Gmailrequires 2-Step Verification before an app password can be created —
app_password_intro_gmail(
strings.xml:149): "To connect Gmail, create an app password in your Google Account. Gmail requires2-Step Verification to be turned on before you can create one." But the screen gives the user no way to
act on that if it isn't already on. The only outbound link on the screen is the "Create an app password
for Gmail" button (
AppPasswordSetupScreen.kt:148-157), which opensMailProvider.GMAIL.appPasswordHelpUrl=
https://myaccount.google.com/apppasswords(MailProvider.kt:40) — the page that itself rejects/bouncesthe user if 2-Step Verification isn't enabled yet.
So a user without 2FA already on gets stuck: the in-app text names the prerequisite, but the only link
provided is to the page that requires it, not one that explains how to satisfy it.
This is Gmail-specific — neither Yahoo's nor iCloud's intro string (
app_password_intro_yahoo/app_password_intro_icloud,strings.xml:150-151) mentions a 2FA prerequisite, so only the Gmail pathneeds to change.
Suggested approach
Add a second, conditional action on the Gmail app-password screen that opens Google's official 2-Step
Verification setup help article, reusing the same
LocalUriHandler+runCatchingpattern already usedfor the app-password button (
AppPasswordSetupScreen.kt:148-153) rather than introducing a new one.MailProvider.appPasswordHelpUrl(MailProvider.kt:31) is a per-entry enum field; the simplest fit isanother nullable field (e.g.
twoFactorHelpUrl: String?),nullfor Yahoo/iCloud, set for Gmail toGoogle's 2-Step Verification article (e.g.
https://support.google.com/accounts/answer/185839—reconfirm the exact current URL when implementing).
OutlinedButton(or plain text link) directly under the existing "Create an apppassword" button (
AppPasswordSetupScreen.kt:147-157), shown only when the field is non-null, with anew string resource (e.g.
app_password_2fa_help) following the existingapp_password_*naming.place (
AppPasswordSetupScreen.kt:80,150-152) instead of duplicating it.Acceptance criteria
link to Google's official setup instructions (not just the app-passwords page, which will reject
them).
snackbar, not a crash).
strings.xmlfollowing the existingapp_password_*naming convention.