Présentation de l'architecture

Le projet Android Open Source (AOSP) est accessible au public et modifiable Code source Android. 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 l'application mobile Android Google Cloud.

Il existe deux niveaux de compatibilité pour les appareils qui implémentent AOSP: AOSP et Android. Vous devez disposer d'un appareil compatible avec AOSP. conforme à la liste des exigences du Document de définition de compatibilité (CDD). Une Un appareil compatible avec Android doit être conforme à la liste des exigences du CDD. et des exigences relatives aux logiciels du fournisseur, ainsi que des tests tels que ceux Suite de test des fournisseurs (VTS) et Compatibility Test Suite (CTS) Pour en savoir plus, sur la compatibilité avec Android, consultez le Programme de compatibilité Android

Architecture AOSP

La pile logicielle pour AOSP contient les couches suivantes:

Architecture de la pile logicielle AOSP

Figure 1 : Architecture de la pile logicielle AOSP

Voici 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. Google Le Play Store est largement utilisé pour rechercher et télécharger des applications Android, mais il existe bien d'autres alternatives. Dans certains cas, un fabricant d'appareils peut vouloir préinstaller une application Android pour prendre en charge la fonctionnalité de base de l'appareil. Si vous souhaitez développer des applications Android, reportez-vous à 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 sur l'appareil en tant qu'applications privilégiées.
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 de l'accès direct à l'implémentation du framework Android. Parce qu’un fabricant d’appareils peuvent accéder directement à des API instables dans le framework Android, ces applications doit être préinstallé sur l'appareil et ne peut être mis à jour que lorsque le logiciel système est mis à jour.
API système
L'API System représente les API Android disponibles uniquement pour les partenaires et 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 applications Android tierces développeurs. Pour en savoir plus sur l'API Android, consultez 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 applications sont créées. Certaines parties du framework sont accessibles au public via la de l'API Android. D'autres parties du framework sont disponibles uniquement pour les OEM via les API système. Android code du framework 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. Fonctionnalités exposées par l'API du framework Android communique avec les services système pour accéder au matériel sous-jacent.
Environnement d'exécution Android (ART)
Environnement d'exécution Java fourni par AOSP. ART effectue les tâches 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)
Un HAL est une couche d'abstraction avec une interface standard pour les fournisseurs de matériel à mettre en œuvre. Les HAL permettent à Android d'être indépendant du pilote de niveau inférieur mises en œuvre. L'utilisation d'une HAL vous permet d'implémenter une fonctionnalité sans affectant ou modifiant le système de niveau supérieur. Pour plus d'informations, consultez la présentation de HAL.
Demons 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 noyau ou d'autres interfaces, et ne dépendent pas d'une couche HAL basée sur l'espace utilisateur la mise en œuvre.

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 aux fournisseurs. Pour une description, y compris les définitions des composants du noyau AOSP, reportez-vous au Présentation du noyau

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 lien dans le panneau de navigation de gauche, puis commencez par la présentation de cette section.