Présentation de l'architecture

Le projet Android Open Source (AOSP) est un code source Android accessible publiquement et modifiable. Tout le monde peut télécharger et modifier AOSP pour son appareil. AOSP fournit une implémentation complète et entièrement fonctionnelle de la plate-forme mobile Android.

Il existe deux niveaux de compatibilité pour les appareils implémentant AOSP: la compatibilité AOSP et la compatibilité Android. Un appareil compatible avec AOSP doit respecter la liste des exigences du document de définition de la compatibilité (CDD). Un appareil compatible avec Android doit respecter la liste des exigences du CDD et des exigences logicielles du fournisseur (VSR), ainsi que les tests tels que ceux de la suite de tests du fournisseur (VTS) et de la suite de tests de compatibilité (CTS). Pour en savoir plus sur la compatibilité avec Android, consultez le programme de compatibilité Android.

Architecture AOSP

La pile logicielle d'AOSP contient les couches suivantes:

Architecture de la pile logicielle AOSP.

Figure 1 : Architecture de la pile logicielle AOSP.

Vous trouverez ci-dessous la liste des définitions des termes utilisés dans la figure 1:

Application Android
Application créée uniquement à l'aide de l'API Android. Le Google Play Store est largement utilisé pour rechercher et télécharger des applications Android, mais il existe de nombreuses autres alternatives. Dans certains cas, un fabricant d'appareils 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, consultez developers.android.com.
Application privilégiée
Application créée à l'aide d'une combinaison des 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
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'appareils peut accéder directement à des API instables dans le framework 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 System représente les API Android disponibles uniquement pour les partenaires et les OEM à inclure dans les applications groupées. Ces API sont marquées comme @SystemApi dans le code source.
API Android
L'API Android est l'API publique disponible pour les développeurs d'applications Android tierces. Pour en savoir plus sur l'API Android, consultez la documentation de référence de l'API Android.
Framework Android
Groupe de classes Java, d'interfaces et d'autres codes précompilés sur lesquels les applications sont créées. Certaines parties du framework sont accessibles au public via l'utilisation de l'API Android. Les autres parties du framework ne sont disponibles que pour les OEM via les 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. Les fonctionnalités exposées par l'API du framework Android communiquent avec les services système pour accéder au matériel sous-jacent.
Android Runtime (ART)
Environnement d'exécution Java fourni par AOSP. ART traduit le bytecode de l'application en instructions spécifiques au processeur exécutées par l'environnement d'exécution de l'appareil.
Couche d'abstraction matérielle (HAL)
Une HAL est une couche d'abstraction avec une interface standard que les fournisseurs de matériel doivent implémenter. Les HAL permettent à Android d'être indépendant des implémentations de pilotes de bas niveau. 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 en savoir plus, consultez la présentation de HAL.
Daemons et bibliothèques natifs

Les daemons natifs de cette couche incluent init, healthd, logd et storaged. Ces daemons 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 kernel 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 appareil. 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 obtenir une description, y compris des définitions, des composants du kernel AOSP, consultez la section Présentation du kernel.

Et maintenant ?

  • Si vous débutez avec AOSP et que vous souhaitez vous lancer dans le développement, consultez 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 panneau de navigation de gauche, puis commencez par la présentation de cette section.