Как достать boot img из прошивки

Здесь процесс решения и результат, а не только готовый результат.

Прежде всего хочется сказать, что если в интернете нет готового решения для конкрентного телефона, то нужно копаться в коде, а если не понимать что код делает, то ничего не получится. К счастью если на информатике были азы delphi или чего-то подобного и знать основы if else, то разобраться и сделать можно.

Обсуждения других пользователей, поиск решений и готовые решения в результате моих 2-х дневных поисков тут:
forum.xda-developers.com/…read.php?t=1815131&page=7
4pda.ru/forum/index.php?showtopic=675183&

Расписываю не только мой метод, но и пути решения, так как когда я сам искал способ, то очень помогали решения и домыслы других в построении схемы работы этого всего.

Сначала метод №1 c fastboot, который у меня не получился:
fastboot oem off-mode-charge 0

То есть нужно установить ADB. Весь качать не нужно, можно скачать урезанную версию на forum.xda-developers.com/showthread.php?t=2588979
Затем установить root на телефон, включить режим отладки по USB. Подключить телефон. На компьютере в папке программы adb в любом месте проводника при нажатом shift нажать правой кнопкой и в меню выбрать Открыть окно команд. Там пишем adb devices и видим телефон, если не видим решаем впорос, если видим, то вводим adb reboot-bootloader и телефон загрузится в fastboot. далее собственно: fastboot oem off-mode-charge 0
У меня не прокатило потому что далее написало — я искал решение, но не нашёл и забыл на этот лёгкий способ. Есть подозрение на урезанную версию adb или на драйвера, но ладно, есть другой метод — это правка boot.

Далее метод №2 по парвке загрузчика.

Лично я начал с того, что все говорят нужно править init.rc. Но init.rc перезаписывается каждый раз при запуске телефона из бута => НУЖНО ПРАВИТЬ БУТ.

Проще всего получить boot.img и записать его обратно — это использовать бэкапер под свой телеон. Бэкапер не просто приложений андроид, а всей системы телефона. Для этого нужно найти тему про свой телефон и в ней обязательно будет скрипт или программа, которая делает бэкап телефона. У меня это AIO Tookit. В описании программы будет написано, что потребуется установить драйвера для телефона, чтобы программа смогла с ним связаться и сделать полный бэкап. Так же можно использовать другие способы, в этой теме forum.hovatek.com/thread-1405.html написаны основные — adb, adb + dd, ADB + ROMdump.zip, Terminal + ROMdump.zip, AIO Flasher.

boot.img получен, ура, теперь его нужно разобрать.

Сначала сложный способ, затем лёгкий 🙂

СЛОЖНЫЙ для windows юзера:

Есть такой split_bootimg.pl на перл. Для split_bootimg.pl (разбивалка бута) требуется perl, в принципе можно поставить на windows и из винды запустить разбивалку бута, но собиралки, то нет( поэтому есть более правильный способ через cygwin (описание на русском на хабре очень хорошее) — в нём можно работать как в linux (либо если нет возможности скачать и поставить cygwin можно запустить виртуалку virtualbox или сервак) так:
-разбираем boot или с помощью split_bootimg.pl или с помощью unpackbootimg+mkbootimg (найти можно легко по имени файла, например тут), можно воспользоваться инструкциями например такой инструкцией

ЛЁГКИЙ для windows юзера:
На 4pda парень молодец сделал суперлёгкую программу для windows, которая разбивает и собирает бут. Качаем, читаем описание как работать =>boot.img разбит! ramdisk получен!

Правка системных файлов в boot.img (точнее в ramdisk):

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

Сначала работал вот с этим кодом в init.star.rc (в разных телефонах называется по разному, но шаблон у всех у них один init.XXX.rc):

(НАЗОВУ ЭТО сервисом charger)

service charger /charger
class charger
user root
group root
oneshot

По коду: сервис charger: класс charger запускает файл /charger

Пробовал (не помогло, забегая вперёд напишу что если бы знал про монтирование /system, то часть вариантов сработало бы):
— с работающего телефона скопировал через root explorer себе файл reboot из /system/bin/reboot (нужен root) и затем подменил файл /charger в корне ramdisk
— вместо "/charger" писал "/sbin/reboot" а в /sbin/ копировал reboot файл, играл с правами на него
— вместо "/charger" писал "/system/bin/reboot"
— вставлял дополнительные строки (от пользователей с 4pda): on property:ro.bootmode=charger…(далее много кода, это только начало) и тд
Всё это не приносило успеха, но по совету по on property:ro.bootmode=charger как я вижу сейчас есть доля истины, так как в полном коде есть монтирование /system — забегая вперёд скажу что монтирование /system — это развязка.

Задался вопросом почему charger исполняется, а reboot нет. Иметь бы исходники их. Права одинаковые. Видимо внутри функции в reboot не исполняются, но почему?

Многие пишут, что на прошивках cyagoen всё работает если просто в файл /charger вписать:
#!/system/bin/sh
/system/bin/reboot
Опять забегая вперёд скажу, что видимо там при подключении зарядки в коде уже прописано монтирование /system.

Ну и на 3-ий день с утра я уже держал в голове, что начну я с того, что возьму весь код в другом файле уже init.star.model.rc (обратил на него внимание потому что в нём много монтирований похожих на загрузку ос) из строки функции:

(ВСЕ on — НАЗОВУ ФУНКЦИЕЙ ДЛЯ УДОБСТВА)

on fs
(там ниже идёт куча монтирований всех систем и ещё всего при загрузке ОС) — думаю ОС при моей функции:
on charger
должно выполнить всё то же что и при загрузке ОС чтобы мой reboot работал точно и вставил всё что ниже функции:
on fs
в мою функцию:
on charger
и так как там в функции on fs было exec /system/bin/какой-то_бинарник, то попробовал его заменить на exec /system/bin/reboot
и при подключении зарядки телефон перезагрузился! То что я обрадовался — это ничего не сказать:)
Далее построчно поудалял строки и выявил, что главное это монтирование /system:
mount ext4 /dev/block/mmcblk0p1 /system wait ro

/dev/block/mmcblk0p1 — у разных прошивок может быть свой! Чтобы узнать его нужно на работающем телефоне в терминале (Terminal Emulator в play market) на рутованном телефоне глануть точки монтирования (fstab ещё в linux называется):
cat /proc/mounts
и найти строку по /system

То есть в итоге чтобы заработало нужно в init.rc в функции on charger вместо старта класса (class_start) charger:

on charger
class_start charger

Сделать:

on charger
mount ext4 /dev/block/mmcblk0p1 /system wait ro
exec /system/bin/reboot
#class_start charger

То есть в код добавлено монтирование /system и исполнение файла reboot из /system, а старт класса charger можно хоть оставить, хоть убрать, ведь он не успеет исполниться после reboot

Далее просто из проб:
Если так же смонтировать /system в файле init.rc в функции on charger и стартануть класс charger:
on charger
mount ext4 /dev/block/mmcblk0p1 /system wait ro
class_start charger
А в классе charger в init.xxx.rc ничего не меняя по классу charger просто файл /charger подменить файлом reboot, то ничего не работает. Странно! Но думаю это потому, что в бинарнике-файле reboot используются не только файлы из /system, но и из других папок, которые я не подмонтировал. Если подмонтировать всё как при старте ОС, то думаю reboot тоже сработает. И подтверждение моей теории вот что: если не подменять /charger файлом reboot, а в этот файл /charger вписать:
#!/system/bin/sh
/system/bin/reboot
То работает! Но это учитывая то, что /system я уже ранее подмонтировал! Ведь тут используются только /system/bin/sh и /system/bin/reboot из /system, который я и смонтировал.

То есть главное ДОЛЖЕН БЫТЬ ПОДМОНТИРОВАН РАЗДЕЛ /system

Ну и 2 рабочих у меня способа:
1. Можно прописать в классе charger исполнение любого файла с содержимым:
#!/system/bin/sh
/system/bin/reboot
2. Можно в функции on charger прописать:
exec /system/bin/reboot

Всё это будет работать только если подмонтирован /system

2-х дневная разработка сократилась бы в 100 раз если бы я сообразил про монтирование с самого начала, потому что все мои попытки правки и класса charger и функции on charger работали бы в большинстве вариантов если бы при этом был подмонтирован /system.

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

Далее на очереди изменение boot logo на логотип марки автомобиля:)

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

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

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

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

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

Подключите устройство Android к ПК
Запустите программу 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 (дампа) с выбранного раздела. Перед тем как начать убедитесь что у вас достаточно много свободной памяти на карте памяти!

Для того чтобы снять образ необходимо в ADB RUN зайти в меню (7) Manual Command > (1) Adb
Залогиниться в терминале под 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) скопируйте данные образы на ПК:

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

fastboot flash boot boot.img

fastboot flash system system.img

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

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

Содержание статьи

Начнем с того, что тебе нужен Linux. В Windows ты сможешь только разобрать прошивку, но собрать обратно уже не получится по чисто техническим причинам. Теперь о прошивке. Обычно они распространяются в виде ZIP-архивов, прошиваемых через кастомные рекавери. Именно один из них нам и понадобится для опытов. Начинать путь ромодела я рекомендую с какой-нибудь максимально приближенной к AOSP кастомной прошивки, потому что в ней зачастую проще разобраться, чем в стоке.

Нужный ZIP можно найти на XDA Developers или 4PDA. Но имей в виду, что нужна прошивка конкретно для твоей модели аппарата, — у того же Galaxy S7 есть несколько модификаций для разных рынков, не всегда совместимых между собой.

Структура ZIP-файла с прошивкой

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

META-INF — папка с метаинформацией о прошивке (сертификат автора, манифест со списком файлов, их контрольными суммами), скриптом обновления (updater-script) и инсталлятором (update-binary), который выполняет команды скрипта по монтированию разделов, копированию файлов и другим действиям с NAND-памятью;
boot.img — образ с ядром и RAM-диском (он прошивается в раздел boot);
system.new.dat — это, грубо говоря, и есть сама прошивка, а точнее образ раздела system, содержащий операционную систему Android за вычетом ядра;
system.transfer.list — содержит список команд, которые необходимо выполнить, чтобы поблочно скопировать содержимое system.new.dat в раздел system при установке прошивки;
system.patch.dat — используется для OTA-обновлений, то есть выборочного внесения изменений в прошивку; если прошивка «полная», он имеет нулевой размер.

Содержимое ZIP-файла прошивки LineageOS для Nexus 5

Xakep #252. Чемоданчик хакера

Распаковываем system.new.dat

Файлы system.new.dat и system.transfer.list представляют для нас наибольший интерес. Точнее, не они, а содержащаяся в них система. Но добраться до нее не так просто.

Скрипт

Самые ленивые могут разобрать прошивку с помощью скрипта System_Extractor-Linux.

Распаковываем архив с прошивкой в любую папку.
Качаем скрипт по ссылке и разархивируем в любую папку.
Запускаем файл ext (если будет ругаться на отсутствие Java, просто пропусти, нажав y ; Java нужна только для запаковки).
Теперь выбираем распаковку, нажав кнопку 1, а затем Enter.
Новая папка с именем extract_* появится рядом с файлом ext и папкой tools . Копируем в нее файлы system.new.dat и system.transfer.list .
После копирования файлов нажимаем Enter и ждем. Через некоторое время нужно будет опять нажать Enter, ввести пароль администратора и еще раз тапнуть Enter.
Готово. Содержимое system в папке extract_*/output .

Скрипт для распаковки system.new.dat в Linux

Ручной способ

Распаковываем архив с прошивкой в любую папку (например, в rom ):

Скачиваем нужные нам инструменты в эту папку:

Он преобразует файл system.new.dat в raw-образ с именем system.img . Монтируем образ к подпапке mnt :

Содержимое образа system

Структура каталогов Android

После распаковки system появится следующая каталоговая структура:

app — предустановленные приложения со стандартными привилегиями;
priv-app — предустановленные приложения с повышенными привилегиями, в том числе некоторые компоненты системы;
bin — бинарные файлы формата ELF, аналог каталогов /bin и /usr/bin в Linux. Содержит различные системные компоненты, используемые более высокоуровневыми компонентами системы;
etc — файлы настроек. Полный аналог /etc в Linux, используемый, однако, только теми самыми системными компонентами. Приложения Android хранят индивидуальные настройки в каталогах /data/data/ ;
fonts — шрифты. По умолчанию содержит только фирменные шрифты Roboto;
framework — библиотеки Java-классов, используемых системой и приложениями. Тут же лежит файл framework-res.apk , содержащий полное описание интерфейса операционной системы, включая все графические файлы;
lib и lib64 — Linux-библиотеки, используемые низкоуровневыми компонентами системы. Аналог каталогов /lib и /usr/lib в Linux, включая такие стандартные библиотеки, как libc, libz, libssl. На устройствах с архитектурой ARMv7 и ниже каталог lib64 будет отсутствовать;
media — медиафайлы: рингтоны, звуки уведомлений, звуки интерфейса и анимация загрузки ОС;
tts — файлы, необходимые синтезатору речи;
usr — каталог, который обычно содержит файлы, необходимые для работы приложений из каталога bin. По сути, аналог /usr/share ;
vendor — файлы, поставляемые производителем устройства. Обычно содержит бинарный firmware для различных железных компонентов, например модуля Wi-Fi;
xbin — необязательный каталог; кастомные прошивки используют его для хранения таких вещей, как интерпретатор bash, SSH, PowerTOP, BusyBox, и других полезных инструментов;
build.prop — файл, содержащий информацию о сборке, а также различные низкоуровневые настройки;
addon.d — содержит скрипты, запускаемые после установки прошивки. Сюда же GApps прописывают свой скрипт, благодаря которому возрождаются после переустановки прошивки.

Ознакомившись с базовой структурой Android, начнем вносить изменения.

Удаляем и добавляем приложения

Все предустановленные программы можно найти в двух папках:

Друг от друга они отличаются привилегиями доступа. Если программы из app имеют такие же полномочия, как сторонние программы (например, установленные из Play Store), то приложения из priv-app могут использовать привилегированные API (права privileged). Подробнее об этом можно узнать из нашей статьи.

Для предустановки приложения в прошивку просто кинь ее APK-файл в /system/app/ . Можно, конечно, создать отдельную папку, но в нашем случае в этом нет смысла, потому что папка служит для хранения библиотек и odex-файлов, которых у нас попросту нет. Для удаления просто удали папку с ним.

Можно пойти дальше и поменять стоковые приложения на аналоги. К примеру, для замены календаря удаляем папку Calendar и копируем в /system/app наш любимый com.rpagyc.simplecalendar.apk . А можно и не копировать. Тогда прошивка будет без календаря.

Главное, помни: стоковые программы могут быть связаны между собой. Поэтому удаление одной проги вполне может привести к полной неработоспособности другой (к примеру, CalendarProvider и Calendar: удалив первый, ты сделаешь неработоспособным не только стоковый, но и любой другой календарь). К счастью, в чистых AOSP-прошивках взаимосвязей не так много.

Меняем анимацию загрузки

Анимация хранится в виде PNG-картинок, упакованных в архив /system/media/bootanimation.zip без сжатия. Внутри архива находятся:

desc.txt — файл, описывающий анимацию;
part0 — папка с файлами анимаций, которые воспроизводятся первыми;
part1 — папка с файлами анимаций, которые воспроизводятся вторыми;
.
part? — крайняя папка, изображения с которой воспроизводятся в конце.

Файл desc.txt может содержать нечто вроде

Назначение этих строк интуитивно понятно: 1920 × 1080 — разрешение картинки, 60 — число кадров в секунду. Part0 и part1 указывают на папки, из которых будет воспроизводиться анимация, и последовательность воспроизведения. Вообще, может быть как одна часть, так и несколько (три и больше).

Изображения, находящиеся в папках part, пронумерованы пятью цифрами в порядке воспроизведения: 00000.png , 00001.png , 00002.png . Эти изображения можно поменять на свои, тем самым создав оригинальную анимацию. А можно просто удалить файл bootanimation.zip . Тогда девайс будет показывать анимацию из стандартного Android. Или воспользоваться уже готовой коллекцией анимаций на 4PDA.

Четыре части в bootanimation.zip для LineageOS

Изменяем звуковое оформление

Фактически все звуки, которые воспроизводит система, хранятся в папке /system/media/audio . Внутри нее ты найдешь следующие папки:

alarms — мелодии будильника;
notifications — звуки уведомлений;
ringtones — мелодии звонка;
ui — системные звуки, например низкий заряд батареи, фокусировка камеры, выбор элементов интерфейса.

В alarms, notifications, ringtones можно накидать сколько угодно любых мелодий. Взять их можно, например, здесь:

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

Добавляем шрифты

Шрифты хранятся в fonts . Найти архивы с файлами шрифтов можно на 4PDA и XDA. Для установки достаточно скопировать с заменой ttf-файлы из архива в папку fonts .

Меняем системные настройки (build.prop)

В образе system есть интересный файлик build.prop , содержащий множество полезной информации о железе устройства и настройках, устанавливаемых по умолчанию, для различных стоковых приложений. Справедливости ради замечу, что это не всегда так. Например, в Gigaset ME и ME Pro build.prop разделен на две части. В одной части содержатся настройки для Gigaset ME, а для ME Pro некоторые строки продублированы, но ключи (название смартфона и так далее) в них другие. Это было сделано, чтобы обеспечить более-менее корректную работоспособность одной и той же прошивки на разных аппаратах.

Дополнительный файл для Gigaset ME и ME Pro

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

ro.product.model и ro.product.manufacturer — модель смартфона и имя производителя. С помощью замены этих строк можно заставить Play Store думать, будто у тебя другой смартфон, что откроет доступ к большему количеству софта. Для всяких малоизвестных китайских смартфонов эти строчки могут стать спасительными;
hw.qemu.mainkeys — принимает только два значения: 0 — показать наэкранные клавиши навигации, 1 — не показывать кнопки. Отсутствие строки соответствует 0;
debug.sf.nobootanimation — значение 1 отключает анимацию загрузки, что немного поднимает ее скорость. Установка 0 или удаление строки возвращает анимацию на место;
ro.telephony.default_network — говорит системе, в какой режим должна быть переключена мобильная сеть при загрузке;
ro.sf.lcd_density — DPI дисплея, наиболее точное значение для дисплея можно посчитать через удобный сайт. Но никто не запрещает поставить и большее или меньшее значение по своему вкусу: более высокие значения делают элементы интерфейса крупнее, низкие — меньше;
ro.config.vc_call_vol_steps — количество шагов громкости во время разговора (по умолчанию 8);
ro.config.media_vol_steps — количество шагов громкости мультимедиа (по умолчанию 15).

Внедряем в прошивку Google Apps

Почти всегда кастомные прошивки поставляются без сервисов Google и магазина приложений. Разработчики предлагают нам установить их отдельно с помощью пакета GApps. Однако его можно интегрировать прямо в прошивку.

Для начала необходимо скачать пакет GApps. Я рекомендую брать архивы Open GApps. Выбираешь версию Android, архитектуру процессора и вариант комплектации (Pico, Nano, Stock. ), который определяет, сколько различных приложений Google содержит архив. Я рекомендую скачать версию Pico. Она содержит только Play Store и набор необходимых для его работы библиотек.

Интеграция GApps в прошивку выполняется так:

Распаковываем ZIP-архив GApps с помощью любого архиватора.
Переходим в папку Core.
Видим множество архивов с расширением .tar.lz . Извлекаем с помощью lzip.
После распаковки копируем файлы из папок в соответствующие папки в system. Что куда кидать, нетрудно догадаться по структуре каталогов в архиве. Например, configupdater (со скриншота) нужно кидать в папку priv-app .
Переходим в папку GApps (находится рядом с Core) и проделываем пункты 3 и 4 для файлов в ней.
Все, мы интегрировали GApps в нашу прошивку!

Структура каталогов configupdater-all.tar.lz

Свободное место

Необходимо понимать, что место для установки прошивок ограниченно. Нельзя установить прошивку, размер которой перевешивает размер раздела system устройства. Посмотреть его значение можно, используя ADB:

Инфа о разделе system

Второй вариант: поставить на устройство терминал и набрать команду

Размер раздела в байтах можно узнать, установив на смартфон BusyBox и выполнив в терминале команду

Или то же самое с помощью ADB:

Место, занимаемое прошивкой, будет приблизительно равно размеру system в распакованном виде. Вообще, при создании прошивки необходимо учитывать, что юзер также может прошить поверх нее различные модификации (SuperSU, Xposed) или перенести приложения в раздел system. Например, минимальный пакет приложений Google (Pico) требует минимум 150 Мбайт дополнительного пространства для установки.

При необходимости размер файла прошивки можно уменьшить, удалив не только ненужные программы из /system/app ( /system/priv-app ) и звуки вызова из system/media/audio и bootanimation.zip , но и:

/system/tts/lang_pico — языки примитивного голосового движка Pico TTS, голосовой движок Google это не затронет;
/system/usr/srec/config/ — офлайн-языки. Можно будет скачать потом онлайн, если понадобится.

Сборка

После внесения изменений нужно собрать все обратно. Сначала запакуем раздел system в system.new.dat . Скачиваем нужные нам инструменты:

Преобразовываем нашу папку обратно в RAW-образ. Назовем его system_new.img :

1073741824 меняем на размер раздела system в байтах. Желательно даже сделать его чуть меньше. Делаем из RAW-образа sparse-образ:

Преобразуем наш образ в system.transfer.list и system.new.dat , которые и нужно кидать в архив с прошивкой, но сначала удалим старые файлы:

Отделим файлы прошивки от лишней шелухи (файлов, которые мы загружали для работы. Для этого удобно пользоваться архивом с прошивкой). Удалили? Теперь нужно запаковать прошивку в ZIP-архив (любым архиватором).

Осталось подписать архив. Сделать это можно как на самом Android с помощью ZipSigner, так и на ПК (потребуется установленная Java):

Подводные камни

Во время сборки system.new.dat ты можешь столкнуться с несколькими проблемами, вызванными постоянными изменениями в механизмах формирования прошивок Android. Описанный выше способ должен хорошо сработать в случае основанной на Android 5.1 прошивки, в более новых могут возникнуть сложности, так что потребуется использовать другие версии инструментов сборки. К сожалению, мы не можем описать все нюансы сборки, поэтому, возможно, придется погуглить.

Установка

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

Выводы

Эта статья описывает лишь верхушку огромного айсберга под названием «модификация прошивок». «Серьезные» прошивки не только дополняют ядро и саму прошивку со стоковыми приложениями множеством функций (которые зачастую вырваны из других ядер и прошивок), организовывая или даже меняя принципы их взаимодействия, но и вполне могут кардинально менять принципы работы ОС. Правда, такая поделка — это уже не Android, а отдельная ОС, даже если Play-сервисы получится туда поставить (кстати, такие действия, мягко говоря, не поощряются Google). Ну и не забываем: все оболочки от производителей — TouchWiz, ZenUI, HTC Sense и так далее — всего лишь обычные кастомы, максимально привязанные к железу устройства и друг к другу.