Permissions d'application

De nombreuses fonctionnalités des appareils et des systèmes d'exploitation actuels peuvent avoir des conséquences importantes sur la vie privée, la sécurité et les performances en cas d'utilisation abusive. C'est pourquoi il est de plus en plus fréquent que les plateformes demandent le consentement explicite de l'utilisateur avant d'accéder à ces fonctionnalités.

Les API de permission de Qt permettent à l'application de vérifier ou de demander la permission pour de telles fonctionnalités d'une manière multiplateforme.

Utilisation

L'accès au microphone de l'appareil est une fonction qui nécessite généralement le consentement de l'utilisateur. Une application permettant d'enregistrer des mémos vocaux pourrait ressembler à ce qui suit :

void VoiceMemoWidget::onRecordingInitiated()
{
    m_microphone->startRecording();
}

Pour que cette application fonctionne bien sur les plateformes qui exigent le consentement de l'utilisateur pour l'accès au microphone, nous l'étendrions comme suit :

void VoiceMemoWidget::onRecordingInitiated() { QMicrophonePermission microphonePermission ; switch (qApp->checkPermission(microphonePermission)) { case Qt::PermissionStatus::Undetermined :        qApp->requestPermission(microphonePermission, this,
                   &VoiceMemoWidget::onRecordingInitiated) ; return; case Qt::PermissionStatus::Denied :  m_permissionInstructionsDialog->show() ; return; case Qt::PermissionStatus::Granted :  m_microphone->startRecording() ; } }

Nous commençons par vérifier si nous connaissons déjà l'état de la permission du microphone. Si ce n'est pas le cas, nous lançons une demande de permission pour déterminer l'état actuel, qui demandera éventuellement l'accord de l'utilisateur. Nous connectons le résultat de la demande au slot dans lequel nous nous trouvons déjà, afin d'avoir une autre chance d'évaluer l'état de la permission.

Une fois que l'état de la permission est connu, soit parce que la permission nous a été accordée ou refusée à un moment antérieur, soit après avoir reçu le résultat de la demande que nous venons de lancer, nous redirigeons l'utilisateur vers une boîte de dialogue expliquant pourquoi nous ne pouvons pas enregistrer de mémos vocaux pour le moment (si la permission a été refusée), ou nous procédons à l'utilisation du microphone (si la permission a été accordée).

Déclarer des autorisations

Certaines plateformes exigent que les permissions demandées soient déclarées au moment de la construction.

Plateformes Apple

Chaque permission demandée doit être accompagnée d'une chaîne de description d'utilisation dans le fichier Info.plist de l'application, décrivant pourquoi l'application a besoin d'accéder à la permission donnée. Par exemple :

<key>NSMicrophoneUsageDescription</key>
<string>The microphone is used to record voice memos.</string>

Les clés de description d'utilisation pertinentes sont décrites dans la documentation de chaque type d'autorisation.

Pour vous assurer que le backend de permission approprié est inclus dans votre application, veuillez indiquer au système de construction votre Info.plist personnalisé.

Android

Chaque permission demandée doit être accompagnée d'une entrée uses-permission dans le fichier AndroidManifest.xml de l'application. Par exemple :

<manifest ...>
    <uses-permission android:name="android.permission.RECORD_AUDIO"/>
</manifest>

Pour vous assurer que le backend de permission approprié est inclus dans votre application, veuillez indiquer au système de construction votre AndroidManifest.xml personnalisé ou utilisez qt_add_android_permission().

Les noms des permissions sont décrits dans la documentation de chaque type de permission.

Permissions disponibles

Les types de permissions suivants sont disponibles :

Meilleures pratiques

Pour garantir la meilleure expérience possible à l'utilisateur final, nous recommandons d'adopter les meilleures pratiques suivantes pour la gestion des autorisations d'application :

• Demander le minimum d'autorisations nécessaires. Par exemple, si vous n'avez besoin que de l'accès au microphone, ne demandez pas l'autorisation d'utiliser la caméra au cas où. Utilisez les propriétés des différents types d'autorisation pour limiter encore davantage la portée de l'autorisation, par exemple QContactsPermission::setAccessMode() pour demander un accès en lecture seule.
• Demander des autorisations en réponse à des actions spécifiques de l'utilisateur. Par exemple, reporter la demande d'autorisation pour le microphone jusqu'à ce que l'utilisateur appuie sur le bouton pour enregistrer de l'audio. Le fait d'associer la demande d'autorisation à une action spécifique permet à l'utilisateur de mieux comprendre pourquoi l'autorisation est nécessaire. Ne demandez pas toutes les autorisations nécessaires au démarrage.
• Présentez un contexte et des explications supplémentaires si nécessaire. Parfois, l'action de l'utilisateur n'est pas un contexte suffisant. Envisagez de présenter une boîte de dialogue d'explication après que l'utilisateur a initié l'action, mais avant de demander l'autorisation, afin que l'utilisateur sache ce qui va se passer lorsque la boîte de dialogue d'autorisation du système apparaîtra par la suite.
• Soyez transparent et explicite sur les raisons pour lesquelles des autorisations sont nécessaires. Dans les boîtes de dialogue d'explication et les descriptions d'utilisation, expliquez en toute transparence pourquoi une permission particulière est nécessaire pour que votre application fournisse une fonctionnalité spécifique, afin que les utilisateurs puissent prendre des décisions en connaissance de cause.
• Tenez compte des autorisations refusées. Les autorisations que vous demandez peuvent être refusées pour diverses raisons. Vous devez toujours tenir compte de cette situation, en dégradant gracieusement l'expérience de votre application et en présentant des explications claires à l'utilisateur sur la situation.
• Ne demandez jamais de permissions à une bibliothèque. La demande de permissions doit être faite le plus près possible de l'utilisateur, là où les informations nécessaires pour prendre de bonnes décisions sur les points ci-dessus sont disponibles. Les bibliothèques peuvent vérifier les permissions, afin de s'assurer qu'elles disposent des conditions préalables pour effectuer leur travail, mais si la permission est indéterminée ou refusée, cela doit être reflété par l'API de la bibliothèque, afin que l'application puisse à son tour demander les permissions nécessaires.