Что такое ядро системы андроид

Что такое Android?

Когда речь заходит об Android, многие не совсем понимают, что имеет ввиду человек. Android — это смартфон или операционная система? Что вообще такое «операционная система»? Многим может показаться этот вопрос слишком простым, но не все до конца понимают это. Операционная система — это то, благодаря чему работает смартфон. Одно дело — железка, но без установленной программы она никому не нужна. И задача операционной системы — сделать из устройства полезную вещь. В данном материале мы ответим на вопрос «Что такое Android?», окунем читателя в историю системы и познакомим с операционными системами нового поколения, которые станут заменой Android.

Что такое Android?

Что такое Android?

Android — что это?

Это операционная система. Она была создана Энди Рубином. Он стал источником идеи. Более того, Android мог называться совсем иначе, ведь Энди решил использовать данное название, потому что у него уже был куплен когда-то домен android.com. В 2005 году у Энди кончались деньги, он обращался ко многим компаниям, и тогда на проект обратили внимание ребята из Google. Они купили компанию, и разработчики Android, включая Энди Рубина, стали работать над системой уже под крылом Google.

Когда была создана ОС Android?

Энди Рубин — создатель Android

В 2005 году Google купила компанию Android, сумма сделки составила 130 миллионов долларов. Спустя два года Google запустила альянс OHA и анонсировала открытую платформу Android. С 2007 года разработчикам предоставили доступ к SDK и эмулятору Android. 23 сентября 2008 года вышла первая версия системы. С этого момента и началась эпоха Android-телефонов.

Когда Android стал популярным?

В 2007 году балом правил iPhone. Лишь с выходом Droid от Motorola, который технически был мощнее и функциональнее iPhone, Google удалось немного изменить ситуацию. Примерно с 2009 года люди стали всерьез относиться к Android — в ней начали видеть главного конкурента смартфонам Apple. И если бы не политика распространения системы, как открытой OS, вряд ли сегодня она бы занимала 80% рынка.

Android работает на ядре Linux

Что такое ядро Linux?

Android работает на ядре Linux, создателем которого является Линус Торвальдз. Работу над ядром он начал еще в 1991 году. Код ядра Linux написан на языках Си и ассемблер. Ядро Linux в настоящее время используется не только в Android-телефонах, но еще и в операционных системах семейства Linux (Ubuntu, Fedora, Debian, Red Hat и так далее).

Что такое ядро в операционной системе?

Ядро — это главный компонент операционной системы. Ядро отвечает за взаимодействие операционной системы с процессором, памятью. Оно предоставляет файловые и сетевые сервисы. Ядро — это самый низкий уровень операционной системы в вопросе взаимодействия с аппаратным обеспечением.

Список всех версий Android

• Android 1 «Apple Pie» (дата выхода 2010 год)
• Android 4.0 Ice Cream Sandwich (дата выхода 2011 год)
• Android 4.1 Jelly Bean (дата выхода 2012 год)
• Android 4.2 (дата выхода 2012 год)
• Android 4.3 (дата выхода 2013 год)
• Android 4.4 KitKat (дата выхода 2013 год)
• Android 5.0 Lollipop (дата выхода 2014 год)
• Android 5.1 (дата выхода 2015 год)
• Android 6.0 Marshmallow (дата выхода 2016 год)
• Android 7.0 Nougat (дата выхода 2016 год)
• Android 7.1 (дата выхода 2016 год)
• Android 8.0 Oreo (дата выхода 2017 год)
• Android 8.1 (дата выхода 2017 год)
• Android 9.0 Pie (дата выхода 2018 год)
• Android 10 (дата выхода 2019 год, список телефонов, которые получили Android 10, что нового в Android 10)
• Android 11 (дата выхода 2020 год, Android 11 — список нововведений)

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

Операционная система Fuchsia

Fushia — операционная система нового поколения

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

Harmony OS — операционная система от Huawei

Harmony OS — операционная система от Huawei

Это первая операционная система нового поколения на микроядре и с модульной архитектурой для смартфонов. Китайцы создали её в качестве конкурента Android. Вместе с Harmony OS Huawei будет предлагать потребителям сервисы Huawei Mobile Services с собственным магазином приложений AppGallery.

В данном материале мы рассмотрели что же такое Android, изучили историю, версии а также рассмотрели главного конкурента от Huawei. Остались вопросы? Задайте их в нашем Телеграм-чате, можете подписаться на наши новости в Яндекс Дзен.

Новости, статьи и анонсы публикаций

Свободное общение и обсуждение материалов

Трещины и царапины на дисплее смартфона выглядят неэстетично, могут негативно влиять на работу сенсоров и видимость картинки. А замена матрицы некоторых моделей может достигать половины их стоимости. Я уже не говорю о том, что экран в царапинах в принципе ухудшает восприятие устройства, и его потом будет намного сложнее продать на вторичке. Поэтому лучше заблаговременно озаботиться защитой своего аппарата и его самого уязвимого компонента, наклеив на него плёнку или стекло.

Китайский производственный гигант Huawei усердно работает и пытается придумать что-то новое с тех пор, как начали действовать запреты со стороны США. Они оказывают влияние на компанию и заставляют менять свою политику, чтобы обойти санкции или не нарваться на новые. Пока дела у компании идут довольно неплохо. В том числе это возможно благодаря разработанной некоторое время назад собственной операционной системе HarmonyOS. И вот мы стоим на пороге новой версии этой ОС, которая должна стать самым большим прорывом в ее истории. Только вот станет ли?

На какие характеристики вы обращаете внимание, если хотите купить мощный смартфон? Скорее всего, это процессор, но далеко не только от него зависит производительность устройства. Также на быстродействие влияет память, а точнее – ее тип. И в этом отношении мы стали свидетелями настоящей революции, ведь в ближайшие месяцы в продажу поступят смартфоны с накопителями UFS 4.0. Разберемся, чем этот стандарт отличается от предшественника, и действительно ли новые модели будут быстрее игровых консолей PlayStation 5 и Xbox Series X.

>Список всех версий Android

тут список далеко не ВСЕХ версий Андроид.
Почему-то забыли про версии 1.1, 1.5, 1.6, 2.0, 2.1, 2.2, 3.0, 3.1, 3.2, не говоря уже о версиях третьего порядка…

Умилило «В 2007 году балом правил iPhone. »
Да уж. �� Только «балерина» была хромой. В iOS даже Copy-Paste «забыли» встроить.Не говоря уже об убогости (по сути) первого iPhone 2S. iPod с функцией «звонилкм».
В 2007-м бал правил Windows Mobile в смартфонах. А уж iOS только потом развился и вытеснил Microsoft полностью.

Обзор особенностей ядра Андроида

В детском садике мы с единомышленниками препарировали кузнечиков в надежде разобраться в их строении. В школе распаивали радиоприёмник “Россия”. В институте дошла очередь до автомобилей, гайки которых были многократно переставлены. Интересы поменялись, но желание “разбирать” иногда просыпается, и сегодня оно направлено на Андроид.

Сколько раз вас выручало наличие исходников Андроида? Меня — уже не счесть. Андроид — открытый проект, но, к сожалению, у нас есть возможность только читать; править код Андроида, не будучи сотрудником Google, практически невозможно. Погрустим над этим моментом и загрузим репозиторий. Как это сделать, отлично описано на официальном сайте.

Общая архитектура

Архитектуру Андроида можно схематично изобразить так:

Оригинальная схема не содержит информации об особенностях ядра и не акцентирует внимание на Binder-е и системных сервисах. А ведь Binder является “клеем”, связывающим все компоненты системы.

Как правило, в книгах описывается верхний левый синий прямоугольник, то есть API, которое доступно разработчику прикладных приложений. Нас же интересует всё, что ниже. Сегодня мы рассмотрим только ядро.

Ядро — центральная часть любого дистрибутива, называемого “Линукс”. Несмотря на доступность “чистого” ядра, многие разработчики (Ubuntu, Fedora, SuSe и т.д.) добавляют к нему свои патчи перед включением в дистрибутив. Андроид идёт той же дорогой, только ценой потери прямой совместимости: на “чистом” ядре он не заведётся. В настоящее время есть намерения включить “андроидизмы” в основную версию ядра, в 2011 году Линус Торвальдс давал на этот процесс 4-5 лет. Успех уже достигнут в рамках включения механизма wakelocks в версии ядра 3.5.

Рассмотрим “андроидизмы” более подробно.

История данного механизма эпична, потянет на сборник статей “Путь wakelock-ов в Линукс”: их обсуждение заняло порядка 2000 писем в рассылке LKML.

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

На телефонах требовался другой механизм: основное состояние системы — “спячка”, выход из него осуществляется только в случаях необходимости. Таким образом, система может уснуть, даже если какое-то приложение проявляет активность. В Андроиде был реализован механизм wakelock-ов: если приложение (или драйвер) выполняет что-то важное, что должно дойти до логического завершения, оно “захватывает” wakelock, предотвращая засыпание устройства.

Попытки портирования механизма wakelock-ов в ядро вызвали сопротивление многих разработчиков. Программисты Андроида решали конкретную проблему, решением которой стал определённый механизм. Условия задачи были весьма узки. Целевая платформа — ARM, поэтому использовались её особенности: ARM-процессоры изначально предполагают частую смену режимов работы “сна” и “бодрствования”, в отличие от x86. В Андроиде приложения общаются с системой управления питанием через PowerManager, а что делать клиентским Линукс-приложениям?

Разработчики Андроида даже не пытались найти общее решение “на будущее”, которое потом без проблем бы вливалось в основное ядро, не консультировались по этой проблеме с сообществом ядра Линукс. Можно ли их за это винить? Несмотря на все проблемы и обсуждения, как упоминалось выше, в ядре появилось API с идентичной функциональностью autosleep.

Программистам приложений под Андроид довольно редко приходится сталкиваться с wakelock-ами, так как платформа и драйверы обрабатывают возложенные на них обязательства с учётом “спящего” режима. Тем не менее, вмешаться в этот процесс поможет знакомый PowerManager. Кстати, автору приходит в голову только один сценарий: не дать телефону уснуть при запуске сервиса из BroadcastReceiver-а, что решается вспомогательным классом из Android Support Library WakefulBroadcastReceiver.

Low Memory Killer

В стандартном ядре Линукса есть Out of Memory Killer, который на основании параметра badness определяет убиваемый процесс:

badness_for_task = total_vm_for_task / (sqrt(cpu_time_in_seconds) *
sqrt(sqrt(cpu_time_in_minutes)))

Таким образом, чем больше процесс потребляет памяти и чем меньше живёт, тем меньше ему повезёт.

Все программисты, читавшие документацию или проходившие собеседования, знают, что, во-первых, процесс может быть “убит” и при наличии свободных ресурсов, во-вторых, кандидат на вытеснение выбирается по другим критериям: наличие “живых” Андроид-компонент, видимость пользователю и так далее.

Механизм довольно простой: каждому процессу присваивается приоритет от -17 до 16, при этом чем выше приоритет, тем выше вероятность убивания процесса, и, в зависимости от количества свободной памяти, выбирается приоритет, начиная с которого процессы будут завершены. Приоритеты описаны в ProcessList.java. Занимательно, что приоритет приложения домашнего экрана HOME_APP_ADJ довольно высок, а я-то думал: почему он постоянно перезапускается?

Массивы mOomAdj и mOomMinFreeLow/mOomMinFreeHigh как раз задают правила “когда что очистить”:

Таким образом, приложение домашнего экрана вытесняется при остатке свободной памяти в 73728 КБ на телефоне с экраном 1280×800 и ОЗУ в 700 МБ.
ProcessList передаёт соответствующие значения в ядро, что можно видеть в его методе updateOomLevels.

Приоритеты процессам выставляет Activity Manager Service, один из многих системных сервисов, общаться с которым можно через Activity Manager.

Binder, наряду с другими решениями (Files, Sigmals, Sockets, Pipes, Semaphores, Shared Memory и т.д.), решает задачу межпроцессного взаимодействия. Ноги у данного решения растут из проекта OpenBinder, разработчики которого в своё время перешли в команду Андроида.

Bionic (реализация libc) не использует System V IPC, так как в андроидовском окружении стандартные средства приведут к утечкам ресурсов.

1. Управление потоками (мы все помним, что сервис, поддерживающий AIDL, должен работать в многопоточном окружении). Максимальное число потоков — 15 (ProcessState.c, метод open_driver), поэтому не стоит блокировать Binder-потоки в большом количестве без лишней необходимости.
2. Механизм информирования о смерти процесса, держащего объект Binder “Link to Death”. Например, через него Window Manager узнаёт о смерти приложения и удаляет связанные с ним окна. Также LocationManager при смерти всех своих слушателей перестаёт опрашивать GPS-приёмник. Lowmemorykiller доволен. 🙂
3. 2 режима вызова: блокирующий и неблокирующий (oneway). В первом случае вызывающий поток блокируется и ждёт отработки метода в потоке процесса-обработчика. Программисты просто вызывают методы через точку, взаимодействие потоков берёт на себя платформа.
4. Передача UID и PID для безопасности. Через них системные сервисы определяют, есть ли у вызывающего процесса права совершать запрашиваемые действия.
5. Для Java-программистов — средства создания Proxy и Stub-ов для конвертирования вызовов Java-методов в транзакции Binder-а.

Рассмотрим как это работает на примере LocationManager-а.

1. Наше приложение вызывает соответствующий метод у LocationManager-а.
2. LocationManager делегирует вызов прокси-объекту, преобразующему Java-методы и объекты в Binder-транзакцию (прокси-объектом у LocationManager-а является mService).
3. Транзакция посылается драйверу ядра, который перенаправляет её LocationManagerService-у, отнаследованному от .LocationManager.Stub.
4. .LocationManager.Stub делает обратные действия: разворачивает транзакцию в вызов Java-метода.
5. .LocationManagerService обрабатывает запрос (используя, например, GPS-драйвер).
6. Stub-объект пакует ответ в транзакцию, и процесс идёт в обратном направлении.
7. Драйвер пересылает ответ обратно.
8. Прокси-объект распаковывает результат вызова метода в Java-объекты.

Как видим, за вызовом методов системных сервисов скрывается довольно большая логика.

Anonymous Shared Memory (ashmem) — механизм разделяемой памяти. В Линуксе, как правило, данный механизм реализован через POSIX SHM. Разработчики Андроида сочли его недостаточно защищённым, что могло сыграть на руку вредоносному ПО. Особенностями ashmem-а являются счётчик ссылок, при обнулении которого разделяемая память может быть освобождена (например, память освобождается при завершении всех процессов, использующих её), и сокращение разделяемого региона при нехватке памяти в системе.

Ярким примером использования ashmem-а является процесс zygote, в котором загружается стартовая версия Dalvik VM с загруженными базовыми классами и ресурсами, а остальные приложения просто ссылаются на эту память.

Binder имеет ограничение на размер транзакции в 1МБ (иначе будет выброшено исключение TransactionTooLargeException). Если нам надо передать из одного процесса в другой большой объём данных, можно как раз воспользоваться Ashmem-ом: создать MemoryFile и передать дескриптор файла в другой процесс.

Обычные дистрибутивы, как правило, используют две системы логирования: лог ядра, доступный через команду dmesg, и системные логи, располагающиеся обычно в директории /var/log.

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

На диаграмме представлена общая система логирования Андроида. Драйвер логирования предоставляет доступ к каждому буферу через /dev/log/*. Приложения имеют доступ к ним не напрямую, а через библиотеку liblog. С библиотекой liblog общаются классы Log, Slog и EventLog. Команда adb logcat показывает содержимое буфера “main”.

В данной заметке мы кратко рассмотрели некоторые особенности Андроида как Линукс-системы. За скобками остались некоторые другие части (pmem, RAM console и т.д.), а также такие важные аспекты платформы в целом, как System Service, процесс запуска системы и другие. Если данная тема будет интересна, в следующих статьях мы рассмотрим и их.

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

Перепрошивка ядра Андроид-устройства

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

Ядро операционной системы Андроид и его прошивка

Что представляет собой ядро мобильного устройства?

Ядро операционной системы является основой программного обеспечения, которое управляет аппаратной частью устройства. От него зависят основные параметры любого гаджета. Следует заметить, что операционная система Андроид состоит из трёх взаимосвязанных компонентов — ядра Linux, вертикальной машины Dalvik и разных низкоуровневых сервисов и библиотек. Если речь идёт о кастомной прошивке, то затрагиваются только два компонента, которые позволяют добавлять новые системные сервисы, оптимизировать существующие параметры и изменять графическую оболочку.

Желающие установить ядро на Андроид должны понимать, что существует различие между понятиями кастомное ядро и кастомная прошивка. Последняя является неофициальной версией программного обеспечения. Кастомная прошивка разработана командой специалистов под конкретные устройства. Кастомное ядро основывается на ядре Linux, представляя собой его неофициальную версию. Часто кастомное ядро идёт в комплекте с прошивкой. Но его можно установить отдельно после смены прошивки. По сути, оно не заменяет родное ядро мобильного устройства, что является конечной целью такой операции.

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

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

Прошивка гаджета через Fastboot

Перепрошить устройство Андроид можно через Fastboot. Но для начала следует установить утилиту на ваш гаджет. Существует две версии такой программы. Первая предусматривает скачивание Fastboot в комплексе с официальной программой Android SDK. Вторая версия предполагает загрузку утилиты отдельно.

Мы рекомендуем проверить, видит ли ваше мобильное устройство ноутбук либо компьютер. Для этого необходимо выполнить подключение через USB. После загрузки и установки на компьютер, ноутбук, работающий на операционной системе Windows, утилиты Fastboot и подключения смартфона необходимо открыть командную строку. Для этого откройте Поиск. В Windows 8 для этого достаточно направить курсор мыши в правую часть экрана и выбрать соответствующий раздел. В Поиске необходимо ввести «cmd», после чего перед вами появится командная строка. Устройство следует перевести в режим прошивки. Далее следует ввести команду, которая протестируют взаимодействие компьютера и мобильного устройства:

Если все работает, необходимо загрузить правильную версию прошивки ядра boot.img. Мы не рекомендуем перепрошивать ядро оригинальных прошивок, поскольку это может привести к проблемам в работе смартфона. Файл следует сохранить в заранее созданный раздел на диске C под названием «Android». После этого необходимо загрузить мобильное устройство в Fastboot и подсоединить к компьютеру. На экране появится сообщение «Fastboot USB».

Далее на компьютере необходимо открыть командную строку и ввести следующие коды:

• cd C:\Android.
• fastboot flash boot boot.img.
• fastboot erase cache.
• fastboot reboot.

Очень важно правильно вводить все слова с учётом регистра и пробелов. Команда cd открывает необходимую папку, в которой содержатся требуемые файлы. После этого происходит перепрошивка. Команда fastboot erase cache удаляет раздел Кэш. Последняя команда — fastboot reboot перезагружает устройство из режима прошивки в обычный. Если все указанные действия вы произвели правильно, то процесс пройдёт успешно.

Прошивка с помощью ClockworkMod Recovery

ClockworkMod Recovery (либо сокращённо CWM) — это система восстановления, которая используется вместо заводского оригинального Recovery. CWM позволяет установить новую прошивку на мобильное устройство, прошить ядро, сделать резервную копию файлов и восстановить оболочку. Такая система умеет работать с файлами обновления прошивок, имеющих zip-формат. ClockworkMod устанавливается во внутреннюю память устройства, заменяя собой заводское Recovery. Чтобы запустить CWM, необходимо знать комбинацию клавиш, которая подходит для вашего гаджета. В большинстве случаев это комбинация кнопок уменьшения звука и включения питания, которые следует нажать во время загрузки устройства.

Для прошивки ядра следует скачать архив с расширением zip. В нём обязательно должна находиться папка META-INF. Далее существует два варианта. В первом случае нужно указать файл прошивки. Второй вариант предполагает помещение файла прошивки в папку /sdcard. После этого следует активировать ClockworkMod Recovery, найти там функцию Apply update from sdcard и указать необходимый файл.

Следует отметить, что меню ClockworkMod Recovery является удобным и понятным для большинства пользователей. Кроме такой системы восстановления для прошивки, можно использовать TWRP Recovery. Этот инструмент является удобным и популярным среди пользователей Андроид. Главное — выбрать правильный файл прошивки.

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