Normal Permission dans Android — définition, niveaux de protection et principe de fonctionnement

Qu’est-ce que Normal Permission dans Android

Normal Permission est un type d’autorisation système dans Android avec ProtectionLevel normal, accordé à une application automatiquement au moment de l’installation. Le développeur n’a pas besoin d’écrire de code pour la demander — il suffit de déclarer l’autorisation dans AndroidManifest.xml. L’utilisateur ne voit aucun dialogue et ne peut pas révoquer une autorisation normale séparément, seulement en désinstallant l’application entière.

Le système Android classe les autorisations normales comme à faible risque — elles ne donnent pas accès aux données personnelles, à l’appareil photo ou au microphone. Exemples typiques : accès à Internet, contrôle de la vibration, lecture de l’état Wi-Fi. Selon le Android Security Model (2024), environ 40 pour cent de toutes les autorisations système appartiennent à la catégorie normale.

Une propriété importante — les autorisations normales ne peuvent pas être révoquées à l’exécution via les Paramètres. Si l’utilisateur souhaite refuser l’accès, la seule solution est de désinstaller l’application. Les développeurs doivent en tenir compte dans l’architecture, mais pour les utilisateurs, cette approche simplifie l’interaction : pas de dialogues au premier lancement.

Historique de la catégorie

La division en autorisations normales et dangereuses est apparue dans Android 6.0 Marshmallow (API 23). Avant cette version, toutes les autorisations étaient demandées à l’installation — l’utilisateur voyait une liste unique et l’acceptait ou la refusait dans son ensemble. Normal Permission a conservé ce modèle pour les opérations à faible risque, tandis que Dangerous est passé à la demande d’exécution. Ce changement a amélioré l’expérience utilisateur tout en renforçant la sécurité.

Quelles API nécessitent Normal Permission

De nombreuses API système Android nécessitent une déclaration explicite d’une autorisation normale, même si l’accès est automatique. Par exemple, la classe ConnectivityManager nécessite ACCESS_NETWORK_STATE, VibratorService nécessite VIBRATE, WifiManager nécessite ACCESS_WIFI_STATE. Sans déclarer le uses-permission correspondant, l’appel de ces API entraînera une SecurityException.

Comment fonctionne ProtectionLevel normal

ProtectionLevel normal est le niveau de protection minimal dans le système d’autorisations Android. Les autorisations avec ce niveau sont déclarées dans le manifeste, et le système vérifie la déclaration à l’installation, accordant l’accès sans intervention de l’utilisateur. Aucun élément d’interface n’est affiché, aucun callback n’est invoqué.

Le mécanisme de vérification fonctionne au niveau de PackageManager. Lors de l’installation de l’APK, le système analyse toutes les balises uses-permission, détermine le niveau de protection de chaque autorisation en les comparant aux définitions système dans les fichiers permissions.xml, et pour le niveau normal enregistre simplement l’accès. Le processus prend des millisecondes et ne nécessite aucune interaction avec l’interface utilisateur.

L’algorithme d’octroi fonctionne comme suit :

• Le système lit le manifeste au moment de l’installation de l’application
• Il compare le protectionLevel dans /etc/permissions/ sur l’appareil
• Si la valeur est normal — accorde automatiquement l’accès
• L’autorisation reste active jusqu’à la désinstallation complète de l’application

L’utilisateur ne peut pas révoquer une autorisation normale via l’interface. Dans les paramètres des applications, dans la section Autorisations, seules les autorisations dangereuses sont affichées. Cela contraste avec iOS, où chaque autorisation nécessite une confirmation séparée indépendamment du niveau de sensibilité de la fonction.

Normal Permission vs Dangerous Permission

Normal et Dangerous Permission sont deux catégories opposées de protection dans Android. La principale différence réside dans la méthode d’octroi : les normales sont accordées automatiquement à l’installation, les dangereuses nécessitent un consentement explicite via un dialogue d’exécution. Cette distinction est intégrée dans l’architecture de sécurité d’Android depuis la version 6.0 Marshmallow.

Comparaison des caractéristiques clés :

Différence dans la demande à l’utilisateur

L’utilisateur ne voit aucun dialogue lors de la demande de Normal Permission. Si une application a besoin d’INTERNET — elle l’obtient silencieusement. Pour Dangerous Permission, le système affiche un dialogue modal décrivant l’accès demandé. L’utilisateur appuie sur Autoriser ou Refuser, et peut ensuite révoquer l’autorisation à tout moment via les Paramètres. C’est une différence UX clé qui détermine la stratégie de développement de l’interface.

Quand choisir Normal

Normal doit être utilisé dans tous les cas où l’accès ne concerne pas des données sensibles. ACCESS_NETWORK_STATE pour vérifier la connectivité, VIBRATE pour le retour haptique, INTERNET pour les requêtes HTTP — ce sont toutes des autorisations normales. Utiliser le niveau dangerous là où normal suffit est une mauvaise pratique, créant des dialogues inutiles et réduisant la confiance de l’utilisateur dans l’application.

Liste des autorisations normales dans Android

Android définit plusieurs dizaines d’autorisations normales, chacune correspondant à une fonction système spécifique. Toutes sont disponibles via les constantes de la classe Manifest.permission. Voici une liste des plus fréquemment utilisées dans le développement d’applications.

Groupes d’autorisations normales

Les autorisations normales ne sont pas regroupées en Permission Groups pour l’affichage dans l’interface. Les groupes dans Android sont destinés à l’écran des paramètres, où seules les autorisations dangereuses sont affichées. Cependant, les autorisations normales peuvent être logiquement divisées en catégories : réseau (INTERNET, ACCESS_NETWORK_STATE), matériel (VIBRATE, WAKE_LOCK), système (SET_ALARM) et autorisations Bluetooth.

Certaines constantes de Manifest.permission peuvent changer de niveau de protection sur différentes versions d’Android. Par exemple, BLUETOOTH_CONNECT sur Android 12+ est devenu une autorisation dangereuse avec demande d’exécution, alors que sur les versions plus anciennes elle était normale. Les développeurs sont invités à vérifier le protectionLevel actuel pour l’API cible via la documentation.

Vérification de Normal Permission via PackageManager

Un développeur peut vérifier par programmation si une autorisation est normale via PackageManager. La méthode getPermissionInfo retourne PermissionInfo dont le champ protectionLevel contient le drapeau PermissionInfo.PROTECTION_NORMAL. C’est utile pour la gestion dynamique et le débogage.

fun isNormalPermission(permission: String): Boolean {
    val pm = packageManager
    val info = pm.getPermissionInfo(
        permission,
        PackageManager.GET_META_DATA
    )
    return info.protectionLevel ==
        PermissionInfo.PROTECTION_NORMAL
}

Comment déclarer Normal Permission dans le manifeste

Déclarer Normal Permission dans AndroidManifest.xml est l’opération la plus simple, nécessitant une seule balise uses-permission. Aucune configuration supplémentaire de protectionLevel n’est requise, car le niveau de protection est déterminé par la définition du système, pas par le manifeste de l’application. Le développeur spécifie simplement le nom complet de la constante.

<!-- AndroidManifest.xml -->
<uses-permission
    android:name="android.permission.INTERNET" />
<uses-permission
    android:name="android.permission.ACCESS_NETWORK_STATE" />
<uses-permission
    android:name="android.permission.VIBRATE" />

Le système traite toutes les déclarations à l’installation. Si au moins une des autorisations déclarées a un protectionLevel différent de normal, une demande d’exécution sera nécessaire. INTERNET est l’autorisation normale la plus populaire, présente dans la plupart des applications Android, en particulier celles qui effectuent des requêtes HTTP ou chargent du contenu depuis le réseau.

Exemple de manifeste complet

Un exemple complet d’AndroidManifest.xml avec des autorisations normales et dangereuses démontre la différence : syntaxiquement les balises uses-permission sont identiques, mais à l’exécution INTERNET et VIBRATE seront accordées automatiquement, tandis que CAMERA nécessitera un dialogue.

<manifest
    xmlns:android="http://schemas.android.com/apk/res/android">

    <!-- Normal permissions -->
    <uses-permission
        android:name="android.permission.INTERNET" />
    <uses-permission
        android:name="android.permission.VIBRATE" />

    <!-- Dangerous permission -->
    <uses-permission
        android:name="android.permission.CAMERA" />
</manifest>

Manifest Merger et Normal Permission

Lors de l’utilisation de bibliothèques — Google Play Services, Firebase, Glide — elles peuvent ajouter leurs propres uses-permission au manifeste final via le Manifest Merger. Certaines sont normales (INTERNET pour Firebase), d’autres dangereuses (ACCESS_FINE_LOCATION pour Google Maps). Le développeur doit vérifier le manifeste fusionné final dans build/outputs/logs/manifest-merger-report.txt avant la publication.

Limitations de Normal Permission

Normal Permission a deux limitations fondamentales : l’impossibilité de révocation par l’utilisateur et l’absence d’interface de gestion. Si l’utilisateur ne fait pas confiance à l’application mais que l’autorisation normale a déjà été accordée automatiquement — la seule solution est de désinstaller l’application. Cela crée un certain risque, car les autorisations normales ne peuvent pas être bloquées par les moyens standard d’Android.

Une limitation supplémentaire apparaît sur les appareils avec plusieurs profils (Work Profile, Multiple Users). Normal Permission est accordée à tous les profils à la fois — l’application ne peut pas restreindre l’autorisation à un seul. Dans les scénarios d’entreprise, cela est résolu via Managed Configurations.

Il est impossible de vérifier si une application utilise une Normal Permission à un moment donné. La méthode système checkSelfPermission ne fonctionne que pour les autorisations dangereuses. Pour les normales, elle retourne toujours PERMISSION_GRANTED, ce qui ne reflète pas l’activité réelle. Cela doit être pris en compte lors des audits de sécurité et de l’analyse du comportement de l’application.

Il convient également de noter que certains fabricants d’appareils (Xiaomi, Huawei, Samsung) modifient le comportement standard des autorisations. Sur leurs firmwares, Normal Permission peut nécessiter des autorisations supplémentaires dans le shell propriétaire MIUI ou EMUI. Les développeurs sont invités à tester sur des appareils réels de différents fabricants.