Cette page a été traduite par l'API Cloud Translation.

Glossaire de la plateforme Android

Consultez la liste ci-dessous pour apprendre la terminologie de base du projet Open Source Android (AOSP). Voici d'autres sources pour les définitions des termes clés :

Voir Codage avec respect pour des exemples de terminologie à utiliser et à éviter pour un écosystème plus inclusif.

applications

fichier .apk: Fichier de package d'application Android. Chaque application Android est compilée et empaquetée dans un seul fichier qui inclut tout le code de l'application (fichiers .dex), les ressources, les actifs et le fichier manifeste. Le fichier de package d'application peut avoir n'importe quel nom mais doit utiliser l'extension .apk . Par exemple : myExampleAppname.apk . Pour plus de commodité, un fichier de package d'application est souvent appelé ".apk".
Connexe : Application .
Action: Une description de quelque chose qu'un expéditeur d'intention veut faire. Une action est une valeur de chaîne affectée à un Intent. Les chaînes d'action peuvent être définies par Android ou par un développeur tiers. Par exemple, android.intent.action.VIEW pour une URL Web, ou com.example.rumbler.SHAKE_PHONE pour une application personnalisée pour faire vibrer le téléphone.
Connexe : Intention .
Activité: Un écran unique dans une application, avec le code Java de support, dérivé de la classe Activity . Le plus souvent, une activité est visiblement représentée par une fenêtre plein écran qui peut recevoir et gérer des événements d'interface utilisateur et effectuer des tâches complexes, en raison de la fenêtre qu'elle utilise pour rendre sa fenêtre. Bien qu'une activité soit généralement en plein écran, elle peut également être flottante ou transparente.
Application: Du point de vue des composants, une application Android se compose d'une ou plusieurs activités, services, écouteurs et récepteurs d'intention. Du point de vue du fichier source, une application Android se compose de code, de ressources, d'actifs et d'un seul manifeste. Lors de la compilation, ces fichiers sont regroupés dans un seul fichier appelé fichier de package d'application (.apk).
Connexe : .apk , Activité
Récepteur de diffusion: Une classe d'application qui écoute les intentions qui sont diffusées, plutôt que d'être envoyées à une seule application/activité cible. Le système délivre une intention de diffusion à tous les récepteurs de diffusion intéressés, qui gèrent l'intention de manière séquentielle.
Connexe : Intention , Filtre d'intention .
Fournisseur de contenu: Une couche d'abstraction de données que vous pouvez utiliser pour exposer en toute sécurité les données de votre application à d'autres applications. Un fournisseur de contenu est construit sur la classe ContentProvider , qui gère les chaînes de requête de contenu d'un format spécifique pour renvoyer des données dans un format spécifique. Voir la rubrique Fournisseurs de contenu pour plus d'informations.
Connexe : Utilisation de l'URI dans Android
Dialogue: Une fenêtre flottante qui agit comme une forme légère. Une boîte de dialogue ne peut avoir que des commandes de bouton et est destinée à effectuer une action simple (telle que le choix d'un bouton) et peut-être à renvoyer une valeur. Une boîte de dialogue n'est pas destinée à persister dans la pile d'historique, à contenir une mise en page complexe ou à effectuer des actions complexes. Android vous propose une boîte de dialogue simple par défaut avec des boutons facultatifs, bien que vous puissiez définir votre propre disposition de boîte de dialogue. La classe de base des boîtes de dialogue est Dialog .
Connexe : Activité .
Intention: Un objet de message que vous pouvez utiliser pour lancer ou communiquer avec d'autres applications/activités de manière asynchrone. Un objet Intent est une instance de Intent . Il comprend plusieurs champs de critères que vous pouvez fournir pour déterminer quelle application/activité reçoit l'intention et ce que fait le destinataire lors de la gestion de l'intention. Les critères disponibles incluent l'action souhaitée, une catégorie, une chaîne de données, le type MIME des données, une classe de traitement, etc. Une application envoie une intention au système Android, plutôt que de l'envoyer directement à une autre application/activité. L'application peut envoyer l'intention à une seule application cible ou l'envoyer sous forme de diffusion, qui peut à son tour être gérée par plusieurs applications de manière séquentielle. Le système Android est responsable de la résolution du meilleur récepteur disponible pour chaque intention, en fonction des critères fournis dans l'intention et les filtres d'intention définis par d'autres applications. Pour plus d'informations, consultez Intentions et filtres d'intention .
Connexe : filtre d'intention , récepteur de diffusion .
Filtre d'intention: Un objet filtre qu'une application déclare dans son fichier manifeste, pour indiquer au système quels types d'intentions chacun de ses composants est prêt à accepter et avec quels critères. Grâce à un filtre d'intention, une application peut exprimer son intérêt pour des types de données spécifiques, des actions d'intention, des formats d'URI, etc. Lors de la résolution d'une intention, le système évalue tous les filtres d'intention disponibles dans toutes les applications et transmet l'intention à l'application/activité qui correspond le mieux à l'intention et aux critères. Pour plus d'informations, consultez Intentions et filtres d'intention .
Connexe : intention , récepteur de diffusion .
Ressources: Composants d'application non programmatiques qui sont externes au code d'application compilé, mais qui peuvent être chargés à partir du code d'application à l'aide d'un format de référence bien connu. Android prend en charge divers types de ressources, mais les ressources d'une application typique seraient constituées de chaînes d'interface utilisateur, de composants de mise en page d'interface utilisateur, de graphiques ou d'autres fichiers multimédias, etc. Une application utilise des ressources pour prendre en charge efficacement la localisation et divers profils et états de périphérique. Par exemple, une application comprendrait un ensemble distinct de ressources pour chaque type local ou de périphérique pris en charge, et elle pourrait inclure des ressources de mise en page spécifiques à l'orientation actuelle de l'écran (paysage ou portrait). Pour plus d'informations sur les ressources, voir Ressources et actifs . Les ressources d'une application sont toujours stockées dans les sous-dossiers res/* du projet.
Service: Un objet de classe Service qui s'exécute en arrière-plan (sans aucune présence d'interface utilisateur) pour effectuer diverses actions persistantes, telles que la lecture de musique ou la surveillance de l'activité du réseau.
En relation : Activité
URI dans Android: Android utilise des chaînes URI (uniform resource identifier) comme base pour demander des données à un fournisseur de contenu (par exemple, pour récupérer une liste de contacts) et pour demander des actions dans une intention (par exemple, ouvrir une page Web dans un navigateur). Le schéma et le format d'URI sont spécialisés en fonction du type d'utilisation, et une application peut gérer des schémas et des chaînes d'URI spécifiques comme elle le souhaite. Certains schémas d'URI sont réservés par les composants du système. Par exemple, les demandes de données provenant d'un fournisseur de contenu doivent utiliser le content:// . Dans un intent, un URI utilisant un schéma http:// sera géré par le navigateur.

Construire

adb: Android Debug Bridge, une application de débogage en ligne de commande incluse avec le SDK. Il fournit des outils pour parcourir l'appareil, copier des outils sur l'appareil et transférer des ports pour le débogage. Si vous développez dans Android Studio, adb est intégré à votre environnement de développement. Voir Pont de débogage Android pour plus d'informations.
Projet Android: Un référentiel Git sur un hôte Android Gerrit. Voir Outils de contrôle de code source > Gerrit pour plus d'informations.
Créer une empreinte digitale: L'empreinte digitale de build est une chaîne unique, lisible par l'homme, contenant des informations sur le fabricant émises pour chaque build. Voir Comprendre les empreintes digitales de build pour plus d'informations.
Gite: L'outil de contrôle de source utilisé par Android qui fonctionnait historiquement sur un seul référentiel Git. Utilisé conjointement avec Repo pour plusieurs référentiels Git. Voir Outils de contrôle de code source > Git pour plus d'informations.
Branche Git - canonique: Des versions distinctes pour chaque référentiel Git, telles que android-11.0.0_r1 , trouvées sur cs.android.com/android/platform/superproject/+/android-11.0.0_r1 . Voir Git Branching - Branches in a Nutshell pour plus d'informations.
Branche Git - locale: Une branche temporaire dans le client Repo actuel pour apporter des modifications au code, démarrée avec le repo start branch-name . commande. une ligne active de développement. Le commit le plus récent sur une branche est appelé la pointe de cette branche.
Référentiel Git: Parfois appelé projet, il s'agit d'une partie de la base de code représentant un composant ou un type d'appareil particulier, tel que frameworks/base ou platform/packages/apps/Car/Media .
Fichier manifeste: Un fichier XML qui décrit un regroupement de référentiels Git par branche, les révisions Git à partir desquelles extraire ces référentiels et leur disposition sur un système de fichiers. Ce fichier XML, généralement nommé default.xml , est associé à une branche Repo et décrit les référentiels Git et les branches Git extraits lorsque vous initialisez et synchronisez la branche Repo. Ce fichier définit les différents référentiels Git que l'outil Repo doit récupérer dans une caisse client Repo afin de créer un produit (tel que Android Automotive OS). Voir tous les manifestes sur android.googlesource.com/platform/manifest/+refs . Consultez le manifeste par défaut inclus dans les fichiers AndroidManifest pour extraire les fichiers de la plate-forme Android (AOSP) sur android.googlesource.com/platform/manifest/+/refs/heads/main/default.xml . Consultez le fichier AndroidManifest.xml pour obtenir des informations sur l'application et le format de manifeste du référentiel pour le développement de la plate-forme.
Mise à jour en direct (OTA): Les appareils Android sur le terrain peuvent recevoir et installer des mises à jour OTA (over-the-air) du système, des logiciels d'application et des règles de fuseau horaire. Voir Mises à jour OTA pour plus d'informations.
Repo: Un wrapper autour de Git pour faciliter les opérations sur plusieurs référentiels Git. Il agrège et gère les nombreux référentiels Git comme une caisse ou une base de code unique. Voir Outils de contrôle de code source > Dépôt pour plus d'informations.
Succursale de pension: Une collection de référentiels Git capturés dans un fichier AndroidManifest qui représente une version (build) de la base de code Android, telle que android11-gsi ou aosp-android-games-sdk , téléchargée via les commandes repo init et repo sync . Consultez la description du fichier manifeste pour les liens vers tous les fichiers manifestes et utilisez https://cs.android.com/ pour rechercher leurs versions.
uprev: En général, uprev met à jour un sous-projet constitutif d'un projet plus vaste vers une version plus récente. Un uprev modifie un niveau de révision soit vers la prochaine version incrémentée, soit vers la dernière version disponible. Dans le cas d'un package HIDL, pour maintenir l'extensibilité rétrocompatible au niveau du package , une version mineure uprev met à jour le nouveau package vers une version mineure supérieure tout en conservant le même nom et la même version majeure que l'ancien package. Dans le cas de la configuration Bootloader , un uprev met à jour la prise en charge de la version de l'en-tête de démarrage vers la dernière version.

Graphique

Toile: Une surface de dessin qui gère la composition des bits réels par rapport à un objet Bitmap ou Surface . Il dispose de méthodes pour le dessin informatique standard de bitmaps, de lignes, de cercles, de rectangles, de texte, etc., et est lié à un Bitmap ou à une Surface. Canvas est le moyen le plus simple et le plus simple de dessiner des objets 2D à l'écran. La classe de base est Canvas .
Connexes : Drawable , OpenGL ES , Surface .
Dessinable: Une ressource visuelle compilée qui peut être utilisée comme arrière-plan, titre ou autre partie de l'écran. Un dessin est généralement chargé dans un autre élément de l'interface utilisateur, par exemple en tant qu'image d'arrière-plan. Un drawable n'est pas en mesure de recevoir des événements, mais attribue diverses autres propriétés telles que "l'état" et la planification, pour activer des sous-classes telles que des objets d'animation ou des bibliothèques d'images. De nombreux objets dessinables sont chargés à partir de fichiers de ressources dessinables - fichiers xml ou bitmap qui décrivent l'image. Les ressources drawable sont compilées dans des sous-classes de android.graphics.drawable . Pour plus d'informations sur les drawables et les autres ressources, voir Ressources .
Related: Ressources , Canevas
Ressource de mise en page: Un fichier XML qui décrit la disposition d'un écran d'activité.
Connexe : Ressources
Image à neuf patchs / à 9 patchs / à neuf patchs: Une ressource bitmap redimensionnable qui peut être utilisée pour les arrière-plans ou d'autres images sur l'appareil. Voir Image extensible à neuf patchs pour plus d'informations.
Connexe : Ressources .
OpenGL ES: Android fournit des bibliothèques OpenGL ES pour le rendu 3D accéléré par le matériel. Pour le rendu 2D, Canvas est l'option la plus simple. » OpenGL ES est disponible dans le kit de développement natif Android (NDK) pour une utilisation facile. Les packages android.opengl et javax.microedition.khronos.opengles exposent la fonctionnalité OpenGL ES.
Connexe: Toile , Surface
Surface: Un objet de type Surface représentant un bloc de mémoire qui est composé à l'écran. Une surface contient un objet Canvas pour le dessin et fournit diverses méthodes d'assistance pour dessiner des calques et redimensionner la surface. Vous ne devez pas utiliser cette classe directement ; utilisez plutôt SurfaceView .
Connexe: Toile
SurfaceView: Un objet View qui encapsule une surface pour le dessin et expose des méthodes pour spécifier sa taille et son format de manière dynamique. Un SurfaceView fournit un moyen de dessiner indépendamment du thread d'interface utilisateur pour les opérations gourmandes en ressources (telles que les jeux ou les aperçus de caméra), mais il utilise par conséquent de la mémoire supplémentaire. SurfaceView prend en charge les graphiques Canvas et OpenGL ES. La classe de base est SurfaceView .
Connexe: Surface
Thème: Ensemble de propriétés (taille du texte, couleur d'arrière-plan, etc.) regroupées pour définir divers paramètres d'affichage par défaut. Android fournit quelques thèmes standard, répertoriés dans R.style (commençant par "Theme_").
Voir: Objet qui dessine dans une zone rectangulaire de l'écran et gère les clics, les frappes au clavier et d'autres événements d'interaction. Une vue est une classe de base pour la plupart des composants de mise en page d'un écran d'activité ou de dialogue (zones de texte, fenêtres, etc.). Il reçoit des appels de son objet parent (voir ViewGroup ) pour se dessiner, et informe son objet parent de l'endroit et de la taille qu'il aimerait avoir (ce qui peut ou non être respecté par le parent). Pour plus d'informations, voir View .
Connexes : Afficher la hiérarchie , Afficher le groupe , Widget
Afficher la hiérarchie: Agencement d'objets View et ViewGroup qui définit l'interface utilisateur pour chaque composant d'une application. La hiérarchie se compose de groupes de vues contenant une ou plusieurs vues enfants ou groupes de vues. Vous pouvez obtenir une représentation visuelle d'une hiérarchie de vues pour le débogage et l'optimisation à l'aide de la visionneuse de hiérarchie fournie avec le SDK Android.
Connexe : Afficher , AfficherGroupe
AfficherGroupe: Un objet conteneur qui regroupe un ensemble de vues enfant. Le groupe de vues est chargé de décider de l'emplacement des vues enfants et de leur taille, ainsi que d'appeler chacune à se dessiner le cas échéant. Certains groupes de vues sont invisibles et ne servent qu'à la mise en page, tandis que d'autres ont une interface utilisateur intrinsèque (par exemple, une zone de liste déroulante). Les groupes de vues sont tous dans le package widget , mais étendent ViewGroup .
Connexes : Afficher , Afficher la hiérarchie
Widget: L'une d'un ensemble de sous-classes View entièrement implémentées qui restituent des éléments de formulaire et d'autres composants d'interface utilisateur, tels qu'une zone de texte ou un menu contextuel. Parce qu'un widget est entièrement implémenté, il gère la mesure et le dessin lui-même et répond aux événements de l'écran. Les widgets sont tous dans le package android.widget .
Fenêtre: Dans une application Android, objet dérivé de la classe abstraite Window qui spécifie les éléments d'une fenêtre générique, tels que l'apparence (texte de la barre de titre, emplacement et contenu des menus, etc.). Dialog et Activity utilisent une implémentation de cette classe pour afficher une fenêtre. Vous n'avez pas besoin d'implémenter cette classe ou d'utiliser des fenêtres dans votre application.

Plateforme

Android Runtime (ART) et Dalvik: Le runtime Android (ART) est le runtime géré utilisé par les applications et certains services système sur Android. Le runtime Android (ART) est le runtime par défaut pour les appareils exécutant Android 5.0 (API niveau 21) et supérieur. ART et son prédécesseur Dalvik ont été créés à l'origine spécifiquement pour le projet Android Open Source. ART en tant que runtime exécute le format Dalvik Executable et la spécification du bytecode Dex. ART et Dalvik sont des runtimes compatibles exécutant le bytecode Dex, donc les applications développées pour Dalvik devraient fonctionner lorsqu'elles sont exécutées avec ART.
Ligne de code: Une ligne de code contient la version d'un produit logiciel. Il se compose d'une ou plusieurs branches d'un ou plusieurs référentiels, qui sont souvent tous en cours de développement actif en même temps. La ligne de code est le point d'agrégation et la cible de la version. Pour plus d'informations sur les lignes de code, consultez Gestion des logiciels Android .
fichier .dex: Fichier de code d'application Android compilé.
Les programmes Android sont compilés dans des fichiers .dex (Dalvik Executable), qui sont à leur tour compressés dans un seul fichier .apk sur l'appareil. Les fichiers .dex peuvent être créés en traduisant automatiquement des applications compilées écrites dans le langage de programmation Java.

Test

Artefacts: Les artefacts sont des journaux liés à la construction permettant un dépannage local. Ces journaux sont accessibles directement depuis Gerrit lors de la consultation de votre liste de modifications. Faites défiler jusqu'à Presubmit Status et cliquez sur le lien rouge Build pour afficher ou télécharger le fichier build_error.log associé. Vous pouvez également obtenir ces artefacts à partir du serveur central d'intégration continue d'Android sur ci.android.com/ en cliquant sur l'icône Télécharger (flèche vers le bas) pour la cible et le build. Pour plus d'informations sur la recherche d'artefacts, consultez Intégration continue d'Android .
CDD: Le document de définition de compatibilité Android (CDD) énumère les exigences qui doivent être remplies pour que vos appareils soient compatibles avec la dernière version d'Android. Pour être considérées comme compatibles avec Android, les implémentations d'appareils DOIVENT répondre aux exigences présentées dans cette définition de compatibilité, y compris tous les documents incorporés par référence. Pour plus d'informations sur le CDD, consultez le document de définition de compatibilité Android .
CTS: La suite de tests de compatibilité (CTS) est la suite de tests permettant de garantir l'exactitude de l'API et les spécifications énoncées dans le CDD. Il est disponible en tant que source dans AOSP et en téléchargement en tant que binaire. Pour plus d'informations, consultez Suite de tests de compatibilité .
Vérificateur CTS: Le Compatibility Test Suite Verifier (CTS Verifier) est un complément au CTS. CTS Verifier fournit des tests pour les API et les fonctions qui ne peuvent pas être testées sur un appareil fixe sans saisie manuelle (par exemple, qualité audio, accéléromètre, etc.). Pour plus d'informations, consultez Utilisation de CTS Verifier .
Débogage: Le débogage nécessite de rechercher et de corriger les erreurs dans le code de la plate-forme Android, que ce soit dans les fonctionnalités ou leurs tests. Pour plus d'informations, consultez Déboguer le code de la plate-forme Android native
Test Google (GTest): GTest est le framework de test et de simulation C++ de Google. Les binaires GTest accèdent généralement aux couches d'abstraction de niveau inférieur ou effectuent un IPC brut sur divers services système. Pour cette raison, l'approche de test pour Gtest est généralement étroitement liée au service testé. Trouvez le code sur github.com/google/googletest et la documentation sur google.github.io/googletest .
Essai d'instrumentation: Un test d'instrumentation fournit un environnement d'exécution de test spécial lancé par la commande am instrument , où le processus d'application ciblé est redémarré et initialisé avec le contexte d'application de base, et un thread d'instrumentation est démarré à l'intérieur de la machine virtuelle du processus d'application. Pour plus d'informations, voir Tests d'instrumentation .
Logcat: Logcat est un outil de ligne de commande qui vide un journal des messages système, y compris les traces de la pile lorsque l'appareil génère une erreur et les messages que vous avez écrits à partir de votre application avec la classe Log . Pour plus d'informations, consultez Outil de ligne de commande Logcat .
Enregistrement: La connexion à Android est complexe en raison du mélange de normes utilisées qui sont combinées dans logcat . Pour plus de détails sur les principales normes utilisées, consultez Comprendre la journalisation .
Conflit de fusion: Un conflit de fusion se produit lorsque deux versions ou plus du même fichier ne peuvent plus être fusionnées automatiquement par le serveur de build Android. Celles-ci nécessitent généralement une modification manuelle du fichier pour résoudre toutes les mises à jour conflictuelles.
Tests de pré-soumission et de post-soumission: Les tests de pré-soumission sont utilisés pour empêcher l'introduction d'échecs dans les noyaux communs. Les résultats ne sont pas accessibles au public pour le moment.

Les tests de post-soumission Android sont effectués lorsqu'un nouveau correctif est validé dans une branche commune du noyau. En saisissant aosp_kernel comme nom de branche partiel, vous pouvez voir une liste des branches du noyau avec les résultats disponibles. Par exemple, les résultats pour `android-mainline` peuvent être trouvés ici .
Tradefed: Le harnais de test Trade Federation (Tradefed ou TF en abrégé) est un cadre de test continu conçu pour exécuter des tests sur des appareils Android. Par exemple, Tradefed est utilisé pour exécuter le CTS et le VTS. Pour plus d'informations, voir Présentation de la fédération commerciale .
VTS: L'Android Vendor Test Suite (VTS) fournit des fonctionnalités étendues pour les tests Android, promeut un processus de développement piloté par les tests et automatise les tests du noyau HAL et du système d'exploitation. Pour plus d'informations, consultez Vendor Test Suite (VTS) et Infrastructure .