- Запускаю на Android игры c Symbian и N-Gage через бесплатный эмулятор. Ностальгия 👾
- Содержание
- Установка и настройка эмулятора
- Установка и запуск игр
- Впечатления от игры
- How to install user apps as Android system apps
- Warning
- Requirements
- Installing a System App with ES File Explorer
- Installing a System App via ADB
- Познавательно-практический экскурс в архитектуру Android
- Содержание статьи
- Как работает Android
- Шаг первый. ABOOT и таблица разделов
- Хакер #184. Современный фронтенд
- Шаг второй. Раздел boot
- Выносы из текста
- Шаг второй, альтернативный. Раздел recovery
- Команды fastboot
- Шаг третий. Инициализация
- Команды init.rc
- Шаг четвертый. Zygote и app_process
- Выводы
- Евгений Зобнин
Запускаю на Android игры c Symbian и N-Gage через бесплатный эмулятор. Ностальгия 👾
Совсем недавно в Google Play Store вышел эмулятор с названием EKA2L1. Он написан на C++ и умеет запускать приложения и игры, созданные под платформы Symbian OS и N-Gage. Я опробовал его и делюсь в этой статье впечатлениями и инструкцией, как запустить игры прошлого на своём Android-смартфоне.
Содержание
Установка и настройка эмулятора
После загрузки приложения EKA2L1 из Google Play Store, необходимо установить образ системы. Для этого нужно найти прошивку в интернете. Мною были без труда найдены и опробованы образы систем следующих устройств:
- Nokia 5320
- Nokia 5800
- Nokia N-Gage
- Nokia N95
- Nokia E5-00
- Nokia 5530
Рекомендую в первую очередь пробовать эмулируемый девайс из этого списка и только потом тестировать другие.
Если образ системы загружен в ZIP-архиве, его нужно распаковать. Большинство прошивок состоит из двух файлов с расширениями .RPKG и .ROM.
Для установки подобных ОС достаточно в меню EKA2L1 выбрать пункт Devices, сменить метод установки на RPKG, в поле RPKG указать путь к файлу с соответствующим расширением, в поле ROM — файл с расширением ROM. После выбора файлов нажать Install — процесс установки занимает пару минут.
Прошивка Nokia N-Gage выглядит и устанавливается немного иначе. Внутри папки Data находятся папки drives и roms с подпапками. В приложении EKA2L1 нажимаем Devices, но методом установки выбираем Raw Dump. В первом поле Raw Dump выбираем путь к папке Data/drives/z/rh-4. Обращу внимание, что название последней папки может отличаться в зависимости от образа прошивки N-Gage. Так, мне встретились варианты NEM-4 и RH-29. Выберите ту папку, которая находится в вашей прошивке.
Во втором поле выбираем папку Data/roms/rh-4. Здесь точно так же последняя папка может слегка отличаться названием, выбирайте ту, которая есть у вас.
Готово, нажимаем Install и ждём пару минут, пока не появится всплывающее уведомление, сообщающее об успешной установке. Сменить текущее устройство можно всё в том же меню Devices.
Установка и запуск игр
Для установки игр N-Gage необходимо проделать следующую последовательность действий:
- найти и загрузить архив с нужной игрой;
- распаковать архив;
- содержимое папки apps поместить по пути EKA2L1/data/drives/е/apps/;
- если присутствует папка libs, то поместить её содержимое по пути EKA2L1/data/drives/е/Libs/;
- если папки libs нет с игрой, тогда придётся найти в Сети и загрузить набор библиотек для игр.
Установка Symbian-игр выглядит иначе.
- Загружаем .sis- или .sisx-файл игры.
- Заходим в EKA2L1 и нажимаем на кнопку с иконкой плюса.
- Находим загруженный файл и выбираем его.
После добавления игра должна появиться в списке всех приложений в эмуляторе.
Впечатления от игры
Я протестировал игры как для Symbian, так и для N-Gage. Игры для платформы N-Gage запустились без каких-либо проблем. Rayman 3, Sega Rally, Tom Clancy’s Splinter Cell: Team Stealth Action — все они идут без подлагиваний и багов. Управление происходит при помощи наэкранных кнопок — не самый удобный вариант, но привыкнуть можно, к тому же они не перекрывают изображение.
С играми для Symbian всё несколько сложнее. Иногда экранная клавиатура перекрывает часть изображения — сами кнопки полупрозрачные, но вот при нажатии на них важный контент может перекрываться пальцами. Впрочем, это лишь малая часть проблем. Куда сложнее запустить что-либо, так как некоторые игры совместимы только с конкретной версией ОС и подобрать нужную конфигурацию непросто. Кроме того, при установке любой программы регулярно вылетает сам эмулятор.
Тем не менее, я смог поиграть в Asphalt 2, Bounce Touch, Carmageddon и Prince Of Persia HD. Игры идут отлично, без вылетов и тормозов — проблема, повторюсь, только в подборке нужной версии.
Такой способ запуска вполне удобен и не доставляет дискомфорта. Но вот процесс поиска и установки игр может отнять немало времени и убить всякое желание играть.
Источник
How to install user apps as Android system apps
Part of the benefits of having an Android device is being able to install an app on it. Installing is as simple as one, two, three; just search for your desired app on the Google Play Store and hit the Install button. Though installing apps is easy, they can be installed as either user apps or system apps.
User apps are installed in the typical way via the Google Play Store, Amazon Appstore, third-party markets, or sideloading. In contrast, system apps are apps pre-installed in the phone’s system partition with your ROM and typically, Android device users don’t have the access to the system partition. This means that, ordinarily, users cannot directly install apps to or uninstall from the system partition.
You can install user apps as system apps by using such apps as Titanium Backup, but you have to go for the paid version of the app to be able to enjoy such feature. However, there are other methods to install user apps as system apps without paying fees. Check out this guide for methods of installing ordinary user apps as system apps.
Warning
- The information in this guide is provided for instructional and educational purposes only. There is no guarantee that these instructions will work under your specific and unique circumstances.
- Use these instructions at your own risk. We shall not hold any responsibility or liability for whatever happens to you or your device arising from your use of the info in this guide.
- Read and understand the whole guide first before actually performing the instructions.
Requirements
- A rooted Android device. If you haven’t rooted your Android device yet, you can check out our list of the rooting methods we’ve covered.
- Enable USB debugging on your Android device. On most Android devices, you can find USB Debugging in Settings > Applications > Development.
- Backup all personal data on your phone to make sure you have a copy of your personal data (e.g., contacts, SMS, MMS, Internet settings, Wi-Fi passwords, and the like) in case the procedure in this guide erases such data.
-
- For backup tips, check our guides on how to sync your data to the cloud and how to create local backups of your mobile data.
- Maintain a battery charge of 70% or more to make sure that you have sufficient power for the entire procedure.
Installing a System App with ES File Explorer
For this method, you will need root access and the ES File Explorer app. You can download this app free from the Google Play Store.
- Configure ES File Explorer by doing the following steps:
- Launch ES File Explorer.
- Select Menu and choose Settings.
- Under Settings, enable the options for Up to root and Root Explorer. A message will appear, requiring you to confirm your action. You will also need to confirm Superuser access.
- Enable Mount File System.
- Go back to the app’s main menu.
- Get a copy of the APK (Android Package) of the app that you want to save as a system file by doing the following steps (skip to step 3 if you already have the app’s APK file):
- Install an app from the Google Play Store. For this guide, we will be using the app BioRhythms as an example.
- Launch ES File Explorer and navigate to /data/app.
- Locate the APK file that you want to install as a system app. If you don’t know the APK’s filename, simply go to the Google Play Store link of your chosen app. View the link and take note of the words after “?id=”. This will be your APK’s filename. For instance, the BioRhythms app link is https://play.google.com/store/apps/details?id=app.biorhythms. The BioRhythms’ APK is app.biorhythms-1.apk.
- Create a backup of the chosen APK by copying it to the phone’s SD Card.
- After creating a backup, long tap on the APK file and a menu will appear. Choose Cut. A blue arrow will appear at the bottom of the screen.
- Go back to the main menu and navigate to /system/app/.
- Drag the little arrow at the bottom of the screen. It will bring up the icon of the APK file.
- Tap the APK file and it will be transferred to /system/app/.
- Find the APK file in /system/app/. Press and hold it and a menu will appear.
- Select Properties on the menu. The dialog properties will show up.
- Tap Change and it will show the permissions dialog box.
- Check the boxes for the following permissions in the dialog box:
- User: Read and Write
- Group: Read
- Other: Read
- Select OK once the required settings have been made.
- Reboot your device.
You app is now saved as a system app.
Installing a System App via ADB
For this method, make sure that you have installed ADB (Android Debug Bridge) on your computer. You can get ADB by setting up the Android Software Development Kit (SDK) on your computer.
Источник
Познавательно-практический экскурс в архитектуру Android
Содержание статьи
Тебя никогда не интересовало, как работают fastboot или ADB? Или почему смартфон под управлением Android практически невозможно превратить в кирпич? Или, может быть, ты давно хотел узнать, где кроется магия фреймворка Xposed и зачем нужны загрузочные скрипты /system/etc/init.d? А как насчет консоли восстановления (recovery)? Это часть Android или вещь в себе и почему для установки сторонней прошивки обычный рекавери не подходит? Ответы на все эти и многие другие вопросы ты найдешь в данной статье.
Как работает Android
Узнать о скрытых возможностях программных систем можно, поняв принцип их работы. В некоторых случаях сделать это затруднительно, так как код системы может быть закрыт, но в случае Android мы можем изучить всю систему вдоль и поперек. В этой статье я не буду рассказывать обо всех нюансах работы Android и остановлюсь только на том, как происходит запуск ОС и какие события имеют место быть в промежутке между нажатием кнопки питания и появлением рабочего стола.
Попутно я буду пояснять, что мы можем изменить в этой цепочке событий и как разработчики кастомных прошивок используют эти возможности для реализации таких вещей, как тюнинг параметров ОС, расширение пространства для хранения приложений, подключение swap, различных кастомизаций и многого другого. Всю эту информацию можно использовать для создания собственных прошивок и реализации различных хаков и модификаций.
Шаг первый. ABOOT и таблица разделов
Все начинается с первичного загрузчика. После включения питания система исполняет код загрузчика, записанного в постоянную память устройства. Затем он передает управление загрузчику aboot со встроенной поддержкой протокола fastboot, но производитель мобильного чипа или смартфона/планшета имеет право выбрать и любой другой загрузчик на его вкус. Например, компания Rockchip использует собственный, несовместимый с fastboot загрузчик, для перепрограммирования и управления которым приходится использовать проприетарные инструменты.
Протокол fastboot, в свою очередь, представляет собой систему управления загрузчиком с ПК, которая позволяет выполнять такие действия, как разлочка загрузчика, прошивка нового ядра и recovery, установка прошивки и многие другие. Смысл существования fastboot в том, чтобы иметь возможность восстановить смартфон в начальное состояние в ситуации, когда все остальные средства не работают. Fastboot останется на месте, даже если в результате экспериментов ты сотрешь со смартфона все разделы NAND-памяти, содержащие Android и recovery.
Получив управление, aboot проверяет таблицу разделов и передает управление ядру, прошитому в раздел с именем boot, после чего ядро извлекает в память RAM-образ из того же раздела и начинает загрузку либо Android, либо консоли восстановления. NAND-память в Android-устройствах поделена на шесть условно обязательных разделов:
- boot — содержит ядро и RAM-диск, обычно имеет размер в районе 16 Мб;
- recovery — консоль восстановления, состоит из ядра, набора консольных приложений и файла настроек, размер 16 Мб;
- system — содержит Android, в современных девайсах имеет размер не менее 1 Гб;
- cache — предназначен для хранения кешированных данных, также используется для сохранения прошивки в ходе OTA-обновления и поэтому имеет размер, сходный с размерами раздела system;
- userdata — содержит настройки, приложения и данные пользователя, ему отводится все оставшееся пространство NAND-памяти;
- misc — содержит флаг, определяющий, в каком режиме должна грузиться система: Android или recovery.
Кроме них, также могут существовать и другие разделы, однако общая разметка определяется еще на этапе проектирования смартфона и в случае aboot зашивается в код загрузчика. Это значит, что: 1) таблицу разделов нельзя убить, так как ее всегда можно восстановить с помощью команды fastboot oem format; 2) для изменения таблицы разделов придется разлочить и перепрошить загрузчик с новыми параметрами. Из этого правила, однако, бывают исключения. Например, загрузчик того же Rockchip хранит информацию о разделах в первом блоке NAND-памяти, так что для ее изменения перепрошивка загрузчика не нужна.
Часть кода загрузчика, определяющая таблицу разделов
Хакер #184. Современный фронтенд
Особенно интересен раздел misc. Существует предположение, что изначально он был создан для хранения различных настроек независимо от основной системы, но в данный момент используется только для одной цели: указать загрузчику, из какого раздела нужно грузить систему — boot или recovery. Эту возможность, в частности, использует приложение ROM Manager для автоматической перезагрузки системы в recovery с автоматической же установкой прошивки. На ее же основе построен механизм двойной загрузки Ubuntu Touch, которая прошивает загрузчик Ubuntu в recovery и позволяет управлять тем, какую систему грузить в следующий раз. Стер раздел misc — загружается Android, заполнил данными — загружается recovery. то есть Ubuntu Touch.
Шаг второй. Раздел boot
Если в разделе misc не стоит флаг загрузки в recovery, aboot передает управление коду, расположенному в разделе boot. Это не что иное, как ядро Linux; оно находится в начале раздела, а сразу за ним следует упакованный с помощью архиваторов cpio и gzip образ RAM-диска, содержащий необходимые для работы Android каталоги, систему инициализации init и другие инструменты. Никакой файловой системы на разделе boot нет, ядро и RAM-диск просто следуют друг за другом. Содержимое RAM-диска такое:
- data — каталог для монтирования одноименного раздела;
- dev — файлы устройств;
- proc — сюда монтируется procfs;
- res — набор изображений для charger (см. ниже);
- sbin — набор подсобных утилит и демонов (adbd, например);
- sys — сюда монтируется sysfs;
- system — каталог для монтирования системного раздела;
- charger — приложение для отображения процесса зарядки;
- build.prop — системные настройки;
- init — система инициализации;
- init.rc — настройки системы инициализации;
- ueventd.rc — настройки демона uventd, входящего в состав init.
Это, если можно так выразиться, скелет системы: набор каталогов для подключения файловых систем из разделов NAND-памяти и система инициализации, которая займется всей остальной работой по загрузке системы. Центральный элемент здесь — приложение init и его конфиг init.rc, о которых во всех подробностях я расскажу позже. А пока хочу обратить внимание на файлы charger и ueventd.rc, а также каталоги sbin, proc и sys.
Файл charger — это небольшое приложение, единственная задача которого — вывести на экран значок батареи. Он не имеет никакого отношения к Android и используется тогда, когда устройство подключается к заряднику в выключенном состоянии. В этом случае загрузки Android не происходит, а система просто загружает ядро, подключает RAM-диск и запускает charger. Последний выводит на экран иконку батареи, изображение которой во всех возможных состояниях хранится в обычных PNG-файлах внутри каталога res.
Файл ueventd.rc представляет собой конфиг, определяющий, какие файлы устройств в каталоге sys должны быть созданы на этапе загрузки системы. В основанных на ядре Linux системах доступ к железу осуществляется через специальные файлы внутри каталога dev, а за их создание в Android отвечает демон ueventd, являющийся частью init. В нормальной ситуации он работает в автоматическом режиме, принимая команды на создание файлов от ядра, но некоторые файлы необходимо создавать самостоятельно. Они перечислены в ueventd.rc.
Каталог sbin в стоковом Android обычно не содержит ничего, кроме adbd, то есть демона ADB, который отвечает за отладку системы с ПК. Он запускается на раннем этапе загрузки ОС и позволяет выявить возможные проблемы на этапе инициализации ОС. В кастомных прошивках в этом каталоге можно найти кучу других файлов, например mke2fs, которая может потребоваться, если разделы необходимо переформатировать в ext3/4. Также модеры часто помещают туда BusyBox, с помощью которого можно вызвать сотни Linux-команд.
Каталог proc для Linux стандартен, на следующих этапах загрузки init подключит к нему procfs, виртуальную файловую систему, которая предоставляет доступ к информации обо всех процессах системы. К каталогу sys система подключит sysfs, открывающую доступ к информации о железе и его настройкам. С помощью sysfs можно, например, отправить устройство в сон или изменить используемый алгоритм энергосбережения.
Файл build.prop предназначен для хранения низкоуровневых настроек Android. Позже система обнулит эти настройки и перезапишет их значениями из недоступного пока файла system/build.prop.
Корневой раздел ТВ-приставки OUYA
Выносы из текста
- Fastboot останется на месте, даже если в результате экспериментов ты сотрешь со смартфона содержимое всех разделов NAND-памяти
- Раздел recovery полностью самодостаточен и содержит миниатюрную операционную систему, которая никак не связана с Android
- Слегка изменив файл fstab, мы можем заставить init загрузить систему с карты памяти
Шаг второй, альтернативный. Раздел recovery
В том случае, если флаг загрузки recovery в разделе misc установлен или пользователь включил смартфон с зажатой клавишей уменьшения громкости, aboot передаст управление коду, расположенному в начале раздела recovery. Как и раздел boot, он содержит ядро и RAM-диск, который распаковывается в память и становится корнем файловой системы. Однако содержимое RAM-диска здесь несколько другое.
В отличие от раздела boot, выступающего в роли переходного звена между разными этапами загрузки ОС, раздел recovery полностью самодостаточен и содержит миниатюрную операционную систему, которая никак не связана с Android. У recovery свое ядро, свой набор приложений (команд) и свой интерфейс, позволяющий пользователю активировать служебные функции.
В стандартном (стоковом) recovery таких функций обычно всего три: установка подписанных ключом производителя смартфона прошивок, вайп и перезагрузка. В модифицированных сторонних recovery, таких как ClockworkMod и TWRP, функций гораздо больше. Они умеют форматировать файловые системы, устанавливать прошивки, подписанные любыми ключами (читай: кастомные), монтировать файловые системы на других разделах (в целях отладки ОС) и включают в себя поддержку скриптов, которая позволяет автоматизировать процесс прошивки и многие другие функции.
С помощью скриптов, например, можно сделать так, чтобы после загрузки recovery автоматически нашел на карте памяти нужные прошивки, установил их и перезагрузился в Android. Эта возможность используется инструментами ROM Manager, auto-flasher, а также механизмом автоматического обновления CyanogenMod и других прошивок.
Кастомные рекавери также поддерживают скрипты бэкапа, располагающиеся в каталоге /system/addon.d/. Перед прошивкой recovery проверяет наличие скриптов и выполняет их перед тем, как произвести прошивку. Благодаря таким скриптам gapps не исчезают после установки новой версии прошивки.
Команды fastboot
Чтобы получить доступ к fastboot, необходимо установить Android SDK, подключить смартфон к ПК с помощью кабеля и включить его, зажав обе кнопки громкости. После этого следует перейти в подкаталог platform-tools внутри SDK и запустить команду
На экран будет выведено имя устройства. Другие доступные команды:
- fatsboot oem unlock — разлочка загрузчика на нексусах;
- update файл.zip — установка прошивки;
- flash boot boot.img — прошивка образа boot-раздела;
- flash recovery recovery.img — прошивка образа раздела recovery;
- flash system system.img — прошивка образа системы;
- boot recovery.img — загрузка образа recovery без прошивки;
- oem format — восстановление разрушенной таблицы разделов;
- reboot — перезагрузка.
Шаг третий. Инициализация
Итак, получив управление, ядро подключает RAM-диск и по окончании инициализации всех своих подсистем и драйверов запускает процесс init, с которого начинается инициализация Android. Как я уже говорил, у init есть конфигурационный файл init.rc, из которого процесс узнает о том, что конкретно он должен сделать, чтобы поднять систему. В современных смартфонах этот конфиг имеет внушительную длину в несколько сот строк и к тому же снабжен прицепом из нескольких дочерних конфигов, которые подключаются к основному с помощью директивы import. Тем не менее его формат достаточно простой и по сути представляет собой набор команд, разделенных на блоки.
Каждый блок определяет стадию загрузки или, выражаясь языком разработчиков Android, действие. Блоки отделены друг от друга директивой on, за которой следует имя действия, например on early-init или on post-fs. Блок команд будет выполнен только в том случае, если сработает одноименный триггер. По мере загрузки init будет по очереди активировать триггеры early-init, init, early-fs, fs, post-fs, early-boot и boot, запуская таким образом соответствующие блоки команд.
Часть конфига init.rc из CyanogenMod
Если конфигурационный файл тянет за собой еще несколько конфигов, перечисленных в начале (а это почти всегда так), то одноименные блоки команд внутри них будут объединены с основным конфигом, так что при срабатывании триггера init выполнит команды из соответствующих блоков всех файлов. Это сделано для удобства формирования конфигурационных файлов для нескольких устройств, когда основной конфиг содержит общие для всех девайсов команды, а специфичные для каждого устройства записываются в отдельные файлы.
Наиболее примечательный из дополнительных конфигов носит имя initrc.имя_устройства.rc, где имя устройства определяется автоматически на основе содержимого системной переменной ro.hardware. Это платформенно-зависимый конфигурационный файл, который содержит блоки команд, специфичные для конкретного устройства. Кроме команд, отвечающих за тюнинг ядра, он также содержит примерно такую команду:
Она означает, что теперь init должен подключить все файловые системы, перечисленные в файле ./fstab.имя_устройства, который имеет следующую структуру:
Обычно в нем содержатся инструкции по подключению файловых систем из внутренних NAND-разделов к каталогам /system (ОС), /data (настройки приложений) и /cache (кешированные данные). Однако слегка изменив этот файл, мы можем заставить init загрузить систему с карты памяти. Для этого достаточно разбить карту памяти на три 4 раздела: 1 Гб / ext4, 2 Гб / ext4, 1 Гб / ext4 и оставшееся пространство fat32. Далее необходимо определить имена разделов карты памяти в каталоге /dev (для разных устройств они отличаются) и заменить ими оригинальные имена устройств в файле fstab.
Типичное содержимое файла fstab
В конце блока boot init, скорее всего, встретит команду class_start default, которая сообщит, что далее следует запустить все перечисленные в конфиге службы, имеющие отношение к классу default. Описание служб начинается с директивы service, за которой следует имя службы и команда, которая должна быть выполнена для ее запуска. В отличие от команд, перечисленных в блоках, службы должны работать все время, поэтому на протяжении всей жизни смартфона init будет висеть в фоне и следить за этим.
Современный Android включает в себя десятки служб, но две из них имеют особый статус и определяют весь жизненный цикл системы.
Команды init.rc
Процесс init имеет встроенный набор команд, многие из которых повторяют стандартный набор команд Linux. Наиболее примечательные из них:
- exec /путь/до/команды — запустить внешнюю команду;
- ifup интерфейс — поднять сетевой интерфейс;
- class_start имя_класса — запустить службы, относящиеся к указанному классу;
- class_stop имя_класса — остановить службы;
- insmod /путь/до/модуля — загрузить модуль ядра;
- mount ФС устройство каталог — подключить файловую систему;
- setprop имя значение — установить системную переменную;
- start имя_службы — запустить указанную службу;
- trigger имя — включить триггер (выполнить указанный блок команд);
- write /путь/до/файла строка — записать строку в файл.
Шаг четвертый. Zygote и app_process
На определенном этапе загрузки init встретит в конце конфига примерно такой блок:
Это описание службы Zygote, ключевого компонента любой Android-системы, который ответственен за инициализацию, старт системных служб, запуск и остановку пользовательских приложений и многие другие задачи. Zygote запускается с помощью небольшого приложения /system/bin/app_process, что очень хорошо видно на приведенном выше куске конфига. Задача app_proccess — запустить виртуальную машину Dalvik, код которой располагается в разделяемой библиотеке /system/lib/libandroid_runtime.so, а затем поверх нее запустить Zygote.
Когда все это будет сделано и Zygote получит управление, он начинает формирование среды исполнения Java-приложений с помощью загрузки всех Java-классов фреймворка (сейчас их более 2000). Затем он запускает system_server, включающий в себя большинство высокоуровневых (написанных на Java) системных сервисов, в том числе Window Manager, Status Bar, Package Manager и, что самое важное, Activity Manager, который в будущем будет ответственен за получение сигналов о старте и завершении приложений.
После этого Zygote открывает сокет /dev/socket/zygote и уходит в сон, ожидая данные. В это время запущенный ранее Activity Manager посылает широковещательный интент Intent.CATEGORY_HOME, чтобы найти приложение, отвечающее за формирование рабочего стола, и отдает его имя Zygote через сокет. Последний, в свою очередь, форкается и запускает приложение поверх виртуальной машины. Вуаля, у нас на экране появляется рабочий стол, найденный Activity Manager и запущенный Zygote, и статусная строка, запущенная system_server в рамках службы Status Bar. После тапа по иконке рабочий стол пошлет интент с именем этого приложения, его примет Activity Manager и передаст команду на старт приложения демону Zygote
В терминологии Linux RAM-диск — это своего рода виртуальный жесткий диск, существующий только в оперативной памяти. На раннем этапе загрузки ядро извлекает содержимое диска из образа и подключает его как корневую файловую систему (rootfs).
В процессе загрузки Android отображает три разных загрузочных экрана: первый появляется сразу после нажатия кнопки питания и прошит в ядро Linux, второй отображается на ранних этапах инициализации и записан в файл /initlogo.rle (сегодня почти не используется), последний запускается с помощью приложения bootanimation и содержится в файле /system/media/bootanimation.zip.
Кроме стандартных триггеров, init позволяет определять собственные триггеры, которые могут срабатывать от самых разных событий: подключения устройства к USB, изменения состояния смартфона или изменения состояния системных переменных.
Кроме всего прочего, Activity Manager также занимается убийством фоновых приложений при нехватке памяти. Значения порогов свободной памяти содержатся в файле /sys/module/lowmemorykiller/parameters/minfree.
Все это может выглядеть несколько непонятно, но самое главное — запомнить три простые вещи:
- Процесс запуска Android делится на две ключевые стадии: до Zygote и после. До старта Zygote система инициализирует низкоуровневые компоненты ОС. Это такие операции, как подключение (монтирование) файловых систем, запуск низкоуровневых служб (например rild, отвечающий за работу с GSM-модемом, SurfaceFlinger, управляющий тем, что изображено на экране, vold, управляющий подключенными файловыми системами). После запуска Zygote начинается инициализация исключительно Java-компонентов, которые составляют 80% операционной системы. Этим, в частности, пользуется известный фреймворк Xposed, который при установке подменяет app_process на собственную модифицированную версию, которая способна перехватывать вызовы любых Java-классов, подменяя их на любые другие. Именно поэтому у модулей Xposed такие широкие возможности по модификации внешнего вида и поведения Android. На самом деле они ничего не изменяют в системе, а просто заставляют ее использовать сторонние компоненты вместо своих.
- Java-приложения никогда не запускаются «с нуля». Когда Zygote получает запрос на старт приложения от Activity Manager, он не запускает новую виртуальную машину, а просто форкается, то есть копирует самого себя и затем запускает поверх полученной копии виртуальной машины нужное приложение. Такой принцип работы позволяет, во-первых, свести расход памяти к минимуму, так как Linux при форке копирует память в режиме copy-on-write (новый процесс ссылается на память старого), а во-вторых, существенно ускорить запуск приложения: форк процесса происходит намного быстрее запуска новой виртуальной машины и загрузки нужных приложению Java-классов.
- В Android повсеместно используются интенты. Для общения между собой компоненты Android никогда не применяют прямой вызов процедур и классов. Вместо этого используется система сообщений (интентов), которая, кроме высокого уровня безопасности, дает также множество других вкусностей, таких как, например, возможность вызвать приложение, ничего о нем не зная. Выше я уже писал, что для запуска рабочего стола системе достаточно послать интент Intent.CATEGORY_HOME, на который откликнется любое приложение, способное выполнять функцию лончера. Таким же образом работает кнопка «Поделиться», а также множество других компонентов системы.
Системные службы и потоки ядра
- Официальная документация init.rc в исходниках Android: goo.gl/QciYVW
- Описание формата файла /sys/module/lowmemorykiller/parameters/minfree: goo.gl/gKdGPT
- Каталоговая структура Android: goo.gl/363Sq6
- Описание фоновых служб: goo.gl/rtmGgf
Выводы
Во многом Android сильно отличается от других ОС, и с наскоку в нем не разобраться. Однако, если понять, как все работает, открываются просто безграничные возможности. В отличие от iOS и Windows Phone, операционка от гугла имеет очень гибкую архитектуру, которая позволяет серьезно менять ее поведение без необходимости писать код. В большинстве случаев достаточно подправить нужные конфиги и скрипты.
Евгений Зобнин
Редактор рубрики X-Mobile. По совместительству сисадмин. Большой фанат Linux, Plan 9, гаджетов и древних видеоигр.
Источник