Что значит портированные прошивки
Портирование прошивок Android
Тема, как портировать прошивку Android, довольно избитая, но не теряет актуальности. Наоборот, всё больше людей начинают ею интересоваться. В этой статье мы рассмотрим только портирование устройств с одинаковыми ядрами. Если вы хотите себе суперинтересную прошивку, то самое время начинать разбираться с «кухней» этого процесса.
Пошаговая инструкция
*BROM – как правило, родная прошивка.
**Так как здесь будет рассмотрено ARM устройство, сперва нужно узнать, какой у вас процессор.
Действие первое
Cоздайте backup из директории system/app в любую папку на десктопе. Копируя файлы, вы поймёте, в чём дело, ведь если приступили к портированию, значит, наверное, не раз прошивали свой MID.
Действие второе
Удалите приведённые на картинке директории из BROM и, соответственно, вставьте вместо них папки из PROM.
Действие третье
Теперь файлы из первого действия забрасываем обратно в BROM.
Действие четвёртое
Заходим в папку system/lib BROM и копируем с заменой все библиотеки в соответственное хранилище PROM (не удивляйтесь, так проще). То же самое проделываем по путям /system/etc/init.d и /system/etc/permissions. Три вышеуказанные директории теперь можно уничтожить (в BROM), а на их место скопировать всё из PROM.
Важно: откройте файлы build.prop в обеих ROM-ах через Notepad++. Этот усовершенствованный блокнот хорошо показывает табы. Последние должны быть один напротив другого, а запись ro.build.description= должна абсолютно совпадать, иначе прошить устройство у вас не получится вовсе. Если запись не такая, проредактируйте её. То же самое проделайте с updater-script, находящийся по пути META-INFcomgoogleandroid. Естественно, запись должна быть идентична с записью PROMа.
Очень важно: совершенно нельзя менять symlinks. Вы можете изменить или исправить, то ли добавить ui_prints, run_programs, asserts и, конечно, ядро.
Самое важное: в Updater-script BROM Format values должны быть для вашего устройства. Иногда нужно исправить в init.rc BOOTCLASSPATH или просто скопировать его из RBOOT. Потом, естественно, перепаковать ядро.
Ну, всё! Портирование прошивок Android на базе ARM делается так. Удачи!
Портирование MIUI прошивок на MTK смартфоны (На примере MT6582)
Всем привет и возможно пока (ибо на днях в баню попаду)
Что же.. в этот раз напишу гайд по портированию прошивок MIUI с одного МТК девайса на другой, естественно что гайд будет о портировании MIUI 7 и только до версии 4.4 включительно.
Что же для этого нужно?
Итак, для начала вы должны получить рут права, далее в смартфоне включить отладку по USB, как правило этот пункт находится в меню разработчика.
Тут мы должны слить бэкап на комп, чтобы на его основе создать прошивку.
Заходим в программу и если все правильно сделали то нажать кнопку ROOT, чтоб получить root shell (когда вы его получите то прямоугольник в нижнем левом углу станет зеленого цвета).
Далее открываем вторую вкладку программы и выбираем БЭКАП
Начнется создание бэкапа, и далее вам будет предложено запаковать все в архив.
Этого делать не нужно, нажимаете НЕТ (ну или да, если так хочется).
Тут нам важно записать или запомнить какой номер у точек монтирования.
Раздел SYSTEM и раздел DATA.
Тут указано mmcblk0p5 для system (для примера).
Все это пригодится немного позже.
Отлично, бэкап создан и теперь настало время для модификации прошивки.
2) Скачайте прошивку MIUI для вашего процессора, от любой модели смартфона.
К примеру если у вас MT6582 то качаете то же самое.
Ни в коем случае не используйте бэкап сторонних смартфонов, даже тех же моделей, поскольку существуют различные «ревизии» у одной и той же модели.
На одном китайском galaxy s6 я нашел более 5 ревизий и 2 разных типа памяти.
К чему приведет скачивание не той ревизии? от нерабочей камеры, отсутствие картинки до бутлупа (зависания на логотипе).
3) Распаковывайте скачанную прошивку и для удобства откройте 2 окна проводника, со своим бэкапом и скачанной прошивкой.
Примерно это должно быть так
Да да, архив system надо распаковать.
Итак. а теперь переходим к замене фаилов.
Заменяем из папки с бэкапом в папку с скачанной прошивкой
папки lib/hw ; lib/soundfx ; lib/ssl копируем целиком с заменой.
4) Распаковка boot.img и сборка
В архиве с скачаной прошивкой вы должны найти boot.img фаил.
Теперь создайте две папки с программами mtwintool.
В первую папку кидаете бут с бэкапа, во вторую бут из новой прошивки.
Так должна выглядеть папка программы, в папку IN кидайте бут фаил, в другую папку программы кидаете бут фаил от новой прошивки (которую скачали)
Запускаем программу открыв menu.bat (не забудьте когда откроете программу переключить язык на английский)
Тут выбираем сначала пункт 5 (init tools) жмем клавишу Y затем выбираем пункт 1, далее выбираем image unpack и там же выбираем пункт номер 1.
Теперь мы должны получить такую картину
Проделайте те же действия со вторым бутом (из новой прошивки).
Теперь заменяем фаилы.
пусть вас не смущает то что в некоторых прошивках нет фаила kernel_header.
fstab
fstab.fat.nand
fstab.nand
init.project.rc
init.no_ssd.rc этот файл может называться в другом ядре init.ssd.rc
init.usb.rc
так же не забываем о камере
открываем init.rc и находим там раздел #Camera
и копируем все с данного раздела из init.rc (бэкапа) в init.rc новой прошивки.
что копировать именно? пример моего init.rc
Теперь запускаем mtwintools в той папке в которую копировали фаилы с бэкапа и переходим к процессу запаковки.
Для этого в Mtwintools нужно выбрать пункт 1, затем нажать image pack и выбираем фаил бута.
Далее нам будет предложено выбрать метод запаковки, на мой взгляд лучшее это gzip.
Меняем размер bootsize, ставим вместо 0x1000 другое значение, например 0x1200 и так далее, затем снова пытаемся создать бут, если он снова весит 0 килобайт, увеличиваем значение и так до тех пор пока бут не прийдет к нормальному обьему (главное чтоб не 0)
5) Редактирование скрипта
Открываем папку META-INF\com\google\android
фаил updater-script открываем и находим значения вроде таких
format(«ext4», «EMMC», «/dev/block/mmcblk0p5», «0», «/system»);
Вспоминаем карту блоков, а точнее под каким номером у вас находится system и data.
Если в скрипте написано
format(«ext4», «EMMC», «/dev/block/mmcblk0p5», «0», «/system»);
Менять нужно абсолютно все параметры где есть упоминание mmcblk0p(X) под вашу карту блоков.
Теперь перемещаете бут фаил в новую прошивку
и запаковывайте в ZIP. вот и вся система)
НО напоследок дам пару советов.
найдите там параметр ro.sf.lcd_density и измените его значение.
Вот и все ребята,спасибо за внимание.
Напоследок котейку для ламповости поста
Давно хотел снять видео о том как можно обойти блокировку по mi-аккаунту на телефоне Xiaomi Redmi Note 6 Pro методом неофициальной разблокировки загрузчика и установки кастомной прошивки Lineage OS, в которой mi-сервисы соответственно отсутствует :)))
Но сегодня впроцессе подготовки к съемке видео обнаружил интересный баг MIUI 10, который позволяет очень легко обойти блокировку экрана или Google-аккаунта (frp), после сброса к заводским установкам.
Соответственно задаем новый ключ блокировки экрана, подключаем телефон к Wi-Fi (или симку вставляем), вводим свой новый ключик и все, блокировка успешно снята.
Убираем тормоза на смартфонах Xiaomi
Проблема: на смартфонах Xiaomi (и не ксиаоми, а сяомИ) с 2 или 3 гб оперативы на борту часто подтормаживает интерфейс. Владельцы Redmi и Redmi Note грустят больше остальных, так как процы тут побюджетнее и тормоза ощутимее (впрочем, тут могу ошибаться).
Актуальность проблемы: средствами системы эти приложения заморозить или удалить не получится.
Приложение XiaomiADBFastbootTools для ПК, которое позволяет БЕЗ РУТА удалять приложения на смартфоне с последующей возможностью восстановления.
2) Скачиваем и устанавливаем последнюю версию джава-машины по ссылке https://www.oracle.com/java/technologies/javase-jdk14-downlo. чтобы приложение из п. 1 в принципе могло запуститься.
3) Включаем отладку по USB на смартфоне:
Когда приложение скачает из интернета необходимые файлы, видим примерно такую картину:
6) Осталось отметить «вредные» приложения галочкой и нажать кнопку Uninstall.
Удалённые приложения находятся на вкладке Reinstaller и восстанавливаются за один клик.
Инструкция может показаться сложноватой, но поверьте, оно стоит того. Жаль не сделал скриншот ДО, а вот ПОСЛЕ выкладываю:
(грёбаный скайп, если не держать его в пямяти, то уведомления не приходят, даже с включённой автозагрузкой 😡)
Свободно 1,6 ГБ и это через 3 часа после перезагрузки и с парой приложений в памяти! Чисто субъективно, по скорости и отзывчивости это другой телефон. А я уже собирался свой Redmi 7 3Gb на Redmi 8T 4Gb менять, но теперь думаю ещё годик с ним похожу.
PS Всякие гугловские приложения типа Фильмов и Музыки тоже можно удалить если не пользуетесь, но без удаления системной сяомовской шелухи это не слишком помогает.
Если программа не видит смартфон, проблема решается одним из способов:
3) заменить кабель на другой
4) при подключении телефона к ПК выбрать режим только зарядка и подтвердить разрешение на отладку
Что значит портированные прошивки
Начнем с общих вопросов:
Q: Ну и кто все это придумал? Проклятые производители простым гикам жизнь усложняют?
A: Новая структура «A/B разделов» разработана непосредственно Google-ом как часть глобальных изменений в архитектуре Android. Она успешно используется в смартфонах Google Pixel, Essential Phone и различных других устройствах. В дальнейшем все больше устройств от сторонних производителей будут ее использовать. Ничего плохого и страшного в этом нет, наоборот, открывается много новых возможностей.
Таблица разделов на примере Google Pixel:
Дабы наглядно отобразить, изложенную выше, теорию и увидеть отличия по сравнению с другими устройствами — познакомимся с таблицей разделов Google Pixel.
Если вы вообще не знакомы со структурой разделов в Linux-подобных системах, и Android в частности, — советую поискать информацию об этом в Google, благо ее полно.
Нас интересуют конкретные разделы, существующие в двух копиях для наглядности и демонстрации.
Итак (раскрываем код полностью):
/dev/block/bootdevice/by-name/aboot_a # Разделы первого загрузчика (Слот «a»)
/dev/block/bootdevice/by-name/apdp_a # Разделы первого загрузчика (Слот «a»)
/dev/block/bootdevice/by-name/bootlocker_a # Разделы первого загрузчика (Слот «a»)
/dev/block/bootdevice/by-name/cmnlib32_a # Разделы первого загрузчика (Слот «a»)
/dev/block/bootdevice/by-name/cmnlib64_a # Разделы первого загрузчика (Слот «a»)
/dev/block/bootdevice/by-name/devcfg_a # Разделы первого загрузчика (Слот «a»)
/dev/block/bootdevice/by-name/hosd_a # Разделы первого загрузчика (Слот «a»)
/dev/block/bootdevice/by-name/hyp_a # Разделы первого загрузчика (Слот «a»)
/dev/block/bootdevice/by-name/keymaster_a # Разделы первого загрузчика (Слот «a»)
/dev/block/bootdevice/by-name/msadp_a # Разделы первого загрузчика (Слот «a»)
/dev/block/bootdevice/by-name/pmic_a # Разделы первого загрузчика (Слот «a»)
/dev/block/bootdevice/by-name/rpm_a # Разделы первого загрузчика (Слот «a»)
/dev/block/bootdevice/by-name/tz_a # Разделы первого загрузчика (Слот «a»)
/dev/block/bootdevice/by-name/xbl_a # Разделы первого загрузчика (Слот «a»)
/dev/block/bootdevice/by-name/aboot_b # Разделы второго загрузчика (Слот «b»)
/dev/block/bootdevice/by-name/apdp_b # Разделы второго загрузчика (Слот «b»)
/dev/block/bootdevice/by-name/bootlocker_b # Разделы второго загрузчика (Слот «b»)
/dev/block/bootdevice/by-name/cmnlib32_b # Разделы второго загрузчика (Слот «b»)
/dev/block/bootdevice/by-name/cmnlib64_b # Разделы второго загрузчика (Слот «b»)
/dev/block/bootdevice/by-name/devcfg_b # Разделы второго загрузчика (Слот «b»)
/dev/block/bootdevice/by-name/hosd_b # Разделы второго загрузчика (Слот «b»)
/dev/block/bootdevice/by-name/hyp_b # Разделы второго загрузчика (Слот «b»)
/dev/block/bootdevice/by-name/keymaster_b # Разделы второго загрузчика (Слот «b»)
/dev/block/bootdevice/by-name/msadp_b # Разделы второго загрузчика (Слот «b»)
/dev/block/bootdevice/by-name/pmic_b # Разделы второго загрузчика (Слот «b»)
/dev/block/bootdevice/by-name/rpm_b # Разделы второго загрузчика (Слот «b»)
/dev/block/bootdevice/by-name/tz_b # Разделы второго загрузчика (Слот «b»)
/dev/block/bootdevice/by-name/xbl_b # Разделы второго загрузчика (Слот «b»)
/dev/block/bootdevice/by-name/modem_a # Раздел первого модема/радиомодуля (Слот «a»)
/dev/block/bootdevice/by-name/modem_b # Раздел второго модема/радиомодуля (Слот «b»)
/dev/block/bootdevice/by-name/boot_a # Раздел первого ядра (Слот «a»)
/dev/block/bootdevice/by-name/boot_b # Раздел второго ядра (Слот «b»)
/dev/block/bootdevice/by-name/vendor_a # Первый проприетарный раздел (Слот «a»)
/dev/block/bootdevice/by-name/vendor_b # Второй проприетарный раздел (Слот «b»)
/dev/block/bootdevice/by-name/system_a # Первый системный раздел (Слот «a»)
/dev/block/bootdevice/by-name/system_b # Второй системный раздел (Слот «b»)
Как видно из выдержки выше, — имеются два, независимых между собой, слота, а именно «группы разделов», которые содержат в себе основные, обновляемые компоненты прошивки.
Два представленных слота состоят из:
Bootloader (загрузчик) — 28 разделов (14 на каждый слот).
Radio/Modem (радиомодуль) — 2 раздела (по одному на слот).
Boot (ядро) — 2 раздела (по одному на слот).
Vendor (драйверы) — 2 раздела (по одному на слот).
System (система) — 2 раздела (по одному на слот).
Остальные разделы, не указанные в таблице, представлены в одном экземпляре за ненадобностью их деления.
Обратите внимание раздел пользовательского хранилища (userdata) всегда один! Именно поэтому вы не можете (без очистки хранилища) одновременно использовать две абсолютно разных прошивки, будет конфликт. Возможно одновременное использование одинаковых по типу прошивок (а в некоторых случаях и это невозможно без сброса данных).
Принципиальные отличия по сравнению с другими устройствами:
С дублированием разделов и, структурой в целом, разобрались. Однако, вы могли заметить (если просматривали полную таблицу разделов) отсутствие, привычных в любом устройстве, разделов «/recovery» и «/cache». Да, их действительно нет. Но могут и встречаться в отклонениях от нормы.
Q: Стоп. Но если раздела для Recovery нет, а сам Recovery есть (Он ведь есть, правда?), где же он находится?
A: Система восстановления (Recovery) включена в состав образа ядра (boot). А потому, наличие, отсутствие и тип установленного recovery напрямую зависят от ядра системы. Переключение в него (Recovery), как и раньше, осуществляется специальным флагом в «/misc» разделе.
Именно в этом и состоит загвоздка установки TWRP — его как-то нужно «засунуть» в ядро. Потому TWRP сначала временно загружают (устанавливать то его некуда), а затем уже из TWRP, специальным скриптом, на лету распаковывается ядро и вшивается в него TWRP. Такая же схема «перепаковки ядра на лету» применяется при получении «systemless» рут-прав через SuperSU и Magisk.
Q: Хорошо, а что же тогда случилось с «/cache» разделом?
A: В привычных устройствах он необходим лишь для хранения OTA обновлений и системных логов Recovery, в данном же случае, ввиду применения новой схемы этих самых обновлений (см. ниже), раздел стал попросту «не нужОн». Вот от него и избавились.
Ручное переключение слотов:
Естественно, помимо самих слотов, должен быть способ ручного взаимодействия с ними. И он есть. Для ручного переключения текущего активного слота необходимо воспользоваться утилитой fastboot. Команды:
Итоги и положения:
1. Между слотами как система, так и сам пользователь могут переключаться.
2. Изначально (с завода) слоты полностью идентичны между собой. Различия появляются после применения любого OTA обновления системы.
3. Слоты изолированы между собой. Состояние и целостность одного слота никак не влияет на другой. За исключением применения OTA обновлений (см. ниже).
«Seamless» система обновлений:
Итак, с разделами и слотами разобрались. Но что же там с обновлениями, наверняка их тоже коснулись изменения, ввиду описанного выше?
Да, OTA обновления на устройствах с A/B структурой кардинально отличаются от того, что мы можем видеть на других устройствах.
Android 8.0+ — трансляция обновлений:
Начиная с версии Android 8.0 возможна (но не обязательна) частичная реализация трансляции обновлений с одновременным их применением (прямая запись).
Это значит, что обновления не нуждаются в предварительной их загрузке, а применяются «на лету».
Как портировать прошивки на Андроид?
Портирование прошивок интересует многих продвинутых пользователей, которые хотят адаптировать свое устройство для другой среды с сохранением её полезных свойств. Обычно основная цель этого процесса — сделать прошивку на своём гаджете «интереснее» и расширить её функционал. Давайте рассмотрим, как всё это происходит на технике Android с платформой ARM.
Каждый из пользователей хотел бы добавить в свой гаджет что-то оригинальное
Что нужно для портирования прошивок?
Для осуществления этого процесса требуются следующие составляющие:
Как происходит портирование прошивки?
Затем, на устройстве, где мы будем собирать прошивку (его другое название — BROM) мы удаляем эти файлы, а вместо них копируем из источника, который ещё называется PROM следующие директории:
Ещё на базовый ROM мы копируем в папку /system/lib библиотеку libandroid_runtime.so. Теперь мы снова перемещаем в BROM прежде удалённые файлы из первого действия.
В последующем мы делаем копию таких библиотек из базового ROM’а в PROM, как:
Обратите внимание, что копирование производится с заменой существующих на другом оборудовании данных, а не в качестве их дополнения. Теперь мы удаляем три эти директории на BROM и на их место копируем всё из PROM`а.
Переходим к работе с редактором Notepad и выполняем следующие действия:
Примечание. Вы можете редактировать или добавлять такие параметры, как ядро или permissions, asserts, ui_prints, run_programs, но ни в коем случае не меняйте значение symlinks.
Последнее, что необходимо сделать — проверить в скрипте updater параметр Format values на базовом ROM`е (указанные данные должны подходить для вашего оборудования). Если у двух ядер разные производители, обязательно распакуйте ядро и скопируйте из портируемого ROM`a данные BOOTCLASSPATH на BROM по адресу init.rc.
После всех выполненных действий прошивка окажется в базовом ROM`е, а вы сможете дополнить её по своему усмотрению. Как видите, весь процесс занимает немного времени и не требует особых знаний. Поэтому вы вполне можете справиться с портированием прошивок самостоятельно.