Google is committed to advancing racial equity for Black communities. See how.
Cette page a été traduite par l'API Cloud Translation.
Switch to English

Architecture Android

L'architecture du système Android contient les composants suivants:

Vue d'ensemble de l'architecture du système Android
Figure 1. Architecture du système Android
  • Cadre d'application . Le cadre d'application est le plus souvent utilisé par les développeurs d'applications. En tant que développeur de matériel, vous devez être conscient des API de développeur, car beaucoup sont directement mappées aux interfaces HAL sous-jacentes et peuvent fournir des informations utiles sur l'implémentation des pilotes.
  • Binder IPC . Le mécanisme IPC (Binder Inter-Process Communication) permet au cadre d'application de traverser les limites du processus et d'appeler le code des services système Android. Cela permet aux API de cadre de haut niveau d'interagir avec les services système Android. Au niveau du framework applicatif, cette communication est cachée au développeur et les choses semblent "juste fonctionner".
  • Services système . Les services système sont des composants modulaires et ciblés tels que Window Manager, Search Service ou Notification Manager. Les fonctionnalités exposées par les API du framework d'application communiquent avec les services système pour accéder au matériel sous-jacent. Android comprend deux groupes de services: système (tel que Window Manager et Notification Manager) et média (services impliqués dans la lecture et l'enregistrement de supports).
  • Couche d'abstraction matérielle (HAL) . Un HAL définit une interface standard que les fournisseurs de matériel doivent implémenter, ce qui permet à Android d'être indépendant des implémentations de pilotes de niveau inférieur. L'utilisation d'un HAL vous permet d'implémenter des fonctionnalités sans affecter ou modifier le système de niveau supérieur. Les implémentations HAL sont regroupées dans des modules et chargées par le système Android au moment opportun. Pour plus de détails, consultez Couche d'abstraction matérielle (HAL) .
  • Noyau Linux . Le développement de vos pilotes de périphérique est similaire au développement d'un pilote de périphérique Linux classique. Android utilise une version du noyau Linux avec quelques ajouts spéciaux tels que Low Memory Killer (un système de gestion de la mémoire plus agressif pour préserver la mémoire), les verrous de réveil (un service système PowerManager ), le pilote Binder IPC et d'autres fonctionnalités importantes pour une plateforme embarquée mobile. Ces ajouts concernent principalement les fonctionnalités du système et n'affectent pas le développement des pilotes. Vous pouvez utiliser n'importe quelle version du noyau tant qu'elle prend en charge les fonctionnalités requises (telles que le pilote de classeur). Cependant, nous vous recommandons d'utiliser la dernière version du noyau Android. Pour plus de détails, consultez Construction de noyaux .

Langage de définition d'interface HAL (HIDL)

Android 8.0 a restructuré le cadre du système d'exploitation Android (dans un projet appelé Treble ) pour permettre aux fabricants de mettre à jour plus facilement, plus rapidement et moins cher les appareils vers une nouvelle version d'Android. Dans cette nouvelle architecture, le langage de définition d'interface HAL (HIDL, prononcé "hide-l") spécifie l'interface entre un HAL et ses utilisateurs, permettant de remplacer le framework Android sans reconstruire les HAL.

HIDL sépare l'implémentation du fournisseur (logiciel de bas niveau spécifique à l'appareil écrit par les fabricants de silicium) du cadre du système d'exploitation Android via une nouvelle interface de fournisseur. Les fournisseurs ou fabricants de SOC créent des HAL une fois et les placent dans une partition /vendor sur le périphérique; le framework, dans sa propre partition, peut alors être remplacé par une mise à jour over-the-air (OTA) sans recompiler les HAL.

La différence entre l'architecture Android héritée et l'architecture actuelle basée sur HIDL réside dans l'utilisation de l'interface du fournisseur:

  • Dans Android 7.x et versions antérieures, aucune interface de fournisseur formelle n'existe, les fabricants d'appareils doivent donc mettre à jour une grande partie du code Android pour déplacer un appareil vers une version plus récente d'Android:

    Figure 2. Environnement de mise à jour Android hérité
  • Dans Android 8.0 et versions ultérieures, une nouvelle interface de fournisseur stable permet d'accéder aux parties spécifiques au matériel d'Android, de sorte que les fabricants d'appareils peuvent fournir de nouvelles versions d'Android simplement en mettant à jour le cadre du système d'exploitation Android, sans travail supplémentaire de la part des fabricants de silicium:

    Figure 3. Environnement de mise à jour Android actuel

Tous les nouveaux appareils lancés avec Android 8.0 et supérieur peuvent profiter de la nouvelle architecture. Pour garantir la compatibilité ascendante des implémentations du fournisseur, l'interface du fournisseur est validée par Vendor Test Suite (VTS) , qui est analogue à la Compatibility Test Suite (CTS) . Vous pouvez utiliser VTS pour automatiser les tests de noyau HAL et OS dans les architectures Android existantes et actuelles.

Ressources d'architecture

Pour plus de détails sur l'architecture Android, consultez les sections suivantes:

  • Types HAL . Décrit les HAL liés, passthrough, Same-Process (SP) et hérités.
  • HIDL (Général) . Contient des informations générales sur l'interface entre un HAL et ses utilisateurs.
  • HIDL (C ++) . Contient des détails sur la création d'implémentations C ++ des interfaces HIDL.
  • HIDL (Java) . Contient des détails sur l'interface Java pour les interfaces HIDL.
  • ConfigStore HAL . Décrit les API pour accéder aux éléments de configuration en lecture seule utilisés pour configurer l'infrastructure Android.
  • Superpositions de l'arborescence des périphériques . Fournit des détails sur l'utilisation des superpositions d'arborescence de périphériques (DTO) dans Android.
  • Kit de développement natif du fournisseur (VNDK) . Décrit l'ensemble des bibliothèques exclusives au fournisseur pour l'implémentation des HAL du fournisseur.
  • Objet d'interface fournisseur (VINTF) . Décrit les objets qui regroupent les informations pertinentes sur un appareil et rendent ces informations disponibles via une API interrogeable.
  • SELinux pour Android 8.0 . Détails des modifications et personnalisations de SELinux.

En plus des ressources sur ce site, les membres de l'équipe Treble ont publié Treble: Fast Software Updates by Creating an Equilibrium in an Active Software Ecosystem of Globally Distributed Stakeholders . Le document est gratuit pour les membres de l'ACM et les non-membres peuvent acheter ou lire le résumé.