Dangerous Permission sur Android : définition, liste des autorisations et demande runtime

Qu'est-ce que Dangerous Permission sur Android

Dangerous Permission est une catégorie d'autorisations système Android qui donnent accès aux données sensibles de l'utilisateur. Contrairement aux autorisations normales, les autorisations dangereuses ne sont pas accordées automatiquement lors de l'installation — l'application doit les demander explicitement à l'exécution via le mécanisme runtime introduit dans Android 6.0 Marshmallow (API 23).

La nécessité d'une demande explicite est due à la nature des données que ces autorisations protègent : localisation de l'utilisateur, contacts personnels, contenu de l'appareil photo et du microphone, historique des appels et SMS. Android considère ces données comme sensibles et exige que l'utilisateur accorde l'accès en toute connaissance de cause. Selon Android Privacy Sandbox (2024), les utilisateurs refusent en moyenne environ 30 pour cent des demandes runtime.

Une caractéristique clé de Dangerous Permission est la possibilité de le révoquer à tout moment. L'utilisateur peut aller dans Paramètres — Applications — Autorisations et désactiver toute autorisation dangereuse. L'application doit être prête à ce qu'une autorisation précédemment accordée puisse être révoquée à tout moment sans redémarrage.

ProtectionLevel dangerous

Le niveau de protection dangerous est défini dans les définitions d'autorisations système au niveau de l'OS. Lorsqu'une application déclare uses-permission avec ce protectionLevel, le système marque l'autorisation comme nécessitant une demande runtime. Contrairement à normal, les autorisations dangerous sont toujours affichées dans l'interface de gestion des autorisations du système et peuvent être révoquées.

Permission Group et Dangerous

Toutes les autorisations dangereuses sont regroupées en Permission Groups par catégorie fonctionnelle. Par exemple, CAMERA et CAMERA2 sont dans le groupe CAMERA, ACCESS_FINE_LOCATION et ACCESS_COARSE_LOCATION sont dans le groupe LOCATION. Si un utilisateur a accordé une autorisation d'un groupe, les autorisations restantes du même groupe sont accordées automatiquement sans boîte de dialogue supplémentaire.

Comment fonctionne la demande runtime

La demande runtime est un mécanisme où l'application appelle une API système pour afficher une boîte de dialogue de demande d'autorisation. L'utilisateur voit une fenêtre modale avec le nom de l'autorisation et les boutons Autoriser et Refuser. Après la réponse, le système appelle le callback onRequestPermissionsResult avec le résultat.

Le cycle complet comprend trois étapes : vérification du statut via checkSelfPermission, appel de requestPermissions si l'autorisation n'est pas accordée et traitement du résultat dans onRequestPermissionsResult. La vérification du statut est obligatoire car l'utilisateur peut avoir révoqué l'autorisation à tout moment via les paramètres, et appeler une fonction sans vérification entraînera une SecurityException.

fun checkAndRequestCameraPermission() {
    when {
        ContextCompat.checkSelfPermission(
            this,
            Manifest.permission.CAMERA
        ) == PackageManager.PERMISSION_GRANTED -> {
            openCamera()
        }
        else -> {
            ActivityCompat.requestPermissions(
                this,
                arrayOf(Manifest.permission.CAMERA),
                REQUEST_CAMERA_CODE
            )
        }
    }
}

Le traitement du résultat se fait dans ActivityResultLauncher ou onRequestPermissionsResult. L'approche moderne recommandée est d'utiliser ActivityResultContracts.RequestPermission, qui fournit une API plus propre sans codes de demande explicites. Ce contrat retourne un Boolean — si l'autorisation a été accordée ou non.

Bonnes pratiques de demande

Demandez les autorisations dangereuses strictement dans le contexte d'utilisation de la fonctionnalité, pas au démarrage de l'application. Si l'utilisateur a appuyé sur le bouton de l'appareil photo — demandez CAMERA. S'il a ouvert une carte — demandez LOCATION. Les demandes contextuelles donnent deux fois plus d'acceptations que la demande de toutes les autorisations au premier lancement. Il est également recommandé de ne pas demander plus d'une autorisation à la fois pour que l'utilisateur comprenne quelle fonctionnalité nécessite l'accès.

Liste des autorisations dangereuses sur Android

Android définit plusieurs groupes d'autorisations dangereuses, chacun contenant une ou plusieurs constantes. La liste la plus complète est disponible dans la classe Manifest.permission. Voici les principaux groupes et autorisations utilisés dans le développement.

Nouvelles autorisations dans Android 12+

À partir d'Android 12, Google a renforcé les exigences pour certaines autorisations. Par exemple, BLUETOOTH_CONNECT et BLUETOOTH_SCAN sont devenues dangereuses et nécessitent une demande runtime. L'autorisation BODY_SENSORS_BACKGROUND a également été ajoutée pour l'accès en arrière-plan aux capteurs. Les développeurs doivent mettre à jour targetSdkVersion et tester les demandes sur les versions actuelles de l'OS.

Autorisations pour Android 13+

Android 13 (API 33) a introduit de nouvelles autorisations pour les notifications (POST_NOTIFICATIONS) et les fichiers multimédias (READ_MEDIA_IMAGES, READ_MEDIA_VIDEO, READ_MEDIA_AUDIO), remplaçant le READ_EXTERNAL_STORAGE général. Désormais, l'accès aux photos, vidéos et audio est demandé séparément via des autorisations spécialisées sans boîte de dialogue unique.

Dangerous vs Normal Permission

Les autorisations Dangerous et Normal diffèrent fondamentalement par leur mode d'octroi, leur révocabilité et leur UX. Normal est accordée automatiquement lors de l'installation, Dangerous nécessite une boîte de dialogue runtime explicite. Normal ne peut pas être révoquée via les paramètres, Dangerous peut être désactivée à tout moment. Cette asymétrie crée différents modèles de développement.

Du point de vue du code, les autorisations dangereuses nécessitent plus de travail : checkSelfPermission, requestPermissions, gestion du refus. Pour les normales, une ligne dans AndroidManifest.xml suffit. Cependant, Dangerous Permission donne le contrôle à l'utilisateur, ce qui augmente la confiance, en particulier pour les fonctionnalités sensibles comme l'appareil photo ou la localisation.

Le choix entre les catégories n'appartient pas au développeur — il est déterminé par le système. Le développeur déclare seulement uses-permission, et le système détermine la catégorie en fonction de protectionLevel. Cependant, la stratégie de demande des autorisations dangereuses affecte l'expérience utilisateur : des boîtes de dialogue fréquentes ou inappropriées diminuent la note de l'application.

Comment demander des autorisations en Kotlin

La façon moderne de demander des autorisations en Kotlin est d'utiliser ActivityResultContracts.RequestMultiplePermissions ou RequestPermission. Ces contrats font partie de la bibliothèque androidx.activity et fournissent une API propre basée sur les lambdas, sans avoir à surcharger onRequestPermissionsResult.

class CameraActivity : AppCompatActivity() {
    private val requestPermissionLauncher =
        registerForActivityResult(
            ActivityResultContracts.RequestPermission()
        ) { isGranted: Boolean ->
            if (isGranted) {
                openCamera()
            } else {
                showPermissionDeniedMessage()
            }
        }

    fun requestCamera() {
        when {
            ContextCompat.checkSelfPermission(
                this,
                Manifest.permission.CAMERA
            ) == PackageManager.PERMISSION_GRANTED ->
                openCamera()
            ActivityCompat.shouldShowRequestPermissionRationale(
                this,
                Manifest.permission.CAMERA
            ) ->
                showRationaleDialog()
            else ->
                requestPermissionLauncher.launch(
                    Manifest.permission.CAMERA
                )
        }
    }
}

Demander plusieurs autorisations à la fois

Lorsqu'une application a besoin de plusieurs autorisations dangereuses simultanément, utilisez RequestMultiplePermissions. Le contrat retourne Map<String, Boolean> où la clé est le nom de l'autorisation et la valeur le résultat. C'est utile au premier lancement lorsque vous devez demander CAMERA et RECORD_AUDIO pour l'enregistrement vidéo.

Gestion du premier refus

Si l'utilisateur refuse la demande, la méthode shouldShowRequestPermissionRationale retourne true. Cela signale qu'il faut afficher une explication de pourquoi l'autorisation est nécessaire. La meilleure pratique est d'afficher une boîte de dialogue personnalisée avec une explication et un bouton Réessayer. Si l'utilisateur refuse à nouveau la demande avec la case Never Ask Again cochée, shouldShowRequestPermissionRationale retournera false, et vous devez rediriger vers Paramètres.

Gestion du refus et Never Ask Again

Never Ask Again est un drapeau que l'utilisateur peut définir en refusant la boîte de dialogue runtime pour la deuxième fois. Après cela, la boîte de dialogue standard n'est plus affichée pour cette autorisation. La seule façon d'accorder l'accès est de rediriger l'utilisateur vers les paramètres système des applications.

Le développeur doit distinguer deux scénarios de refus : premièrement, quand shouldShowRequestPermissionRationale retourne true (l'utilisateur a refusé mais la boîte de dialogue peut encore être affichée), et deuxièmement, quand la méthode retourne false (Never Ask Again est actif ou l'autorisation est bloquée par une politique). Dans le second cas, vous devez afficher un bouton Ouvrir Paramètres.

fun handlePermissionDenied(permission: String) {
    if (ActivityCompat.shouldShowRequestPermissionRationale(
            this, permission
    )) {
        showRationaleDialog(permission)
    } else {
        showSettingsRedirectDialog(permission)
    }
}

private fun showSettingsRedirectDialog(permission: String) {
    AlertDialog.Builder(this)
        .setTitle("Accès refusé")
        .setMessage(
            "Autorisation bloquée. Ouvrez Paramètres."
        )
        .setPositiveButton("Paramètres") { _, _ ->
            val intent = Intent(
                Settings.ACTION_APPLICATION_DETAILS_SETTINGS,
                Uri.fromParts(
                    "package", packageName, null
                )
            )
            startActivity(intent)
        }
        .show()
}

Il est important de ne pas redemander l'autorisation si shouldShowRequestPermissionRationale a retourné false. Un appel répété à requestPermissions dans ce cas n'affichera pas de boîte de dialogue — le résultat reviendra immédiatement avec DENIED sans explication. L'utilisateur rencontrera un comportement confus, ce qui nuit à l'expérience d'utilisation de l'application.