Share
Avant la publication de M, le modèle d'autorisations Android était une décision du tout ou rien pour les utilisateurs au moment de l'installation. Cela signifiait que si un utilisateur souhaitait utiliser une application, il devait d'abord accepter toutes les autorisations incluses dans l'application ou choisir de ne pas l'installer du tout. Cela a conduit de nombreux développeurs à perdre leurs installations d'applications, une déconnexion de confiance entre les utilisateurs et les développeurs et d'autres problèmes de confidentialité..
Dans le nouveau modèle d'autorisations, les utilisateurs pourront approuver les autorisations au moment de l'exécution, au besoin, et les refuser à tout moment. Dans cet article, vous apprendrez comment ce changement de gestion des autorisations vous affectera en tant que développeur et comment vos utilisateurs expérimenteront vos applications..
Il convient de noter que cet article a été écrit avant la version officielle d'Android M, de sorte que certaines informations peuvent changer avec la version officielle..
Alors que Android M nécessite toujours des autorisations pour être déclaré dans AndroidManifest.xml, les utilisateurs devront maintenant approuver ou refuser l'utilisation de cette autorisation au moment de l'exécution. Un changement important dans la nouvelle version d'Android est que android.permission.INTERNET et android.permission.WRITE_EXTERNAL_STORAGE ont été déclassés à partir d'une note de dangereux à Ordinaire. Cela signifie que vous n'avez pas besoin d'inviter l'utilisateur avant utilisation.
Lors de la demande d'approbation d'autorisation, l'utilisateur sera invité en fonction du groupe d'autorisations, plutôt que d'être invité à approuver toutes les autorisations au sein d'un groupe. Cela signifie que si votre application a besoin d'envoyer et de recevoir des SMS, votre utilisateur sera uniquement invité à approuver le groupe d'autorisations SMS. Vous trouverez ci-dessous une liste des groupes d'autorisations actuellement pris en charge dans Android M Developer Preview 2, comme indiqué dans les paramètres système..
Il convient également de noter qu'Android dispose d'un robuste Intention système, qui permet aux développeurs de demander des données à d’autres applications. Plutôt que de demander l'autorisation de la caméra et de développer une application utilisant les API de caméra à partir de zéro, vous pouvez demander à l'utilisateur de prendre une photo à l'aide d'une application de caméra déjà approuvée afin de pouvoir insérer une image dans votre application. Les autorisations impliquant la caméra seront gérées par l'application de la caméra.
Lorsque vous devez utiliser une fonctionnalité nécessitant une autorisation, un flux général d'événements se produira. Vous devez d’abord vérifier si cette autorisation a déjà été approuvée par votre utilisateur..
Si l'utilisateur n'a pas approuvé l'autorisation, vous pouvez lui présenter une boîte de dialogue de demande d'autorisation. La première fois que vous présenterez ceci à l'utilisateur, il devra refuser ou approuver l'autorisation..
Toutefois, s’ils ont déjà refusé l’autorisation et qu’on leur demande de nouveau, ils auront l’option de ne plus jamais demander cette autorisation..
Vous pouvez vérifier si une autorisation a déjà été accordée en appelant checkSelfPermission avant d'utiliser une fonctionnalité qui nécessitera cette autorisation. Cette méthode retourne un int valeur basée sur si l'autorisation est accordée ou non.
Si c'est égal à PackageManager.PERMISSION_GRANTED, alors vous pouvez continuer comme prévu. Cependant, si cette permission n’a pas encore été accordée, vous pouvez la demander avec demandePermissions, passer dans un tableau de chaînes de permission et une coutume int code de demande pour suivre le flux logique de votre application.
int hasLocationPermission = checkSelfPermission (Manifest.permission.ACCESS_FINE_LOCATION); int hasSMSPermission = checkSelfPermission (Manifest.permission.SEND_SMS); listepermissions = new ArrayList (); if (hasLocationPermission! = PackageManager.PERMISSION_GRANTED) permissions.add (Manifest.permission.ACCESS_FINE_LOCATION); if (hasSMSPermission! = PackageManager.PERMISSION_GRANTED) permissions.add (Manifest.permission.SEND_SMS); if (! permissions.isEmpty ()) requestPermissions (permissions.toArray (nouvelle chaîne [permissions.size ()]), REQUEST_CODE_SOME_FEATURES_PERMISSIONS);
Une fois que demandePermissions est appelé, une boîte de dialogue de demande s'affiche pour chaque groupe d'autorisations pour lesquelles votre application demande une autorisation. Il est recommandé de ne demander que les autorisations nécessaires, plutôt que de manière groupée lorsque votre utilisateur lance l’application pour la première fois..
Quand votre utilisateur a fini avec les dialogues, onRequestPermissionsResult est appelé et peut être consulté dans votre Activité. C’est là que vous démarrez votre fonctionnalité ou que vous gérez le cas où votre utilisateur a refusé une ou plusieurs autorisations..
Un exemple de vérification d'une autorisation accordée ou refusée est présenté ci-dessous. Si l'utilisateur a refusé les autorisations requises pour votre fonctionnalité, vous devez désactiver cette fonctionnalité et lui indiquer pourquoi elle ne fonctionne pas dans votre application..
@Override public void onRequestPermissionsResult (int requestCode, permissions String [], int [] grantResults) switch (requestCode) case REQUEST_CODE_SOME_FEATURES_PERMISSIONS: pour (int i = 0; i < permissions.length; i++ ) if( grantResults[i] == PackageManager.PERMISSION_GRANTED ) Log.d( "Permissions", "Permission Granted: " + permissions[i] ); else if( grantResults[i] == PackageManager.PERMISSION_DENIED ) Log.d( "Permissions", "Permission Denied: " + permissions[i] ); break; default: super.onRequestPermissionsResult(requestCode, permissions, grantResults);
Alors que les applications conçues pour Android M doivent implémenter les nouvelles boîtes de dialogue et méthodes d'autorisation, les applications créées pour les versions précédentes d'Android présentent toujours aux utilisateurs une liste des autorisations au moment de l'installation. Bien que les autorisations soient acceptées avant que les utilisateurs puissent utiliser votre application, elles peuvent toujours être révoquées à tout moment..
Dans la mesure où l'infrastructure de gestion des autorisations révoquées ne sera pas disponible dans les applications ciblant moins d'Android M, toutes les fonctionnalités nécessitant des autorisations requises seront renvoyées. nul, 0, ou une valeur vide lorsque les autorisations ne sont pas accordées. Cela peut entraîner un comportement inattendu dans les applications. Il est donc recommandé aux développeurs de se préparer à mettre à niveau leurs applications afin de prendre en charge le nouveau modèle d'autorisation Android M dès que possible..
Dans cet article, vous avez appris à connaître le nouveau modèle d'autorisation Android M et à prendre en charge les autorisations mises à jour dans vos applications. Nous avons également expliqué comment les applications réagiront à la nouvelle version d'Android lorsqu'elles auront été créées pour les versions précédentes. Grâce à ces informations, vous devriez pouvoir préparer vos applications pour la publication officielle de la prochaine mise à jour pour Android..
Accentsconagua