Details
-
Epic
-
Resolution: Unresolved
-
P1: Critical
-
None
-
Re-opening as this needs further work to make public API, including the macOS/iOS backends.
-
App Permissions API in Qt 6
-
-
2021wk08PO2, 2021wk10PO2, 2021wk12PO3, 2021wk14PO2, 2021wk16PO2, 2021wk18PO2
Description
Many features of today's devices and operating systems can have significant privacy, security, and performance implications, if misused. As a result, it's increasingly common for platforms to require explicit consent from the user before accessing these features. In Qt 6.5 we establish generic, plug-in based framework and add an initial set of API and platform support.
Below is a scratch-pad content from WIP items still needing investigation:
How to model read-only and other common variants of permissions- QPermissions::PermissionModifier enum and dedicated PermissionRequest type allowing e.g. requestPermission(Calendar | ReadOnly)
How to model more complex permissions such as location accuracy- Via QPermissions::LocationPermission subclass with dedicated setters for accuracy and availability
What to name the permission results (Denied/Rejected/etc, Accepted/Authorized/Granted, etc)- Renamed Authorized -> Granted, based on:
- Apple: Authorized/Denied/NotDetermined (but some callbacks take a "granted" bool parameter)
- Android: Granted/Denied
- Web: Granted/Denied/Prompt
- Windows: Allowed/Denied/UserPrompt
- Renamed Authorized -> Granted, based on:
- Whether to allow calling checkPermission from secondary threads (requestPermission is main thread only)
Whether to adopt a combination of the defaults discussed in an earlier comment, where QT_CONFIG is combined with Undetermined- Adopted QT_CONFIG based approach as discussed in comment-662003
Whether the API belongs in QGuiApplication since it potentially depends on user interaction to request permissions.- Permissions can be requested for QCoreApplication cases as well, at least on some platforms (macOS), for example for recording audio, or reading contacts. The permission UI is presented by the system, so it doesn't matter that the app itself is running headless.
Determine whether Restricted is needed- Will remove. There is very little use-case for distinguishing between being denied a permission because the user clicked "deny" in a dialog or because the user enabled restrictions on that permission globally. This approach is also what Chromium seems to do: https://chromium.googlesource.com/chromium/src/+/refs/heads/main/device/bluetooth/bluetooth_adapter_mac.mm#228
- Determine whether libraries should request permissions on behalf of users, or limit to checkPermission
Whether the API should go into QCoreApplication or the QPermissions namespace- Decided on QCoreApplication, as that leaves us a place to have possible signals in the future
Whether we need a static API or not- No need for static API, as requiring a QCA instance is fine, and aligns with the best-practice of requesting permissions late (when needed), instead of first thing in main()
- Additional permissions
- BodySensors
- PhysicalActivity
- Storage
- Notifications
- ScreenCapture
- Reminders
- Photos
And items still yet to do:
- Document platform specifics, e.g. Apple Info.plist
- Document best practices for permissions
- Move QtMultimedia off of manually managing permissions (QAVFCamera/AVFCameraSession, androidRequestPermission)
Attachments
Issue Links
- is required for
-
QTBUG-84382 QtAndroidExtras in Qt 6
- Closed
- resulted in
-
QTBUG-93626 Add permission API implementation for iOS and macOS
- Closed
- links to
- mentioned in
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...