Архитектура мобильного приложения android. Иерархия папок в 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 - среда выполнения прикладных программ. Ключевыми её составляющими являются набор стандартных библиотек и виртуальная машина 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 позволяет создавать Java -приложения, управляющие устройством через разработанные Google библиотеки. Также есть возможность писать приложения на Си и других языках программирования с помощью Android Native Development Kit.Первым устройством, работающим под управлением Android, стал разработанный компанией HTC смартфон T-Mobile G1 , презентация которого состоялась 23 сентября 2008 года.Вскоре другие производители заявили о намерении выпустить устройства с Android.Кроме того, энтузиасты портировали Android на ряд известных устройств, среди которых: Nokia N810 , смартфоны HTC Touch , HTC TyTN II .Также известны случаи успешного портирования на компьютеры архитектуры x86.Отдельного упоминания достойна инициатива компании Koolu, которая занялась не только портированием Android на Neo FreeRunner , но и строит свой бизнес на продаже этих -смартфонов с предустановленной мобильной платформой Google.

Альтернативные прошивки, разрабатываемые открытым сообществом

Существует сообщество энтузиастов, разрабатывающее полностью open-source варианты Android-прошивок. CyanogenMod и VillainROM - известные примеры данных прошивок.

  • удаления из Android-устройства сервисов Google (например, таких как синхронизация данных) - для обеспечения локализации данных пользователя только на Android-устройстве - исключения возможности передачи идентификационной информации (IMEI, номера телефона, GPS-координат и т. д.) на серверы Google;
  • более оперативного и частого (по сравнению с производителями самих аппаратов) предоставления новых версий Android OS;
  • дополнения Android-прошивки новыми настройками и функциями. Возможность для хранения загруженных приложений на MicroSD карте (для версий Android до 2.2) и т. д.

Некоторые производители Android-устройств аппаратно блокируют возможность перепрошивки (например, HTC), некоторые аппаратно не блокируют (но тем не менее сохраняют трудности по перепрошивке; например, LG (для версий Android до 2.2.1). А некоторые производители (Sony Ericsson в некоторых моделях аппаратов) делают всё чтобы продвинутый пользователь мог не только установить другую прошивку, но и самостоятельно создать свою (предоставляется детальная инструкции по замене прошивок, программное обеспечение, документация по архитектуре программной платформы, код оригинальной прошивки и т.д.). Риск, связанный с возможной поломкой телефона в процессе разблокирования, перекладывается на пользователя, который в случае разблокирования загрузчика соглашается с условиями, указывающими на досрочную потерю гарантии на телефон (для восстановления гарантии необходимо снова установить официальным флэшером официальную прошивку).

Архитектура Android

Уровень ядра Linux (Linux Kernel)

Как известно, Андроид основан на несколько урезанном ядре ОС Linux и поэтому на этом уровне мы можем видеть именно его (версии 2.6.x). Оно обеспечивает функционирование системы и отвечает за безопасность, управление памятью, энергосистемой и процессами, а также предоставляет сетевой стек и модель драйверов

Уровень библиотек (Libraries)


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

  1. Surface Manager – в ОС Android используется композитный менеджер окон. Вместо того чтобы производить отрисовку графики напрямую в буфер дисплея, система посылает поступающие команды отрисовки в закадровый буфер, где они накапливаются вместе с другими, составляя некую композицию, а потом выводятся пользователю на экран. Это позволяет системе создавать интересные бесшовные эффекты, прозрачность окон и плавные переходы.
  2. Media Framework – библиотеки. С их помощью система может осуществлять запись и воспроизведение аудио и видео контента, а также вывод статических изображений. Поддерживаются многие популярные форматы, включая MPEG4, H.264, MP3, AAC, AMR, JPG и PNG.
  3. SQLite – легковесная и производительная реляционная СУБД , используемая в Android в качестве основного движка для работы с базами данных, используемыми приложениями для хранения информации.
  4. OpenGL ES (OpenGL for Embedded Systems) – подмножество графического программного интерфейса OpenGL, адаптированное для работы на встраиваемых системах.
  5. FreeType – библиотека для работы с битовыми картами. Это высококачественный движок для шрифтов и отображения текста.
  6. WebKit – библиотеки браузерного движка, используемого также в десктопных браузерах Google Chrome и Apple Safari.
  7. SGL (Skia Graphics Engine) – открытый движок для работы с 2D-графикой. Графическая библиотека является продуктом Google и часто используется в других их программах.
  8. SSL - библиотеки для поддержки одноименного криптографического протокола.
  9. Libc – стандартная библиотека языка C, а именно её BSD реализация, настроенная для работы на устройствах на базе Linux. Носит название Bionic.

На этом же уровне располагается Android Runtime – среда выполнения.


Ключевыми её составляющими являются набор библиотек ядра и виртуальная машина Dalvik . Библиотеки обеспечивают большую часть низкоуровневой функциональности, доступной библиотекам ядра языка Java.

Каждое приложение в ОС Android запускается в собственном экземпляре виртуальной машины Dalvik. Таким образом, все работающие процессы изолированы от операционной системы и друг от друга. И вообще, архитектура Android Runtime такова, что работа программ осуществляется строго в рамках окружения виртуальной машины. Благодаря этому осуществляется защита ядра операционной системы от возможного вреда со стороны других её составляющих. Поэтому код с ошибками или вредоносное ПО не смогут испортить Android и устройство на его базе, когда сработают. Такая защитная функция, наряду с выполнением программного кода, является одной из ключевых для надстройки Android Runtime.

Уровень каркаса приложений (Application Framework)


Android позволяет использовать всю мощь API , используемого в приложениях ядра. Архитектура построена таким образом, что любое приложение может использовать уже реализованные возможности другого приложения при условии, что последнее откроет доступ на использование своей функциональности. Таким образом, архитектура реализует принцип многократного использования компонентов ОС и приложений.

Основой всех приложений является набор систем и служб:

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

Android – это набор открытого программного обеспечения для мобильных устройств от компании Google, в состав которого входит операционная система и комплект базовых межплатформенных приложений.

Для разработки приложений под платформу Android потребуется набор инструментов и библиотек API - Android SDK, последнюю версию которого вы можете найти .

На представленном ниже рисунке показана архитектура ОС Android.


Уровень приложений (Applications)

В состав Android входит комплект базовых приложений: клиенты электронной почты и SMS, календарь, различные карты, браузер, программа для управления контактами и много другое. Все приложения, запускаемые на платформе Android написаны на языке Java.

Уровень каркаса приложений (Application Framework)

Android позволяет использовать всю мощь API, используемого в приложениях ядра. Архитектура построена таким образом, что любое приложение может использовать уже реализованные возможности другого приложения при условии, что последнее откроет доступ на использование своей функциональности. Таким образом, архитектура реализует принцип многократного использования компонентов ОС и приложений.

Основой всех приложений является набор систем и служб:
1. Система представлений (View System ) – это богатый набор представлений с расширяемой функциональностью, который служит для построения внешнего вида приложений, включающий такие компоненты, как списки, таблицы, поля ввода, кнопки и т.п.
2. Контент-провайдеры (Content Providers ) – это службы, которые позволяют приложениям получать доступ к данным других приложений, а также предоставлять доступ к своим данным.
3. Менеджер ресурсов (Resource Manager ) предназначен для доступа к строковым, графическим и другим типам ресурсов.
4. Менеджер извещений (Notification Manager ) позволяет любому приложению отображать пользовательские уведомления в строке статуса.
5. Менеджер действий (Activity Manager ) управляет жизненным циклом приложений и предоставляет систему навигации по истории работы с действиями.

Уровень библиотек (Libraries)

Платформа Android включает набор C/C++ библиотек, используемых различными компонентами ОС. Для разработчиков доступ к функциям этих библиотек реализован через использование Application Framework. Ниже представлены некоторые из них:
1. System C library - BSD-реализация стандартной системной библиотеки C (libc) для встраиваемых устройств, основанных на Linux.
2. Media Libraries – библиотеки, основанные на PacketVideo‘s OpenCORE, предназначенные для поддержки проигрывания и записи популярных аудио- и видео- форматов (MPEG4, H.264, MP3, AAC, AMR, JPG, PNG и т.п.).
3. Surface Manager – менеджер поверхностей управляет доступом к подсистеме отображения 2D- и 3D- графических слоев.
4. LibWebCore – современный движок web-браузера, который предоставляет всю мощь встроенного Android-браузера.
5. SGL – движок для работы с 2D-графикой.
6. 3D libraries – движок для работы с 3D-графикой, основанный на OpenGL ES 1.0 API.
7. FreeType – библиотека, предназначенная для работы со шрифтами.
8. SQLite – мощный легковесный движок для работы с реляционными БД.

Уровень среды исполнения (Android Runtime)

В состав Android входит набор библиотек ядра, которые предоставляют большую часть функциональности библиотек ядра языка Java.

Платформа использует оптимизированную, регистр-ориентированную виртуальную машину Dalvik, в отличии от нее стандартная виртуальная машина Java – стек-ориентированная. Каждое приложение запускается в своем собственном процессе, со своим собственным экземпляром виртуальной машины. Dalvik использует формат Dalvik Executable (*.dex), оптимизированный для минимального использования памяти приложением. Это обеспечивается такими базовыми функциями ядра Linux, как организация поточной обработки и низкоуровневое управление памятью. Байт-код Java, на котором написаны ваши приложения, компилируются в dex-формат при помощи утилиты dx, входящей в состав SDK.

Уровень ядра Linux (Linux Kernel)

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

Архитектура ОС Android представляется интерес, прежде всего, для разработчиков, которые все о ней и так знают, поэтому попробуем донести эти сведения до рядовых пользователей в интересном и понятном виде, чтобы они знали, как работает их любимая система. В том, что она именно любимая для многих, сомневаться не приходится. Но некоторые еще не до конца понимают всякие процессы, зачем и почему имеет смысл разлочивать устройство, лишать его гарантии и безопасности.

Первое, что нужно знать: Android есть вариант ОС Linux, и хоть здесь эта система нашла свою родную нишу. Внутри системы, на самом базовом ее уровне, находится модифицированное ядро Linux, которое, как в больших системах, нужно часто обновлять. Намного чаще, чем в других мобильных ОС, иначе вы лишитесь возможности использовать новые фишки, датчики, приложения и прочие полезные штуки. Ядро работает с приложениями и драйверами через API системы, и только на этом уровне драйверов и системных приложений можно писать программы на языке С++. Среднюю часть машины занимает платформа, которую можно сравнить с.NET от Майкрософт. Она управляется языком Java. Каждое приложение пользователя порождает процесс, когда платформа формирует для него виртуальную среду исполнения. В этот момент Java приложения в виде кода классов и библиотек автоматически переводятся в универсальный байт-код, исполняемый на байт-машине Delvik. Эта машина имеет много общего с Java-машиной JVM.

Приложения работают в изолированной друг от друга среде, захватывая только те ресурсы, которые им необходимы. В этом коренное отличие, например, от программ на ПК, где любая программа может захватить все ресурсы. Хотя приложения оптимизированы по качеству кода и изолированы друг от друга, у них есть не только приоритеты вытесняющей многозадачности, но и способы обмена данными и файлами путем присвоения им одинаковых идентификаторов. Таким образом, можно сделать так, что родственные программы будут тратить минимум лишних ресурсов, обращаясь к API через платформу, а также общим файлам профилей, спискам контактов и т.д. Здесь интересно то, что Delvik можно подсунуть и другой код на Java, который виртуальная машина примет как родной. Это позволяет реализовывать многочисленные виртуальные системы разработки, применять новые языки программирования и даже менять фреймворк приложений на альтернативные варианты – лишь бы он умел генерировать байт-код и соответствовать вызовам API.

Платформа, или фреймворк, работает с данными унифицированным образом, переводя их в формат баз данных SQLite – с таким же форматом работает, к примеру, Mozilla на ПК. Доступом в Сеть заведует оптимизированный для мобильных устройств браузер Chrome. Для создания безупречной графики API поддерживает технологию OpenGL ES v.3.0, а также целый набор жадных графических и видеоформатов и контейнеров для их хранения, включая h.264, mkv, MP4 и т.д.

Связь с другими устройствами – проводная (USB, карты памяти) и беспроводная (BT, IR, Wi-Fi, EDGE/3G/LTE). Множество датчиков завязаны на получение сигналов извне системы: GPS, акселерометр, компас, фотосъемка, датчик темноты, фитнес-датчики.

В заводском состоянии 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 должен подключить все файловые системы, перечисленные в файле./fstab.имя_устройства, который имеет следующую структуру:

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

Обычно в нем содержатся инструкции по подключению файловых систем из внутренних 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, операционка от гугла имеет очень гибкую архитектуру, которая позволяет серьезно менять ее поведение без необходимости писать код. В большинстве случаев достаточно подправить нужные конфиги и скрипты.