AndroidManifest.xml — qu'est-ce que c'est, composants principaux et configuration du manifeste

Qu'est-ce que AndroidManifest.xml

AndroidManifest.xml est le fichier de configuration racine au format XML que tout projet Android doit avoir dans le répertoire app/src/main. Le système Android l'analyse avant d'exécuter tout code d'application — lors de l'analyse de l'APK à l'installation. Si le manifeste contient une erreur de syntaxe ou s'il manque une déclaration obligatoire, l'installation est interrompue avec un message d'erreur.

Le fichier contient une déclaration complète de l'application : une liste de tous les composants (Activity, Service, BroadcastReceiver, ContentProvider), les autorisations demandées, la version minimale du SDK, les exigences matérielles et la configuration des thèmes et styles. Chaque composant qui peut être invoqué par le système ou d'autres applications doit être explicitement déclaré dans le manifeste. Ceci est une exigence de sécurité : sans déclaration explicite, le composant n'est pas disponible pour l'invocation.

Sans un manifeste correctement configuré, l'application ne peut pas être installée via Google Play ou par sideloading. Le système vérifie le manifeste lors de l'analyse de l'APK et rejette l'installation en cas d'erreurs. Google Play analyse également le manifeste à la recherche de configurations dangereuses : si exported=true sur un composant sans intent-filter, un avertissement est émis ; et si des autorisations obligatoires pour targetSdk 34+ manquent, la publication est bloquée. Par conséquent, comprendre la structure du manifeste est une compétence obligatoire pour les développeurs Android.

Composants de l'application dans le manifeste

Chaque composant d'une application Android doit être explicitement enregistré dans le manifeste. Ceci est une exigence obligatoire de la plateforme pour les quatre types de composants. Sans enregistrement, le composant ne peut pas être créé par le système, et tenter de le lancer entraînera une ActivityNotFoundException ou une exception similaire. Les composants sont enregistrés dans la balise application dans un ordre qui n'affecte pas leur fonctionnement.

Activity

La balise activity enregistre un écran d'application. L'attribut exported détermine si d'autres applications peuvent lancer cette Activity. À partir d'Android 12, l'absence de exported en présence d'intent-filter provoque une erreur de compilation — c'est une exigence de sécurité. Le point d'entrée est défini via intent-filter avec action MAIN et category LAUNCHER. Chaque Activity doit avoir un android:name unique correspondant au nom complet ou relatif de la classe.

<activity
    android:name=".MainActivity"
    android:exported="true"
    android:windowSoftInputMode="adjustResize">
    <intent-filter>
        <action android:name="android.intent.action.MAIN" />
        <category android:name="android.intent.category.LAUNCHER" />
    </intent-filter>
</activity>

Service

La balise service définit un service d'arrière-plan. À partir d'Android 8, les services d'arrière-plan ont des limitations strictes : un foreground service nécessite une notification obligatoire visible par l'utilisateur avec une icône, et un bound service ne vit que tant qu'un client lui est lié. Les services s'exécutant en arrière-plan sans notification sont automatiquement arrêtés par le système dans les minutes qui suivent le passage de l'application en arrière-plan. Pour les tâches de longue durée, utilisez WorkManager au lieu de Service.

<service
    android:name=".SyncService"
    android:exported="false"
    android:foregroundServiceType="dataSync" />

BroadcastReceiver

La balise receiver déclare un récepteur de messages de diffusion système ou personnalisés. À partir d'Android 8, la plupart des broadcasts implicites ne sont plus délivrés aux récepteurs déclarés statiquement dans le manifeste. Il est plutôt recommandé d'enregistrer les récepteurs dynamiquement via Context.registerReceiver dans le code. Les exceptions incluent certains broadcasts système comme BOOT_COMPLETED, qui nécessitent encore un enregistrement statique dans le manifeste.

<receiver
    android:name=".ConnectivityReceiver"
    android:exported="true">
    <intent-filter>
        <action android:name="android.net.conn.CONNECTIVITY_CHANGE" />
    </intent-filter>
</receiver>

Autorisations dans Android

Chaque autorisation dangereuse dans Android nécessite une déclaration dans le manifeste via la balise uses-permission. À partir d'Android 6, les autorisations dangereuses sont demandées à l'exécution via une boîte de dialogue avec l'utilisateur, mais la déclaration dans le manifeste reste obligatoire. Sans elle, la méthode requestPermissions lance une SecurityException. Les autorisations de niveau normal comme INTERNET et ACCESS_NETWORK_STATE sont accordées automatiquement à l'installation.

La balise uses-permission-sdk-23 spécifie les autorisations nécessaires uniquement sur Android 6.0+. Cela permet de maintenir la compatibilité avec les versions plus anciennes sans demander d'autorisations inexistantes. Par exemple, POST_NOTIFICATIONS n'est disponible que sur Android 13+, il doit donc être spécifié via uses-permission-sdk-33 pour éviter une erreur d'autorisation inconnue sur les appareils plus anciens. L'attribut maxSdkVersion dans uses-permission permet de révoquer automatiquement les autorisations inutiles lors de la mise à jour de l'application sur les versions plus récentes d'Android.

Les autorisations de niveau normal (INTERNET, ACCESS_NETWORK_STATE) sont accordées automatiquement à l'installation et ne nécessitent pas de demande à l'exécution. Elles sont également déclarées via uses-permission mais ne sont pas affichées à l'utilisateur dans une boîte de dialogue. Pour contrôler l'accès aux composants de l'application depuis d'autres applications, le mécanisme des composants protégés par autorisation est utilisé : vous pouvez spécifier une autorisation personnalisée au niveau Activity ou Service, qui sera vérifiée par le système lorsque le composant est appelé de l'extérieur. Cela offre une couche de sécurité supplémentaire pour la communication inter-processus.

Intent Filters et deep links

La balise intent-filter dans le manifeste déclare quels intents implicites un composant peut traiter. C'est le mécanisme par lequel Android connecte les actions système ou personnalisées à l'application. Un intent filter se compose de trois éléments : action, category et data. Les trois peuvent être combinés pour une description précise des intents que le composant doit recevoir. Le système sélectionne le composant approprié en fonction du filtre le plus spécifique.

<activity android:name=".DeepLinkActivity">
    <intent-filter android:autoVerify="true">
        <action android:name="android.intent.action.VIEW" />
        <category android:name="android.intent.category.DEFAULT" />
        <category android:name="android.intent.category.BROWSABLE" />
        <data
            android:scheme="https"
            android:host="itsectr.com"
            android:pathPrefix="/app" />
    </intent-filter>
</activity>

L'attribut autoVerify active la vérification Android App Links : le système contacte le serveur pour confirmer la propriété du domaine. Sans vérification, les deep links fonctionnent via la boîte de dialogue de sélection standard où l'utilisateur choisit l'application pour ouvrir le lien. Après une vérification réussie, les liens s'ouvrent directement dans l'application sans dialogue. Google Search Console utilise également autoVerify pour indexer les deep links et les afficher dans les résultats de recherche.

Les filtres avec action.VIEW et les catégories DEFAULT et BROWSABLE traitent les liens provenant des navigateurs, des e-mails et d'autres applications. C'est le mécanisme principal pour implémenter les deep links dans Android. Pour prendre en charge des schémas d'URL personnalisés comme myapp://, il suffit de spécifier le scheme sans hôte. Cependant, Google recommande d'utiliser les deep links HTTPS plutôt que les schémas personnalisés car ils sont plus sécurisés et ne nécessitent pas d'autorisations supplémentaires. Les schémas personnalisés peuvent être interceptés par toute application enregistrant le même schéma.

Attributs de l'application et métadonnées

La balise racine manifest contient les attributs de paquet, de version et de SDK. La balise application stocke les paramètres globaux : thème, icône, libellé et indicateurs de débogage. Les attributs de manifest définissent le versioning au niveau du paquet, tandis que les attributs de application déterminent l'apparence et le comportement généraux de l'application. Les valeurs peuvent être des références à des ressources via la syntaxe @ ou des littéraux de chaîne.

<manifest
    xmlns:android="http://schemas.android.com/apk/res/android"
    package="com.itsectr.myapp"

    <uses-sdk
        android:minSdkVersion="24"
        android:targetSdkVersion="34" />

    <application
        android:label="MyApp"
        android:icon="@mipmap/ic_launcher"
        android:theme="@style/Theme.MyApp"
        android:supportsRtl="true"
        android:allowBackup="true">
        <!--  Composants de l'application  -->
    </application>
</manifest>

La balise meta-data dans application permet de stocker des paires clé-valeur arbitraires. Ceci est pratique pour configurer des bibliothèques tierces : clés API, URL de points de terminaison et indicateurs de fonctionnalité. Les données de meta-data sont accessibles via PackageManager.getApplicationInfo().metaData à l'exécution. Par exemple, Firebase et Google Maps utilisent meta-data pour transmettre des clés d'accès sans les coder en dur dans le code source. Au lieu de cela, les clés sont définies dans le manifeste et peuvent différer selon les variantes de build.

L'attribut android:extractNativeLibs contrôle l'extraction des bibliothèques natives de l'APK. Pour les applications avec targetSdk 34+, cet attribut doit être explicitement spécifié, sinon la compilation peut échouer avec l'erreur INSTALL_FAILED_INVALID_APK. Si extractNativeLibs=false, les bibliothèques natives restent dans l'APK sans décompression, ce qui réduit la taille de l'application installée mais augmente le temps de chargement des bibliothèques. Pour la plupart des applications modernes, extractNativeLibs=false est recommandé pour réduire l'espace disque utilisé sur l'appareil de l'utilisateur.

L'attribut android:networkSecurityConfig permet de spécifier un fichier de configuration de sécurité réseau. Ceci est particulièrement important pour les applications avec targetSdk 28+, où le trafic HTTP est bloqué par défaut. Le fichier de configuration définit les certificats de confiance, les domaines pour les connexions HTTP et les règles de pinning de certificats. Cela remplace l'attribut obsolète android:usesCleartextTraffic et offre un mécanisme plus flexible pour gérer la sécurité des connexions au niveau du système d'exploitation.

L'attribut android:largeHeap demande une taille de heap augmentée pour l'application. Par défaut, Android alloue à chaque application une quantité limitée de mémoire qui dépend de l'appareil et de la version de l'OS. Si l'application travaille avec des images lourdes, des vidéos ou de grands ensembles de données, largeHeap peut éviter OutOfMemoryError. Cependant, abuser de cet attribut est nocif : une application avec une consommation mémoire élevée est arrêtée plus rapidement par le système en cas de faibles ressources. Utilisez largeHeap uniquement après profilage et confirmation du besoin.