AOSP

AOSP to kod źródłowy i dokumentacja Androida, które Google udostępnia każdemu. Google opisuje go jako pełny produkt dla deweloperów w jakości produkcyjnej, otwarty na dostosowywanie i przenoszenie na inny sprzęt. Możesz z niego zbudować własny wariant systemu Android dla własnych urządzeń. Kod obejmuje sam system operacyjny: od jądra Linux i warstwy abstrakcji sprzętu po framework Androida, środowisko uruchomieniowe i aplikacje systemowe.

Większość AOSP jest na licencji Apache 2.0, którą projekt wskazuje jako preferowaną. Wyjątki rozpatruje się indywidualnie; na przykład poprawki jądra Linux są na licencji GPLv2.

AOSP nie zawiera Google Mobile Services (GMS), czyli według dokumentacji zestawu aplikacji i API Google, które mogą być preinstalowane na urządzeniach. Do tej warstwy należy Google Play. Urządzenie może ubiegać się o licencję na Google Play i GMS tylko wtedy, gdy jest zgodne z Androidem: musi spełniać wymagania dokumentu Compatibility Definition Document (CDD) i przejść testy Compatibility Test Suite (CTS). Zgodność daje prawo do starania się o licencję, ale nie przyznaje jej automatycznie. Android na większości telefonów konsumenckich to więc AOSP z GMS i zmianami producenta, a urządzenie zbudowane na samym AOSP działa na Androidzie bez aplikacji i usług Google.

Google zmieniło sposób publikowania kodu. Od 2026 r. publikuje kod źródłowy w AOSP w II i IV kwartale, a gałąź manifestu android-latest-release zawsze wskazuje najnowsze wydanie opublikowane w AOSP. Poprawki bezpieczeństwa mają własny rytm: biuletyny bezpieczeństwa Androida wychodzą w pierwszy poniedziałek każdego miesiąca, a poprawki bezpieczeństwa platformy trafiają do AOSP 24 do 48 godzin po kwartalnych biuletynach w marcu, czerwcu, wrześniu i grudniu.

Budowa na AOSP daje kontrolę nad całym systemem, a razem z nią każde zadanie, które dla producenta telefonu zwykle wykonuje warstwa Google. Wymagania dla zespołu, który planuje własny system na bazie AOSP:

• Dystrybucja aplikacji należy do Ciebie. Bez Google Play aplikacje trafiają na urządzenia przez Twój własny sklep, kanał zarządzany albo sideloading. Ktoś musi aplikacje sprawdzać, podpisywać i publikować ich aktualizacje.
• Aktualizacje należą do Ciebie. Flota potrzebuje backendu aktualizacji OTA, kluczy do podpisywania wydań, pakietów pełnych i przyrostowych oraz stopniowych wydań. AOSP daje mechanizm aktualizacji na urządzeniu, ale nie daje serwera.
• Poprawki bezpieczeństwa przychodzą według harmonogramu. Każdy miesięczny biuletyn trzeba ocenić, a przy publikacji kodu w II i IV kwartale Twoje zmiany trzeba scalać z bazą, która się przesuwa. Ustal, kto to robi i jak często.
• Obsługa płyty to praca po stronie sprzętu. Sterowniki, jądro i komponenty producenta pochodzą od dostawcy układu i płyty. Bez utrzymywanego pakietu wsparcia płyty (board support package) nowa wersja Androida może nie trafić na Twój sprzęt.
• Zarządzanie flotą bywa częścią systemu. Na urządzeniach firmowych możesz potrzebować funkcji MDM, kontroli sieci, takiej jak inspekcja pakietów, i zdalnego czyszczenia, a we własnym systemie można je wbudować w system operacyjny zamiast dodawać jako aplikację.
• Build wymaga mocnego sprzętu. Google podaje co najmniej 400 GB wolnego miejsca na dysku do pobrania i zbudowania kodu (250 GB na pobranie i 150 GB na build) oraz co najmniej 64 GB RAM na 64-bitowym Linuksie x86. Pełny build trwa około 40 minut na maszynie z 72 rdzeniami i około 6 godzin na maszynie z 6 rdzeniami.

Samo AOSP to kod z licencjami, a nie regulacja. Urządzenie, które ma mieć aplikacje Google, musi przejść program zgodności Androida: CDD wymienia wymagania sprzętowe i programowe, a CTS to bezpłatny zestaw testów dostępny jako plik binarny albo kod źródłowy w AOSP. Urządzenie, które nie stara się o zgodność, może używać kodu w dowolnym zgodnym z prawem celu, ale nie należy do ekosystemu Google Play. W UE podłączone urządzenie zbudowane na AOSP i wprowadzone na rynek jest też produktem z elementami cyfrowymi, więc obowiązki aktualizacji z Cyber Resilience Act opisane w haśle aktualizacja OTA dotyczą go tak samo jak każdego innego urządzenia.

W latach 2019-2021 zbudowaliśmy RAW OS dla Raw Control, utwardzony system telefonu na bazie Androida, zbudowany na CopperheadOS. Wokół systemu zbudowaliśmy sklep z wyłącznie zatwierdzonymi aplikacjami, inspekcję pakietów wewnątrz systemu operacyjnego i zarządzanie urządzeniami z panelem administratora.

Utrzymanie własnego Androida w aktualnej wersji było osobnym projektem. Projekt miał stały strumień prac nad utrzymywaniem zgodności RAW OS ze zmianami w Copperhead i z nowymi urządzeniami: synchronizację naszych repozytoriów z repozytoriami Copperhead oraz przygotowanie i testy systemu na nowy sprzęt. Kiedy Copperhead przeszedł na Androida 11, zespół wyrównał repozytoria, w lipcu 2021 r. zbudował Androida od Copperhead, usunął błędy kompilacji przy scalaniu naszych zmian z frameworks/base, repozytorium frameworka Androida, a w sierpniu uruchomił aplikację Ustawienia i build wydaniowy. Potem nasze funkcje trzeba było po kolei przenieść na nową bazę i sprawdzić, w tym wykrywanie karty SIM. Zadanie uruchomienia RAW OS na Androidzie 11 zamknęliśmy we wrześniu 2021 r.

Dla Mudity pracujemy nad sklepem z aplikacjami i platformą OTA jej telefonów. Nie budowaliśmy systemu operacyjnego Mudity.