Начиная с 27 марта 2025 г. мы рекомендуем использовать android-latest-release вместо aosp-main для создания и участия в AOSP. Дополнительные сведения см. в разделе Изменения в AOSP .
Оптимизируйте свои подборки
Сохраняйте и классифицируйте контент в соответствии со своими настройками.
Проект Android Open Source Project (AOSP) представляет собой общедоступный и модифицируемый исходный код Android. Любой желающий может скачать и модифицировать AOSP для своего устройства. AOSP предоставляет полную и полнофункциональную реализацию мобильной платформы Android.
Для устройств, реализующих AOSP, существует два уровня совместимости: совместимость с AOSP и совместимость с Android. Устройство, совместимое с AOSP, должно соответствовать требованиям, изложенным в документе определения совместимости (CDD) . Устройство, совместимое с Android, должно соответствовать требованиям, изложенным в CDD, а также требованиям к программному обеспечению поставщика (VSR) и тестам, таким как Vendor Test Suite (VTS) и Compatibility Test Suite (CTS) . Дополнительную информацию о совместимости с Android см. в программе совместимости Android .
Архитектура AOSP
Программный стек для AOSP содержит следующие слои:
Рисунок 1. Архитектура программного стека AOSP.
Ниже приведен список определений терминов, используемых на рисунке 1:
Android-приложение
Приложение, созданное исключительно с использованием API Android. Google Play Store широко используется для поиска и загрузки приложений для Android, хотя существует множество других альтернатив. В некоторых случаях производитель устройства может предустанавливать приложение Android для поддержки основных функций устройства. Если вы заинтересованы в разработке приложений для Android, посетите сайт developer.android.com .
Привилегированное приложение
Приложение, созданное с использованием API Android и системных API. Эти приложения должны быть предустановлены на устройстве как привилегированные.
Приложение производителя устройства
Приложение, созданное с использованием комбинации API Android, системного API и прямого доступа к реализации фреймворка Android. Поскольку производитель устройства может напрямую обращаться к нестабильным API фреймворка Android, эти приложения должны быть предустановлены на устройстве и могут обновляться только при обновлении системного ПО устройства.
Системный API
Системный API представляет собой API Android, доступные только партнёрам и OEM-производителям для включения в состав приложений. В исходном коде эти API обозначены как @SystemApi.
API Android
Android API — это общедоступный API для сторонних разработчиков приложений для Android. Информацию об Android API см. в справочнике по Android API .
Android-фреймворк
Группа классов Java, интерфейсов и другого предварительно скомпилированного кода, на основе которого создаются приложения. Некоторые части фреймворка доступны публично через API Android. Другие части фреймворка доступны только OEM-производителям через системные API. Код фреймворка Android выполняется внутри процесса приложения.
Системные службы
Системные службы представляют собой модульные специализированные компоненты, такие как system_server , SurfaceFlinger и MediaService. Функциональность, предоставляемая API фреймворка Android, взаимодействует с системными службами для доступа к базовому оборудованию.
Среда выполнения Android (ART)
Среда выполнения Java, предоставляемая AOSP. ART выполняет преобразование байт-кода приложения в специфичные для процессора инструкции, которые выполняются средой выполнения устройства.
Уровень аппаратной абстракции (HAL)
HAL — это уровень абстракции со стандартным интерфейсом, который могут реализовать поставщики оборудования. HAL позволяют Android не зависеть от реализаций драйверов нижнего уровня. Использование HAL позволяет реализовать функциональность, не влияя на систему верхнего уровня и не изменяя её. Подробнее см. в обзоре HAL .
Собственные демоны и библиотеки
К собственным демонам этого уровня относятся init , healthd , logd и storaged . Эти демоны взаимодействуют напрямую с ядром или другими интерфейсами и не зависят от реализации HAL в пользовательском пространстве.
К нативным библиотекам этого уровня относятся libc , liblog , libutils , libbinder и libselinux . Эти нативные библиотеки напрямую взаимодействуют с ядром или другими интерфейсами и не зависят от реализации HAL в пользовательском пространстве.
Ядро
Ядро является центральной частью любой операционной системы и взаимодействует с аппаратным обеспечением устройства. По возможности ядро AOSP разделено на аппаратно-независимые и специфичные для конкретного производителя модули. Описание компонентов ядра AOSP, включая определения, см. в разделе «Обзор ядра» .
Что дальше?
Если вы новичок в AOSP и хотите приступить к разработке, обратитесь к разделу «Начало работы» .
Если вы хотите узнать больше о конкретном слое AOSP, щелкните название раздела в левой навигационной панели и начните с обзора этого раздела.
Контент и образцы кода на этой странице предоставлены по лицензиям. Java и OpenJDK – это зарегистрированные товарные знаки корпорации Oracle и ее аффилированных лиц.
Последнее обновление: 2025-07-28 UTC.
[[["Прост для понимания","easyToUnderstand","thumb-up"],["Помог мне решить мою проблему","solvedMyProblem","thumb-up"],["Другое","otherUp","thumb-up"]],[["Отсутствует нужная мне информация","missingTheInformationINeed","thumb-down"],["Слишком сложен/слишком много шагов","tooComplicatedTooManySteps","thumb-down"],["Устарел","outOfDate","thumb-down"],["Проблема с переводом текста","translationIssue","thumb-down"],["Проблемы образцов/кода","samplesCodeIssue","thumb-down"],["Другое","otherDown","thumb-down"]],["Последнее обновление: 2025-07-28 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."]]