QML Application Permissions

當今設備和 OS (操作係統) 的許多特徵可能對隱私、安全性、及性能有顯著影響，若濫用。因此，要求用戶明確同意的平颱越來越普遍，在訪問這些特徵之前。

The Qt QML 核心 module exposes the Qt C++ 應用程序權限 functionality to QML via a set of permission types that can be used to check or request permission in a cross platform manner.

BluetoothPermission	Access to the user's Bluetooth peripherals
CalendarPermission	Access to the user's calendar
CameraPermission	訪問用戶攝像機
ContactsPermission	Access to the user's contacts
LocationPermission	Access to the user's location
MicrophonePermission	Access to the user's microphone

注意： The available permission types cover core functionality of Qt modules like Qt Multimedia and Qt Positioning, but do not encompass all platform-specific permissions. Custom permission types are not currently supported.

用法

To check and request a specific permission in your application, include an instance of the appropriate permission type, and set any of its properties if needed:

CalendarPermission {
    id: calendarPermission
    accessMode: CalendarPermission.ReadWrite
}

The type can be used to check the current state of the permissions, for example to drive a state based UI:

states: [
    State {
        name: "waitingForPermission"
        when: calendarPermission.status == Qt.PermissionStatus.Undetermined
        PropertyChanges { target: permissionRequestItem; visible: true }
    },
    State {
        name: "permissionDenied"
        when: calendarPermission.status == Qt.PermissionStatus.Denied
        PropertyChanges { target: permissionDeniedItem; visible: true }
    }
]

In the example above, two permission specific items will be overlaid if the permission status is not granted. The request UI could perhaps look like:

Rectangle {
    id: permissionRequestItem
    anchors.fill: parent
    visible: false
    Text {
        anchors.centerIn: parent
        text: qsTr("We need your permission to access the calendar."
            + "Please tap this screen to request permission.")
    }
    MouseArea {
        anchors.fill: parent
        onClicked: calendarPermission.request()
    }
}

With a corresponding denied UI:

Rectangle {
    id: permissionDeniedItem
    anchors.fill: parent
    color: "red"
    visible: false
    Text {
        anchors.centerIn: parent
        text: qsTr("We need your permission to access the calendar,"
            + "but permission was not granted. Please resolve.")
    }
}

Changing permission properties

The properties of a permission can be changed, even after a request has been initiated by calling `request()`. This will update the status, if it changes a result of the new property values, but will not result in an automatic request using the new set of properties.

For example, if upgrading an already granted calendar permission for access mode Qt.CalendarPermission.ReadOnly to Qt.CalendarPermission.ReadWrite , the platform will respond in one of three ways:

By implicitly granting the extended permission, for example because the platform doesn't distinguish between the two access modes, which will result in no state change.
By moving the status back to Undetermined, so that the user can be consulted again for access to the now extended permission.
By moving the status to Denied , for example if permissions can not be upgraded once initially requested.

All these states should then move the application's UI into the appropriate state, where the user is informed of the new state, with the possibility of requesting the new permission if possible, or reverting to a less extensive permission.

Interaction between permission items

Although the permission state is ultimately tied to the underlying application, each permission item reports its own status independently of all other items, and needs to be independently requested if needed.

For example, requesting calendar access for one item will not update the status of another CalendarPermission item, even if these have the exact same properties.