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 :
Figure 1. Architecture de la pile logicielle AOSP.
Voici une liste des définitions des termes utilisés dans la figure 1 :
- Application Androïd
- 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, 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, reportez-vous à 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 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'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.
- API système
- L'API système 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 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. Des parties du cadre sont accessibles au public via l'utilisation de l'API Android. D'autres parties de la structure ne sont disponibles que 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 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,logdetstoraged. 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,libbinderetlibselinux. 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 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, 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 la navigation de gauche et commencez par l'aperçu de cette section.