Основы безопасности операционной системы Android. Native user space, ч.1. Введение в андроид устройство

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

Работа со структурой папок и файлов в Android.

В какой папке находятся контакты и другие данные на Android? Формат файловой системы Android не похож на . Вот как организована внутренняя память здесь:

Память устройства – это память, с которой вы будете работать. Здесь вы сможете использовать и изменять любые файлы. Как проводник Windows или Mac. Здесь хранятся данные некоторых приложений – фотографии, видео, кэш игр или интернет-браузера и т. д.
SD-карта – на многих устройствах Android также есть слоты для SD-карт. Вы можете подключить SD-карту к компьютеру или другому устройству, загрузить на неё файлы и затем вставить в смартфон. Если вы используете устройство на Marshmallow и SD-карту, отформатированную для использования в качестве внутреннего накопителя, она не будет отображаться в файловом менеджере отдельно, а вместо этого станет частью вашего устройства.
Root – в Android есть специальная корневая папка, в которой хранятся данные , конфиденциальная информация и т. д. Большинство файловых менеджеров не могут вносить здесь изменения из соображений безопасности. Если только у вас нет доступа root и файлового менеджера, способного его использовать. Получение root и доступ к системным данным требуют знаний об устройстве системы и назначении её компонентов, поэтому новичкам лучше не рисковать.

Все фотографии с камеры телефона сохраняются в этой папке, как и на других цифровых камерах. Они отображаются в утилитах «Галерея» или «Фото», но физически находятся здесь. Это касается и хранения видеофайлов.
Bluetooth – говорит само за себя;
Download. Здесь располагаются загрузки браузера. Их можно свободно изменять, удалять или перемещать. Скачанные файлы можно экспортировать на любой накопитель.
Movies, Music, Pictures, Ringtones, Video. Это папки, предназначенные для хранения ваших личных медиафайлов. Необходимы для быстрого доступа и синхронизации Android-смартфона с ПК.
папка System хранит все системные настройки и данные всех приложений смартфона.

Вы можете просматривать эти папки из любого файлового менеджера. Один щелчок по файлу отобразит список установленных приложений, которые его поддерживают. Вы можете работать с хранящимися здесь данными напрямую, открывая их как на ПК.

Как управлять файлами и использовать файловую систему на Android

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

Как получить доступ к встроенному файловому менеджеру Android

В устройствах Android 6.x (Marshmallow) или новее есть встроенный файловый менеджер, он просто скрыт в настройках. Откройте Настройки-Память-Другое, и вы получите полный список всех файлов и папок в памяти смартфона. Приложение также можно вывести отдельным ярлыком на рабочий экран. В версии Nougat Android 7 файловый менеджер является частью приложения «Загрузки», но по сути это одно и то же. Здесь отображаются определённые типы файлов, такие как изображения, видео, музыка и загрузки. Чтобы получить доступ к полной файловой системе телефона, зайдите в Настройки-Память-Другое.

Сторонний менеджер

Но встроенный менеджер довольно слаб по сравнению с некоторыми вариантами, доступными в Google Play. Для более эффективного управления файлами установите один из доступных файловых менеджеров. Solid Explorer – один из самых популярных файловых менеджеров в Play Market. Он имеет мощные встроенные функции, такие как доступ к облачной учётной записи и двух окон в ландшафтном режиме (на любом устройстве!). Хорошо работает поддержка клиентов и часто выходят обновления. Через 2 недели бесплатная пробная версия закончится, и за дальнейшее использование придётся заплатить 2 доллара.

ES File Explorer – один из лучших root-файл менеджеров, доступных в Google Play Store. Одной из основных особенностей утилиты является использование Корзины, где хранятся недавно удалённые данные. Это бесплатное приложение не только содержит все основные функции управления файлами, но также имеет возможность управлять любыми приложениями на рутированном смартфоне. Возможности утилиты:

доступ, сортировка, передача, переименование, копирование и вставка, удаление, резервное копирование или восстановление любых файлов и папок на устройствах Android с root;
сжимайте документы, распаковывайте сжатые данные;
зашифруйте данные паролем;
загрузите мультимедиа в облачные сервисы.

Root Browser File Manager – мощный и эффективный проводник с внушительным функционалом. Особенности:

Измените возможности доступа на смартфоне или других устройствах;
отправляйте файлы по отдельности или партиями;
создавайте папки и изменяйте их на своё усмотрение;
сделайте полную копию, удалите, переименуйте и даже переместите данные на другое устройство;
сохраните файлы в любом месте на устройстве.

File Manager + позволяет управлять файлами и папками на устройстве, NAS и в облачном сервисе. Управляйте файлами как в локальной папке, так и в облачном хранилище. Поддерживает все действия проводника, такие как просмотр, поиск, навигация по структуре папок, копировать/вставить, вырезать/удалить, переименовать, распаковывать и сортировать. Полный контроль над файлами мультимедиа, документами и APK. Доступ к удалённому или совместному хранилищу, например, к NAS и FTP-серверу. Проанализируйте локальное хранилище, чтобы удалить ненужные файлы.

Если вам необходим доступ к записям календаря или заметкам, необходимо отталкиваться от используемого приложения. Все файлы данных утилит находятся в папке /data/. В File Explorer от NextApp есть новые способы передачи файлов между Android и компьютером, встроена поддержка нескольких Windows, что позволяет одновременно просматривать два окна, а также поддержка большинства форматов файлов и документов, в которых хранятся приложения. Доступ к сетевому компьютеру, включая FTP, WebDAV и SMB. Просмотр аудиоконтента, плейлистов, альбомов и исполнителей.

Как добавить свои собственные мелодии и звуки уведомлений

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

Для начала вам нужно скачать мелодию звонка или звук уведомления прямо на ваше устройство Android или перенести её с компьютера на внутреннее хранилище. Android поддерживаются форматы MP3, M4A, WAV и OGG, поэтому практически любой аудиофайл, который вы можете скачать, будет работать.

Шаг 2. Скопируйте звуковые файлы в соответствующую папку

После того, как вы загрузили звуковой файл, вам нужно переместить его в нужную папку. Здесь необходимо использовать сторонний файловый менеджер. Рассмотрим процедуру на примере ES File Explorer. После установки проводника откройте его и перейдите в папку «Download» во внутренней памяти или на SD-карте (в зависимости от настроек девайса). Выделите файл длинным нажатием, затем в меню нажмите Вырезать. Нажмите кнопку «Назад» один раз, чтобы вернуться в предыдущий каталог. Здесь откройте папку Ringtones, затем нажмите «Вставить». Если на вашем устройстве нет папки «Ringtones», просто создайте её.

Шаг 3. Перезагрузите смартфон

После переноса рингтона в нужную папку перезагрузите телефон или планшет, чтобы Android мог увидеть файл. Откройте «Настройки» и перейдите к «Звук и уведомление». Выберите «Рингтон» или «Мелодия уведомления по умолчанию», найдите в списке стандартных сигналов свой и установите его в качестве мелодии звонка. Если вы используете SD-карту, получить доступ к каталогу Android можно также и через cardreader и ПК. При этом могут обнаружиться новые каталоги, которые не отображаются в проводнике Android. Тем более в том случае, если вы используете одну и ту же SD-карту на нескольких устройствах.

В какой папке находятся контакты и другие данные

Доступ к этим документам можно получить только и стороннего файлового менеджера. Файл с контактами называется contacts.db или contacts2.db, и располагается по пути:

/data/data/com.android.providers.contacts/databases/

Это файл базы данных, поэтому углубляться в его редактирование не стоит. Чтобы экспортировать контакты в файл и сохранить его на карте памяти или ПК, воспользуйтесь встроенными инструментами. Откройте «Контакты», затем «Меню», выберите «Экспорт» и отметьте нужные контакты, затем выберите «Экспорт на карту памяти» и нажмите ОК. В папке storage/sdcard1 появится документ с расширением.vcf. перенесите его на другое устройство или ПК. Чтобы восстановить контакты, зайдите в меню «Контакты», выберите «Импорт из внутренней памяти». Укажите путь, по которому хранятся контакты на вашем Android и дождитесь окончания копирования.

Текстовые сообщения и MMS также хранятся в паке data:

/data/data/com.android.providers.telephony/ databases/mmssms.db

Для их сохранения или переноса на другой девайс понадобится специальное ПО. Например, SMS Backup & Restore или другое подобное. Такой софт работает по одному принципу – запустите утилиту – Backup SMS – укажите путь для сохранения и дождитесь окончания операции. После этого скопируйте файл на ПК или другое устройство. Восстановить SMS можно с помощью той же утилиты. Выберите Restore SMS, укажите путь где хранятся смс и дождитесь окончания восстановления.

Управление данными и файлами в Android напоминает навигацию по каталогам Windows или Linux. Только здесь необходимо получить специальные разрешения на изменение системных данных – root-права.

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

Смысл существования такой системы, конечно же, в том, чтобы сэкономить процессор, оперативную память, а также ресурс батареи. Благодаря ей (но не только) iPhone мог работать быстро в условиях ограниченных ресурсов и очень бережно относился к батарее.

Как устроена операционная система Андроид

Android всегда работал иначе. Здесь можно запустить множество различных приложений и все они будут оставаться в памяти и даже смогут работать в фоне. Вы открываете браузер, вводите адрес и, пока загружается страница, запускаете почтовый клиент и читаете письма. Все как на десктопе, с тем исключением, что вам не нужно заботиться о закрытии приложений, система сделает это сама, когда оперативная память подойдет к концу или ее не хватит для размещения запускаемого приложения (само собой, в первую очередь в расход пойдут редко используемые приложения). Этот механизм называется lowmemorykiller .

Имея права root, настройки lowmemorykiller можно регулировать напрямую или с помощью специальных приложений

Важным элементом системы многозадачности были службы (service). Это особые компоненты приложений, которые могли работать в фоне абсолютно в любых условиях: включен экран или выключен, свернуто приложение или развернуто, службам плевать даже на то, запущено ли родительское приложение вообще. Оно просто говорило: «Эй, Android, мне нужны ресурсы процессора, я хочу сделать некоторые расчеты» - и получало эти ресурсы. В терминологии Android такой запрос к системе называется wakelock (а если точнее - процессорный wakelock).

Однако поддержка такого мощного и полезного инструмента сыграла с Google злую шутку. Появилось огромное количество приложений, которые плодили службы на каждый чих, постоянно выполняли какую-то работу и не давали смартфону спать. Установив на смартфон сотню приложений, пользователь получал несколько десятков служб, каждая из которых периодически что-то делала (обновить ленту твиттера, пока телефон спит, - это же так важно).

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

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

Сама Google также предпринимала определенные действия для борьбы с «ядовитыми» службами. Большой шаг в этом направлении был сделан в Android 4.4, где появился интеллектуальный механизм, который определял, не работает ли служба слишком много времени и не сильно ли она грузит процессор, и, если это оказывалось так, прибивал ее на месте и не давал запуститься. Даже на поверхностный взгляд эта версия системы жила на батарейке заметно дольше предыдущих.

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

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

И наконец, в Android 8.0 Google пошла на радикальный шаг - запретила работу фоновых служб. Но с двумя исключениями:

Приложение в некоторых случаях, например когда оно находится на экране, может запускать службы, но Android прибьет их после ухода приложения в сон.
Видимые пользователю службы до сих пор разрешены. Это так называемый foreground service , служба, которая видна в панели уведомлений и имеет иконку в статусбаре.

Казалось бы, да, службы - это зло, но как теперь быть таким приложениям, как противоугонное, которое должно работать незаметно в фоне? Или тот же почтовый клиент? Из-за необходимости периодически проверять почту он должен висеть в панели уведомлений?

На самом деле нет. Google шла к запрету служб еще с версии 5.0, где появился так называемый JobScheduler . Это специальная подсистема, которая позволяет приложениям попросить Android выполнить ту или иную работу в такое-то время или при возникновении такого-то события (подключение к интернету, например). И да, JobScheduler сильно напоминает аналогичную функцию из iOS.

Binder

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

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

Работу Binder обеспечивают драйвер в ядре Linux и Service Manager

Эта особенность дала Android очень широкие возможности автоматизации, о которых мы знаем благодаря таким приложениям, как Tasker, Automate или Locale. Все эти приложения доступны и для Android 8, разве что некоторые опасные возможности, такие как включение/выключение режима полета, теперь запрещены для использования обычными приложениями.

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

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

Google исправила это недоразумение опять же в Android 8.0. Теперь приложения могут регистрировать обработчики широковещательных интентов только во время своей работы (за небольшими исключениями).

Сервисы Google

Google любит бравировать тем, что Android - операционная система с открытым исходным кодом. Это, конечно же, не совсем так. С одной стороны, код Android действительно открыт, и именно поэтому мы имеем доступ к такому количеству разнообразных кастомных прошивок. С другой стороны, собрав Android из официальных исходников, вы получите систему без нескольких важных компонентов: 1) отдельных драйверов, исходники которых производитель прячет, как коммерческую тайну, 2) сервисов Google, которые нужны в первую очередь для получения доступа к аккаунту, запуска Google Play и облачного бэкапа.

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

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

Скачать пакет с сервисами и приложениями Google для кастомной прошивки можно с сайта opengapps.org (слово open не означает, что они открыты)

Именно поэтому на свет появился проект microG, задача которого - воссоздать самую важную функциональность сервисов Google в открытом коде. Уже сейчас microG позволяет получить доступ к своему аккаунту, активировать push-уведомления, доступ к картам Google и определению местоположения по сотовым вышкам. И все это при размере в четыре мега и почти полном отсутствии требований к оперативке и ресурсу батареи.

У проекта есть собственная сборка прошивки LineageOS, которая из коробки включает в себя microG и все необходимые для его работы модификации.

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

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

Слоеный пирог Android

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

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

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

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

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

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

Сегодня SELinux используется для защиты почти всех системных компонентов Android. И это стало причиной резкого снижения количества найденных багов в Android. Но привело к фокусировке взломщиков на ядре, а точнее тех самых закрытых драйверах, аудит кода которых никто не проводил и безопасность которых не гарантирована (а она, как оказалось, находится в плачевном состоянии).

(1 оценок, среднее: 5,00 из 5)

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

Как работает Android

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

Шаг первый. ABOOT и таблица разделов

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

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

Часть кода загрузчика, определяющая таблицу разделов

Шаг второй. Раздел 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.

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

Шаг второй, альтернативный. Раздел recovery

В том случае, если флаг загрузки recovery в разделе misc установлен или пользователь включил смартфон с зажатой клавишей уменьшения громкости, aboot передаст управление коду, расположенному в начале раздела recovery. Как и раздел boot, он содержит ядро и RAM-диск, который распаковывается в память и становится корнем файловой системы. Однако содержимое RAM-диска здесь несколько другое.

Шаг третий. Инициализация

Итак, получив управление, ядро подключает RAM-диск и по окончании инициализации всех своих подсистем и драйверов запускает процесс init, с которого начинается инициализация Android. Как я уже говорил, у init есть конфигурационный файл init.rc, из которого процесс узнает о том, что конкретно он должен сделать, чтобы поднять систему. В современных смартфонах этот конфиг имеет внушительную длину в несколько сот строк и к тому же снабжен прицепом из нескольких дочерних конфигов, которые подключаются к основному с помощью директивы import. Тем не менее его формат достаточно простой и по сути представляет собой набор команд, разделенных на блоки.

Часть конфига init.rc из CyanogenMod

Mount_all ./fstab.имя_устройства

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

Типичное содержимое файла fstab

Шаг четвертый. Zygote и app_process

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

Все это может выглядеть несколько непонятно, но самое главное - запомнить три простые вещи:

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

Выводы

Во многом Android сильно отличается от других ОС, и с наскоку в нем не разобраться. Однако, если понять, как все работает, открываются просто безграничные возможности. В отличие от iOS и Windows Phone, операционка от гугла имеет очень гибкую архитектуру, которая позволяет серьезно менять ее поведение без необходимости писать код. В большинстве случаев достаточно подправить нужные конфиги и скрипты.

В этой серии статей я расскажу о внутреннем устройстве Android - о процессе загрузки, о содержимом файловой системы, о Binder и Android Runtime, о том, из чего состоят, как устанавливаются, запускаются, работают и взаимодействуют между собой приложения, об Android Framework, и о том, как в Android обеспечивается безопасность.

Статьи серии:

Как работает Android, часть 1

Немного фактов

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

Android - свободный и открытый проект. Большинство исходного кода (который можно найти на ) распространяется под свободной лицензией Apache 2.0.

Компания Android Inc. была основана в 2003 году и в 2005 году куплена Google. Публичная бета Android вышла в 2007 году, а первая стабильная версия - в 2008, с тех пор мажорные релизы выходят примерно раз в год. Последняя на момент написания стабильная версия Android - 7.1.2 Nougat.

Android is Linux

По поводу такой формулировки было много споров, так что сразу поясню, что именно я имею в виду под этой фразой: Android основан на ядре Linux, но значительно отличается от большинства других Linux-систем.

Среди исходной команды разработчиков Android был Robert Love, один из самых известных разработчиков ядра Linux, да и сейчас компания Google остаётся одним из самых активных контрибьюторов в ядро, поэтому неудивительно, что Android построен на основе Linux.

Как и в других Linux-системах, ядро Linux обеспечивает такие низкоуровневые вещи, как управление памятью, защиту данных, поддержку мультипроцессности и многопоточности. Но - за несколькими исключениями - вы не найдёте в Android других привычных компонентов GNU/Linux-систем: здесь нет ничего от проекта GNU, не используется X.Org, ни даже systemd. Все эти компоненты заменены аналогами, более приспособленными для использования в условиях ограниченной памяти, низкой скорости процессора и минимального потребления энергии - таким образом, Android больше похож на встраиваемую (embedded) Linux-систему, чем на GNU/Linux.

Другая причина того, что в Android не используется софт от GNU - известная политика «no GPL in userspace»:

We are sometimes asked why Apache Software License 2.0 is the preferred license for Android. For userspace (that is, non-kernel) software, we do in fact prefer ASL 2.0 (and similar licenses like BSD, MIT, etc.) over other licenses such as LGPL.
Android is about freedom and choice. The purpose of Android is promote openness in the mobile world, and we don’t believe it’s possible to predict or dictate all the uses to which people will want to put our software. So, while we encourage everyone to make devices that are open and modifiable, we don’t believe it is our place to force them to do so. Using LGPL libraries would often force them to do just that.

Само ядро Linux в Android тоже немного модифицировано: было добавлено несколько небольших компонентов, в том числе ashmem (anonymous shared memory), Binder driver (часть большого и важного фреймворка Binder, о котором я расскажу ниже), wakelocks (управление спящим режимом) и low memory killer. Исходно они представляли собой патчи к ядру, но их код был довольно быстро добавлен назад в upstream-ядро. Тем не менее, вы не найдёте их в «обычном линуксе»: большинство других дистрибутивов отключают эти компоненты при сборке.

В качестве libc (стандартной библиотеки языка C) в Android используется не GNU C library (glibc), а собственная минималистичная реализация под названием , оптимизированная для встраиваемых (embedded) систем - она значительно быстрее, меньше и менее требовательна к памяти, чем glibc, которая обросла множеством слоёв совместимости.

В Android есть оболочка командной строки (shell) и множество стандартных для Unix-подобных систем команд/программ. Во встраиваемых системах для этого обычно используется пакет Busybox , реализующий функциональность многих команд в одном исполняемом файле; в Android используется его аналог под названием Toybox . Как и в «обычных» дистрибутивах Linux (и в отличие от встраиваемых систем), основным способом взаимодействия с системой является графический интерфейс, а не командная строка. Тем не менее, «добраться» до командной строки очень просто - достаточно запустить приложение-эмулятор терминала. По умолчанию он обычно не установлен, но его легко, например, скачать из Play Store (Terminal Emulator for Android , Material Terminal , Termux). Во многих «продвинутых» дистрибутивах Android - таких, как LineageOS (бывший CyanogenMod) - эмулятор терминала предустановлен.

Второй вариант - подключиться к Android-устройству с компьютера через Android Debug Bridge (adb). Это очень похоже на подключение через SSH:

user@desktop-linux$ adb shell android$ uname Linux

Из других знакомых компонентов в Android используются библиотека FreeType (для отображения текста), графические API OpenGL ES , EGL и Vulkan , а также легковесная СУБД SQLite .

Кроме того, раньше для реализации WebView использовался браузерный движок WebKit , но начиная с версии 7.0 вместо этого используется установленное приложение Chrome (или другое; список приложений, которым разрешено выступать в качестве WebView provider, конфигурируется на этапе компиляции системы). Внутри себя Chrome тоже использует основанный на WebKit движок Blink , но в отличие от системной библиотеки, Chrome обновляется через Play Store - таким образом, все приложения, использующие WebView, автоматически получают последние улучшения и исправления уязвимостей.

It’s all about apps

Как легко заметить, использование Android принципиально отличается от использования «обычного Linux» - вам не нужно открывать и закрывать приложения, вы просто переключаетесь между ними, как будто все приложения запущены всегда. Действительно, одна из уникальных особенностей Android - в том, что приложения не контролируют напрямую процесс, в котором они запущены. Давайте поговорим об этом подробнее.

Основная единица в Unix-подобных системах - процесс. И низкоуровневые системные сервисы, и отдельные команды в shell’е, и графические приложения - это процессы. В большинстве случаев процесс представляет собой чёрный ящик для остальной системы - другие компоненты системы не знают и не заботятся о его состоянии. Процесс начинает выполняться с вызова функции main() (на самом деле _start), и дальше реализует какую-то свою логику, взаимодействуя с остальной системой через системные вызовы и простейшее межпроцессное общение (IPC).

Поскольку Android тоже Unix-подобен, всё это верно и для него, но в то время как низкоуровневые части - на уровне Unix - оперируют понятием процесса, на более высоком уровне - уровне Android Framework - основной единицей является приложение . Приложение - не чёрный ящик: оно состоит из отдельных компонентов, хорошо известных остальной системе.

У приложений Android нет функции main() , нет одной точки входа. Вообще, Android максимально абстрагирует понятие приложение запущено как от пользователя, так и от разработчика. Конечно, процесс приложения нужно запускать и останавливать, но Android делает это автоматически (подробнее я расскажу об этом в следующих статьях). Разработчику предлагается реализовать несколько отдельных компонентов, каждый из которых обладает своим собственным жизненным циклом.

In Android, however, we explicitly decided we were not going to have a main() function, because we needed to give the platform more control over how an app runs. In particular, we wanted to build a system where the user never needed to think about starting and stopping apps, but rather the system took care of this for them… so the system had to have some more information about what is going on inside of each app, and be able to launch apps in various well-defined ways whenever it is needed even if it currently isn’t running.

Для реализации такой системы нужно, чтобы приложения имели возможность общатся друг с другом и с системными сервисами - другими словами, нужен очень продвинутый и быстрый механизм IPC.

Этот механизм - Binder.

Binder

Binder - это платформа для быстрого, удобного и объектно-ориентированного межпроцессного взаимодействия.

Разработка Binder началась в Be Inc. (для BeOS), затем он был портирован на Linux и открыт. Основной разработчик Binder, Dianne Hackborn, была и остаётся одним из основных разработчиков Android. За время разработки Android Binder был полностью переписан.

Binder работает не поверх System V IPC (которое даже не поддерживается в bionic), а использует свой небольшой модуль ядра, взаимодействие с которым из userspace происходит через системные вызовы (в основном ioctl) на «виртуальном устройстве» /dev/binder . Со стороны userspace низкоуровневая работа с Binder, в том числе взаимодействие с /dev/binder и marshalling/unmarshalling данных, реализована в библиотеке .

Низкоуровневые части Binder оперируют в терминах объектов, которые могут пересылаться между процессами. При этом используется подсчёт ссылок (reference-counting) для автоматического освобождения неиспользуемых общих ресурсов и уведомление о завершении удалённого процесса (link-to-death) для освобождения ресурсов внутри процесса.

Высокоуровневые части Binder работают в терминах интерфейсов, сервисов и прокси-объектов. Описание интерфейса, предоставляемого программой другим программам, записывается на специальном языке AIDL (Android Interface Definition Language), внешне очень похожем на объявление интерфейсов в Java. По этому описанию автоматически генерируется настоящий Java-интерфейс, который потом может использоваться и клиентами, и самим сервисом. Кроме того, по.aidl -файлу автоматически генерируются два специальных класса: Proxy (для использования со стороны клиента) и Stub (со стороны сервиса), реализующие этот интерфейс.

Для Java-кода в процессе-клиенте прокси-объект выглядит как обычный Java-объект, который реализует наш интерфейс, и этот код может просто вызывать его методы. При этом сгенерированная реализация прокси-объекта автоматически сериализует переданные аргументы, общается с процессом-сервисом через libbinder, десериализует переданный назад результат вызова и возвращает его из Java-метода.