Przegląd architektury

Android Open System Platform (AOSP) to publicznie dostępny i modyfikowalny kod źródłowy Androida. Każdy może pobrać i zmodyfikować AOSP dla swojego urządzenia. AOSP zapewnia kompletną iw pełni funkcjonalną implementację platformy mobilnej Android.

Istnieją dwa poziomy kompatybilności urządzeń implementujących AOSP: kompatybilność AOSP i kompatybilność z Androidem. Urządzenie kompatybilne z AOSP musi być zgodne z listą wymagań zawartych w dokumencie definicji zgodności (CDD) . Urządzenie zgodne z systemem Android musi być zgodne z listą wymagań zawartych w CDD i Vendor Software Requirements (VSR) oraz testami, takimi jak te w Vendor Test Suite (VTS) i Compatibility Test Suite (CTS) . Więcej informacji na temat zgodności z systemem Android można znaleźć w programie zgodności z systemem Android .

Architektura AOSP

Stos oprogramowania dla AOSP zawiera następujące warstwy:

Architektura stosu oprogramowania AOSP.

Rysunek 1. Architektura stosu oprogramowania AOSP.

Poniżej znajduje się lista definicji terminów użytych na rysunku 1:

Aplikacja na Androida
Aplikacja stworzona wyłącznie przy użyciu interfejsu Android API. Sklep Google Play jest powszechnie używany do znajdowania i pobierania aplikacji na Androida, chociaż istnieje wiele innych alternatyw. W niektórych przypadkach producent urządzenia może chcieć wstępnie zainstalować aplikację na Androida w celu obsługi podstawowych funkcji urządzenia. Jeśli interesuje Cię tworzenie aplikacji na Androida, odwiedź stronę developers.android.com
Uprzywilejowana aplikacja
Aplikacja stworzona przy użyciu kombinacji interfejsów API systemu Android i systemowych. Te aplikacje muszą być wstępnie zainstalowane jako aplikacje uprzywilejowane na urządzeniu.
Aplikacja producenta urządzenia
Aplikacja stworzona przy użyciu kombinacji Android API, systemowego API i bezpośredniego dostępu do implementacji frameworka Android. Ponieważ producent urządzenia może bezpośrednio uzyskiwać dostęp do niestabilnych interfejsów API w systemie Android, te aplikacje muszą być preinstalowane na urządzeniu i mogą być aktualizowane tylko wtedy, gdy aktualizowane jest oprogramowanie systemowe urządzenia.
Interfejs API systemu
Systemowy interfejs API reprezentuje interfejsy API systemu Android, które są dostępne tylko dla partnerów i producentów OEM i mogą być dołączane do pakietów aplikacji. Te interfejsy API są oznaczone jako @SystemApi w kodzie źródłowym.
Interfejs API Androida
Interfejs API Androida to publicznie dostępny interfejs API dla zewnętrznych programistów aplikacji na Androida. Aby uzyskać informacje na temat interfejsu API systemu Android, zapoznaj się z dokumentacją dotyczącą interfejsu API systemu Android .
Framework Androida
Grupa klas Java, interfejsów i innego wstępnie skompilowanego kodu, na podstawie którego budowane są aplikacje. Fragmenty struktury są publicznie dostępne za pośrednictwem interfejsu API systemu Android. Inne części struktury są dostępne tylko dla producentów OEM za pośrednictwem systemowych interfejsów API. Kod struktury systemu Android jest uruchamiany w procesie aplikacji.
Usługi systemowe
Usługi systemowe to modułowe, ukierunkowane komponenty, takie jak system_server , SurfaceFlinger i MediaService. Funkcjonalność udostępniana przez interfejs API systemu Android komunikuje się z usługami systemowymi w celu uzyskania dostępu do bazowego sprzętu.
Środowisko wykonawcze Androida (ART)
Środowisko uruchomieniowe Java dostarczane przez AOSP. ART wykonuje tłumaczenie kodu bajtowego aplikacji na instrukcje specyficzne dla procesora, które są wykonywane przez środowisko wykonawcze urządzenia.
Warstwa abstrakcji sprzętu (HAL)
HAL to warstwa abstrakcji ze standardowym interfejsem do wdrożenia przez dostawców sprzętu. HAL pozwalają Androidowi być niezależnym od implementacji sterowników niższego poziomu. Korzystanie z warstwy HAL umożliwia implementację funkcjonalności bez wpływu na system wyższego poziomu lub jego modyfikowania. Aby uzyskać więcej informacji, zobacz przegląd HAL .
Natywne demony i biblioteki

Rodzime demony w tej warstwie to init , healthd , logd i storaged . Te demony współdziałają bezpośrednio z jądrem lub innymi interfejsami i nie zależą od implementacji HAL opartej na przestrzeni użytkownika.

Biblioteki natywne w tej warstwie obejmują libc , liblog , libutils , libbinder i libselinux . Te biblioteki natywne współdziałają bezpośrednio z jądrem lub innymi interfejsami i nie zależą od implementacji HAL opartej na przestrzeni użytkownika.

Jądro

Jądro jest centralną częścią każdego systemu operacyjnego i komunikuje się z bazowym sprzętem na urządzeniu. Tam, gdzie to możliwe, jądro AOSP jest podzielone na moduły niezależne od sprzętu i moduły specyficzne dla dostawcy. Opis, w tym definicje, składników jądra AOSP można znaleźć w Przeglądzie jądra .

Co dalej?

  • Jeśli jesteś nowy w AOSP i chcesz rozpocząć programowanie, zapoznaj się z sekcją Pierwsze kroki .
  • Jeśli chcesz dowiedzieć się więcej o konkretnej warstwie AOSP, kliknij nazwę sekcji w lewym panelu nawigacyjnym i zacznij od omówienia tej sekcji.