AndroidManifest Permissions : concepts clés, déclaration et types d’autorisations

Que sont les AndroidManifest Permissions ?

Les AndroidManifest Permissions sont le mécanisme de sécurité d’Android qui contrôle l’accès des applications aux données protégées et aux fonctions système. Chaque application doit déclarer les autorisations nécessaires dans le fichier AndroidManifest.xml à l’aide de l’élément . Sans déclaration, l’appel de l’API correspondante générera une erreur de sécurité SecurityException.

Le modèle d’autorisations Android a connu plusieurs étapes d’évolution. Avant Android 6.0 (API 23), toutes les autorisations étaient accordées lors de l’installation — l’utilisateur voyait la liste complète et acceptait ou refusait l’installation de l’application. À partir d’Android 6.0, les autorisations de niveau dangerous sont demandées à l’exécution (Runtime Permissions), offrant à l’utilisateur un contrôle plus flexible.

Les autorisations sont divisées en quatre niveaux de protection : normal (accordées automatiquement à l’installation), dangerous (nécessitent une demande à l’exécution), signature (disponibles uniquement pour les applications signées avec le même certificat) et special (nécessitent une activation séparée dans les paramètres). Chaque niveau a son propre mécanisme d’octroi et de révocation.

Selon Google I/O 2024, Android 15 prévoit d’introduire des autorisations plus granulaires — l’utilisateur pourra accorder l’accès uniquement à certains fichiers de la bibliothèque multimédia, et non à l’ensemble de la collection. Cela poursuit la tendance d’Android à minimiser la quantité de données fournies par défaut.

Différence avec le modèle d’autorisations iOS

Contrairement à iOS, où toutes les autorisations sont demandées à l’exécution, Android divise les autorisations en types d’installation (install-time) et d’exécution (runtime). Le niveau normal est accordé automatiquement à l’installation sans notification à l’utilisateur. Le niveau dangerous nécessite une boîte de dialogue explicite, comme dans iOS.

Autre différence : sous Android, les autorisations sont regroupées en groupes d’autorisations. Si l’utilisateur accepte l’accès à l’appareil photo, l’application obtient automatiquement l’accès au microphone — ils sont dans le même groupe MICROPHONE. Sous iOS, chaque autorisation est demandée indépendamment, sans tenir compte des groupes.

Évolution des autorisations par versions Android

Quels types d’autorisations existent

Android définit quatre niveaux de protection pour les autorisations, chacun avec ses propres règles d’octroi. Examinons chaque niveau en détail.

Autorisations Normales (install-time)

Les autorisations normales sont accordées automatiquement lors de l’installation de l’application sans notification ni demande à l’utilisateur. Elles couvrent les fonctions à faible risque qui ne menacent pas la vie privée de l’utilisateur : INTERNET, ACCESS_NETWORK_STATE, VIBRATE, BLUETOOTH. L’utilisateur ne voit aucune boîte de dialogue de consentement — l’autorisation est considérée comme accordée dès l’installation.

Le développeur n’a pas besoin de gérer les demandes dans le code pour les autorisations normales — il suffit de les déclarer dans le manifeste. Cependant, sous Android 12+, lors de l’installation depuis Google Play, l’utilisateur voit un onglet « Autorisations » listant toutes les autorisations normales, ce qui augmente la transparence. Selon Statista (2024), plus de 90% des applications sur Google Play utilisent INTERNET comme autorisation normale la plus courante.

Autorisations Dangereuses (runtime)

Les autorisations dangereuses couvrent l’accès aux données et fonctions qui peuvent compromettre la vie privée : appareil photo, microphone, géolocalisation, contacts, SMS, téléphone, calendrier, capteurs corporels. Ces autorisations nécessitent un mécanisme en deux étapes : déclaration dans le manifeste + demande à l’exécution via ActivityCompat.requestPermissions().

L’utilisateur peut refuser une autorisation dangereuse, et l’application doit gérer ce scénario correctement. Sous Android 11+, si l’utilisateur refuse deux fois, les demandes ultérieures n’affichent pas la boîte de dialogue système — le système retourne automatiquement DENIED. Dans ce cas, l’application doit diriger l’utilisateur vers les paramètres.

Autorisations Signature et Special

Le niveau signature — l’autorisation est accordée automatiquement si l’application est signée avec le même certificat que le système ou une autre application ayant défini l’autorisation. Utilisé pour les applications système et d’entreprise. Exemple : BIND_ACCESSIBILITY_SERVICE — disponible uniquement pour les applications système.

Le niveau special (SYSTEM_ALERT_WINDOW, WRITE_SETTINGS, REQUEST_INSTALL_PACKAGES, MANAGE_EXTERNAL_STORAGE) — nécessite une action explicite de l’utilisateur via les paramètres système. L’application peut ouvrir la page des paramètres avec Intent(Settings.ACTION_MANAGE_OVERLAY_PERMISSION). Google Play limite l’utilisation des autorisations special et exige une justification dans le formulaire de publication.

Runtime Permission : travailler avec les autorisations dangereuses

Depuis Android 6.0, toutes les autorisations dangereuses nécessitent une demande à l’exécution. Parcourons le cycle complet de travail avec les runtime permissions en Kotlin.

Vérification et demande d’autorisation

Avant d’appeler une API nécessitant une autorisation dangereuse, vérifiez toujours l’état actuel via ContextCompat.checkSelfPermission(). Si l’état est PERMISSION_GRANTED, vous pouvez appeler l’API. Si PERMISSION_DENIED, vous devez demander l’autorisation via ActivityResultContract RequestPermission (AndroidX) ou l’ancienne méthode requestPermissions().

Il est recommandé d’utiliser ActivityResultContracts.RequestMultiplePermissions pour demander plusieurs autorisations à la fois. Google recommande de regrouper les autorisations connexes (par exemple, appareil photo + microphone pour l’enregistrement vidéo) dans une seule boîte de dialogue, afin que l’utilisateur voie le contexte complet de la demande.

import android.Manifest
import android.content.pm.PackageManager
import androidx.activity.result.contract.ActivityResultContracts
import androidx.core.content.ContextCompat

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

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

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

Gestion du refus « Ne plus demander »

Si l’utilisateur refuse deux fois, Android place la demande dans l’état « Never ask again ». Dans ce cas, shouldShowRequestPermissionRationale() retourne false, et la boîte de dialogue système ne sera pas affichée. L’application doit diriger l’utilisateur vers les paramètres système via Intent(Settings.ACTION_APPLICATION_DETAILS_SETTINGS).

Important : n’affichez pas une boîte de dialogue proposant d’ouvrir les paramètres immédiatement après le premier refus — cela est perçu comme un comportement agressif. Utilisez shouldShowRequestPermissionRationale() pour déterminer s’il est nécessaire d’afficher une explication. Les Directives Material Design recommandent d’afficher un écran expliquant la valeur de l’accès, et non pas seulement un bouton « Ouvrir les paramètres ».

private fun openAppSettings() {
    Intent(
        Settings.ACTION_APPLICATION_DETAILS_SETTINGS,
        Uri.fromParts("package", packageName, null)
    ).also { intent ->
        startActivity(intent)
    }
}

private fun showPermissionSettings() {
    AlertDialog.Builder(this)
        .setTitle("Accès à l’appareil photo")
        .setMessage("Autorisez l’accès à l’appareil photo dans les Paramètres, "
            + "pour prendre des photos de profil")
        .setPositiveButton("Ouvrir les paramètres") { _, _ ->
            openAppSettings()
        }
        .setNegativeButton("Annuler", null)
        .show()
}

Déclaration des autorisations dans AndroidManifest.xml

Le fichier AndroidManifest.xml contient l’élément pour chaque autorisation utilisée par l’application. Les autorisations sont déclarées au niveau avant l’élément .

Syntaxe de déclaration

Chaque autorisation est déclarée avec un élément distinct utilisant l’attribut android:name qui spécifie le nom complet de l’autorisation. Pour les autorisations introduites dans des versions spécifiques d’Android, utilisez l’attribut maxSdkVersion pour limiter la déclaration aux seules versions nécessaires — cela améliore la compatibilité.

Par exemple, l’autorisation WRITE_EXTERNAL_STORAGE n’est pas nécessaire sous Android 10+ (Scoped Storage), spécifiez donc maxSdkVersion="28" (Android 9). Cela évite les questions inutiles des utilisateurs sur les versions plus récentes. Android Studio avertit des maxSdkVersion recommandés via Lint.

<!-- AndroidManifest.xml -->
<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android">

    <!-- Normal permissions (install-time) -->
    <uses-permission
        android:name="android.permission.INTERNET" />
    <uses-permission
        android:name="android.permission.ACCESS_NETWORK_STATE" />

    <!-- Dangerous permissions (runtime) -->
    <uses-permission
        android:name="android.permission.CAMERA" />
    <uses-permission
        android:name="android.permission.ACCESS_FINE_LOCATION" />

    <!-- Legacy storage permission limited to API 28 and below -->
    <uses-permission
        android:name="android.permission.WRITE_EXTERNAL_STORAGE"
        android:maxSdkVersion="28" />

    <uses-feature
        android:name="android.hardware.camera"
        android:required="false" />

    <application>
        <!-- ... -->
    </application>
</manifest>

Utilisation de pour le filtrage

L’élément indique que l’application nécessite un matériel spécifique (appareil photo, GPS, NFC). L’attribut android:required="false" permet d’installer l’application sur des appareils sans ce matériel — la disponibilité est vérifiée dans le code. Si required="true", Google Play filtre l’application et la rend indisponible pour les appareils non compatibles.

Il est recommandé de définir required="false" pour toutes les fonctionnalités matérielles et de vérifier la disponibilité par programmation via PackageManager.hasSystemFeature(). Cela élargit l’audience de votre application. La seule exception est si la fonctionnalité est critique pour le fonctionnement de l’application (une application de taxi sans GPS n’a pas de sens).

Bonnes pratiques et erreurs

La gestion correcte des autorisations est un aspect clé de la qualité d’une application Android. Examinons les principales recommandations et les erreurs typiques.

Minimiser les autorisations demandées

Ne demandez que les autorisations réellement nécessaires au fonctionnement de l’application. Chaque autorisation supplémentaire réduit le taux de conversion des installations et augmente le nombre de refus. La Google Play Console montre combien d’utilisateurs ont refusé l’installation en raison de l’ensemble des autorisations. Selon AppBrain (2024), les applications avec 10+ autorisations dangereuses ont 35% d’installations en moins.

Révisez régulièrement votre liste d’autorisations. Supprimez celles qui ne sont pas utilisées, en particulier lors de la migration vers des versions plus récentes d’Android où certaines autorisations deviennent optionnelles. Par exemple, avec le sélecteur de photos (ActivityResultContracts.PickVisualMedia) sous Android 13+, l’accès à la bibliothèque multimédia peut être obtenu sans l’autorisation dangereuse READ_MEDIA_IMAGES.

Afficher une explication avant la demande

Avant de demander une autorisation dangereuse, affichez à l’utilisateur un écran expliquant pourquoi cette autorisation est nécessaire et quelle valeur elle apporte. Material Design recommande d’utiliser une feuille inférieure ou une boîte de dialogue avec une icône, un texte bref et un bouton « Continuer ». L’explication augmente le consentement de 20à30% par rapport à une demande directe.

Vérifiez shouldShowRequestPermissionRationale() avant d’appeler launch(). Si true, affichez l’explication. Si false, soit l’autorisation est déjà accordée, soit l’utilisateur l’a refusée définitivement (ne plus demander). Dans ce dernier cas, affichez un bouton « Ouvrir les paramètres » plutôt que de répéter la demande.

Tester tous les scénarios d’autorisations

Testez tous les scénarios possibles : octroi de l’autorisation, refus, refus définitif, révocation de l’autorisation dans les paramètres, réinitialisation des autorisations (Android 11+ auto-reset). Chaque scénario doit être traité sans crash ni perte de données. Le Guide de test Android recommande d’utiliser la bibliothèque TestPermission pour automatiser les tests.

Portez une attention particulière au scénario où l’utilisateur révoque une autorisation pendant que l’application est en cours d’exécution (application minimisée → Paramètres → révocation). Au retour dans l’application, vérifiez toutes les autorisations dans onResume(). Ne vous fiez pas à la mise en cache du statut des autorisations — l’utilisateur peut les modifier à tout moment.

Erreurs typiques

• Demander une autorisation sans vérifier d’abord checkSelfPermission — déclenche une boîte de dialogue inutile
• Ignorer shouldShowRequestPermissionRationale — dégrade l’expérience utilisateur après le premier refus
• Demander une autorisation sans contexte (juste « Autoriser l’accès ? ») — réduit le consentement
• Utiliser WRITE_EXTERNAL_STORAGE sous Android 10+ sans maxSdkVersion — demande inutile
• Absence de vérification des autorisations dans onResume — manquer la révocation d’autorisation dans les paramètres