Présentation Du Manifest Android

Chaque projet Android comprend un fichier manifeste, AndroidManifest.xml. Dans Android Studio, vous pouvez accéder au manifeste de l'application à partir du dossier app / manifestests.

Le manifeste définit la structure et les métadonnées de votre application, ses composants et ses exigences.Votre manifeste comprend des nœuds pour chacune des activités, services, fournisseurs de contenu et récepteurs de diffusion qui composent votre application et, à l'aide des filtres d'intention et des autorisations, déterminez la manière dont ils interagissent entre eux et avec d'autres applications. Le manifeste est constitué d’une balise racine manifeste avec un attribut de package défini sur le nom unique du package du projet. Il devrait également inclure un attribut xmlns: android qui fournit plusieurs attributs système requis dans le fichier.L'extrait de code XML suivant illustre un nœud racine de manifeste:

< manifest xmlns:android="http://schemas.android.com/apk/res/android"           package="com.professionalandroid.apps.helloworld" >

  [ ... manifest nodes ... ]

< /manifest >

Le manifeste spécifie les métadonnées de l'application (telles que son icône et son thème) dans le nœud d'application de niveau supérieur. Des nœuds de niveau supérieur supplémentaires peuvent spécifier les autorisations requises, les tests unitaires et les exigences en matière de matériel, d'écran ou de plate-forme (comme décrit dans la section suivante).La liste suivante récapitule certaines des balises de sous-nœud manifestes et fournit un extrait de code XML illustrant l'utilisation de chaque balise: 

• utilise-feature : Android est disponible sur une grande variété de plates-formes matérielles. Vous pouvez utiliser des nœuds uses-feature pour spécifier les fonctionnalités matérielles et logicielles requises par votre application pour fonctionner correctement.Notez que cela empêchera votre application d'être installée sur un périphérique qui n'inclut pas une fonctionnalité spécifiée, telle qu'un matériel NFC dans le fragment de code suivant:

< uses-feature android:name="android.hardware.nfc" / >

Utilisez ce nœud uniquement si vous souhaitez empêcher l’installation de votre application sur des périphériques n’incluant pas certaines fonctionnalités. Actuellement, les fonctionnalités requises prises en charge incluent les catégories suivantes:

• Audio : pour les applications nécessitant un pipeline audio à faible latence ou de niveau professionnel, ou nécessitant une entrée microphone. 
• Bluetooth : lorsqu'une radio Bluetooth ou BTLE est requise.Caméra: pour les applications nécessitant une caméra. Vous pouvez également exiger (ou définir en option) la prise en charge frontale ou arrière, la mise au point automatique, le post-traitement manuel, le capteur manuel, le flash ou le support RAW.
• Device Hardware UI (Interface utilisateur matérielle du périphérique) : l'application est conçue pour une interface utilisateur de périphérique spécifique: automobile ou montre, par exemple.Empreinte digitale - Nécessite un matériel biométrique capable de lire les empreintes digitales.Gamepad: pour les jeux (ou les applications) nécessitant une entrée du contrôleur de jeu, à partir de l'appareil lui-même ou d'un gamepad connecté.Infrared (Infrarouge): indique une fonctionnalité infrarouge (IR) requise (généralement pour communiquer avec d'autres périphériques IR grand public). 
• Location— Si vous avez besoin de services basés sur la localisation. Vous pouvez également spécifier explicitement le support réseau ou GPS.
• NFC— Nécessite le support NFC (Near-Field Communications).
• OpenGL ES hardware— L’application nécessite l’extension OpenGL ES Android Pack installée sur le périphérique.
• Sensors— Vous permet de spécifier une exigence pour tous les capteurs matériels potentiellement disponibles, notamment un accéléromètre, un baromètre, une boussole, un gyroscope, des capteurs permettant de détecter la température ambiante, la fréquence cardiaque, la lumière, la proximité, l'humidité, ainsi qu'un compteur et un détecteur de pas.
• Telephony— Pour spécifier que la téléphonie en général ou une radio téléphonique spécifique (GSM ou CDMA) est requise.
• Touchscreen— Pour spécifier le type d’écran tactile requis par votre application, y compris le nombre de contacts d’entrée distincts pouvant être détectés et suivis.
• USB— Pour les applications nécessitant la prise en charge du mode hôte USB ou accessoire
• Wi-Fi— Où le support de réseau Wi-Fi est requis
• Communication software— L'application nécessite la prise en charge de services SIP (Session Initiation Protocol) ou de services VoIP (Voice Over Internet Protocol).
• Device management software— Utilisez ces fonctionnalités logicielles facultatives pour spécifier que votre application requiert la prise en charge des périphériques, notamment le service de sauvegarde, l'application des stratégies de périphérique, les utilisateurs gérés, la suppression d'utilisateurs et le démarrage vérifié.
• Media software— Si votre application nécessite la prise en charge MIDI, l'impression, une interface utilisateur «maigre» (télévision), la télévision en direct ou l'écran d'accueil.

La variété de plates-formes sur lesquelles Android est disponible augmente, tout comme le matériel et les logiciels en option. Vous pouvez trouver une liste complète du matériel à fonctionnalités multiples à l'adresse developer.android.com/guide/topics/manifest/uses-feature-element .html#features-reference. 

Pour garantir la compatibilité, spécifier l'exigence de certaines autorisations implique une exigence de fonctionnalité. En particulier, demander la permission d'accéder à Bluetooth, à la caméra, à l'une des autorisations du service de localisation, à l'enregistrement audio, au Wi-Fi et aux autorisations liées à la téléphonie implique la fonctionnalité matérielle correspondante. Vous pouvez remplacer ces exigences implicites en ajoutant un attribut requis et en le définissant sur false. Par exemple, une application de prise de notes qui prend en charge (mais ne nécessite pas) l'enregistrement d'une note audio peut choisir de rendre le matériel du microphone facultatif:

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

Le matériel de la caméra représente également un cas particulier. Pour des raisons de compatibilité, demander l'autorisation d'utiliser l'appareil photo ou ajouter un nœud Usages-fonctionnalité le nécessitant implique que la caméra prenne en charge la mise au point automatique. Vous pouvez le spécifier aussi facultatif que nécessaire:

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

< uses-feature android:name="android.hardware.camera.autofocus"

              android:required="false" />

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

• supports-screens— Avec la prolifération de centaines de tailles d'écran, résolutions et densités différentes et l'introduction du mode multi-fenêtres, vous devez créer des conceptions d'interface utilisateur réactives pour votre application offrant une bonne expérience à tous les utilisateurs. Bien qu'il soit techniquement possible d'utiliser le nœud supports-screen pour limiter la disponibilité de votre application à un sous-ensemble de résolutions d'écran prises en charge, cela est considéré comme une mauvaise pratique et doit être évité.
• supports-gl-texture— Indique que l'application est capable de fournir des actifs de texture compressés à l'aide d'un format de compression de texture GL particulier. Vous devez utiliser plusieurs éléments supports-gl-texture si votre application est capable de prendre en charge plusieurs formats de compression de texture. Vous pouvez trouver la liste la plus récente des valeurs de format de compression de texture GL prises en charge à l'adresse

 developer.android.com/guide/topics/manifest/ supports-gl-texture-element.html.

< supports-gl-texture android:name="GL_OES_compressed_ETC1_RGB8_texture" / >

• uses-permission— Dans le cadre du modèle de sécurité, les balises uses-permission déclarent les autorisations utilisateur requises par votre application. Chaque autorisation que vous spécifiez sera présentée à l'utilisateur avant l'installation de l'application (sur les appareils fonctionnant sous Android 5.1 ou version antérieure) ou pendant son exécution (sur les appareils exécutant Android 6.0 et versions ultérieures). Des autorisations sont requises pour de nombreux appels de méthodes et d'API, généralement ceux associés à un coût ou à une implication en matière de sécurité (tels que la numérotation, la réception de SMS ou l'utilisation de services basés sur la localisation). Nous les présentons dans le reste de ce livre, au besoin.

< uses-permission android:name="android.permission.ACCESS_FINE_LOCATION"/ >

• permission— Vos composants d'application partagés peuvent également créer des autorisations pour en restreindre l'accès à partir d'autres composants d'application. Vous pouvez utiliser les autorisations de plate-forme existantes à cet effet ou définir vos propres autorisations dans le manifeste. Pour ce faire, utilisez la balise permission pour créer une définition de permission.Vous pouvez spécifier le niveau d'accès des autorisations d'accès (normal, dangereux, signature, signatureOrSystem), une étiquette et une ressource externe contenant la description qui explique les risques liés à l'octroi de l'autorisation spécifiée. Pour plus d'informations sur la création et l'utilisation de vos propres autorisations, reportez-vous au Chapitre 20, "Développement Android avancé".

< permission android:name="com.professionalandroid.perm.DETONATE_DEVICE"

            android:protectionLevel="dangerous"             android:label="Self Destruct"

            android:description="@string/detonate_description">

< /permission >

•  application—Un manifeste ne peut contenir qu'un seul nœud d'application. Il utilise des attributs pour spécifier les métadonnées de votre application, notamment son nom, son icône et son thème. Vous pouvez également indiquer si vous autorisez la sauvegarde automatique des données à l'aide d'Android Auto Backup (comme décrit au chapitre 8) et si vous prenez en charge les dispositions d'interface utilisateur de droite à gauche.

Si vous utilisez une classe d'application personnalisée, vous devez la spécifier ici à l'aide de l'attribut android: name.  Le nœud d'application fait également office de conteneur pour les nœuds d'activité, de service, de fournisseur de contenu et de récepteur de diffusion qui spécifient les composants de l'application.

< application

  android:label="@string/app_name"   android:icon="@mipmap/ic_launcher"   android:theme="@style/AppTheme"   android:allowBackup="true"   android:supportsRtl="true"   android:name=".MyApplicationClass">

  [ ... application component nodes ... ]

< /application >

• activity: une balise d'activité est requise pour chaque activité de votre application. Utilisez l'attribut android: name pour indiquer le nom de la classe d'activité. Vous devez inclure l'activité de lancement principale et toute autre activité pouvant être affichée. Tenter de démarrer une activité qui n’est pas incluse dans le manifeste lève une exception d’exécution. Chaque nœud d’activité prend en charge les balises enfant d’intention-filter qui définissent les intentions pouvant être utilisées pour démarrer l’activité.Notez qu’un point est utilisé comme raccourci pour le nom du package de l’application lors de la spécification du nom de classe de l’Activité: 

< activity android:name=".MyActivity" >

  <intent-filter>

    <action android:name="android.intent.action.MAIN" />

    <category android:name="android.intent.category.LAUNCHER" />

  </intent-filter>

< /activity >

            < receiver android:name=".MyIntentReceiver" >

< /receiver >

 Remarque L'Assistant Nouveau projet Android Studio crée automatiquement un nouveau fichier manifeste lorsqu'il crée un nouveau projet.