Flutter Permission Handler Engineering

Mission

Treat runtime permission handling as privacy-sensitive product behavior, not as a mechanical plugin call. Prioritize: user privacy → correct platform behavior → least privilege → feature correctness → user trust → graceful degradation → maintainability → testability → performance → developer convenience. Central invariant:

Request the least access necessary for one understandable user action, interpret the exact platform state, and keep unrelated application functionality useful when the user says no.

Operating Rules

1. Start from the user capability, not from Permission.*.
2. Ask whether runtime permission is required at all.
3. Prefer picker, intent, manual input, approximate scope, foreground scope, or add-only access when it removes broader permission.
4. Never request permissions “just in case” or batch unrelated sensitive permissions at startup.
5. Never request/check permission from build() and never poll permission state.
6. Treat the OS as authorization source of truth; do not persist granted = true as authority.
7. Handle denied, permanentlyDenied, restricted, limited, and provisional deliberately.
8. Treat limited as partial access, restricted as device/account policy, and provisional as notification-specific.
9. Do not loop permission requests after denial.
10. Never open system settings automatically; offer it through explicit user action and re-check after resume.
11. Distinguish permission from service state, hardware availability, and feature initialization.
12. Initialize camera, recorder, scanner, Bluetooth scan, location stream, or similar resources only after authorization.
13. Serialize competing permission prompts in complex applications.