Principes de base des applications

Les applications Android peuvent être écrites en Kotlin, le langage de programmation Java, et en C++. Android SDK Tools compile 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 requis au moment de l'exécution, c'est-à-dire le fichier utilisé par Android appareils 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 certaines métadonnées supplémentaires qui ne sont pas requises dans de l'environnement d'exécution. AAB est un format de publication qui ne peut pas être installé sur les appareils Android. Il reporte la génération et la signature de l'APK à un stade ultérieur.

Lorsque vous distribuez votre application via Google Play, par exemple, les serveurs Google Play génèrent des APK optimisés contenant uniquement les ressources et requis par l'appareil qui demande l'installation de l'application.

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

• Android est un système Linux multi-utilisateur dans lequel chaque application un autre utilisateur.
• Par défaut, le système attribue à chaque application un ID utilisateur Linux unique, utilisé uniquement par le système et est inconnu pour l’application. Le système définit les autorisations pour tous les fichiers d'une application afin que seul l'identifiant 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 d'autres applications.
• Par défaut, chaque application s'exécute dans son propre processus Linux. Le système Android démarre le processus lorsqu'un des composants de l'application doivent être exécutés, puis arrêté le processus lorsqu'il n'est plus 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. En d'autres termes, Par défaut, chaque application n'a accès qu'aux composants dont elle a besoin pour travailler et pas plus. Cela crée un environnement très sécurisé dans lequel une application ne peut pas accéder à certaines parties le système pour lequel il n'a pas d'autorisation.

Toutefois, une application peut partager des données avec d'autres applications pour accéder aux services système:

• Il est possible de faire en sorte que deux applications partagent le même identifiant utilisateur Linux, auquel cas. ils peuvent accéder aux fichiers des autres. Pour préserver les ressources système, les applications associées au même ID utilisateur peut aussi s'exécuter dans le même processus Linux et partager la même VM. La les applications doivent également être signées avec le même certificat.
• Une application peut demander l'autorisation d'accéder aux données de l'appareil, telles que position, appareil photo et connexion Bluetooth. L'utilisateur a pour accorder explicitement ces autorisations. Pour en savoir plus sur les autorisations, consultez 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 l'appareil requis pour votre l'application.
• Ressources distinctes du code de l'application et permettant à celle-ci optimiser de façon optimale son comportement pour diverses configurations d'appareils.

Composants de l'application

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

Il existe quatre types de composants d'application:

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

Chaque type a un objectif spécifique et a un cycle de vie distinct qui définit comment 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 des interactions avec l'utilisateur. Elle représente une seule avec une interface utilisateur. Par exemple : une application de messagerie peut avoir une activité affichant une liste les e-mails, la rédaction d'un e-mail et la lecture des e-mails. Bien que les activités s'associent pour former une expérience utilisateur cohérente dans l'application de messagerie, chacune est indépendante des autres.

Une autre application peut lancer n'importe laquelle activités si l'application de messagerie le permet. Par exemple, une application d'appareil photo peut lancer activité dans l'application de messagerie pour rédiger un nouvel e-mail permettant à 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 l'utilisateur (ce qui est affiché à l'écran) afin que système continue d’exécuter le processus qui héberge l’activité.
• Savoir quels processus précédemment utilisés contiennent des activités arrêtées auxquelles l'utilisateur pourrait revenir et en donnant la priorité à ces processus pour qu'ils restent disponibles.
• Aider l'application à gérer l'arrêt de son processus afin que l'utilisateur puisse revenir aux activités dont l'état précédent est restauré.
• Permet aux applications d'implémenter des flux utilisateur entre elles et au système de coordonner ces flux. Le principal exemple de ceci est le partage.

Vous implémentez une activité en tant que sous-classe de la classe Activity. Pour plus 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 permettant à une application de s'exécuter en arrière-plan pour toutes sortes de raisons. Il s'agit d'un composant qui s'exécute en arrière-plan pour exécuter des opérations ou pour effectuer des tâches pour des processus à distance. Un service ne fournit pas d'interface utilisateur.

Pour Par exemple, un service peut lire de la musique en arrière-plan lorsque l'utilisateur utilise une autre application ; ou il peut récupérer des données sur le réseau sans bloquer l’interaction de l’utilisateur avec une activité. Autre tel qu'une activité, peut démarrer le service et le laisser s'exécuter ou s'y associer interagissent avec elle.

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

Les services démarrés indiquent au système de les maintenir en exécution jusqu'à ce que leur travail soit terminé. Il peut s'agir de synchroniser certaines données en arrière-plan ou de lire de la musique même lorsque l'utilisateur quitte l'application. La synchronisation de données en arrière-plan ou la lecture de musique représentent différents types de démarrages. que le système gère différemment:

• L'utilisateur connaît directement la lecture de musique et l'application le communique à le système en indiquant qu'il souhaite être au premier plan, avec une notification pour indiquer à l'utilisateur qu'il est exécuté. Dans ce cas, le système donne la priorité au maintien processus en cours d'exécution, car l'utilisateur a une mauvaise expérience s'il disparaît.
• L'utilisateur n'a pas directement connaissance d'un service d'arrière-plan standard. le système a plus de liberté dans la gestion de son processus. Il pourrait le laisser tuer, redémarrer le service un peu plus tard, s'il a besoin de RAM pour des choses plus de se préoccuper immédiatement de l’utilisateur.

Les services liés s'exécutent, car une autre application (ou le système) a indiqué vouloir utiliser la Google Cloud. 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 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, alors il sait qu'il doit traiter le processus B comme quelque chose l’utilisateur se préoccupe également.

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

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 dispose du rôle d'économiser 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 JobScheduler documentation de référence.

Broadcast receivers

Un broadcast receiver est un composant qui permet au système de diffuser des événements Application en dehors d'un flux utilisateur standard afin qu'elle puisse répondre à la diffusion à l'échelle du système annonces. Comme les broadcast receivers constituent une autre entrée bien définie dans l'application, le système peut diffuser des annonces même à des 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. Comme l'alarme est envoyée à un BroadcastReceiver dans l'application, il n'est pas nécessaire que l'application 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, la batterie est faible ou une photo est prise. Les applications peuvent également lancer des diffusions, par exemple pour indiquer à d'autres applications que certaines données sont téléchargées sur l'appareil et peuvent être utilisées.

Bien que la diffusion n'affichent pas d'interface utilisateur, ils peuvent créer une notification dans la barre d'état pour alerter l'utilisateur lorsqu'un événement de diffusion se produit. Le plus souvent, un broadcast receiver est Il s'agit d'une simple passerelle pour d'autres composants. Il est conçu pour effectuer très peu de tâches.

Par exemple, un broadcast receiver peut programmer un JobService pour qu'il effectue une tâche en fonction sur un événement à l'aide de JobScheduler. Les broadcast receivers impliquent souvent que les applications interagissent entre elles. Il est donc important de connaître sur la sécurité lors de leur configuration.

Un broadcast receiver est implémenté en tant que sous-classe de BroadcastReceiver, et chaque diffusion est transmise en tant qu'objet Intent. Pour plus d'informations, 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 dans tout autre espace de stockage persistant lieu où se trouve l'application peut accéder. Par l'intermédiaire du fournisseur de contenu, d'autres applis peuvent interroger ou modifier les données, si le fournisseur de contenu le permet.

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

Il peut être tentant de considérer un fournisseur de contenu comme une abstraction d'une base de données, car il existe de nombreuses API et de l'assistance intégrée pour ce cas courant. Toutefois, leur fonctionnement est différent l'objectif principal 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 de la manière dont elle souhaite mapper les données qu'elle contient à un espace de noms URI, en distribuant ces URI à d'autres entités qui peuvent à leur tour les utiliser pour accéder données. Cela permet au système de gérer une application de plusieurs façons:

• L'attribution d'un URI ne nécessite pas que l'application reste en cours d'exécution. Les URI peuvent donc persister après leur qui sont propriétaires de l'application. Le système doit seulement s'assurer qu'une application propriétaire est toujours en cours d'exécution lorsqu'elle récupère les données de l'application à partir de l'URI correspondant.
• Ces URI fournissent également un important modèle de sécurité précis. Par exemple, un L'application peut placer l'URI d'une image qu'elle contient dans le presse-papiers, mais conserver son contenu le fournisseur est verrouillé afin que d'autres applications ne puissent pas y accéder librement. Lorsqu'une deuxième application tente pour accéder à cet URI dans le presse-papiers, le système peut autoriser l'application accéder aux données à l'aide d'une autorisation d'URI temporaire. afin qu'il n'accède qu'aux données se trouvant 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.

Un fournisseur de contenu est implémenté en tant que sous-classe de ContentProvider. et doivent implémenter un ensemble standard d'API permettant à d'autres applications des transactions. Pour en savoir plus, consultez la page consacrée aux fournisseurs de contenu pour les développeurs. .

Un aspect unique de la conception du système Android est que toute application peut démarrer une autre composant de l'application. Par exemple, si vous souhaitez que l'utilisateur capture avec l'appareil photo de votre appareil, il existe probablement une autre application qui fait cela, et votre peut l'utiliser au lieu de développer une activité pour prendre une photo vous-même. Vous ne devez pas devez intégrer ou même créer un lien vers le code de l'application Appareil photo. À la place, vous pouvez démarrer l'activité dans l'application Appareil photo qui capture une 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 fait partie de votre application.

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

Comme le système exécute chaque application dans un processus distinct avec des autorisations de fichiers qui restreindre l'accès à d'autres applications, votre application ne peut pas activer directement un composant depuis 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 spécifiant votre intent 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 les uns aux autres au moment de l'exécution. On peut les penser à que les messagers qui demandent une action à partir d'autres composants, qu'ils appartiennent ou non à votre application ou à une 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, par exemple view ou send quelque chose et spécifier l'URI des données sur lesquelles agir, entre autres éléments que le un composant en cours de démarrage.

Par exemple, un intent peut transmettre une requête pour afficher une image ou ouvrir une page Web. Dans certains cas, vous pouvez activité pour recevoir un résultat, auquel cas l'activité renvoie également le résultat en Intent. Vous pouvez également émettre un intent l'utilisateur choisira un contact personnel et le renverra à vous. L'intent de retour inclut URI pointant vers le contact choisi.

Pour les broadcast receivers, l'intent définit annonce. Par exemple, une annonce pour indiquer 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 activé lorsqu'il est ciblé par une requête provenant d'un ContentResolver. Le contenu le résolveur gère toutes les transactions directes avec le fournisseur de contenu, et le composant des transactions avec le fournisseur appelle des méthodes sur le ContentResolver. Pour des raisons de sécurité, cela laisse une couche d'abstraction entre le fournisseur de contenu et le composant qui demande des informations.

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

• Vous pouvez démarrer une activité ou lui proposer quelque chose de nouveau en en transmettant un Intent à startActivity() ou, lorsque vous voulez 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 un service ou donner de nouvelles instructions à un service en cours en en transmettant un Intent à startService(). Vous pouvez créer une liaison au 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() sur un ContentResolver.

Pour en savoir plus sur l'utilisation des intents, consultez la section Intents 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.

Le fichier manifeste

Avant que le système Android puisse démarrer un composant d'application, il doit savoir que le 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 de le répertoire de projet de l'application.

Le fichier manifeste fait un certain nombre de choses en plus de déclarer les composants de l'application, par exemple:

• Identifie les autorisations de l'utilisateur requises par l'application, telles que l'accès à Internet ou un accès en lecture aux contacts de l'utilisateur.
• Déclare la valeur minimale Niveau d'API requises 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, les services Bluetooth ou un écran multipoint.
• Déclare les bibliothèques d'API avec lesquelles l'application doit être associée (autres que le framework Android API), telles que le bibliothèque Google Maps.

Déclarer les composants

La tâche principale du fichier manifeste consiste à informer le système des composants de l'application. Pour 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 le <application> , l'attribut android:icon pointe vers les ressources associées à une icône qui identifie l'élément l'application.

Dans l'élément <activity>, L'attribut android:name spécifie le nom de classe complet du 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:

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

Activités, services et fournisseurs de contenu que vous incluez dans votre source sans les déclarer dans le fichier manifeste ne sont pas visibles par le système et, par conséquent, ne peuvent jamais s'exécuter. Toutefois, annoncer Les récepteurs peuvent être déclarés dans le fichier manifeste ou créés dynamiquement dans le code BroadcastReceiver et enregistrés auprès du système en appelant registerReceiver()

Pour savoir comment structurer le fichier manifeste de votre application, consultez la présentation des fichiers manifestes d'application.

Déclarer les fonctionnalité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 À faire en nommant explicitement le composant cible, en utilisant le nom de la classe du composant, dans l'intent. Vous pouvez également utiliser un intent implicite, décrit le type d'action à effectuer et, éventuellement, les données que vous souhaitez effectuer l'action. Un intent implicite permet au système de trouver un composant sur l'appareil capable d'effectuer l'opération l'action et le démarrer. Si plusieurs composants peuvent effectuer l'action décrite par le l'utilisateur choisit celle à 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 explicite l'intention. L'utilisation d'un intent implicite pour démarrer un service car vous ne pouvez pas savoir 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 les intent reçu vers les 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 capacités de l'activité afin qu'elle puisse répondre aux intents à partir d'autres applications. Pour ce faire, vous devez en ajoutant 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 à "send" ; des intents pour 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 e-mail.

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

Déclarer des exigences concernant les applications

De nombreux appareils fonctionnent sous Android, mais ils ne fournissent pas tous les mêmes fonctionnalités et capacités. Pour empêcher l'installation de votre application sur des appareils n'offrant pas les fonctionnalités requises par votre application, vous devez définir clairement un profil les types d'appareils compatibles avec votre application en déclarant les exigences concernant les appareils et les logiciels dans votre fichier manifeste.

La plupart de ces déclarations ne sont fournies qu'à titre indicatif. Le système ne lit pas mais des services externes comme Google Play les lisent pour les utilisateurs qui recherchent des applications sur leur appareil.

Par exemple, supposons que votre application nécessite un appareil photo et utilise des 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 elles sont écrasées par Gradle pendant le processus de compilation. Pour en savoir plus, consultez Spécifier les exigences de niveau d'API

Vous déclarez la fonctionnalité de caméra 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 n'ont pas de ou si vous disposez Une version d'Android inférieure à 8.0 ne peut pas installer votre application depuis Google Play. Cependant, vous pouvez également déclarer que votre application utilise l'appareil photo, l'exiger. Pour ce faire, définissez la required à false, vérifiez au moment de l'exécution si si l'appareil est équipé d'une caméra, et désactivez toutes ses fonctionnalités si nécessaire.

En savoir plus sur la gestion de la compatibilité de votre application avec différents appareils est disponible dans la présentation de la compatibilité des appareils.

Ressources d'une application

Une application Android ne se compose pas seulement de code. Il nécessite des ressources séparément du code source, comme les images, les fichiers audio et tout ce qui concerne l'image 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é avec des fichiers XML.

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

Pour chaque ressource que vous incluez dans votre projet Android, les Build Tools SDK définissent une ID d'entier, que vous pouvez utiliser pour référencer la ressource à partir du code de votre application ou de et 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 outils du SDK génèrent un ID de ressource nommé R.drawable.logo. Cet ID correspond à un nombre entier spécifique à l'application, pour référencer l'image et l'insérer dans votre interface utilisateur.

L'un des aspects les plus importants pour fournir des ressources séparées de votre code source est la possibilité de fournir d'autres ressources pour différents appareils de configuration.

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

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

Pour Par exemple, vous pouvez créer différentes mises en page pour vos activités en fonction l'orientation et la taille de l'écran de votre appareil. Lorsque l'écran de l'appareil est en mode portrait (grand) vous pouvez utiliser une mise en page avec des boutons disposés verticalement, mais lorsque l'écran est en en mode paysage (grand format), vous pouvez aligner les boutons horizontalement. Modifier la mise en page en fonction de l'orientation, vous pouvez définir deux mises en page et appliquer les au nom du répertoire de chaque mise en page. Ensuite, le système applique automatiquement les 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 demande et sur la manière de créer d'autres ressources pour différentes configurations d'appareil, consultez la présentation des ressources d'application. À en savoir plus sur les bonnes pratiques et la conception d'applications robustes et de qualité consultez le Guide de l'architecture des applications.

Ressources supplémentaires

Pour en savoir plus sur le développement Android à l'aide de vidéos et de tutoriels de code, consultez le Développer des applications Android en Kotlin Cours Udacity.