Android под свое устройство

Строим Android x86

Установка окружения для сборки

Для сборки Android потребуется 64 битная версия Linux. Еще один важный момент: обратите внимание на версию GCC, которая установлена на системе. Google поддерживает версию GCC 4.4 и выше. Так же на системе должна быть установлена реализация Java от Oracle.
Установка дополнительных зависимостей для Ubuntu 12.04:

Установите символьную ссылку для устранения конфликта имен:

Загрузка дерева исходных кодов

Установка Repo

Repo — утилита управления репозиториями, упрощающая работу с Git для Android. Более подробную информацию можно прочесть здесь (http://source.android.com/source/version-control.html)
Для установки, инициализации и настройки Repo выполните следующие шаги:
• Убедитесь, что у вас есть директория bin в вашем домашнем каталоге и она прописана в PATH:

• Загрузите Repo скрипт и выставите права на выполнение:

Инициализация Repo клиента

После установки Repo, настройте доступ к репозиториям исходных кодов Android:
• Создайте пустую директорию для исходных файлов и перейдите в нее. Например, это может выглядеть так:

• Запустите скрипт repo init, чтобы обновить версию самого Repo.

Эта команда подключит ветку master из дерева исходных кодов Android. Вы можете указать любую другую, используя ключ -b:

Для просмотра всех доступных веток введите команду:

Нас интересуют наиболее последние версии Android от Google:

• Jelly Bean: remotes/origin/android-4.1.1_r6
• Ice Cream Sandwich: remotes/origin/android-4.0.4_r2.1

Можно выбрать любую на ваш вкус, дальнейшие шаги не будут отличаться. Для демонстрации процесса сборки под VirtualBox возьмем версию Jelly Bean (JB).
В случае успешной инициализации вы увидите сообщение о том, что Repo инициализирован в вашей директории и в ней появится папка .repo

Загрузка файлов

Чтобы загрузить исходные файлы из репозитория в вашу рабочую директорию выполните команду:

Начальная синхронизация может занять больше часа времени.

Сборка ядра

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

Воспользуемся заранее подготовленной версией ядра от Intel:

Перейдем в директорию ядра:

Теперь у нас есть исходники ядра. Нужно модифицировать конфигурационный файл и пересобрать. Чтобы сократить время на полную настройку ядра, воспользуемся конфигурационным файлом, который подготовили для на разработчики. Важный момент — не забывайте указать архитектуру для которой происходит сборка ядра, в нашем случае это x86.

Через несколько секунд загрузится графическое меню настройки ядра. Стрелками «вверх», «вниз» вы можете передвигаться по пунктам меню, «Enter» чтобы зайти в подменю. Все точно так же как с обычным ядром Linux.

Чтобы включить поддержку мыши:
• Зайдите в «Device Drivers»
• Выберите «Input device Support»
• Отметьте «Mice»
Вы можете зайти в подменю «Mice» и посмотреть дополнительные настройки драйверов.
Затем выйдите из меню конфигурации ядра. Это можно сделать с помощью нескольких нажатий на «Esc». Не забудьте сохранить настройки, когда меню конфигурации предложит это сделать.
Сделав необходимые настройки ядра, соберем его. Это не займет много времени, особенно если вы используете многоядерную машину — можете указать опцию команды make: -j N, где N — число ядер (например, для написания статьи использовалась make -j 32).

При успешной компиляции вы увидите сообщение:

Путь до нового ядра указан в последней строке.

Подмена ядра

Путь к ядру, которое будет использовано в сборке для VirtualBox можно определить следующим образом:

Должно вывестись примерно следующее:

Скопируем bzImage по найденному пути:

Построение Android

Установим окружение для сборки:

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

После выполнения команды вы увидите информацию о предстоящей сборке:

Затем необходимо запустить сборку исходников командой make. Хорошим тоном считается сохранять лог сборки, это можно сделать с помощью утилиты tee.

Процесс сборки может занять значительное время, конкретные цифры зависят от мощности центрального процессора и объема оперативной памяти машины. На системе, которая использовалась для подготовки статьи это заняло около часа. Рекомендуемое число потоков для сборки можно определить из расчета 2GB оперативной памяти на поток.
При успешной компиляции, последняя строка вывода будет содержать путь и размер образа:

Далее необходимо собрать загрузочный образ для VirtualBox:

Если сборка прошла успешно, в консоли должна появиться запись:

Настройка VirtualBox

Эмулятор Jelly Bean

Сборка эмулятора мало чем отличается от сборки версии для VirtualBox. Если у вас уже есть исходные коды, то приступайте к сборке с шага инициализации окружения. Для чистоты эксперимента, будет процесс постройки эмулятора будет изложен с самого начала. Поэтому создадим отдельную директорию для Jelly Bean Emulator и повторим уже знакомые шаги.

Загрузка исходных кодов

Выбор сборки эмулятора

В случае успеха вы увидите:

Пока идет процесс компиляции, скопируем конфигурационный файл и соберем ядро для эмулятора.

Теперь сборка эмулятора завершена.
Самый простой способ запустить его:

Например, можно запустить с только что собранным ядром, с разрешением 480×800, объемом оперативной памяти 512 мегабайт и включенным аппаратным ускорением графики.

Более подробно о возможностях и настройках эмулятора можно прочитать здесь

Источник

Что делать, если под рукой нет Android-устройства? Обзор Android-эмуляторов

Введение

Часто бывает необходимость проверить работу свеженаписанного приложения на устройстве. Но вполне может оказаться, что устройства под рукой нет. Или нет устройства с определенными параметрами (правда, это больше относится к размеру/разрешению экрана). Что же делать в этом случае?
К счастью, альтернативы есть. Android-сообщество и разные компании предлагают на выбор несколько вариантов замены android-устройств для разных целей.

Я кратко расскажу о следующих:

• Эмулятор в составе SDK
• Genymotion
• Android x86
• Bluestacks

Если интересно — добро пожаловать под кат (осторожно, достаточно много картинок)

Эмулятор в составе SDK

Сайт: http://developer.android.com/sdk/index.html
Самый очевидный способ подмены устройства. Если занимаешься разработкой под Android — эмулятор точно есть.

Использование

Плюсы

Минусы

• Медленный, если не использовать HAXM
• Не ARM, если использовать HAXM
• Нет эмуляции Bluetooth, OTG, наушников и некоторых других железных параметров

Genymotion

Сайт: http://www.genymotion.com/
Проприетарная реализация, выросшая из проекта AndroVM.
По сути, виртуальная машина на VirtualBox с дополнительными фишками вроде своих контролов, расширенной настройки и т.д.
Достаточно удобен, быстр, много возможность, коммандлайн тулы, Java API для тестов.
При создании устройства из сети выкачивается его образ.
APK можно устанавливать, перетянув их на окно с виртуалкой.

Плюсы

Минусы

• Платный для компаний, и это главный минус
• Не ARM
• Достаточно долгий выход актуальных версий Android

Android x86

Сайт: http://www.android-x86.org/
Проект по портированию Android на платформу x86. Распространяется в виде образа iso, можно запустить/установить в виртуальной машине, при большом желании можно даже поставить на живую машину с x86 процессором (на ноутбук, например).
Работает быстро, но есть куча проблем из-за того, что это виртуальная машина. Например, привязывние мыши внутри окна виртуалки, доступ к adb только по сети и т.д.

Для использования в VirtualBox нужно отключать Mouse Integration, иначе в виртуальной машине не видно курсора.

Для подключения adb нужно выполнить

IP-адрес можно узнать, нажав в машине Alt+F1 и введя netcfg. Вернуться в графический режим — Alt+F7.

Плюсы

Минусы

• Неудобный доступ к adb
• Минусы, связанные с использованием VM — привязка мыши, например
• Не ARM
• Очень долгий выход актуальных версий

Bluestacks

Сайт: www.bluestacks.com
Позиционируется как плеер приложений для Windows, Mac и TV. Умеет запускать приложения, имеет доступ к маркету. Неудобен для разработки и тестирования — apk ставятся тулом из комплекта, но доступ к adb можно получить. Однако для запуска приложений может быть полезен.
Для подключения через adb:

Плюсы

Минусы

• Неудобно ставить приложения
• Непонятно, что с версиями android (2.3 под OS X, под Windows ставился 4.0)
• Нет под linux

Источник

Познавательно-практический экскурс в архитектуру 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-памяти, так что для ее изменения перепрошивка загрузчика не нужна.

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

Хакер #184. Современный фронтенд

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

Шаг второй. Раздел boot

Если в разделе misc не стоит флаг загрузки в recovery, aboot передает управление коду, расположенному в разделе boot. Это не что иное, как ядро Linux; оно находится в начале раздела, а сразу за ним следует упакованный с помощью архиваторов cpio и gzip образ RAM-диска, содержащий необходимые для работы Android каталоги, систему инициализации init и другие инструменты. Никакой файловой системы на разделе boot нет, ядро и RAM-диск просто следуют друг за другом. Содержимое RAM-диска такое:

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

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

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

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

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

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

Файл build.prop предназначен для хранения низкоуровневых настроек Android. Позже система обнулит эти настройки и перезапишет их значениями из недоступного пока файла system/build.prop.

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

Выносы из текста

• 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 и запустить команду

На экран будет выведено имя устройства. Другие доступные команды:

• fatsboot oem unlock — разлочка загрузчика на нексусах;
• update файл.zip — установка прошивки;
• flash boot boot.img — прошивка образа boot-раздела;
• flash recovery recovery.img — прошивка образа раздела recovery;
• flash system system.img — прошивка образа системы;
• boot recovery.img — загрузка образа recovery без прошивки;
• oem format — восстановление разрушенной таблицы разделов;
• reboot — перезагрузка.

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

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

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

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

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

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

Она означает, что теперь init должен подключить все файловые системы, перечисленные в файле ./fstab.имя_устройства, который имеет следующую структуру:

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

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

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

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

Команды init.rc

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

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

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

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

Это описание службы 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

В терминологии Linux RAM-диск — это своего рода виртуальный жесткий диск, существующий только в оперативной памяти. На раннем этапе загрузки ядро извлекает содержимое диска из образа и подключает его как корневую файловую систему (rootfs).

В процессе загрузки Android отображает три разных загрузочных экрана: первый появляется сразу после нажатия кнопки питания и прошит в ядро Linux, второй отображается на ранних этапах инициализации и записан в файл /initlogo.rle (сегодня почти не используется), последний запускается с помощью приложения bootanimation и содержится в файле /system/media/bootanimation.zip.

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

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

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

• Процесс запуска Android делится на две ключевые стадии: до Zygote и после. До старта Zygote система инициализирует низкоуровневые компоненты ОС. Это такие операции, как подключение (монтирование) файловых систем, запуск низкоуровневых служб (например rild, отвечающий за работу с GSM-модемом, SurfaceFlinger, управляющий тем, что изображено на экране, vold, управляющий подключенными файловыми системами). После запуска Zygote начинается инициализация исключительно Java-компонентов, которые составляют 80% операционной системы. Этим, в частности, пользуется известный фреймворк Xposed, который при установке подменяет app_process на собственную модифицированную версию, которая способна перехватывать вызовы любых Java-классов, подменяя их на любые другие. Именно поэтому у модулей Xposed такие широкие возможности по модификации внешнего вида и поведения Android. На самом деле они ничего не изменяют в системе, а просто заставляют ее использовать сторонние компоненты вместо своих.
• Java-приложения никогда не запускаются «с нуля». Когда Zygote получает запрос на старт приложения от Activity Manager, он не запускает новую виртуальную машину, а просто форкается, то есть копирует самого себя и затем запускает поверх полученной копии виртуальной машины нужное приложение. Такой принцип работы позволяет, во-первых, свести расход памяти к минимуму, так как Linux при форке копирует память в режиме copy-on-write (новый процесс ссылается на память старого), а во-вторых, существенно ускорить запуск приложения: форк процесса происходит намного быстрее запуска новой виртуальной машины и загрузки нужных приложению Java-классов.
• В Android повсеместно используются интенты. Для общения между собой компоненты Android никогда не применяют прямой вызов процедур и классов. Вместо этого используется система сообщений (интентов), которая, кроме высокого уровня безопасности, дает также множество других вкусностей, таких как, например, возможность вызвать приложение, ничего о нем не зная. Выше я уже писал, что для запуска рабочего стола системе достаточно послать интент Intent.CATEGORY_HOME, на который откликнется любое приложение, способное выполнять функцию лончера. Таким же образом работает кнопка «Поделиться», а также множество других компонентов системы.

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

• Официальная документация init.rc в исходниках Android: goo.gl/QciYVW
• Описание формата файла /sys/module/lowmemorykiller/parameters/minfree: goo.gl/gKdGPT
• Каталоговая структура Android: goo.gl/363Sq6
• Описание фоновых служб: goo.gl/rtmGgf

Выводы

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

Евгений Зобнин

Редактор рубрики X-Mobile. По совместительству сисадмин. Большой фанат Linux, Plan 9, гаджетов и древних видеоигр.

Источник