Principes de base des applications

Les applications Android peuvent être écrites en Kotlin, le langage de programmation Java et les langages C++. Les SDK Tools pour Android compilent votre code, ainsi que tous les fichiers de données et de ressources, dans un APK ou un Android App Bundle.

Un package Android, qui est un fichier d'archive avec le suffixe .apk, contient le contenu d'une application Android requise au moment de l'exécution. C'est le fichier que les appareils Android utilisent pour installer l'application.

Un Android App Bundle, qui est un fichier d'archive avec le suffixe .aab, contient le contenu d'un projet d'application Android, y compris des métadonnées supplémentaires qui ne sont pas requises au moment de l'exécution. AAB est un format de publication et ne peut pas être installé sur les appareils Android. Cela retarde la génération et la signature de l'APK.

Par exemple, lors de la distribution de votre application via Google Play, ses serveurs génèrent des APK optimisés qui ne contiennent que les ressources et le code requis par l'appareil qui demande l'installation de l'application.

Chaque application Android se trouve dans son propre bac à sable de sécurité, protégé par les fonctionnalités de sécurité Android suivantes:

• Le système d'exploitation Android est un système Linux multi-utilisateur dans lequel chaque application est un utilisateur différent.
• Par défaut, le système attribue à chaque application un ID utilisateur Linux unique, utilisé uniquement par le système et inconnu de l'application. Le système définit des autorisations pour tous les fichiers d'une application afin que seul l'ID utilisateur attribué à cette application puisse y accéder.
• Chaque processus possède sa propre machine virtuelle (VM), de sorte que le code d'une application s'exécute indépendamment des autres applications.
• Par défaut, chaque application s'exécute dans son propre processus Linux. Le système Android lance le processus lorsque l'un des composants de l'application doit être exécuté, puis l'arrête lorsqu'il n'est plus nécessaire ou lorsque le système doit récupérer de la mémoire pour d'autres applications.

Le système Android applique le principe du moindre privilège. Autrement dit, chaque application n'a accès par défaut qu'aux composants dont elle a besoin pour effectuer son travail. Cela crée un environnement très sécurisé dans lequel une application ne peut pas accéder à certaines parties du système pour lesquelles elle n'est pas autorisée.

Toutefois, il existe plusieurs façons pour une application de partager des données avec d'autres applications et pour qu'une application accède aux services système:

• Vous pouvez faire en sorte que deux applications partagent le même ID utilisateur Linux, auquel cas elles peuvent accéder à leurs fichiers respectifs. Pour conserver les ressources système, les applications ayant le même ID utilisateur peuvent également s'exécuter dans le même processus Linux et partager la même VM. Elles doivent également être signées avec le même certificat.
• Une application peut demander l'autorisation d'accéder aux données d'un appareil, telles que sa position, son appareil photo et sa connexion Bluetooth. L'utilisateur doit accorder explicitement ces autorisations. Pour en savoir plus sur les autorisations, consultez la section Autorisations sur Android.

Le reste de ce document présente les concepts suivants:

• Principaux composants du framework qui définissent votre application.
• Fichier manifeste dans lequel vous déclarez les composants et les fonctionnalités d'appareil requises pour votre application.
• Ressources distinctes du code de l'application et permettant à celle-ci d'optimiser correctement son comportement pour diverses configurations d'appareil.

Composants de l'application

Les composants d'application sont les éléments de base d'une application Android. Chaque composant est un point d'entrée par lequel le système ou un utilisateur peut accéder à votre application. Certains composants dépendent d'autres.

Il existe quatre types de composants d'application:

• Activités
• Services
• Broadcast receivers
• Fournisseurs de contenu

Chaque type remplit un objectif distinct et possède un cycle de vie distinct qui définit la manière dont un composant est créé et détruit. Les sections suivantes décrivent les quatre types de composants d'application.

Activités

Une activité est le point d'entrée pour interagir avec l'utilisateur. Il représente un écran unique avec une interface utilisateur. Par exemple, une application de messagerie peut avoir une activité qui affiche une liste de nouveaux e-mails, une autre pour rédiger un e-mail et une autre pour lire les e-mails. Bien que les activités fonctionnent ensemble pour former une expérience utilisateur cohérente dans l'application de messagerie, elles sont indépendantes les unes des autres.

Une autre application peut démarrer l'une de ces activités si l'application de messagerie le permet. Par exemple, une application d'appareil photo peut lancer l'activité dans l'application de messagerie pour rédiger un nouvel e-mail afin de permettre à l'utilisateur de partager une photo.

Une activité facilite les interactions clés suivantes entre le système et l'application:

• Garder une trace de ce qui intéresse actuellement l'utilisateur (ce qui est affiché à l'écran) afin que le système continue d'exécuter le processus qui héberge l'activité.
• Identifier les processus précédemment utilisés qui contiennent des activités arrêtées auxquelles l'utilisateur peut revenir et prioriser ces processus pour qu'ils restent disponibles
• Aider l'application à gérer la fermeture de son processus afin que l'utilisateur puisse revenir aux activités avec son état précédent restauré.
• Fournir aux applications un moyen d'implémenter des flux utilisateur entre eux et au système de coordonner ces flux Le principal exemple de ceci est le partage.

Vous allez implémenter une activité en tant que sous-classe de la classe Activity. Pour plus d'informations sur la classe Activity, consultez Présentation des activités.

Services

Un service est un point d'entrée à usage général pour assurer l'exécution d'une application en arrière-plan pour toutes sortes de raisons. Il s'agit d'un composant qui s'exécute en arrière-plan pour effectuer des opérations de longue durée ou pour des processus distants. Un service ne fournit pas d'interface utilisateur.

Par exemple, un service peut lire de la musique en arrière-plan lorsque l'utilisateur se trouve dans une autre application, ou récupérer des données sur le réseau sans bloquer l'interaction de l'utilisateur avec une activité. Un autre composant, tel qu'une activité, peut démarrer le service et le laisser s'exécuter ou s'y associer pour interagir avec lui.

Il existe deux types de services qui indiquent au système comment gérer une application: les services démarrés et les services liés.

Les services démarrés indiquent au système de continuer à fonctionner jusqu'à la fin de l'opération. Il peut s'agir de synchroniser certaines données en arrière-plan ou de lire de la musique même lorsque l'utilisateur a quitté l'application. La synchronisation des données en arrière-plan ou la lecture de musique représentent différents types de services démarrés que le système gère différemment:

• L'utilisateur connaît directement la lecture de musique. L'application le communique au système en indiquant qu'elle souhaite être exécutée au premier plan et en informant l'utilisateur qu'elle est en cours d'exécution. Dans ce cas, le système donne la priorité à l'exécution du processus de ce service, car l'expérience utilisateur sera médiocre s'il disparaît.
• L'utilisateur n'est pas directement informé d'un service d'arrière-plan standard. Le système a donc plus de liberté dans la gestion de son processus. Il peut être arrêté, en redémarrant le service ultérieurement, s'il a besoin de RAM pour des éléments qui préoccupent davantage l'utilisateur.

Les services liés s'exécutent, car une autre application (ou le système) a indiqué vouloir l'utiliser. Un service lié fournit une API à un autre processus, et le système sait qu'il existe une dépendance entre ces processus. Ainsi, si le processus A est lié à un service du processus B, le système sait qu'il doit maintenir le processus B et son service en cours d'exécution pour A. En outre, si le processus A est quelque chose qui intéresse l'utilisateur, il sait qu'il doit traiter le processus B comme quelque chose dont l'utilisateur se soucie également.

En raison de leur flexibilité, les services sont des éléments de base utiles pour toutes sortes de concepts système de niveau supérieur. Les fonds d'écran animés, les écouteurs de notifications, les économiseurs d'écran, les modes de saisie, les services d'accessibilité et de nombreuses autres fonctionnalités système essentielles sont tous conçus en tant que services que les applications implémentent et auxquels le système se lie lorsqu'ils s'exécutent.

Un service est implémenté en tant que sous-classe de Service. Pour en savoir plus sur la classe Service, consultez la présentation des services.

Remarque:Si votre application cible Android 5.0 (niveau d'API 21) ou une version ultérieure, utilisez la classe JobScheduler pour planifier des actions. JobScheduler a l'avantage de préserver la batterie en planifiant de manière optimale les tâches afin de réduire la consommation d'énergie et en utilisant l'API Doze. Pour en savoir plus sur l'utilisation de cette classe, consultez la documentation de référence sur JobScheduler.

Broadcast receivers

Un broadcast receiver est un composant qui permet au système de fournir des événements à l'application en dehors d'un flux utilisateur standard afin que l'application puisse répondre aux annonces de diffusion à l'échelle du système. Étant donné que les broadcast receivers constituent une autre entrée bien définie dans l'application, le système peut diffuser des annonces, même aux applications qui ne sont pas en cours d'exécution.

Ainsi, par exemple, une application peut programmer une alarme pour publier une notification afin d'informer l'utilisateur d'un événement à venir. Étant donné que l'alarme est envoyée à un BroadcastReceiver dans l'application, celle-ci n'a pas besoin de s'exécuter jusqu'à ce que l'alarme se déclenche.

De nombreuses annonces proviennent du système, comme une annonce annonçant que l'écran est éteint, que la batterie est faible ou qu'une photo a été prise. Les applications peuvent également lancer des diffusions, par exemple pour informer d'autres applications que certaines données sont téléchargées sur l'appareil et peuvent être utilisées.

Bien que les broadcast receivers n'affichent pas d'interface utilisateur, ils peuvent créer une notification de barre d'état pour alerter l'utilisateur lorsqu'un événement de diffusion se produit. Le plus souvent, un broadcast receiver n'est qu'une simple passerelle vers d'autres composants et est destiné à effectuer très peu de travail.

Par exemple, un broadcast receiver peut programmer un JobService pour effectuer des tâches en fonction d'un événement à l'aide de JobScheduler. Les broadcast receivers impliquent souvent des applications qui interagissent les unes avec les autres. Il est donc important de connaître les implications de sécurité lors de leur configuration.

Un broadcast receiver est implémenté en tant que sous-classe de BroadcastReceiver, et chaque annonce est diffusée en tant qu'objet Intent. Pour en savoir plus, consultez la classe BroadcastReceiver.

Fournisseurs de contenu

Un fournisseur de contenu gère un ensemble partagé de données d'application que vous pouvez stocker dans le système de fichiers, dans une base de données SQLite, sur le Web ou sur tout autre emplacement de stockage persistant auquel votre application peut accéder. Via le fournisseur de contenu, d'autres applications peuvent interroger ou modifier les données, si le fournisseur de contenu le permet.

Par exemple, le système Android fournit un fournisseur de contenu qui gère les coordonnées de l'utilisateur. Toute application disposant des autorisations appropriées peut interroger le fournisseur de contenu, par exemple en utilisant ContactsContract.Data, pour lire et écrire des informations sur une personne spécifique.

Il est tentant de considérer un fournisseur de contenu comme une abstraction d'une base de données, car beaucoup d'API et d'assistance sont intégrées à ce cas courant. Cependant, leur objectif principal est différent du point de vue de la conception du système.

Pour le système, un fournisseur de contenu est un point d'entrée dans une application permettant de publier des éléments de données nommés, identifiés par un schéma d'URI. Ainsi, une application peut décider comment elle souhaite mapper les données qu'elle contient à un espace de noms d'URI, en transmettant ces URI à d'autres entités qui peuvent à leur tour les utiliser pour accéder aux données. Le système peut effectuer plusieurs actions pour gérer une application:

• L'attribution d'un URI n'exige pas que l'application reste en cours d'exécution. Les URI peuvent donc persister après la fermeture de l'application propriétaire. Le système doit simplement s'assurer qu'une application propriétaire est toujours en cours d'exécution lorsqu'il récupère les données de l'application à partir de l'URI correspondant.
• Ces URI fournissent également un modèle de sécurité très précis en termes de sécurité. Par exemple, une application peut placer l'URI d'une image figurant dans le presse-papiers, mais laisser son fournisseur de contenu verrouillé afin que les autres applications ne puissent pas y accéder librement. Lorsqu'une deuxième application tente d'accéder à cet URI dans le presse-papiers, le système peut l'autoriser à accéder aux données à l'aide d'une autorisation d'URI temporaire. Ainsi, elle n'accède qu'aux données qui se trouvent derrière cet URI, et à rien d'autre dans la deuxième application.

Les fournisseurs de contenu sont également utiles pour lire et écrire des données privées et non partagées avec votre application.

Un fournisseur de contenu est implémenté en tant que sous-classe de ContentProvider et doit implémenter un ensemble standard d'API permettant à d'autres applications d'effectuer des transactions. Pour en savoir plus, consultez le guide du développeur pour les fournisseurs de contenu.

Un aspect unique de la conception du système Android est que n'importe quelle application peut lancer le composant d'une autre application. Par exemple, si vous souhaitez que l'utilisateur prenne une photo avec l'appareil photo de l'appareil, il existe probablement une autre application qui effectue cette opération. Votre application peut l'utiliser au lieu de développer une activité pour prendre une photo vous-même. Vous n'avez pas besoin d'intégrer ni même de créer un lien vers le code de l'application Appareil photo. À la place, vous pouvez démarrer l'activité qui prend une photo dans l'application Appareil photo. Une fois l'opération terminée, la photo est même renvoyée à votre application afin que vous puissiez l'utiliser. Pour l'utilisateur, il semble que l'appareil photo fasse en fait partie de votre application.

Lorsque le système démarre un composant, il lance le processus de cette application (s'il n'est pas déjà en cours d'exécution) et instancie les classes nécessaires au composant. Par exemple, si votre application lance l'activité dans l'application d'appareil photo qui prend une photo, cette activité s'exécute dans le processus appartenant à l'application Appareil photo, et non dans le processus de votre application. Par conséquent, contrairement à la plupart des autres systèmes, les applications Android n'ont pas de point d'entrée unique: il n'y a pas de fonction main().

Étant donné que le système exécute chaque application dans un processus distinct avec des autorisations de fichiers qui limitent l'accès à d'autres applications, votre application ne peut pas activer directement un composant à partir d'une autre application. Toutefois, le système Android peut le faire. Pour activer un composant dans une autre application, vous transmettez au système un message qui spécifie votre intent pour démarrer un composant particulier. Le système active ensuite le composant pour vous.

Activer les composants

Un message asynchrone appelé intent active trois des quatre types de composants: les activités, les services et les broadcast receivers. Les intents associent des composants individuels au moment de l'exécution. Vous pouvez les considérer comme des messagers qui demandent une action à d'autres composants, qu'ils appartiennent à votre application ou à un autre.

Un intent est créé avec un objet Intent, qui définit un message pour activer un composant spécifique (intent explicite) ou un type de composant spécifique (intent implicite).

Pour les activités et les services, un intent définit l'action à effectuer, telle que l'affichage ou l'envoi, et peut spécifier l'URI des données à traiter, ainsi que d'autres éléments dont le composant en cours de démarrage a peut-être besoin.

Par exemple, un intent peut transmettre une demande d'activité visant à afficher une image ou à ouvrir une page Web. Dans certains cas, vous pouvez démarrer une activité pour recevoir un résultat, auquel cas l'activité renvoie également le résultat dans une Intent. Vous pouvez également émettre un intent pour permettre à l'utilisateur de choisir un contact personnel et de vous le renvoyer. L'intent de retour inclut un URI pointant vers le contact choisi.

Pour les broadcast receivers, l'intent définit l'annonce de diffusion. Par exemple, une annonce indiquant que la batterie de l'appareil est faible n'inclut qu'une chaîne d'action connue qui indique que la batterie est faible.

Contrairement aux activités, aux services et aux broadcast receivers, les fournisseurs de contenu sont activés lorsqu'ils sont ciblés par une requête provenant d'un ContentResolver. Le résolveur de contenu gère toutes les transactions directes avec le fournisseur de contenu, et le composant qui effectue des transactions avec le fournisseur appelle des méthodes sur l'objet ContentResolver. Pour des raisons de sécurité, cela laisse une couche d'abstraction entre le fournisseur de contenu et le composant demandant des informations.

Il existe des méthodes distinctes pour activer chaque type de composant:

• Vous pouvez démarrer une activité ou lui attribuer une nouvelle action en transmettant un Intent à startActivity() ou, lorsque vous souhaitez que l'activité renvoie un résultat, startActivityForResult().
• Sur Android 5.0 (niveau d'API 21) ou version ultérieure, vous pouvez utiliser la classe JobScheduler pour planifier des actions. Pour les versions antérieures d'Android, vous pouvez démarrer un service ou fournir de nouvelles instructions à un service en cours en transmettant un Intent à startService(). Vous pouvez établir une liaison avec le service en transmettant un Intent à bindService().
• Vous pouvez lancer une diffusion en transmettant un Intent à des méthodes telles que sendBroadcast() ou sendOrderedBroadcast().
• Vous pouvez envoyer une requête à un fournisseur de contenu en appelant query() au niveau d'un ContentResolver.

Pour en savoir plus sur l'utilisation des intents, consultez le document Intents et filtres d'intent. Les documents suivants fournissent plus d'informations sur l'activation de composants spécifiques : Présentation des activités, Présentation des services, BroadcastReceiver et Fournisseurs de contenu.

Fichier manifeste

Pour que le système Android puisse démarrer un composant d'application, il doit savoir que ce composant existe en lisant le fichier manifeste de l'application, AndroidManifest.xml. Votre application déclare tous ses composants dans ce fichier, qui se trouve à la racine du répertoire du projet de l'application.

Le fichier manifeste effectue un certain nombre d'actions en plus des composants de l'application, par exemple:

• Identifie toutes les autorisations de l'utilisateur requises par l'application, telles que l'accès à Internet ou l'accès en lecture aux contacts de l'utilisateur.
• Déclare le niveau d'API minimal requis par l'application, en fonction des API qu'elle utilise.
• Déclare les fonctionnalités matérielles et logicielles utilisées ou requises par l'application, telles qu'un appareil photo, des services Bluetooth ou un écran multipoint.
• Déclare les bibliothèques d'API auxquelles l'application doit être associée (autres que les API du framework Android), telles que la bibliothèque Google Maps.

Déclarer des composants

La tâche principale du fichier manifeste consiste à informer le système sur les composants de l'application. Par exemple, un fichier manifeste peut déclarer une activité comme suit:

<?xml version="1.0" encoding="utf-8"?>
<manifest ... >
    <application android:icon="@drawable/app_icon.png" ... >
        <activity android:name="com.example.project.ExampleActivity"
                  android:label="@string/example_label" ... >
        </activity>
        ...
    </application>
</manifest>

Dans l'élément <application>, l'attribut android:icon pointe vers les ressources pour une icône qui identifie l'application.

Dans l'élément <activity>, l'attribut android:name spécifie le nom de classe complet de la sous-classe Activity, et l'attribut android:label spécifie une chaîne à utiliser comme libellé visible par l'utilisateur pour l'activité.

Vous devez déclarer tous les composants d'application à l'aide des éléments suivants:

• Éléments <activity> pour les activités
• Éléments <service> pour les services
• Éléments <receiver> pour les broadcast receivers
• Éléments <provider> pour les fournisseurs de contenu

Les activités, les services et les fournisseurs de contenu que vous incluez dans votre source, mais que vous ne déclarez pas dans le fichier manifeste ne sont pas visibles par le système et, par conséquent, ne peuvent jamais s'exécuter. Toutefois, les broadcast receivers peuvent être déclarés dans le fichier manifeste ou créés dynamiquement dans le code en tant qu'objets BroadcastReceiver et enregistrés auprès du système en appelant registerReceiver().

Pour découvrir comment structurer le fichier manifeste de votre application, consultez Présentation du fichier manifeste d'application.

Déclarer les capacités des composants

Comme indiqué dans la section Activer les composants, vous pouvez utiliser un Intent pour démarrer des activités, des services et des broadcast receivers. Pour ce faire, nommez explicitement le composant cible dans l'intent à l'aide du nom de la classe du composant. Vous pouvez également utiliser un intent implicite, qui décrit le type d'action à effectuer et, éventuellement, les données sur lesquelles vous souhaitez effectuer l'action. Un intent implicite permet au système de trouver sur l'appareil un composant pouvant effectuer l'action et la démarrer. Si plusieurs composants peuvent effectuer l'action décrite par l'intent, l'utilisateur sélectionne celui à utiliser.

Attention:Si vous utilisez un intent pour démarrer un Service, assurez-vous que votre application est sécurisée à l'aide d'un intent explicite. L'utilisation d'un intent implicite pour démarrer un service représente un risque de sécurité, car vous ne pouvez pas savoir avec certitude quel service répond à l'intent et l'utilisateur ne peut pas voir quel service démarre. À partir d'Android 5.0 (niveau d'API 21), le système génère une exception si vous appelez bindService() avec un intent implicite. Ne déclarez pas de filtres d'intent pour vos services.

Le système identifie les composants qui peuvent répondre à un intent en comparant l'intent reçu aux filtres d'intent fournis dans le fichier manifeste d'autres applications sur l'appareil.

Lorsque vous déclarez une activité dans le fichier manifeste de votre application, vous pouvez éventuellement inclure des filtres d'intent qui déclarent les fonctionnalités de l'activité afin qu'elle puisse répondre aux intents d'autres applications. Pour ce faire, ajoutez un élément <intent-filter> en tant qu'enfant de l'élément de déclaration du composant.

Par exemple, si vous créez une application de messagerie avec une activité permettant de rédiger un nouvel e-mail, vous pouvez déclarer un filtre d'intent pour répondre aux intents "Envoyer" afin d'envoyer un nouvel e-mail, comme illustré dans l'exemple suivant:

<manifest ... >
    ...
    <application ... >
        <activity android:name="com.example.project.ComposeEmailActivity">
            <intent-filter>
                <action android:name="android.intent.action.SEND" />
                <data android:type="*/*" />
                <category android:name="android.intent.category.DEFAULT" />
            </intent-filter>
        </activity>
    </application>
</manifest>

Si une autre application crée un intent avec l'action ACTION_SEND et le transmet à startActivity(), le système peut lancer votre activité afin que l'utilisateur puisse rédiger et envoyer un e-mail.

Pour en savoir plus sur la création de filtres d'intent, consultez le document Intents et filtres d'intents.

Déclarer les exigences de l'application

De nombreux appareils fonctionnant sous Android ne disposent pas tous des mêmes fonctionnalités. Pour empêcher l'installation de votre application sur des appareils qui ne disposent pas des fonctionnalités dont elle a besoin, vous devez définir clairement un profil pour les types d'appareils compatibles en déclarant les exigences liées aux appareils et aux logiciels dans votre fichier manifeste.

La plupart de ces déclarations ne sont fournies qu'à titre indicatif. Le système ne les lit pas, mais des services externes tels que Google Play les lisent afin de permettre aux utilisateurs de filtrer les applications lorsqu'ils recherchent des applications depuis leur appareil.

Par exemple, supposons que votre application nécessite un appareil photo et utilise les API introduites dans Android 8.0 (niveau d'API 26). Vous devez déclarer ces exigences. Les valeurs de minSdkVersion et targetSdkVersion sont définies dans le fichier build.gradle de votre module d'application:

android {
  ...
  defaultConfig {
    ...
    minSdkVersion 26
    targetSdkVersion 29
  }
}

Remarque:Ne définissez pas minSdkVersion et targetSdkVersion directement dans le fichier manifeste, car ils sont écrasés par Gradle lors du processus de compilation. Pour en savoir plus, consultez Spécifier les exigences du niveau d'API.

Vous déclarez la fonctionnalité d'appareil photo dans le fichier manifeste de votre application:

<manifest ... >
    <uses-feature android:name="android.hardware.camera.any"
                  android:required="true" />
    ...
</manifest>

Avec les déclarations présentées dans ces exemples, les appareils qui ne sont pas équipés d'une caméra ou dont la version d'Android est antérieure à la version 8.0 ne peuvent pas installer votre application depuis Google Play. Cependant, vous pouvez également déclarer que votre application utilise l'appareil photo, mais qu'il n'en a besoin pas. Pour ce faire, définissez l'attribut required sur false, vérifiez si l'appareil est équipé d'une caméra au moment de l'exécution et désactivez ses fonctionnalités si nécessaire.

Pour en savoir plus sur la gestion de la compatibilité de votre application avec différents appareils, consultez la Présentation de la compatibilité des appareils.

Ressources d'une application

Une application Android ne se résume pas à du code. Elle nécessite des ressources distinctes du code source, telles que des images, des fichiers audio et tout ce qui concerne la présentation visuelle de l'application. Par exemple, vous pouvez définir des animations, des menus, des styles, des couleurs et la mise en page des interfaces utilisateur de l'activité à l'aide de fichiers XML.

L'utilisation de ressources d'application permet de mettre à jour facilement diverses caractéristiques de votre application sans modifier le code. Fournir des ensembles de ressources alternatives vous permet d'optimiser votre application pour diverses configurations d'appareil, telles que différentes langues et tailles d'écran.

Pour chaque ressource que vous incluez dans votre projet Android, les SDK Build Tools définissent un ID entier unique, que vous pouvez utiliser pour référencer la ressource à partir du code de votre application ou d'autres ressources définies en XML. Par exemple, si votre application contient un fichier image nommé logo.png (enregistré dans le répertoire res/drawable/), les SDK Tools génèrent un ID de ressource nommé R.drawable.logo. Cet ID correspond à un entier spécifique à l'application, que vous pouvez utiliser pour référencer l'image et l'insérer dans votre interface utilisateur.

L'un des aspects les plus importants de la fourniture de ressources distinctes de votre code source est la possibilité de fournir d'autres ressources pour différentes configurations d'appareil.

Par exemple, en définissant des chaînes d'interface utilisateur en XML, vous pouvez les traduire dans d'autres langues et les enregistrer dans des fichiers distincts. Android applique ensuite les chaînes de langue appropriées à votre interface utilisateur en fonction d'un qualificatif de langue que vous ajoutez au nom du répertoire de ressources, tel que res/values-fr/ pour les valeurs de chaîne en français, et le paramètre de langue de l'utilisateur.

Android accepte de nombreux qualificatifs pour vos autres ressources. Le qualificatif est une chaîne courte que vous incluez dans le nom de vos répertoires de ressources afin de définir la configuration de l'appareil pour laquelle ces ressources sont utilisées.

Par exemple, vous pouvez créer différentes mises en page pour vos activités en fonction de l'orientation et de la taille de l'écran de l'appareil. Lorsque l'écran de l'appareil est en mode portrait (haut), vous pouvez utiliser une mise en page avec des boutons disposés verticalement, mais lorsque l'écran est en mode paysage (large), vous pouvez aligner les boutons horizontalement. Pour modifier la mise en page en fonction de l'orientation, vous pouvez définir deux mises en page et appliquer le qualificatif approprié au nom de répertoire de chaque mise en page. Ensuite, le système applique automatiquement la mise en page appropriée en fonction de l'orientation actuelle de l'appareil.

Pour en savoir plus sur les différents types de ressources que vous pouvez inclure dans votre application et sur la création d'autres ressources pour différentes configurations d'appareil, consultez la présentation des ressources de l'application. Pour en savoir plus sur les bonnes pratiques et la conception d'applications robustes et de qualité en production, consultez le guide de l'architecture des applications.

Ressources supplémentaires

Pour apprendre le développement Android à l'aide de vidéos et de tutoriels de code, consultez le cours Udacity Développer des applications Android avec Kotlin.