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.

Remarque :AOSP ne prend pas en charge les applications qui nécessitent des services backend, comme une application de messagerie cloud ou des services de localisation avancés. AOSP n'inclut pas non plus l'ensemble complet d'applications destinées aux utilisateurs finaux qui peuvent être nécessaires pour certains types d'appareils.

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:

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, bien qu'il existe de nombreuses autres alternatives. Dans certains cas, un fabricant d'appareils peut vouloir 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 accessible au public 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, d'interfaces et d'autres codes précompilés Java sur lesquels reposent les applications. 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 effectue la traduction du 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 les définitions, des composants du noyau AOSP, consultez la présentation du noyau.

Et maintenant ?

• Si vous débutez avec AOSP et souhaitez commencer 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.