Список статей
Здесь собраны ссылки на мои статьи из этой темы:- Основы безопасности операционной системы Android. Уровень ядра
- Основы безопасности операционной системы Android. Native user space, ч.1
- Основы безопасности операционной системы Android. Native user space, ч.2
- Основы безопасности операционной системы Android. Безопасность на уровне Application Framework. Binder IPC
Что подразумевается под Native user space
Под Native user space подразумеваются все компоненты пространства пользователя, которые выполняются вне Dalvik Virtual Machine, и которые не являются частью Linux kernel.Файловая система Android
Для начала давайте рассмотрим структуру файловой системы Android. Хотя Android и базируется на Linux kernel, привычную нашему глазу структуру файловой системы мы здесь не увидим. Давайте запустим эмулятор и посмотрим, что у нас есть. Для этого выполним комманду:Adb shell ls -al
В моем терминале для эмулятора на Android 4.2 я вижу следующий результат:
Drwxr-xr-x root root 2013-04-10 08:13 acct
drwxrwx--- system cache 2013-04-10 08:13 cache
dr-x------ root root 2013-04-10 08:13 config
lrwxrwxrwx root root 2013-04-10 08:13 d -> /sys/kernel/debug
drwxrwx--x system system 2013-04-10 08:14 data
-rw-r--r-- root root 116 1970-01-01 00:00 default.prop
drwxr-xr-x root root 2013-04-10 08:13 dev
lrwxrwxrwx root root 2013-04-10 08:13 etc -> /system/etc
-rwxr-x--- root root 244536 1970-01-01 00:00 init
-rwxr-x--- root root 2487 1970-01-01 00:00 init.goldfish.rc
-rwxr-x--- root root 18247 1970-01-01 00:00 init.rc
-rwxr-x--- root root 1795 1970-01-01 00:00 init.trace.rc
-rwxr-x--- root root 3915 1970-01-01 00:00 init.usb.rc
drwxrwxr-x root system 2013-04-10 08:13 mnt
dr-xr-xr-x root root 2013-04-10 08:13 proc
drwx------ root root 2012-11-15 05:31 root
drwxr-x--- root root 1970-01-01 00:00 sbin
lrwxrwxrwx root root 2013-04-10 08:13 sdcard -> /mnt/sdcard
d---r-x--- root sdcard_r 2013-04-10 08:13 storage
drwxr-xr-x root root 2013-04-10 08:13 sys
drwxr-xr-x root root 2012-12-31 03:20 system
-rw-r--r-- root root 272 1970-01-01 00:00 ueventd.goldfish.rc
-rw-r--r-- root root 4024 1970-01-01 00:00 ueventd.rc
lrwxrwxrwx root root 2013-04-10 08:13 vendor -> /system/vendor
Я отмечу здесь только главные директории и те, которые нам пригодятся в будущем. В Интернете можно найти описание и предназаначение других директорий. Можно заметить, что некоторые директории такие же, как и в Linux, например, /dev
, /proc
, /sys
, /mnt
, /etc
И их предназначение в основном такое же, как и в Linux. Кстати, отметьте, что мы не видим /bin
и /lib
директорий. Где они скрылись, я расскажу чуть позже.
C другой стороны можно заметить директории, которых в Linux вообще нет. Среди них нас интересуют /data
, /system
, /cache
, /init
, /init.rc
Давайте рассмотрим их назначение поподробнее.
/system
Это главная директория, где хранятся неизменяемые компоненты Android системы. Если проводить аналогию, то эта папка похожа на папку C:\windows\
, доступную только для чтения. Т.е. изменять данные в этой директории мы не можем. Как раз здесь можно найти директории /bin
и /lib
, где хранятся различные исполняемые файлы и shared libraries. Кроме того, здесь же лежат системные приложения, которые встроены в операционку и которые, по умолчанию, нельзя удалить. Содержимое этой директории формируется во время компиляции операционной системы.
/data
Т.к. /system
у нас доступна только для чтения, то должна быть директория где хранятся изменяемые данные. /data
как раз ею и является. Например, в эту директорию в /data/app
сохраняются apk файлы устанавливаемых приложений, а в /data/data
хранятся их данные (эту директорию мы подробно рассматривали в прошлой статье).
/cache
Это просто временное хранилище. Также в эту директорию сохраняются, а потом из неё запускаются системные обновления.
Чтобы понять, что такое /init файл и для чего нужны непонятные файлы с расширением *.rc, рассмотрим процесс загрузки системы.
Процесс загрузки Android
Давайте рассмотрим несколько шагов процесса загрузки операционной системы Android. Эта картинка взята из книги «Embedded Android», там же можно найти и более детальное описание. Хотя в целом я и понимаю процесс, но для меня это больше магия:)
CPU.
Когда вы нажимаете на кнопку включения, на процессор вашего устройства начинает подаваться напряжение. Так как до этого момента процессор был выключен, и так как он не способен сохранять свое состояние без подачи напряжения, то сразу после старта он находится в некотором неинициализированном состоянии. В данном случае процессор считывает из своего специального регистра некоторый жестко зашитый адрес и начинает выполнять инструкции начиная с него. Чаще всего, этот адрес указывает на чип, в который зашит bootloader (загрузчик).
Bootloader.
Bootloader инициализирует RAM и загружает в неё Linux kernel. Кроме того Bootloader создает RAMdisk.
Linux kernel.
Ядро инициализирует различные подсистемы, встроенные драйвера и монтирует root filesystem (корневую файловую систему). После этого ядро может запускать первую программу.
На этом магия заканчивается и дальше всё становится более-менее понятно.
Init
Первой программой в случае Android является init . Исполняемый файл находится в корневой директории (/init ). Именно эту программу стартует ядро после своей загрузки. Её исходники находятся в папке Давайте в них слегка покопаемся. Нас интересует :Int main(int argc, char **argv)
{
...
/* clear the umask */
umask(0);
/* Get the basic filesystem setup we need put
* together in the initramdisk on / and then we will
* let the rc file figure out the rest.
*/
mkdir("/dev", 0755);
mkdir("/proc", 0755);
mkdir("/sys", 0755);
mount("tmpfs", "/dev", "tmpfs", MS_NOSUID, "mode=0755");
mkdir("/dev/pts", 0755);
mkdir("/dev/socket", 0755);
mount("devpts", "/dev/pts", "devpts", 0, NULL);
mount("proc", "/proc", "proc", 0, NULL);
mount("sysfs", "/sys", "sysfs", 0, NULL);
...
init_parse_config_file("/init.rc");
...
}
Вначале мы создаем и монтируем некоторые необходимые для работы директории, а потом парсим файл /init.rc
и выполняем то, что распарсили. Формат /init.rc
файла очень хорошо описан в , там же можно найти и пример. Если кратко, то этот файл представляет собой набор actions (секций - именнованная последовательность комманд). Каждая последовательность команд срабатывает по определенному trigger (триггеру). Например, следующая последовательно - это action, в которой trigger - это fs, а последовательность команд - это набор mount команд:
Исходный файл /init.rc
находится в Давайте рассмотрим некоторые основные его части, хотя я вам очень советую просмотреть его полность. После этого многие вещи вам должны стать понятны. Итак, начинается наш файл следующими строками:
Import /init.usb.rc
import /init.${ro.hardware}.rc
import /init.trace.rc
Они означают, что кроме init.rc
файла нужно также импортировать настройки из файлов init.usb.rc
, init.trace.rc
и из файла с непонятным именем init.${ro.hardware}.rc
Впрочем, ${ro.hardware}
- это просто переменная, значение которая определяет тип железа. В случае эмулятора, её значение, например, - goldfish
. Далее определяются переменные окружения:
On init
...
# setup the global environment
export PATH /sbin:/vendor/bin:/system/sbin:/system/bin:/system/xbin
export LD_LIBRARY_PATH /vendor/lib:/system/lib
export ANDROID_BOOTLOGO 1
export ANDROID_ROOT /system
export ANDROID_ASSETS /system/app
export ANDROID_DATA /data
export ANDROID_STORAGE /storage
export ASEC_MOUNTPOINT /mnt/asec
export LOOP_MOUNTPOINT /mnt/obb
export BOOTCLASSPATH /system/framework/core.jar:/system/framework/okhttp.jar:/system/framework/core-junit.jar:/system/framework/bouncycastle.jar:/system/framework/ext.jar:/system/framework/framework.jar:/system/framework/telephony-common.jar:/system/framework/mms-common.jar:/system/framework/android.policy.jar:/system/framework/services.jar:/system/framework/apache-xml.jar
...
После этого происходит инициализация переменных, необходимых для работы устройства. Если вас заинтересует эта тема, то вы легко найдете информацию о той или иной комманде. Давайте подробно рассмотрим следующий блок (который я уже приводил в этой статье):
On fs
# mount mtd partitions
# Mount /system rw first to give the filesystem a chance to save a checkpoint
mount yaffs2 mtd@system /system
mount yaffs2 mtd@system /system ro remount
mount yaffs2 mtd@userdata /data nosuid nodev
mount yaffs2 mtd@cache /cache nosuid nodev
MTD - Memory Technology Devices. Если в общих чертах, то MTD - это специальный чип с энергонезависимой (т.е. данные на этом чипе сохраняются после перезагрузки или выключения) flash-памятью (типа NOR или NAND), на который сохраняются образы дисков. В этой статье более подробно рассказывается об этом типе устройств, а также об ограничениях. Специально для этих разновидностей flash-памяти были разработаны специальные файловые системы, например, YAFFS. Одно из самых важных ограничений этих типов памяти заключается в том, что для того чтобы записать данные в сектор, куда уже записаны какие-то данные, вам надо полностью сначала стереть весь сектор. Поэтому производители стали переходить на новый тип блочной flash-памяти (eMMC), на которые можно поставить обычную ext4 файловую систему и избавиться от указанного ограничения. Т.к. я показываю пример init.rc
файла для эмулятора, где вся работа эмулируется, то в нем по умолчанию используется файловая система YAFFS2 (думаю, что это пережитки прошлого, т.к. YAFFS2 использовалась для всех устройств до Android 2.2). В реальном устройстве (это как раз один из примеров, когда необходимо использовать init.rc
файл для определенного железа) эти комманды будут перезаписаны. Например, в случае устройства herring
(Google Nexus S), в файле эта секция выглядит следующим образом:
On fs
mkdir /efs 0775 radio radio
mount yaffs2 mtd@efs /efs noatime nosuid nodev
chmod 770 /efs/bluetooth
chmod 770 /efs/imei
mount_all /fstab.herring
...
Где fstab.herring
- это , содержимое которого выглядит следующим образом:
...
/dev/block/platform/s3c-sdhci.0/by-name/system /system ext4 ro wait
/dev/block/platform/s3c-sdhci.0/by-name/userdata /data ext4 noatime,nosuid,nodev,nomblk_io_submit,errors=panic wait,encryptable=/efs/userdata_footer
Как вы могли заметить, /system
, /data
, /cache
- это просто mounting points (точки монтирования файловой системы), которые указывают либо на MTD устройства (в случае эмулятора), либо на блочные устройства (в случае настоящего устройства), куда записаны соответствующие дисковые образы (system.img, userdata.img и cache.img). Я не уверен, но думаю, что внутри смартфона находится один единственный чип с flash-памятью, разделенный на partitions (тома), в каждый из которых записан соответствующий образ. Этот чип с flash-памятью - то, что мы знаем под именем Internal storage
(внутренняя память), объем которой - один из основных параметров смартфона.
Следует заметить, что /system смонтирован read-only (только для чтения). Это означает, что содержимое данного раздела не изменяется в процессе работы устройства, а только когда вы, например, обновляете систему на вашем устройстве (используя системные обновления).
Продолжим рассматривать наш init.rc . По триггеру post-fs-data формируется базовая структура файловой системы /data раздела. Там, в общем всё понятно - набор mkdir , chown , chmod команд.
Далее init.rc запускает несколько демонов. Если вернуться к рисунку в начале статьи, то они перечислены в блоке Native daemons. На этом мы пока остановимся. Как вы могли заметить из рисунка, я не полностью рассмотрел процесс загрузки операционной системы. Некоторые непокрытые этапы я рассмотрю в следующих статья.
Заключение
В следующей части я расскажу, откуда берутся образы system.img, userdata.img и cache.img и рассмотрю безопасность на уровне Native user space. Как всегда приветствуются исправления, дополнения, а так же предложения, о чем написать. И хотя у меня уже есть некоторый план, о чем писать в следующих статья, я готов его подкорректировать.В этой серии статей я расскажу о внутреннем устройстве 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-метода.
Как работает Android
Узнать о скрытых возможностях программных систем можно, поняв принцип их работы. В некоторых случаях сделать это затруднительно, так как код системы может быть закрыт, но в случае Android мы можем изучить всю систему вдоль и поперек. В этой статье я не буду рассказывать обо всех нюансах работы Android и остановлюсь только на том, как происходит запуск ОС и какие события имеют место быть в промежутке между нажатием кнопки питания и появлением рабочего стола.
Попутно я буду пояснять, что мы можем изменить в этой цепочке событий и как разработчики кастомных прошивок используют эти возможности для реализации таких вещей, как тюнинг параметров ОС, расширение пространства для хранения приложений, подключение swap, различных кастомизаций и многого другого. Всю эту информацию можно использовать для создания собственных прошивок и реализации различных хаков и модификаций.
Шаг первый. U-BOOT и таблица разделов
Все начинается с первичного загрузчика. После включения питания система исполняет код загрузчика, записанного в постоянную память устройства. Чаще всего его роль выполняет модифицированная версия загрузчика u-boot со встроенной поддержкой протокола fastboot, но производитель мобильного чипа или смартфона/планшета имеет право выбрать и любой другой загрузчик на его вкус. Например, компания Rockchip использует собственный, несовместимый с fastboot загрузчик, и для его перепрограммирования и управления им приходится использовать проприетарные инструменты.
Протокол fastboot, в свою очередь, представляет собой систему управления загрузчиком с ПК, которая позволяет выполнять такие действия, как разлочка загрузчика, прошивка нового ядра и recovery, установка прошивки и многие другие. Смысл существования fastboot в том, чтобы иметь возможность восстановить смартфон в начальное состояние в ситуации, когда все остальные средства не работают. Fastboot останется на месте, даже если в результате экспериментов ты сотрешь со смартфона все содержимое всех разделов NAND-памяти, потеряв доступ и к Android, и к recovery.
Получив управление, u-boot проверяет таблицу разделов и передает управление ядру, прошитому в раздел с именем boot, после чего ядро извлекает в память RAM-образ из того же раздела и начинает загрузку либо Android, либо консоли восстановления. NAND-память в Android-устройствах поделена на шесть условно обязательных разделов:
- boot - содержит ядро и RAM-диск, обычно имеет размер в районе 16 Мб;
- recovery - консоль восстановления, состоит из ядра, набора консольных приложений и файла настроек, размер 16 Мб;
- system - содержит Android, в современных девайсах имеет размер не менее 1 Гб;
- cache - предназначен для хранения кешированных данных, также используется для сохранения прошивки в ходе OTA-обновления и поэтому имеет размер, сходный с размерами раздела system;
- userdata - содержит настройки, приложения и данные пользователя, ему отводится все оставшееся пространство NAND-памяти;
- misc - содержит флаг, определяющий, в каком режиме должна грузиться система: Android или recovery.
В терминологии Linux RAM-диск - это своего рода виртуальный жесткий диск, существующий только в оперативной памяти. На раннем этапе загрузки ядро извлекает содержимое диска из образа и подключает его как корневую файловую систему (rootfs).
Кроме них, также могут существовать и другие разделы, однако общая разметка определяется еще на этапе проектирования смартфона и в случае u-boot зашивается в код загрузчика. Это значит, что: 1) таблицу разделов нельзя убить, так как ее всегда можно восстановить с помощью команды fastboot oem format; 2) для изменения таблицы разделов придется разлочить и перепрошить загрузчик с новыми параметрами. Из этого правила, однако, бывают исключения. Например, загрузчик того же Rockchip хранит информацию о разделах в первом блоке NAND-памяти, так что для ее изменения перепрошивка загрузчика не нужна.
Особенно интересен раздел misc. Существует предположение, что изначально он был создан для хранения различных настроек независимо от основной системы, но в данный момент используется только для одной цели: указать загрузчику, из какого раздела нужно грузить систему - boot или recovery. Эту возможность, в частности, использует приложение ROM Manager для автоматической перезагрузки системы в recovery с автоматической же установкой прошивки. На ее же основе построен механизм двойной загрузки Ubuntu Touch, которая прошивает загрузчик Ubuntu
в recovery и позволяет управлять тем, какую систему грузить в следующий раз. Стер раздел misc - загружается Android, заполнил данными - загружается recovery... то есть Ubuntu Touch.
Часть кода загрузчика, определяющая таблицу разделов:
static struct partition partitions = {
{ "-", 123 },
{ "xloader", 128 },
{ "bootloader", 256 },
/* "misc" partition is required for recovery */
{ "misc", 128 },
{ "-", 384},
{ "efs", 16384 },
{ "recovery", 8*1024 },
{ "boot", 8*1024 },
{ "system", 512*1024 },
{ "cache", 256*1024 },
{ "userdata", 0 },
{ 0, 0 }
};
Шаг второй. Раздел boot
Если в разделе misc не стоит флаг загрузки в recovery, u-boot передает управление коду, расположенному в разделе boot. Это не что иное, как ядро Linux; оно находится в начале раздела, а сразу за ним следует упакованный с помощью архиваторов cpio и gzip образ RAM-диска, содержащий необходимые для работы Android каталоги, систему инициализации init и другие инструменты. Никакой файловой системы на разделе boot нет, ядро и RAM-диск просто следуют друг за другом. Содержимое RAM-диска такое:
- data - каталог для монтирования одноименного раздела;
- dev - файлы устройств;
- proc - сюда монтируется procfs;
- sbin - набор подсобных утилит и демонов (adbd, например);
- res - набор изображений для charger (см. ниже);
- 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-команд.
В процессе загрузки Android отображает три разных загрузочных экрана: первый появляется сразу после нажатия кнопки питания и прошит в ядро Linux, второй отображается на ранних этапах инициализации и записан в файл /initlogo.rle (сегодня почти не используется), последний запускается с помощью приложения bootanimation и содержится в файле /system/media/bootanimation.zip.
Каталог proc для Linux стандартен, на следующих этапах загрузки init подключит к нему procfs, виртуальную файловую систему, которая предоставляет доступ к информации обо всех процессах системы. К каталогу sys система подключит sysfs, открывающую доступ к информации о железе и его настройкам. С помощью sysfs можно, например, отправить устройство в сон или изменить используемый алгоритм энергосбережения.
Файл build.prop предназначен для хранения низкоуровневых настроек Android. Позже система обнулит эти настройки и перезапишет их значениями из недоступного пока файла system/build.prop.
Шаг второй, альтернативный. Раздел recovery
В том случае, если флаг загрузки recovery в разделе misc установлен или пользователь включил смартфон с зажатой клавишей уменьшения громкости, u-boot передаст управление коду, расположенному в начале раздела recovery. Как и раздел boot, он содержит ядро и RAM-диск, который распаковывается в память и становится корнем файловой системы. Однако содержимое RAM-диска здесь несколько другое.
В отличие от раздела boot, выступающего в роли переходного звена между разными этапами загрузки ОС, раздел recovery полностью самодостаточен и содержит миниатюрную операционную систему, которая никак не связана с Android. У recovery свое ядро, свой набор приложений (команд) и свой интерфейс, позволяющий пользователю активировать служебные функции.
В стандартном (стоковом) recovery таких функций обычно всего три: установка подписанных ключом производителя смартфона прошивок, вайп и перезагрузка. В модифицированных сторонних recovery, таких как ClockworkMod и TWRP, функций гораздо больше. Они умеют форматировать файловые системы, устанавливать прошивки, подписанные любыми ключами (читай: кастомные), монтировать файловые системы на других разделах (в целях отладки ОС) и включают в себя поддержку скриптов, которая позволяет автоматизировать процесс прошивки и многие другие функции.
С помощью скриптов, например, можно сделать так, чтобы после загрузки recovery автоматически нашел на карте памяти нужные прошивки, установил их и перезагрузился в Android. Эта возможность используется инструментами ROM Manager, autoflasher, а также механизмом автоматического обновления CyanogenMod и других прошивок.
Кастомные рекавери также поддерживают скрипты бэкапа, располагающиеся в каталоге /system/addon.d/. Перед прошивкой recovery проверяет наличие скриптов и выполняет их перед тем, как произвести прошивку. Благодаря таким скриптам gapps не исчезают после установки новой версии прошивки.
Шаг третий. Инициализация
Итак, получив управление, ядро подключает RAM-диск и по окончании инициализации всех своих подсистем и драйверов запускает процесс init, с которого начинается инициализация Android. Как я уже говорил, у init есть конфигурационный файл init.rc, из которого процесс узнает о том, что конкретно он должен сделать, чтобы поднять систему. В современных смартфонах этот конфиг имеет внушительную длину в несколько сот строк и к тому же снабжен прицепом из нескольких дочерних конфигов, которые подключаются к основному с помощью директивы import. Тем не менее его формат достаточно простой и по сути представляет собой набор команд, разделенных на блоки.
Каждый блок определяет стадию загрузки или, выражаясь языком разработчиков Android, действие. Блоки отделены друг от друга директивой on, за которой следует имя действия, например on early-init или on post-fs. Блок команд будет выполнен только в том случае, если сработает одноименный триггер. По мере загрузки init будет по очереди активировать триггеры early-init, init, early-fs, fs, post-fs, early-boot и boot, запуская таким образом соответствующие блоки команд.
Если конфигурационный файл тянет за собой еще несколько конфигов, перечисленных в начале (а это почти всегда так), то одноименные блоки команд внутри них будут объединены с основным конфигом, так что при срабатывании триггера init выполнит команды из соответствующих блоков всех файлов. Это сделано для удобства формирования конфигурационных файлов для нескольких устройств, когда основной конфиг содержит общие для всех девайсов команды, а специфичные для каждого устройства записываются в отдельные файлы.
Наиболее примечательный из дополнительных конфигов носит имя initrc.имя_ устройства.rc где имя переменной определяется автоматически на основе содержимого файла ro.hardware. Это платформенно-зависимый конфигурационный файл, который содержит блоки команд, специфичные для конкретного устройства. Кроме команд, отвечающих за тюнинг ядра, он также содержит примерно такую команду:
mount_all ./fstab.имя_устройства
Она означает, что теперь init должен подключить все файловые системы, перечисленные в файле./fstab.имя_устройства, который имеет следующую структуру:
Имя_устройства_(раздела) точка_монтирования файловая_система опции_фс прочие опции
Обычно в нем содержатся инструкции по подключению файловых систем из внутренних NAND-разделов к каталогам /system (ОС), /data (настройки приложений) и /cache (кешированные данные). Однако, слегка изменив этот файл, мы можем заставить init загрузить систему с карты памяти. Для этого достаточно разбить карту памяти на три-четыре раздела: 1 Гб / ext4, 2 Гб / ext4, 1 Гб / ext4 и оставшееся пространство fat32. Далее необходимо определить имена разделов карты памяти в каталоге /dev (для разных устройств они отличаются) и заменить ими оригинальные имена устройств в файле fstab.
В конце блока boot init, скорее всего, встретит команду class_start default, которая сообщит, что далее следует запустить все перечисленные в конфиге службы, имеющие отношение к классу default. Описание служб начинается с директивы service, за которой следует имя службы и команда, которая должна быть выполнена для ее запуска. В отличие от команд, перечисленных в блоках, службы должны работать все время, поэтому на протяжении всей жизни смартфона init будет висеть в фоне и следить за этим.
Современный Android включает в себя десятки служб, но две из них имеют особый статус и определяют весь жизненный цикл системы.
Шаг четвёртый. Zygote и App_process
На определенном этапе загрузки init встретит в конце конфига примерно такой блок:
service zygote /system/bin/app_process -Xzygote /system/bin --zygote --start-system-server class default socket zygote stream 660 root system onrestart write /sys/android_power/request_state wake onrestart write /sys/power/state on onrestart restart media onrestart restart netd
Это описание службы Zygote, ключевого компонента любой Android-системы, который ответственен за инициализацию, старт системных служб, запуск и остановку пользовательских приложений и многие другие задачи. Zygote запускается с помощью небольшого приложения /system/bin/app_process, что очень хорошо видно на приведенном выше куске конфи-га. Задача app_proccess - запустить виртуальную машину Dalvik, код которой располагается в разделяемой библиотеке /system/lib/libandroid_runtime.so, а затем поверх нее запустить Zygote.
Когда все это будет сделано и Zygote получит управление, он начинает формирование среды исполнения Java-приложений с помощью загрузки всех Java-классов фреймворка (сейчас их более 2000). Затем он запускает system_server, включающий в себя большинство высокоуровневых (написанных на Java) системных сервисов, в том числе Window Manager, Status Bar, Package Manager и, что самое важное, Activity Manager, который в будущем будет ответственен за получение сигналов о старте и завершении приложений.
После этого Zygote открывает сокет /dev/socket/zygote и уходит в сон, ожидая данные. В это время запущенный ранее Activity Manager посылает широковещательный интент Intent.CATEGORY_HOME, чтобы найти приложение, отвечающее за формирование рабочего стола, и отдает его имя Zygote через сокет. Последний, в свою очередь, форкается и запускает приложение поверх виртуальной машины. Вуаля, у нас на экране появляется рабочий стол, найденный Activity Manager и запущенный Zygote, и статусная строка, запущенная system_server в рамках службы Status Bar. После тапа по иконке рабочий стол пошлет интент с именем этого приложения, его примет Activity Manager и передаст команду на старт приложения демону Zygote.
Все это может выглядеть несколько непонятно, но самое главное - запомнить три простые вещи:
Во многом Android сильно отличается от других ОС, и с наскоку в нем не разобраться. Однако, если понять, как все работает, открываются просто безграничные возможности. В отличие от iOS и Windows Phone, операционка от гугла имеет очень гибкую архитектуру, которая позволяет серьезно менять ее поведение без необходимости писать код. В большинстве случаев достаточно подправить нужные конфиги и скрипты.
][ 05.14
Предположим, что вам повезло и Дед Мороз положил под елку новомодный гаджет. Большой популярностью в последнее время пользуются смартфоны, букридеры и планшеты на Раскрыть потенциал такого подарка поможет начинающим владельцам "умных" устройств гид Вестей.Хайтек.
Что это? Android — это программа, при помощи которой вы управляете своим устройством. Ее история началась в 2005 году, когда Google купила одноименную компанию-разработчика и начала развивать платформу. В сентябре 2008-го была выпущена первая стабильная версия Android — 1.0 (под кодовым названием Apple Pie). За последующие четыре года вышло 14 "изданий" ОС. Релиз самой последней на сегодняшней день версии — 4.1/4.2 (Jelly Bean) — состоялся в июне 2012-го.
Android, которая получает поддержку от крупнейшей в мире поисковой системы, быстро стала самой популярной мобильной ОС в мире. Ее успеху во многом способствовала открытость исходного кода и политика Google, которая разрешает производителям бесплатно устанавливать Android на свою продукцию. "Робота" предпочитают такие крупные компании, как HTC, Samsung, Sony и Motorola.
— Если нужно срочно пополнить баланс телефона или Интернета, оплатить услуги ЖКХ, купить билет или просто перевести деньги. К вашим услугам — десятки приложений от крупных платежных систем и банков. В Google Play, например, есть "Яндекс.Деньги", Webmoney, QIWI, "Альфа-Банк", "Русский Стандарт", "ТКС Банк" или Home Credit Bank.
— Сориентироваться на местности или построить маршрут для поездки на автомобиле помогут
Читайте какими бывают устройства Android. Операционная система Андроид, разработкой которой с лета 2005 года занимается компания Google, за очень короткий срок стала одной из самых популярных на мировом рынке, подвинув многих конкурентов. Зеленый робот, ставший лицом ОС, узнаваем пользователями и, что немаловажно, любим. Система добилась невероятных успехов, став основой для устройств самого разного назначения. Но какие конкретно устройства работают на ? Мы задались целью составить материал, в котором постараемся раскрыть ответ на этот вопрос.
Чем так хороша ОС Android
На рынке мобильных операционных систем сегодня главенствует, как многим известно, всего два представителя – iOS и Android. Этим двум противоборствующим ОС удалось попросту вытеснить всех остальных игроков, которым приходится довольствоваться ничтожным процентом.
И вот уже около десяти лет не утихают споры о том, что же лучше – или Android. В пользу первой говорит проработанность и стабильность – все для людей. Однако система является закрытой, а используется только в продукции компании Apple. Android же располагает к себе открытостью с возможностью кастомизации, а также обилием самых разных устройств – система доступна любой компании.
В открытости и распространенности и заключаются преимущества Андроид. Систему в своих целях используют и производители смартфонов, планшетов, умных часов, и автоконцерны. Кроме того, продукция, выпускаемая на Android, как правило, дешевле конкурентов на других операционных системах.
Устройства Android: где только не используется система
Ну что ж, теперь непосредственно к устройствам на Android. Их огромное число, потому мы затронем самые распространенные.
Смартфоны и Android
Первым устройством, которому выпала честь опробовать на себе преимущества Андроид, стал, конечно же, смартфон. Случилось это не так уж и давно – осень 2008 года. Всего-то девять лет назад был выпущен первый девайс на этой системе! Первым смартфоном был HTC Dream, который имел выдвижную клавиатуру и простецкие характеристики, которые не идут ни в какое сравнение с нынешними флагманами.
Смартфон был построен на базе чипа Qualcomm MSM7201A – одно ядро и частота 528 МГц. Эту «мощь» дополнили 192 Мб оперативной и 256 Мб постоянной памяти, благо можно было установить карту памяти на 16 Гб. 3.2-дюймовый экран получил разрешение 320×480 точек. И, как ни крути, для того времени это был настоящий прорыв.
После HTC Dream потенциал Андроид рассмотрели многие компании, открыв новую эру мобильных ОС. В Россию первый смартфон на Android приехал только в 2009 году, и стал им ни какой-нибудь там Samsung или LG, а HIGHSCREEN PP5420. И аппарат выглядит интересно даже сейчас.
Он обзавелся двумя экранами (дополнительный OLED ), процессором Qualcomm MSM7201A, ОЗУ 128 МБ, ПЗУ 256 МБ.
Однако операционная система тогда считалась выбором гиков, а большинству пользователей было комфортно с мобильными телефонами от Nokia. Прыжок выше головы Android сделала, когда обновилась до версии 2.3 (2011 год). Десятки компаний стали выбирать эту систему, да и пользователи рассмотрели потенциал.
Что имеем сегодня? Все крупнейшие производители (сами знаете за исключением кого) используют в своих смартфонах Android, добавляя что-то свое в код системы, дабы сделать ее лучше. Каждый год система обновляется, получая приставку в названии. С выходом новых версий пополняется арсенал возможностей Android. И нет никаких предпосылок, чтобы рынок смартфонов отказался от системы в ближайшие годы.
Планшеты
Планшет Одним из первых представителей планшетов на Android стал Samsung Galaxy Tab, который попал на полки магазинов в 2010 году. Корейская компания выпускала устройство, чтобы навязать конкуренцию iPad, который уже тогда был готов стать лидером продаж.
До Samsung уже были попытки выпустить планшет на Андроид, но они либо просто не увенчались успехом, либо прошли незамеченными. Первый Galaxy Tab работал на версии 2.2, которая была явно не лучшим выбором для подобного класса гаджетов – она просто не была приспособлена в то время для планшетов, что не скрывала и Google. Хотя Samsung и постаралась ее доработать.
Расцвет планшетов начался после выхода Android версии 3.0, которая была разработана специально для этих устройств. Полки магазинов мгновенно наполнились дешевыми китайскими планшетами, которые привлекали пользователя своей ценой. Следующие версии Андроид стали универсальными, что позволило использовать систему и на смартфонах, и на планшетах.
Сегодня Android-планшеты переживают не лучшие времена – новинки выходят редко, пользователи отдают предпочтение фаблетам, к тому же, серьезную конкуренцию навязывают iPad и модели на Windows.
Телевизоры, Mini PC, игровые приставки и TV Box на Android
Вслед за смартфонами, планшетами и некоторыми другими устройствами Андроид проник и в мультимедийные устройства. Еще летом 2012 года Nexus представила медиа-развлекательное устройство Q, которое подключалось к телевизору и воспроизводило различный контент. Работал гаджет на Android 4.0. Позже, в 2014 году, Google показала – ответвление, которое предназначалось для приставок и телевизоров. Android TV перенял всю функциональность основной системы, став более адаптированным к управлению пультом ДУ.
За широкие возможности ОС особенно приглянулась многим производителям , которые, подключаясь к телевизору, превращают его в некое подобие большого смартфона. Очень любимы эти устройства китайскими компаниями, выпускающими ТВ Боксы по 2000-3000 рублей. На Android TV выпускаются и некоторые модели телевизоров, но большинство крупных компаний имеет свои системы , от которых не желает отказываться.
Кроме того, с выходом Android 4.4 в интернет-магазинах появилось немало Mini PC на этой системе – небольшие устройства (часто в виде флешки), которые, по сути, представляют собой все те же TV Box. Главное их достоинство – компактность, позволяющая носить в кармане.
Многим пользователям интересна Android и как игровая система. Компании же стараются потворствовать желаниям покупателей. Уже сегодня на прилавках магазинов электроники можно найти игровую приставку на Android от , а также кучу портативных моделей от китайских компаний.
Android с каждым годом только усиливает позиции на рынках развлекательных мультимедийных устройств. Функциональности системы сегодня достаточно для комфортного просмотра онлайн-контента, запуска тысяч игр и многих других целей.
Носимая электроника и техника для дома
Относительно недавно новым трендом стала умная носимая электроника, в числе которой оказались . На волне популярности Android выпустила в 2014 году свою систему для умных часов – . Как и полноценную ОС, ее постарались сделать наиболее удобной и функциональной. Сегодня на Android Wear доступны часы от таких крупных брендов как Samsung, LG, Huawei, Sony и других.
Не обошла система от Google стороной и технику для дома, которая год от года становится умнее. Уже в 2009 году пользователи могли приобрести рамку для фотографий на Android, позже к тренду присоединилась бытовая техника, в частности холодильники. Производители встраивают в свои устройства сенсорные панели, с помощь которых можно производить настройку работы холодильника, заказывать еду, управлять удаленно, задействовав планшет или смартфон.
Интересные приборы для кухни с операционной системой Андроид «на борту» представляют почти на каждой выставке. Кроме того, падает постепенно и цена на подобные устройства, что способствует их быстрому распространению.
Ноутбуки, камеры, проекторы, электронные книги
Есть ноутбуки, работающие на Android. Их относительно немного, но Google сегодня готова приложить все усилия, чтобы их продукт навязал конкуренцию системе уже десктопной – Windows. Кроме того, каждый пользователь может опробовать Андроид на своем компьютере или ноутбуке, причем совершенно бесплатно.
Однако пока ноутбуки на Андроид особым успехом не пользуются – все же для работы со многим программами на голову выше . Возможно, только пока.
А вот проекторы на Android выглядят поинтереснее. Сегодня многие компании выпускают портативные модели, которые оснащаются Android TV, что позволяет насладиться любимым шоу или сериалом в любом месте: хоть дома на диване, хоть в лесу под елью. Но, опять же, это больше нишевые устройства, которые не имеют такого спроса как смартфоны или смарт часы.
Любителям чтения сегодня доступны электронные книги на Android. Они существенно функциональнее своих братьев, на которых можно лишь открыть скачанный заранее роман или повесть. Подобные модели и в Интернете позволяют посидеть, и фильм посмотреть, ну и, конечно же, насладиться чтением.
Устройства для автомобилей
Фото: Андроид-магнитола Shuttle SDVA-6950 v2 Автомобили сегодня так же распространены, как и смартфоны, так почему бы и их не наградить современной операционной системой. Крупные холдинги оснащают новые модели бортовыми компьютерами, которые полностью отслеживают состояние авто, готовы помочь водителю с маршрутом и развлекут в длинной пробке фильмом.
Кроме того, на рынке полным-полно различных устройств на Андроид, которые может позволить каждый. Это, естественно, позволяющие загрузить тысячи карт, куда же без магнитолы, которая не только будет воспроизводить музыку, но и видео из YouTube в длинной пробке покажет. Дополнить этот тандем готовы видеорегистраторы, которые с помощью Android обладают существенно большими возможностями.
Заключение
Список устройств, работающих на операционной системе Google, действительно впечатляет. По факту, ни одна другая система не способна похвастаться столь широким распространением. И ведь сферы применения Android только расширяются. Общедоступность и функциональность делают свое дело – система растет впечатляющими темпами, оставляя позади конкурентов. Может вы, уважаемые читатели, тоже знаете какие-нибудь экзотические устройства на Android?
