The contacts permission is currently requested with a raw system dialog and no rationale — ComposeScreen.kt calls permissionLauncher.launch(READ_CONTACTS) directly with no explanation of why the app wants contacts, and no shouldShowRequestPermissionRationale handling.
Proposal
Show a short in-app rationale before/with the request explaining that contacts are used only for on-device recipient autocomplete (no upload), and handle shouldShowRequestPermissionRationale so a re-request explains itself. This lives wherever the request ends up (see the move-to-onboarding ticket — the onboarding step is the natural home).
Why
Play guidance and the project's own permissions doc (docs/play-permissions.md, from #17) expect an in-context rationale for READ_CONTACTS.
Improves grant rate and user trust; contacts is a sensitive permission requested by an email client.
Related: the move-to-onboarding ticket (rationale should be part of that step) and the re-enable-after-decline ticket.
The contacts permission is currently requested with a **raw system dialog and no rationale** — `ComposeScreen.kt` calls `permissionLauncher.launch(READ_CONTACTS)` directly with no explanation of *why* the app wants contacts, and no `shouldShowRequestPermissionRationale` handling.
## Proposal
Show a short in-app rationale before/with the request explaining that contacts are used **only** for on-device recipient autocomplete (no upload), and handle `shouldShowRequestPermissionRationale` so a re-request explains itself. This lives wherever the request ends up (see the move-to-onboarding ticket — the onboarding step is the natural home).
## Why
- Play guidance and the project's own permissions doc (`docs/play-permissions.md`, from #17) expect an in-context rationale for `READ_CONTACTS`.
- Improves grant rate and user trust; contacts is a sensitive permission requested by an email client.
Related: the move-to-onboarding ticket (rationale should be part of that step) and the re-enable-after-decline ticket.
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.
The contacts permission is currently requested with a raw system dialog and no rationale —
ComposeScreen.ktcallspermissionLauncher.launch(READ_CONTACTS)directly with no explanation of why the app wants contacts, and noshouldShowRequestPermissionRationalehandling.Proposal
Show a short in-app rationale before/with the request explaining that contacts are used only for on-device recipient autocomplete (no upload), and handle
shouldShowRequestPermissionRationaleso a re-request explains itself. This lives wherever the request ends up (see the move-to-onboarding ticket — the onboarding step is the natural home).Why
docs/play-permissions.md, from #17) expect an in-context rationale forREAD_CONTACTS.Related: the move-to-onboarding ticket (rationale should be part of that step) and the re-enable-after-decline ticket.