Boot img где находится android

Boot img где находится android

Dreamer.

Введение

Общаясь на форумах и являясь куратором нескольких тем, часто сталкиваюсь с полным непониманием новичков об устройстве андроида. «Ну, а зачем обычному пользователю знать это?» — скажете вы. И тут я с вами соглашусь, задав встречный вопрос: «А зачем тогда обычный пользователь лезет в дебри прошивок, root доступа и твиков системы, не понимая в этом ничего?». Именно это и натолкнуло меня на написание данной статьи, в которой я попытаюсь, обычным и понятным языком, донести сложные вещи.

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

Содержание:

  1. Разделы внутренней памяти.
  2. Bootloader,recovery,adbиfastboot
  3. Внутренности системы.
  4. Root.

1. Разделы внутренней памяти

Внутренняя память устройства на андроиде разбита на несколько логических дисков (разделов).

Приведу только основные:

Bootloader – здесь находится микропрограмма (загрузчик), позволяющая запускать операционную систему, рекавери и другие сервисные режимы.

Recovery – как видно из названия, тут установлено инженерное меню восстановления или просто Рекавери.

Boot – сердце Андроид ОС, тут находится ядро, драйвера и настройки управления процессором и памятью.

System – системный раздел, в котором находятся все, необходимые для работы Android ОС, файлы, это как папка Windows на вашем диске С: (здесь и далее буду проводить ассоциацию с ОС Windows)

Data – раздел для установки приложений и хранения их данных. (Program files)

User – это всем известная sdcard или, проще говоря, место под пользовательские файлы (Мои документы). Здесь я вынужден сделать отступление, т.к. размещение данного раздела имеет несколько вариантов:

  • Раздел отсутствует во внутренней памяти, а вместо него используется внешний накопитель — самый популярный вариант. (рис.1)
  • В устройствах со встроенной памятью большого размера, данный раздел видится какsdcard, а внешняя карта памяти видится какsdcard2илиextsd(могут быть и другие варианты названия). Обычно, встречается на устройствах сAndroid3.2. (Рис.2 Вариант 1)
  • Данный вариант пришел на смену предыдущему варианту, вместе с Андроид 4.0. РазделUserзаменили папкойmediaна разделеData, что позволило использовать всю доступную пользователю память для установки программ и хранения данных, а не то количество, что выделил нам производитель. Иными словамиsdcardиdataявляются одним целым. (Рис.2 Вариант 2)


2. Bootloader, Recovery, adb и fastboot

Теперь, когда мы знаем, что и где находится, давайте разберемся для чего оно там.

Начнем с Bootloader. Это загрузчик, который запускает Андроид, рекавери и т.п. Когда мы нажимаем кнопку включения, запускается загрузчик и, если нет дополнительных команд (зажатых клавиш), запускает загрузку boot. Если же была зажата комбинация клавиш (у каждого устройства она своя) то запускает, в зависимости от команды, recovery, fastboot или apx. На рисунке ниже наглядно показано, что запускает Bootloader и как взаимосвязаны разделы.

Как видно из рисунка №3, раздел Recovery не влияет на загрузку Андроид ОС, но зачем же он тогда нужен? Давайте попробуем разобраться.

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

Особо внимательные читатели могли заметить на Рис.3 некий Fastboot. Это интерфейс для работы напрямую с разделами внутренней памяти, при помощи командной строки. Через него можно прошить рекавери, ядро или новую версию прошивки, или же форматировать (удалить всю информацию) тот или иной раздел.

Раз уж зашла речь об интерфейсах, хочу рассказать о еще одном, довольно известном,- adb (android debug bridge). Это, так называемый, режим отладки и назван он так неспроста – через него можно отслеживать работу, как системы в целом, так и отдельных приложений. Но это еще не все, при помощи adb можно получить полный доступ к файловой системе устройства и изменять системные файлы или же вытянуть важную информацию, когда ваш девайс завис на загрузке. Все функции режима отладки описывать не буду т.к. моя цель донести общую информацию, а не подробный обзор о функциях того или иного режима.

3. Внутренности системы

Разобравшись с теорией, давайте запустим Андроид ОС.

Нажимаем кнопку питания — запускается Bootloader, который загружает Ядро (boot), оно, в свою очередь, запускает систему (System), ну, а она уже подгружает программы (data) и пользовательское пространство (user). (Рис.3)

А теперь перейдем в корневой каталог и посмотрим на внутренности самой Android OS:

В этой схеме я привел, только необходимые для ознакомления, директории. На самом деле их гораздо больше и на обзор только одной папки System понадобится целая статья.

Читайте также:  В микшере громкости нет игры

И так, папка data. Как можно догадаться из названия, она как-то связана с данными, но с какими? Да практически со всеми, это и данные о синхронизации и аккаунтах, пароли к точкам доступа wifi и настройки vpn, и так далее. Среди всего прочего тут можно обнаружить папки app, data и dalvikcache – рассмотрим их назначение:

  • app – сюда устанавливаются программы и игры.
  • data – здесь хранятся данные приложений, их настройки, сэйвы игр и прочая информация.
  • dalvikcache — программная область кэш-памяти для программы Dalvik. Dalvik это Java-виртуальная машина, которая является основой для работы программ, имеющих *.apk расширение. Для того, чтобы сделать запуск программ быстрее — создается их кэш.

Папка System хранит в себе системные данные и все необходимое для работы ОС. Давайте рассмотрим некоторые из этих папок:

  • app – здесь находятся системные приложения (смс, телефон, календарь, настройки и т.п.), а так же приложения установленные производителем устройства (фирменные виджеты, живые обои и т.д.).
  • fonts – системные шрифты
  • media – содержит стандартные мелодии звонков, уведомлений, будильников и звуков интерфейса, а так же загрузочную анимацию (bootanimation)
  • build.prop – Этот файл упоминается, чуть ли не первым, в разговорах и статьях о тонкой настройке системы. В нем содержится огромное количество настроек, таких как плотность экрана, время задержки сенсора приближения, управление wifi, имя и производитель устройства и многие другие параметры.

4. Root

Знать что в какой папке это хорошо, но можно ли что-то с этим сделать?

— Да! Но нужны права суперпользователя (root) или, если проводить аналогию с Windows, права Администратора. Изначально все устройства на Андроид идут без root прав для конечного пользователя, т.е. покупая девайс, мы не являемся в нем полноценными хозяевами. Это сделано как для защиты от вредоносных программ, так и от самого пользователя – ведь, в неумелых руках, полный доступ к системе может привести к «смерти» операционной системы и последующей необходимости в перепрошивке устройства.

«Ну и в чем польза такой опасной штуки?» — спросите Вы.

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

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

— Это все здорово, но теперь любая программа сможет получить доступ к «сердцу» операционки и моим данным?

— Нет. Вы сами решаете разрешить, тому или иному приложению, получить root доступ, или нет. Для этого существует программа Superuser или ее продвинутая сестра SuperSU. Без этой или подобной программы воспользоваться root не возможно.

Эпилог

Как видите, Андроид не такая уж и сложная штука. Надеюсь, после прочтения статьи, вы узнали что-то новое или получили ответ на давно интересовавший вопрос.

Засим откланиваюсь, до встречи в комментариях. 😉

Многие начинающие ромоделы Android или гики не знают как снять образ с Android. В данной статье подробно рассказано как узнать нужные вам /dev/block, как снять дампы с них, разобрать их или в последствие восстановиться.

Для тех кто ничего не понял о чем речь. В данной статье будет подробно рассказано как снять текущее состояние с разделов Android — system, data, efs, preload, cache или выдрать ядро (zImage / boot.img). С какой целью расписываться здесь не будет, так как это уже другая история.

Необходимо для снятия образа

  1. Скачайте и установите на ПК фирменную программу сайта ADB RUN (если в курсе, что такое adb или установлено Android SDK, то устанавливать не нужно);
  2. Android смартфон или планшет должен быть c Root правами Подробно о Root Android:
    • Что такое Root?
    • Как получить Root?
    • Активировать Отладка по USB;
    • Установить драйвера если вдруг не установлены;
    • USB кабель.

    Инструкция как снять образ с Android

    1. Подключите устройство Android к ПК
    2. Запустите программу ADB RUN и перейдите в меню (a) Adb

    Узнаем /dev/block разделов

    Что такое /dev/block/? /dev/block/ — это «диски» на которых находятся разделы system, data, cache.

    Вариант 1

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

    Для того чтобы узнать /dev/block/ вводим команду:

    adb shell mount

    Получаем список, где видим список с нашими разделами и к каким /dev/block/ они примонтированы

    Вариант 2

    Подключаем Android к компьютеру в adb вводим:

    Получаем весь список блоков.

    Снятие образа Android с выбранного раздела

    И так когда мы уже знаем где находятся какие разделы, можно приступать к снятию образа Android (дампа) с выбранного раздела. Перед тем как начать убедитесь что у вас достаточно много свободной памяти на карте памяти!

    1. Для того чтобы снять образ необходимо в ADB RUN зайти в меню (7) Manual Command > (1) Adb
    2. Залогиниться в терминале под Root -ом:
    Читайте также:  Как зайти в телеграм если потерял сим

    3. Набрать linux команду для снятия дампа:

    dd if=/dev/block/XXXXX of=/sdcard/NAME_razdel.img

    • где XXXXXXXXX— раздел с которого вы снимаете
    • где NAME_razdel.img — имя которое вы присвоите при снятии образа с выборного раздела (давать имена лучше также как они указаны, если data то data)

    Процедура снятия может занять определенное время, от 1 минуты до 15, в это время лучше не дергать ваш Android!

    [Обновление]

    В новых версиях ADB RUN появилась возможность быстро снять образ каждый раз не набирая столь длинные команды. Все что вам нужно это знать имя блока.

    Когда вы уже знаете необходимый блок, перейдите в ADB RUN:

    • С главного меню в раздел Backup -> Backup dev/block
    • Выбираем Backup
    • Указываем последние данные с блока (данные после block/)
    • Ждем пока снимется образ (не трогать Android)

    Восстановление раздела из созданного образа Android (дампа раздела)

    Когда вам будет необходимо выполнить восстановление из ранее созданного образа, нужно сделать вот, что:

    Убедитесь что образ все еще находиться в разделе /sdcard — так как бекап создавался именно в этот раздел, либо переместите его обратно.

    Прописать следующую команду:

    dd if=/sdcard/NAME_razdel.img of=/dev/block/XXXX

    • где XXXXXXXXX— раздел на которой вы заливаете образ
    • где NAME_razdel.img — имя образа выборного раздела (давать имена лучше также как они указаны, если data то data)

    Процедура восстановления может занять определенное время, от 1 минуты до 30 в это время лучше не дергать ваш Android!

    [Обновление]

    Особенно актуально для тех кто не удачно выполнил S-OFF (или планирует выполнить) или неудачно прошил кастомную прошивку, либо после не удачных экспериментов!

    Для устройств Sony, HTC, Xiaomi и других устройств на которых есть режим Fastboot могут выполнить восстановление следующим образом после ранее обязательного снятия boot.img (zImage) и system.img (factoryfs.img) скопируйте данные образы на ПК:

    1. Переведите Android в режим fastboot (bootloader) и подключить к ПК;
    2. Файлы boot.img и system.img переместить в папку C:/adb_run/bin;
    3. Запустить ADB RUN и перейти в пункт (a) ADB;
    4. Набрать следующие команды (подробно о Fastboot):

    fastboot flash boot boot.img

    fastboot flash system system.img

    Система будет восстановлена в исходное состояние! Можете продолжать эксперименты!

    На этом все! Подписывайтесь и Оставайтесь с сайтом Android +1! Удачи!

    2016-08-19

    Патчинг ядра для корректной работы Android при загрузке с SD-карты

    Недавно решил помочь обладателям девайса LG L80 Dual (D380) , на котором очень часто "отмирает" eMMC чип. При этом девайс переходит в 9008 режим. В данном режиме PBL на большинстве Qualcomm девайсов пробует произвести загрузку со второго канала SDCC. Конечно же Android ядро загрузится и со второго канала SDCC, но вот остальные части этой ОС совсем не приспособлены адекватно работать в такой ситуации.

    Сразу отмечу, что переход девайса в режим 9008 не во всех случаях означает, что PBL будет пытаться произвести загрузку с SD-карты. Данное утверждение верно лишь тогда, когда переход в 9008 связан именно с проблемами инициализации eMMC устройства (подключено к первому каналу SDCC).

    Самое простое решение озвученной проблемы — это патчинг исходников ядра. Данные патчи я уже давно разработал для своего девайса, т.к. eMMC чипы помирают и у владельцев Highscreen Boost 2 SE (я уже и лично с этим сталкивался).
    Вот ссылки на патчи:
    1) mmc: Swap msm_sdcc.1 msm_sdcc.2 devices via kernel param
    2) base: Fix initialization msm_sdcc.X devices when use swap_sdcc

    Если эти патчи присутствуют в ядре и в командной строке ядра указан параметр " androidboot.swap_sdcc=1 ", то при обращении ОС к устройству с именем " /dev/block/platform/msm_sdcc.1/mmcblk0 " будет задействован не eMMC чип, а SD-карта. Т.е. данные патчи позволяют перенаправить вызовы на самом низком уровне, что избавляет от необходимости изменения кучи разных настроек в прошивке для корректной работы ОС с SD-карты.

    Но для LG L80 Dual (D380) никто так и не выложил исходников ядра. Поэтому в данном случае нужно патчить стоковое ядро. И я расскажу как это сделать без использования дизассемблера. Буду использовать только следующий набор утилит:
    1) AndImgTool — распаковщик образов
    2) dtbToolCM
    3) dtc
    4) WinHEX — виндовый hex-редактор
    5) Notepad++ — функциональный тектовый редактор
    6) zimg-packer.py — скрипт для пересоздания zImage

    Работу с первыми тремя утилитами я уже описывал в этом блоге. Поэтому заострять внимание на них я не стану.

    Приступим. Сначала нужно распаковать образ boot.img , для чего я использую виндовую утилиту AndImgTool. В результате мы получим на выходе следующие, интересующие нас, файлы:
    1) kernel.img — оригинальный образ ядра;
    2) zImage — упакованный образ ядра;
    3) dtb.img — QCDT образ дерева устройств.

    Читайте также:  Как удалить офис 365 в windows 10

    Начнем патчинг с файла kernel.img . Т.к. целевой девайс основан на SoC msm8210, то для начала нужно взглянуть на исходники ядра для этого чипа. Вначале стоит начать со структуры msm8610_auxdata_lookup :
    В данной структуре следует поменять местами физические адреса устройств: 0xF98240000xF98A4000 , 0xF98249000xF98A4900 . При наличии исходников сделать это просто. Но и без них это тоже довольно просто. Главное найти это место в файле kernel.img , который представляет оригинальный образ Android-ядра. Для поиска этого места нужно в WinHEX вызвать диалог " Find Hex Value " и указать для поиска следующую последовательность байт " 004982F9 " (так выглядит 32-битное число 0xF9824900 в виде массива байт). Результат поиска таков:
    После изменения физических адресов этот участок файла примет такой вид:
    Из структуры, приведённой выше, понятно, что сразу после физического адреса находится адрес строки, содержащей название канала SDCC. Поэтому делаем вывод о том, что строка " msm_sdcc.1 " расположена по адресу 0xC0B245A8 , а строка " msm_sdcc.2 " — по адресу 0xC0B245B4 .

    Далее взглянем на содержимое структуры msm_clocks_8610 :
    В этой структуре следует поменять местами названия " msm_sdcc.1 " ⇄ " msm_sdcc.2 ". Для начала это место нужно найти. Для этого достаточно устроить поиск HEX-последовательности " A845B2C0 ", которая означает адрес строки " msm_sdcc.1 ". Результат поиска может быть не один, но нас интересует такой участок файла kernel.img, в котором рядышком находятся адреса 0xC0B245A8, 0xC0B245A8, 0xC0B245B4, 0xC0B245B4 (см. структуру msm_clocks_8610 ). И такое место в файле действительно есть и оно выглядит так:
    Сразу можно заметить, что за первым адресом 0xC0B245A8 следует ещё один такой же, а затем следуют два адреса 0xC0B245B4 . Второго похожего места в файле kernel.img просто нету.
    Для патчинга структуры msm_clocks_8610 достаточно поменять местами эти самые адреса. После чего получаем такой листинг:
    На этом патчинг файла kernel.img закончен. Изменения следует сохранить.

    Теперь приступим к патчингу QCDT. Сначала нужно распаковать файл dtb.img . Для этого нужно воспользоваться утилитами android-image-tools (сам процесс распаковки уже описывался в этой блоге). После распаковки я получил два файла " dt_00.dts " и " dt_01.dts ". Дальнейшие изменения я буду вносить в оба файла, т.к. скорее всего они все могут быть задействованы ядром (видимо у LG L80 две ревизии мат. плат).

    Файлы " dt_XX.dts " следует изменять в обычном тектовом редакторе Notepad++.

    На первом этапе патчинга DeviceTree нужно пропатчить все места, где есть упоминание строки " sdcc ".

    После запуска поска строки " sdcc " находим следующее место:
    В этом месте (как и во всех остальных) нужно поменять местами содержимое данных объектов. В итоге получаем такое содержимое:
    Дальнейший поиск строки " sdcc " указал на следующее место:
    В этом месте (как и во всех остальных) нужно поменять местами содержимое данных объектов. В итоге получаем такое содержимое:
    Затем поиск строки " sdcc " выводит на следующее место:
    Здесь тоже следует помемять местами объекты. Но при этом объект " qcom,sdcc@f9824000 ", который отвечает за eMMC, лучшее вообще удалить, т.к. в рассматриваемом случае eMMC чип полностью нерабочий. Так же стоит выставить параметр " qcom,nonremovable ", что укажет на то, что SD-карта будет неизвлекаемой. В результате получим это:
    На этом поиск строки " sdcc " заканчивается. Теперь нужно устроить поиск строки " sdhci ".
    После запуска поска строки " sdhci " находим следующее место:
    В этом месте тоже исключаем поддержку eMMC чипа. В итоге получаем:
    Дальнейший поиск строки " sdhci " указал на следующее место:
    Здесь тоже следует помемять местами объекты. Но при этом объект " sdhci@f9824900 ", который отвечает за eMMC, лучшее вообще удалить, т.к. в рассматриваемом случае eMMC чип полностью нерабочий. Так же стоит выставить параметр " qcom,nonremovable ", что укажет на то, что SD-карта будет неизвлекаемой. В результате получим это:
    На этом редактирование DeviceTree можно закончить. Теперь нужно отредактированные dts-файлы преобразовать в QCDT-образ при помощи утилит android-image-tools (сам процесс уже описывался в этой блоге).

    В результате патчинга мы получили обновлённые файлы kernel.img и dtb.img . Т.к. утилита AndImgTool не умеет преобразовывать файл kernel.img в файл zImage , то нужно предварительно воспользоваться специальным python-скриптом zimg-packer.py. Данный скрипт поддерживат только те zImage , которые используют GZIP алгоритм. После отработки этого скрипта должен появиться файл zImage_new , который нужно переименовать в zImage . После этого при помощи утилиты AndImgTool нужно создать новый файл boot.img , который будет содержать патченные kernel.img и dtb.img .

    Полученный zImage допускается использовать и для создания TWRP, который будет запускаться с SD-карты.

    Ссылка на основную публикацию
    Adblock detector