Андроид для чайников - что это за система

Тебя никогда не интересовало, как работают fastboot или ADB? Или почему смартфон под управлением Android практически невозможно превратить в кирпич? Или, может быть, ты давно хотел узнать, где кроется магия фреймворка Xposed и зачем нужны загрузочные скрипты /system/etc/init.d? А как насчет консоли восстановления (recovery)? Это часть Android или вещь в себе и почему для установки сторонней прошивки обычный рекавери не подходит? Ответы на все эти и многие другие вопросы ты найдешь в данной статье.

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

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

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

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

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

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

Получив управление, aboot проверяет таблицу разделов и передает управление ядру, прошитому в раздел с именем boot, после чего ядро извлекает в память RAM-образ из того же раздела и начинает загрузку либо Android, либо консоли восстановления. NAND-память в Android-устройствах поделена на шесть условно обязательных разделов:

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

Кроме них, также могут существовать и другие разделы, однако общая разметка определяется еще на этапе проектирования смартфона и в случае aboot зашивается в код загрузчика. Это значит, что: 1) таблицу разделов нельзя убить, так как ее всегда можно восстановить с помощью команды fastboot oem format; 2) для изменения таблицы разделов придется разлочить и перепрошить загрузчик с новыми параметрами. Из этого правила, однако, бывают исключения. Например, загрузчик того же Rockchip хранит информацию о разделах в первом блоке NAND-памяти, так что для ее изменения перепрошивка загрузчика не нужна.

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

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

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

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

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

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

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

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

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

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

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

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

Шаг второй, альтернативный. Раздел 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 не исчезают после установки новой версии прошивки.

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

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

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

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

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

Предположим, что вам повезло и Дед Мороз положил под елку новомодный гаджет. Большой популярностью в последнее время пользуются смартфоны, букридеры и планшеты на Раскрыть потенциал такого подарка поможет начинающим владельцам "умных" устройств гид Вестей.Хайтек.

Что это? 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.

— Сориентироваться на местности или построить маршрут для поездки на автомобиле помогут

В этой статье я попробую рассмотреть безопасность чуть-чуть повыше ядра, а именно: как работает безопасность в Native user space. Мы коснемся темы процесса загрузки операционной системы и рассмотрим структуру файловой системы Android. Как я уже говорил, я не очень силен в Linux, поэтому если заметите неточности, то исправляйте - меня научите и статью улучшите. Так как эта тема довольно обширная, я решил разбить её на две части. В первой части мы рассмотрим процесс загрузки операционной системы и особенности файловой системы. Всем кому интересно, добро пожаловать!

Список статей

Здесь собраны ссылки на мои статьи из этой темы:

Основы безопасности операционной системы 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

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

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

в 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.

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

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

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

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

С помощью скриптов, например, можно сделать так, чтобы после загрузки recovery автоматически нашел на карте памяти нужные прошивки, установил их и перезагрузился в Android. Эта возможность используется инструментами ROM Manager, autoflasher, а также механизмом автоматического обновления CyanogenMod и других прошивок.

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

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

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

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

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

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

Шаг четвёртый. 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.

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

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

][ 05.14

Разве это не здорово, когда научная фантастика становится научным фактом? Наверняка вы помните о крутом устройстве связи, которым обладал капитан Кирк из Стартрека, и я уверен, что вы даже желали быть обладателем этого чуда. Напомню, капитан Кирк и экипаж под названием «Энтерпрайз» могли общаться на расстоянии с помощью этих устройств персональной связи.
Теперь, когда мы живём в эпоху электроники и всего умного, в 21 веке, наши «коммуникаторы» кладут на лопатки устройства из Стартрека. Мы не только можем говорить друг с другом посредством нынешних смартфонов, но и читать сообщения, слушать музыкальный контент, играть в крутые трёхмерные игры, работать с документами, фотографировать, проверять электронную почту, находить рестораны, работать в Интернете, смотреть кино - всё это в одном устройстве. Залезешь под кат - узнаешь всё самое интересное!

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

Вот список некоторых возможностей, которыми сможет ежедневно пользоваться человек, обладающим смартфоном:

Управление персональной информацией, включая заметки, календарь и списки дел
Передача медиаконтента посредством беспроводных интерфейсов Wi-Fi, Bluetooth, NFC
Связь с ноутбуком и персональными компьютерами
Синхронизация данных с приложениями
Многофункциональные приложения: статистика работы процессорных ядер, подробный прогноз погоды, чтение актуальных новостей, переводчики, электронная почта, мессенджеры, видеоигры наконец
Сканирование документов, QR-кодов и штрих-кодов
Замена кошелька. Смартфон может хранить информацию о кредитных картах
Оплата счетов и услуг. Такие приложения, как WebMoney, PayPal или CardStar помогут вам
Создание сети Wi-Fi, которую смогут использовать одновременно несколько устройств. Это означает, что вы можете получить доступ ко всемирной паутине с планшета iPad или ноутбука без использования маршрутизатора или другого периферийного устройства

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

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

Сегодня каждый человек имеет смартфон, ну или по крайней мере мечтает о нём. На самом же деле, по оценкам насчиталось порядка 1.4 миллиарда используемых смартфонов в мире по состоянию на декабрь 2013 года. Люди постоянно используют их во многих сферах жизнедеятельности: звонки, фотографии, серфинг в Интернете и множество других вещей, включая покупки автомобилей - капитан Кирк будет ревновать.

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

Смартфоны используют сетевую технологию для отправки и получения данных (телефонные звонки, просмотр веб-страниц, передача файлов). Разработчики классифицируют эту технологию в поколениях. Вы помните первое поколение? Она включала в себя аналоговые технологии мобильного телефона. Однако, как сотовые технологии прогрессировали, протоколы стали более совершенными. В 2014 году сотовые телефоны находятся в мире четвёртого поколения сетей или 4G. В настоящее время многие производители оснащают смартфоны поддержкой сетей четвёртого поколения, но есть и такие компании, как Samsung, например, которые разрабатывают пятое поколение, то есть 5G, которая, если недавние испытания верны, позволит вам скачать весь фильм менее чем за секунду.

Аппаратное и программное обеспечения

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

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

Ядро - система управления процессами и драйверами аппаратных средств
Промежуточное программное обеспечение - библиотеки программного обеспечения, которые позволяют смартфону обзаводиться приложениями (безопасность, веб-браузер, передача сообщений)
Среда исполнения приложений (Application Execution Environment, AEE) - интерфейсы прикладного программирования, которые позволяют разработчикам создавать свои собственные программы
Структура пользовательского интерфейса (Framework UI) - графика и макеты, отображаемые на экране
Пакет приложений - основные приложения для доступа к повседневным задачам, будь то открытие меню, календарь, сообщения, почтовый ящик, калькулятор и другие

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

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

Android . Предназначена в первую очередь для сенсорных мобильных устройств. Разработана компанией Google, изначально была создана компанией Android Inc. Большинство людей считают операционную систему Android революционной технологией, потому что она имеет открытый исходный код и позволяет писать людям программные коды и приложения, что означает зелёный робот постоянно развивается. Операционная система Android может работать сразу с несколькими приложениями - это многозадачность. В настоящее время магазин приложений, используемый в Android и называемый Google Play, насчитывает более миллиона различных приложений.

iOS . Компания Apple, как снова же многие считают, всегда была революционной и создавала соответствующие продукты - простые и логичные. Рекламируемая производителем как самая передовая мобильная операционная система, iOS поддерживает большое количество функций. По состоянию на момент публикации данной статьи, iOS 7 способна автоматически обновлять приложения и обзавелась подобным главному конкуренту в лице зелёного робота центром управления, который даёт пользователям доступ к наиболее часто используемым функциям. Плоский, минималистичный и яркий дизайн новой версии операционной системы от Apple многие обругали, но свыклись.

Windows Phone . Рецензенты говорят, что данная операционная система так же проста в плане использования, как и Android. Её главным достижением являются живые тайлы, которые запрограммированы как плитки разных размеров. С помощью них пользователь может легко получать доступ к нужной и актуальной информации. Windows Phone 8 хорошо работает в связке с другими продуктами Microsoft, в том числе и такие приложения, как Office и Exchange. Для тех, кто много звонит, постоянно зависает в социальных сетях и использует текстовые сообщения, детище софтверного тек-гиганта из Редмонда удовлетворит данные потребности.

Ubuntu Touch . На первый взгляд, по мнению экспертов, Ubuntu Touch может показаться обычной операционной системой, но это не так. Эксперты говорят, что Ubuntu Touch - одна из самых простых операционных систем для использования. Она не использует аппаратные кнопки навигации, потому как основана на жестах подобно другому продукту - Sailfish OS. Разработанная компанией Canonical, Ubuntu Touch позволяет пользователям разблокировать смартфон простым жестом. Вы можете провести пальцев вниз от верхнего края, чтобы получить доступ к основной информации - дате, времени, сообщениям (из различных приложений: Skype и Facebook) и беспроводным сетям. Кроме того, обладатели смартфонов под управлением данной ОС смогут без проблем обмениваться фотографиями. Каждая сделанная фотография автоматически загружается в личное облако, что делает её доступной на всех устройствах, в том числе и под управлением iOS, Android и Windows Phone.

Гибкие интерфейсы

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

Bluetooth
Эта функция, использующая беспроводные сети, обеспечивает обмен информацией между различными мобильными устройствами. Главная задача синего зуба - передача данных без помощи проводов и обеспечение экономичной и дешёвой радиосвязи. Среди поддерживающих данную технологию устройств стоит отметить следующие: принтеры, сканеры, устройства ввода, компьютеры и гарнитуры. Некоторые версии Bluetooth позволяют только связать одно устройство за раз, а другие способны связать одновременно несколько устройств. Чтобы узнать больше, ознакомьтесь с соответствующей из колонки «Как это работает».

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

Open Mobile Alliance (OMA) является совместной организацией с одной миссией. Они сформировали рабочую группу синхронизации данных, которая продолжает свою работу, начатую в рамках инициативы SyncML. SyncML - проект на открытых стандартах, направленный на ликвидацию неприятностей и заботясь о том, чтобы пользовательская информация и данные синхронизировались между собой и наоборот. Проект разработан таким образом, чтобы любой вид данных мог быть синхронизирован с любым применением аппаратных средств через любую сеть, при условии, что они все запрограммированы по стандартам OMA. Это включает в себя синхронизацию веб, Bluetooth, а также почтовых протоколов и TCP/IP сетей.

SyncML позволяет синхронизировать данные с телефона на устройство под управлением операционных систем Windows, Mac, Linux с помощью Bluetooth, инфракрасного порта (ИК-порт, IrDA), HTTP или с помощью кабеля USB. Если желаете получить дополнительную информацию, вам стоит посетить веб-сайт Open Mobile Alliance.

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

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

Будущее смартфонов

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

Пожалуй, самым сложным фактором для будущего является обеспечение безопасности. Смартфоны могут быть уязвимы к нарушениям безопасности. Например, атака под названием Evil Twin (Злой Близнец), в процессе которой хакер устанавливает сервисный идентификатор сервиса, создавая легитимную точку доступа или сеть и одновременно блокируя трафик на реальном сервере. Когда пользователь подключается к серверу хакера, информация может быть попросту перехвачена и безопасность данных будет находится под угрозой. С другой же стороны, некоторые критики утверждают, что производители антивирусного программного обеспечения значительно преувеличивают риски, вред и объём телефонных вирусов, чтобы помочь таким образом самим же себе в продаже фирменных продуктов.

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