À partir du 27 mars 2025, nous vous recommandons d'utiliser android-latest-release au lieu de aosp-main pour créer et contribuer à AOSP. Pour en savoir plus, consultez la section Modifications apportées à AOSP.
Restez organisé à l'aide des collections
Enregistrez et classez les contenus selon vos préférences.
Le Projet Android Open Source (AOSP) est un code source Android 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 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 compatibilité (CDD). Un appareil compatible avec Android doit respecter la liste des exigences du CDD et des exigences logicielles du fournisseur (VSR), ainsi que des tests tels que ceux de la Vendor Test Suite (VTS) et de la 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 :
Figure 1 : Architecture de la pile logicielle AOSP.
Vous trouverez ci-dessous la définition 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 trouver 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 la fonctionnalité principale 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 aux API instables du 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 afin d'être incluses 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 destinée aux 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
Ensemble de classes Java, d'interfaces et d'autres codes précompilés sur lesquels les applications sont conçues. Certaines parties du framework sont accessibles au public grâce à l'utilisation de l'API Android. D'autres parties du framework 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.
Android Runtime (ART)
Environnement d'exécution Java fourni par AOSP. ART traduit le 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)
Une HAL est une couche d'abstraction avec une interface standard que les fournisseurs de matériel peuvent implémenter. Les HAL permettent à Android d'être agnostique quant aux implémentations de pilotes de niveau inférieur. L'utilisation d'une 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.
Kernel
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 noyau AOSP, consultez la présentation du noyau.
Étapes suivantes
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 et commencez par la présentation de cette section.
Le contenu et les exemples de code de cette page sont soumis aux licences décrites dans la Licence de contenu. Java et OpenJDK sont des marques ou des marques déposées d'Oracle et/ou de ses sociétés affiliées.
Dernière mise à jour le 2025/07/24 (UTC).
[[["Facile à comprendre","easyToUnderstand","thumb-up"],["J'ai pu résoudre mon problème","solvedMyProblem","thumb-up"],["Autre","otherUp","thumb-up"]],[["Il n'y a pas l'information dont j'ai besoin","missingTheInformationINeed","thumb-down"],["Trop compliqué/Trop d'étapes","tooComplicatedTooManySteps","thumb-down"],["Obsolète","outOfDate","thumb-down"],["Problème de traduction","translationIssue","thumb-down"],["Mauvais exemple/Erreur de code","samplesCodeIssue","thumb-down"],["Autre","otherDown","thumb-down"]],["Dernière mise à jour le 2025/07/24 (UTC)."],[],[],null,["# Architecture overview\n\nThe *Android Open Source Project (AOSP)* is publicly available and modifiable\nAndroid source code. Anyone can download and modify AOSP for their device. AOSP\nprovides a complete and fully functional implementation of the Android mobile\nplatform.\n| **Note:** AOSP can't provide support for apps that require backend services, such as a cloud messaging or advanced location services app. AOSP also doesn't include a full set of end-user apps that might be needed for particular types of devices.\n\nThere are two levels of compatibility for devices implementing AOSP: AOSP\ncompatibility and Android compatibility. An *AOSP-compatible device* must\nconform to the list of requirements in the\n[Compatibility Definition Document (CDD)](/docs/compatibility/cdd). An\n*Android-compatible device* must conform to the list of requirements in the CDD\nand Vendor Software Requirements (VSR) and tests such as those in the\n[Vendor Test Suite (VTS)](/docs/core/tests/vts) and\n[Compatibility Test Suite (CTS)](/docs/compatibility/cts). For further\ninformation on Android compatibility, refer to the\n[Android compatibility program](/docs/compatibility).\n\nAOSP architecture\n-----------------\n\nThe software stack for AOSP contains the following layers:\n\n**Figure 1.** AOSP software stack architecture.\n\nFollowing is a list of definitions for terms used in Figure 1:\n\n*Android app*\n: An app created solely using the Android API. Google\n Play Store is widely used to find and download Android apps, though there are\n many other alternatives. In some cases, a device manufacturer might want to\n preinstall an Android app to support the core functionality of the device. If\n you're interested in developing Android apps, refer to\n [developers.android.com](https://developer.android.com/).\n\n*Privileged app*\n: An app created using a combination of the Android and system APIs. These apps\n must be preinstalled as privileged apps on a device.\n\n*Device manufacturer app*\n: An app created using a combination of the Android API, system API, and direct\n access to the Android framework implementation. Because a device manufacturer\n might directly access unstable APIs within the Android framework, these apps\n must be preinstalled on the device and can be updated only when the device's\n system software is updated.\n\n*System API*\n: The System API represents Android APIs available only to partners and\n OEMs for inclusion in bundled applications. These APIs are marked as @SystemApi\n in the source code.\n\n*Android API*\n: The Android API is the publicly available API for third-party Android app\n developers. For information on the Android API, refer to\n [Android API reference](https://developer.android.com/reference).\n\n*Android framework*\n: A group of Java classes, interfaces, and other precompiled code upon which\n apps are built. Portions of the framework are publicly accessible through the\n use of the Android API. Other portions of the framework are\n available only to OEMs through the use of the system APIs. Android\n framework code runs inside an app's process.\n\n*System services*\n: System services are modular, focused components such as `system_server`,\n SurfaceFlinger, and MediaService. Functionality exposed by Android framework API\n communicates with system services to access the underlying hardware.\n\n*Android runtime (ART)*\n: A Java runtime environment provided by AOSP. ART performs the\n translation of the app's bytecode into processor-specific instructions\n that are executed by the device's runtime environment.\n\n*Hardware abstraction layer (HAL)*\n: A HAL is an abstraction layer with a standard interface for hardware vendors\n to implement. HALs allow Android to be agnostic about lower-level driver\n implementations. Using a HAL lets you implement functionality without\n affecting or modifying the higher level system. For further information,\n see the [HAL overview](/docs/core/architecture/hal).\n\n*Native daemons and libraries*\n\n: Native daemons in this layer include `init`, `healthd`, `logd`, and\n `storaged`. These daemons interact directly with the kernel or other interfaces\n and don't depend on a userspace-based HAL implementation.\n\n Native libraries in this layer include `libc`, `liblog`, `libutils`,\n `libbinder`, and `libselinux`. These Native libraries interact directly with\n the kernel or other interfaces and don't depend on a userspace-based HAL\n implementation.\n\n*Kernel*\n\n: The kernel is the central part of any operating system and talks to the\n underlying hardware on a device. Where possible, the AOSP kernel is split\n into hardware-agnostic modules and vendor-specific modules. For a description,\n including definitions, of AOSP kernel components, refer to the\n [Kernel overview](/docs/core/architecture/kernel).\n\nWhat's next?\n------------\n\n- If you're new to AOSP, and want to get started with development, refer to the [Get started section](/docs/setup).\n- If you want to learn more about a specific layer of AOSP, click the section's name in the left navigation and begin with the overview for that section."]]
