A partir del 27 de marzo de 2025, te recomendamos que uses android-latest-release en lugar de aosp-main para compilar y contribuir a AOSP. Para obtener más información, consulta Cambios en AOSP.
Organiza tus páginas con colecciones
Guarda y categoriza el contenido según tus preferencias.
El Proyecto de código abierto de Android (AOSP) es el código fuente de Android disponible para el público y modificable. Cualquier persona puede descargar y modificar el AOSP para su dispositivo. El AOSP proporciona una implementación completa y totalmente funcional de la plataforma móvil de Android.
La pila de software del AOSP contiene las siguientes capas:
Figura 1: Arquitectura de pila de software AOSP.
A continuación, se incluye una lista de definiciones de los términos que se usan en la Figura 1:
App para Android
Una app creada únicamente con la API de Android. Google Play Store se usa ampliamente para encontrar y descargar apps para Android, aunque existen muchas otras alternativas. En algunos casos, es posible que el fabricante de un dispositivo quiera preinstalar una app para Android que admita la funcionalidad principal del dispositivo. Si te interesa desarrollar apps para Android, consulta developers.android.com.
App con privilegios
Una app creada con una combinación de las APIs de Android y del sistema. Estas apps deben preinstalarse como apps con privilegios en un dispositivo.
App del fabricante del dispositivo
Una app creada con una combinación de la API de Android, la API del sistema y el acceso directo a la implementación del framework de Android. Dado que un fabricante de dispositivos puede acceder directamente a las APIs inestables dentro del framework de Android, estas apps deben estar preinstaladas en el dispositivo y solo se pueden actualizar cuando se actualiza el software del sistema del dispositivo.
API del sistema
La API de System representa las APIs de Android disponibles solo para socios y OEM para su inclusión en aplicaciones integradas. Estas APIs están marcadas como @SystemApi en el código fuente.
API de Android
La API de Android es la API disponible públicamente para los desarrolladores de apps para Android de terceros. Para obtener información sobre la API de Android, consulta la referencia de la API de Android.
Framework de Android
Es un grupo de clases, interfaces y otro código precompilado de Java sobre el que se compilan las apps. Se puede acceder públicamente a partes del framework a través de la API de Android. Otras partes del framework solo están disponibles para los OEM a través del uso de las APIs del sistema. El código del framework de Android se ejecuta dentro del proceso de una app.
Servicios del sistema
Los servicios del sistema son componentes modulares y enfocados, como system_server, SurfaceFlinger y MediaService. La funcionalidad que expone la API del framework de Android se comunica con los servicios del sistema para acceder al hardware subyacente.
Android Runtime (ART)
Un entorno de ejecución de Java proporcionado por AOSP. ART realiza la traducción del código de bytes de la app en instrucciones específicas del procesador que ejecuta el entorno de ejecución del dispositivo.
Capa de abstracción de hardware (HAL)
Una HAL es una capa de abstracción con una interfaz estándar para que los proveedores de hardware la implementen. Los HAL permiten que Android sea independiente de las implementaciones de controladores de nivel inferior. El uso de un HAL te permite implementar funciones sin afectar ni modificar el sistema de nivel superior. Para obtener más información, consulta la descripción general del HAL.
Daemons y bibliotecas nativos
Los daemons nativos en esta capa incluyen init, healthd, logd y storaged. Estos daemons interactúan directamente con el kernel o con otras interfaces, y no dependen de una implementación de HAL basada en el espacio del usuario.
Las bibliotecas nativas en esta capa incluyen libc, liblog, libutils, libbinder y libselinux. Estas bibliotecas nativas interactúan directamente con el kernel o con otras interfaces, y no dependen de una implementación de HAL basada en el espacio del usuario.
Kernel
El kernel es la parte central de cualquier sistema operativo y se comunica con el hardware subyacente de un dispositivo. Cuando es posible, el kernel del AOSP se divide en módulos independientes del hardware y módulos específicos del proveedor. Para obtener una descripción, incluidas las definiciones, de los componentes del kernel de AOSP, consulta la Descripción general del kernel.
Próximos pasos
Si es la primera vez que usas el AOSP y quieres comenzar a desarrollar, consulta la sección de introducción.
Si quieres obtener más información sobre una capa específica del AOSP, haz clic en el nombre de la sección en el menú de navegación de la izquierda y comienza con la descripción general de esa sección.
El contenido y las muestras de código que aparecen en esta página están sujetas a las licencias que se describen en la Licencia de Contenido. Java y OpenJDK son marcas registradas de Oracle o sus afiliados.
Última actualización: 2025-07-24 (UTC)
[[["Fácil de comprender","easyToUnderstand","thumb-up"],["Resolvió mi problema","solvedMyProblem","thumb-up"],["Otro","otherUp","thumb-up"]],[["Falta la información que necesito","missingTheInformationINeed","thumb-down"],["Muy complicado o demasiados pasos","tooComplicatedTooManySteps","thumb-down"],["Desactualizado","outOfDate","thumb-down"],["Problema de traducción","translationIssue","thumb-down"],["Problema con las muestras o los códigos","samplesCodeIssue","thumb-down"],["Otro","otherDown","thumb-down"]],["Última actualización: 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."]]
