Cette page a été traduite par l'API Cloud Translation.

Demander des autorisations d'exécution

Chaque application Android s'exécute dans un bac à sable en accès limité. Si votre application doit utiliser des ressources ou des informations en dehors de son propre bac à sable, vous pouvez déclarer une autorisation d'exécution et configurer une demande d'autorisation pour fournir cet accès. Ces étapes font partie du workflow d'utilisation des autorisations.

Si vous déclarez des autorisations dangereuses et que votre application est installée sur un appareil exécutant Android 6.0 (niveau 23 d'API) ou une version ultérieure, vous devez demander ces autorisations lors de l'exécution en suivant les étapes de ce guide.

Si vous ne déclarez aucune autorisation dangereuse ou si votre application est installée sur un appareil exécutant Android version 5.1 (niveau 22 d'API) ou antérieure, les autorisations sont automatiquement accordées. Il est donc inutile de poursuivre la procédure décrite sur cette page.

Principes de base

Les principes de base pour demander des autorisations lors de l'exécution sont :

Demandez une autorisation en contexte, lorsque l'utilisateur commence à interagir avec la fonctionnalité qui l'exige.
Ne bloquez pas l'utilisateur. Proposez toujours la possibilité d'annuler un flux d'interface utilisateur éducatif, comme un flux expliquant le motif de la demande d'autorisations.
Si l'utilisateur refuse ou révoque une autorisation nécessaire à une fonctionnalité, effectuez une dégradation élégante de votre application afin qu'il puisse continuer à l'utiliser, en désactivant éventuellement la fonctionnalité qui requiert l'autorisation.
Ne présumez aucun comportement du système. Par exemple, supposons que les autorisations n'apparaissent pas dans le même groupe d'autorisations. Un groupe d'autorisations permet simplement au système de réduire le nombre de boîtes de dialogue système présentées à l'utilisateur lorsqu'une application demande des autorisations étroitement liées.

Workflow de demande d'autorisations

Avant d'afficher des demandes d'autorisation d'exécution dans votre application, déterminez si c'est nécessaire. Vous pouvez répondre à de nombreux cas d'utilisation dans votre application, tels que la prise de photos, la mise en pause de contenus multimédias et l'affichage de publicité pertinente, sans avoir à demander d'autorisations.

Si vous estimez que votre application doit demander des autorisations d'exécution, procédez comme suit :

Dans le fichier manifeste de votre application, affichez les autorisations potentiellement requises par votre application.
Concevez l'expérience utilisateur de votre application de sorte que des actions spécifiques soient associées à des autorisations d'exécution spécifiques. Indiquez aux utilisateurs quelles actions peuvent les obliger à autoriser l'accès aux données utilisateur privées de votre application.
Attendez que l'utilisateur appelle la tâche ou l'action dans votre application qui nécessite un accès à des données utilisateur privées spécifiques. Votre application peut alors demander l'autorisation d'exécution nécessaire pour accéder à ces données.
Vérifiez si l'utilisateur a déjà autorisé l'exécution requise par votre application. Si tel est le cas, votre application peut accéder aux données utilisateur privées. Si ce n'est pas le cas, passez à l'étape suivante.

Vérifiez que vous disposez de cette autorisation chaque fois que vous effectuez une opération qui l'exige.
Vérifiez si votre application doit donner une justification à l'utilisateur en lui expliquant pourquoi il doit accorder une autorisation d'exécution particulière. Si le système détermine que votre application ne doit pas donner de justification, passez directement à l'étape suivante sans afficher d'élément d'interface utilisateur.

En revanche, si le système détermine que votre application doit donner une justification, présentez-la à l'utilisateur dans un élément d'interface utilisateur. Cette explication doit préciser clairement les données auxquelles votre application tente d'accéder et les avantages qu'elle peut apporter à l'utilisateur s'il accorde l'autorisation d'exécution. Une fois que l'utilisateur a pris connaissance de la justification, passez à l'étape suivante.
Demandez l'autorisation d'exécution requise par votre application pour accéder aux données utilisateur privées. Le système affiche une invite d'autorisation d'exécution, comme celle proposée sur la page de présentation des autorisations.
Vérifiez, dans la réponse, si l'utilisateur a accordé ou non l'autorisation d'exécution.
Si l'utilisateur a accordé l'autorisation à votre application, vous pouvez accéder aux données utilisateur privées. S'il a refusé l'autorisation, effectuez une dégradation élégante de l'expérience de votre application afin qu'elle lui propose une fonctionnalité sans les informations protégées par cette autorisation.

L'image 1 illustre le workflow et l'ensemble de décisions associés à ce processus :

**Figure 1.** Schéma illustrant le workflow permettant d'afficher les demandes d'autorisation d'exécution sur Android.

Déterminer si l'autorisation a déjà été accordée à votre application

Pour vérifier si l'utilisateur a déjà accordé à votre application une autorisation particulière, transmettez cette autorisation à la méthode ContextCompat.checkSelfPermission(). Cette méthode renvoie PERMISSION_GRANTED ou PERMISSION_DENIED, selon que votre application dispose ou non de l'autorisation.

Expliquer pourquoi votre application requiert cette autorisation

La boîte de dialogue des autorisations affichée par le système lorsque vous appelez requestPermissions() indique l'autorisation souhaitée par votre application, mais n'en précise pas la raison. L'utilisateur peut parfois trouver cela déroutant. Nous vous recommandons d'expliquer à l'utilisateur pourquoi votre application souhaite obtenir les autorisations avant d'appeler requestPermissions().

Des études montrent que les utilisateurs se sentent plus en confiance avec les demandes d'autorisation lorsqu'ils en connaissent la raison, par exemple si l'autorisation est nécessaire pour prendre en charge une fonctionnalité essentielle de l'application ou pour la publicité. Si vous n'utilisez qu'une partie des appels d'API qui requièrent un groupe d'autorisations, il est donc recommandé de lister explicitement celles que vous utilisez et pourquoi. Par exemple, si vous n'utilisez que la localisation approximative, indiquez-le dans la description ou dans les articles d'aide de votre appli.

Parfois, il est également utile d'informer en temps réel les utilisateurs de l'accès aux données sensibles. Par exemple, si vous accédez à la caméra ou au micro, il est recommandé d'en informer l'utilisateur à l'aide d'une icône de notification dans l'application ou dans la barre de notification (si l'application s'exécute en arrière-plan) pour ne pas donner l'impression de collecter des données de façon insidieuse.

Enfin, si vous devez demander une autorisation pour faire fonctionner un élément de votre application, mais que la raison n'est pas claire pour l'utilisateur, trouvez un moyen de lui expliquer pourquoi vous avez besoin des autorisations les plus sensibles.

Si la méthode ContextCompat.checkSelfPermission() renvoie PERMISSION_DENIED, appelez shouldShowRequestPermissionRationale(). Si elle renvoie true, l'interface utilisateur éducative s'affiche. Dans cette interface utilisateur, expliquez pourquoi la fonctionnalité que l'utilisateur souhaite activer requiert une autorisation spécifique.

De plus, si votre application demande une autorisation liée à la localisation, au micro ou à la caméra, vous pouvez expliquer pourquoi votre application a besoin d'accéder à ces informations.

Demander des autorisations

Une fois qu'une interface utilisateur éducative s'affiche ou que la valeur renvoyée pour shouldShowRequestPermissionRationale() indique qu'il est inutile d'afficher une interface utilisateur éducative, demandez l'autorisation. Une boîte de dialogue d'autorisation système s'affiche, dans laquelle les utilisateurs peuvent choisir d'accorder une autorisation particulière à votre application.

Pour ce faire, utilisez le contrat RequestPermission, inclus dans une bibliothèque AndroidX, pour permettre au système de gérer le code de demande d'autorisation à votre place. Étant donné que le contrat RequestPermission simplifie votre logique, il est recommandé de l'utiliser dès que possible. Si nécessaire, vous pouvez toutefois gérer vous-même un code de requête dans la requête d'autorisation et inclure ce code dans votre logique de rappel d'autorisation.

Autoriser le système à gérer le code de demande d'autorisation

Pour permettre au système de gérer le code de demande d'autorisation, ajoutez des dépendances aux bibliothèques suivantes dans le fichier build.gradle de votre module :

androidx.activity version 1.2.0 ou ultérieure.
androidx.fragment version 1.3.0 ou ultérieure.

Vous pouvez ensuite utiliser l'une des classes suivantes :

Pour demander une seule autorisation, utilisez RequestPermission.
Pour demander plusieurs autorisations en même temps, utilisez RequestMultiplePermissions.

Pour utiliser le contrat RequestPermission, procédez comme suit ; le processus est presque identique pour le contrat RequestMultiplePermissions.

Dans la logique d'initialisation de votre activité ou fragment, soumettez une intégration d'ActivityResultCallback dans un appel à registerForActivityResult(). ActivityResultCallback définit la manière dont votre application gère la réponse de l'utilisateur à la demande d'autorisation.

Conservez une référence à la valeur de registerForActivityResult() renvoyée, qui est de type ActivityResultLauncher.
Pour afficher la boîte de dialogue d'autorisations système si nécessaire, appelez la méthode launch() sur l'instance de ActivityResultLauncher que vous avez enregistrée à l'étape précédente.

Une fois la méthode launch() appelée, la boîte de dialogue des autorisations système s'affiche. Lorsque l'utilisateur fait un choix, le système appelle de manière asynchrone votre intégration de ActivityResultCallback, que vous avez définie à l'étape précédente.

Remarque : Votre application ne peut pas personnaliser la boîte de dialogue qui s'affiche lorsque vous appelez launch(). Pour proposer plus d'informations ou de contexte à l'utilisateur, modifiez l'interface utilisateur de votre application afin que les utilisateurs comprennent plus facilement pourquoi une fonctionnalité de votre application nécessite une autorisation particulière. Par exemple, vous pouvez modifier le texte du bouton qui active la fonctionnalité.

En outre, le texte de la boîte de dialogue d'autorisation système fait référence au groupe d'autorisations associé à l'autorisation demandée. Ce regroupement d'autorisations sert à faciliter l'utilisation du système, et votre application ne doit pas dépendre d'autorisations appartenant ou non à un groupe d'autorisations spécifique.

L'extrait de code suivant illustre comment gérer la réponse liée aux autorisations :

Kotlin

// Register the permissions callback, which handles the user's response to the
// system permissions dialog. Save the return value, an instance of
// ActivityResultLauncher. You can use either a val, as shown in this snippet,
// or a lateinit var in your onAttach() or onCreate() method.
val requestPermissionLauncher =
    registerForActivityResult(RequestPermission()
    ) { isGranted: Boolean ->
        if (isGranted) {
            // Permission is granted. Continue the action or workflow in your
            // app.
        } else {
            // Explain to the user that the feature is unavailable because the
            // feature requires a permission that the user has denied. At the
            // same time, respect the user's decision. Don't link to system
            // settings in an effort to convince the user to change their
            // decision.
        }
    }

Java

// Register the permissions callback, which handles the user's response to the
// system permissions dialog. Save the return value, an instance of
// ActivityResultLauncher, as an instance variable.
private ActivityResultLauncher<String> requestPermissionLauncher =
    registerForActivityResult(new RequestPermission(), isGranted -> {
        if (isGranted) {
            // Permission is granted. Continue the action or workflow in your
            // app.
        } else {
            // Explain to the user that the feature is unavailable because the
            // feature requires a permission that the user has denied. At the
            // same time, respect the user's decision. Don't link to system
            // settings in an effort to convince the user to change their
            // decision.
        }
    });

Cet extrait de code illustre le processus recommandé pour rechercher une autorisation et la demander à l'utilisateur si nécessaire :

Kotlin

when {
    ContextCompat.checkSelfPermission(
            CONTEXT,
            Manifest.permission.REQUESTED_PERMISSION
            ) == PackageManager.PERMISSION_GRANTED -> {
        // You can use the API that requires the permission.
    }
    ActivityCompat.shouldShowRequestPermissionRationale(
            this, Manifest.permission.REQUESTED_PERMISSION) -> {
        // In an educational UI, explain to the user why your app requires this
        // permission for a specific feature to behave as expected, and what
        // features are disabled if it's declined. In this UI, include a
        // "cancel" or "no thanks" button that lets the user continue
        // using your app without granting the permission.
        showInContextUI(...)
    }
    else -> {
        // You can directly ask for the permission.
        // The registered ActivityResultCallback gets the result of this request.
        requestPermissionLauncher.launch(
                Manifest.permission.REQUESTED_PERMISSION)
    }
}

Java

if (ContextCompat.checkSelfPermission(
        CONTEXT, Manifest.permission.REQUESTED_PERMISSION) ==
        PackageManager.PERMISSION_GRANTED) {
    // You can use the API that requires the permission.
    performAction(...);
} else if (ActivityCompat.shouldShowRequestPermissionRationale(
        this, Manifest.permission.REQUESTED_PERMISSION)) {
    // In an educational UI, explain to the user why your app requires this
    // permission for a specific feature to behave as expected, and what
    // features are disabled if it's declined. In this UI, include a
    // "cancel" or "no thanks" button that lets the user continue
    // using your app without granting the permission.
    showInContextUI(...);
} else {
    // You can directly ask for the permission.
    // The registered ActivityResultCallback gets the result of this request.
    requestPermissionLauncher.launch(
            Manifest.permission.REQUESTED_PERMISSION);
}

Gérer soi-même le code de demande d'autorisation

Au lieu d'autoriser le système à gérer le code de demande d'autorisation, vous pouvez gérer ce code vous-même. Pour ce faire, incluez le code de demande dans un appel à requestPermissions().

L'extrait de code suivant illustre la méthode pour demander une autorisation à l'aide d'un code de demande :

Kotlin

when {
    ContextCompat.checkSelfPermission(
            CONTEXT,
            Manifest.permission.REQUESTED_PERMISSION
            ) == PackageManager.PERMISSION_GRANTED -> {
        // You can use the API that requires the permission.
        performAction(...)
    }
    ActivityCompat.shouldShowRequestPermissionRationale(
            this, Manifest.permission.REQUESTED_PERMISSION) -> {
        // In an educational UI, explain to the user why your app requires this
        // permission for a specific feature to behave as expected, and what
        // features are disabled if it's declined. In this UI, include a
        // "cancel" or "no thanks" button that lets the user continue
        // using your app without granting the permission.
        showInContextUI(...)
    }
    else -> {
        // You can directly ask for the permission.
        requestPermissions(CONTEXT,
                arrayOf(Manifest.permission.REQUESTED_PERMISSION),
                REQUEST_CODE)
    }
}

Java

if (ContextCompat.checkSelfPermission(
        CONTEXT, Manifest.permission.REQUESTED_PERMISSION) ==
        PackageManager.PERMISSION_GRANTED) {
    // You can use the API that requires the permission.
    performAction(...);
} else if (ActivityCompat.shouldShowRequestPermissionRationale(
        this, Manifest.permission.REQUESTED_PERMISSION)) {
    // In an educational UI, explain to the user why your app requires this
    // permission for a specific feature to behave as expected, and what
    // features are disabled if it's declined. In this UI, include a
    // "cancel" or "no thanks" button that lets the user continue
    // using your app without granting the permission.
    showInContextUI(...);
} else {
    // You can directly ask for the permission.
    requestPermissions(CONTEXT,
            new String[] { Manifest.permission.REQUESTED_PERMISSION },
            REQUEST_CODE);
}

Lorsque l'utilisateur a répondu à la boîte de dialogue d'autorisations du système, celui-ci appelle l'intégration de onRequestPermissionsResult() dans votre application. Le système transmet la réponse de l'utilisateur à la boîte de dialogue d'autorisation, ainsi que le code de requête que vous avez défini, comme indiqué dans l'extrait de code suivant :

Kotlin

override fun onRequestPermissionsResult(requestCode: Int,
        permissions: Array<String>, grantResults: IntArray) {
    when (requestCode) {
        PERMISSION_REQUEST_CODE -> {
            // If request is cancelled, the result arrays are empty.
            if ((grantResults.isNotEmpty() &&
                    grantResults[0] == PackageManager.PERMISSION_GRANTED)) {
                // Permission is granted. Continue the action or workflow
                // in your app.
            } else {
                // Explain to the user that the feature is unavailable because
                // the feature requires a permission that the user has denied.
                // At the same time, respect the user's decision. Don't link to
                // system settings in an effort to convince the user to change
                // their decision.
            }
            return
        }

        // Add other 'when' lines to check for other
        // permissions this app might request.
        else -> {
            // Ignore all other requests.
        }
    }
}

Java

@Override
public void onRequestPermissionsResult(int requestCode, String[] permissions,
        int[] grantResults) {
    switch (requestCode) {
        case PERMISSION_REQUEST_CODE:
            // If request is cancelled, the result arrays are empty.
            if (grantResults.length > 0 &&
                    grantResults[0] == PackageManager.PERMISSION_GRANTED) {
                // Permission is granted. Continue the action or workflow
                // in your app.
            }  else {
                // Explain to the user that the feature is unavailable because
                // the feature requires a permission that the user has denied.
                // At the same time, respect the user's decision. Don't link to
                // system settings in an effort to convince the user to change
                // their decision.
            }
            return;
        }
        // Other 'case' lines to check for other
        // permissions this app might request.
    }
}

Demander l'autorisation d'accéder à la position

Lorsque vous demandez une autorisation d'accéder à la position, suivez les mêmes bonnes pratiques que pour toute autre autorisation d'exécution. S'agissant des autorisations d'accéder à la position, l'une des principales différences est que le système en comprend plusieurs. Les autorisations que vous demandez et la manière dont vous les demandez dépendent des exigences de localisation du cas d'utilisation de votre application.

Localisation au premier plan

Si votre application contient une fonctionnalité qui ne partage ou ne reçoit des informations de localisation qu'une seule fois, ou pendant une durée déterminée, un accès à la localisation au premier plan est nécessaire. Quelques exemples :

Dans une application de navigation, une fonctionnalité permet aux utilisateurs d'obtenir des instructions de navigation détaillées.
Dans une application de chat, une fonctionnalité permet aux utilisateurs de partager leur position actuelle avec un autre utilisateur.

Le système considère que votre application utilise la localisation au premier plan si l'une des fonctionnalités de votre application accède à la position actuelle de l'appareil dans l'une des situations suivantes :

Une activité liée à votre application est visible.
Votre application exécute un service de premier plan. Lorsqu'un service de premier plan est en cours d'exécution, le système le fait savoir à l'utilisateur en affichant une notification permanente. Votre application conserve l'accès lorsqu'elle est placée en arrière-plan (par exemple, lorsque l'utilisateur appuie sur le bouton Accueil ou éteint l'écran de son appareil).

Sur Android 10 (niveau d'API 29) ou version ultérieure, vous devez déclarer un type de service de premier plan location, comme indiqué dans l'extrait de code suivant. Sur les versions antérieures d'Android, il est recommandé de déclarer ce type de service de premier plan.
```


<service
    android:name="MyNavigationService"
    android:foregroundServiceType="location" ... >
    
</service>
```

Vous déclarez que la localisation au premier plan est nécessaire lorsque votre application demande l'autorisation ACCESS_COARSE_LOCATION ou ACCESS_FINE_LOCATION, comme indiqué dans l'extrait de code suivant :

<manifest ... >
  <!-- Include this permission any time your app needs location information. -->
  <uses-permission android:name="android.permission.ACCESS_COARSE_LOCATION" />

  <!-- Include only if your app benefits from precise location access. -->
  <uses-permission android:name="android.permission.ACCESS_FINE_LOCATION" />
</manifest>

Localisation en arrière-plan

Une application nécessite un accès à la localisation en arrière-plan si l'une de ses fonctionnalités partage en continu sa position avec d'autres utilisateurs ou utilise l'API Geofencing. Quelques exemples :

Dans une application de partage de position avec la famille, une fonctionnalité permet aux utilisateurs de partager leur position en continu avec les membres de leur famille.
Dans une application IoT, une fonctionnalité permet à l'utilisateur de configurer ses appareils connectés de sorte qu'ils s'éteignent lorsqu'il quitte la maison, puis se rallument à son retour.

Le système considère que votre application utilise la localisation en arrière-plan si elle accède à la position actuelle de l'appareil dans une situation autre que celles décrites dans la section Localisation au premier plan. La précision de la localisation en arrière-plan est identique à celle de la localisation au premier plan et dépend des autorisations d'accès à la position déclarées par votre application.

Sur Android 10 (niveau d'API 29) ou version ultérieure, vous devez déclarer l'autorisation ACCESS_BACKGROUND_LOCATION dans le fichier manifeste de votre application pour demander l'accès à la localisation en arrière-plan au moment de l'exécution. Sur les versions antérieures d'Android, lorsque votre application reçoit un accès à la localisation au premier plan, elle reçoit également automatiquement l'accès à la localisation en arrière-plan.

<manifest ... >
  <!-- Required only when requesting background location access on
       Android 10 (API level 29) and higher. -->
  <uses-permission android:name="android.permission.ACCESS_BACKGROUND_LOCATION" />
</manifest>

Gérer le refus d'autorisation

Si l'utilisateur refuse une demande d'autorisation, votre application doit aider les utilisateurs à comprendre les conséquences de ce refus. En particulier, votre application doit informer les utilisateurs des fonctionnalités qui ne fonctionnent pas sans l'autorisation requise. Pour ce faire, respectez les bonnes pratiques suivantes :

Attirez l'attention des utilisateurs. Mettez en évidence une partie spécifique de l'interface utilisateur de votre application lorsque les fonctionnalités sont limitées parce qu'elles requièrent des autorisations non accordées. Voici quelques exemples de ce que vous pouvez mettre en place :
- Afficher un message dans lequel les résultats ou les données de la fonctionnalité auraient été affichés
- Afficher un autre bouton contenant une icône d'erreur et une couleur
Soyez précis. Évitez les messages génériques. Indiquez plutôt clairement les fonctionnalités qui ne sont pas disponibles sans les autorisations nécessaires.
Ne bloquez pas l'interface utilisateur. Autrement dit, n'affichez pas de message d'avertissement en plein écran qui empêche les utilisateurs de continuer à utiliser votre application.

En parallèle, votre application doit respecter la décision de l'utilisateur de refuser une autorisation. À partir d'Android version 11 (niveau 30 d'API), si l'utilisateur appuie sur Refuser plusieurs fois pour une autorisation spécifique pendant l'installation de votre application sur un appareil, la boîte de dialogue des autorisations système n'apparaît plus en cas de nouvelle demande de cette autorisation. L'action de l'utilisateur implique l'option "Ne plus demander". Dans les versions antérieures, la boîte de dialogue des autorisations système s'affichait chaque fois que l'application demandait une autorisation, sauf si l'utilisateur avait déjà coché une case ou une option "Ne plus demander".

Si un utilisateur refuse une demande d'autorisation plusieurs fois, ce refus est considéré comme permanent. Il est très important de ne demander des autorisations aux utilisateurs que s'ils ont besoin d'accéder à une fonctionnalité spécifique. Sinon, vous risquez de perdre par inadvertance la possibilité de leur demander à nouveau des autorisations.

Dans certains cas, l'autorisation peut être automatiquement refusée sans intervention de l'utilisateur. Une autorisation peut également être automatiquement accordée. Il est important de ne rien présupposer concernant le comportement automatique. Chaque fois que votre application a besoin d'accéder à une fonctionnalité nécessitant une autorisation, vérifiez qu'elle dispose de cette autorisation.

Pour fournir la meilleure expérience utilisateur possible lorsque vous demandez des autorisations pour une application, consultez également les bonnes pratiques concernant les autorisations d'application.

Inspecter l'état de refus lors des tests et du débogage

Pour déterminer si des autorisations d'application ont été définitivement refusées (à des fins de débogage et de test), utilisez la commande suivante :

adb shell dumpsys package PACKAGE_NAME

Où PACKAGE_NAME est le nom du package à inspecter.

Le résultat de la commande contient des sections qui se présentent comme suit :

...
runtime permissions:
  android.permission.POST_NOTIFICATIONS: granted=false, flags=[ USER_SENSITIVE_WHEN_GRANTED|USER_SENSITIVE_WHEN_DENIED]
  android.permission.ACCESS_FINE_LOCATION: granted=false, flags=[ USER_SET|USER_FIXED|USER_SENSITIVE_WHEN_GRANTED|USER_SENSITIVE_WHEN_DENIED]
  android.permission.BLUETOOTH_CONNECT: granted=false, flags=[ USER_SENSITIVE_WHEN_GRANTED|USER_SENSITIVE_WHEN_DENIED]
...

Les autorisations qui ont été refusées une fois par l'utilisateur sont signalées par USER_SET. Les autorisations qui ont été définitivement refusées en sélectionnant Refuser à deux reprises sont signalées par USER_FIXED.

Pour que les testeurs voient la boîte de dialogue de requête pendant les tests, réinitialisez ces indicateurs lorsque vous avez terminé de déboguer votre application. Pour ce faire, utilisez la commande suivante :

adb shell pm clear-permission-flags PACKAGE_NAME PERMISSION_NAME user-set user-fixed

PERMISSION_NAME est le nom de l'autorisation que vous souhaitez réinitialiser.

Pour afficher la liste complète des autorisations d'application Android, consultez la page de référence des API d'autorisation.

Autorisations ponctuelles

L'option "Uniquement cette fois" est le deuxième des trois boutons de la boîte de dialogue. — **Figure 2.** Boîte de dialogue système qui s'affiche lorsqu'une application demande une autorisation ponctuelle.

À partir d'Android 11 (niveau d'API 30), chaque fois que votre application demande une autorisation liée à la localisation, au micro ou à l'appareil photo, la boîte de dialogue des autorisations utilisateur contient une option appelée Uniquement cette fois-ci, comme l'illustre la figure 2. Si l'utilisateur sélectionne cette option dans la boîte de dialogue, une autorisation ponctuelle temporaire est accordée à votre application.

Votre application peut alors accéder aux données associées pendant une période qui dépend du comportement de votre application et des actions de l'utilisateur :

Tant que l'activité de votre application est visible, elle peut accéder aux données.
Si l'utilisateur envoie votre application en arrière-plan, celle-ci peut continuer à accéder aux données pendant une courte période.
Si vous lancez un service de premier plan alors que l'activité est visible et que l'utilisateur déplace votre application en arrière-plan, celle-ci peut continuer à accéder aux données jusqu'à l'arrêt du service de premier plan.

L'action de l'application prend fin lorsque l'autorisation est révoquée

Si l'utilisateur révoque l'autorisation ponctuelle, par exemple dans les paramètres système, votre application ne peut pas accéder aux données, que vous ayez ou non lancé un service de premier plan. Comme pour toute autorisation, si l'utilisateur révoque l'autorisation ponctuelle de votre application, le processus s'interrompt.

Lorsque l'utilisateur ouvre par la suite votre application et qu'une fonctionnalité de celle-ci demande l'accès à la localisation, au micro ou à la caméra, il est de nouveau invité à donner son autorisation.

Réinitialiser les autorisations inutilisées

Android propose plusieurs façons de réinitialiser les autorisations d'exécution inutilisées à leur état refusé par défaut :

Une API dans laquelle vous pouvez supprimer de manière proactive l'accès de votre application à une autorisation d'exécution inutilisée ;
Un mécanisme système qui réinitialise automatiquement les autorisations des applications inutilisées.

Supprimer l'accès à l'application

Sur Android version 13 (niveau 33 d'API) ou ultérieure, vous pouvez supprimer l'accès de votre application aux autorisations d'exécution dont elle n'a plus besoin. Lorsque vous mettez à jour votre application, effectuez cette étape afin que les utilisateurs comprennent mieux pourquoi votre application continue à demander des autorisations spécifiques. Les utilisateurs font ainsi plus facilement confiance à votre application.

Pour supprimer l'accès à une autorisation d'exécution, soumettez le nom de cette autorisation à revokeSelfPermissionOnKill(). Pour supprimer l'accès à un groupe d'autorisations d'exécution en même temps, soumettez un ensemble de noms d'autorisations à revokeSelfPermissionsOnKill(). Le processus de suppression des autorisations se produit de manière asynchrone et supprime tous les processus associés à l'ID unique de votre application.

Pour que le système supprime l'accès de votre application aux autorisations, tous les processus associés à votre application doivent être supprimés. Lorsque vous appelez l'API, le système détermine quand supprimer ces processus en toute sécurité. En général, le système attend que votre application s'exécute un long moment en arrière-plan plutôt qu'au premier plan.

Pour indiquer à l'utilisateur que votre application n'a plus besoin d'accéder à des autorisations d'exécution spécifiques, affichez une boîte de dialogue la prochaine fois qu'il lancera votre application. Cette boîte de dialogue peut inclure la liste des autorisations.

Réinitialiser automatiquement les autorisations des applications inutilisées

Si votre application cible Android version 11 (niveau 30 d'API) ou ultérieure et n'est pas utilisée pendant quelques mois, le système protège les données utilisateur en réinitialisant automatiquement les autorisations d'exécution sensibles que l'utilisateur a accordées à votre application. Pour en savoir plus, consultez le guide sur l'hibernation de l'application.

Demander à devenir le gestionnaire par défaut si nécessaire

Certaines applications dépendent de l'accès aux informations utilisateur sensibles liées aux journaux d'appels et aux SMS. Si vous souhaitez demander les autorisations spécifiques aux journaux d'appels et aux SMS, et publier votre application sur le Play Store, vous devez inviter l'utilisateur à définir votre application comme gestionnaire par défaut pour une fonction système essentielle avant de demander ces autorisations d'exécution.

Pour en savoir plus sur les gestionnaires par défaut, y compris sur la manière d'afficher une invite de gestionnaire par défaut aux utilisateurs, consultez le guide des autorisations propres aux gestionnaires par défaut.

Accepter toutes les autorisations d'exécution à des fins de test

Pour accorder automatiquement toutes les autorisations d'exécution lorsque vous installez une application sur un émulateur ou un appareil de test, utilisez l'option -g pour la commande adb shell install, comme l'illustre l'extrait de code suivant :

adb shell install -g PATH_TO_APK_FILE

Ressources supplémentaires

Pour en savoir plus sur les autorisations, consultez les articles suivants :

Pour en savoir plus sur la demande d'autorisations, consultez les exemples d'autorisations.

Vous pouvez également suivre cet atelier de programmation qui présente les bonnes pratiques concernant la confidentialité.

Déclarer des autorisations d'applications

Demander des autorisations spéciales