Что такое инициализация андроида

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

Инициализация – это что такое? Для чего она проводится? Какие следствия её осуществления? Что делать при возникновении ошибок? Эти и множество иных вопросов мы рассмотрим в рамках данной статьи.

Общая информация

Для начала давайте разберёмся, что же собой представляет инициализация. Это обозначение используется для создания, активации, подготовке к работе и определению параметров программного обеспечения или аппаратной составляющей. Иными словами, они приводятся в состояние готовности к использованию. Процесс инициализации всегда направлен извне по отношению к объекту управления (программе или устройству). Он необходим для того, чтобы определить параметры и правила работы.

Примеры инициализации

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

Поговорим о программах

Как видите, инициализация – это важный аспект взаимодействия с информационными технологиями. Давайте рассмотрим, как же происходит этот процесс на примере загрузочной программы EXE. Итак, первоначально необходимо передать «Ассемблеру» указания, в которых будет иметься и соответствовать действительности информация про сегментные регистры. Затем сохраняется адрес в стеке, что находится в регистре DS. После этого он обнуляется. И в завершение – в регистр загружается адрес нужного сегмента данных. Когда работает «Ассемблер», то он может определять наличие смещений в отдельных областях. При этом перед загрузочным модулем включается 256-байтная область, которая известна ещё как префикс программного сегмента PSP. Чтобы установить адрес её начальной точки используется регистр DS. Пользовательская программа сохраняет адрес, помещая его в стек с последующим возвратом в DOS. И здесь часто возникает ошибка инициализации. Почему? Дело в том, что системе требуется, чтобы следующее значение было нулевым адресом стека. Для этого необходимо, чтобы с помощью специальной команды был очищен регистр AX. Если этого не сделать, то возникают проблемы. Когда же может возникнуть ошибка инициализации? При использовании нелицензионного программного обеспечения, когда не был произведён качественный взлом, или же, когда она запускается просто на разных операционных системах, и были перемещены адреса системных регистров.

Когда могут возникать проблемы?

Это весьма интересный вопрос, на который всё же нужно дать ответ, раскрыть его полностью. Рассмотрим, что собой представляет инициализация Windows. Первоначально подгружается базовая система ввода/вывода. И уже БСВВ инициализирует операционную систему. Если нет конфликтов с системными регистрами, то всё подгружается без проблем и так же функционирует. Но, допустим, была установлена пиратская операционная система. И пришло заводское обновление. Если согласиться на предложение его установить, то будет заменена часть информации, которая позволяет работать. И из-за внутренних механизмов безопасности функционирование будет блокировано. Иными словами, повреждение конфигурации любой программы – это самая частая причина того, что инициализация не возможна. Но, к счастью, это относится разве что к более старым версиям, нежели Windows 10, которая была сделана бесплатной. А сейчас давайте обратим внимание к аппаратной составляющей.

Как работает жесткий диск?

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

Тестирование

Итак, мы знаем, что собой представляет инициализация. Это постепенно подводит к такому вопросу – а что делать в случае проблем? Первоначально необходимо протестировать проблему. Это можно сделать и вручную, разбираясь с теми ошибками, что выводит компьютер, или же воспользоваться любым некоммерческим продуктом соответствующего профиля. Многие считают, что они не удобны в плане использования и информативности и предпочитают использовать базовую систему ввода/вывода. В пользу последней следует отметить систематичность и методичность перебора информации, и высокую результативность подобного тестирования. К тому же, проверка в таких случаях проводится внимательно и небольшими «порциями» загрузочной области, причем – по битах. Если всё было перепробовано, а система не работает, то появляется сообщение о критическом сбое. В случае работы с программой выводится информация о проблеме.

Восстановление

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

1. Провести полную перестройку структуры диска. Иными словами – отформатировать его (данные будут удалены), и заново смонтировать операционную систему.
2. Перезаписать главную загрузочную запись с помощью стандартной утилиты. Подходит только для логических областей и существует вероятность удаления данных.
3. Правка загрузочного сектора сторонними программами.
4. Фиксация неисправности с использованием команды bootrec и осуществление реанимации дисковых структур.

Заключение

Вот и было рассмотрено, что же собой представляет инициализация. Частные примеры и случаи можно рассматривать ещё долго и упорно, но, увы, размеры статьи ограничены. Главное – что был рассмотрен сам механизм этого процесса.

Источник

Русские Блоги

Подробный процесс инициализации Android (1)

14 апреля 2013 г. 20:06:42 geekguy Просмотров 7785Больше
Колонка: Android Deep Discovery
Заявление об авторском праве: эта статья является оригинальной статьей блоггера и не может быть воспроизведена без разрешения блоггера.https://blog.csdn.net/nokiaguy/article/details/8800962
Процесс инициализации Android (два); анализ языка инициализации (init.rc)

Версия программного обеспечения, использованная в этой статье

Ядро Linux: 3.1.10

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

Android — это операционная система, основанная на ядре Linux. Аналогичен Ubuntu Linux и Fedora Linux. Просто в Android добавлена ​​уникальная поддержка мобильных устройств на уровне приложений. Поскольку Android — это система ядра Linux, основной процесс запуска должен также соответствовать правилам Linux. Если вы изучали другие системы Linux, вы должны понимать, что полная система Linux сначала загружает ядро ​​Linux в память, то есть файл bzImage, сгенерированный путем компиляции исходного кода ядра Linux, и файл zImage для исходного кода ядра Linux, оптимизированный для Android. Этот файл является двоичной версией ядра Linux. Поскольку zImage работает в пространстве ядра, а программное обеспечение, которое мы обычно используем, работает в пространстве приложения (для подробного описания пространства ядра и пространства приложения вы можете обратиться к книге «Android Deep Discovery (Vol. 1): HAL и разработка драйверов»). В последующих томах будет проведен комплексный анализ всей системы Android). Пространство ядра и пространство приложения не могут быть доступны напрямую через уровень адресации памяти, поэтому необходимо установить какой-то механизм связи.

В настоящее время в Linux имеется множество механизмов связи, которые могут взаимодействовать между пространством пользователя и пространством ядра, например, файлы драйверов устройств (находятся в каталоге / dev) и файлы памяти (каталог / proc, / sys и т. Д.). Студенты, знающие Linux, должны знать, что одной из важных характеристик Linux является то, что все существует в форме файлов, например, устройство обычно соответствует одному или нескольким файлам устройства. Эти файлы, которые взаимодействуют с пространством ядра, находятся в пользовательском пространстве, поэтому после загрузки ядра Linux необходимо сначала создать каталог, в котором расположены эти файлы. Программа, которая выполняет эти задачи, является инициалом, который представит эта статья. Init — это программа командной строки. Одна из его основных задач — создать каталог, в котором находятся эти файлы, взаимодействующие с пространством ядра. Когда ядро ​​Linux загружено, первое, что нужно сделать, это вызвать программу init, то есть init — это первая программа, выполняемая в пространстве пользователя.

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

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

/ system / core / init

Где init.c — основной файл init. Теперь откройте файл и посмотрите его содержимое. Поскольку init — это программа командной строки, анализ init.c должен начинаться с главной функции. Теперь она лучше основной функции. Код выглядит следующим образом:

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

Первая работа хорошо понятна. Вторая задача — ядро ​​init. В системе Linux init — это родительский процесс всех процессов в пространстве приложения. Поэтому мы обычно выполняем команды в терминале Linux и создаем процессы. Это на самом деле сделано в этом бесконечном цикле. Другими словами, после выполнения команды ps -e в терминале Linux все процессы, кроме init, рассматриваются как созданные init. И init будет резидентом. Конечно, если init зависает, система Linux в основном падает.

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

Основная задача создания каталога в начале основной функции относительно проста, и в этой части анализировать нечего. Это вызов какого-то общего API (mkdir) для создания некоторых каталогов. Теперь скажем несколько отступлений, поскольку исходный код Android (включая init) на самом деле относится к области прикладного программирования Linux, поэтому для полного понимания исходного кода Android, в дополнение к пониманию базовой структуры Linux, API уровня приложений Linux должен быть знаком , Чтобы удовлетворить потребности этих читателей, в будущем я напишу несколько статей о разработке приложений для Linux. Хорошо, теперь, когда мы вернулись к работе, давайте проанализируем более важную часть: анализ файла конфигурации.

Файл конфигурации здесь в основном относится к init.rc. Читатель может войти в оболочку Android и увидеть, что в корневом каталоге есть файл init.rc. Этот файл доступен только для чтения, даже если у вас есть права доступа root, вы можете изменить файл. Поскольку файлы, которые мы видим в корневом каталоге, являются просто изображениями файлов памяти. Другими словами, после запуска Android он загружает файл init.rc в память. Изменение содержимого файла init.rc на самом деле просто изменение содержимого файла init.rc в памяти. После перезапуска Android содержимое файла init.rc будет восстановлено до первоначальной загрузки. Единственный способ полностью изменить содержимое файла init.rc — это изменить образ ядра (boot.img) в ПЗУ Android. Фактически, boot.img называется образом ядра, но помимо полного файла ядра Linux (zImage), он также содержит другой файл образа (ramdisk.img). ramdisk.img содержит файл init.rc и команду init. Таким образом, файл init.rc может быть полностью изменен только путем изменения файла init.rc в файле ramdisk.img, перепаковки файла boot.img и перепрошивки компьютера. Если у читателя есть исходный код Android, после компиляции вы увидите, что соответствующие подкаталоги в каталоге out сгенерируют корневой каталог, который фактически является содержимым ramdisk.img после распаковки. Вы увидите команду init и файл init.rc. Как изменить файл init.rc и как прошить аппарат, будет обсуждаться в следующих статьях. Тем не менее, это содержание не имеет отношения к этой статье, поэтому они не будут обсуждаться подробно.

Теперь вернемся к основной функции. После создания каталога вы увидите, что следующие 3 функции выполняются.

Среди них, property_init в основном выделяет некоторое пространство для хранения свойств, эта функция не является основной. Однако, когда мы смотрим на файл init.rc, мы обнаруживаем, что в начале файла используются некоторые операторы import для импорта других файлов конфигурации, например, /init.usb.rc. Большинство файлов конфигурации используют определенное имя файла напрямую. Только следующий код использует переменную ($ ) для выполнения части имени файла конфигурации. Откуда взялась эта переменная?

Первое, что нужно понять, это то, что содержимое файла конфигурации init. $ .rc обычно связано с текущим оборудованием. Теперь давайте сосредоточимся на функции get_hardware_name. Код выглядит следующим образом:

Из кода метода get_hardware_name можно узнать, что этот метод в основном используется для определения значений переменных оборудования и версии. Редакция здесь не обсуждается, пока мы изучаем оборудование. Источником оборудования является командная строка ядра Linux или содержимое файла / proc / cpuinfo. Командная строка ядра Linux пока не обсуждается (поскольку это значение редко передается). Сначала посмотрите на / proc / cpuinfo. Этот файл является виртуальным файлом (файлом памяти). Если вы выполните команду cat / proc / cpuinfo, вы увидите содержимое этого файла. Как показано на рисунке 1. В белом поле находится значение поля Hardware. Поскольку устройство является Nexus 7, значение является группером. Если программа здесь, имя файла конфигурации, связанного с оборудованием, — init.grouper.rc. Читатели с Nexus 7 увидят, что в корневом каталоге действительно есть файл init.grouper.rc. Обратите внимание, что собственное ПЗУ Nexus 7 не задает имя файла конфигурации в другом месте, поэтому имя файла конфигурации — это значение, взятое из поля «Оборудование» файла / proc / cpuinfo.

Теперь посмотрите на функцию process_kernel_cmdline, вызываемую после функции get_hardware_name, код выглядит следующим образом:

Помимо использования функции import_kernel_cmdline для импорта переменных ядра в функции process_kernel_cmdline, основной функцией является вызов функции export_kernel_boot_props для установки переменных ядра через свойства, например, для установки аппаратных переменных через свойство ro.boot.hardware, что означает, что свойство ro.boot.hardware Это значение может изменить значение аппаратного поля, полученного из файла / proc / cpuinfo в функции get_hardware_name. Давайте посмотрим на код функции export_kernel_boot_props.

Как видно из кода функции export_kernel_boot_props, эта функция фактически устанавливает некоторые значения свойств вперед и назад и использует некоторые значения свойств для изменения переменных, таких как консоль и оборудование. Аппаратная переменная (то есть массив из 32 символов) была получена один раз из файла / proc / cpuinfo в функции get_hardware_name, а значение устанавливается один раз через свойство ro.boot.hardware в функции export_kernel_boot_props, но в Этот атрибут не установлен в Nexus 7, поэтому значение аппаратного обеспечения все еще является групповым. Наконец, свойство ro.hardware устанавливается с помощью аппаратной переменной, поэтому конечный файл инициализации называется init.grouper.rc.
Вот еще один вопрос. Я уже упоминал о свойствах или файлах свойств много раз. Так что же означают эти файлы свойств? Такое init.rc? Конечно нет. Фактически, эти файлы свойств являются файлами конфигурации, которые расположены в разных каталогах и последовательно считываются системой.

Вы должны понять, как init обрабатывает эти атрибуты, прежде чем изучать эти файлы конфигурации. Читатели, написавшие собственные приложения для Windows, должны понимать, что в Windows есть механизм реестра, который предоставляет большое количество атрибутов в реестре. В Linux есть похожий механизм, это служба атрибутов. Init запустит службу свойств (сервис Socket) во время процесса запуска и установит область памяти в памяти для хранения этих свойств. При чтении этих свойств читайте непосредственно из этой области памяти. Если вы изменяете значение свойства, вам необходимо заполнить его через службу свойств подключения Socket. В функции действия в файле init.c вызывается функция start_property_service для запуска службы свойств. Действие — это механизм выполнения в init.rc и аналогичных файлах. Поскольку имеется много содержимого, выполнение в файле init.rc Механизм будет подробно обсуждаться в следующей статье.

Теперь вы можете найти функцию start_property_service в файле Property_service.c, который находится в том же каталоге, что и файл init.c.

Теперь, когда мы знаем, как запустить службу свойств, следующие два макроса также задействованы в функции start_property_service.

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

В предыдущем чтении значения свойства использовалась функция property_get, которая реализована в Property_service.c. Код выглядит следующим образом:

Видно, что базовая функция __system_property_find вызывается в функции property_get, и эта функция действительно реализует функцию получения значения свойства. Эта функция принадлежит библиотеке bionic и реализована в файле system_properties.c. Читатель может найти файл в следующем каталоге.

/ bionic / libc / bionic

Код функции __system_property_find выглядит следующим образом:

Из кода функции __system_property_find легко увидеть, что в первой строке используется переменная __system_property_area__, которая является глобальной. В предыдущем анализе основной функции была задействована функция property_init, которая называлась функцией init_property_area, которая используется для инициализации области памяти свойств, то есть переменной __system_property_area__.

В заголовочном файле system_properties.h, соответствующем файлу system_properties.c, упомянутому ранее, определены два вышеупомянутых макроса, представляющих путь к файлу свойств.На самом деле, есть два других макроса, представляющих путь. Всего имеется четыре файла свойств. Файл system_properties.h находится в / bionic / libc / include / sys. Четыре макроса определены следующим образом:

Теперь читатели могут войти в соответствующий каталог устройства Android, обычно вы можете найти вышеуказанные файлы 4. Как правило, вы найдете файл default.prop в корневом каталоге, а cat default.prop увидит содержимое файла. Служба свойств загружает все свойства во все четыре файла свойств и свойства, установленные с помощью property_set. На терминале устройства Android вы можете напрямую использовать команду getprop, чтобы получить все значения свойств из службы свойств. Как показано на рисунке 2. Команда getprop также может напрямую получить конкретное значение свойства на основе имени свойства, например, getprop ro.build.product.

Если читатель заинтересован, вы можете увидеть, как getprop читает и записывает свойства через службу свойств. Файл исходного кода для команды getprop — getprop.c. Читатель может найти файл в / system / core / toolbox. Фактически, получение значений свойств с помощью getprop также выполняется с помощью функции property_get. Эта функция была проанализирована ранее, и фактически была вызвана функция __system_property_find для получения соответствующего значения свойства из области памяти, указанной в переменной __system_property_area__.

Кроме того, в файле system_properties.c есть две следующие функции для изменения или добавления значения свойства через службу свойств.

Переменная property_service_socket участвует в функции send_prop_msg, которая определяется следующим образом:

Источник