Android Open Source Project

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

Android Runtime

Android Open Source Project — це відкрита основа Android, яка дає можливість створювати власні Android-системи, кастомні прошивки, vendor ROM, automotive-рішення, TV-платформи, dedicated devices і дослідницькі збірки. * AOSP overview. критично: “Open source” не означає “без правил”. Перед збіркою потрібно мати достатньо місця на диску й стабільне інтернет-з’єднання. Android на комерційному смартфоні

Build system функціонує з:

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

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

Практична порада: AOSP варто вивчати, якщо цікаво не без зусиль писати Android-застосунки, а розуміти, як функціонує сама Android-платформа. Без нього керувати вихідним кодом Android було б значно важче.== Security patches ==

критично: без зусиль зібрати AOSP недостатньо для комерційного Android-пристрою. * AOSP source tree настільки великий, що перше завантаження здатна стати окремим випробуванням для диска й інтернету. Розробник бере AOSP, device tree, vendor blobs і patches спільноти, щоб створити новішу Android-прошивку для пристрою, який виробник уже не оновлює. Виробники й розробники мають дотримуватися ліцензійних вимог.

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

Automotive infotainment

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

критично: AOSP-застосунок камери або launcher — це не те саме, що Pixel Camera, Samsung Camera або інша vendor-реалізація. AOSP виступає як основою оновлень Android, але шлях оновлення версій до конкретного смартфона складніший.== adb і fastboot ==

Android 16 і AOSP

Найцікавіше: AOSP — це причина, чому Android здатна існувати не лише як Google Pixel, а як величезна сім’я пристроїв: смартфони, планшети, телевізори, автомобільні системи, POS-термінали, handheld-пристрої й кастомні прошивки. критично: Android базується на Linux kernel, але не функціонує як звичайний desktop Linux із GNOME, systemd і класичними пакетними менеджерами. Android security patches виправляють уразливості в системі, framework, kernel, drivers або vendor-компонентах. Якщо в ній погані конфігурація, застарілі patches або сумнівні застосунки, вона здатна бути небезпечнішою за офіційний Android.

критично: “Android open source” не означає, що весь Android-смартфон на 100% відкритий. через Hardware Abstraction Layer або HAL — шар, який користувачі можуть Android працювати з hardware через стандартизовані інтерфейси. Цікавий факт: через AOSP старий телефон іноді здатна отримати нове життя через custom ROM, навіть якщо виробник уже давно припинив офіційні оновлення версій. * Android 16 release notes. Цікавий факт: Binder — одна з тих технологій Android, яку звичайний користувач системи ніколи не бачить, але без неї Android-застосунки не могли б нормально говорити із системою.

запуск застосунків;
виконання байткоду;
компіляцію;
garbage collection;
performance;
memory management для app runtime;
оптимізацію запуску;
інтеграцію з Android Framework. Критично: вимкнення SELinux або permissive-режим у production-прошивці здатна серйозно знизити безпеку пристрою. Custom ROM здатна додавати:

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

Treble важливий для: cd 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. LineageOS показує, як AOSP здатна стати фундаментом для community-проєкту, який підтримує багато пристроїв, додає власні функції й часто продовжує життя старих смартфонів. Цікавий факт: Android здатна бути не лише в телефоні, а й у машині — але automotive Android має зовсім інші вимоги до безпеки, оновлень і взаємодії з hardware.

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

Потрібні:

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

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

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

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

Google Play Services;
Firebase Cloud Messaging;
Google Maps API;
Play Integrity;
billing через Google Play;
proprietary media services;
vendor-specific APIs;
DRM;
push notification infrastructure. :contentReference [oaicite:4]{index=4}

AOSP і Pixel

Vendor blobs

камери;
аудіо;
сенсорів;
GPS;
Bluetooth;
Wi-Fi;
NFC;
біометрії;
графіки;
радіомодуля;
power management;
vendor-specific hardware. * AOSP architecture overview. Водночас робота з AOSP складна: потрібні знання build system, HAL, kernel, SELinux, device tree, vendor blobs, security patches і compatibility testing.== Висновок ==

AOSP — це причина, чому Android здатна існувати в такій кількості форм: телефони, планшети, телевізори, автомобілі, handheld-пристрої й кастомні ROM.

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

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

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

repo sync -c -j8

source build/envsetup.sh

AOSP і Android Things

Офіційна документація описує AOSP як публічно доступний і змінюваний Android source code, що надає повну й функціональну реалізацію Android mobile platform. Правило: AOSP дає permission model, але приватність користувача залежить і від прошивки, і від застосунків, і від налаштувань.

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

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

m

vendor ROM;
custom ROM;
privacy-focused OS;
Android без GMS;
enterprise Android;
kiosk OS;
smart TV system;
automotive system;
device-specific firmware;
research OS. * Android Developers documentation. критично: AOSP-система без GMS здатна запускати APK, але не всі застосунки працюватимуть повноцінно.== Linux kernel в Android ==

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

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

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

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

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

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

створення Android-прошивок;
розробки системних компонентів;
портів Android на нові пристрої;
custom ROM;
vendor ROM;
Android TV-подібних систем;
automotive-систем;
embedded Android;
тестування Android framework;
дослідження мобільних ОС;
security research;
навчання системній розробці;
створення GSI;
розробки HAL і драйверної інтеграції;
перевірки сумісності з Android APIs. Android здається “однією ОС”, але насправді це ціла ERP-платформа шарів. Google Mobile Services або GMS — це набір Google-застосунків і сервісів, які не виступає як без зусиль частиною AOSP.=== Privacy-focused Android ===

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

Проста аналогія: Treble намагається зробити так, щоб “верх Android” можна було оновлювати без повного переписування “низу” від виробника. критично: те, що Android source code доступний, не означає, що всі смартфони одразу отримають оновлення версій. Для маленьких MCU краще підходять RTOS на кшталт FreeRTOS або Zephyr. Compatibility Definition Document або CDD — документ, який описує вимоги сумісності для Android-пристроїв.== Device tree ==

Repo і manifests

створити Android-based OS;
вивчити архітектуру Android;
розробляти platform-level компоненти;
робити custom ROM;
адаптувати Android для пристрою;
тестувати Android framework;
працювати з HAL;
будувати embedded Android;
створювати GSI;
досліджувати security model;
навчатися системній мобільній розробці;
робити privacy-focused Android-варіант;
створювати kiosk або dedicated device. Над kernel виступає як Android-specific шари: Binder IPC, Android Framework, ART, HAL, permission model, package manager і системні сервіси.== AOSP і приватність ==

Android Framework

Repo;
командний рядок;
Linux build host;
Android build system;
emulator;
adb;
fastboot;
debugging tools;
source.android.com документація. Це лише загальна схема.== конкурентні переваги AOSP ==

Framework надає API для:

Android Studio і AOSP

board configuration;
product makefiles;
partition layout;
kernel parameters;
init scripts;
hardware features;
sepolicy;
vendor integration;
build targets;
device-specific overlays. Google Pixel використовує Android із Google-сервісами, Pixel-specific features, proprietary components і офіційними оновленнями від Google.

! F-Droid часто використовують на AOSP-based або privacy-focused прошивках як джерело open source Android-застосунків. AOSP важливий не лише для Google чи виробників смартфонів.== Custom ROM == Custom ROM — неофіційна або community-прошивка Android, часто побудована на AOSP. * не містить Google Play за замовчуванням;

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

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

shell на пристрої;
встановлення APK;
перегляду logs;
копіювання файлів;
debugging;
керування emulator;
запуску команд. AOSP без GMS здатна працювати як Android-система, але багато звичних користувацьких функцій або застосунків можуть бути відсутніми. AOSP має багато security-механізмів, але безпечний Android-пристрій — це не лише AOSP. m

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

розробка програмного забезпечення AOSP

'''Android Verified Boot''' оптимізує перевіряти цілісність завантажуваних компонентів.<div style="background:#eafaf1; border-left:6px solid #2ecc71; padding:12px; margin:12px 0;">

'''критично:''' Pixel Android близький до Google-бачення Android, але це не голий AOSP.== AOSP і застосунки ==
</div>

SELinux оптимізує:

'''Практична роль:''' AOSP дає свободу створювати Android-варіанти, але якість такого варіанту залежить від команди, hardware, оновлень і security-процесів.== Приклади сценаріїв використання ==
Саме тому два пристрої можуть обидва бути “Android”, але відчуватися дуже по-різному: один має майже чистий AOSP-інтерфейс, інший — важку оболонку виробника, власні застосунки, інший launcher, інші конфігурація камери й додаткові сервіси.</div>

Документація AOSP так само має release notes для Android 16, Android 16 QPR1 і Android 16 QPR2. Android permission model контролює, до чого застосунки мають доступ. :contentReference [oaicite:1]{index=1}
<div style="background:#eafaf1; border-left:6px solid #2ecc71; padding:12px; margin:12px 0;">

'''Практична роль:''' Repo для AOSP — це як диспетчер великої бібліотеки Git-репозиторіїв. HAL потрібен для:
<div style="background:#fef2f2; border-left:6px solid #ef4444; padding:12px; margin:12px 0;">

== AOSP і Android Automotive ==

== Тематичні мітки ==

== LineageOS ==
'''ADB''' і '''fastboot''' — важливі інструменти Android-розробки й тестування. * source tree;
* device configuration;
* product configuration;
* lunch targets;
* Soong;
* Blueprint;
* Make-файлами в частині legacy;
* vendor blobs;
* kernel artifacts;
* system images;
* boot images;
* OTA packages. * швидших оновлень;
* стабільніших vendor interfaces;
* розділення system і vendor;
* GSI;
* porting;
* підтримки різних пристроїв;
* зменшення залежності framework від vendor-коду.<div style="background:#eafaf1; border-left:6px solid #2ecc71; padding:12px; margin:12px 0;">

* launcher;
* settings;
* dialer;
* contacts;
* messaging;
* camera у базовому вигляді;
* package installer;
* system UI;
* documents UI;
* input methods;
* basic browser або web components у відповідних збірках. AOSP так само виступає як основою для automotive-напрямів Android. * infotainment;
* vehicle HAL;
* multi-display;
* audio zones;
* car settings;
* automotive UX;
* Google Automotive Services у сертифікованих сценаріях;
* vendor customization;
* long-term support. Значна частина Android-платформи поширюється під Apache License 2.0, але kernel-компоненти пов’язані з GPL через Linux kernel. '''Практична роль:''' зібрати AOSP — це не без зусиль натиснути “Build”. '''Увага:''' AOSP source tree дуже великий.== AOSP і Android TV ==

AOSP містить код під різними open source-ліцензіями. AOSP

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

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

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

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

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

камери;
мікрофона;
геолокації;
контактів;
SMS;
storage;
Bluetooth;
notifications;
sensors;
background activity;
phone state;
nearby devices. * Project Treble documentation. Проте сама ідея Android у embedded-сценаріях залишається через vendor-рішення, Android Automotive, Android TV, handheld devices і спеціалізовані пристрої. Вони працюють через Android APIs.

Compatibility Test Suite

Android використовує Linux kernel як нижній системний шар. :contentReference [oaicite:5]{index=5}

Hardware Abstraction Layer

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-подібні сервіси. * Android Compatibility Test Suite documentation. компанія-користувач створює спеціальну AOSP-збірку для термінала самообслуговування, де користувач системи бачить лише один контрольований застосунок. Android Studio зазвичай застосовується для для розробки Android-застосунків, а не для повної збірки AOSP. :contentReference [oaicite:3]{index=3}

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

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

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

Цікавий факт: Android на Samsung, Xiaomi, OnePlus, Sony і Pixel має спільну AOSP-основу, але виробники можуть так сильно змінити верхні шари, що користувач системи бачить зовсім різний досвід. AOSP дає вихідний код і документацію Android-платформи, але не замінює Google Mobile Services, vendor drivers, сертифікацію, device-specific інтеграцію й бізнес-процес оновлень. * Документація щодо Repo, manifests, GSI, HAL, ART, SELinux, Verified Boot, custom ROM і Android build system.

! критично: AOSP можна адаптувати для різних пристроїв, але не кожному embedded-пристрою потрібен повний Android.

Помилка: думати, що AOSP можна без зусиль зібрати й одразу отримати повноцінну заміну офіційній прошивці для будь-якого смартфона. repo init -u https://android.googlesource.com/platform/manifest -b android-latest-release

Permissions

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

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

CTS перевіряє:

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

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

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

== Цікавий факт ==

* API behavior;
* permissions;
* security;
* media;
* graphics;
* framework behavior;
* app compatibility;
* platform requirements;
* system behavior;
* відповідність CDD. * перевірки Treble;
* тестування AOSP;
* development;
* compatibility testing;
* porting;
* debugging vendor implementation;
* перевірки чистішого Android system image.</div>
З 27 березня 2025 року офіційна документація рекомендує platform developers використовувати `android-latest-release` замість `aosp-main` для збірки й внесків в AOSP; цей manifest вказує на latest AOSP release branch.<div style="background:#e7f3ff; border-left:6px solid #2b7cff; padding:12px; margin:12px 0;">
<div style="background:#e7f3ff; border-left:6px solid #2b7cff; padding:12px; margin:12px 0;">

Device tree здатна містити:

'''Практична роль:''' CDD оптимізує зробити так, щоб Android-застосунок не поводився зовсім по-різному на кожному пристрої. * 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. * новий AOSP release;
* адаптація виробника;
* vendor drivers;
* kernel updates;
* security patches;
* carrier testing у частині ринків;
* CTS;
* OTA infrastructure;
* device-specific testing;
* підписані образи;
* rollout. Це спрощений приклад.</div>
Дозволи можуть стосуватися:
<div style="background:#fff7ed; border-left:6px solid #fb923c; padding:12px; margin:12px 0;">
<div style="background:#fdecea; border-left:6px solid #e74c3c; padding:12px; margin:12px 0;">
Вони можуть змінювати:

<div style="background:#fff4e5; border-left:6px solid #f39c12; padding:12px; margin:12px 0;">

</div>
'''Android''' — це ширша назва операційної системи й екосистеми. Але приватність залежить від конкретної прошивки. Багато компонентів конкретного пристрою можуть бути закритими.<div style="background:#fdecea; border-left:6px solid #e74c3c; padding:12px; margin:12px 0;">

== Джерела ==

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

<div style="background:#fff4e5; border-left:6px solid #f39c12; padding:12px; margin:12px 0;">

<div style="background:#eafaf1; border-left:6px solid #2ecc71; padding:12px; margin:12px 0;">
Збірка AOSP зазвичай потребує Linux-середовища, багато дискового простору, RAM, інструментів і часу. * Android security documentation. '''Проста аналогія:''' AOSP — це не один застосунок і не одне ядро, а цілий набір поверхів: від Linux kernel до кнопок, вікон, дозволів і системних сервісів. '''Практична роль:''' AOSP — це загальна платформа, а device tree пояснює, як саме ця платформа має працювати на конкретному телефоні. Окремо варто відзначити у межах якого доступні вихідний код, документація й базова реалізація операційної системи Android виступає ключовою рисою '''Android Open Source Project''' або '''AOSP'''. У реальному проєкті потрібні правильний target, device configuration, vendor blobs, залежності й документація для конкретного пристрою.== System apps ==

* 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. * “Чистий AOSP” не означає “Pixel”.<div style="background:#fff4e5; border-left:6px solid #f39c12; padding:12px; margin:12px 0;">
</div>
</div>

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

source build/envsetup.sh

{| class="wikitable"

Вони можуть бути потрібні для:
'''критично:''' custom ROM здатна бути корисною, але встановлення прошивки має ризики: bootloop, втрата даних, проблеми з банківськими застосунками, гарантією й безпекою. AOSP не потрібно плутати з “усім Android на телефоні”. Критерій
== Див. так само ==
'''Критично:''' якщо прошивка базується на AOSP, це ще не означає, що в ній легально або технічно доступні Google Play і Google-сервіси. '''Критично:''' розблокований bootloader, застаріла custom ROM або permissive SELinux можуть звести нанівець багато переваг Android security model. Це ще device support, security, testing, updates, документація й відповідальність за користувача. ADB застосовується для для:
'''Практична роль:''' GSI оптимізує перевірити, наскільки пристрій здатна працювати з generic Android system image, а не лише з прошивкою виробника. * плутати 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. На ньому можна побудувати багато різних систем, але якість результату залежить від інженерії, драйверів, безпеки й підтримки. * актуальні security patches;
* SELinux enforcing;
* Verified Boot;
* правильні permissions;
* захищений bootloader;
* шифрування даних;
* безпечний update system;
* trusted firmware;
* vendor patching;
* CTS/security testing;
* secure key storage;
* ізоляція застосунків;
* Play Integrity або альтернативні trust-механізми в залежності від екосистеми. Він дав світові Android як гнучку платформу, яку можна адаптувати до різних пристроїв і сценаріїв. * Android app developer і AOSP platform developer — це дуже різні ролі. Йому потрібен окремий TV-досвід. * Custom ROM-спільноти існують саме через тому, що AOSP дає відкриту основу для Android. '''Критично:''' навіть якщо AOSP відкритий, на 100% відкрита прошивка для реального телефона часто неможлива без заміни або відкриття vendor blobs.<div style="background:#fff4e5; border-left:6px solid #f39c12; padding:12px; margin:12px 0;">
== AOSP і ліцензії ==
<div style="background:#e7f3ff; border-left:6px solid #2b7cff; padding:12px; margin:12px 0;">

== AOSP і Android ==

Команда створює Android ROM без Google-сервісів, із посиленими privacy controls і мінімальним набором системних застосунків. '''Android Runtime''' або '''ART''' — середовище виконання Android-застосунків.</div>

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

* remote control UX;
* Leanback UI;
* media playback;
* DRM;
* HDMI;
* audio/video codecs;
* streaming apps;
* Google TV або vendor UI;
* certification;
* app compatibility;
* low-latency media. До GMS можуть належати:

AOSP здатна бути основою для Android TV-подібних систем, smart TV і медіапристроїв. Офіційна сторінка Android Developers зазначала availability of the source code at the Android Open Source Project для Android 16.<div style="background:#e8f8f5; border-left:6px solid #16a085; padding:12px; margin:12px 0;">

<div style="background:#fdecea; border-left:6px solid #e74c3c; padding:12px; margin:12px 0;">
'''Найлюдяніший факт:''' AOSP — це як “скелет і нервова платформа” Android. AOSP застосовується для для:

</div>
== Build system ==
'''Критично:''' старий Android без security patches здатна бути ризиковим, навіть якщо телефон “ще нормально функціонує”. * Android Compatibility Definition Document.== Збірка AOSP ==

'''Android Framework''' — високорівневий шар, через який застосунки працюють із системою. AOSP виступає як фундаментом, на якому будуються Android-пристрої, кастомні прошивки, vendor-системи, емулятори, дослідницькі збірки і багато комерційних Android-варіантів. Для керування ними застосовують, коли потрібно інструмент '''Repo''' і manifest-файли.<div style="background:#fff4e5; border-left:6px solid #f39c12; padding:12px; margin:12px 0;">

<div style="background:#f0eaff; border-left:6px solid #8e44ad; padding:12px; margin:12px 0;">

mkdir aosp

<div style="background:#fdecea; border-left:6px solid #e74c3c; padding:12px; margin:12px 0;">

* виробників пристроїв;
* Android compatibility;
* API behavior;
* hardware requirements;
* software requirements;
* app compatibility;
* сертифікації;
* однакової поведінки застосунків;
* ecosystem consistency. App development значно простіший за platform development. '''AOSP''' — це відкритий вихідний код Android-платформи. * Activity;
* Service;
* BroadcastReceiver;
* ContentProvider;
* permissions;
* notifications;
* location;
* camera;
* media;
* storage;
* window management;
* input;
* sensors;
* telephony;
* connectivity;
* accessibility. * Багато Android-функцій, які користувач системи сприймає як “без зусиль телефон”, насправді проходять через складний ланцюг: app → framework → system service → HAL → driver → hardware. '''Небезпека:''' погано зібрана або застаріла AOSP-прошивка здатна бути менш безпечною, ніж офіційна прошивка виробника. * Офіційна документація Android Open Source Project. Android використовує SELinux для mandatory access control. Потрібна сумісність, тестування й сертифікація. Android у магазинному смартфоні часто складається з AOSP, драйверів виробника, firmware, Google Mobile Services, застосунків виробника, оболонки, сертифікації та додаткових сервісів. * процеси;
* пам’ять;
* драйвери;
* файлові системи;
* мережу;
* security primitives;
* scheduling;
* power management;
* device nodes;
* ізоляцію;
* hardware access. * прошивання images;
* bootloader-level operations;
* factory images;
* recovery;
* flashing boot/system/vendor images;
* unlock/lock bootloader у підтримуваних сценаріях. * ізолювати процеси;
* обмежувати system services;
* захищати vendor components;
* контролювати доступ до файлів;
* зменшувати наслідки exploit;
* enforce policy;
* підтримувати Android security model.<div style="background:#e7f3ff; border-left:6px solid #2b7cff; padding:12px; margin:12px 0;">

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

Android 16 виступає як актуальною великою версією Android у сучасній документації Android.== Обмеження AOSP ==

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

Compatibility Definition Document

Практична роль: Android app developer створює застосунок для Android, а AOSP developer змінює саму платформу, на якій ці застосунки працюють. це відкритий проєкт. * AOSP відкритий, але сучасний Android-смартфон часто залежить від закритих camera, modem, GPU і firmware-компонентів.

оновлення версій Android

SELinux в Android

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

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

Verified Boot

Fastboot застосовується для для:

які репозиторії потрібні;
які гілки використовувати;
які ревізії завантажити;
структуру source tree;
відповідність релізу;
набір компонентів платформи. Практична роль: Android TV-пристрій — це не без зусиль телефонний Android на великому екрані.=== Android-based kiosk ===

критично: AOSP — це платформа для інженерів і виробників, а не готовий “конструктор прошивки за 5 хвилин”. Застосунки для Android зазвичай не “знають”, чи пристрій функціонує на AOSP, Pixel Android, Samsung One UI або іншій оболонці. Vendor blobs — закриті binary-компоненти від виробника пристрою або чипсета. Для конкретного пристрою потрібні device tree, vendor files, kernel, правильний target і додаткові інструкції. Але щоб отримати готовий телефон, потрібні ще м’язи, шкіра, очі, голос і характер виробника.== Generic System Image ==

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

Виробник автомобільної системи використовує Android/AOSP-основу для мультимедіа, навігації й взаємодії з автомобільними сервісами. Android Things був Google-напрямом для IoT, але пізніше був закритий як загальна платформа.== AOSP і безпека == критично: Android Studio і AOSP — пов’язані, але не однакові світи.== Binder IPC ==

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

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

SEO title: Android Open Source Project — відкрита основа Android для пристроїв, прошивок, виробників і розробників

SEO keywords: Android Open Source Project, AOSP, Android source code, Android OS, Android platform, Android Framework, Linux kernel, HAL, ART, Android Runtime, Repo, manifest, android-latest-release, Android 16, GMS, Google Mobile Services, CTS, CDD, Project Treble, GSI, custom ROM, LineageOS, mobile operating system, open source Android

</noinclude>
 {{SEO
Шаблон для службового SEO-опису сторінки.

}}

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. AOSP добре підходить, якщо потрібно:

Основна ідея: AOSP — це відкрита основа Android. Kernel відповідає за:

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

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

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

Manifest визначає:

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

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

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

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

Суть Framework: застосунок не керує телефоном напряму. :contentReference [oaicite:2]{index=2}

всіх документацію й вихідний код Android забезпечується через Офіційна документація Android описує AOSP як доступні; так само реалізовано які можна використовувати для створення власних варіантів Android OS. Pixel має багато додаткових Google і device-specific компонентів. Потрібно мати device tree, vendor components, правильний target і багато місця на диску.

lunch

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

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

AOSP має багатошарову архітектуру. Binder — механізм міжпроцесної взаємодії в Android. Потрібні:

AOSP дає можливість створювати форки Android.

AOSP і Google Mobile Services

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. Pixel здатна містити:

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

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

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

GPU;
modem;
Wi-Fi;
Bluetooth;
audio DSP;
sensors;
fingerprint reader;
face unlock hardware;
proprietary firmware;
hardware acceleration.

Студент або розробник збирає AOSP в емуляторі, змінює системний компонент і дивиться, як це впливає на роботу Android. repo init -u https://android.googlesource.com/platform/manifest -b android-latest-release

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