Файлова структура android. Внутрішній устрій систем Android

Файлова система os Android

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

в андроїд немає звичних багатьом дисків - таких як з або д. Корінь файлової системи у нас: «». до кореневої директорії приєднуються всі інші директорії. Розглянемо деякі з них:

system- за назвою вже можна здогадатися що тут розташовуються системні файли (що щось на зразок ми можемо бачити в ос від майкрософт c: windows). Де ці файли за замовчуванням незмінні. Призначені вони для функціонування операційної системи. Так само тут розташовуються вбудовані додатки, вбудовані в ос. Якщо ми отримаємо рут права то зможемо вносити свої зміни в даній директорії. Однак робити це варто акуратно бо видалені файли  і папки не відновляться самі по собі. У такому випадку нам допоможуть лише перепрошивка або бекап. Дещо - що цікаве можна знайти в папці systemmedia. В архіві bootanimation.zip  лежать картинки складові анімацію при включенні апарату. Ще в корені папки system можна знайти файл build.prop  який містить в собі багато налаштувань, від опису апарату до щільності екрану (для настройки цього конфіга існує багато сторонніх додатків).скрін

Data  - на відміну від систем тут зберігаються змінювані файли. В під категорії app  якраз зберігаються apk встановлених нами програм. скрін

Якщо нам потрібен апк файл будь-якого додатка то ми легко можемо його там знайти. А в datadata  дані цих встановлених програм.
Mnt  -в цей розділ монтується призначена для користувача пам'ять (якщо наприклад встановити флеш карту). Таким чином якщо ми помістимо наш тхт файл в корінь флеш карти то повний шлях буде виглядати так « mntsdcardфайл.тхт». Сюди ж монтується вбудований диск у смартфонів без підтримки карт пам'яті. скрін

Як зробити wipe (скидання налаштувань) на android

існує кілька способів форматування. Про кілька з них нижче
1.сброс через настройки. Заходимо в настройки \u003e\u003e відновлення і скидання \u003e\u003e скидання налаштувань. Скидає всі настройки і видаляє встановлений по. Перед цим можна зробити резервне копіювання деяких налаштувань, зазначивши галочкою відповідний пункт. Після перезавантаження апарат запитає відновити ці дані.
скрін

2.сброс через recovery.  Корисний в тій ситуації коли апарат не включається. Буде потрібно рут доступ і відповідно встановлений recovery. Залежно від встановленого recovery розташування пунктів може відрізнятися. У мене це пункт advanced wipe. Містить в собі:
dalvik cache  - форматування кеша віртуальної машини  dalvik.
System- форматування системного розділу.
Data  - видалення всіх сторонніх додатків в пам'яті пристрою а так само для користувача налаштувань.
cache - видалення кеша
format sdcard  - форматування карти пам'яті. Видалення всього що знаходиться на карті пам'яті.
format sd-ext- форматування ЕХТ розділу на карті пам'яті (якщо був створений такий розділ. Наприклад для монтування скрипта посилається додатки при установки на карту).
3. форматування за допомогою сервісного коду.  Якщо набрати * 2767 * 3855 #. відразу ж після набору стається збій. Будьте уважні.
Так наприклад видалення вмісту папки datadata  ми видалимо настройки і дані додатків але не самі додатки. Це так само можна зробити і з налаштувань програми «видалити дані». При видаленні папки дата буде видалено встановлені додатки.
Побажання, поправки, доповнення до статті прохання залишати в коментарях або до мене в личку. стаття буде доповнюватися. Дякую читачам, успіхів.
-----------------
  Залишити коментарі можна в розділі Каталог статей програмне забезпечення проміжного шару, Лежить набір бібліотек (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 - середовище виконання прикладних програм. Ключовими її складовими є набір стандартних бібліотек і віртуальна машина Dalvik. Кожна програма в ОС Android запускається у власному примірнику віртуальної машини Dalvik. Таким чином, всі, хто працює процеси ізольовані від операційної системи і один від одного. Архітектура Android Runtime така, що робота програм здійснюється строго в рамках оточення віртуальної машини. Завдяки цьому здійснюється захист ядра операційної системи від можливої ​​шкоди з боку інших її складових. Тому код з помилками або шкідливі програми не зможуть зіпсувати ОС Android і пристрій на її базі. Така захисна функція, поряд з виконанням програмного коду, є однією з ключових для Android Runtime.

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

1. Багатий і розширюваний набір уявлень (Views), який може бути використаний для створення візуальних компонентів додатків, наприклад, списків, текстових полів, таблиць, кнопок або навіть вбудованого web-браузера.
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 відсутні деякі не використовуються в Android функції POSIX, доступні в повній реалізації 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 призначена для процесорів c відносно низькими тактовими частот.
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 можуть бути відсутні деякі компоненти з вищенаведеного списку.

Всі «Андроїдні» планшети управляються однією з версій мобільної операційної системи від компанії Google. При цьому, більш старі версії можуть не підтримувати деякі з сучасних додатків.

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

Отже, на самому нижньому рівні знаходяться самі апаратні компоненти: процесори, сенсори, проводи й друковані плати. Наступним шаром є ядро ​​операційної системи. Ядро іноді ще називають вбудованим (або фірмовим) програмним забезпеченням. Більш відомо англомовне визначення «firmware». Це програмне забезпечення здійснює контроль над апаратними ресурсами пристрою, управління ними та їх розподілом.

Ця частина операційної системи «переводить» на мову апаратних компонентів ті команди, які віддає користувач за допомогою зручного графічного інтерфейсу. Зразком ядра для Android стала операційна система з відкритим кодом Linux 2.6.

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

На тому ж рівні програмного стека розташовуються кореневі бібліотеки, необхідні для підтримки додатків, написаних на мові Java. Java є мовою програмування від Sun Microsystems. Ще порівняно недавно телефони з підтримкою Java-додатків були дуже поширені. В даний час вони все більшою мірою витісняються смартфонами.

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

На наступному рівні розташовується інфраструктура додатків (application framework). Вона є основою для всіх додатків «андроидного» девайса. Інфраструктура додатків є сполучною ланкою між додатками і іншими частинами операційної системи.

Google рекомендує розробникам створювати такі додатки, які взаємодіють з цим шаром в рамках інтерфейсу прикладного програмування () розробленої пошуковим гігантом операційної системи. Розробникам залишається тільки ознайомитися з цими правилами, що стосуються API. Їм не потрібно замислюватися про технічні характеристики  кожного «андроидного» планшета.

Самий верхній рівень програмного стека містить інтерфейс користувача і всі додатки «андроидного» планшета. Саме цю частину операційної системи постійно бачить перед собою користувач. Але за цим привабливим і барвистим шаром ховається маса нудного, і цікавого тільки фахівцям коду.

Як і будь-яка інша операційна система, і інші апаратні ресурси планшета.

За матеріалами computer.howstuffworks.com

# Факти | Як влаштований 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.

Кореневий розділ ТВ-приставки OUYA​

Крок другий, альтернативний. розділ 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 не зникають після установки нової версії  прошивки.

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

Отже, отримавши управління, ядро ​​підключає 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.rc з CyanogenMod​

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

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

mount_all ./fstab.імя_устройства

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

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

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

Типове вміст файлу fstab​

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

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

Крок четвертий. 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

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

Системні служби і потоки ядра​

висновки

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

• Переклад

У цій статті ми розглянемо архітектуру Android-додатків.

Відверто кажучи, офіційну Google по цій темі я вважаю не дуже корисною. Детально відповідаючи на питання «як», вона зовсім не пояснює «що» і «чому». Отже, ось моя версія, і, я сподіваюся, вона внесе деяку ясність. Так, до речі, я повністю схвалюю читання статей Google, оскільки вони містять корисну інформацію, повторювати яку я не збираюся.

Архітектура ОС Android - трохи історії

  Як це часто буває в IT, багато речей не можуть бути пояснені у відриві від історії виникнення конкретного програмного забезпечення. Ось чому ми повинні звернутися до витоків ОС Android.

Розробка ОС Android була розпочата в 2003 молодою компанією Android Inc. У 2005 році ця компанія була куплена Google. Я вважаю, що головні особливості архітектури Android були визначені саме в цей період. Це заслуга не тільки Android Inc; архітектурні концепції і фінансові ресурси Google зробили вирішальний вплив на архітектуру Android. Далі я приведу кілька прикладів.

Якщо ви пам'ятаєте, 2003-2005 роки були ознаменовані підвищеною увагою до AJAX додатків. Я думаю, це зробило основне вплив на архітектуру Android: у багатьох аспектах вона ближче до архітектури типового AJAX додатки, ніж до десктопних GUI додатку, написаному на Java, C #, C ++, VB і тп.

Не знаю, чому так сталося. Моя здогадка - це придумав хтось із Google в той період, коли насичені інтернет-додатки (Rich Internet Applications, RIA) в дусі Google Docs або Gmail вважалися рішенням всіх проблем. По-моєму, цю ідею не можна назвати ні поганою, ні хорошою. Просто пам'ятайте, що Android-додатки дуже сильно відрізняються від десктопних.

Вплив архітектурної філософії Eclipse помітно у виборі принципу реалізації GUI, який більше схоже на SWT, ніж на Swing.

У стандартах оформлення коду Android присутній «угорська нотація», народжена в стінах MS. Можна припустити, що той, хто писав ці стандарти, раніше займався розробкою під Windows.

Архітектурні рівні Android

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

1. В основі лежить модифікована і урізана версія Linux, як я і згадував в одній з моїх попередніх статей.
2. Над рівнем Linux знаходиться рівень інфраструктури додатки, що містить віртуальну машину Dalvik, веб-браузер, базу даних SQLite, деякі інфраструктурні «милиці» і Java API.
3. І, нарешті, рівень написаних в Google Android-додатків. Взагалі кажучи, вони є розширенням рівня інфраструктури, оскільки розробник може використовувати ці додатки або їх частини як будівельні блоки для власних розробок.

  Розглянемо ці шари один за іншим і більш докладно.

рівень Linux

  Уявіть собі, що ви - архітектор в молодої компанії. Ви повинні розробити ОС для нового типу пристроїв. Що ви будете робити?

Грубо кажучи, у вас два шляхи: реалізовувати власні ідеї, почавши з нуля або ж використовувати існуючу ОС і адаптувати її під свої пристрої.

Реалізація з нуля завжди звучить захоплююче для програмістів. У ці моменти ми всі віримо в те, що в цей раз ми все зробимо краще, ніж роблять інші, і навіть краще, ніж ми самі робили раніше.

Тим не менш, це не завжди практично. Наприклад, використання ядра Linux помітно зменшило вартість розробки (можливо десь і без того надмірно велику). Погодьтеся, якщо хтось вирішить створити щось, що нагадує ядро ​​Linux в його сьогоднішньому стані, йому буде потрібно кілька мільйонів доларів.

Якщо ви керуєте Android Inc, то у вас за визначенням не може бути стільки грошей. Якщо ви керуєте Google, то у вас такі гроші знайдуться, але ви, швидше за все, подумаєте двічі, перш ніж витратити їх на створення власної ОС. Так само ви витратите кілька років, перш ніж досягнете сьогоднішнього стану Linux; кілька років затримки можуть стати занадто великим запізненням при виході на ринок.

У подібній ситуації компанія Apple вирішила побудувати Mac OS на основі Free BSD. Android Inc прийняла рішення використовувати Linux як основу для Android. Вихідні тексти як Free BSD, так і Linux, знаходяться у вільному доступі і надають собою гарну основу для будь-яких розробок, будь то Apple або Google.

Але в той час запустити стандартний Linux на мобільному пристрої було неможливо (зараз це вже не так). Пристрої мали занадто мало оперативної і незалежній пам'яті. Процесори були значно повільніше в порівнянні з процесорами комп'ютерів, де зазвичай використовується Linux. Як результат, розробники Android вирішили мінімізувати системні вимоги  Linux.

Якщо розглядати Linux на високому рівні, То це комбінація ядра (без якого не можна обійтися) і безлічі інших, необов'язкових частин. Можна навіть запустити одне ядро, без чого б то не було ще. Так, Google змушена в будь-якому випадку використовувати ядро ​​Linux як частина ОС Android. Крім того, були розглянуті необов'язкові частини і з них вибрано найнеобхідніше. Наприклад, були додані мережевий фаєрвол IPTables і оболонка Ash. Цікаво, що додали саме Ash, а не Bash, не дивлячись на те, що останній на порядок потужніша; ймовірно, це рішення було засноване на тому, що Ash менш вимогливий до ресурсів.

Розробники Android модифікували ядро ​​Linux, додавши підтримку заліза, використовуваного в мобільних пристроях і, найчастіше, недоступного на комп'ютерах.

Вибір Linux в якості основи зробив величезний вплив на всі аспекти ОС Android. Збірка Android, по суті, є варіація процесу складання Linux. код Android  знаходиться під управлінням git (інструмент, розроблений для управління кодом Linux). І так далі.

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

Ви можете запитати, як же бути, якщо необхідно розробити нативное додаток для Android? Google настійно не рекомендує робити цього. Технічно, звичайно, це можливо, але в подальшому у вас не буде можливості поширювати цей додаток нормальним способом. Так що подумайте двічі, перш ніж почати нативную розробку під Android, якщо звичайно, ви не працює над Android Open Source Project (AOSP), тобто власне ОС Android.

Рівень інфраструктури додатки

  Незважаючи на деяку схожість Apple iOS  і Android ОС, існують значні відмінності між архітектурними рішеннями на інфраструктурному рівні обох ОС.

Apple вирішила використовувати Objective-C як мова програмування і середовище виконання додатки iOS. Objective-C виглядає більш-менш природним вибором для ОС, в основі якої лежить Free BSD. Можна розглядати Objective-C як звичайний C ++ з кастомними препроцесором, який додає деякі специфічні лінгвістичні конструкції. Чому ж не можна використовувати стандартний C ++, на якому написана Free BSD? Мені здається причина в тому, що Apple намагається все робити в своєму, «еппловскій» стилі.

Основна ідея в тому, що додатки iOS написані більш-менш на тому ж мовою, що і що стоїть за ними ОС.

Android-додатки сильно відрізняються в цьому сенсі. Вони написані на Java, а це зовсім інша технологія, ніж C ++ (хоча синтаксис і успадкований від C ++).

Я думаю, основна причина полягає в необхідності одному і тому ж додатку працювати на різному апаратному забезпеченні. Ця проблема має місце лише для ОС Android; у хлопців з Apple такої проблеми немає. iOS працює тільки на обладнанні власного виробництва, і Apple повністю контролює весь процес. Для Android же все навпаки: Google не контролює виробників апаратних засобів. Наприклад, ОС Android працює на процесорах з архітектурою x86, ARM і Atom (в коментах підказують, що x86 включає в себе Atom, і Android працює на x86, ARM, PPC і MIPS - примітка перекладача). На бінарному рівні ці архітектури несумісні.

Якби архітектори ОС Android вибрали той же шлях, що і архітектори з Apple, розробники додатків під Android були б змушені поширювати кілька версій одного і того ж додатка одночасно. Це стало б серйозною проблемою, яка могла б привести до краху всього проекту Android.

Для того, щоб один і той же додаток могло працювати на різному апаратному забезпеченні, компанія Google використовувала контейнер-орієнтовану архітектуру (container-based architecture). У такій архітектурі двійковий код виконується програмним контейнером і ізолюється від деталей конкретного апаратного забезпечення. Приклади всім знайомі - Java і C #. В обох мовах двійкового коду не залежить від специфіки апаратного забезпечення і виконується віртуальною машиною.

Звичайно, є й інший спосіб досягти незалежності від апаратного забезпечення на рівні двійкового коду. Як один з варіантів, можна використовувати емулятор апаратного забезпечення, так само відомий як QEMU. Він дозволяє емулювати, наприклад, пристрій з процесором ARM на платформі x86 і так далі. Google могла б використовувати C ++ як мову для розробки додатків всередині емуляторів. Дійсно, Google використовує такий підхід в своїх емуляторах Android, які побудовані на основі QEMU.

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

Як би там не було, компанія Google прийшла до рішення використовувати Java як основна мова розробки додатків і середовища їх виконання.

Я думаю, це було критично важливе архітектурне рішення, яке поставило Android осторонь від інших мобільних ОС на основі Linux, представлених в даний час. Наскільки мені відомо, ні в однієї з них немає сумісності двійкового коду на рівні додатків. Візьмемо для прикладу MeeGo. Вона використовує C ++ і фреймворк Qt; не дивлячись на те, що Qt багатоплатформовий, необхідність робити різні збірки для різних платформ не зникає.

Вибравши Java, потрібно було вирішити, яку віртуальну машину (JVM) використовувати. Зважаючи на обмеженість ресурсів використання стандартної JVM було утруднено. Єдиним можливим вибором було використання Java ME JVM, розробленої для мобільних пристроїв. Однак щастя Google було б неповним без розробки власної віртуальної машини, і з'явилася Dalvik VM.

Dalvik VM відрізняється від інших віртуальних Java-машин наступним:

• Вона використовує спеціальний формат DEX для зберігання двійкових кодів, на противагу форматам JAR і Pack200, які є стандартом для інших віртуальних Java-машинах. Компанія Google заявила, що бінарники DEX менше, ніж JAR. Я думаю, з тим же успіхом вони могли б використовувати Pack200, але вони вирішили піти своїм шляхом.
• Dalvik VM оптимізована для виконання декількох процесів одночасно.
• Dalvik VM використовує архітектуру, засновану на регістрах проти стековой архітектури в інших JVM, що призводить до збільшення швидкості виконання і зменшення розмірів бінарників.
• Вона використовує власний набір інструкцій (а не стандартний байткод JVM)
• Можливий запуск (якщо необхідно) декількох незалежних Android-додатків в одному процесі
• Виконання програми може охоплювати кілька процесів Dalvik VM «природним чином» (пізніше ми обговоримо, що це означає). Для підтримай цього додано:
  • Спеціальний механізм серіалізациі об'єктів, заснований на класах Parcel і Parcelable. Функціонально переслідуються ті ж цілі, що і Java Serializable, але в результаті дані мають менший обсяг і потенційно більш терпимі до версійність змін класів.
  • Особливий спосіб для здійснення дзвінків між процесами (inter process calls, IPC), основний на Android Interface Definition Language (AIDL).
• До Android 2.2 Dalvik VM не підтримувала JIT-компіляцію, що було серйозним ударом по продуктивності. Починаючи з версії 2.2, швидкість виконання часто використовуваних додатків