Przegląd architektury

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 swoje urządzenie. AOSP zapewnia kompletną i w pełni funkcjonalną implementację mobilnej platformy Android.

Istnieją 2 poziomy zgodności urządzeń z AOSP: zgodność z AOSP i zgodność z Androidem. Urządzenie zgodne z AOSP musi spełniać wymagania podane w dokumentacji zdefiniowanej zgodności (CDD). Urządzenie zgodne z Androidem musi spełniać wymagania określone w dokumentach CDD i VSR oraz przechodzić testy takie jak Vendor Test Suite (VTS) i Compatibility Test Suite (CTS). Więcej informacji o zgodności z Androidem znajdziesz w Programie zgodności z Androidem.

Architektura AOSP

Pakiet oprogramowania AOSP zawiera te warstwy:

Architektura stosu oprogramowania AOSP

Rysunek 1. Architektura stosu oprogramowania AOSP

Poniżej znajdziesz listę definicji terminów użytych na rysunku 1:

Aplikacja na Androida
Aplikacja utworzona wyłącznie przy użyciu interfejsu API Androida. Sklep Google Play jest często 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 umożliwić korzystanie z podstawowych funkcji urządzenia. Jeśli chcesz tworzyć aplikacje 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 jako aplikacje uprzywilejowane na urządzeniu.
Aplikacja producenta urządzenia
Aplikacja utworzona przy użyciu kombinacji interfejsu API Androida, interfejsu API systemu i bezpośredniego dostępu do implementacji platformy Androida. Producent urządzenia może mieć bezpośredni dostęp do niestabilnych interfejsów API w ramach frameworka Androida, dlatego te aplikacje muszą być wstępnie zainstalowane na urządzeniu i można je aktualizować tylko po zaktualizowaniu oprogramowania systemowego urządzenia.
System API
Interfejs System API to interfejsy API Androida dostępne tylko dla partnerów i producentów OEM do umieszczania w aplikacji w pakiecie. Te interfejsy API są oznaczone w kodzie źródłowym jako @SystemApi.
Android API
Interfejs Android API jest publicznie dostępny dla deweloperów aplikacji na Androida. Informacje o interfejsie API Androida znajdziesz w dokumentacji interfejsu API Androida.
Framework Androida
Grupa klas Java, interfejsów i innego skompilowanego kodu, na którym są tworzone aplikacje. Niektóre części tej platformy są publicznie dostępne dzięki interfejsowi API Androida. Inne części tej platformy są dostępne tylko dla producentów OEM za pomocą interfejsów API systemu. Kod frameworka Androida jest wykonywany w ramach procesu 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 Androida komunikują się z usługami systemowymi, aby uzyskać dostęp do sprzętu.
środowisko wykonawcze Androida (ART),
Środowisko wykonawcze Java udostępniane przez AOSP. ART dokonuje przetłumaczenia bajtkodu aplikacji na instrukcje procesora, które są wykonywane przez środowisko uruchomieniowe urządzenia.
Warstwa abstrakcji sprzętowej (HAL)
HAL to warstwa abstrakcji z interfejsem standardowym do implementacji przez dostawców sprzętu. Interfejsy HAL pozwalają Androidowi nie przejmować się implementacjami sterowników na niższym poziomie. Zastosowanie interfejsu HAL umożliwia implementację funkcji bez wpływu na system wyższego poziomu lub jego modyfikacji. Więcej informacji znajdziesz w omówieniu HAL.
Natywni demony i biblioteki

Do natywnych demonów na tym poziomie należą init, healthd, logd i storaged. Te demony współpracują bezpośrednio z jądrem lub innymi interfejsami i nie są zależne od implementacji HAL w przestrzeni użytkownika.

Biblioteki natywne na tym poziomie to libc, liblog, libutils, libbinder i libselinux. Biblioteki natywne współpracują bezpośrednio z jądrem lub innymi interfejsami i nie są zależne od implementacji HAL w przestrzeni użytkownika.

Rdzeń

Rdzeń jest centralną częścią każdego systemu operacyjnego i komunikuje się z podstawowym sprzętem na urządzeniu. W miarę możliwości jądro AOSP jest dzielone na moduły niezależne od sprzętu i specyficzne dla dostawcy. Aby uzyskać opis komponentów jądra AOSP, w tym ich definicje, zapoznaj się z artykułem Omówienie jądra.

Co dalej?

  • Jeśli dopiero zaczynasz korzystać z AOSP i chcesz rozpocząć pracę nad aplikacją, zapoznaj się z sekcją Pierwsze kroki.
  • Jeśli chcesz dowiedzieć się więcej o konkretnej warstwie AOSP, kliknij jej nazwę w panelu nawigacyjnym po lewej stronie i zacznij od ogólnego omówienia tej sekcji.