Architecture AOSP

Restez organisé à l'aide des collections Enregistrez et classez les contenus selon vos préférences.

La plate-forme Android Open System (AOSP) est un code source Android accessible au public 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 mettant en œuvre 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 vendeur (VSR) et des tests tels que ceux de la suite de tests du vendeur (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 la pile logicielle AOSP
Figure 1. Architecture de la pile logicielle AOSP.
  • Application Androïd. Une application créée uniquement à l'aide de l'API Android dans le SDK 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, 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, rendez-vous sur developers.android.com .
  • Application privilégiée. Une 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 de fabrication d'appareils. 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'appareils 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.
  • Cadre Android. Un groupe de classes Java, d'interfaces et d'autres codes précompilés sur lesquels les applications sont construites. Des parties du framework sont accessibles au public via l'utilisation des API Android du SDK Android. D'autres parties du framework ne sont disponibles que pour les OEM via l'utilisation des API système du SDK Android. Le code du framework Android s'exécute dans le processus d'une application.
  • SDK Android. Un kit de développement logiciel à utiliser pour créer des applications qui interagissent avec le framework Android. Le SDK Android se compose de l'API Android, disponible pour toutes les applications, et de l'API système, disponible uniquement pour les applications privilégiées. Pour plus d'informations sur l'API Android du SDK Android, rendez-vous sur developers.android.com . Notez qu'il existe également un kit de développement natif Android (NDK) qui vous permet d'écrire une partie de votre application Android en utilisant du code natif.
  • 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 d'application 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 doivent implémenter. Les HAL permettent à Android d'être agnostique quant aux 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 vue d' ensemble 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. Élément central de tout système d'exploitation, le noyau 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 une description, y compris les définitions, des composants du noyau AOSP, reportez-vous à la présentation du noyau .

Et après?

  • Si vous débutez avec AOSP et que vous souhaitez vous lancer dans le développement, passez à la section Premiers pas .
  • Si vous souhaitez en savoir plus sur une couche spécifique d'AOSP, cliquez sur le nom de la couche dans la navigation de gauche et commencez par la vue d'ensemble de cette couche.