Présentation de l'architecture

La plate-forme Android Open System (AOSP) est un code source Android accessible au public et modifiable. N'importe qui peut télécharger et modifier AOSP pour son appareil. AOSP fournit une implémentation complète et entièrement fonctionnelle de la plateforme mobile Android.

Il existe deux niveaux de compatibilité pour les appareils implémentant AOSP : la compatibilité AOSP et la compatibilité Android. Un appareil compatible AOSP doit être conforme à la liste des exigences du document de définition de compatibilité (CDD) . Un appareil compatible Android doit être conforme à la liste des exigences du CDD et des exigences logicielles du fournisseur (VSR) et aux tests tels que ceux de la suite de tests du fournisseur (VTS) et de la suite de tests de compatibilité (CTS) . Pour plus d'informations sur la compatibilité Android, reportez-vous au programme de compatibilité Android .

Architecture AOSP

La pile logicielle pour AOSP contient les couches suivantes :

Architecture de pile logicielle AOSP.

Figure 1. Architecture de la pile logicielle AOSP.

Voici une liste de définitions des termes utilisés dans la figure 1 :

Application Android
Une application créée uniquement à l'aide de l'API Android. Google Play Store est largement utilisé pour rechercher et télécharger des applications Android, bien qu'il existe de nombreuses autres alternatives. Dans certains cas, le fabricant d'un appareil peut souhaiter préinstaller une application Android pour prendre en charge les fonctionnalités de base de l'appareil. Si vous souhaitez développer des applications Android, reportez-vous à Developers.android.com.
Application privilégiée
Une application créée à l'aide d'une combinaison d'API Android et système. Ces applications doivent être préinstallées en tant qu'applications privilégiées sur un appareil.
Application du fabricant de l'appareil
Une application créée à l'aide d'une combinaison de l'API Android, de l'API système et d'un accès direct à l'implémentation du framework Android. Étant donné qu'un fabricant d'appareil peut accéder directement à des API instables dans le cadre Android, ces applications doivent être préinstallées sur l'appareil et ne peuvent être mises à jour que lorsque le logiciel système de l'appareil est mis à jour.
API système
L'API système représente les API Android disponibles uniquement pour les partenaires et les OEM pour inclusion dans les applications groupées. Ces API sont marquées comme @SystemApi dans le code source.
API Android
L'API Android est l'API accessible au public pour les développeurs d'applications Android tiers. Pour plus d'informations sur l'API Android, reportez-vous à la référence de l'API Android .
Cadre Android
Un groupe de classes Java, d'interfaces et d'autres codes précompilés sur lesquels les applications sont construites. Certaines parties du framework sont accessibles au public via l'utilisation de l'API Android. D'autres parties du framework sont disponibles uniquement pour les OEM via l'utilisation des API système. Le code du framework Android s'exécute dans le processus d'une application.
Services système
Les services système sont des composants modulaires et ciblés tels que system_server , SurfaceFlinger et MediaService. La fonctionnalité exposée par l'API du framework Android communique avec les services système pour accéder au matériel sous-jacent.
Exécution Android (ART)
Un environnement d'exécution Java fourni par AOSP. ART effectue la traduction du bytecode de l'application en instructions spécifiques au processeur qui sont exécutées par l'environnement d'exécution de l'appareil.
Couche d'abstraction matérielle (HAL)
Un HAL est une couche d'abstraction avec une interface standard que les fournisseurs de matériel peuvent implémenter. Les HAL permettent à 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 ni modifier le système de niveau supérieur. Pour plus d'informations, consultez la présentation de HAL .
Démons et bibliothèques natifs

Les démons natifs de cette couche incluent init , healthd , logd et storaged . Ces démons interagissent directement avec le noyau ou d'autres interfaces et ne dépendent pas d'une implémentation HAL basée sur l'espace utilisateur.

Les bibliothèques natives de cette couche incluent libc , liblog , libutils , libbinder et libselinux . Ces bibliothèques natives interagissent directement avec le noyau ou d'autres interfaces et ne dépendent pas d'une implémentation HAL basée sur l'espace utilisateur.

Noyau

Le noyau est la partie centrale de tout système d'exploitation et communique avec le matériel sous-jacent d'un périphérique. Dans la mesure du possible, le noyau AOSP est divisé en modules indépendants du matériel et en modules spécifiques au fournisseur. Pour une description, y compris les définitions, des composants du noyau AOSP, reportez-vous à la présentation du noyau .

Et après?

  • Si vous êtes nouveau sur AOSP et que vous souhaitez vous lancer dans le développement, reportez-vous à la section Premiers pas .
  • Si vous souhaitez en savoir plus sur une couche spécifique d'AOSP, cliquez sur le nom de la section dans le volet de navigation de gauche et commencez par la présentation de cette section.