Autorisations dans Xamarin.Android
Vue d’ensemble
Les applications Android s’exécutent dans leur propre bac à sable et, pour des raisons de sécurité, n’ont pas accès à certaines ressources système ou matériel sur l’appareil. L’utilisateur doit accorder explicitement l’autorisation à l’application avant d’utiliser ces ressources. Par exemple, une application ne peut pas accéder au GPS sur un appareil sans autorisation explicite de l’utilisateur. Android lève un Java.Lang.SecurityException si une application tente d’accéder à une ressource protégée sans autorisation.
Les autorisations sont déclarées dans le AndroidManifest.xml par le développeur de l’application lors du développement de l’application. Android a deux workflows différents pour obtenir le consentement de l’utilisateur pour ces autorisations :
- Pour les applications qui ciblaient Android 5.1 (niveau d’API 22) ou une version antérieure, la demande d’autorisation s’est produite lors de l’installation de l’application. Si l’utilisateur n’a pas accordé les autorisations, l’application n’est pas installée. Une fois l’application installée, il n’existe aucun moyen de révoquer les autorisations, sauf en désinstallant l’application.
- À compter d’Android 6.0 (niveau d’API 23), les utilisateurs ont eu davantage de contrôle sur les autorisations ; ils peuvent accorder ou révoquer des autorisations tant que l’application est installée sur l’appareil. Cette capture d’écran montre les paramètres d’autorisation de l’application Contacts Google. Il répertorie les différentes autorisations et permet à l’utilisateur d’activer ou de désactiver les autorisations :
Les applications Android doivent case activée au moment de l’exécution pour voir si elles sont autorisées à accéder à une ressource protégée. Si l’application n’a pas d’autorisation, elle doit effectuer des demandes à l’aide des nouvelles API fournies par le Kit de développement logiciel (SDK) Android pour que l’utilisateur accorde les autorisations. Les autorisations sont divisées en deux catégories :
- Autorisations normales : il s’agit d’autorisations qui posent peu de risque de sécurité pour la sécurité ou la confidentialité de l’utilisateur. Android 6.0 accorde automatiquement des autorisations normales au moment de l’installation. Consultez la documentation Android pour obtenir la liste complète des autorisations normales.
- Autorisations dangereuses : contrairement aux autorisations normales, les autorisations dangereuses sont celles qui protègent la sécurité ou la confidentialité de l’utilisateur. Ceux-ci doivent être explicitement accordés par l’utilisateur. L’envoi ou la réception d’un sms est un exemple d’action nécessitant une autorisation dangereuse.
Important
La catégorie à laquelle appartient une autorisation peut changer au fil du temps. Il est possible qu’une autorisation qui a été classée comme une autorisation « normale » soit élevée dans les futurs niveaux d’API à une autorisation dangereuse.
Les autorisations dangereuses sont également subdivisée en groupes d’autorisations. Un groupe d’autorisations contiendra des autorisations qui sont liées logiquement. Lorsque l’utilisateur accorde l’autorisation à un membre d’un groupe d’autorisations, Android accorde automatiquement l’autorisation à tous les membres de ce groupe. Par exemple, le groupe d’autorisations STORAGE détient à la fois les WRITE_EXTERNAL_STORAGE autorisations et .READ_EXTERNAL_STORAGE Si l’utilisateur accorde l’autorisation à READ_EXTERNAL_STORAGE, l’autorisation WRITE_EXTERNAL_STORAGE est automatiquement accordée en même temps.
Avant de demander une ou plusieurs autorisations, il est recommandé de fournir une justification quant à la raison pour laquelle l’application a besoin de l’autorisation avant de demander l’autorisation. Une fois que l’utilisateur comprend la logique, l’application peut demander l’autorisation de l’utilisateur. En comprenant la raison d’être, l’utilisateur peut prendre une décision éclairée s’il souhaite accorder l’autorisation et comprendre les répercussions si ce n’est pas le cas.
L’ensemble du flux de travail de vérification et de demande d’autorisations est appelé case activée d’autorisations d’exécution et peut être résumé dans le diagramme suivant :
La bibliothèque de support Android rétroporte certaines des nouvelles API pour obtenir des autorisations sur les anciennes versions d’Android. Ces API rétroportées case activée automatiquement la version d’Android sur l’appareil, il n’est donc pas nécessaire d’effectuer un niveau d’API case activée chaque fois.
Ce document explique comment ajouter des autorisations à une application Xamarin.Android et comment les applications qui ciblent Android 6.0 (niveau d’API 23) ou ultérieur doivent effectuer une case activée d’autorisation d’exécution.
Notes
Il est possible que les autorisations pour le matériel affectent la façon dont l’application est filtrée par Google Play. Par exemple, si l’application nécessite une autorisation pour l’appareil photo, Google Play n’affiche pas l’application dans le Google Play Store sur un appareil sur lequel aucune caméra n’est installée.
Spécifications
Il est vivement recommandé que les projets Xamarin.Android incluent le package NuGet Xamarin.Android.Support.Compat . Ce package rétroporte les API spécifiques aux autorisations vers les versions antérieures d’Android, en fournissant une interface commune sans avoir à case activée constamment la version d’Android sur laquelle l’application s’exécute.
Demande d’autorisations système
La première étape de l’utilisation des autorisations Android consiste à déclarer les autorisations dans le fichier manifeste Android. Cette opération doit être effectuée quel que soit le niveau d’API ciblé par l’application.
Les applications qui ciblent Android 6.0 ou version ultérieure ne peuvent pas supposer que, étant donné que l’utilisateur a accordé l’autorisation à un moment donné dans le passé, l’autorisation sera valide la prochaine fois. Une application qui cible Android 6.0 doit toujours effectuer une autorisation d’exécution case activée. Les applications qui ciblent Android 5.1 ou version antérieure n’ont pas besoin d’effectuer une autorisation d’exécution case activée.
Notes
Les applications doivent uniquement demander les autorisations dont elles ont besoin.
Déclaration d’autorisations dans le manifeste
Les autorisations sont ajoutées au AndroidManifest.xml avec l’élément uses-permission . Par exemple, si une application doit localiser la position de l’appareil, elle nécessite des autorisations d’emplacement précises et de cours. Les deux éléments suivants sont ajoutés au manifeste :
<uses-permission android:name="android.permission.ACCESS_COARSE_LOCATION" />
<uses-permission android:name="android.permission.ACCESS_FINE_LOCATION" />
Il est possible de déclarer les autorisations à l’aide de la prise en charge de l’outil intégrée à Visual Studio :
Double-cliquez sur Propriétés dans le Explorateur de solutions et sélectionnez l’onglet Manifeste Android dans le Fenêtre Propriétés :
Si l’application n’a pas encore de AndroidManifest.xml, cliquez sur Aucun AndroidManifest.xml trouvé. Cliquez pour en ajouter un comme indiqué ci-dessous :
Sélectionnez les autorisations dont votre application a besoin dans la liste Autorisations requises et enregistrez :
Xamarin.Android ajoute automatiquement des autorisations au moment de la génération aux builds Debug. Cela facilite le débogage de l’application. En particulier, deux autorisations notables sont INTERNET et READ_EXTERNAL_STORAGE. Ces autorisations définies automatiquement ne semblent pas être activées dans la liste Autorisations requises . Toutefois, les builds de mise en production utilisent uniquement les autorisations qui sont explicitement définies dans la liste Autorisations requises .
Pour les applications qui ciblent Android 5.1 (niveau d’API 22) ou inférieur, il n’y a rien de plus à faire. Les applications qui s’exécuteront sur Android 6.0 (API 23 niveau 23) ou version ultérieure doivent passer à la section suivante sur la façon d’effectuer des vérifications d’autorisation au moment de l’exécution.
Vérifications des autorisations d’exécution dans Android 6.0
La ContextCompat.CheckSelfPermission méthode (disponible avec la bibliothèque de support Android) est utilisée pour case activée si une autorisation spécifique a été accordée. Cette méthode retourne une Android.Content.PM.Permission énumération qui a l’une des deux valeurs suivantes :
Permission.Granted: l’autorisation spécifiée a été accordée.Permission.Denied: l’autorisation spécifiée n’a pas été accordée.
Cet extrait de code est un exemple de case activée pour l’autorisation Caméra dans une activité :
if (ContextCompat.CheckSelfPermission(this, Manifest.Permission.Camera) == (int)Permission.Granted)
{
// We have permission, go ahead and use the camera.
}
else
{
// Camera permission is not granted. If necessary display rationale & request.
}
Il est recommandé d’informer l’utilisateur de la raison pour laquelle une autorisation est nécessaire pour une application afin qu’une décision éclairée puisse être prise d’accorder l’autorisation. Par exemple, une application qui prend des photos et les géo-étiquettes. Il est clair pour l’utilisateur que l’autorisation de caméra est nécessaire, mais il peut ne pas être clair pourquoi l’application a également besoin de l’emplacement de l’appareil. La justification doit afficher un message pour aider l’utilisateur à comprendre pourquoi l’autorisation d’emplacement est souhaitable et que l’autorisation caméra est requise.
La ActivityCompat.ShouldShowRequestPermissionRationale méthode est utilisée pour déterminer si la justification doit être présentée à l’utilisateur. Cette méthode retourne true si la justification d’une autorisation donnée doit être affichée. Cette capture d’écran montre un exemple de Snackbar affiché par une application qui explique pourquoi l’application doit connaître l’emplacement de l’appareil :
Si l’utilisateur accorde l’autorisation, la ActivityCompat.RequestPermissions(Activity activity, string[] permissions, int requestCode) méthode doit être appelée. Cette méthode nécessite les paramètres suivants :
- activity : il s’agit de l’activité qui demande les autorisations et qui doit être informée par Android des résultats.
- permissions : liste des autorisations demandées.
- requestCode : valeur entière utilisée pour faire correspondre les résultats de la demande d’autorisation à un
RequestPermissionsappel. Cette valeur doit être supérieure à zéro.
Cet extrait de code est un exemple des deux méthodes qui ont été abordées. Tout d’abord, une case activée est effectuée pour déterminer si la justification de l’autorisation doit être affichée. Si la justification doit être affichée, un snackbar est affiché avec la justification. Si l’utilisateur clique sur OK dans la barre de collation, l’application demande les autorisations. Si l’utilisateur n’accepte pas la justification, l’application ne doit pas continuer à demander des autorisations. Si la justification n’est pas affichée, l’activité demande l’autorisation :
if (ActivityCompat.ShouldShowRequestPermissionRationale(this, Manifest.Permission.AccessFineLocation))
{
// Provide an additional rationale to the user if the permission was not granted
// and the user would benefit from additional context for the use of the permission.
// For example if the user has previously denied the permission.
Log.Info(TAG, "Displaying camera permission rationale to provide additional context.");
var requiredPermissions = new String[] { Manifest.Permission.AccessFineLocation };
Snackbar.Make(layout,
Resource.String.permission_location_rationale,
Snackbar.LengthIndefinite)
.SetAction(Resource.String.ok,
new Action<View>(delegate(View obj) {
ActivityCompat.RequestPermissions(this, requiredPermissions, REQUEST_LOCATION);
}
)
).Show();
}
else
{
ActivityCompat.RequestPermissions(this, new String[] { Manifest.Permission.Camera }, REQUEST_LOCATION);
}
RequestPermission peut être appelé même si l’utilisateur a déjà accordé l’autorisation. Les appels suivants ne sont pas nécessaires, mais ils permettent à l’utilisateur de confirmer (ou de révoquer) l’autorisation. Quand RequestPermission est appelé, le contrôle est remis au système d’exploitation, qui affiche une interface utilisateur pour accepter les autorisations :
Une fois l’utilisateur terminé, Android retourne les résultats à l’activité via une méthode de rappel, OnRequestPermissionResult. Cette méthode fait partie de l’interface ActivityCompat.IOnRequestPermissionsResultCallback qui doit être implémentée par l’activité. Cette interface a une méthode unique, OnRequestPermissionsResult, qui sera appelée par Android pour informer l’activité des choix de l’utilisateur. Si l’utilisateur a accordé l’autorisation, l’application peut continuer et utiliser la ressource protégée. Voici un exemple d’implémentation OnRequestPermissionResult :
public override void OnRequestPermissionsResult(int requestCode, string[] permissions, Permission[] grantResults)
{
if (requestCode == REQUEST_LOCATION)
{
// Received permission result for camera permission.
Log.Info(TAG, "Received response for Location permission request.");
// Check if the only required permission has been granted
if ((grantResults.Length == 1) && (grantResults[0] == Permission.Granted)) {
// Location permission has been granted, okay to retrieve the location of the device.
Log.Info(TAG, "Location permission has now been granted.");
Snackbar.Make(layout, Resource.String.permission_available_camera, Snackbar.LengthShort).Show();
}
else
{
Log.Info(TAG, "Location permission was NOT granted.");
Snackbar.Make(layout, Resource.String.permissions_not_granted, Snackbar.LengthShort).Show();
}
}
else
{
base.OnRequestPermissionsResult(requestCode, permissions, grantResults);
}
}
Résumé
Ce guide explique comment ajouter et case activée pour les autorisations dans un appareil Android. Différences dans le fonctionnement des autorisations entre les anciennes applications Android (niveau < API 23) et les nouvelles applications Android (niveau > API 22). Il a expliqué comment effectuer des vérifications d’autorisation d’exécution dans Android 6.0.