Architektura AOSP

Zadbaj o dobrą organizację dzięki kolekcji Zapisuj i kategoryzuj treści zgodnie ze swoimi preferencjami.

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ń w CDD i Vendor Software Requirements (VSR) oraz testami, takimi jak te w Vendor Test Suite (VTS) i Compatability 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.
  • Aplikacja na Androida. Aplikacja utworzona wyłącznie przy użyciu interfejsu API systemu Android w pakiecie Android SDK. 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, przejdź na 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 do produkcji urządzeń. 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.
  • Framework Androida. Grupa klas Java, interfejsów i innego wstępnie skompilowanego kodu, na podstawie którego budowane są aplikacje. Części struktury są publicznie dostępne za pośrednictwem interfejsów API systemu Android SDK. Inne części struktury są dostępne tylko dla producentów OEM za pośrednictwem interfejsów API systemu Android SDK. Kod struktury systemu Android jest uruchamiany w procesie aplikacji.
  • SDK Androida. Zestaw programistyczny do użytku w tworzeniu aplikacji współpracujących ze strukturą Androida. Zestaw Android SDK składa się z interfejsu API systemu Android, dostępnego dla wszystkich aplikacji, oraz systemowego interfejsu API, dostępnego tylko dla aplikacji uprzywilejowanych. Więcej informacji na temat interfejsu API systemu Android SDK można znaleźć na stronie developers.android.com . Pamiętaj, że istnieje również natywny zestaw programistyczny Androida (NDK) , który umożliwia napisanie części aplikacji na Androida przy użyciu natywnego kodu.
  • 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 aplikacji Java dostarczane przez AOSP. ART dokonuje translacji 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 modyfikowania go.
  • 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. Centralna część każdego systemu operacyjnego, jądro 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, przejdź do sekcji Pierwsze kroki .
  • Jeśli chcesz dowiedzieć się więcej o konkretnej warstwie AOSP, kliknij nazwę warstwy w lewym panelu nawigacyjnym i zacznij od przeglądu tej warstwy.