Android Open Source Project

Android Open Source Project або AOSP — це відкритий проєкт, у межах якого доступні вихідний код, документація й базова реалізація операційної системи Android. AOSP є фундаментом, на якому будуються Android-пристрої, кастомні прошивки, vendor-системи, емулятори, дослідницькі збірки та багато комерційних Android-варіантів.

AOSP не потрібно плутати з “усім Android на телефоні”. Android у магазинному смартфоні часто складається з AOSP, драйверів виробника, firmware, Google Mobile Services, застосунків виробника, оболонки, сертифікації та додаткових сервісів.

Основна ідея: AOSP — це відкрита основа Android. Вона дає код платформи, але не автоматично дає Google Play, сертифікацію, драйвери конкретного телефона або готову комерційну прошивку.

Цікавий факт

Android здається “однією ОС”, але насправді це ціла екосистема шарів. AOSP — лише ядро цієї екосистеми в широкому сенсі: framework, системні сервіси, базові застосунки, build system, HAL-інтерфейси, runtime, частина інструментів і документація.

Саме тому два пристрої можуть обидва бути “Android”, але відчуватися дуже по-різному: один має майже чистий AOSP-інтерфейс, інший — важку оболонку виробника, власні застосунки, інший launcher, інші налаштування камери й додаткові сервіси.

Найцікавіше: AOSP — це причина, чому Android може існувати не лише як Google Pixel, а як величезна сім’я пристроїв: смартфони, планшети, телевізори, автомобільні системи, POS-термінали, handheld-пристрої й кастомні прошивки.

Загальний опис

Офіційна документація Android описує AOSP як доступні для всіх документацію й вихідний код Android, які можна використовувати для створення власних варіантів Android OS. :contentReference[oaicite:1]{index=1}

AOSP використовується для:

створення Android-прошивок;
розробки системних компонентів;
портів Android на нові пристрої;
custom ROM;
vendor ROM;
Android TV-подібних систем;
automotive-систем;
embedded Android;
тестування Android framework;
дослідження мобільних ОС;
security research;
навчання системній розробці;
створення GSI;
розробки HAL і драйверної інтеграції;
перевірки сумісності з Android APIs.

Перевага: AOSP дозволяє виробникам і розробникам не створювати мобільну ОС з нуля, а брати готову Android-платформу й адаптувати її під пристрій.

AOSP і Android

Android — це ширша назва операційної системи й екосистеми.

AOSP — це відкритий вихідний код Android-платформи.

Критерій	AOSP	Android на комерційному смартфоні
Код	Відкрита основа Android	AOSP + vendor code + firmware + сервіси + оболонка
Google Play	Не входить за замовчуванням	Є лише на сертифікованих пристроях із GMS
Драйвери	Не містить усіх закритих драйверів конкретного пристрою	Постачається виробником
Інтерфейс	Базовий Android	Може бути Pixel UI, One UI, HyperOS, ColorOS тощо
Призначення	Основа для збірки й кастомізації	Готовий продукт для користувача

Важливо: “Android open source” не означає, що весь Android-смартфон повністю відкритий. Багато компонентів конкретного пристрою можуть бути закритими.

AOSP і Google Mobile Services

Google Mobile Services або GMS — це набір Google-застосунків і сервісів, які не є просто частиною AOSP.

До GMS можуть належати:

Google Play Store;
Google Play Services;
Google Maps;
Gmail;
YouTube;
Google Search;
Google Assistant;
Google Photos;
Firebase/Google API інтеграції в частині застосунків;
push notifications через FCM;
SafetyNet/Play Integrity-подібні сервіси.

AOSP без GMS може працювати як Android-система, але багато звичних користувацьких функцій або застосунків можуть бути відсутніми.

Критично: якщо прошивка базується на AOSP, це ще не означає, що в ній легально або технічно доступні Google Play і Google-сервіси.

Архітектура AOSP

AOSP має багатошарову архітектуру.

Основні шари:

Linux kernel;
hardware abstraction layer;
native libraries;
Android Runtime;
system services;
Android Framework;
system apps;
permissions;
package manager;
media stack;
graphics stack;
telephony;
connectivity;
security model;
build system;
compatibility tools.

Офіційна документація описує AOSP як публічно доступний і змінюваний Android source code, що надає повну й функціональну реалізацію Android mobile platform. :contentReference[oaicite:2]{index=2}

Проста аналогія: AOSP — це не один застосунок і не одне ядро, а цілий набір поверхів: від Linux kernel до кнопок, вікон, дозволів і системних сервісів.

Linux kernel в Android

Android використовує Linux kernel як нижній системний шар.

Kernel відповідає за:

процеси;
пам’ять;
драйвери;
файлові системи;
мережу;
security primitives;
scheduling;
power management;
device nodes;
ізоляцію;
hardware access.

Але Android — це не “звичайний Linux-дистрибутив”. Над kernel є Android-specific шари: Binder IPC, Android Framework, ART, HAL, permission model, package manager і системні сервіси.

Важливо: Android базується на Linux kernel, але не працює як звичайний desktop Linux із GNOME, systemd і класичними пакетними менеджерами.

Hardware Abstraction Layer

Hardware Abstraction Layer або HAL — шар, який допомагає Android працювати з hardware через стандартизовані інтерфейси.

HAL потрібен для:

камери;
аудіо;
сенсорів;
GPS;
Bluetooth;
Wi-Fi;
NFC;
біометрії;
графіки;
радіомодуля;
power management;
vendor-specific hardware.

Практична роль: HAL — це міст між універсальним Android framework і конкретним залізом конкретного телефона.

Android Runtime

Android Runtime або ART — середовище виконання Android-застосунків.

ART відповідає за:

запуск застосунків;
виконання байткоду;
компіляцію;
garbage collection;
performance;
memory management для app runtime;
оптимізацію запуску;
інтеграцію з Android Framework.

Практична роль: ART — одна з причин, чому Android-застосунки можуть запускатися на різних пристроях, не будучи зібраними окремо під кожну модель телефона.

Android Framework

Android Framework — високорівневий шар, через який застосунки працюють із системою.

Framework надає API для:

Activity;
Service;
BroadcastReceiver;
ContentProvider;
permissions;
notifications;
location;
camera;
media;
storage;
window management;
input;
sensors;
telephony;
connectivity;
accessibility.

Суть Framework: застосунок не керує телефоном напряму. Він просить Android Framework зробити потрібну дію через офіційні API.

Binder IPC

Binder — механізм міжпроцесної взаємодії в Android.

Binder потрібен для:

спілкування застосунків із system services;
IPC між процесами;
permission checks;
service manager;
Android Framework;
AIDL;
безпечної взаємодії компонентів;
системної архітектури Android.

Цікавий факт: Binder — одна з тих технологій Android, яку звичайний користувач ніколи не бачить, але без неї Android-застосунки не могли б нормально говорити із системою.

System apps

AOSP містить базові системні застосунки й компоненти, але вони не завжди збігаються з Google-застосунками на комерційному Android.

System apps можуть включати:

launcher;
settings;
dialer;
contacts;
messaging;
camera у базовому вигляді;
package installer;
system UI;
documents UI;
input methods;
basic browser або web components у відповідних збірках.

Важливо: AOSP-застосунок камери або launcher — це не те саме, що Pixel Camera, Samsung Camera або інша vendor-реалізація.

Build system

AOSP має власну систему збірки, яка дозволяє зібрати Android для конкретного target.

Build system працює з:

source tree;
device configuration;
product configuration;
lunch targets;
Soong;
Blueprint;
Make-файлами в частині legacy;
vendor blobs;
kernel artifacts;
system images;
boot images;
OTA packages.

Практична роль: зібрати AOSP — це не просто натиснути “Build”. Потрібно мати device tree, vendor components, правильний target і багато місця на диску.

Repo і manifests

AOSP складається з багатьох Git-репозиторіїв. Для керування ними використовується інструмент Repo і manifest-файли.

Manifest визначає:

які репозиторії потрібні;
які гілки використовувати;
які ревізії завантажити;
структуру source tree;
відповідність релізу;
набір компонентів платформи.

З 27 березня 2025 року офіційна документація рекомендує platform developers використовувати `android-latest-release` замість `aosp-main` для збірки й внесків в AOSP; цей manifest вказує на latest AOSP release branch. :contentReference[oaicite:3]{index=3}

Практична роль: Repo для AOSP — це як диспетчер великої бібліотеки Git-репозиторіїв. Без нього керувати вихідним кодом Android було б значно важче.

Android 16 і AOSP

Android 16 є актуальною великою версією Android у сучасній документації Android. Офіційна сторінка Android Developers зазначала availability of the source code at the Android Open Source Project для Android 16. :contentReference[oaicite:4]{index=4}

Документація AOSP також має release notes для Android 16, Android 16 QPR1 і Android 16 QPR2. :contentReference[oaicite:5]{index=5}

Важливо: актуальна версія Android і доступність конкретних гілок AOSP змінюються, тому для розробки завжди потрібно перевіряти офіційну документацію source.android.com.

Compatibility Definition Document

Compatibility Definition Document або CDD — документ, який описує вимоги сумісності для Android-пристроїв.

CDD важливий для:

виробників пристроїв;
Android compatibility;
API behavior;
hardware requirements;
software requirements;
app compatibility;
сертифікації;
однакової поведінки застосунків;
ecosystem consistency.

Практична роль: CDD допомагає зробити так, щоб Android-застосунок не поводився зовсім по-різному на кожному пристрої.

Compatibility Test Suite

Compatibility Test Suite або CTS — набір тестів для перевірки сумісності Android-пристрою.

CTS перевіряє:

API behavior;
permissions;
security;
media;
graphics;
framework behavior;
app compatibility;
platform requirements;
system behavior;
відповідність CDD.

Важливо: просто зібрати AOSP недостатньо для комерційного Android-пристрою. Потрібна сумісність, тестування й сертифікація.

Project Treble

Project Treble — архітектурний підхід Android, який розділяє Android framework і vendor implementation.

Treble важливий для:

швидших оновлень;
стабільніших vendor interfaces;
розділення system і vendor;
GSI;
porting;
підтримки різних пристроїв;
зменшення залежності framework від vendor-коду.

Проста аналогія: Treble намагається зробити так, щоб “верх Android” можна було оновлювати без повного переписування “низу” від виробника.

Generic System Image

Generic System Image або GSI — generic Android system image, який використовується для тестування сумісності Treble-пристроїв.

GSI корисний для:

перевірки Treble;
тестування AOSP;
development;
compatibility testing;
porting;
debugging vendor implementation;
перевірки чистішого Android system image.

Практична роль: GSI допомагає перевірити, наскільки пристрій може працювати з generic Android system image, а не лише з прошивкою виробника.

Custom ROM

Custom ROM — неофіційна або community-прошивка Android, часто побудована на AOSP.

Custom ROM може додавати:

новий Android для старого пристрою;
інший launcher;
privacy-функції;
root-friendly середовище;
додаткові налаштування;
мінімальні Google-застосунки або їх відсутність;
performance tweaks;
security patches;
інший дизайн;
додатковий контроль.

Важливо: custom ROM може бути корисною, але встановлення прошивки має ризики: bootloop, втрата даних, проблеми з банківськими застосунками, гарантією й безпекою.

LineageOS

LineageOS — один із найвідоміших прикладів custom ROM, побудованих на основі Android/AOSP.

LineageOS показує, як AOSP може стати фундаментом для community-проєкту, який підтримує багато пристроїв, додає власні функції й часто продовжує життя старих смартфонів.

Цікавий факт: завдяки AOSP старий телефон іноді може отримати нове життя через custom ROM, навіть якщо виробник уже давно припинив офіційні оновлення.

Vendor blobs

Vendor blobs — закриті binary-компоненти від виробника пристрою або чипсета.

Вони можуть бути потрібні для:

камери;
GPU;
modem;
Wi-Fi;
Bluetooth;
audio DSP;
sensors;
fingerprint reader;
face unlock hardware;
proprietary firmware;
hardware acceleration.

Критично: навіть якщо AOSP відкритий, повністю відкрита прошивка для реального телефона часто неможлива без заміни або відкриття vendor blobs.

Device tree

Device tree у контексті Android-прошивок — набір конфігурацій і описів, які допомагають зібрати Android для конкретного пристрою.

Device tree може містити:

board configuration;
product makefiles;
partition layout;
kernel parameters;
init scripts;
hardware features;
sepolicy;
vendor integration;
build targets;
device-specific overlays.

Практична роль: AOSP — це загальна платформа, а device tree пояснює, як саме ця платформа має працювати на конкретному телефоні.

SELinux в Android

Android використовує SELinux для mandatory access control.

SELinux допомагає:

ізолювати процеси;
обмежувати system services;
захищати vendor components;
контролювати доступ до файлів;
зменшувати наслідки exploit;
enforce policy;
підтримувати Android security model.

Критично: вимкнення SELinux або permissive-режим у production-прошивці може серйозно знизити безпеку пристрою.

Permissions

Android permission model контролює, до чого застосунки мають доступ.

Дозволи можуть стосуватися:

камери;
мікрофона;
геолокації;
контактів;
SMS;
storage;
Bluetooth;
notifications;
sensors;
background activity;
phone state;
nearby devices.

Правило: AOSP дає permission model, але приватність користувача залежить і від прошивки, і від застосунків, і від налаштувань.

Verified Boot

Android Verified Boot допомагає перевіряти цілісність завантажуваних компонентів.

Verified Boot важливий для:

захисту від підміни system image;
перевірки boot chain;
виявлення модифікацій;
integrity;
device trust;
enterprise security;
захисту користувацьких даних;
сумісності з security expectations.

Практична роль: Verified Boot допомагає користувачу й системі знати, чи не була прошивка змінена неочікуваним способом.

Оновлення Android

AOSP є основою оновлень Android, але шлях оновлення до конкретного смартфона складніший.

Потрібні:

новий AOSP release;
адаптація виробника;
vendor drivers;
kernel updates;
security patches;
carrier testing у частині ринків;
CTS;
OTA infrastructure;
device-specific testing;
підписані образи;
rollout.

Важливо: те, що Android source code доступний, не означає, що всі смартфони одразу отримають оновлення.

Security patches

Android security patches виправляють уразливості в системі, framework, kernel, drivers або vendor-компонентах.

Security patch важливий для:

захисту від відомих exploit;
enterprise compliance;
банківських застосунків;
privacy;
Play Integrity;
довіри до пристрою;
безпечного використання інтернету.

Критично: старий Android без security patches може бути ризиковим, навіть якщо телефон “ще нормально працює”.

Збірка AOSP

Збірка AOSP зазвичай потребує Linux-середовища, багато дискового простору, RAM, інструментів і часу.

Типова логіка:

repo init -u https://android.googlesource.com/platform/manifest -b android-latest-release
repo sync
source build/envsetup.sh
lunch
m

Це спрощений приклад. У реальному проєкті потрібні правильний target, device configuration, vendor blobs, залежності й документація для конкретного пристрою.

Увага: AOSP source tree дуже великий. Перед збіркою потрібно мати достатньо місця на диску й стабільне інтернет-з’єднання.

Розробка AOSP

AOSP-розробка відрізняється від звичайної Android app development.

AOSP-розробник може працювати з:

framework;
native services;
system apps;
HAL;
SELinux policies;
build system;
init;
kernel integration;
device configuration;
CTS failures;
platform APIs;
system permissions;
boot images;
OTA;
debugging system services.

Практична роль: Android app developer створює застосунок для Android, а AOSP developer змінює саму платформу, на якій ці застосунки працюють.

Android Studio і AOSP

Android Studio зазвичай використовується для розробки Android-застосунків, а не для повної збірки AOSP.

Для AOSP частіше потрібні:

Repo;
командний рядок;
Linux build host;
Android build system;
emulator;
adb;
fastboot;
debugging tools;
source.android.com документація.

Важливо: Android Studio і AOSP — пов’язані, але не однакові світи. App development значно простіший за platform development.

adb і fastboot

ADB і fastboot — важливі інструменти Android-розробки й тестування.

ADB використовується для:

shell на пристрої;
встановлення APK;
перегляду logs;
копіювання файлів;
debugging;
керування emulator;
запуску команд.

Fastboot використовується для:

прошивання images;
bootloader-level operations;
factory images;
recovery;
flashing boot/system/vendor images;
unlock/lock bootloader у підтримуваних сценаріях.

Практична роль: adb — це “розмова з Android, коли він запущений”, а fastboot — “розмова з пристроєм на нижчому рівні завантаження”.

AOSP і кастомізація виробників

Виробники пристроїв беруть AOSP і додають власні компоненти.

Вони можуть змінювати:

launcher;
settings;
camera app;
power management;
theming;
system services;
update system;
device care tools;
cloud services;
app store;
gestures;
security features;
AI-функції;
vendor UX;
preinstalled apps.

Цікавий факт: Android на Samsung, Xiaomi, OnePlus, Sony і Pixel має спільну AOSP-основу, але виробники можуть так сильно змінити верхні шари, що користувач бачить зовсім різний досвід.

AOSP і Pixel

Google Pixel використовує Android із Google-сервісами, Pixel-specific features, proprietary components і офіційними оновленнями від Google.

Pixel не дорівнює “чистий AOSP”.

Pixel може містити:

Google Mobile Services;
Pixel Launcher;
Pixel Camera;
proprietary drivers;
Tensor-specific components;
Pixel Feature Drops;
Google AI features;
Play Integrity;
vendor configuration;
device-specific optimizations.

Важливо: Pixel Android близький до Google-бачення Android, але це не голий AOSP.

AOSP і приватність

AOSP без Google-сервісів часто цікавить людей, які хочуть більше контролю над пристроєм.

Можливі privacy-сценарії:

мінімум попередньо встановлених сервісів;
відсутність GMS;
власні open source-застосунки;
контроль permissions;
firewall-рішення;
локальні сервіси;
privacy-focused ROM;
F-Droid-подібні джерела застосунків;
self-hosted sync.

Але приватність залежить від конкретної прошивки.

Критично: AOSP-прошивка не є автоматично приватною. Якщо в ній погані налаштування, застарілі patches або сумнівні застосунки, вона може бути небезпечнішою за офіційний Android.

AOSP і безпека

AOSP має багато security-механізмів, але безпечний Android-пристрій — це не лише AOSP.

Потрібні:

актуальні security patches;
SELinux enforcing;
Verified Boot;
правильні permissions;
захищений bootloader;
шифрування даних;
безпечний update system;
trusted firmware;
vendor patching;
CTS/security testing;
secure key storage;
ізоляція застосунків;
Play Integrity або альтернативні trust-механізми в залежності від екосистеми.

Критично: розблокований bootloader, застаріла custom ROM або permissive SELinux можуть звести нанівець багато переваг Android security model.

AOSP і застосунки

Застосунки для Android зазвичай не “знають”, чи пристрій працює на AOSP, Pixel Android, Samsung One UI або іншій оболонці. Вони працюють через Android APIs.

Але проблеми можуть виникати, якщо застосунок залежить від:

Google Play Services;
Firebase Cloud Messaging;
Google Maps API;
Play Integrity;
billing через Google Play;
proprietary media services;
vendor-specific APIs;
DRM;
push notification infrastructure.

Важливо: AOSP-система без GMS може запускати APK, але не всі застосунки працюватимуть повноцінно.

AOSP і F-Droid

F-Droid часто використовують на AOSP-based або privacy-focused прошивках як джерело open source Android-застосунків.

F-Droid корисний для:

open source apps;
privacy-friendly apps;
альтернатив Google-застосункам;
легких утиліт;
локальних інструментів;
community app ecosystem.

Практична роль: F-Droid часто доповнює AOSP-системи, де немає Google Play або користувач хоче більше open source-застосунків.

AOSP і Android Automotive

AOSP також є основою для automotive-напрямів Android.

Android Automotive OS використовується в автомобільних infotainment-системах і тісніше інтегрується з автомобільним hardware, ніж звичайний Android Auto.

AOSP у automotive-сценаріях важливий для:

infotainment;
vehicle HAL;
multi-display;
audio zones;
car settings;
automotive UX;
Google Automotive Services у сертифікованих сценаріях;
vendor customization;
long-term support.

Цікавий факт: Android може бути не лише в телефоні, а й у машині — але automotive Android має зовсім інші вимоги до безпеки, оновлень і взаємодії з hardware.

AOSP і Android TV

AOSP може бути основою для Android TV-подібних систем, smart TV і медіапристроїв.

У TV-сценаріях важливі:

remote control UX;
Leanback UI;
media playback;
DRM;
HDMI;
audio/video codecs;
streaming apps;
Google TV або vendor UI;
certification;
app compatibility;
low-latency media.

Практична роль: Android TV-пристрій — це не просто телефонний Android на великому екрані. Йому потрібен окремий TV-досвід.

AOSP і Android Things

Android Things був Google-напрямом для IoT, але пізніше був закритий як загальна платформа. Проте сама ідея Android у embedded-сценаріях залишається через vendor-рішення, Android Automotive, Android TV, handheld devices і спеціалізовані пристрої.

Важливо: AOSP можна адаптувати для різних пристроїв, але не кожному embedded-пристрою потрібен повний Android. Для маленьких MCU краще підходять RTOS на кшталт FreeRTOS або Zephyr.

AOSP і ліцензії

AOSP включає код під різними open source-ліцензіями. Значна частина Android-платформи поширюється під Apache License 2.0, але kernel-компоненти пов’язані з GPL через Linux kernel.

Ліцензії важливі для:

виробників;
модифікації коду;
публікації змін;
використання kernel;
compliance;
vendor obligations;
open source notices;
юридичного аудиту;
комерційних продуктів.

Важливо: “Open source” не означає “без правил”. Виробники й розробники мають дотримуватися ліцензійних вимог.

AOSP і форки Android

AOSP дозволяє створювати форки Android.

Форки можуть бути:

vendor ROM;
custom ROM;
privacy-focused OS;
Android без GMS;
enterprise Android;
kiosk OS;
smart TV system;
automotive system;
device-specific firmware;
research OS.

Практична роль: AOSP дає свободу створювати Android-варіанти, але якість такого варіанту залежить від команди, hardware, оновлень і security-процесів.

Переваги AOSP

Основні переваги AOSP:

відкритий вихідний код Android;
можливість кастомізації;
велика екосистема;
Android Framework;
сумісність із Android APIs;
основа для custom ROM;
основа для vendor ROM;
документація;
build system;
security model;
Linux kernel foundation;
HAL-архітектура;
Treble;
GSI;
можливість дослідження й навчання;
глобальний вплив на мобільні пристрої.

Головна перевага: AOSP зробив Android не однією закритою системою, а платформою, яку можуть адаптувати виробники, спільноти й дослідники.

Обмеження AOSP

AOSP має обмеження.

Можливі проблеми:

не містить Google Play за замовчуванням;
не містить усіх proprietary drivers;
не гарантує підтримку конкретного телефона;
складна збірка;
великий source tree;
потрібні vendor blobs;
потрібна device-specific інтеграція;
не всі застосунки працюють без GMS;
потрібні security patches;
custom ROM може бути нестабільною;
сертифікація складна;
оновлення залежать від виробника або maintainer-ів;
camera якість часто залежить від закритих vendor-компонентів.

Помилка: думати, що AOSP можна просто зібрати й одразу отримати повноцінну заміну офіційній прошивці для будь-якого смартфона.

Коли варто використовувати AOSP

AOSP добре підходить, якщо потрібно:

створити Android-based OS;
вивчити архітектуру Android;
розробляти platform-level компоненти;
робити custom ROM;
адаптувати Android для пристрою;
тестувати Android framework;
працювати з HAL;
будувати embedded Android;
створювати GSI;
досліджувати security model;
навчатися системній мобільній розробці;
робити privacy-focused Android-варіант;
створювати kiosk або dedicated device.

Практична порада: AOSP варто вивчати, якщо цікаво не просто писати Android-застосунки, а розуміти, як працює сама Android-платформа.

Коли AOSP може бути невдалим вибором

AOSP може бути не найкращим вибором, якщо:

потрібно просто створити Android-застосунок;
потрібен готовий Google Play-пристрій;
немає команди для підтримки прошивки;
немає vendor blobs;
немає device tree;
потрібна повна сумісність банківських застосунків;
важлива офіційна сертифікація;
потрібні найкращі camera features виробника;
потрібні OTA-оновлення без власної інфраструктури;
потрібна проста ОС для маленького мікроконтролера;
немає часу на build system і debugging.

Важливо: AOSP — це платформа для інженерів і виробників, а не готовий “конструктор прошивки за 5 хвилин”.

Хороші практики AOSP

Рекомендовано:

використовувати офіційну документацію source.android.com;
починати з підтримуваного target або emulator;
використовувати `android-latest-release` для актуальної розробки;
мати достатньо місця на диску;
не змішувати випадкові patches;
контролювати device tree;
документувати vendor blobs;
тримати SELinux enforcing;
запускати CTS/VTS у серйозних проєктах;
перевіряти security patches;
тестувати OTA;
мати backup перед прошиванням;
не зберігати важливі дані на тестових збірках;
вести changelog;
використовувати code review.

Головне правило: AOSP-проєкт — це не лише код. Це ще device support, security, testing, updates, документація й відповідальність за користувача.

Типові помилки початківців

Поширені помилки:

плутати AOSP і Google Android;
чекати Google Play у чистому AOSP;
не враховувати vendor blobs;
не читати device-specific документацію;
вимикати SELinux для “простоти”;
прошивати основний телефон без backup;
не розуміти різницю між app development і platform development;
недооцінювати build time;
не перевіряти CTS;
не оновлювати security patches;
ігнорувати bootloader і Verified Boot;
ставити random ROM із невідомого джерела;
очікувати ідеальну камеру в чистому AOSP.

Небезпека: погано зібрана або застаріла AOSP-прошивка може бути менш безпечною, ніж офіційна прошивка виробника.

Цікаві факти про AOSP

AOSP — це причина, чому Android може існувати в такій кількості форм: телефони, планшети, телевізори, автомобілі, handheld-пристрої й кастомні ROM.
“Чистий AOSP” не означає “Pixel”. Pixel має багато додаткових Google і device-specific компонентів.
Android app developer і AOSP platform developer — це дуже різні ролі.
AOSP source tree настільки великий, що перше завантаження може стати окремим випробуванням для диска й інтернету.
Багато Android-функцій, які користувач сприймає як “просто телефон”, насправді проходять через складний ланцюг: app → framework → system service → HAL → driver → hardware.
AOSP відкритий, але сучасний Android-смартфон часто залежить від закритих camera, modem, GPU і firmware-компонентів.
Custom ROM-спільноти існують саме завдяки тому, що AOSP дає відкриту основу для Android.

Найлюдяніший факт: AOSP — це як “скелет і нервова система” Android. Але щоб отримати готовий телефон, потрібні ще м’язи, шкіра, очі, голос і характер виробника.

Приклади сценаріїв використання

Custom ROM для старого телефона

Розробник бере AOSP, device tree, vendor blobs і patches спільноти, щоб створити новішу Android-прошивку для пристрою, який виробник уже не оновлює.

Android-based kiosk

Компанія створює спеціальну AOSP-збірку для термінала самообслуговування, де користувач бачить лише один контрольований застосунок.

Automotive infotainment

Виробник автомобільної системи використовує Android/AOSP-основу для мультимедіа, навігації й взаємодії з автомобільними сервісами.

Privacy-focused Android

Команда створює Android ROM без Google-сервісів, із посиленими privacy controls і мінімальним набором системних застосунків.

Навчання Android internals

Студент або розробник збирає AOSP в емуляторі, змінює системний компонент і дивиться, як це впливає на роботу Android.

Підказка: найкраще починати з AOSP emulator або офіційно підтримуваних build targets, а не з випадкового телефона без документації.

Приклад спрощеної збірки AOSP

mkdir aosp
cd aosp

repo init -u https://android.googlesource.com/platform/manifest -b android-latest-release
repo sync -c -j8

source build/envsetup.sh
lunch
m

Це лише загальна схема. Для конкретного пристрою потрібні device tree, vendor files, kernel, правильний target і додаткові інструкції.

Важливо: не прошивайте власну збірку на реальний пристрій без повного backup, розуміння bootloader, recovery і способу відновлення.

Джерела

Офіційна документація Android Open Source Project.
AOSP overview.
AOSP architecture overview.
Android 16 release notes.
Android Developers documentation.
Android Compatibility Definition Document.
Android Compatibility Test Suite documentation.
Android security documentation.
Project Treble documentation.
Документація щодо Repo, manifests, GSI, HAL, ART, SELinux, Verified Boot, custom ROM і Android build system.

Висновок

Android Open Source Project — це відкрита основа Android, яка дозволяє створювати власні Android-системи, кастомні прошивки, vendor ROM, automotive-рішення, TV-платформи, dedicated devices і дослідницькі збірки. AOSP дає вихідний код і документацію Android-платформи, але не замінює Google Mobile Services, vendor drivers, сертифікацію, device-specific інтеграцію й процес оновлень.

AOSP важливий не лише для Google чи виробників смартфонів. Він дав світові Android як гнучку платформу, яку можна адаптувати до різних пристроїв і сценаріїв. Водночас робота з AOSP складна: потрібні знання build system, HAL, kernel, SELinux, device tree, vendor blobs, security patches і compatibility testing.

Головна думка: AOSP — це не готовий смартфон у вигляді коду, а фундамент Android. На ньому можна побудувати багато різних систем, але якість результату залежить від інженерії, драйверів, безпеки й підтримки.