Od 27 marca 2025 r. zalecamy używanie android-latest-release zamiast aosp-main do kompilowania i wspołtworzenia AOSP. Więcej informacji znajdziesz w artykule o zmianach w AOSP.
Zadbaj o dobrą organizację dzięki kolekcji
Zapisuj i kategoryzuj treści zgodnie ze swoimi preferencjami.
Projekt Android Open Source (AOSP) to publicznie dostępny i modyfikowalny kod źródłowy Androida. Każdy może pobrać i zmodyfikować AOSP na swoim urządzeniu. AOSP zapewnia kompletną i w pełni funkcjonalną implementację mobilnej platformy Android.
Urządzenia z AOSP mogą być zgodne na 2 poziomach: zgodność z AOSP i zgodność z Androidem. Urządzenie zgodne z AOSP musi spełniać wymagania wymienione w dokumencie definicji zgodności (CDD). Urządzenie zgodne z Androidem musi spełniać wymagania zawarte w dokumentach CDD i VSR oraz przechodzić testy, takie jak te w pakiecie VTS i pakiecie CTS. Więcej informacji o zgodności z Androidem znajdziesz w programie zgodności z Androidem.
Poniżej znajdziesz definicje terminów użytych na ilustracji 1:
Aplikacja na Androida
Aplikacja utworzona wyłącznie przy użyciu interfejsu Android API. Sklep Google Play jest powszechnie używany do wyszukiwania i pobierania aplikacji na Androida, ale istnieje wiele innych alternatyw. W niektórych przypadkach producent urządzenia może chcieć wstępnie zainstalować aplikację na Androida, aby obsługiwać podstawowe funkcje urządzenia. Jeśli interesuje Cię tworzenie aplikacji na Androida, odwiedź stronę developers.android.com.
Aplikacja z uprawnieniami
Aplikacja utworzona przy użyciu kombinacji interfejsów API Androida i systemowych. Te aplikacje
muszą być wstępnie zainstalowane na urządzeniu jako aplikacje uprzywilejowane.
Aplikacja producenta urządzenia
Aplikacja utworzona przy użyciu kombinacji interfejsu Android API, interfejsu systemowego API i bezpośredniego dostępu do implementacji struktury Androida. Ponieważ producent urządzenia może mieć bezpośredni dostęp do niestabilnych interfejsów API w ramach Androida, te aplikacje muszą być wstępnie zainstalowane na urządzeniu i można je aktualizować tylko wtedy, gdy aktualizowane jest oprogramowanie systemowe urządzenia.
System API
Interfejs System API reprezentuje interfejsy API Androida dostępne tylko dla partnerów i producentów OEM do uwzględnienia w aplikacjach pakietowych. Te interfejsy API są oznaczone w kodzie źródłowym jako @SystemApi.
Android API
Android API to publicznie dostępny interfejs API dla deweloperów aplikacji na Androida innych firm. Informacje o interfejsie Android API znajdziesz w dokumentacji interfejsu Android API.
Framework Androida
Grupa klas, interfejsów i innego wstępnie skompilowanego kodu w języku Java, na których opierają się aplikacje. Części platformy są publicznie dostępne dzięki interfejsowi Android API. Pozostałe części platformy są dostępne tylko dla producentów OEM za pomocą interfejsów API systemu. Kod platformy Android działa w procesie aplikacji.
Usługi systemowe
Usługi systemowe to modułowe, wyspecjalizowane komponenty, takie jak system_server, SurfaceFlinger i MediaService. Funkcje udostępniane przez interfejs API platformy Android
komunikują się z usługami systemowymi, aby uzyskać dostęp do sprzętu.
Android runtime (ART)
Środowisko wykonawcze Java udostępniane przez AOSP. ART tłumaczy kod bajtowy aplikacji na instrukcje specyficzne dla procesora, które są wykonywane przez środowisko wykonawcze urządzenia.
Warstwa abstrakcji sprzętowej (HAL)
HAL to warstwa abstrakcji ze standardowym interfejsem, który mogą wdrażać dostawcy sprzętu. Warstwy HAL umożliwiają Androidowi niezależność od implementacji sterowników niższego poziomu. Korzystanie z warstwy HAL umożliwia wdrażanie funkcji bez wpływu na system wyższego poziomu i bez jego modyfikowania. Więcej informacji znajdziesz w omówieniu HAL.
Usługi i biblioteki natywne
Do natywnych demonów w tej warstwie należą init, healthd, logd i storaged. Te demony wchodzą w bezpośrednią interakcję z jądrem lub innymi interfejsami i nie zależą od implementacji HAL opartej na przestrzeni użytkownika.
Biblioteki natywne w tej warstwie to libc, liblog, libutils, libbinder i libselinux. Biblioteki natywne wchodzą w bezpośrednią interakcję z jądrem lub innymi interfejsami i nie zależą od implementacji HAL opartej na przestrzeni użytkownika.
Kernel
Jądro to centralna część każdego systemu operacyjnego, która komunikuje się z podstawowym sprzętem urządzenia. W miarę możliwości jądro AOSP jest dzielone na moduły niezależne od sprzętu i moduły specyficzne dla dostawcy. Opis komponentów jądra AOSP, w tym definicje, znajdziesz w omówieniu jądra.
Co dalej?
Jeśli dopiero zaczynasz korzystać z AOSP i chcesz rozpocząć tworzenie aplikacji, zapoznaj się z sekcją Wprowadzenie.
Jeśli chcesz dowiedzieć się więcej o konkretnej warstwie AOSP, kliknij nazwę sekcji w panelu nawigacyjnym po lewej stronie i zacznij od jej omówienia.
Treść strony i umieszczone na niej fragmenty kodu podlegają licencjom opisanym w Licencji na treści. Java i OpenJDK są znakami towarowymi lub zastrzeżonymi znakami towarowymi należącymi do firmy Oracle lub jej podmiotów stowarzyszonych.
Ostatnia aktualizacja: 2025-07-24 UTC.
[[["Łatwo zrozumieć","easyToUnderstand","thumb-up"],["Rozwiązało to mój problem","solvedMyProblem","thumb-up"],["Inne","otherUp","thumb-up"]],[["Brak potrzebnych mi informacji","missingTheInformationINeed","thumb-down"],["Zbyt skomplikowane / zbyt wiele czynności do wykonania","tooComplicatedTooManySteps","thumb-down"],["Nieaktualne treści","outOfDate","thumb-down"],["Problem z tłumaczeniem","translationIssue","thumb-down"],["Problem z przykładami/kodem","samplesCodeIssue","thumb-down"],["Inne","otherDown","thumb-down"]],["Ostatnia aktualizacja: 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."]]
