Omówienie architektury

Projekt Android Open Source Project (AOSP) jest publicznie dostępny i można go modyfikować. Kod źródłowy Androida. Każdy może pobierać i modyfikować AOSP na swoim urządzeniu. Średnia wartość zamówienia zapewnia pełną i w pełni funkcjonalną implementację platformy.

Istnieją 2 poziomy zgodności urządzeń z AOSP: AOSP zgodność aplikacji z Androidem. Urządzenie zgodne z AOSP musi spełniać wymagania listy dokument z definicją zgodności (CDD). An Urządzenie zgodne z Androidem musi być zgodne z listą wymagań określonych w CDD. wymagania dotyczące oprogramowania dostawcy (VSR) oraz testy, takie jak te Vendor Test Suite (VTS) oraz Compatibility Test Suite (CTS). Więcej informacji o zgodności z Androidem znajdziesz w Program zgodności z Androidem

Architektura AOSP

Stos oprogramowania dla AOSP zawiera te warstwy:

Architektura stosu oprogramowania AOSP.

Rysunek 1. Architektura stosu oprogramowania AOSP.

Poniżej znajduje się lista definicji terminów używanych na rys. 1:

W aplikacji na Androida
Aplikacja utworzona wyłącznie przy użyciu interfejsu API Androida. Google Sklep Play jest powszechnie używany do znajdowania i pobierania aplikacji na Androida. wiele innych rozwiązań. W niektórych przypadkach producent urządzenia może chcieć wstępnie zainstalować aplikację na Androida, aby obsługiwała ona główną funkcjonalność urządzenia. Jeśli jeśli chcesz tworzyć aplikacje na Androida, zapoznaj się z developers.android.com.
Aplikacja z podwyższonymi uprawnieniami
Aplikacja utworzona przy użyciu kombinacji interfejsów API Androida i systemowych interfejsów API. Te aplikacje musi być wstępnie zainstalowana na urządzeniu jako aplikacja z odpowiednimi uprawnieniami.
Aplikacja producenta urządzenia
Aplikacja utworzona przy użyciu kombinacji interfejsu API Androida, systemowego interfejsu API i interfejsu bezpośredniego dostępu do platformy Android. Ponieważ producent urządzenia mogą uzyskać bezpośredni dostęp do niestabilnych interfejsów API na platformie Androida, muszą być fabrycznie zainstalowane na urządzeniu i mogą zostać zaktualizowane tylko wtedy, gdy oprogramowanie systemowe.
System API
Interfejs System API reprezentuje interfejsy API Androida dostępne tylko dla partnerów i OEM, którzy chcą dołączyć do aplikacji w pakiecie. Te interfejsy API są oznaczone jako @SystemApi w kodzie źródłowym.
Interfejs API Androida
Android API to publicznie dostępny interfejs API dla aplikacji innych firm na Androida dla programistów. Informacje o interfejsie Android API znajdziesz tutaj: Dokumentacja API na Androida
Platforma Androida
Grupa klas, interfejsów i wstępnie skompilowanego kodu w Javie, do tworzenia aplikacji. Część platformy jest publicznie dostępna w za pomocą interfejsu API Androida. Inne elementy struktury to: dostępne wyłącznie dla producentów OEM za pomocą systemowych interfejsów API. Android, działa w procesie aplikacji.
Usługi systemowe
Usługi systemowe to modułowe, precyzyjne komponenty, takie jak system_server, SurfaceFlinger i MediaService. Funkcje udostępniane przez interfejs Android Framework API komunikuje się z usługami systemowymi, aby uzyskać dostęp do sprzętu.
Środowisko wykonawcze Androida (ART)
Środowisko wykonawcze Java udostępniane przez AOSP. ART wykonuje tłumaczenie kodu bajtowego aplikacji na instrukcje dla konkretnego procesora wykonywane w środowisku wykonawczym urządzenia.
Warstwa abstrakcji sprzętowej (HAL)
HAL to warstwa abstrakcji ze standardowym interfejsem dla dostawców sprzętu do wdrożenia. Listy HAL umożliwiają Androidowi niezależność od sterowników niższego poziomu implementacji. Użycie HAL pozwala wdrożyć funkcje bez wpływając na system wyższego poziomu lub modyfikując jego działanie. Aby uzyskać więcej informacji, zobacz omówienie HAL.
Natywne demony i biblioteki

Natywne demony w tej warstwie to init, healthd, logd oraz storaged Daemony wchodzą w bezpośrednią interakcję z jądrem lub innymi interfejsami i nie wymagają implementacji HAL opartej na przestrzeni użytkownika.

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

Jądro

Jądro stanowi centralną część każdego systemu operacyjnego i komunikuje się bazowego urządzenia. Gdy jest to możliwe, jądro AOSP jest podzielone. w moduły niezależne od sprzętu i moduły związane z konkretnym dostawcą. Aby dodać opis: w tym definicje komponentów jądra AOSP, zapoznaj się z Omówienie jądra systemu.

Co dalej?

  • Jeśli dopiero zaczynasz korzystać z AOSP i chcesz zacząć programować, przeczytaj artykuł znajdziesz w sekcji Pierwsze kroki.
  • Jeśli chcesz dowiedzieć się więcej o konkretnej warstwie AOSP, kliknij w lewym panelu nawigacyjnym i zacząć od omówienia tej sekcji.