Runtime Permission : quels types existent et principe de fonctionnement dans Android

Qu'est-ce que Runtime Permission ?

Runtime Permission est un modèle de sécurité Android dans lequel l'application demande l'accès à des données confidentielles au moment où cette fonctionnalité est réellement nécessaire à l'utilisateur. Avant Android 6.0, toutes les autorisations étaient accordées lors de l'installation de l'application, et l'utilisateur ne pouvait pas les révoquer sans désinstaller complètement l'application.

Évolution du modèle d'autorisations Android

Avant Android 6.0, l'utilisateur voyait une liste de toutes les autorisations lors de l'installation et pouvait soit toutes les accepter, soit refuser l'installation. Une étude de 2015 a montré que 87% des utilisateurs ne lisent pas la liste des autorisations lors de l'installation. Android 6.0 a introduit les runtime permissions, divisant les autorisations en normales (automatiques) et dangereuses (avec demande). Android 11 a ajouté les autorisations uniques — révocation automatique à la fermeture de l'application. Android 13 a introduit le sélecteur de photos et les notifications push comme runtime permissions distinctes.

iOS utilise un modèle similaire depuis iOS 10, où l'accès à l'appareil photo, au microphone et à la géolocalisation est demandé lors de la première utilisation. Cependant, iOS n'a pas de concept d'« autorisations normales » — chaque autorisation est demandée explicitement, et le refus persiste jusqu'à ce que le développeur refasse la demande via les paramètres système.

Comment fonctionne Runtime Permission dans Android ?

Runtime Permission fonctionne via une boîte de dialogue système invoquée par la méthode requestPermissions() (AndroidX — ActivityResultLauncher). Le système affiche une boîte de dialogue standard avec une explication, et l'utilisateur choisit « Autoriser » ou « Refuser ». Après la réponse, un callback est déclenché où l'application traite la décision de l'utilisateur.

Demande d'autorisation via ActivityResultLauncher

private lateinit var requestPermissionLauncher: ActivityResultLauncher<String>

override fun onCreate(savedInstanceState: Bundle?) {
    super.onCreate(savedInstanceState)

    requestPermissionLauncher =
        registerForActivityResult(ActivityResultContracts.RequestPermission()) { isGranted ->
            if (isGranted) {
                startCamera()
            } else {
                showPermissionDeniedDialog()
            }
        }
}

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

La méthode shouldShowRequestPermissionRationale retourne true si l'utilisateur a déjà refusé la demande une fois. Dans ce cas, il est recommandé d'afficher une boîte de dialogue expliquant pourquoi l'application a besoin de l'autorisation, et seulement ensuite de refaire la demande. Cela augmente la probabilité de consentement de l'utilisateur de 30–40% (données Google I/O 2024).

Types d'autorisations dans Android

Android classe toutes les autorisations en plusieurs niveaux de protection : normales, dangereuses, de signature et spéciales. Les autorisations normales sont accordées automatiquement lors de l'installation. Les autorisations dangereuses nécessitent une demande d'exécution. Les autorisations de signature sont disponibles uniquement pour les applications signées avec le même certificat.

Groupes d'autorisations dangereuses

Les autorisations spéciales (SYSTEM_ALERT_WINDOW, WRITE_SETTINGS, MANAGE_EXTERNAL_STORAGE) nécessitent une navigation supplémentaire vers les paramètres système via Settings.ACTION_MANAGE_OVERLAY_PERMISSION. Ces autorisations ne peuvent pas être demandées via la boîte de dialogue standard du système et nécessitent une action explicite de l'utilisateur dans l'écran des paramètres.

Demande d'autorisations dans Android 12+

Android 12 a introduit des changements significatifs dans le modèle des runtime permissions. Les autorisations uniques permettent d'accorder l'accès à l'appareil photo, au microphone ou à la géolocalisation pour une seule session. Dès que l'utilisateur ferme l'application, l'autorisation est automatiquement révoquée. Les indicateurs de confidentialité sont des indicateurs verts dans la barre d'état qui montrent quand une application utilise l'appareil photo ou le microphone.

Gestion des autorisations uniques

// Android 12+ — gestion de l'autorisation unique de localisation
private fun checkLocationPermission() {
    val permissionLauncher =
        registerForActivityResult(ActivityResultContracts.RequestMultiplePermissions()) { permissions ->

        val fineLocationGranted = permissions[Manifest.permission.ACCESS_FINE_LOCATION]
        val coarseLocationGranted = permissions[Manifest.permission.ACCESS_COARSE_LOCATION]

        if (fineLocationGranted == true) {
            showUserLocation()
        } else {
            showLocationDisabledDialog()
        }
    }

    permissionLauncher.launch(
        arrayOf(
            Manifest.permission.ACCESS_FINE_LOCATION,
            Manifest.permission.ACCESS_COARSE_LOCATION
        )
    )
}

// Vérifier si l'autorisation a été révoquée par le système (Android 12+)
class PermissionReceiver : BroadcastReceiver() {
    override fun onReceive(context: Context, intent: Intent) {
        if (intent.action == Intent.ACTION_PERMISSION_REVOCATION) {
            handleRevokedPermission(intent.getStringExtra(Intent.EXTRA_REVOKED_PERMISSION))
        }
    }
}

Android 13 a ajouté l'autorisation POST_NOTIFICATIONS au groupe dangereux, nécessitant une demande explicite pour envoyer des notifications push. Android 14 a introduit des restrictions sur la géolocalisation en arrière-plan : l'application doit obtenir l'approbation explicite de l'utilisateur à chaque demande de localisation en arrière-plan. Le sélecteur de photos (API 33+) a remplacé le besoin de READ_EXTERNAL_STORAGE pour la sélection d'images.

Gestion des refus de l'utilisateur

Le refus de l'utilisateur à une demande d'autorisation est une situation normale qui doit être traitée correctement. Il existe deux types de refus : unique (l'utilisateur a appuyé sur « Refuser ») et permanent (l'utilisateur a sélectionné « Ne plus demander »). Dans le second cas, la boîte de dialogue système n'apparaîtra plus et l'application doit rediriger l'utilisateur vers les paramètres système.

Stratégie de gestion des refus

Après le premier refus, l'application doit afficher une boîte de dialogue de justification — sa propre explication de pourquoi l'autorisation est nécessaire. Si l'utilisateur refuse à nouveau, l'application doit rediriger vers l'écran des paramètres de l'application via Settings.ACTION_APPLICATION_DETAILS_SETTINGS. Material 3 recommande d'utiliser PermissionRequestBottomSheet pour une UX plus naturelle.

Il est important de ne pas bloquer complètement les fonctionnalités de l'application en cas de refus. Par exemple, si l'utilisateur a refusé la géolocalisation, l'application doit proposer une saisie manuelle de l'adresse. Pour l'appareil photo, permettre le téléchargement d'une image depuis la galerie. Google recommande de toujours fournir un mécanisme de secours pour toutes les runtime permissions.

Recommandations de sécurité

Les runtime permissions ne sont pas seulement un mécanisme technique, mais aussi un élément de confiance de l'utilisateur envers l'application. Demander une autorisation à un moment inapproprié (par exemple, au premier lancement) réduit considérablement la probabilité de consentement. Google Play Store analyse la fréquence et le contexte des demandes d'autorisation : les applications avec des demandes agressives obtiennent des positions moins élevées dans les résultats de recherche.

Règles pour les demandes d'autorisation

Contexte — demandez l'autorisation immédiatement avant d'effectuer l'action qui la nécessite. Minimum — demandez uniquement les autorisations réellement nécessaires au fonctionnement de la fonctionnalité. Transparence — expliquez à l'utilisateur pourquoi l'autorisation est nécessaire avant la boîte de dialogue système. Révocation — abonnez-vous à ACTION_PERMISSION_REVOCATION pour gérer correctement la révocation des autorisations au moment de l'exécution.

Pour tester les runtime permissions, utilisez les commandes adb : adb shell pm revoke <package> android.permission.CAMERA permet de simuler la révocation d'autorisation sans réinstaller l'application. Espresso et UiAutomator prennent en charge les tests de boîtes de dialogue d'autorisation via GrantPermissionRule. L'intégration de ces outils dans le pipeline CI/CD est obligatoire pour les applications avec runtime permissions.

Audit des autorisations dans Google Play Console

Google Play Console fournit une section d'audit des autorisations, où les développeurs peuvent voir à quelle fréquence les autorisations sont demandées, quel pourcentage d'utilisateurs accorde l'accès et quelles autorisations ont été révoquées. L'analyse de ces données aide à identifier les demandes inefficaces et à optimiser l'UX. Par exemple, si moins de 40% des utilisateurs accordent la géolocalisation, envisagez de revoir le moment de la demande et d'ajouter une justification plus convaincante.

L'utilisation de Android Vitals pour surveiller les ANR (Application Not Responding) liés aux autorisations est également critique. Si une demande d'autorisation est exécutée sur le thread principal ou si la boîte de dialogue système bloque l'interface, cela peut provoquer une ANR sur les appareils lents. Déplacez la vérification et la demande d'autorisation vers un thread séparé ou utilisez les coroutines Kotlin pour un traitement asynchrone afin d'éviter de bloquer l'interface utilisateur.