→ Архітектура комп'ютера для андроїда. Внутрішній пристрій Android

Архітектура комп'ютера для андроїда. Внутрішній пристрій Android

програмне забезпечення проміжного шару, лежить набір бібліотек (Libraries), призначений на вирішення типових завдань, потребують високої ефективності. Тобто, саме цей рівень відповідає за надання реалізованих алгоритмів для вищих рівнів, підтримку файлових форматів, здійснення кодування та декодування інформації (наприклад можна навести мультимедійні кодеки), малювання графіки та багато іншого. Бібліотеки реалізовані на C/C++ та скомпільовані під конкретне апаратне забезпеченняпристрої, разом з яким вони і поставляються виробником у встановленому вигляді.

Перерахуємо деякі з низькорівневих бібліотек:

  1. Surface Manager - в ОС Android використовується композитний менеджер вікон, на зразок Compiz (Linux), але більш примітивний. Замість того, щоб робити малювання графіки безпосередньо в буфер дисплея, система посилає команди малювання, що надходять, в закадровий буфер, де вони накопичуються разом з іншими, складаючи якусь композицію, а потім виводяться користувачеві на екран. Це дозволяє системі створювати цікаві безшовні ефекти, реалізувати прозорість вікон та плавні переходи.
  2. Media Framework – бібліотеки, реалізовані на базі PacketVideo OpenCORE. З їх допомогою система може здійснювати запис та відтворення аудіо та відео даних, а також виведення статичних зображень. Підтримуються багато популярних форматів, включаючи MPEG4, H.264, MP3, AAC, AMR, JPG та PNG. У майбутньому на зміну OpenCORE має прийти простіший фреймворк Stagefright.
  3. SQLite - легковажна і продуктивна реляційна СУБД, що використовується в Android як основний двигун для роботи з базами даних.
  4. 3D бібліотеки – використовуються для високооптимізованого малювання 3D-графіки, при можливості використовують апаратне прискорення. Їхні реалізації будуються на основі API OpenGL ES 1.0.
  5. FreeType – бібліотека для роботи з бітовими картами, а також для розтеризації шрифтів та здійснення операцій над ними. Це високоякісний движок для шрифтів та відображення тексту.
  6. LibWebCore – бібліотеки відомого браузерного движка WebKit, що використовується також у десктопних браузерах Google Chrome та Apple Safari.
  7. SGL (Skia Graphics Engine) – відкритий двигун для роботи з 2D-графікою. Графічна бібліотека є продуктом Google і часто використовується в інших програмах.
  8. SSL – бібліотеки для підтримки однойменного криптографічного протоколу на базі OpenSSL.
  9. libc – бібліотека стандартних викликів мови C, аналог glibc (GNU libc з Linux) для маленьких пристроїв. Зветься Bionic.


Мал. 1.5.

На цьому рівні розташовується Android Runtime - середовище виконання прикладних програм. Ключовими її складовими є набір стандартних бібліотек та віртуальна машинаДальвік. Кожна програма в ОС Android запускається у власному примірнику віртуальної машини Dalvik. Таким чином, усі працюючі процеси ізольовані від операційної системи та один від одного. Архітектура Android Runtime така, що робота програм здійснюється строго в рамках оточення віртуальної машини. Завдяки цьому здійснюється захист ядра операційної системи від можливої ​​шкоди з боку її складових. Тому код з помилками або шкідливе програмне забезпечення не зможуть зіпсувати ОС Android і пристрій на її базі. Така захисна функція поряд з виконанням програмного коду є однією з ключових для Android Runtime.

Рівнем вище розташовується Application Framework, який іноді називається рівнем каркасу додатків. Саме через каркаси додатків розробники отримують доступ до API, що надаються компонентами системи, що лежать нижче рівня. Крім того, завдяки архітектурі фреймворку будь-якому додатку надаються вже реалізовані можливості інших додатків, до яких дозволено отримувати доступ. У базовий набір сервісів і систем, що лежать в основі кожної програми та є частинами фреймворку, входять:

  1. Багатий і розширюваний набір уявлень (Views), який може бути використаний для створення візуальних компонентів додатків, наприклад списків, текстових полів, таблиць, кнопок або навіть вбудованого веб-браузера.
  2. Контент-провайдери (Content Providers), що управляють даними, які одні програми відкривають для інших, щоб ті могли їх використовувати для своєї роботи.
  3. Менеджер ресурсів (Resource Manager), що забезпечує доступ до ресурсів, що не несуть коду, наприклад, до рядкових даних, графіки, файлів та інших.
  4. Менеджер оповіщень (Notification Manager), завдяки якому всі програми можуть відображати власні повідомлення користувача в рядку стану.
  5. Менеджер дій (Activity Manager), який керує життєвими циклами програм, зберігає дані про історію роботи з діями, а також надає систему навігації за ними.
  6. Менеджер розташування (Location Manager), що дозволяє програмам періодично отримувати оновлені дані про поточне географічне розташування пристрою.

На вершині програмного стека Android лежить рівень додатків (Applications). Сюди відноситься набір базових програм, який встановлений на ОС Android. Наприклад, до нього входять браузер, поштовий клієнт, програма для відправки SMS, карти, календар, менеджер контактів та багато інших. Список інтегрованих програм може змінюватись в залежності від моделі пристрою та версії Android. І крім цього базового набору до рівня програм відносяться всі прикладні програми під платформу Android, у тому числі й встановлені користувачем.

Як правило, програми під Android пишуться мовою Java, але існує можливість розробляти програми і на C/C++ (за допомогою Native Development Kit). Екзотикою можна назвати використання Basic (за допомогою Simple) та інших мов. Також можна створювати власні програми за допомогою конструкторів програм, таких як App Inventor.

1.6. Особливості ядра

Ядро є найважливішою частиною ОС Linux, і на відміну від інших його частин було перенесено в ОС Android майже повністю. Проте в процесі перенесення на ядро ​​було накладено близько 250 патчів.

У ядрі ОС Android було вирішено відмовитися від засобів міжпроцесної взаємодії ОС Linux і замість них створити єдиний механізм, названий Binder. Binder дозволяє викликати методи одного процесу з іншого процесу, передаючи їм аргументи та отримуючи результат, подібно до того, як методи викликаються всередині одного процесу. Binder виконує цю роботу з мінімальним використанням пам'яті.

Для забезпечення налагодження на маленьких пристроях в ядро ​​додано висновок налагоджувальної інформації послідовний портта реалізована підтримка команди logcat.

Великі зміни торкнулися роботи із пам'яттю. Традиційна пам'ять Linux shmem, що розділяється, була замінена на ashmem. Те ж завдання, але на рівні фізичної пам'яті вирішується за допомогою драйвера pmem. Доданий спеціальний обробник нестачі пам'яті (out of memory), названий Viking Killer, у найпростішому випадку він просто вбиває процес, але можуть бути задані складніші правила.

У мережевий стек додано нові налаштування безпеки, підтримка файлової системи для флеш-носіїв YAFFS2 включена в ядро ​​.

1.7. Java-машина Dalvik

Dalvik Virtual Machine є частиною мобільної платформи Android. Це віртуальна машина, автором якої є Ден Бронштейн Вона поширюється як вільне програмне забезпеченняпід BSD-сумісною ліцензією Apache 2.0. Багато в чому саме цей факт зіграв свою роль у вирішенні Google відмовитися від JME (Java Micro Edition), на яку необхідно було б отримати ліцензію від Sun. Тому корпорація, метою якої було створення відкритої операційної системи, розробило свою власну віртуальну машину.

На відміну від більшості віртуальних машин (тієї ж Java Virtual Machine), які є стек-орієнтованими, Dalvik є регістр-орієнтованою, що не можна назвати стандартним рішенням. З іншого боку, воно дуже добре підходить для роботи на процесорах RISC-архітектури, до яких відносяться і процесори ARM, які дуже широко застосовуються в мобільних пристроях.

Dalvik проектувалася спеціально під платформу Android. Враховувався той факт, що платформа будує всі процеси як ізольовані, що виконуються кожен у своєму адресному просторі. Віртуальна машинаоптимізована для низького споживання пам'яті та роботи на мобільному апаратному забезпеченні. Починаючи з версії Android 2.2, Dalvik використовує JIT (Just-in-Time) компіляцію. В результаті цих особливостей, вийшла швидка та продуктивна віртуальна машина, що може позначатися роботі додатків загалом.

Dalvik використовує свій байт-код. Під час розробки програми під Android перекладаються компілятором у спеціальний машинно-незалежний низькорівневий код. При виконанні на платформі саме Dalvik інтерпретує та виконує таку програму.

Крім того, Dalvik здатна переводити байт-код Java в коди власного формату і також виконувати їх у своєму віртуальному середовищі. Програмний код пишеться мовою Java, а після компіляції все. class файли конвертуються у формат.dex (придатний для інтерпретації Dalvik) за допомогою спеціальної утиліти dx, що входить до складу Android SDK .

1.8. Bionic

Bionic – бібліотека стандартних викликів мови C, що розповсюджується під ліцензією BSD (Berkeley Software Distribution – система поширення програмного забезпечення у вихідних кодах, створена для обміну досвідом між навчальними закладами) та розроблена Google для Android. У bionic відсутні деякі функції POSIX, що не використовуються в Android, доступні в повній реалізації glibc.

Основні відмінності bionic:

  1. BSD ліцензії: Android використовує Linux ядро, яке знаходиться під GNU General Public License (GPL), але Google побажав ізолювати програми для Android від наслідків GPL. GNU libc, який зазвичай використовується з ядром Linux, знаходиться під ліцензією GNU LGPL, як альтернативний uClibc.
  2. Мінімальні розміри: об'єктний код bionic набагато менше (приблизно в 2 рази), ніж glibc і трохи менше, ніж uclibc.
  3. Bionic призначена для процесорів з відносно низькими тактовими частотами.
  4. зрізана, але ефективна реалізація ниток POSIX.

1.9. Огляд Java-інтерфейсів прикладного програміста

Для прикладного програміста Android - набір інтерфейсів на мові Java. Розглянемо, як його організовано. В основі набору - пакети, що входять до стандарту мови Java, такі як java.util, java.lang, java.io. Вони є на будь-якій платформі, де можуть бути запущені java-програми, і неспецифічні для Android. До них примикають розширення, які до стандарту мови не входять, але де-факто давно є стандартними - пакети javax.net, javax.xml.

Також в Android включені менш поширені розширення Java-пакет org.apache.http, найбільша реалізація протоколу HTTP. Пакет org.json відповідає за серіалізацію об'єктів JavaScript та підтримку технології AJAX. Пакет org.w3c.dom забезпечує об'єктну модель документа

Файлова система є свого роду структуру тієї чи іншої накопичувача. Вона відповідає за те, який максимальний обсяг файлу можна зберегти в пам'яті, довжину їх назв, а також організацію циклів запису або читання. Файлові системи виступають у ролі посередників між програмним кодом та фізичним вмістилищем.

Для різних операційних систем та типів пристроїв існують окремі ФС та гаджети на ОС Android, не є винятком. Давайте розберемося, які файлові системи підтримує Android і з якою метою використовується кожна з них?

1. Yaffs та Yaffs2

Автор файлової системи Yaffs (Yet Another Flash File System) є Чарльз Меннінг, родом з Нової Зеландії. Дана ФС призначається для роботи флеш-накопичувачів і оперативної пам'яті. Основною її перевагою є підвищення термінів експлуатації модулів пам'яті, оскільки система автоматично пропускає комірки, призначені для одноразового запису. Yaffs2 використовувалася для роботи внутрішньої пам'яті гаджетів Android версії 2.2 і 2.3.

2. VFAT

Vfat не є повноцінною самостійною файловою системою, а є розширенням FAT. Допрацьована версія дозволяє зберігати файли з довгими іменами, але за іншими характеристиками є морально застарілою. Vfat може використовуватися на картах пам'яті, а операційні системи на базі ОС Android повністю їх підтримують. В основному це файлова система флешки android.

3. F2FS

F2FS (Flash Friendly File System) – файлова система, яка призначена в першу чергу на роботу з флеш-пам'яттю та SSD-накопичувачами. Розробив її співробітник компанії Samsung, Кім Че Гик, а після публікації вихідного коду її доопрацювали інші інженери компанії. F2FS може використовуватися на картах пам'яті SD/MMC, а також з багатьма іншими типами пам'яті. Для повноцінної кастомізації існує цілий набір утиліт. З переваг можна відзначити гарну гнучкість у налаштуванні, високі показники збереження життєвого циклу блоків пам'яті, а також зберігання даних у вигляді журналу. Хорошу швидкість забезпечує те, що індекси даних зберігаються в оперативну пам'ять, а підтримка F2FS включена в ядро ​​Linux, починаючи з версії 3.8.

4. Ext2-Ext4

Ext2 – Ext4 – основні файлові системи Android. Саме вони використовуються для роботи внутрішнього сховища на більшості сучасних гаджетів, і якщо перші пристрої працювали під версіями Ext2, то починаючи з версії Android 4, основними стали Ext3, а потім і Ext4. Основна відмінність між варіаціями полягає у наявності журналування. Тобто, якщо в процесі запису або читання даних відбувається системний збій, наприклад, несподіване відключення живлення, не станеться втрати або пошкодження даних. Незважаючи на те, що в основному ФС формату Ext використовується в основному в блокових накопичувачах, користувачі можуть встановити даний тип і для карт пам'яті, але без сторонніх утиліт отримати доступ до них з операційних систем, крім Linux, буде неможливо. Файлова система флешки Android зазвичай форматуються у FAT (VFAT) або NTFS, а флеш-пам'ять - у Ext3 або Ext4.

5. UBIFS

mSATA SSD 16 GB Sandisk - SDSA3DD-016G

UBIFS – файлова система, призначена виключно для пам'яті типу NAND (флеш-накопичувачі, що використовуються на мобільних пристроях). Її основна перевага – це зниження зносу носіїв даних. Складається така ФС із двох шарів - UBI (відповідає за роботу та зв'язок з фізичним носієм) та UBIFS (сама файлова система). Розробником UBIFS є компанія Nokia, але зустріти подібну файлову систему можна не тільки на оригінальних пристроях від даного виробника, але й на інших гаджетах, наприклад, китайського виготовлення.

6. Samsung RFS

Samsung RFS – розроблена корейською компанією Samsung файлова система для пристроїв на базі ОС Linux, а одним із різновидів останнього є Android. Призначається фірмова ФС для флеш-пам'яті NAND та використовується у багатьох гаджетах власного виробництва. Для полегшення роботи з файлами використовується таблиця формату FAT, що дозволяє максимально просто зробити запис файлів на флеш-пам'ять та їх читання. Специфіка RFS враховує особливості NAND накопичувачів, що дозволяє збільшити тривалість їхньої експлуатації, а також знизити ймовірність втрати даних при системних збоях та випадкових відключеннях живлення.

7. SDCardFS

Компанія Google тривалий час використовувала у своїх пристроях файлову систему FUSE, але мала ряд недоліків, серед яких необхідно відзначити малу кількість пам'яті, що виділяється під додатки під додатки, а також велике споживання сховища при кешуванні даних. На заміну FUSE прийшла SDCardFS, яка вирішувала ці проблеми, але являла собою свого роду оболонку, що емулює FAT32. Вона надсилає дані файловим системам нижнього рівня, що дозволяє оптимізувати роботу смартфонів, а також виправляє помилки, пов'язані з передачею даних на комп'ютер та назад. SDCardFS по суті не є класичною файловою системою, але значно позначається на швидкості роботи смартфонів або планшетів на Android.

Висновки

Файлові системи Android найрізноманітніші. Серед них є загальні ФС, призначені для роботи з ОС на базі Linux, так і специфічні, які використовуються в NAND-накопичувачах. Незважаючи на таку різноманітність, виробники все ж таки прикладають спільні зусилля для просування та покращення тієї чи іншої файлової системи, оскільки саме від роботи внутрішніх складових залежить майбутнє ринку Android-гаджетів.

Варто також наголосити на тому факті, що над поліпшенням різних файлових систем можуть одночасно працювати конкуруючі концерни, і саме таке об'єднання змушує цифрові технології розвиватися, незалежно від того, наскільки запекла боротьба на споживчому ринку. І тільки виробники смартфонів визначають, яка файлова система на Android працює краще за тих чи інших обставин.

Схожі записи:


Тебе ніколи не цікавило, як працюють fastboot чи ADB? Або чому смартфон під керуванням Android практично неможливо перетворити на цеглу? Чи, можливо, ти давно хотів дізнатися, де криється магія фреймворку Xposed і навіщо потрібні скрипти завантаження /system/etc/init.d? А як щодо консолі відновлення (recovery)? Це частина Android або річ у собі і чому для встановлення сторонньої прошивки звичайний рекавер не підходить? Відповіді на всі ці та багато інших питань ти знайдеш у цій статті.

Як працює Android

Дізнатися про приховані можливості програмних систем можна, зрозумівши принцип їхньої роботи. У деяких випадках це важко, оскільки код системи може бути закритий, але у випадку Android ми можемо вивчити всю систему вздовж і впоперек. У цій статті я не розповідатиму про всі нюанси роботи Android і зупинюся тільки на тому, як відбувається запуск ОС і які події мають місце в проміжку між натисканням кнопки живлення і появою робочого столу.

Принагідно я поясню, що ми можемо змінити в цьому ланцюжку подій і як розробники кастомних прошивок використовують ці можливості для реалізації таких речей, як тюнінг параметрів ОС, розширення простору для зберігання додатків, підключення swap, різних кастомізацій та багато іншого. Всю цю інформацію можна використовувати для створення власних прошивок та реалізації різних хаків та модифікацій.

Крок перший. ABOOT та таблиця розділів

Все починається з первинного завантажувача. Після увімкнення живлення система виконує код завантажувача, записаного в постійну пам'ять пристрою. Потім він передає управління завантажувачу aboot із вбудованою підтримкою протоколу fastboot, але виробник мобільного чіпа або смартфона/планшета має право вибрати будь-який інший завантажувач на його смак. Наприклад, компанія Rockchip використовує власний, несумісний із fastboot завантажувач, для перепрограмування та управління яким доводиться використовувати пропрієтарні інструменти.

Протокол fastboot, у свою чергу, є системою управління завантажувачем з ПК, яка дозволяє виконувати такі дії, як розлочка завантажувача, прошивка нового ядра і recovery, установка прошивки та багато інших. Сенс існування fastboot у тому, щоб мати можливість відновити смартфон у початковий стан у ситуації, коли решта коштів не працюють. Fastboot залишиться на місці, навіть якщо в результаті експериментів ти зітреш зі смартфона всі розділи NAND-пам'яті, що містять Android та recovery.

Отримавши управління, aboot перевіряє таблицю розділів і передає управління ядру, прошитому розділ з ім'ям boot, після чого ядро ​​витягує на згадку RAM-образ з тієї ж розділу і починає завантаження або Android, або консолі відновлення. NAND-пам'ять в Android-пристроях поділена на шість умовно обов'язкових розділів:

  • boot - містить ядро ​​та RAM-диск, зазвичай має розмір у районі 16 Мб;
  • recovery – консоль відновлення, складається з ядра, набору консольних додатків та файлу налаштувань, розмір 16 Мб;
  • system – містить Android, у сучасних девайсах має розмір не менше 1 Гб;
  • cache - призначений для зберігання кешованих даних, також використовується для збереження прошивки в ході OTA-оновлення і тому має розмір, подібний до розмірів розділу system;
  • userdata - містить налаштування, додатки і дані користувача, йому відводиться весь простір NAND-пам'яті, що залишився;
  • misc - містить прапор, визначальний, у якому режимі має вантажитися система: Android чи recovery.

Крім них, також можуть існувати й інші розділи, проте загальна розмітка визначається ще на етапі проектування смартфона і у разі aboot зашивається в код завантажувача. Це означає, що: 1) таблицю розділів не можна вбити, оскільки її можна відновити з допомогою команди fastboot oem format; 2) для зміни таблиці розділів доведеться розлочити та перепрошити завантажувач із новими параметрами. З цього правила, однак, бувають винятки. Наприклад, завантажувач того ж Rockchip зберігає інформацію про розділи в першому блоці NAND-пам'яті, так що для зміни перепрошивка завантажувача не потрібна.

Особливо цікавим є розділ misc. Існує припущення, що спочатку він був створений для зберігання різних налаштувань незалежно від основної системи, але зараз використовується тільки для однієї мети: вказати завантажувачу, з якого розділу потрібно вантажити систему - boot або recovery. Цю можливість, зокрема, використовує програму ROM Manager для автоматичного перезавантаження системи в recovery з автоматичною установкою прошивки. На її основі побудований механізм подвійного завантаження Ubuntu Touch, яка прошиває завантажувач Ubuntu в recovery і дозволяє керувати тим, яку систему вантажити наступного разу. Стер розділ misc - завантажується Android, заповнив даними - завантажується recovery... тобто Ubuntu Touch.

Крок другий. Розділ boot

Якщо в розділі misc не стоїть прапор завантаження в recovery, aboot передає керування кодом, розташованим у розділі boot. Це не що інше, як ядро ​​Linux; воно знаходиться на початку розділу, а відразу за ним слід запакований за допомогою архіваторів cpio та gzip образ RAM-диска, що містить необхідні для роботи Android каталоги, систему ініціалізації init та інші інструменти. Жодної файлової системи на розділі boot немає, ядро ​​і RAM-диск просто йдуть один за одним. Вміст RAM-диска такий:

  • data – каталог для монтування однойменного розділу;
  • dev – файли пристроїв;
  • proc – сюди монтується procfs;
  • res - набір зображень для charger (див. нижче);
  • sbin - набір підсобних утиліт та демонів (adbd, наприклад);
  • sys – сюди монтується sysfs;
  • system – каталог для монтування системного розділу;
  • charger - програма для відображення процесу зарядки;
  • build.prop – системні налаштування;
  • init – система ініціалізації;
  • init.rc – налаштування системи ініціалізації;
  • ueventd.rc - налаштування демона uventd, що входить до складу init.

Це, якщо можна так висловитися, скелет системи: набір каталогів для підключення файлових систем з розділів NAND-пам'яті та система ініціалізації, яка займеться рештою роботи завантаження системи. Центральний елемент тут - додаток init та його конфіг init.rc, про які у всіх подробицях я розповім пізніше. А поки що хочу звернути увагу на файли charger і ueventd.rc, а також каталоги sbin, proc і sys.

Файл charger – це невелика програма, єдине завдання якого – вивести на екран значок батареї. Він не має жодного відношення до Android і використовується тоді, коли пристрій підключається до зарядника у вимкненому стані. В цьому випадку завантаження Android не відбувається, а система просто завантажує ядро, підключає диск RAM і запускає charger. Останній виводить на екран іконку батареї, зображення якої у всіх можливих станах зберігається у PNG-файлах всередині каталогу res.

Файл ueventd.rc є конфігом, що визначає, які файли пристроїв у каталозі sys повинні бути створені на етапі завантаження системи. У заснованих на ядрі Linux системах доступ до заліза здійснюється через спеціальні файли всередині каталогу dev, а їх створення в Android відповідає демон ueventd, що є частиною init. У нормальній ситуації він працює в автоматичному режимі, приймаючи команди створення файлів від ядра, але деякі файли необхідно створювати самостійно. Вони наведені в ueventd.rc.

Каталог sbin в стокове Android не містить нічого, крім adbd, тобто демона ADB, який відповідає за налагодження системи з ПК. Він запускається на ранньому етапі завантаження ОС та дозволяє виявити можливі проблеми на етапі ініціалізації ОС. У кастомних прошивках у цьому каталозі можна знайти купу інших файлів, наприклад mke2fs, яка може бути потрібна, якщо розділи необхідно переформатувати в ext3/4. Також модери часто розміщують туди BusyBox, за допомогою якого можна викликати сотні Linux-команд.

Каталог proc для Linux стандартний, на наступних етапах завантаження init підключить до нього procfs, віртуальну файлову систему, яка надає доступ до інформації про всі процеси системи. До каталогу sys система підключить sysfs, що відкриває доступ до інформації про залізо та його налаштування. За допомогою sysfs можна, наприклад, відправити пристрій у сон або змінити алгоритм енергозбереження, що використовується.

Файл build.prop призначений для зберігання налаштувань Android. Пізніше система обнулює ці налаштування і перезапише їх значеннями з поки що недоступного файлу system/build.prop.


Виноси з тексту

  • Fastboot залишиться на місці, навіть якщо в результаті експериментів ти зітреш зі смартфона вміст усіх розділів NAND-пам'яті
  • Розділ recovery є повністю самодостатнім і містить мініатюрну операційну систему, яка ніяк не пов'язана з Android
  • Злегка змінивши файл fstab, ми можемо змусити init завантажити систему з картки пам'яті

Крок другий, альтернативний. Розділ recovery

У тому випадку, якщо прапор завантаження recovery в розділі misc встановлений або користувач увімкнув смартфон із клавішею зменшення гучності, aboot передасть управління коду, розташованому на початку розділу recovery. Як і розділ boot, він містить ядро ​​та RAM-диск, який розпаковується в пам'ять і стає коренем файлової системи. Однак вміст RAM-диску тут дещо інший.

На відміну від розділу boot, що виступає в ролі перехідної ланки між різними етапами завантаження ОС, розділ recovery є повністю самодостатнім і містить мініатюрну операційну систему, яка ніяк не пов'язана з Android. Recovery має своє ядро, свій набір додатків (команд) і свій інтерфейс, що дозволяє користувачеві активувати службові функції.

У стандартному (стоковому) recovery таких функцій зазвичай всього три: встановлення підписаних ключем виробника смартфона прошивок, вайп та перезавантаження. У модифікованих сторонніх recovery, таких як ClockworkMod та TWRP, функцій набагато більше. Вони вміють форматувати файлові системи, встановлювати прошивки, підписані будь-якими ключами (читай: кастомні), монтувати файлові системи на інших розділах (з метою налагодження ОС) і включають підтримку скриптів, яка дозволяє автоматизувати процес прошивки і багато інших функцій.

За допомогою скриптів, наприклад, можна зробити так, щоб після завантаження recovery автоматично знайшов на карті пам'яті потрібні прошивки, встановив їх та перезавантажився на Android. Ця можливість використовується інструментами ROM Manager, auto-flasher, а також механізмом автоматичного оновлення CyanogenMod та інших прошивок.

Кастомні рекавері також підтримують скрипти бекапу, що знаходяться в каталозі /system/addon.d/. Перед прошивкою recovery перевіряє наявність скриптів і виконує їх перед тим, як зробити прошивку. Завдяки таким скриптам gapps не зникають після встановлення нової версії прошивки.

Команди fastboot

Щоб отримати доступ до fastboot, необхідно встановити Android SDK, підключити смартфон до ПК за допомогою кабелю та увімкнути його, затиснувши обидві кнопки гучності. Після цього слід перейти в підкаталог platform-tools усередині SDK та запустити команду

Fastboot devices

На екрані буде виведено ім'я пристрою. Інші доступні команди:

  • fatsboot oem unlock- розлочка завантажувача на нексусах;
  • update файл.zip- Встановлення прошивки;
  • flash boot boot.img- Прошивка образу boot-розділу;
  • flash recovery recovery.img- прошивка образу розділу recovery;
  • flash system system.img- Прошивка образу системи;
  • oem format- Відновлення зруйнованої таблиці розділів;

Крок третій. Ініціалізація

Отже, отримавши управління, ядро ​​підключає RAM-диск і після ініціалізації всіх своїх підсистем і драйверів запускає процес init, з якого починається ініціалізація Android. Як я вже говорив, init має конфігураційний файл init.rc, з якого процес дізнається про те, що саме він повинен зробити, щоб підняти систему. У сучасних смартфонах цей конфіг має значну довжину в кілька сотень рядків і до того ж має причеп з кількох дочірніх конфігів, які підключаються до основного за допомогою директиви import. Проте його формат досить простий і по суті є набором команд, розділених на блоки.

Кожен блок визначає стадію завантаження або, висловлюючись мовою розробників Android, дію. Блоки відокремлені один від одного директивою on, за якою слідує ім'я дії, наприклад on early-init або on post-fs. Блок команд буде виконано лише у тому випадку, якщо спрацює однойменний тригер. У міру завантаження init по черзі активуватиме тригери early-init, init, early-fs, fs, post-fs, early-boot і boot, запускаючи таким чином відповідні блоки команд.


Якщо файл конфігурації тягне за собою ще кілька конфігів, перерахованих на початку (а це майже завжди так), то однойменні блоки команд усередині них будуть об'єднані з основним конфігом, так що при спрацюванні тригера init виконає команди з відповідних блоків всіх файлів. Це зроблено для зручності формування конфігураційних файлів для декількох пристроїв, коли основний конфіг містить спільні для всіх девайсів команди, а специфічні для кожного пристрою записуються в окремі файли.

Найбільш примітний з додаткових конфігів має ім'я initrc.ім'я_пристрою.rc, де ім'я пристрою визначається автоматично на основі вмісту системної змінної ro.hardware. Це платформно-залежний файл конфігурації, який містить блоки команд, специфічні для конкретного пристрою. Крім команд, які відповідають за тюнінг ядра, він також містить приблизно таку команду:

Mount_all ./fstab.ім'я_пристрою

Вона означає, що тепер init повинен підключити всі файлові системи, перелічені у файлі.

Ім'я_пристрою_(розділу) точка_монтування файлова_система опції_фс інші опції

Зазвичай у ньому містяться інструкції з підключення файлових систем із внутрішніх NAND-розділів до каталогів /system (ОС), /data (налаштування додатків) та /cache (кешовані дані). Однак трохи змінивши цей файл, ми можемо змусити init завантажити систему з карти пам'яті. Для цього достатньо розбити карту пам'яті на три 4 розділи: 1 Гб / ext4, 2 Гб / ext4, 1 Гб / ext4 і простір fat32, що залишився. Далі необхідно визначити імена розділів картки пам'яті в каталозі /dev (для різних пристроїв вони відрізняються) та замінити ними оригінальні імена пристроїв у файлі fstab.


В кінці блоку boot init, швидше за все, зустріне команду class_start default, яка повідомить, що далі слід запустити всі перераховані в конфізі служби, що стосуються класу default. Опис служб починається з директиви service, за якою слідує ім'я служби та команда, яка має бути виконана для її запуску. На відміну від команд, перерахованих у блоках, служби повинні працювати весь час, тому протягом усього життя смартфона init висітиме у фоні та стежитиме за цим.

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

Команди init.rc

Процес init має вбудований набір команд, багато з яких повторюють стандартний набір команд Linux. Найбільш примітні з них:

  • exec /шлях/до/команди- запустити зовнішню команду;
  • ifup інтерфейс- підняти мережевий інтерфейс;
  • class_start ім'я_класу- запустити служби, що належать до зазначеного класу;
  • class_stop ім'я_класу- Зупинити служби;
  • insmod /шлях/до/модуля- Завантажити модуль ядра;
  • mount ФС пристрій каталог- Підключити файлову систему;
  • setprop ім'я значення- Встановити системну змінну;
  • start ім'я_служби- запустити вказану службу;
  • trigger ім'я- увімкнути тригер (виконати вказаний блок команд);
  • write /шлях/до/файлу рядок- Записати рядок у файл.

Крок четвертий. Zygote та app_process

На певному етапі завантаження init зустріне в кінці конфігу приблизно такий блок:

Service zygote /system/bin/app_process -Xzygote /system/bin --zygote --start-system-server class default socket zygote stream 660 root system onrestart write /sys/android_power/request_state wake onrestart write /sys/power/state on onrestart restart media onrestart restart netd

Це опис служби Zygote, ключового компонента будь-якої Android-системи, який відповідальний за ініціалізацію, старт системних служб, запуск та зупинку користувацьких додатків та багато інших завдань. Zygote запускається за допомогою невеликої програми /system/bin/app_process, що дуже добре видно на наведеному вище шматку конфігу. Завдання app_proccess - запустити віртуальну машину Dalvik, код якої розташовується в бібліотеці /system/lib/libandroid_runtime.so, що розділяється, а потім поверх неї запустити Zygote.

Коли все це буде зроблено і Zygote отримає управління, він починає формування середовища виконання Java-застосунків за допомогою завантаження всіх Java-класів фреймворку (зараз їх більше 2000). Потім він запускає system_server, що включає більшість високорівневих (написаних на Java) системних сервісів, у тому числі Window Manager, Status Bar, Package Manager і, що найважливіше, Activity Manager, який в майбутньому буде відповідальний за отримання сигналів про старт і завершення додатків.

Після цього Zygote відкриває сокет /dev/socket/zygote і йде в сон, очікуючи на дані. У цей час запущений раніше Activity Manager посилає широкомовний інтент Intent.CATEGORY_HOME, щоб знайти програму, яка відповідає за формування робочого столу, і віддає його ім'я Zygote через сокет. Останній, у свою чергу, форкається і запускає програму поверх віртуальної машини. Вуаля, на екрані з'являється робочий стіл, знайдений Activity Manager і запущений Zygote, і статусний рядок, запущений system_server в рамках служби Status Bar. Після тапа по іконці робочий стіл надішле інтент з ім'ям цієї програми, його прийме Activity Manager і передасть команду на старт програми демону Zygote

INFO

У термінології Linux RAM-диск - це свого роду віртуальний жорсткий диск, що існує лише в оперативній пам'яті. На ранньому етапі завантаження ядро ​​витягує вміст диска з образу та підключає його як кореневу файлову систему (rootfs).

У процесі завантаження Android відображає три різні завантажувальні екрани: перший з'являється відразу після натискання кнопки живлення і прошитий в ядро ​​Linux, другий відображається на ранніх етапах ініціалізації і записаний у файл /initlogo.rle (сьогодні майже не використовується), останній запускається за допомогою bootanimation та міститься у файлі /system/media/bootanimation.zip.

Крім стандартних тригерів, init дозволяє визначати власні тригери, які можуть спрацьовувати від різних подій: підключення пристрою до USB, зміни стану смартфона або зміни стану системних змінних.

Activity Manager також займається вбивством фонових додатків при нестачі пам'яті. Значення порогів вільної пам'яті містяться у файлі /sys/module/lowmemorykiller/parameters/minfree.

Все це може виглядати дещо незрозуміло, але найголовніше – запам'ятати три прості речі:

Багато в чому Android дуже відрізняється від інших ОС, і з наскоку в ньому не розібратися. Однак, якщо зрозуміти, як усе працює, відкриваються просто безмежні можливості. На відміну від iOS та Windows Phone, операційна система від гугла має дуже гнучку архітектуру, яка дозволяє серйозно змінювати її поведінку без необхідності писати код. Найчастіше досить підправити необхідні конфіги та скрипти.

ОС Android – операційна система для мобільних телефонів, планшетних комп'ютерів та нетбуків, заснована на ядрі Linux. Спочатку розроблялася компанією Android Inc., яку потім купила компанія Google. Перша версія ОС Google Android вийшла у вересні 2008 року. Наприкінці 2010 року платформа Android стала найбільш продаваною ОС для смартфонів.

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

Архітектура операційної системи Android

Якщо уявити компонентну модель Android як ієрархії (Рис.2) , можна виділити 4 основних рівня:

Рівень ядра Linux;

Рівень бібліотек (Libraries);

Рівень середовища виконання (Android Runtime);

Рівень каркасу додатків (ApplicationFramework);

Рівень програм (Applications).

Рівень ядра Linux. У самому низу, в основі буде розташовуватись ядро ​​операційної системи. ОС Android заснована на ОС Linux версії 2.6, тим самим платформі доступні системні служби ядра, такі як управління пам'яттю та процесами, забезпечення безпеки, робота з мережею та драйверами. Також ядро ​​служить шаром абстракції між апаратним та програмним забезпеченням.

Рис.2

Рівень бібліотек (Libraries). "Вище" ядра, як програмне забезпечення проміжного шару, лежить набір бібліотек, призначений для вирішення типових завдань, що вимагають високої ефективності. Тобто, саме цей рівень відповідає за надання реалізованих алгоритмів для вищих рівнів, підтримку файлових форматів, здійснення кодування та декодування інформації, відтворення графіки та багато іншого. Бібліотеки реалізовані на C/C++ і скомпільовані під конкретне апаратне забезпечення пристрою, разом з яким вони поставляються виробником у встановленому вигляді.

Перерахуємо деякі з низькорівневих бібліотек:

SurfaceManager - диспетчер поверхонь управляє доступом до підсистеми відображення 2D- та 3D-графічних шарів.

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

SQLite - легковажна і продуктивна реляційна СУБД, що використовується в Android як основний двигун для роботи з базами даних.

3D libraries – бібліотеки для роботи з 3D-графікою.

FreeType – бібліотека, призначена для роботи зі шрифтами.

LibWebCore – ядро ​​вбудованого web-браузера.

SGL (ScalableGraphicsLibrary) – бібліотека для роботи з 2D-графікою.

SSL – бібліотеки для підтримки однойменного криптографічного протоколу.

libc – бібліотека стандартних викликів мови C.

Рівень середовища виконання (Android Runtime). На цьому рівні розташовується Android Runtime - середовище виконання прикладних програм. Ключовими її складовими є набір стандартних бібліотек та віртуальна машина Dalvik. Кожна програма в ОС Android запускається у власному примірнику віртуальної машини Dalvik. Таким чином, усі працюючі процеси ізольовані від операційної системи та один від одного. Архітектура Android Runtime така, що робота програм здійснюється строго в рамках оточення віртуальної машини. Завдяки цьому здійснюється захист ядра операційної системи від можливої ​​шкоди з боку її складових. Тому код з помилками або шкідливе програмне забезпечення не зможуть зіпсувати ОС Android і пристрій на її базі. Така захисна функція поряд з виконанням програмного коду є однією з ключових для Android Runtime.

Рівень каркасу додатків (ApplicationFramework). ОС Android дозволяє повністю використовувати API (інтерфейс програмування додатків - набір готових класів, процедур, функцій, структур та констант), що використовується в додатках ядра. Архітектура побудована таким чином, що будь-яка програма може використовувати вже реалізовані можливості іншої програми за умови, що вона відкриє доступ на використання своєї функціональності. Таким чином, архітектура реалізує принцип багаторазового використання компонентів ОС та додатків.

Основою всіх додатків є набір систем та служб:

Диспетчер дій (ActivityManager) керує життєвим циклом додатків та надає систему навігації з історії роботи з діями.

Диспетчер вікон (Window Manager) керує вікнами, і надає додатків вищий рівень абстракції бібліотеки Surface Manager.

Постачальник вмісту (ContentProviders) - це служби, які дозволяють програмам отримувати доступ до даних інших програм, а також надавати доступ до своїх даних.

Система уявлень (ViewSystem) - це багатий набір уявлень з функціональністю, що розширюється, який служить для побудови зовнішнього вигляду додатків, що включає такі компоненти, як списки, таблиці, поля введення, кнопки і т.п.

Диспетчер сповіщень (NotificationManager) дозволяє будь-якій програмі відображати повідомлення користувача в рядку статусу.

Диспетчер пакетів (Package Manager) керує встановленими пакетами на вашому пристрої, відповідає за встановлення нових та видалення існуючих.

Диспетчер телефонії (Telephony Manager) містить API для взаємодії з можливостями телефонії (дзвінки, смс тощо)

Диспетчер ресурсів (ResourceManager) призначений для доступу до рядкових, графічних та інших типів ресурсів.

Диспетчер розташування (Location Manager), що дозволяє програмам отримувати оновлені дані про поточне географічне розташування пристрою

Рівень програм (Applications). На вершині програмного стека Android лежить рівень додатків. Сюди відноситься набір базових програм, який встановлений на ОС Android. Наприклад, до нього входять браузер, поштовий клієнт, програма для відправки SMS, карти, календар, менеджер контактів та багато інших. Список інтегрованих програм може змінюватись в залежності від моделі пристрою та версії Android. І крім цього базового набору до рівня програм відносяться всі прикладні програми під платформу Android, у тому числі й встановлені користувачем.

Ті, хто використовує iPhone давно, знають, як працювали ранні версії iOS. Фактично це була однозадачна операційна система, яка дозволяла працювати в фоні або переривати роботу поточного додатка тільки встановленим додаткам: ви читаєте книжку, вам дзвонять - книгочиталка згортається, і на екрані з'являється вікно дзвінка. А ось зворотна операція неможлива: книгочиталка не тільки не може перервати роботу інших додатків, а й буде вбита відразу після згортання.

Сенс існування такої системи, звичайно ж, у тому, щоб заощадити процесор, оперативну пам'ять, а також ресурс батареї. Завдяки їй (але не тільки) iPhone міг працювати швидко в умовах обмежених ресурсів і дуже дбайливо ставився до батареї.

Як влаштована операційна система Андроїд

Android завжди працював інакше. Тут можна запустити безліч різних програм і всі вони залишатимуться в пам'яті і навіть зможуть працювати на тлі. Ви відкриваєте браузер, вводите адресу і поки завантажується сторінка, запускаєте поштовий клієнт і читаєте листи. Все як на десктопі, з тим винятком, що вам не потрібно дбати про закриття додатків, система зробить це сама, коли оперативна пам'ять підійде до кінця або її не вистачить для розміщення програми, що запускається (саме собою, в першу чергу в витрату підуть програми, що рідко використовуються) ). Цей механізм називається lowmemorykiller.

Маючи права root, налаштування lowmemorykiller можна регулювати безпосередньо або за допомогою спеціальних додатків

Важливим елементом системи багатозадачності були служби (service). Це особливі компоненти додатків, які могли працювати в фоні абсолютно в будь-яких умовах: включений екран або вимкнений, згорнуто додаток або розгорнуто, службам начхати навіть на те, чи запущено батьківський додаток взагалі. Воно просто говорило: «Гей, Android, мені потрібні ресурси процесора, я хочу зробити деякі розрахунки» - і отримувало ці ресурси. У термінології Android такий запит до системи називається wakelock(а якщо точніше – процесорний wakelock).

Однак підтримка такого потужного та корисного інструменту зіграла з Google злий жарт. З'явилася величезна кількість додатків, які плодили служби на кожних, постійно виконували якусь роботу і не давали смартфону спати. Встановивши на смартфон сотню додатків, користувач отримував кілька десятків служб, кожна з яких періодично щось робила (оновити стрічку твіттера, поки телефон спить, - це так важливо).

Справи були настільки жалюгідні, що китайські виробники, не обтяжені завданням зберегти сумісність з оригінальним Android (це потрібно, якщо хочете встановлювати на свої смартфони Play Store), просто відключили у своїх смартфонах механізми підтримки життєвого циклу служб для несистемних додатків.

Просунуті користувачі йшли іншим шляхом: вони отримували права root і встановлювали додаток Greenify, який дозволяв заморозити служби вибраних додатків так, щоб їх ніхто не зміг розбудити. Існували і більш радикальні варіанти, наприклад, знести весь софт, яким користуєшся рідше одного разу на добу.

Сама Google також вживала певних дій для боротьби з «отруйними» службами. Великий крок у цьому напрямі був зроблений в Android 4.4, де з'явився інтелектуальний механізм, який визначав, чи не працює служба занадто багато часу і чи не сильно вона вантажить процесор, і, якщо це виявлялося так, прибивав її на місці і не давав запуститися. Навіть на поверхневий погляд ця версія системи жила на батарейці помітно довше за попередні.

В Android 6.0 Google пішла ще далі та оснастила її механізмом Doze, який після визначеного часу неактивності смартфона (близько однієї години) переводив його в спеціальний енергозберігаючий режим. Однією з особливостей цього режиму є заборона на wakelock, тобто ні програми, ні служби просто не можуть розбудити смартфон, щоб виконати будь-яку роботу. На око Android 6.0 не став жити довше, тому невідомо, чи спрацював цей механізм взагалі.


Шкала роботи Doze

І нарешті, Android 8.0 Google пішла на радикальний крок - заборонила роботу фонових служб. Але з двома винятками:

Програма в деяких випадках, наприклад, коли вона знаходиться на екрані, може запускати служби, але Android приб'є їх після виходу програми в сон.
Відомі користувачеві служби досі дозволені. Це так званий foreground service, служба, яка видна на панелі повідомлень і має іконку в статусбарі.

Здавалося б, так, служби - це зло, але як тепер бути таким додатком, як протиугінне, яке має працювати непомітно на тлі? Чи той самий поштовий клієнт? Через необхідність періодично перевіряти пошту він повинен висіти на панелі повідомлень?

Насправді ні. Google йшла до заборони служб ще з версії 5.0, де з'явився так званий JobScheduler. Це спеціальна підсистема, яка дозволяє програмам попросити Android виконати ту чи іншу роботу в такий час або при виникненні такої події (підключення до інтернету, наприклад). І так, JobScheduler сильно нагадує аналогічну функцію з iOS.

Binder

Всупереч поширеній думці, Android з перших версій використовував пісочниці для ізоляції додатків. І реалізовані вони були дуже цікавим чином. Кожна програма запускалася від імені окремого користувача Linux і, таким чином, мала доступ тільки до свого каталогу всередині /data/data .

Один з одним і з операційною системою програми могли спілкуватися тільки через IPC-механізм Binder, який вимагав авторизації виконання тієї чи іншої дії. Цей же механізм використовувався і для інших цілей: з його допомогою система оповіщала додатки про системні події, таких як вхідний виклик, що прийшло СМС, втикання зарядки і так далі. Програми отримували повідомлення та могли на них відреагувати.


Роботу Binder забезпечують драйвер в ядрі Linux та Service Manager

Ця особливість дала Android дуже широкі можливості автоматизації, які ми знаємо завдяки таким додаткам, як Tasker, Automate або Locale. Всі ці програми доступні і для Android 8, хіба що деякі небезпечні можливості, такі як увімкнення/вимкнення режиму польоту, тепер заборонені для використання звичайними програмами.

Система оповіщення базується на інтентах (intent), спеціальному механізмі, реалізованому поверх Binder та призначеному для обміну інформацією між додатками (або ОС та додатками), а також запуску компонентів додатків. За допомогою інтентів можна оповіщати програми про події, попросити систему відкрити програму для обробки певних типів даних (наприклад, щоб відкрити певну сторінку в браузері, достатньо надіслати широкомовний інтент із посиланням на сторінку, і на нього відгукнуться всі програми, здатні відображати веб-сторінки, або тільки дефолтовий браузер) або просто запустити компонент тієї чи іншої програми. Наприклад, програми Android запускаються не безпосередньо, а за допомогою інтентів.

На жаль, як і служби, інтенти стали проблемою для Google та користувачів Android. Справа в тому, що широкомовні інтенти, які використовуються для повідомлення додатків про події, приходять відразу до всіх програм, які заявили, що здатні на них реагувати. А щоб програма змогла зреагувати на інтент, її треба запустити. Картина виходить така: на смартфоні є двадцять програм, які можуть реагувати на інтент android.net.conn.CONNECTIVITY_CHANGE, і при кожному підключенні до мережі та відключенні від неї система запускає ці програми, щоб вони змогли зреагувати на інтент. Як це впливає на енергоспоживання - уявіть самі.

Google виправила це непорозуміння знову ж таки в Android 8.0. Тепер програми можуть реєструвати обробники широкомовних інтентів лише під час своєї роботи (за невеликими винятками).

Сервіси Google

Google любить бравірувати тим, що Android - операційна система з відкритим вихідним кодом. Це, звичайно, не зовсім так. З одного боку, код Android справді відкритий, і саме тому ми маємо доступ до такої кількості різноманітних кастомних прошивок. З іншого боку, зібравши Android з офіційних вихідних джерел, ви отримаєте систему без кількох важливих компонентів: 1) окремих драйверів, вихідні джерела яких виробник ховає, як комерційну таємницю, 2) сервісів Google, які потрібні в першу чергу для отримання доступу до облікового запису, запуску Google Play і хмарного бекапу.

Сервіси Google (Google Mobile Services) також відповідають за багато інших речей, включаючи підтримку push-повідомлень, Instant Apps, Google Maps, доступ до календаря, місцезнаходження за стільниковими вежами та Wi-Fi-роутерами, механізм Smart Lock, що дозволяє розблокувати пристрій в Залежно від деяких умов.

У сучасних версіях Android сервіси Google взяли на себе настільки більшу частину роботи, що жити без них виявляється хоч і можливо, але дуже проблематично. А з ними теж невесело: мінімальний варіант пакету GApps (який містить лише сервіси Google та Google Play) важить більше 120 Мбайт, а самі сервіси славляться своєю любов'ю до оперативної пам'яті та заряду батареї. А ще вони закриті, тобто про те, що вони можуть робити, знає лише сама Google.


Завантажити пакет із сервісами та програмами Google для кастомної прошивки можна з сайту opengapps.org (слово open не означає, що вони відкриті)

Саме тому на світ з'явився проект microG, завдання якого – відтворити найважливішу функціональність сервісів Google у відкритому коді. Вже зараз microG дозволяє отримати доступ до свого облікового запису, активувати push-сповіщення, доступ до карт Google і визначення місця розташування по стільникових вежах. І все це при розмірі в чотири мега і майже повній відсутності вимог до оперативної роботи та ресурсу батареї.

Проект має власне складання прошивки LineageOS, яка з коробки включає microG і всі необхідні для його роботи модифікації.

Ядро Linux та рантайм

Android базується на ядрі Linux. Ядро управляє ресурсами смартфона, у тому числі доступом до заліза, управлінням оперативною та постійною пам'яттю, запуском, зупинкою та перенесенням процесів між ядрами процесора та багатьма іншими завданнями. Як і в будь-якій іншій ОС, ядро ​​- це серце Android, центральна частина, без якої все інше розвалиться.


Листковий пиріг Android

Наявність ядра Linux, а також частково сумісного зі стандартом POSIX середовища виконання (насамперед це бібліотека bionic, заснована на реалізації стандартної бібліотеки мови С з OpenBSD) робить Android сумісним із додатками для Linux. Наприклад, система аутентифікації wpa_supplicant, що використовується для підключення до Wi-Fi-мереж, тут точно така ж, як у будь-якому дистрибутиві Linux. У ранніх версіях Android використовувався стандартний bluetooth-стек Linux під назвою bluez (пізніше його замінили реалізацією Qualcomm під назвою Bluedroid). Тут навіть є своя консоль з набором стандартних UNIX/Linux-команд, реалізованих у наборі Toybox, спочатку створеному для Linux-систем, що вбудовуються.

Більшість консольних додатків, написаних для Linux, можна портувати в Android простою перекомпіляцією за допомогою крос-компілятора (головне - використовувати статичну компіляцію, щоб не отримати конфлікт бібліотек), а маючи права root, на Android-девайсі можна без будь-яких проблем запустити повноцінний . Один нюанс - доступ до нього можна буде отримати через консоль, або використовуючи VNC-з'єднання. Також існує проект Maru OS, що дозволяє використовувати смартфон як ПК на базі Debian при підключенні до монітора. Ту ж функцію обіцяє при підключенні смартфонів до монітора за допомогою дока DeX.


Старий добрий mc, запущений в Android

Починаючи з версії 4.4, Android вміє використовувати систему примусового контролю доступу SELinux для захисту від злому та отримання прав root. SELinux розроблена Агентством національної безпеки США і, якщо не вдаватися в деталі, дозволяє обмежити додатки (у тому числі системні низькорівневі компоненти) у можливостях. І мова зовсім не про повноваження, які користувач надає програмам, а про такі речі, як системні виклики і доступ до тих чи інших файлів, незважаючи на стандартні права доступу UNIX.

Серія вразливостей Stagefright, що вразили Android кілька років тому, дозволяла отримати контроль над пристроєм, просто змусивши користувача відкрити MMS або спеціальний файл у браузері. Проблема полягала в мультимедіафреймворку Stagefright, що містить відразу кілька вразливостей переповнення буфера. При відкритті спеціальним чином підготовленого мультимедіафайлу експлоїт використовував вразливість і запускав код від імені Stagefright (який працював під рутом) на пристрої.

Всі ці баги Google благополучно закрила, а також попрацювала над модуляризацією коду фреймворку та його запуском у спеціальних доменах SELinux. Ці домени забороняють компонентам, відповідальним за обробку мультимедіа, використовувати більшу частину системних викликів Linux, включаючи системні виклики групи execve, які якраз і були причетні до запуску шкідливого коду.

Сьогодні SELinux використовується для захисту багатьох системних компонентів Android. І це спричинило різке зниження кількості знайдених багів в Android. Але призвело до фокусування зломщиків на ядрі, а точніше тих закритих драйверах, аудит коду яких ніхто не проводив і безпека яких не гарантована (а вона, як виявилося, перебуває в жалюгідному стані).

(6 оцінок, середнє: 5,00 із 5)

 

 
Це цікаво: